【ITニュース解説】Day 58: Grafana and a Managed Disk

現代のIT開発、特にDevOpsやクラウドの分野では、「システムが作成された」という状態と「システムが実際に動作し、利用できる状態になった」という状態の間に、見落とされがちなギャップが存在する。システムは「成功」と報告しても、利用できるまでにはさらなる確認が必要な場合が多い。本稿では、データ可視化ツールのGrafanaをKubernetesにデプロイするタスクと、Azure管理ディスクを仮想マシンにアタッチするタスクの二つを通じ、このギャップに対処し、真の「動作している」状態をどう確認するかを解説する。

まず一つ目のタスクは、GrafanaをKubernetesクラスターにデプロイし、外部からアクセスできるようにすることだ。Kubernetesは、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを自動化するシステムである。ここでは、Grafanaを動かすための「Deployment」という設定と、外部からアクセスするための「Service」という設定を使用する。Deploymentは、どのコンテナイメージ（Grafanaの最新版）を使って、いくつのレプリカ（インスタンス）を動かすか、どのポートを使うか、そしてメモリやCPUのリソースをどのくらい割り当てるか（requestsは最小限、limitsは最大許容）を定義する。

Serviceは、Deploymentで実行されているGrafanaのPod（Kubernetesにおける最小のデプロイ単位）に安定したネットワークアクセスを提供する。今回使用する「NodePort」タイプのServiceは、Kubernetesクラスター内の各ノード（サーバー）の特定のポート（例: 32000番）を開放し、そのポートへのアクセスをGrafanaコンテナ内部のポート（例: 3000番）に転送する。これにより、クラスター外部から任意のノードのIPアドレスと指定したNodePortを使ってGrafanaにアクセスできるようになる。DeploymentとServiceは、それぞれの設定に記述された「ラベル」（例:app: grafana）を通じて互いに関連付けられる。このラベルが一致することで、ServiceはどのPodにトラフィックを転送すべきかを認識するのだ。

これらの設定をYAML形式のファイルに記述し、kubectl apply -f [ファイル名]コマンドでKubernetesクラスターに適用する。その後、kubectl get deployments.appsやkubectl get svcコマンドで、DeploymentとServiceが正常に作成されたかを確認する。Deploymentのステータスが「READY 1/1」と表示されれば、コンテナ自体は起動したことを意味する。しかし、これはGrafanaアプリケーション自体が完全に起動し、ログインページが表示される準備ができたことを意味するわけではない。

この「作成された」と「動作している」のギャップを埋めるためには、「readiness probe」（稼働状況プローブ）というKubernetesの機能が非常に重要だ。readiness probeを設定することで、Kubernetesはコンテナ内のアプリケーションが本当にリクエストを受け付ける準備ができているかを定期的にチェックする。例えば、Grafanaの例では、ポート3000で/robots.txtにHTTPリクエストを送り、応答があれば準備完了と判断するような設定が考えられる。元の記事のDeploymentにはこのreadiness probeがなかったため、「1/1」表示後もGrafanaのログインページが表示されるまでにタイムラグが生じた。

さらに、公式ドキュメントではデプロイの際にいくつか重要な推奨事項を挙げている。一つは、Grafanaが必要とするリソース（メモリ、CPU）を適切に設定することだ。指定されたリソースが少なすぎると、アプリケーションが不安定になったり、メモリ不足で強制終了されたりする可能性がある。二つ目は、永続ストレージの確保だ。Grafanaはデフォルトで設定やユーザーデータなどをSQLiteデータベースとして/var/lib/grafanaに保存する。もしここに永続ボリュームをマウントしないと、Podが再起動されるたびにデータが失われてしまう。この問題は、Kubernetesの「PersistentVolumeClaim」機能を使って解決できる。また、本番環境ではコンテナイメージのタグに:latestを使うのは避けるべきだ。:latestタグは最新版を指すため、意図しないバージョンアップによる予期せぬ挙動を引き起こす可能性がある。特定バージョンのタグを指定することが推奨される。管理パスワードなども、直接YAMLファイルに書くのではなく、Kubernetesの「Secret」リソースを使って安全に管理すべきである。

二つ目のタスクは、Azureの仮想マシン（VM）に既存の管理ディスクをアタッチすることだ。Azure VMはクラウド上で動作する仮想サーバーであり、管理ディスクはVMに接続して使用する、データの保存領域を提供するストレージサービスである。このタスクでは、既存のdatacenter-diskというディスクをdatacenter-vmという既存のVMに接続する。

ディスクをアタッチする前に、いくつかの重要な確認事項がある。まず、VMとディスクが同じAzureリージョン（データセンターの地理的エリア）にある必要がある。また、もしVMやディスクが「ゾーン」を指定して作成されている場合、それらは同じアベイラビリティゾーンにある必要がある。ディスクがすでに他のVMにアタッチされていないか、また、高性能なPremium SSDなどの特定のディスクタイプが、対応するVMサイズでしか使えないといった互換性の問題がないかも確認する必要がある。これらの確認は、Azure CLIのaz vm showやaz disk showコマンドを使って行うことができる。

次に、VM自体が「初期化済み」であることの確認が重要だ。Azure CLIのaz vm wait --createdコマンドは、VMのプロビジョニング（Azure側でのリソースの準備）が完了したことだけを待つ。しかし、VM内部で動作する「Azure Linux Agent」が起動し、正常に機能している状態こそが、真の「初期化済み」といえる。このエージェントが準備完了 (Ready) になったかどうかは、az vm get-instance-viewコマンドで確認できる。エージェントが動いていなければ、後続のディスクのフォーマットやマウントなどの作業をVM内部から行うことができないからだ。

これらの事前確認が済んだら、az vm disk attachコマンドを使って実際にディスクをVMにアタッチする。このコマンドを実行しても、VMは通常通り稼働を続ける。Azureは、空いている論理ユニット番号（LUN）を自動的に割り当ててくれる。ディスクがアタッチされたことを確認するには、Azure側からaz vm showコマンドでVMのストレージプロファイルをチェックするだけでなく、VM内部からも確認する必要がある。az vm run-command invokeコマンドを使えば、SSH接続なしでVM内でシェルスクリプト（例えばlsblkコマンドでデバイス一覧を表示する）を実行し、ディスクが認識されていることを確認できる。ここで確認できるのは、ディスクが「接続された生の状態」であることだ。つまり、まだパーティションが切られておらず、ファイルシステムも作成されていないため、そのままではデータを保存できない。タスクによっては、さらにパーティション作成やファイルシステム作成、マウントといった手順が必要になる。

記事の中で、diskSizeGbプロパティを照会した際に、az disk showでは値が取得できたのにaz vm showではnullが返ってきたという問題が紹介されている。これは、Azure CLIが返すJSONオブジェクトのプロパティ名が大文字小文字を区別する「JMESPath」というクエリ言語を使う際に重要になるためだ。diskSizeGbとdiskSizeGBのように、わずかな違いでクエリが失敗し、期待する値ではなくnullが返されることがある。この場合、元のJSON出力を確認することで、正しいプロパティ名を見つけることができる。これは、クエリがnullを返した際には、リソースの問題ではなく、まずクエリの書き方を疑うべきだという教訓を示している。

Azure管理ディスクについても、公式ドキュメントが推奨するベストプラクティスがいくつかある。Linux VMでは、ディスクのデバイス名（例:/dev/sdc）はシステム再起動後などに一貫しない可能性があるため、データディスクを参照する際は、ファイルシステムUUIDやAzure Linux Agentが提供するLUNベースのパス（例:/dev/disk/azure/scsi1/lun0）を使用すべきだ。また、ディスクをアタッチする際に適切な「キャッシュ設定」（ReadOnly、Noneなど）を選択することが重要である。これは、ディスクの用途（読み取り専用、書き込み専用など）によってパフォーマンスに影響するため、最初の設定で決めるべきだ。後から変更すると、ディスクがデタッチ・再アタッチされることになる。最後に、ディスクをVMからデタッチする際は、VM内部でディスクをアンマウントし、/etc/fstabからエントリを削除することを忘れてはならない。そして、ディスクをデタッチしても、そのディスクはAzure上で削除されるわけではないため、課金は継続される。不要なディスクは明示的に削除する必要がある。

今回の学習を通して得られる最も重要な教訓は、「システムが作成された」という表面的な成功ステータスと、「システムが実際に意図した通りに機能している」という状態の間には明確な違いがある、ということだ。KubernetesのPodが「1/1」と表示されても、Grafanaのログインページが表示されるまでは、まだ完了とは言えない。Azure VMのプロビジョニングが成功しても、VM内部のエージェントが「Ready」と報告し、lsblkでディスクが認識されるまでは、ディスクの利用準備はできていない。開発や運用の現場では、単にリソースが「存在する」ことを確認するだけでなく、そのリソースが「適切に動作している」ことを検証する具体的な手順と仕組みを確立することが不可欠である。これにより、見かけ上の成功に惑わされず、安定した信頼性の高いシステムを構築できる。