NTT東日本の佐藤と申します よろしくお願いいたしますこちらのセッションでは 当社が準備を進めている映像解析AIプラットフォームについてご紹介したいと思います これはネットワークとコンピューティングを統合したメッグのプラットフォームで 映像解析をもっと短なものにしていこうというものでございます本日はそのコンセプトと それを支えるテクノロジーの根幹でありますオープンシフトを使ったコンテナオケストレーションについて ご紹介したいと思いますはじめに自己紹介させていただきます 私は2007年にNTT東日本に入社をいたしましてキャリアのうちの10年近くおサービス開発の仕事を 携わらせていただいておりますNTTらしいネットワークサービスの開発ですとか あとは音楽配信のサービスの開発を担当させていただきまして 現在ではAI 特に映像解析のサービスの開発に注力をしております こちら本日の目指でございますはじめにNTT東日本の紹介をさせてくださいNTTグループの中でも国内通信事業になっておりましてフレッツ光やギガラクワイファイといった 通信サービスの提供を通じて生活産業のインフラを 皆さまにご提供さし上げています近年ではAI IoTを活用した デジタルトランスフォーメーションにも力を入れています直近のコロナの影響を受け止めて 社会の更なるスマートカーを推進してまいります通信に求められるものは 近年非常に変わってきていますこれまで通信の中心には 常に人がいました電話をかける あるいはインターネットを使う常に中心に人がいて サービスが提供されていますただ IoTの時代を迎えて 人もものもあらゆるものがつながってネットワークで情報をやり取りするようになってきていますそこでやり取りされるデータの量や バリエーションは爆発的に増えていますそこに再適化されたアキテクチャー あるいはサービスのあり方というものが必要だというふうに考えています当社では ネットワークとコンピューティングを統合したメッグのプラットフォームの構築を進めています合わせて 地域社会の皆様や 様々なステイクフォルダーの皆様と一緒にサービスを作る サービス競争を始めていますこのメッグのプラットフォームが もっとも生きる分野の一つに映像解析があるというふうに考えています少し 映像解析の市場に目を向けてみたいと思います映像解析の市場は 2023年までに1,500億円まで成長することが見込まれており 国内で出荷されているIPカメラ映像解析の重要なインフライになりますこちらも年間100万台以上が出荷されていますこのIPカメラ 既に500万台以上が国内で 稼働されていると言われていますあらゆる業種業態で広く使われており映像解析を広げていく上で 十分なインフライになっているというふうに見えます一方で AIによる映像解析はその利用以降が非常に高いにもかかわらず実利用に至っているケースは限定的ですこれはなぜか私たちは AIを使うカスタマーとそれを提供するサービスは 両方に課題があるというふうに考えています順番に見ていきましょうカスタマーが固えている課題は 3つですまず 映像解析に専用のシステムが必要になることが多くこれには大きな初期投資が必要になりますまた 季節のカメラが使えない AIのサービスがありカメラへの投資が20、30になってしまいますさらに 欲しい時に欲しい分だけ使えるといったフレキシビリティのあるサービスが 少ないことも挙げられます一方 サービスが抱えている課題 こちらは2つですシステムインテグレーションで提供する場合カスタマーごと あるいは拠点ごとにアプリケーションとの負担が発生しますクラウドで提供する場合にも ネットワークやセキュリティなどAIの開発以外にもリソースを作る必要がありこちらの負担も無視できませんこのような双方の課題を解決するために当社のメッグのプラットフォームを利用してAIのアプリケーションをサース化しますそして 季節のカメラとメッグをセキュアに交代域に投放しますそれすることによってお客様は システム構築なしに季節のカメラで AIの解析がスタートできるようになりますまた 使いたいAIを使いたい分だけ使えますこの4つの特徴をメッグのプラットフォームの上で実現していますこれを 映像解析AIプラットフォームとして提供する予定ですこの映像解析AIプラットフォームは多くのサービスさんにとって 使いやすいものにするためにアプリケーションのデプロイメントを 容易にするということを突き詰めてまいりましたそれを支えているのが オープンシフトによるコンテナオケストレーションですここからは スピーカーバトンタッチしまして高野さんから 紹介していただきたいと思いますNTT東日本の高野と申しますそれでは ここから私が主に技術面について お話をしたいと思いますよろしくお願いいたしますでは プラットフォームを支えるオープンシフトによる コンテナオケストレーションと題しまして三つのテーマについてお話しいたしますテーマはこちらになりますまず 映像解析AIプラットフォームの コンセプトと技術スタック次に では このプラットフォームになぜオープンシフトを採用したのかここまでを背景としてしましてヘルムで実現する 映像やワークロードのギットオプス実装 この部分を従点的にお話ししたいと思いますでは 初めに プラットフォームのコンセプトと技術スタックについて お話しいたしますこちらのプラットフォームは映像とAIが 気になっておりますので現在 どのような形でこのカメラとAIが結びつけられているのかというところについてお話をさせていただきます左から右に向かって 処理のフローが書かれているんですが注目していただきたいのは四角で大きく囲われた左側の部分ですね一つのカメラに対して一つのGPUサーバーがつながっていてつまり このカメラはこのAIを処理するためだけに使われている一カメラ 一AIこういった形が多く見られる方式になっております対しまして われわれが目指すコンセプトとしましては左側から右側にとありますようにプラットフォームというものを作りましてその上にAIサービスさんが作ったAIアプリケーションを載せていくそしてカスタマ様は自分のカメラを使いたいAIに対してつなげていくつまりマルチカメラ マルチAIといったものを実現しようそのように考えております最後にプラットフォームの構成ですが真ん中のですね東日本マネージドサービスと書かれた部分にレッドハットのオープンシフト コンテナプラットフォームを採用したとこのような構成を採用しております一旦まとめますとコンセプトと技術スタックとしてはオープンシフトというものを軸にマルチカメラ マルチAIを実現していくといったものになっておりますでは続きましてなぜオープンシフトを採用したのかについてお話させていただきます理由としましては こちら1点につきましてまず実現したかったこととしてはリリースサイクルを早くしたいといったことがあげられますこのAIの業界かなりアプリケーションのアップデートの頻度も高く新しい機能もどんどん出てきているそのような中でサービサ様が作った新しいアプリケーションの新しいバージョンをですねどんどんリリースしていく 基板側としてはそれをいかに簡単にしていくかというところがきもだとそのように考えましたそしてリリースサイクルを早くしたいとなってきている時に我々もですねコンテナですとかテールさせるためのクーバネティスを採用しようというふうになってきたわけですがでは実際にクーバネティスを照用で運用していくということを考えた際に2つ課題と感じたものがございますまず1つ目が周辺機能の実装でしてこの図の左側クーバネティスクラスターの右側にオレンジ色で塗った部分が 周辺機能となっております例えばモニタリングロギングですとかそのような形でものがあるかと思いますこういった周辺機能は自分たちで用意しないといけないというところがまず1点目そしてもう1点目が下のアップデート対応ですねこちら1年以内にどんどんバージョンアップをかけていきそれを自力でクーバネティスを使う場合は解決しないといけませんまた先ほど申し上げた周辺機能との互換性というものを常に取っていかないといけないこれをどうしていくかというところを考えた時にエンタープライズ版であるオープンシフトを採用させていただいたという経緯がございますここまででまた一旦まとめさせていただきますとマルチカメラマルチAIをやっていくにあたってコンテナ そしてクーバネティスに注目した時にクーバネティスだけでは足りない部分を商用サービスとして実際に運用していくためにオープンシフトを採用いたしましたではここからはヘルムで実現する映像AIワークロードのGitOps実装というところについてお話しさせていただきます2つに分けさせていただきましてまず1つ目がヘルムでGitOpsをやっていく時に我々が何を課題と感じたのかというところについてお話しした後に実際にではどのような戦略を持ってそれを乗り越えていったかというところについてお話しさせていただきますでは初めに課題についてお話しさせていただきます課題についてお話しする前にまず映像AIのワークロードこれ我々の独自の用語なんですがとは何かというところについてお話しさせていただきます名前に映像AIとついていますとおりまさに映像に関わるそしてAIに関わるというところが非常に特徴となっておりましてまず左側ですね左側のGPUを用いてAI推論するというところが1つポイントになってきますこのGPUを使うことで非常に高速な処理が可能になりますしたくさんのカメラを1つのサーバーに集約することが可能になってまいりますもう1つのポイントがクライアント型ワークロードと書かせていただいたんですがコンテナにあるアプリケーションがカメラに映像ストリームを取得する際にRTSPというプロトコルを使うんですがこれを使う際には実はカメラがサーバーそしてサーバーの上にあるアプリケーションがクライアントという形で通信をいたしますそういったところは非常に大きなポイントとなっておりますそしてここから先はこの特に右側のクライアント型ワークロードである点に着目をしてお話をさせていただきますでは少し話が変わりましてGitOpsの環境を我々はどのように構成したのかについてお話をさせていただきますこちらは図の上段にCIのパイプラインそして図の下段にCDのパイプラインがありますこちら青色のアプリ開発者の方は上段のパイプラインを使って自身が開発したアプリケーションをコンテナにしてコンテナレジストリに格納しますそして非常にリリースサイクルを早くしたいというところでもお話ししましたが新しいバージョンが出ましたとなった際には新しいバージョンをそして使いたいという時にはオレンジの転線部分ですねプロリークエストという形でマニフェストリポジトリーにキックしていきますそうすると左下の承認者が承認をして右側のデプロイのフローに移るわけですがそこでジェンキンスそしてジェンキンスエージェントからこのCLIを叩くという構成を採用しておりますこちら採用の理由としましてはその当時オーシッピー上でですね実際にGAとなっていた2つの機能を採用したという経緯がございます続きましてこちら囲わせていただいたヘルムの部分なんですが今回は特にこのヘルムの部分についてフォーカスをしてお話をさせていただければと思います続きまして少し話題が変わりますがフクーバーニティスの世界でこの映像AIのワークロードを見ていくとというところについてお話をさせていただきますこちら左側にステージング環境右側にプロダクション環境を想定した環境を設けておりましてそれぞれカメラがつながっていますそして環境の上にはポットが立っていてポットにはそれぞれコンフィグマップが割り当たっておりますじゃあなぜコンフィグマップを割り当たっているかというと実際にカメラのURLというのは個々に異なりますのでそれぞれ狙ったカメラにそれぞれつなげるためにコンフィグマップにカメラURL情報を持ちいて持たせております続きまして先ほど絵に描いた部分をクーバーニティスのやむるファイルの観点で見ていくとこのようになります非常に分量が多くなってきたかなというところもお見受けいただけるかと思いますが着目していただきたいのは赤字になっている部分でございましてこちらは一つ一つのやむるごとに値が異なっています色々の部分は値が異なっておらずポットであればポットドシコンフィグマップであればコンフィグマップドシ同じ値を使っておりますこちらが意味するところが何かともしますと同じようなやむるが大量に存在しているただしパラメータが異なるそういったところが一つこの映像やいワークロードの特徴になっておりましてこれをどのように実現していくのかというところで我々はヘルムのテンプレート機能というものに着目をいたしましたでは一旦ヘルムとテンプレート機能についてお話をさせていただきますと図の左上ですね変数と書かれたものにバリューズ.yamlと記載がございますまさに名前が示すとおり変数をずっと並べてあるファイルになっておりまして左下にはテンプレート各ポットという形で先ほどですね赤字で書いていた部分が変数になっているものがあると思っていただければと存じますそしてこの変数とテンプレートかけ合わせますと右側ですね実際にポットのヤムルが数だけ生成されるとそういった機能がヘルムにございます対して先ほどは左下にポットと書かせていただいたんですが次はコンフィグマップになりますコンフィグマップについても同様でして変数ファイルと左下コンフィグマップのテンプレートかけ合わせることでその数だけのコンフィグマップのヤムルファイルを生成することができますでは続きまして今まではクーバネティスのリソースそしてクーバネティスのヤムルそしてそれをヘルムでどう書くかというところについてお話ししましたがギットオプスですので次はギットの観点で見ていきたいと思いますご覧いただいているように左側にステージングブランチそして右側にプロダクションブランチを配置しておりますまた各ブランチの中に配置されているファイルとしてはヘルムのテンプレートというところでお話ししましたファイルを配置しているそのような構成を採用しております続きましてそれぞれのブランチの役割について一度お話しをしますとステージング環境というのはサービスはさまが作った新しいアプリケーションを持ってきて本番環境つまりプロダクション環境に適用する前に最終確認を行う場ですそしてステージングブランチでテストがOKだったものを右側のプロダクションブランチに持ってきましてコードユーザー様にサービスを提供するそのような役割になっておりますでは続きまして実際にあり得る運用上を出てくるユースケースを考えてみます先ほどステージング環境は最終テストの場という形でお伝えをしたかと思いますが実際に新しいアプリのバージョン例えばバージョン1からバージョン2にアップデートをする検証したいというユースケースを考えますこちらずに示しているのは先ほどお示ししたYAMLと全く同じものなのですがこちらをこのようにしていきたいというユースケースはかなり多くあるかと存じます左側のステージング環境はポットの部分ですねバージョン1から2に上げていて実際にYAMLファイルのバージョン2に上げています一方でプロダクション環境というのはすでにお客様に勉強し続けている環境ですのでいきなりバージョン2にするわけにはいかずその検証を待っていますのでバージョン1のままこのYAMLファイルでクバネティス上で動いているとそういった形になっておりますこちらがまさに我々が直面した課題でございましてステージング環境プロダクション環境それぞれに異なるYAMLを適用して運用していきたいそういったところをまず一つ課題としまして次の戦略に移らせていただきますでは続いてその課題をどのように乗り越えたのかというところについてお話をいたします先ほどの課題をもう一度まとめますと環境ごとに異なるYAMLを適用するためにどのようにすればよかったのかというところが課題でございましたここからは戦略12それぞれテンプレートファイルを分割する変数ファイルを分割すると2つの手法についてお話をさせていただきますではまずテンプレートファイルを分割する戦略についてお話しさせていただきますこちら先ほどお見せした図に似ているのですが違うところがございましてこのステージングブランチのファイルの中でテンプレートの下にステージングポット.yamlとプロダクションポット.yamlという2つのファイルこれが新しく用意してあります先ほどはポットのテンプレート1つだったのですがこれをステージング用プロダクション用それで2つに分割をしたとなっておりますではテンプレートを分ければそれでいいのかといいますとそういうわけにはいかなくてバリューズ.yaml変数ファイルの中にそれぞれこれはステージング環境用の変数ですこれはプロダクション用の環境の変数ですと塩部ステージング塩部プロダクションという形で式別詞を追加する必要がありますのでこちらを適用しますそしてヘルムのテンプレートの気泡を見ていきますとそうすることができますこちらをご覧いただいているのはステージングポットヤムルの実際の構成になってきますが赤字の部分ですねif文が書いてありましてif以降でその右の方にステージングという形でブランチの名前をここに記載をしますそうすることで先ほど変数ファイルバリューズ.yamlとはテンプレートファイルをかけ合わせるという変数ファイルをかけ合わせた塩部ステージングと書いた変数こちらについてはヤムルを生成することができます対しましてこの下側ですね塩部プロダクションと書いた変数こちらについてはかけ合わせる時にif文にはまりませんのでヤムルが生成されないそういった運用が可能ですここまで見ていきますとステージングプロダクションそれぞれにテンプレートを分けると非常に運用しやすくてここで少し話を変えまして実用上でまたありそうなユースケースですねについてご紹介いたしますこちら今画面に出していますがステージングポッドヤムルの先ほどif文で書いたところではなく下の方ですねリブネスプローブを追加した例えばこのような例を考えます実際にはバージョンアップに伴って新しい変数が追加されたりですとか追加される部分は異なるかと思いますがやはりポッドのテンプレートも一度使えばそれっきりというわけではなく実際に更新がどんどん入ってくる箇所かと思います今回はこのリブネスプローブをユースケースとして考えますでは続きましてプロダクションポッドドヤムルについてもお話しいたします実は先ほどステージング環境でリブネスプローブの追加ですねこれがもしかにテストが通ってうまくいったということであれば当然プロダクションポッドドヤムルの方についても変更が必要ですそしてそれをお客様に提供するそのような流れになってくるかと思いますここでもう一度ギットの観点から今までの内容をおさらいしますと左側のプロダクションブランチからテストがOKだったら右側のプロダクションブランチに情報が渡っていくそしてバージョンが1から2ステージングポッドヤムルとプロダクションポッドヤムルが再生変更されるそのような形になるかと思いますここで1つ確認しなくてはいけないのが最後のプロダクションポッドヤムルになります実はですね先ほどif文というお話をしましたがステージング環境でif文の条件をクリアして実際にヤムルが生成されてテストされるテンプレートファイルというのはステージングポッドドヤムルのみになっておりますこのプロダクションポッドヤムルについては実機でテストをしたことがないものを使うことになってしまいますこちら非常にご機ですとかそういったミスについてケアできていない形になりますので非常に注意が必要かと思いますですのでまとめますとテンプレートファイルというのはできれば統一していきたい同じものを使いたいというところを我々が考えましたまとめますと環境ごとに異なるヤムルをどのように適用していくかというところについてテンプレートファイルを分けて考えてみましたがそれをやってしまうとプロダクション環境でどうしも一発勝負の適用というのが入ってきますのでできれば避けたいというところが一旦結論でございますでは続きまして戦略に環境ごとにステージングブランチの絵を出させていただいたんですが先ほどはテンプレーツの下のポットドットヤムルこちらがステージングとプロダクションでそれぞれ分けていた図になっていましたが今回は1つだけ存在する最初の図に戻ったというような形になっておりますそこでValues.yamlつまり変数ファイルの中身を見ていきますとこのようになっておりまして先ほど識別詞を追加するというお話も一旦今回はなしでこちらも最初の状態に戻ったと考えます続きましてこちら色を塗ってあるんですがステージングブランチでではこのValues.yaml変数ファイルのどの部分を使うのかといいますと一番上のバージョン情報そしてそのすぐ下のステージング環境につながっているカメラの情報は名前ですとかIPアドレスですねそのような情報を使います一方でプロダクション環境では何を使うかと申しますと同じく一番上のバージョン情報とあとは名称もしくはIPアドレスについてはプロダクション環境だけで使う下の部分を使うそのような形になっておりますまとめますとステージングブランチプロダクションブランチでそれぞれ使う変数使わない変数はこのように立っておりますもう少し見ていきますとバージョン情報ですねこちらについてはブランチによらずどちらでも必要になってきます一方で実際のアプリケーションが使う名称ですとかIPアドレス情報ですねこのようなものは個々の環境でそれぞれ違ったものが必要になってきますここで少し話が変わるのですが我々はですねこの環境ごとに違うものをどのように実現するのかというところを考えたときにこの-fというファイル名を指定するオプションに着目をいたしましたこちら上の図がオプションなしそして下の図がオプションありでそれぞれヘルムのコマンドを実行した場合なんですがまず上のオプションなしの場合ですねこちらは実際今までお話したとおりですねバールズドってやる変数ファイルとあとはテンプレートに書かれたテンプレートをかけ合わせることで右側ですねやむるファイルが書かれます一方で下側ですねオプションをつけた場合例えばこの場合ですとフーバードットやむるというものを指定したとしますそうしますとバールズドットやむるテンプレートというのはもちろんありながらその一番上にですねフーバードットやむるそれをかけ合わせてやむるを生成するという形になっております実はここがポイントでございまして指定した一番上のフーバードットやむるは使いますそしてファイル名を指定するので変数ファイルが差し変わるのではなくバールズドットやむるはそのまま活用されますですので上の図ですと2つだけ参照していたところを下の図ですと3つを参照してかけ合わせたものをやむるファイルにしていくそういった仕様になっておりますここでですね我々が先ほどのヘルムのオプションに着目をして変数ファイルを分割した図を示しております一番上がバリューズドットやむるですねこちらはハイフォンFでどのようなオプションを指定しても使われる変数ですのでつまり共通する変数であるマージョン情報を配置しておりますそしてその下に新しく追記をしているのがステージングドットやむるとプロダクションドットやむるというそれぞれの環境ごとの変数ファイルになっておりましてプロダクションドットやむるについてはステージング環境で使う変数だけそしてプロダクションドットやむるについてはプロダクション環境で使う変数だけを記載したものになっておりますこちら一つポイントとなってきますのがステージングドットやむるプロダクションドットやむるどちらも変数目がアップスとなっておりますがこちらはそれぞれ違うファイルを指定しますので名前を衝突しても問題がないとそのような形で同じ変数目を宣言しているとなっておりますでは先ほどですね例でお見せしましたリブネスプローブを追加するつまりポットのテンプレートにも構成変更が入るそしてかつアプリのバージョンもバージョン1からバージョン2に上げるという例を考えますその場合に変更されるファイルというのが下からいきますとポットドットやむるの構成変更そしてすみません少し吹き出しの位置がバージョン1から2に上がるとそのような形になっておりますそしてではこの情報をですねどのようにステージング環境に適用していくのかについて表した図がこちらになっておりましてステージング環境ですねバージョンが上がった情報プラス右下の吹き出しですねハイフンFオプションのところでですねステージングドットやむるとステージング環境用の変数を指定していますそうすることでステージングドットやむるとセンプレートが駆け合わさったものがステージング環境に実際に適用されていくそのような形になっておりますここでですね次はプロダクション環境に行く前に一つですねセーフティー機構というところについてお話をさせていただきますと実はテストが完了したものについてステージングブランチからプロダクションブランチに移っていくのですがちらですねそのまま移してしまっては例えばプロダクションブランチのプロダクションドットやむるですねをステージングブランチで誤って消してしまった場合にですね上書きされてしまったりですとかそういったオペミスも考えられますのでそこはギッドアトリビュートの設定で除外をしているとそのような形をとっております最後にですねプロダクションブランチでどのように適用されるのかというかとお話しさせていただきますとバリズドットやむるそしてがバージョン1からバージョン2に上がると今度はプロダクションドットやむるを指定してヘルムのインストールをすることでプロダクション環境にデプロイすることができますここまでまたまとめますと戦略運Dですで環境ごとに変数ファイルを分割することでギッドオプスが実現できました最後にまとめますとオープンシフトを軸にマルチカメラマルチAIをやっていくに当たってクーバネティスだけでは足りない商用サービスかの課題をオープンシフトで解決しつつヘルムの変数ファイルを分割することで環境ごとの際に対応してきまいりました以上で私の話を終わりにしたいと思いますご清聴いただきましてありがとうございました