【ITニュース解説】Day 52: Undo Rolls Forward, and the Disk Already Mounted Is the One Not to Trust

この記事は、ITの現場でよく使われるコマンドが、その名前から受ける印象とは異なる挙動をすることがある点に焦点を当てている。特に、Kubernetesのデプロイ管理コマンドと、Microsoft Azureの仮想マシン作成コマンドの二つの事例を通じて、システムエンジニアを目指す初心者が知っておくべき重要な注意点を解説する。

まず、Kubernetesのデプロイ管理におけるkubectl rollout undoコマンドについて見ていこう。このコマンドは名前から「元に戻す」「巻き戻す」というイメージを持たれがちだが、実際には以前のバージョンに戻るための「新しいロールアウト」を開始する。アプリケーションにバグが見つかった際、このコマンドを使って以前の安定したバージョンに戻したいと考えるだろう。具体的には、Kubernetesの内部では、以前のバージョンのアプリケーションの定義（Podテンプレート）が保存されている。undoコマンドを実行すると、この古いPodテンプレートが現在のアプリケーション定義（Deployment）に適用される。Podテンプレートが変更されると、Kubernetesはそれを新しい変更とみなし、新しいバージョンの展開として扱うため、「巻き戻し」ではなく「過去のバージョンへのロールフォワード」と表現される。

この挙動には重要な注意点がある。一つ目は、変更されるのはPodテンプレートのみだということだ。もし、以前のバージョンに戻した後で、アプリケーションのスケール数（Podの数）を変更したり、デプロイ戦略（新しいバージョンへの切り替え方）を変更したりしていた場合、それらの変更はロールバックされずにそのまま残る。二つ目は、Kubernetesが保存する過去のバージョンの履歴には制限がある点だ。デフォルトでは過去10世代の履歴が保存されるが、この設定を変更すると、それ以上古いバージョンには戻せなくなる可能性がある。kubectl rollout historyコマンドで履歴を確認してからundoを実行する習慣をつけるのが良い。そして最も重要な点は、このundoコマンドが修正するのはKubernetesクラスタ内の実行中のアプリケーションの状態だけだということだ。バグの原因となる変更が定義ファイルに残ったままだと、次にファイルをクラスタに適用した際に、再度同じバグがデプロイされてしまう。クラスタの修正だけでなく、ソースコードや定義ファイル自体の修正も完了して初めて、本当のロールバックとなる。

次に、Azureで仮想マシン（VM）を作成するaz vm createコマンドについて解説する。このコマンドも、名前から想像される以上に多くの処理を実行する。単にVMを作成するだけでなく、VMのネットワーク接続に必要な仮想ネットワーク、サブネット、ファイアウォールルールを含むネットワークセキュリティグループ、パブリックIPアドレス、ネットワークインターフェース、そしてOSディスクとデータディスクを同時に作成する。これは、Azure CLIがVMを動かすために必要な周辺リソースを、デフォルト値を使って自動的に作成してくれるためだ。

便利な機能だが、VMを削除する際には注意が必要だ。az vm createコマンド一つでこれら多くのリソースが作成される一方で、VMを削除するだけでは、関連付けられたディスク、ネットワークインターフェース、パブリックIPアドレスなどがデフォルトでは削除されずに残ってしまうことがある。これらの残ったリソースは課金対象となり、不要なコスト発生の原因となる。このような問題を避けるために、Azureには「リソースグループ」という概念がある。Azureのすべてのリソースは、必ずいずれかのリソースグループに属している。ラボ環境などでは、VMとその関連リソースを一つのリソースグループにまとめ、そのグループを削除することで、すべてを一括でクリーンアップできる。

また、Azureのストレージディスクの命名規則には注意が必要だ。Azureポータルでは「Standard HDD」と表示されるものが、CLIでは「Standard_LRS」となる。LRSは「Locally Redundant Storage」の略で、単一のデータセンター内で3重にデータを複製して保存する冗長性レベルを示し、ディスクの種類そのものではない。このように、CLIとポータルで表現が異なる場合があるので、正確な指定のためにはドキュメントの確認が不可欠だ。

az vm createでVMを作成すると、要求していないディスクが一つ追加されることがある。これは「一時ディスク」と呼ばれるもので、VMのサイズに応じて容量が決まり、Linux VMでは通常/mntにマウントされた状態で提供される。この一時ディスクは自由に使えるように見えるが、Microsoftのドキュメントによると、VMのメンテナンスイベント、再デプロイ、停止などの際にデータが失われる可能性がある。通常の再起動では残ることもあるが、信頼性はない。そのため、「一時ディスクにデータを保存してはならない」というのが基本的なルールだ。これは、Amazon Web Services（AWS）における「インスタンスストア」という一時的なストレージとよく似た概念だ。重要なデータは、OSディスクや別途アタッチしたデータディスクなど、永続性のあるストレージに保存する必要がある。

データディスクは通常、生の（未フォーマットの）状態でVMにアタッチされる。これを使うには、パーティション作成、フォーマット、マウント、そして再起動後も自動的にマウントされるよう/etc/fstabにエントリを追加する必要がある。この際、ディスクのデバイスパス（例: /dev/sdc1）は再起動で変わる可能性があるため、ディスクのUUID（Universally Unique Identifier）を使って指定することが推奨されている。UUIDはディスクを一意に識別するため、デバイスパスが変わっても正しくディスクを識別してマウントできる。

az vm createコマンドでVMを作成する際、管理者ユーザー名を指定しない場合の挙動にも注意点がある。筆者はrootユーザーで実行するとデフォルトの管理者ユーザー名がrootとなり、これがAzureの予約名のためコマンドが失敗すると誤解していた。しかし、Azure CLIは現在のOSユーザー名が予約済みの場合、自動的にazureuserを設定する。筆者は結果的に--admin-username azureuserと明示的に指定したが、これは実行ユーザーによらず常にazureuserを作成する良い習慣だ。たとえ正しいコマンドでも、理由の誤解は訂正が重要である。

この記事を通してわかるのは、kubectl rollout undoやaz vm createといったコマンドの名前は、その機能の概要を示しているに過ぎず、実際の挙動はより複雑で、想像とは異なる場合があるということだ。システムエンジニアは、コマンドを名前だけで判断せず、詳細な仕様やドキュメントを確認する習慣が重要だ。ロールバック時のソースコード修正、リソース削除時の関連リソースクリーンアップなど、簡単な操作にも深い注意が必要である。