大容量配信ネットワークをオンプレミスで構築する魅力と誇り

jst_recruit — Mon, 14 Jun 2021 04:51:29 +0000

企業のクラウド活用が進む中、Ｊストリームでは20年以上にわたりオンプレミスでのネットワーク構築にこだわってきた。

「何があろうともサービス提供を継続できる仕組みを作る――そのために思い込みをゼロにして、どうしたらできるかを考える。予測して、調べて、選定して、セットアップして、つなげて……要は全てをコントロールしたいんですよ」。

そこで自身の技術力が試される、と彼らは語る。今回は「ゼロベース思考」で設計し続ける2人のエンジニアに、オンプレミスでのネットワークの魅力について聞いた。

どんな不具合も調べあげ、解決し、事業継続性を担保する

――Ｊストリームでは自社構築ネットワークにこだわり、動画配信サービスを提供してきました。まずは自社のインフラの特徴からうかがいたいと思います。

はい、Ｊストリームが持つ動画関連のインフラは、ネットワークやストレージ、サーバなど汎用的なものから、ハードウェアエンコーダや映像伝送など動画に特化したものまで幅広く取り揃えています。

国内でも珍しいのですが、CDN（Content Delivery Network）というコンテンツ配信の仕組みを独自に構築し、大規模な配信にも耐えられるようにしています。多数の配信サーバで構成されたCDNでは、コンテンツを一時的にキャッシュし、オリジンサーバにかわりエンドユーザーへ配信しますが、キャッシュヒット率の向上にも日々取り組んでいます。

自社インフラ環境の最大の特徴は、ほとんどをオンプレミス（自社設備）で運用している事です。もちろんクラウドを使用する事もありますが、重要になる部分はすべてオンプレミスであり、それを運用するインフラエンジニアも基本的に社員で構成されています。

動画配信のネットワークといっても、Ｊストリームで扱っているような大規模なものは極めて数少ない存在です。また、動画配信は、一般的なWebサービスと比べ大容量のデータとなるので、クラウドでは厳しい部分が多々出てきます。

Ｊストリームがオンプレミスを重視しているのは、常に正しくエンドユーザーにファイルを送れるようにするためなんです。物理層からアプリケーション層まですべてのレイヤーを自分たちでコントロールできるからです。

事業継続性担保のためには、どんな不具合でも自分たちで調べて解決できないといけないという考えがＪストリームには強くあります。

やはりオンプレミスの柔軟性は、トラブルシュートにおいて圧倒的な解決スピードの差を生みますからね。

Ｊストリームのネットワークはあくまでも顧客サービスであり、プロダクトを支えるインフラなので、単純にネットワーク技術という観点だけでなく、自社プロダクトを通じてそれがどう使われるのかというビジネス側の視点抜きには存在しません。

そのため、使用される想定シーンを理解した上で事前に準備をし、整えておく必要があります。それでも、想定外のアクセスがきて円滑に処理することが求められことがあります。

例えば、テレビ連動のコンテンツなどの跳ね上がり方は一気にきます。

いろいろな予測をして、さまざまな仕組みを作ったりはしていますが、それでも想定の10倍以上のアクセスが瞬時に集中することもあります。その際には、クラウドの特徴であるオートスケールなどの機能では間に合わないことがあります。

オンプレミスならば、そこを救えます。社会へのソリューションとしてどうあるべきかを考え、「解決のためのエンジニアリング」という使命感を持って取り組める環境が、ここにはあると思います。

広帯域接続した複数のデータセンターへ配信サーバを配置し、ネットワークを分散制御

――コンテンツの大容量化が進んでいますが、現状、どのような対応を進めているのでしょうか。

動画のビットレートが広帯域化しています。動画を保存するストレージは、今では数TBが一週間で消費されている状況です。コンテンツ配信は、まさに増えるトラフィックとの闘いです。

その中で、24時間365日で使われるネットワークをいかに使いこなし、継続的に分散制御していくかが肝になると考えています。

オンプレミスでのネットワーク構築は、複数のデータセンターを契約しています。ここでのポイントは、配信サーバを分散配置していく事です。また、各データセンターで数十Gbpsから数百Gbpsという広帯域のインターネット接続をして、大量のアクセスに対応させています。

分散させたサーバを制御する仕組みも必要になりますが、こちらは今はGSLBを用いたロードバランス技術を活用しています。あとは、BGPを用いた動的ルーティングの技術、Ansibleを用いた複数台数のサーバの自動セットアップや構成変更などですね。

それらを使ってボトルネックなくトラフィックを転送し、どこがボトルネックになるか予想し排除していきます。ベテランでもめったに手掛けることのないようなことも数多くあります。入社してから、私も初めての経験にたびたび遭遇し、まさにインフラエンジニアとしての技量が日々試されているなと感じます。

Ｊストリームのインフラエンジニアは、データセンターや回線の選定から、ルータやサーバ選びなど物理的な面から対応しています。それらを接続性（ユーザーカバレッジ）、コスト、サービス品質など複数の要素で選定をしていくのは、仕事の醍醐味ですね。

どこのデータセンターを使うか、その際の回線はどうするか、そこに置くサーバをどう構築するかまですべて任せられており、これまでの経験を生かして自社のインフラ全体を見られますしね。

ストレージの部分も大切になりますね。アプライアンスだけでなく、自分たちでスケールできるソフトウェアも視野に入れて検討しています。

――構築を進める際は、ネットワークとサーバの両方の技術が求められるんですね。

そうですね。「ネットワークだけ」「サーバだけ」といったどちらかのみの知識では不十分で、その点では、ジェネラリストとプロフェッショナルの両方の感覚が求められると思います。

ネットワーク技術には波があり、その時の状況に応じて色々と判断が必要になります。サーバを並列でつなげたほうが効率を高められるのか、1台の持つ性能を高めたほうがいいのか、集中と分散の試行を繰り返しながら、その時のベストを選択する必要があります。

ルータにしても、PCみたいな小さなものの方が適した場合もあります。その選定や見極めに関しても、性能だけでなくコストも考えてより良い成果を出していけることが必要ですね。

それを継続して行うことで、技術力と市場競争力の両方を持つネットワークサービスを実現することができます。そこがＪストリームならではの面白さであり、難しさでもあると思います。

――高トラフィックを効率的に捌く仕組みは、どのようにしているのでしょうか。

これは広域負荷分散と呼ばれるものですが、フローに沿って仕組みを説明していきますと、まず、ユーザーの誘導ですね。これは、日常的にルーターのフロー情報から、エンドユーザーをどのデータセンターに誘導するかを自動的に処理しています。

xFlowのデータを基にGSLBを制御するのですが、フルルートの情報すべてをGSLBに登録する事はできません。

そこで誘導のキーとなるDNSサーバに関連するデータを抽出したり、配信トラフィックの多いAS番号に限定するなど、より最適な配信ができるように誘導をチューニングします。

具体的には、DNSベースの広域負荷分散の仕組みを構築し、エンドユーザーの利用するキャッシュDNSサーバのIPアドレスやAS番号などの情報を基に最適な配信サーバに誘導します。

CDNの領域ではキャッシュファイルをいかに制御しキャッシュヒットさせるかが肝になりますが、一般的なWebサーバ用のミドルウェアだけでは細かいキャッシュファイルが扱えない為、自分たちでミドルウェアを書いたりKVS(Key-Value Store)を駆使して動的サイトでも高いキャッシュヒット率を実現しています。

膨大なデータを配信するCDNだからこそ、オンプレミスのメリットは大きいですね。高トラフィックをどう上手く捌いていくか――大容量データを分散させ複数のデータセンター、ISPで負荷分散するためのコントロールであったり、さらにはトラブルシュートの原因の解明であったり、このあたりがCDNに関わる仕事の特に面白いところだと思います。

コンテンツ配信技術のノウハウを凝縮させ、自社の主力サービスへ昇華

――長年のコンテンツ配信の積み重ねの中から、インフラ技術をメインにした自社プロダクトも誕生していますよね。

はい、2015年に提供を開始したJ-Stream CDNext（ジェイストリーム・シーディーネクスト、以下CDNext）というCDNの自社プロダクトです。CDNextは、Web画面上からCDNを管理運用できるもので、現在、自社の主力プラットフォームサービスのひとつです。

CDNextは、長年のCDN個別案件や実証実験等での経験やノウハウをベースにプロダクトへ昇華させたものです。「高度なCDN技術をより手軽に、柔軟に、多くの方に活用いただけるように」というコンセプトのもとに、使いやすさやサポートも重視してサービス提供しています。

契約企業は柔軟に各種配信が制御でき、設定内容はキャッシュサーバへ迅速に反映される

CDNextのエッジサーバを置くデータセンターには、ToRスイッチにサーバが数台、このセットで100Gbps程度のトラフィックを配信できるようになっています。

ハードウェアの能力を無駄なく使い切るために、配信サーバのOSやミドルウェアをチューニングしていますので、設備が少なく、引っ越しもしやすい構成にしています。

ＪストリームではGSLB（広域負荷分散装置）を多段に利用してサービスを作っているので、いつでも簡単にデータセンターの引っ越しもできます。

また、サーバは自動セットアップで簡単に増やせるようにしています。

機能追加や新しいサービス立ち上げ時には、サービス開発担当部署と連携し、サービス開発側での考えをもとにネットワーク担当側で最適な設計を考えます。また、トラブルや障害発生時は、サービス開発側とネットワーク担当側でそれぞれのレイヤーを調べて解決に要する時間を最小限に抑えられるような体制をとっています。

――インフラ技術をメインにしたソリューションには、その他にはどのようなものがあるのでしょうか。

他にもマルチCDNの採用なども挙げられます。これは、可用性や地理的な配置、パフォーマンス、コストといったビジネスニーズに応じて、2つ以上のCDNから最適なものを選択し、負荷を分散させる仕組みです。大規模イベントなどの場合に推奨している考え方です。

マルチCDNでは、提携している他社CDNとトラフィックを融通する事もあります。URLの差異などがあり仕様が異なるので、多段に組み合わせる事でCDN毎の仕様の差異を吸収しています。

APIを連携させる事で、自社のCDNを使っているように見せたりするようなことも可能です。その場合にはトラフィックデータを見ながら、珍しく手動でロードバランサの設定を変更していくのですが、いつもとは違うトラフィックパターンを見ているとそれを自分自身でコントロールしている実感がありなかなか面白いですね。

日本のネットワークの最適化を考え、未来を創る取り組みに携わる

――増大し続けるインターネットトラフィックですが、最適化問題を解決するために、2020年12月には、地域IXの実証実験を行いましたよね。実験の目的はどのようなことにあったのでしょうか。

ネットワークは広帯域化していますが、首都圏・関西圏に集積するコンテンツ事業者の送出の増大が顕著で、周辺地域のインターネット事業者の大きな課題となっていました。すべてのトラフィックを東京と大阪に集めるのはコストや耐障害性の上で課題が残ります。やはりユーザーの近くに配信サーバを分散しておく必要があります。その解決に向けた取り組みでした。

日本は狭いと言っても広いから、何でも東京を介するのではなく、例えば九州へのトラフィックは九州から配信でできるようにしておかなければならない。そこで福岡にデータセンターを借りて地場のISPさんと契約することで、もっとダウンロードを早く、動画配信が途切れず、よりよい画質で視聴ができるように工夫していきました。

CDNもそうですが、自分は地域分散や広域分散をどう進めていくか。私自身、そこにとても興味がありましたので、携われたことは嬉しいです。オンプレミスのネットワーク構築には複数のデータセンターに分散して配信サーバを配置していく事がポイントで、それには分散させたサーバを制御する仕組みがキーになりました。

また、どのIXと繋げばよいか、どこで繋ぐかなど、検討すべきポイントは多岐にわたります。

現場では数msを積み重ねるような検証も多々ありますが、それによって大きなファイルならばダウンロード時間がぐんと短くなったりとか、サイト表示時間が短縮されたりとか。

ひとつひとつは大きな変化ではないかもしれませんが、それらが積み上げられた時に、日本のネットワークの最適化につながっていく。地道なことですが、まさにインターネットの未来を創ることに我々も携わっているんだという社会的な存在価値を感じられる瞬間ですね。

――新しい取り組みだけに、どういう課題設定をし、何を重視し、検証すべきか、まさにここでもゼロから考えながらですね。

実証実験に際しては、実験の意義を常に意識します。今回で言えば、大都市圏とは違った発想で考え、どう接続させていくかが求められました。

例えば、コストとユーザーの誘導においては、地方なので、東京よりもアクセスしてくるユーザは少ないです。そこで、コストを抑えるために地方拠点ではフルルート運用はやめました。AS番号も別で取得し、ある意味チャレンジできる環境にするという取組みも行いました。

ピアリング最優先で、地域ISPとの積極的ピアリングをしたんですよね。

そうですね。今はピアリングのトラフィックだけを地方拠点に誘導する方針で、障害時に拠点ごと切り離せるようにし、実運用の中で効果測定中です。私たちはデータセンターを複数抱えていますが、それをどのようにネットワーク接続していくか、そのやり方や考え方は無限にあるはずなので、これから入ってくる新しい仲間の考えも是非取り入れてみたいと思っています。

データ量を一切気にせずに開発できる環境。
成果を社会や業界へ還元

――最後に、Ｊストリームでエンジニアとして働くことのメリット、ベネフィットについて、開発環境や組織面からうかがいたいと思います。

エンジニアとして嬉しいことの一つ目は、まず、データ量のことを一切気にせずに開発ができることです。クラウド環境では、データトラフィックの料金などを気にしながら開発する事になるし、インスタンスの落とし忘れで膨大な請求が来てしまうなどの心理的な面もありますよね。

動画の場合、長時間ストリームを流したままで検証したり、大容量の4K/8K映像を基にエンコードテストなどをすることも多くあります。そのため、大容量データが流れ続けても気にせずにネットワークやストレージなどのインフラを組んである開発環境が必須になります。そこを専門のインフラエンジニアが直接見ているので、開発を手掛けるエンジニアにとっての恩恵は他社と比べてもすごくあるのではないかと思います。

二つ目は、インフラエンジニアが開発環境の構築に専念できることです。以前は全エンジニアが技術部という一つの枠の中にいましたが、組織変革の一環により環境が整備されました。

現在は、私たちのようにユーザーには見えない物理的なレイヤーを開発するチームから、CDNのキャッシュエンジンやプライベートクラウドを作るようなバックエンドチーム、アプリケーションとして目に見える部分を開発するフロントエンドチームと、専門の担当領域を分かれて活躍できるような組織体制になっています。

立場が違ってもお互いの意見を交換・理解し合い、それぞれの役割を果たしていこうという組織の空気があると思います。

動画配信はいろいろな技術を知らないとできないので、興味の幅が広いエンジニアが多い点が影響しているんでしょうね。社内は、インフラの他、動画技術、ライブ配信、フロントエンド、バックエンドなど多様なプロフェッショナルが存在します。

上のレイヤーの開発者の直面している課題があったとしても、下のレイヤーの開発者もそれを意識して取り組んでいこうという意識が強いですよね。

メリット・ベネフィットの3つ目ですが、自社の専門性を業界や社会に生かせている実感を得られることですね。CDNって一般的に言われるんですけど、実際にどういう風に動いているのか案外知られていないんです。

ですので、JANOGですとか外部講演なども会社として積極的に取り組んでいます。私も1月に開催されたJANOGで、他社の方と一緒に登壇しました。

中で自ら作っている人がまとめて発表することで、よくわかったという反応を得られたり、議論が広がっている様子を目の当たりにすると、自分も貢献できているんだという喜びを感じられますね。

――広がり続ける動画活用の中、インフラ領域での新しい課題も次々と出てくるかと思いますが、引き続きの活躍をお願いします。

※在籍年数や役職を含む記載内容は、取材当時のものです。その後、状況が変化していることがあります。

【関連情報】　※別サイトのＪストリームコーポレートサイトへリンクします。

J-Stream CDNext サービス紹介ページ　

仙台および福岡で地域IXにおけるトラフィック流通効率化の実証実験を実施（プレスリリース）