企業のクラウド活用が進む中、Ｊストリームでは20年以上にわたりオンプレミスでのネットワーク構築にこだわってきた。
「何があろうともサービス提供を継続できる仕組みを作る――そのために思い込みをゼロにして、どうしたらできるかを考える。予測して、調べて、選定して、セットアップして、つなげて……要は全てをコントロールしたいんですよ」。
そこで自身の技術力が試される、と彼らは語る。今回は「ゼロベース思考」で設計し続ける3人のネットワークエンジニアに、オンプレミスでのネットワークの魅力について聞いた。
T・K プラットフォーム本部 ネットワークエンジニア（新卒入社・23年目）
災害発生における情報提供、情報発信でのありがたさ・有用性を実感し、そのために必要なネットワークでの情報発信における堅牢性、冗長性可用性の技術に興味をもちました。動画配信における黎明期から携わって、なお変わりゆく配信技術の向上に楽しみながら携わっています。
N・T プラットフォーム本部 ネットワークエンジニア（新卒入社・15年目）
学生の時からストリーミングに興味があり、自分で配信サーバを作ってライブ配信していました。自宅にサーバーやネットワーク機器があり、そんな中で生活しています。
M・M プラットフォーム本部 ネットワークエンジニア（中途入社・2年目）
Jストリームでは複数のデータセンターを利用しているので「けしからんネットワーク」を使ってみたい！
※余談ですが、JANOGでけしからん連合ネットワークの発表者の登さんが情熱大陸に出演されていました。
――Ｊストリームでは自社構築ネットワークにこだわり、動画配信サービスを提供してきました。まずは自社のインフラの特徴からうかがいたいと思います。
はい、Ｊストリームが持つ動画関連のインフラは、ネットワークやストレージ、サーバなど汎用的なものから、ハードウェアエンコーダや映像伝送など動画に特化したものまで幅広く取り揃えています。
国内でも珍しいのですが、CDN（Content Delicery Network）というコンテンツ配信の仕組みを独自に構築し、大規模な配信にも耐えられるようにしています。多数の配信サーバで構成されたCDNでは、コンテンツを一時的にキャッシュし、オリジンサーバにかわりエンドユーザへ配信しますが、キャッシュヒット率の向上にも日々取り組んでいます。
自社インフラ環境の最大の特徴は、ほとんどをオンプレミス（自社設備）で運用している事です。もちろんクラウドを使用する事もありますが、重要になる部分はすべてオンプレミスであり、それを運用するネットワークエンジニアも基本的に社員で構成されています。
私は2019年10月にＪストリームに転職してきましたが、動画配信のネットワークといっても、これだけ大規模なものは扱ったことがなかったです。前職を含めクラウドの利用経験もありますが、動画配信は、一般的なWebサービスと比べ大容量のデータとなるので、クラウドでは厳しい部分が多々出てきます。
M.M.さんのコメントにも重なりますが、Ｊストリームがオンプレミスを重視しているのは、常に正しくエンドユーザにファイルを送れるようにするためなんです。物理層からアプリケーション層まですべてのレイヤーを自分たちでコントロールできるからです。
事業継続性担保のためには、どんな不具合でも自分たちで調べて解決できないといけないという考えがＪストリームには強くあります。
やはりオンプレミスの柔軟性は、トラブルシュートにおいて圧倒的な解決スピードの差を生みますからね。
Ｊストリームのネットワークはあくまでも顧客サービスであり、プロダクトを支えるインフラなので、単純にネットワーク技術という観点だけでなく、自社プロダクトを通じてそれがどう使われるのかというビジネス側の視点抜きには存在しません。
そのため、使用される想定シーンを理解した上で事前に準備をし、整えておく必要があります。それでも、想定外のアクセスがきて円滑に処理することが求められことがあります。
例えば、テレビ連動のコンテンツなどの跳ね上がり方は一気にきますよね。
そうですね。いろいろな予測をして、さまざまな仕組みを作ったりはしていますが、それでも想定の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を使っているように見せたりするようなことも可能です。その場合にはトラフィックデータを見ながら、珍しく手動でロードバランサの設定を変更していくのですが、いつもとは違うトラフィックパターンを見ているとそれを自分自身でコントロールしている実感がありなかなか面白いですね。
ネットワークは広帯域化していますが、首都圏・関西圏に集積するコンテンツ事業者の送出の増大が顕著で、周辺地域のインターネット事業者の大きな課題となっていました。すべてのトラフィックを東京と大阪に集めるのはコストや耐障害性の上で課題が残ります。やはりユーザの近くに配信サーバを分散しておく必要があります。その解決に向けた取り組みでした。
日本は狭いと言っても広いから、何でも東京を介するのではなく、例えば九州へのトラフィックは九州から配信でできるようにしておかなければならない。そこで福岡にデータセンターを借りて地場のISPさんと契約することで、もっとダウンロードを早く、動画配信が途切れず、よりよい画質で視聴ができるように工夫していきました。
CDNもそうですが、自分は地域分散や広域分散をどう進めていくか。私自身、そこにとても興味がありましたので、携われたことは嬉しいです。オンプレミスのネットワーク構築には複数のデータセンターに分散して配信サーバを配置していく事がポイントで、それには分散させたサーバを制御する仕組みがキーになりました。
また、どのIXと繋げばよいか、どこで繋ぐかなど、検討すべきポイントは多岐にわたります。
現場では数msを積み重ねるような検証も多々ありますが、それによって大きなファイルならばダウンロード時間がぐんと短くなったりとか、サイト表示時間が短縮されたりとか。
ひとつひとつは大きな変化ではないかもしれませんが、それらが積み上げられた時に、日本のネットワークの最適化につながっていく。地道なことですが、まさにインターネットの未来を創ることに我々も携わっているんだという社会的な存在価値を感じられる瞬間ですね。
そうですね。私も現地入りしてネットワーク構築を行いましたが、ネットワークエンジニアとして、この実験に参加する意義を常に意識しながらの日々でした。大都市圏とは違った発想で考え、どう接続させていくかが求められましたね。
私が重視した点としては、コストとユーザの誘導です。地方なので、東京よりもアクセスしてくるユーザは少ないですし、コストを抑えるために地方拠点ではフルルート運用はやめました。AS番号も別で取得し、ある意味チャレンジできる環境にしたんです。
エンジニアとして嬉しいことの一つ目は、まず、データ量のことを一切気にせずに開発ができることです。クラウド環境では、データトラフィックの料金などを気にしながら開発する事になるし、インスタンスの落とし忘れで膨大な請求が来てしまうなどの心理的な面もありますよね。
動画の場合、長時間ストリームを流したままで検証したり、大容量の4K/8K映像を基にエンコードテストなどをすることも多くあります。そのため、大容量データが流れ続けても気にせずにネットワークやストレージなどのインフラを組んである開発環境が必須になります。そこを専門のインフラエンジニアが直接見ているので、開発を手掛けるエンジニアにとっての恩恵は他社と比べてもすごくあるのではないかと思います。
二つ目は、インフラエンジニアが開発環境の構築に専念です。以前は全エンジニアが技術部という一つの枠の中にいましたが、組織変革の一環により環境が整備されました。
現在は、私たちのようにユーザには見えない物理的なレイヤーを開発するチームから、CDNのキャッシュエンジンやプライベートクラウドを作るようなバックエンドチーム、アプリケーションとして目に見える部分を開発するフロントエンドチームと、専門の担当領域を分かれて活躍できるような組織体制になっています。
立場が違ってもお互いの意見を交換・理解し合い、それぞれの役割を果たしていこうという組織の空気があると思います。
動画配信はいろいろな技術を知らないとできないので、興味の幅が広いエンジニアが多い点が影響しているんでしょうね。社内は、ネットワークの他、動画技術、ライブ配信、フロントエンド、バックエンドなど多様なプロフェッショナルが存在します。
上のレイヤーの開発者の直面している課題があったとしても、下のレイヤーの開発者もそれを意識して取り組んでいこうという意識が強いですよね。
