【ITニュース解説】How Adding an Additional EBS Volume to Existing EC2 Almost Broke My Terraform AWS Workflow and Threatened Our Project Deadline

Terraformを使ったAWSのインフラ管理は、多くのシステムエンジニアにとって非常に便利な手法である。コードとしてインフラを定義し、変更履歴を管理し、一貫性のあるデプロイを可能にする「Infrastructure as Code (IaC)」の代表的なツールだからだ。しかし、時にこの強力なツールが、一見簡単な変更で予期せぬ大きな問題を引き起こし、プロジェクトの進行を妨げることがある。今回の話は、まさにその一例であり、システムエンジニアを目指す皆さんにとって、実務で遭遇しうる重要な教訓を含んでいる。

あるプロジェクトで、Terraformを用いて構築・運用されていたAWSのインフラで作業していた時のことだ。すでに稼働中のEC2インスタンスに、追加のEBSボリュームを取り付けるというシンプルなリクエストがあった。EBSボリュームは、EC2インスタンスにデータ保存領域を提供する仮想ディスクのことだ。簡単に思えたこの作業が、実は大きな「悪夢」の始まりだった。既存のEC2インスタンスに新しいEBSボリュームを追加するため、Terraformの設定ファイルにボリュームの定義を追加し、terraform planコマンドを実行したところ、Terraformは驚くべき計画を提示したのだ。それは、新しいボリュームを追加するだけでなく、既存のEC2インスタンス全体を一度破棄し、再構築するというものだった。

なぜこれがそんなに大きな問題だったのかを説明しよう。EC2インスタンスの再構築は、単にサーバーを立て直すだけではない、深刻な影響を伴う操作である。まず、プロジェクトの遅延が避けられなくなる。インスタンスの作成、OSの起動、必要なアプリケーションのインストール、そして各種設定の適用には時間がかかる。納期が迫った重要なプロジェクトであれば、この再構築にかかる時間はプロジェクトのデッドラインを直接脅かす。次に、データ損失のリスクも非常に高い。既存のボリュームに重要なデータが保存されている場合、不注意な操作や設定ミスがあれば、そのデータが失われる可能性がある。バックアップからの復元にも時間がかかり、データの恒久的な損失につながることもあり得る。さらに、インスタンス固有の構成管理も複雑になる。アプリケーションの設定、ネットワーク設定、セキュリティグループの関連付けなど、EC2インスタンスには多くの個別設定が施されていることが多い。インスタンスを再構築するということは、これらの設定をすべてやり直すか、事前に完璧な自動化ができていなければならないことを意味する。最後に、テストへの影響も大きい。再構築されたインスタンスでは、これまで実行してきたテスト環境が失われ、再構築後の環境で再度テストを実施し、全てが正常に動作することを確認しなければならない。これはテスト期間を延長させ、品質保証のプロセスにも影響を及ぼす。これらの理由から、EC2インスタンスの再構築は可能な限り避けたい操作であり、特にシンプルにボリュームを追加したいだけの状況では、あってはならない計画だった。

この問題の技術的な原因は、当時使用していたterraform-aws-modules/terraform-aws-ec2-instanceというTerraformモジュールが、EBSボリュームの設定変更をどのように扱っていたかにあった。通常、EBSボリュームはEC2インスタンスとは独立したリソースとして存在し、後から追加・削除できる。しかし、このモジュールでは、既にデプロイ済みのEC2インスタンスに対してEBSボリュームの設定（ebs_block_deviceブロック）を変更すると、それをインスタンス自体の根本的な変更と見なし、インスタンス全体を再作成する必要があると判断してしまったのだ。Terraformは、コードで定義された状態と現在のインフラの状態を比較し、不一致があればコード通りの状態にするために必要な操作を計画する。このケースでは、モジュール内部のロジックが、EBSボリュームの定義変更をEC2インスタンスのライフサイクルに深く関わる変更だと解釈してしまったため、安全を期してインスタンス全体の再構築を計画したと考えられる。

この予期せぬ挙動に直面し、解決策を求めて様々な試みを行った。Terraformでは、リソースをモジュール内で定義するだけでなく、独立したリソースとして管理することも可能だ。そこで、aws_ebs_volumeリソースでEBSボリュームを個別に作成し、aws_volume_attachmentリソースを使ってEC2インスタンスにアタッチする方法を試した。また、既存のEC2インスタンスやそのボリュームを手動でTerraformのステート（現在のインフラの状態を記録したファイル）にインポートし、Terraformに既存のリソースを認識させようともした。しかし、これらはどれも根本的な解決策にはならず、コードの複雑性を増したり、後の管理を困難にする可能性があった。 この過程で、GitHubのコミュニティで同じ問題に直面している人がいることを発見し、共有されていた回避策の一つも検討した。それは、Terraformのステートファイルを直接操作するというものだった。具体的には、Terraformのステートから既存のEC2インスタンスの情報を一時的に削除し、EBSボリュームを別途Terraformで作成・アタッチし、その後再度EC2インスタンスをステートにインポートし直すという手順だ。この方法は技術的には可能だが、手動でのステート操作は非常にリスクが高い。ステートファイルはTerraformがインフラを管理する上で最も重要な情報源であり、これを誤って操作すると、実際のインフラとTerraformの認識に不整合が生じ、意図しないリソースの削除や更新が起こりうる。特に複数の開発者が同じインフラを扱っているチーム環境では、このような手動操作は混乱とエラーの原因となりやすいため、この方法は採用しないと判断した。

最終的に、この問題に対する真の解決策は、TerraformのAWSプロバイダのバージョンアップによってもたらされた。AWSプロバイダは、TerraformがAWSのリソースを管理するためのプラグインのようなものだ。この問題の発生当時、AWSプロバイダのバージョンは5.8.0を使用していたが、調査を進める中で、バージョン6.0.0でこのEBSボリュームに関する問題が修正されていることが判明した。プロバイダの新しいバージョンでは、EBSボリュームの追加を、EC2インスタンス全体を再構築することなく、適切に既存インスタンスにアタッチするような動作に改善されていたのだ。この情報を得て、Terraformの設定ファイルを更新し、AWSプロバイダのバージョンを6.0.0以降に上げた。その後、再度terraform planコマンドを実行すると、今度はEC2インスタンスを再構築する計画は提示されず、新しいEBSボリュームを作成し、既存のインスタンスにアタッチするだけの、期待通りのシンプルな計画が表示された。この結果を確認し、自信を持ってterraform applyを実行したところ、問題なく新しいEBSボリュームが追加された。

この一連の経験から、システムエンジニアとしていくつかの重要な教訓を得ることができた。まず、ツールやプロバイダのアップデート情報を常に確認することの重要性だ。古いバージョンに潜む問題が、新しいバージョンで修正されているケースは少なくないため、定期的にリリースノートに目を通し、必要に応じて更新を検討することが、スムーズな運用につながる。次に、問題に直面した際には、様々な解決策や回避策を検討する必要があることだ。コミュニティから共有された手動でのステート操作は、一時的なデッドライン対応としては有効な選択肢になり得たかもしれないが、そのリスクとメリットを慎重に比較検討し、プロジェクトの状況に最適な方法を選ぶ判断力が求められる。そして、コミュニティの存在の大きさも改めて認識した。今回の問題も、GitHubのイシューを通じて多くのエンジニアが議論し、情報や回避策を共有していたからこそ、解決の糸口を見つけることができた。何よりも、terraform planコマンドを必ず実行することの価値を再認識した。このコマンドは、変更が実際に適用される前に、どのような操作が行われるかを詳細に確認できる機能であり、意図しない破壊的な変更を未然に防ぎ、大きなトラブルを回避できる。そして最後に、最もシンプルな解決策が最善であることが多いという原則だ。複雑な回避策を探すよりも、問題の根本原因を解消するプロバイダのアップデートを待つ、あるいは探すことが、結果として最も効率的で安全な方法となる場合がある。

もし今後、TerraformでAWSのEC2インスタンスやEBSボリュームを管理する中で、今回のような予期せぬインスタンス再構築の問題に遭遇したら、まずは使用しているAWSプロバイダのバージョンを確認することをおすすめする。バージョン6.0.0以降であれば、この問題は解決されているはずだ。インフラ管理ツールが、時にシンプルな作業を困難にすることはあるが、その課題を乗り越え、よりクリーンで効率的な解決策を見つけた時の達成感は、システムエンジニアとしての大きな喜びとなるだろう。この経験が、システムエンジニアを目指す皆さんの学習と実務の一助となれば幸いだ。