レガシーな開発環境を脱却するために、モダン開発をベースにして構築された全社共通の開発基盤「J-Cloud(ジェイ-クラウド）」。
その存在は、開発スピードと柔軟性を大幅に向上させ、開発体制に大きな変化をもたらしている。今回、構築を手がけた3人のバックエンドエンジニアに話を聞いた。

ー まずは簡単に3人のプロフィールを紹介！

◆T. S.　プラットフォーム本部 バックエンドエンジニア（11年目・新卒)
大学・大学院では宇宙の研究をしていましたが、動画が何となく面白そうだなとこの世界に。ネットワークからバックエンドの開発まで幅広く関わってきました。動画配信技術が大きく変わる中、フロントエンドにも挑戦して新しい技術へ機敏に対応できるようにしたいです。

◆M. S.　プラットフォーム本部 バックエンドエンジニア（9年目・新卒）
学生時代からネットワークを組んでいました！最初はライブエンジニアとして全国を飛び回っていましたが、その後、インフラ部署を経て開発部署へ。チーム力という点では、お互いの失敗を受け入れ、相談し、一緒に解決できることを大切しています。

◆Y. M.　プラットフォーム本部 バックエンドエンジニア（5年目 新卒）
配信サーバの操作や動画トランスコードの実行を管理する統合APIの開発に従事。現在、配信データのログ解析・集約に向け、機械学習領域を学習中。「J-Cloud」構築経験を通じて開発基盤の重要性を再認識、グランドデザインを描けるエンジニアを目指します！

開発環境構築のキーは、マイクロサービス、インフラのコード化

― 今回のテーマは「J-Cloud」ですが、これは以前はなかったものですよね。どういう経緯で作ることになったのか、まずは、その辺りから話を聞かせてください。

M. S.「J-Cloud」は「J-Stream Cloud」の略で、自社のプロダクト開発やサービス開発を支える共通開発基盤です。2018年頃から着手し、現在も日々改良を重ねています。

アジリティ面の特徴としては大きく２つあります。一つはSubversionからGitLabへ移行しモダン開発ベースでのマイクロサービス構成にて開発スピードと高い柔軟性を実現している事。もう一つは、DockerやKubernetesによるコンテナ技術やAnsibleなどを用い、Infrastructure as Codeをベースとすることで、CI/CDの概念によるインフラの構築や運用を自動化できる事です。

各機能をモジュール化し、それぞれをステートレスに設計する事で機能の依存性をできるだけ分離し、スケール性も確保しています。それと同時に、共通する部分は汎用的に作りこむ事で、どこかのプロダクトで作った機能をそのまま他のプロダクトでも再利用できるようにしています。

Y. M.　構築に関して使用されている技術は、着手当時から現在も色々変遷を重ねています。初期はRuby on RailsをベースにREST APIを実装していました。これは基本的なフレームワークのルールをより厳格なRailsによって社員に浸透させる狙いもありました。現在はある程度MVCなどの概念も理解が進んできておりますので、次の段階としては、将来的な機械学習などAI分野への進出を見越してPythonなどの言語への変換を進めています。

とはいえ、インタプリタ言語だけではもちろん高速な処理などは追いつきませんので、APIの内部処理として動く各マイクロサービスではJavaやGolangなどのコンパイル系言語も取り入れています。この辺りはnginxやRedisなどのミドルウェアも組み合わせて開発していますので、一般的な開発経験があればすぐに取り掛かれるようにという部分に焦点をあてて標準化させています。

「J-Cloud」構築の背景には、Ｊストリームに特化した開発者ではなく、日本や世界で通用する開発者への成長を促す狙いがあります。いかにＪストリームで育ったエンジニアが他でも通用するか、また他で活躍しているエンジニアがそのままＪストリームで活躍できるか。オンプレミスのインフラや動画領域の経験など、コアコンピタンスな部分はどうしても特殊性は残りますが、それ以外のアーキテクチャはそれらの経験有無に影響されないので、スタートはきりやすいと思います。

―　マイクロサービスアーキテクチャの導入により、開発者目線ではどう変わりましたか？

Y. M.　自分が入社した時は、まだサービス単位でモノリシックに開発されていたので、とても触るのが怖かったですね。機能が密結合されており、何かを触ると他の部分で想定外の動作になるなど、どこまで影響があるのか誰も把握できない状態でした。

M. S.　一つのコンテンツをアップすると同期されたタスクが同時に動き出すため、データベースからエンコードまで全レイヤーを見ることができないと開発できませんでした。もちろん技術的にもですが、非言語化された「過去の経緯」や「作成者の想い」なども知らないといけない属人的な開発スタイルに縛られていたともいえますね。

マイクロサービス化によって、新しい機能を追加する際に既存のコードを触る機会が大幅に減りました。大きなクラスを触っていたら想定外のところでそのメソッドが呼び出されていてバグが出るなどのリスクも無縁になりましたので、過去の経緯を気にせず単機能の開発に集中できるようになり、みんな積極的に機能開発を行うようになりました。

Y. M.　ステートレスなマイクロサービス化によって、スケールインやスケールアウトも容易になりました。また、CI/CDの整備によってデプロイリスクも軽減されましたので、開発者の心理として安全に集中した機能開発を行えるようにもなり、チャレンジする傾向が強くなってきましたね。チャレンジの数を増やせれば、成功の可能性も増やすことができる。そうやって技術者目線での新しい試みを増やすことが、会社としての強みを増やす事に直結しているんです。

M. S.　リスクもそうですが、マイクロサービス化されたそれぞれの機能は再利用が容易なのも大きいですね。サービスごとに同じような機能を作る「車輪の再発明」のような事は、とても多く発生していました。同一サービスの開発チーム内でも、バックエンドエンジニアとインフラエンジニアが同じようなサーバを作っていたりもしましたしね。全社員が使用できる共通開発基盤にすることで、再利用が基本的な考え方となり、大幅に開発スピードは向上しました。

Y. M.　疎結合な開発体制が整ったことで、「動画のトランスコードに詳しい」というようなスペシャリティも発揮できやすくなるので、尖った特技なども活かしやすくなったかと思います。いろんな特技を持った人が参加する事で、小さな単位での機能レベルから底上げを図り、やがては大きな技術的変遷への対応、世の中のニーズへ決め細かくこたえられる。動画という技術の移り変わりの激しい領域だからこそ、マイクロサービス化は必然だったように思います。

M. S.　はい。今はリリース環境とステージング環境をKubernetes上で構築し、人的ミスを回避できるようにCI/CDによる自動化を取り入れています。導入当初はJenkinsなども使用していましたが、いまはArgoCDに変更するなど日々改善を続けています。

Y. M.　以前は、最初の一歩が重たい感じでした。実機のサーバを調達して、開発するときにはtopコマンドなどでリソースの空きを確認し、historyなどを見ながら恐る恐る触る感じです。開発が終わってデプロイする際にも目視チェックなどを行っており、人的ミスが無いようにすごく神経を使っていました。それに比べれば、重たかった一歩はずいぶんと軽くできたのではと思います。

M. S.　インフラのコード化に関しても、現在はフロントエンドやバックエンドの開発者が自分たちでサーバやミドルウェアの構築、テストやデプロイまでをコードで表現します。自動化などのメリットもそうですが、インフラエンジニアと開発者がコードを通じてやりたいことを相互に理解できるよう共通言語化されたのが大きいですね。コミュニケーションロスもなくなりました。

Y. M.　環境を作るまでの時間が圧倒的に短くなりましたね。コンテナなら、自分たちの開発端末にDockerをインストールしておけばそこでスクラップ＆ビルドを行い、納得できるまでコンテナのビルドチューニングを行える。そこで作ったコンテナはそのままステージングやリリース環境のKubernetes上でも使用される。Vagrantからlibvirtを使用してKVMの仮想サーバ自動生成も気軽にできるので、さっと動かしてみてダメなら壊して簡単にやりなおせます。

何かを思いついたら自分の隙間時間を使ってちょっと試してみる。ダメなら壊す。また思いついたら触ってみる。開発者にとってのチャレンジって構えて行う「大きな何か」ではなく日常的に繰り返す「小さなひらめき」ですから、それを後押しし実現できる開発環境が必要なんです。

技術変化の激しい動画領域で開発スピードを上げていく

― 動画領域の開発では、「J-Cloud」はどのようなメリットがあるものなのでしょうか？

M. S.　一番は、技術や世の中のトレンドに素早く対応できることです。動画領域は技術変化が特に激しく、主流となる技術が4～5年で一変する事も珍しくありません。大きなシステムを作ってしまうと一部だけを変えようにも、全く関係のないところで想定外のバグが出たりなどで、世の中の変化のスピード的についていけない。

「J-Cloud」では、例えばHLS配信においてもPlaylist作成部分を分離してあります。前段の処理をそのまま生かしつつ、Playlistのレンダリングの時点でMPEG-DASH用のPlaylist作成処理だけを追加しHLSと置き換えるイメージですね。そうすれば、そのままMPEG-DASH配信だけでなく、CMAFなど新しい規格にもすぐに対応が可能です。それらの機能をAPIで提供していますので、パラメータでHLSやMPEG-DASHかを選んでもらえればすぐに新しい機能をプロダクトに提供できます。

M. S.　コロナ環境下では動画活用が急速に拡大しました。中でもインターネットライブをもっと手軽に使いたいという企業ニーズが一気に高まり、私たちも緊急開発を多く行いました。その中の一つに疑似ライブ（収録動画をタイムスケジュールに沿ってライブ配信する事）機能がありますが、これは自社プロダクトである「J-Stream Equipmedia（ジェイストリーム・イクイップメディア）」へごく短期間で追加できました。（※関連記事はこちら）

これはそもそも前述したようにレンダリングを別にしたエンジンを作っていたというのもあり、そこにフレーム制御でのカット機能を盛り込むことで機能の再利用を行った事によります。また当然、プロダクトの開発者であるフロントエンドエンジニアが全く動画について調べなくても良かったという、標準的なスキルによる分業化という事も大きいです。

Y. M.　動画由来のメリットという点では、動画データは滞納トラフィックが起こりやすいためスケールを考慮する必要があるのですが、その場合でも処理の重い部分だけをスケールする事でリソースの節約を行う事が可能になりました。必要な処理だけをいくつも複製できるので、一つのコンテナで障害が発生しても別のコンテナで処理を続行するなど、障害回避の構成を作るうえでも役立っていますね。

― Ｊストリームでの開発の面白みとは？

M. S.　Ｊストリームのユニークな点は、オンプレミスの基盤と設備を持っている事です。動画配信と開発を同時にやっている会社は日本でも数少ないですからね。オンプレミスで一から自分で作る楽しさは格別です。

とはいえ、オンプレミスだけでやっていると全体スピードとしては落ちてしまう。「J-Cloud」の構築ではまずはクラウドベースでスタートさえスピードアップを図りながら、徐々にオンプレミスへの移行を計画しています。インフラを柔軟に操作できるようになると、エンコードアクセラレーターなどの独自ハードウェアの組み込みや、キャリア網を使用したエッジコンピューティングなど、様々な利点がもっと出てくると思っています。

Y. M.　クラウドとオンプレミス、どうハイブリッドにしていくかですよね。クラウドの障害時にはオンプレミスに、またオンプレミスの障害時にはクラウドに逃がすなどを考慮すると、ハイブリッド化は必須になると思います。またクラウドも当然マルチクラウドであるとより堅牢になります。

M. S.　5Gなどを見据えると、各キャリアのネットワークに合わせたインフラ設計も必要です。マルチクラウドでありマルチキャリアな汎用プラットフォームは、インフラを含めた設計が必須になりますし、それができるポジションにいるのがＪストリームの良さですかね。

M. S.　直近の課題はそのあたりですね。まずは現在動いている物理サーバをなるべくたくさんコンテナに移行し、コンテナで動くことがまず当たり前の仕組みを作っていけるとよいのではと考えています。

データ処理、双方向配信、MEC……「J-Cloud」の成長の方向性とは？

― 今後、「J-Cloud」へどのような機能拡充を考えていますか？

Y. M.　コロナ環境下での動画配信ニーズの高まりの中で、ライブやトランスコードなどの機能拡充の必要性を感じています。もちろんこれらの基本機能に関しては機能拡張を進めていければと思っていますが、ライブやトランスコードに関する詳細なフィードバックを提供できるように、高度な学習や予測なども取り入れていきます。今は配信するだけではなく、結果を問われる時代ですからね。

M. S.　データ処理基盤ですね。現在でもCDNプロダクトの「J-Stream CDNext（シーディーネクスト）」ではKafkaやHadoopなどを使用してログの大規模処理を行っていますが、それはあくまで結果を可視化するだけのもので、学習や予測などの領域には手を出せていませんでした。Pythonをベースとした機械学習や深層学習などのエッセンスを取り入れていき、AIの活用を前提とした基盤を作れれば、面白いデータが出せるのではと思ってるんですよ。

Y. M.　ちょうど今、昨年入社の新卒メンバーにメインとなってもらい、一緒にログ処理の基盤機能開発を進めている所です。彼の機械学習領域の経験を生かしてデータ部分を作ってもらっています。APIの使用データをPandasで読み込んだ後、scikit-learnなどで決定木にかけることでどういうパターンの際にどういうパラメータが望ましいかなどを自動判別するなど、徐々にAIの活用部分を増やしていければ面白いですね。

M. S.　それ以外では、新たな配信方式への対応ですね。動画配信のプロトコルや仕様はここ10年で大きく変わりました。昔はFlashによるRTMPベース、今はHTTPベースのHLS配信方式がデファクトで使われていますが、ここ数年はWebRTCを使うとリアルタイムな双方向配信だけでなく、大規模な配信なども対応できるようになってきています。そういう動きに対して素早く対応できる体制や仕組みを作っていきたいと思っています。

Y. M.　双方向はやってみたいですね。1対多で配信者と視聴者が分かれている大規模配信はどこでもやっているけど、今は双方向性のあるものが求められています。見ている人がチャットで参加出来たり、音声通話でジョイント出来たりなどは昔からありますが、それ以外にも見るだけではなく参加できる為の様々なアクションを増やしていきたい、その為の機能開発を増やしていけると面白いでしょうね。

M. S.　私はSREについて本格的に取り組みたいですね。監視を細かく行い、月にどれくらいエラーや障害が発生しているかを把握できるようにする。それで「何％まで抑えていこう、これくらいまでなら大丈夫だからもっとチャレンジしよう」と具体的に進めていければと考えています。

機能追加に関しても、今までは営業主体で顧客ニーズに応えるという、開発主体という視点で考えるとやや後手なところがありましたが、SREをベースにSLI(Service Level Indicators)を定義し、開発側からも先手を打って主体的に動けるためのデータを揃える事で、よりチャレンジの目標を明確にできるようにしたいですね。

あとは5G関連でのMECであったり、H.266などの配信フォーマットを実証実験してみたり、…となるとやはりマルチクラウド環境ですかね。

Y. M.　みんな自走力が高いから、どんどん問題を解決したがる（笑）

Ｊストリームは動画配信ネットワークから始まったこともあり、インフラの強い会社だという印象が強いのですが、共通の開発環境として「J-Cloud」ができたことで開発力も確実に上がってきている。「J-Cloud」構築の経験を通じて、開発環境がエンジニアにもたらす影響力を強く感じました。

M. S.　新しい機能を作ることがメインだから、結構チャレンジしていかないといけないし、それをできる為の環境がそろっている、と。

Y. M.　ロールバックもできるから楽ですしね（笑）

M. S.　試行錯誤で悩んだ時も、APIを叩けばJ-Cloudがポンと新しいコンテナを立ち上げてくれますから、安心してチャレンジしてもらいたいですね！

― 今後の基盤拡充にも期待しています。ありがとうございました。