社内共通開発基盤をレガシーからモダンに移行──現場で感じる変化と効果

──今回のテーマとなる「J-Cloud」は、以前にはなかったものですよね。どういう経緯で作ることになったのか聞かせてください。

塩野目 ：「J-Cloud」は「J-Stream Cloud」の略で、自社のプロダクト開発やサービス開発を支える共通開発基盤です。2018年ごろに着手し、2023年1月現在も日々改良を重ねています。

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

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

城田：構築に関して使用されている技術は、変遷を繰り返しています。初期はRuby on RailsをベースにREST APIを実装していました。これは、基本的なフレームワークのルールをより厳格なRailsによって社員に浸透させる狙いもありました。次の段階としては、将来的な機械学習などAI分野への進出を見越してPythonなどの言語への変換を進めています。

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

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

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

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

1つのコンテンツをアップすると同期されたタスクが同時に動き出すため、データベースからエンコードまで全レイヤーを見ないと開発できませんでした。もちろん技術的にもですが、非言語化された「過去の経緯」や「作成者の想い」なども知らないといけない、属人的な開発スタイルに縛られていたともいえますね。マイクロサービス化によって、過去の経緯を気にせず単機能の開発に集中できるようになり、みんな積極的に機能開発を行うようになりました。

塩野目：スケールインやスケールアウトも容易になりました。また、CI/CDの整備によってデプロイリスクも軽減されましたので、開発者の心理として安全に集中した機能開発を行えるようにもなり、チャレンジする傾向が強くなってきましたね。全社員が使用できる共通開発基盤にすることで、再利用が基本的な考え方となり、大幅に開発スピードは向上しました。

疎結合な開発体制が整ったことで、動画のトランスコードに詳しいというようなスペシャリティも発揮できやすくなるので、尖った特技なども活かしやすくなったかと思います。動画という技術の移り変わりの激しい領域だからこそ、マイクロサービス化は必然だったように思います。

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

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

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

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

──Jストリームでの開発のおもしろみとは？

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

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

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

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

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

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

塩野目：それ以外では、新たな配信方式への対応ですね。リアルタイムな双方向配信だけでなく、大規模な配信に対しても素早く対応できる体制や仕組みを作っていきたいと思っています。

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

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

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