K8s
読み: ケーエイツ
K8sとはAI基盤のコンテナ管理
かんたんに言うと
巨大な物流倉庫の司令塔である。無数の荷物であるコンテナをどのトラックに積むか、渋滞時にどう迂回させるかを瞬時に判断し、システム全体の崩壊を防ぐ役割を担う。
Docker単体では足りないコンテナ群の統合管理をK8sが担う理由
Googleが社内システムBorgの経験を元に開発しCNCFに寄贈したK8sは、今やコンテナオーケストレーションのデファクトスタンダードである。Docker単体ではコンテナの起動や停止しかできないが、K8sは複数サーバーにまたがるコンテナ群を統合管理する。
Podという最小単位でコンテナを包み、Nodeと呼ばれる物理サーバーや仮想マシンに配置する。
トラフィックが急増すればPodを増やし、Nodeがダウンすれば別のNodeでPodを再起動する。
この自己修復機能がなければ、深夜のアラート対応でエンジニアは疲弊し切ってしまう。ただ、その内部構造は複雑を極める。どこまで自前で制御すべきか、常に悩ましい。
AI開発におけるK8sの実運用と代表的ツール
機械学習のワークロードはリソースの消費が激しい。学習フェーズではGPUを占有し、推論フェーズではリクエスト数に応じてリソースを増減させる必要がある。
ここでKubeflowの出番である。K8s上で機械学習パイプラインを構築し、モデルの学習からデプロイまでを一元管理する。
自前でK8sクラスタを組むのは狂気の沙汰である。Amazon EKSやGoogle Kubernetes Engineといったマネージドサービスを使うのが現実的な選択になる。
それでも、バージョンアップのたびにAPIが非推奨になる恐怖とは無縁になれない。クラウドベンダーの仕様変更に追従するだけでも、現場の体力は削られていく。
インフラ運用の恩恵と現場を襲う技術的ハードル
K8sはマイクロサービスアーキテクチャと相性が良い。サービスごとに独立してデプロイできるため、システム全体の可用性は確実に上がる。
だが、SREチームの負担は跳ね上がる。ネットワークポリシーの設定ミス一つで、クラスタ全体が通信不能に陥る。
ベンダーロックインを避けるためにK8sを選んだはずが、結局は特定のクラウドプロバイダーの独自機能に依存してしまうケースは後を絶たない。
本当にそこまでの可用性が必要なのか。
システムを止めないための仕組みが、逆にシステムを複雑化させ障害の温床になる。このジレンマに対する明確な答えはなく、プロジェクトごとに判断が分かれるところである。
自社のAIプロジェクトにK8sを導入すべきかの判断基準
製造業の不良品検知ラインや物流の配送ルート最適化など、リアルタイム性と高可用性が求められる現場ではK8sの恩恵は大きい。
しかし、社内向けのチャットボット程度ならCloud RunやAWS App Runnerで事足りる。
流行りだからという理由でK8sに手を出すと、運用コストがインフラコストを上回る悲惨な結末を迎える。
自社の開発体制にK8sを運用できるエンジニアがいるのか。いなければマネージドサービスを使っても破綻する。
技術の選定は常にトレードオフである。身の丈に合わないインフラは、プロジェクトそのものを食いつぶす。
当社の見解
当社は機密情報のマスキング処理を全てローカルAIで行っている。これにより機密情報を外部に送信せずにAI処理できるようになった。だが、AIが嘘をつくハルシネーションの問題は依然としてある。確認していないのに「確認しました」と言う。当社はこの前提で運用を設計している。事実と推測の強制分離、ファクトチェック機能、3つのAIと人間の同士の三重検証を行っている。どこまでいっても、AIは完璧ではない。理論上100%安全設計をしていても、AIも人間も想定しないことは起こるものだ。その万が一に備えておくことが、AIを使う上では前提になっている。だろうではなく、かもしれない運用がAIを使う上での安全基盤となっている。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。