【ITニュース解説】📊 Adding Observability to Gemma 2B on Kubernetes with Prometheus & Grafana

この解説では、Gemma 2BというAIモデルをKubernetesというシステム上で動かす際、その動作状況を詳細に監視する方法について説明する。具体的には、PrometheusとGrafanaというツールを使って監視システムを構築したが、当初は期待する情報が得られず、どのようにして問題を解決したか、そしてそこから何を学んだかという一連の流れをシステムエンジニアを目指す初心者にもわかるように解説する。

まず、Gemma 2BはOllamaというプラットフォームを使ってKubernetes上にデプロイされた。Kubernetesは、コンテナ化されたアプリケーションを管理・運用するためのシステムで、Ollamaはその上でAIモデルを動かすための便利なツールである。そして、Prometheusはシステムから様々なデータを収集し、Grafanaはその収集されたデータをグラフなどで可視化するツールとして使われる。これらを使って、Gemma 2Bの動きを監視し、その性能や安定性を把握しようとしたのが始まりだった。

しかし、実際にPrometheusとGrafanaを設定して監視を始めると、画面に表示されたのはCPUの使用率、メモリの使用量、コンテナの再起動回数といった、ごく基本的な情報ばかりだった。これらは、Gemma 2Bを動かしている「コンテナ」（アプリケーションを隔離された環境で実行するための仮想的な箱）が無事に動いているかどうかは教えてくれるが、AIモデルそのものが「遅延なく処理できているか」「どれくらいの量の仕事をしているか」といった肝心な情報は全く分からなかった。例えば、「1回の推論（AIによる計算）でどれくらいのトークン（単語や文字の単位）を処理したか」「推論にかかる時間はどれくらいか」「全部で何回推論が処理されたか」といったデータは全く見えなかった。これでは、AIモデルの性能が上がっているのか、どこかでボトルネックが起きているのかを判断することができない。

なぜこのような問題が起きたのかを詳しく調査した。PrometheusがOllamaのコンテナからデータを収集しているか、Grafanaがそのデータを使ってダッシュボード（グラフの表示画面）を表示できているかは確認済みだった。問題は、Ollama自体が「モデルレベルのメトリクス」（AIモデル固有の動作情報）を公開していなかったことにあると判明した。Ollamaはデフォルトでは、AIモデルを使って推論を行うためのAPI（アプリケーションが外部と通信するための窓口）は提供するが、その内部の動作状況を示すデータを外部に提供する機能は持っていなかったのだ。つまり、PrometheusはOllamaのコンテナからデータを「スクレイピング」（収集）しようとしていたが、Ollamaは「有用なデータ」を何も提供していなかったため、結果として基本的なコンテナの健全性情報しか得られなかったのである。

この問題を解決するために見つけ出したのが、「Ollama Exporter」というツールだった。このOllama Exporterは、「サイドカーコンテナ」としてOllamaと同じKubernetesのPod（関連する複数のコンテナをひとまとめにした最小のデプロイ単位）の中で動かす。サイドカーコンテナとは、メインとなるコンテナ（この場合はOllama）を補助する目的で、同じPod内で一緒に動くコンテナのことである。Ollama Exporterは、OllamaのAPIと通信することで、Ollamaが内部で持っているモデルレベルの情報を取得し、それをPrometheusが収集できる形式（/metricsという特定のアドレスで）で公開するという役割を担う。Ollamaが直接公開しない情報を、Ollama ExporterがPrometheusが収集可能な形式で外部に提供する機能を持つということだ。

具体的な設定方法としては、OllamaをKubernetesにデプロイするための設定ファイルに、Ollama Exporterのコンテナを追加する部分を記述した。この記述では、Ollama Exporterが使うイメージ（ソフトウェアの元となるパッケージ）を指定し、Ollama Exporterが外部にメトリクスを公開するためのポート番号（11435）を設定する。また、Ollama ExporterがOllama本体と通信できるように、Ollamaが動作しているアドレス（http://localhost:11434）を環境変数として渡した。そして、Prometheusの設定ファイルには、新しくOllama Exporterからデータを収集するためのジョブを追加した。これにより、PrometheusはOllamaサービスのアドレスとOllama Exporterがメトリクスを公開しているポート番号（11435）を指定して、モデルレベルのデータを収集できるようになった。

Ollama Exporterを導入した結果、Grafanaのダッシュボードには、これまで見えなかった重要な情報が鮮やかに表示されるようになった。具体的には、「ollama_requests_total」（推論リクエストの総数）、「ollama_latency_seconds」（1回の推論にかかる遅延時間）、「ollama_tokens_processed」（1回の推論で処理されたトークン数）、「ollama_model_load_time」（Gemma 2Bモデルの読み込みにかかった時間）といったメトリクスである。これにより、単なるコンテナの稼働状況だけでなく、Gemma 2Bモデルが実際にどのように動作し、どれくらいのパフォーマンスを出しているかを明確に把握できるようになった。モデルの動作状況を詳細に確認できるようになった瞬間だった。

この一連の経験から、いくつかの重要な教訓を得た。まず、Kubernetesが提供する基本的なメトリクスだけでは、AIモデルのような複雑なアプリケーションの深い部分の動作状況を把握するには不十分であり、Ollama Exporterのような専用のツールやサイドカーが必要になるということ。次に、Prometheusは、どこからどのようなデータを収集するのかを具体的に指示しない限り、自動的に必要な情報を取ってくるわけではないという事実。そして、詳細なモデルメトリクスを得ることは、単に問題を発見するだけでなく、Gemma 2BのようなAIモデルに割り当てるCPUやメモリといったリソースを適切に調整するためにも非常に役立つということを学んだ。

今後は、このモデルレベルの監視システムをさらに発展させていく計画である。例えば、推論の遅延が急激に増加したり、トークンの処理にエラーが発生したりした場合に自動的に通知するアラートを設定したり、収集したメトリクスを長期間保存するためのLokiやThanosといったストレージシステムに連携させたりすることを考えている。また、Gemma 3、LLaMA 3、Phi-3といった他のAIモデルを導入し、それらの推論遅延を比較することで、各モデルの特性を評価する基盤としても活用していく予定である。この取り組みは、AIモデルをより効率的かつ安定的に運用していくための重要なステップとなる。