イベント
Cloud Operator Days Tokyo 2024のクロージングイベントが開催、OpenInfra Foundation、PFNなどが基調講演に登壇
2024年9月10日 06:15
クラウドインフラ運用技術者のための年次カンファレンスイベント「Cloud Operator Days Tokyo 2024（CODT2024）」の、基調講演を含むクロージングイベントが9月6日にオフラインイベントとして開催された。会場は、東京のお台場の「docomo R＆D OPEN LAB ODAIBA」。
CODT2024では、「運用者に光を！ ～AIの未来、運用者の現実～」のテーマの元、7月16日からオンラインで48のオンデマンドセッションを配信してきた。そして9月6日には、オフラインでクロージングイベントを開催し、オンラインでも配信された中から約半数のセッションのオフライン版も行われた。
クロージングイベントでは、午前中にオフライン版セッションを実施。午後からは、基調講演5本と、パネルディスカッションが行われた。また、オンラインで配信された中から優れたセッションを選考し表彰する「輝け！クラウドオペレーターアワード2024」授賞式も行われた。
OpenInfra Foundation：大きく変化するインフラに対応できるのはオープンソース
基調講演の1つとして、OpenInfra Foundation（旧OpenStack Foundation）のCOO、Mark Collier氏が、「WeAreOpenInfra：How Open Source Communities are Defining the next Generation of Infrastructure」と題して講演した。
まずはOpenInfra Foundationの紹介だ。インフラのオープンソースソフトウェア（OSS）を開発する非営利団体であり、OpenStackのほか、軽量仮想マシンを使ったコンテナ技術「Kata Containers」や、エッジクラウドの「StarlingX」、CIの「Zuul」など、多くのプロジェクトを抱える。
Collier氏は、多くの企業の参加とともに、開発者からユーザーまで11万人のコミュニティメンバーが世界中から集まっていることを紹介した。特にOpenStackについては、60万以上のコードの変更や、1万人弱のコード貢献者が集まり、世界で最もアクティブなOSSプロジェクトの1つだと語った。
Collier氏は、これまでになく大きく変化している世界の中で、インフラ技術関連の注目トレンドを4つ挙げた。
1つめは「Digital Sovereignty（デジタル主権）」。データがどの国にあるか、誰がアクセスできるか、どの法律が適用されるか、ということだ。この問題によって、フランスでは9つの大手銀行がOpenStackによるプライベートクラウドを採用し、世界で300以上のパブリッククラウド事業者がOpenStackを採用しているとCollier氏は紹介した。
2つめは「Licensing Changes（ライセンス変更）」。OSSの世界でいうと、HashiCorp社のライセンス変更によってTerraformからOpenTofuがフォークした件がある。そしてOpenInfra Foundationとしては、VMwareのライセンス変更問題だ。Collier氏は、OpenInfra Foundationのメンバー企業の80％以上で顧客がVMwareからOpenStackへの移行を検討し、60％以上ですでに移行したという数字を紹介した。
3つめは「Security Concerns（セキュリティ上の懸念）」。これについて、軽量仮想マシンを使うことで隔離性を高めたコンテナ技術「Kata Containers」を、Microsoft AzureやAWSなどが採用したことをCollier氏は紹介した。
4つめは「AI is redefining data center infrastructure（AIがデータセンターのインフラを再定義）」。96％の企業がAIのために計算能力の増強を考えているという調査結果や、英国で最速のAIスパコンがOpenStackで構築されていること、OpenStackの新機能としてVGPUのライブマイグレーションを開発中であることなどを紹介した。
これらをふまえてCollier氏は、これからLLMのような新種のアプリケーションのために、新種のハードウェアと新種のソフトウェアが必要になり、そうした挑戦に対応できる唯一の方法がオープンソースだとして講演を締めくくった。
サイバーエージェント：AIの分散学習基盤の構築と、ハマったところ
株式会社サイバーエージェントの青山健人氏は、「サイバーエージェントのLLM開発を支えるプライベート機械学習基盤の運用の取り組み」の題で基調講演に登壇。同社の基盤を整備するCIU（CyberAgent group Infrastructure Unit）で開発した、NVIDIA H100などのGPUを使う機械学習基盤「ML Platform」のうち、分散学習ジョブの実行基盤「Distributed」の構築運用の内幕を紹介した。
同社のML Platformは、CIUが開発する社内向け機械学習基盤のサービスの総称で、社内の機械学習やデータサイエンスのエンジニア向けに開発された。NVIDIA H100 GPUを80基、NVIDIA A100 GPUを100基以上用意している。具体的なサービスとしては、トレーニングの基盤や推論のための基盤などがあり、その1つが今回紹介されたDistributedだ。
機械学習モデルのパラメータ数が増加して1ノードのGPUではメモリ量が不足になることから、複数ノードの分散学習が必要になり、Distributedを開発したという。
Distributedは、ノード間並列分散学習ジョブの実行サービスで、H100 GPUのみを対象とする。ノード間のRDMA通信をサポートし、コンテナから使えるようにしている。
環境の払い出しには、Kubernetes上でMPI計算を実現するOSSの「MPI Operator」を利用。またリソースのキューイングやクォータにはOSSの「Kueue」を利用して、テナントごとに利用可能なフレーバーやリソース総量を制限できるようにしている。
このようにOSSを最大限に活用して開発し、検証のうえ、無事に社内にリリースしたと思いきや、H100 GPUノードすべてを利用した分散学習でトラブルが発生した。H100 GPUノードにDGX H100とHGX H100の2種類を用意しているうち、両者のノードが混在する環境でRDMA通信に失敗する減少が発生していたという。
調査すると、両者で見えるNICのデバイス数が異なり、スクリプトからのAdaptive Routingの設定が不整合になっていたことがわかった。そこでスクリプトを修正することで問題が解決したとのことだった。
この問題から得た学びとして、「動けばOKではなく、分散学習基盤としての性能検証が必要」であることを青山氏は述べた。複数ベンダー混在環境には予想外の落とし穴があり、それらは一つ一つ根気よく仮説検証作業するしかないこと、そしてトラブル解決の記録は文書として残しておくことを氏は語った。
PFN：LLMサーバーの難しいところや、一般のWebサーバーとの違うところ
株式会社Preferred Networks（PFN）の太田佳敬氏は、「自社開発した大規模言語モデルをどうプロダクションに乗せて運用していくか ～インフラ編～」の題で基調講演に登壇した。
PFNでは、AIチップから、計算基盤、生成AI基盤モデル、ソリューション・製品まで、AI技術を垂直統合して開発と応用を進めている。今回の話はそのうち、PFNが開発する純国産の生成AI基盤モデル「PLaMo」について、PLaMoを使って文章を生成するLLMサーバー（APIサーバー）のインフラの部分だ。
LLMのやることとは、起動時にモデルをメモリにロードし、入力を元に文章を1文字ずつ生成するものだ。やっていることはシンプルで、リクエスト処理中を除いて状態は持たないので、理論上は無限にスケールできるはず。しかし、そんなことはない、と太田氏は言う。
その理由は、まず「LLMはあまりにLargeすぎる」ので、ロードするだけでA100で7～10分ぐらいかかるという。そのため、リクエストのたびにロードしていては間に合わない。
さらに、LLMの100Bモデルのデプロイには200GBのGPUメモリが必要であり、するとH100やA100などのハイエンドGPUに選択肢が限られ、しかもそれらは生成にも優先的に使われるので推論で確保するのは厳しい。価格も高く、A100を1年間reservedで使った場合を試算すると、LLMを1つ動かすのに年間2700万円かかるという。
これらの理由から、LLMはリソース管理が難しく、「限られた台数のGPUをどれだけ使い倒せるかが勝負」だと太田氏は語った。そのことから、処理の高速化の重要性がとても高いとのことだった。
その生成の処理を見ると、入力を元に中間状態を作るprefillと、中間状態を元に回答を生成するdecodeの2つのステップに大きく分けられる。このうちprefillは、GPUがひたすら計算を実行する。
一方decodeでは、GPUの転送速度がボトルネックになる。1文字生成するためには、LLMのすべての重みを読み込んで計算し、それを使って次の文字を生成するのを繰り返す。その1文字ぶんの重みはGPUのキャッシュに収まらないため、分割して何度もロードを実行して計算することになる。そして、GPUは計算が高速なので、相対的にロードがボトルネックになるというわけだ。
この重みのデータは全員に共通なので、リクエストをまとめることで、1回のロードで複数のリクエストに使え、効率がよくなる。そこで、いかに同じプロセスにリクエストを束ねるかが重要になる。
これは、複数のプロセスを混ぜない一般的なWebアプリケーションのベストプラクティスと異なる。また一般的なWebアプリケーションでは処理を分散するためにロードバランシングをするが、LLMサーバーの場合は逆にできるだけ1台に集中させることになる。
さらには、LLMサーバーではリクエストごとに文字数が異なり、複数のリクエストをまとめても終わる時間が異なる。これを有効利用する、処理を分割し、全部の処理は終わっていないがいくつか終わって余裕のあるところに次の処理を詰め込む「Continuous Batching」という手法を太田氏は紹介した。
ユーザベース：障害時間短縮にインシデントコマンドシステムを採用、ポストモーテムの補佐に生成AIも
株式会社ユーザベースの安藤裕紀氏は、「10年モノの24x7サービスにおける障害対応と生成AIの活用」の題で基調講演に登壇。同社のNewsPicksサービスにおける障害対応について語った。
NewsPicks事業のプロダクトチームには約100名が在籍し、うち約70名がエンジニア。「全員プロダクト開発エンジニア」文化により、エンジニア全員が開発から運用までオーナーシップを持ち、デプロイを繰り返して、オンコールで障害対応を行うという。
ただし、DevOpsのFour Keysと呼ばれる4項目のうち、「デプロイの頻度」「変更のリードタイム」は進んでいたものの、「平均障害率」「平均修復時間」は普通（安藤氏の言葉では“凡俗”）だったという。その結果、毎日障害対応でもおかしくない状態になっていたと氏は語った。
そこで、「修復時間の短縮」と「変更障害率の低減」に着手したというのが今回の話だ。
修復時間の短縮のためには、障害対応プロセスを整備した。それまで、システムのアラートやビジネスサイドからの緊急呼び出しがあると、運用当番（オンコール担当）が暫定修復したり、担当チームにアサインしたり、必要があれば障害撲滅委員会（ポストモーテム）につなげたりしていたという。これにより、運用当番の障害対応スキルとオーナーシップがばらばらなことが問題になっていた。
そこで書籍「サイトリライアビリティワークブック」で解説されている「インシデントコマンドシステム」を参考にした。運用当番はインシデントコマンダーとして3Cs（調整、コミュニケーション、コントロール）に集中する。つまり、自分では手は動かさずアサインや関係者を巻き込むことに集中する。
障害対応が始まったら、運用当番がSlackの障害チャンネルにスレッドを作り、バーチャルオフィスGather上の障害対応スペースに関係者を集める。そしてSlackのチャンネルに関係者の対応状況を常に共有する。必要があれば、ビジネス担当者の連絡や、ポストモーテムの招集も行う。なお、インシデントコマンダーとしての動き方については、ドキュメントも用意した。
続いて、変更障害率の低減のための、ポストモーテムによる再発防止だ。当初、インシデントコマンダーの導入によってポストモーテムの活性化を期待したが、インシデントコマンダーが大変などの理由により進まなかった。
そこで、インシデントコマンダーの経験による技を再現するために、生成AIを補佐役にできるようにした。SlackにChatGPTのボットが用意されており、スレッドに流れる障害など情報から状況を要約することで、ポストモーテムに記録する内容を生成できるという。現在のところ、要約の精度は改善の余地があるが、プロンプトの改善などがなされていることも安藤氏は紹介した。
Splunk：OpenTelemetryや生成AIに対応した「Splunk Observability」
Splunk Services Japan合同会社の中上健太朗氏は、「クラウド時代のシステム運用再考：オブザーバビリティに取り組んでみよう」の題で基調講演に登壇した。
中上氏は、ハイブリッドクラウド運用は、監視運用対象が増加し、従来の運用との両立や、ツールの増加、障害シナリオの増加など、さまざまな複雑化により難しくなっていると述べた。そして、本来あるべき、スマートなシステム運用や、高いシステム信頼性の維持、クラウドシフトの促進、といったサイクルを実現するために、オブザーバビリティが必要になると語った。
また、オブザーバビリティのためのテレメトリー取得の業界標準としてOpenTelemetryを紹介し、さまざまなオブザーバビリティのバックエンドがOpenTelemetryに対応していると説明した。
そうしたOpenTelemetryに準拠したオブザーバビリティプラットフォームとして中上氏はSplunkの「Splunk Observability」を紹介した。またその中で、自然言語による質問で問題を検出できる「Splunk AI Assistant in Observability Cloud」を紹介した。
優れたセッションを表彰する「輝け！クラウドオペレーターアワード2024」発表
「輝け！クラウドオペレーターアワード2023」授賞式では、審査委員会が選んだ「最優秀オペレーター賞」「審査員特別賞（変革編）」「審査員特別賞（挑戦編）」と、実行委員会が選んだ「実行委員会特別賞」、視聴者の人気（再生数）から選んだ「オーディエンス賞」、若手発表者を表彰する「ヤングオペレーターアワード」が発表された。
なお、審査委員会に筆者も参加していることをお断りしておく。
最優秀オペレーター賞
最優秀オペレーター賞には、日鉄ソリューションズ株式会社の田村大樹氏による「とある金融機関システムにて、カーネル初心者がLinuxカーネルコードと格闘しながらeBPFでオブザーバビリティを高めた話」が選ばれた。
金融機関のシステムにおいて、OSのスケジューラーでレイテンシーが発生している様子を本番環境で観測するために、Linuxカーネル内でプログラムを動かす仕組みである「eBPF」ベースの既存の計測ツールを元に、そのツール自身やeBPF、Linuxカーネルの中を勉強しながら改造して問題を解決した話だ。
選評では、技術の掘り下げと、多くのエンジニアに“刺さる”一般性を両立しており、またeBPFという注目される技術を扱っていることから、審査委員会にて満場一致で最優秀賞に選出したと語られた。
受賞コメントとして田村氏は、初めてセッションに応募し、eBPFというテーマが誰に“刺さる”か不安だったが、ふたを開けたら受賞していたと喜びを表し、「今後も新しい技術を学んで発表するのをやっていきたい」と語った。
審査員特別賞（挑戦編）
審査員特別賞（挑戦編）には、ダイキン工業株式会社の角田潤也氏による「Deep Dive CloudFormation Guard ～社内ルール準拠のAWS自動チェック～」が選ばれた。
AWS上のシステムが社内ルールに準拠しているかどうかを早期に自動チェックするために、CloudFormation Guardのカスタム設定を作り込んだ話だ。
選評では、CloudFormation Guardの設定について、ドキュメント化されていない部分までマニアックに掘り下げて説明していた点が、「挑戦」にふさわしいと語られた。
受賞コメントとして角田氏は、インターネット上を探してみても、実運用で使いこんでいる記事がなかったので、自分で調べて運用している知見を紹介したと苦労を語り、これによってCloudFormation Guardが広まるとうれしいと語った。
審査員特別賞（変革編）
審査員特別賞（変革編）には、株式会社ジェーシービーの平松淳也氏による「二桁を超えるクレジット関連サービスが稼働中のGKEにおいて、年数回のアップグレードを習慣化した手法の紹介」が選ばれた。
金融会社であるJCBの社内コンテナ基盤の開発運用において、GKEのKubernetesのアップグレードに追従してビッグバンリリースを避けるために、自動化を進めた話だ。
選評では、技術的な面だけでなく、当初から組織面や、自動化に対する心理的側面も含めて自動化を推進し、最終的にアップグレードの自動化に至った「変革」の姿勢が評価されたと語られた。
受賞コメントとして平松氏は、今回のCODT2024ではテーマにAIOpsが掲げられていたことに触れ、次回はAIなども挑戦した話も紹介できればと思っていると語った。
実行委員会特別賞
実行委員会特別賞には、ユニアデックス株式会社の藤田勝貫氏による「GAIOps：生成AI活用でIT運用改善～より良く活用するための７つのポイント～」が選ばれた。
社内での生成AI活用のためのシステム運用について、適用業務の選定から、モデル選定、社内データの活用方法、機密データの活用方法、検索手法の選定、いつ始めるかの7項目にもとづいて検討した内容が語られた。
選評としては、CODT2024の「運用者に光を！ ～AIの未来、運用者の現実～」というテーマの元、AIOpsの検討ポイントや適用を、しくじりも含めて語っていた点から、実行委員がすべてのビデオを見た中で高い得票を得たことが語られた。
受賞コメントとして藤田氏は、今回参加し、ほかの発表者のセッションも1本15分でいろいろ聴けたのがよかったとして、また来年も検討したいと語った。
オーディエンス賞
オーディエンス賞には、株式会社野村総合研究所の木村誠明氏と浜崎佑樹氏による「システム運用における生成AIの活用について」が選ばれた。
システム運用で生成AIを活用するにあたり、歴史や領域、手法を紹介したうえで、検証した結果を紹介するセッションだ。なお、検証結果などはオフラインイベントのみで説明された。
選評では、生成AIが有用であるとはわかっているものの、実オペレーションに組み込むには課題があり、それを検証した内容がAIOpsの発展に寄与するものだと語られた。
受賞コメントとしては、実践編も組み込みたかったが15分という枠のため断念したことなどが語られた。
ヤングオペレーター賞
ヤングオペレーター賞には、株式会社ぐるなびの江島礼音氏による「モニタリング品質向上の取り組み」、Airitech株式会社の久保田想也氏による「オブザーバビリティを2つの切り口から実践してみた～トラブルシューティング＆インフラコスト最適化～」、AXLBIT株式会社の磯田将太氏による「性能見える化で明るい未来を」が選ばれた。
受賞コメントとして、磯田氏は「今回はリアルに泥臭い部分も発表したので、まだ見ていない人は見てほしい」と、久保田氏は「これからもオブザーバビリティでお客さまに貢献できるようにがんばりたい」と、江島氏は「ヤングオペレーター賞受賞ということで、会社に戻ってこれからも若さで仕事をしていきたい」と語った。
組織、技術、AIについて、CTOパネル
CTOの仕事についてのパネルディスカッション「CTOパネル」も開かれた。登壇者は、株式会社ぐるなびのCTOの岩本俊明氏と、株式会社LIFULLのCTOの長沢翼氏。司会進行は、CODT2024実行委員長である、AXLBIT株式会社の代表取締役社長の長谷川章博氏。また、参加者からはチャットでリアルタイムの質問が投げられた。
最初のテーマは「エンジニア部門の組織体制を教えてください」。これについて、ぐるなびでは現在、1つのプロダクト部門の中にエンジニアやマーケティングやデータなどを集めた組織体制になっている。
一方のLIFULLでは、事業部単位の組織分けから、職能単位の組織分けを経て、現在は再び事業部単位の組織分けになっているという。
これについては岩本氏も長沢氏も、どちらの分け方も長所と短所があり、組織や事業のフェーズによって繰り返すことになるという意見が出た。
次のテーマは「新たに採用や取り組みを始めた技術で過去失敗したケースを教えてください」。これについても二人とも、「すべて成功な気もするし、すべて失敗な気もする」として、思ったほど大失敗はないと思うと答えた。
関連した「CTO就任時から変わった技術、変わらない技術を教えてください」のテーマについては、岩本氏は言語やプラットフォームを変えていくのをずっとやってきたこと、CTOになったときにエンジニアがチャレンジできる環境を作っていきたいと思ったことを語った。
また長沢氏は、最初にエンジニアのフィロソフィーとして「エンジニアとして経営をリードする」という言葉を作ったと紹介した。エンジニアが経営をわかるようにしよう、というのではなく、エンジニアだからわかることを各自で発信していくことが経営をリードすることにつながるという考えだという。
その次のテーマは、「AIによってエンジニア職のどこが変わる、変わらないと考えますか？」。これについては二人とも、大きく変わると思うと答えた。岩本氏は、資料づくりやコードレビュー、テストコード作成などが楽になり、1人のエンジニアが2人分になると語った。中でも、古いコードを読み解きリファクタリングするのに威力を発揮するだろうと述べた。
長沢氏は、エンジニアはコードを書いたり資料を作成したりするというより問題解決するのが仕事であり、そこは変わらないと思うと答えた。そして、生成AIがコードを書くようになれば、本質を解決する能力や、それを生成AIに指示する力が大事になるだろうと語った。
最後に長谷川氏は、これからCTOを目指す人へのアドバイスを2人に求めた。岩本氏は、自分にとって一番面白いことがCTOなのであれば、ぜひ目指していただければと思うと答えた。
長沢氏は、計画的偶発性理論を引きあいに出しながら「私もCTOを目指してCTOになったわけではない」として、コードの1行から、クラス、システム構成、アーキテクチャ、などとどんどん見る範囲を大きくしていったら、事業の問題が課題として見えてCTOになっていたと答え、面白いと思えればできるようになるんじゃないかと語った。