Zenn
👌

インフラコード (IaC) の設計課題と展望

2025/02/22に公開
AWS
Terraform
IaC
Cloud
infra
tech

近年、インフラをコードで管理する Infrastructure as Code (IaC) のアプローチが一般的となり、AWS をはじめとするクラウド環境でも Terraform などのツールを使った IaC が広く使われています。
しかし、IaC はあくまでも コード化 したインフラ管理であるため、その構造は物理的なクラウドリソース構成に寄りがちです。結果として、論理構造（アプリケーションや機能単位の意図）を見失いがちになるという問題がしばしば指摘されます。
本記事では、AWS の物理構造に強く依存した IaC 構成が抱える問題や、Terraform におけるモジュール管理の実情、そしてそこから生まれるトレーサビリティ低下の課題について解説します。

よくある IaC 構成の傾向

AWS の物理構造に強く依存したコード

AWS のインフラリソースは多岐にわたります。VPC, Subnet, EC2, ALB, RDS, S3, Route53 など、サービス単位で非常に豊富なリソースを扱うことになります。Terraform では、各リソースを単純に列挙していくと、自然と物理的なサービス単位のディレクトリ構成やファイル構成が生まれやすいです。

この結果、インフラ全体の構成が 「AWS サービス = IaC のモジュールまたはディレクトリ構成」 という形にまとまりやすくなります。これは、下位レイヤー（ネットワークやセキュリティ設定など）を担当するインフラエンジニアの視点では整理しやすい反面、アプリケーション視点での 「なぜこのリソースが必要なのか」 といった意図を読み取りにくくする要因にもなります。

環境間の構造の再利用と Terraform モジュール

多くの Web システムなどでは、開発環境 (dev), 試験環境 (staging), 本番環境 (production) などと、複数の環境 を用意するのが一般的です。これらの環境は多くの場合、同一の基本構成 を持つ一方、開発段階の差分やコスト最適化のためのスペックダウンなどの微調整が必要になります。
Terraform では、こういった複数環境における構成の再利用を可能にする仕組みとして module が提供されています。モジュールを適切に設計すれば、DRY (Don’t Repeat Yourself) を実現し、環境間の共通化をしやすくなるという利点があります。

サービス単位のモジュール分割が導く “散在” の問題

よく知られたモジュール分割として「サービスごとにモジュールを分割する」という方法があります。たとえば以下のように、VPC 用モジュール、EC2 用モジュール、RDS 用モジュール、S3 用モジュール … といった具合に分けて管理するイメージです。

modules/
  vpc/
  ec2/
  rds/
  s3/
  route53/
  ...

これはたとえば HashiCorp 社のスタイルガイド に見ることができます。

インフラエンジニアの視点から見ると、この分割は「どのリソースをどのモジュールに書くか」という判断が明快になるため、コードレビューや保守において管理しやすい面がありますが、実際にアプリケーションの新機能要件に応じてインフラを拡張する際には、複数のサービスモジュールにわたる設定変更が生じます。

たとえば新しい Web サーバが必要だとアプリケーションチームが要望を出した場合、以下のように多数のモジュールに手を入れる必要があるかもしれません。

  • ec2 モジュール：EC2 インスタンスの追加、Security Group の調整
  • route53 モジュール：新規サーバへのレコード追加
  • s3 モジュール：一時ファイルやログの保存用バケットに関する設定変更
  • rds モジュール：必要に応じて DB 接続先の追加やセキュリティルール変更
  • vpc モジュール：必要であれば Subnet 追加やルート設定の変更

このように、アプリケーション要件に基づく変更が多数の機能モジュールへ断片化してしまうケースがあるのです。

トレーサビリティの喪失

上記のような、サービス単位のモジュール分割は物理的なビューとしてはわかりやすいですが、「このリソースはいったい何の要件によって追加されたのか？」 がコードを追っているだけでは把握しづらくなります。結果として以下のようなデメリットが生まれます。

  1. 可読性の低下
    モジュール数が増えるほど、必要な変更箇所が散在し、コードベースを俯瞰しづらくなる。新規メンバーが参加した際や外部のチームと連携する際に、学習コストやレビューコストが高くなる。

  2. 運用の複雑化
    リソース間の依存関係が見えづらくなるため、変更の影響範囲を把握しづらい。結果として、本番リリース時のリスクを高める要因になる。

  3. 要件のトレーサビリティ欠如
    アプリケーション側の機能追加や変更が、物理的な AWS リソースの増減・設定変更といった形でどこまで反映されるかが可視化しづらい。いわゆる “コードの散在” により、意図がつかみにくくなる。

これは、システム開発全体で一般的に言われる「要件からのトレーサビリティが失われる」という状態と同義です。コードの記述量が増えるほど、各要素が「何のために」作られたリソースなのか、アプリケーションとどのように紐付いているのかが追いにくくなってしまいます。

ソフトウェア設計方法論と IaC

これまで指摘したように、現在のIaCの設計方法論には課題があります。

  • 物理側の外形的な特徴に基づく設計
  • 低い凝集度によるトレーサビリティ欠如
  • 可読性、変更容易性の低下

しかし一歩俯瞰して問題をとらえてみると、これらはソフトウェア設計論において過去に議論され、すでに大半が解決されている問題のようです。たとえば、オブジェクト指向が登場する以前の手続き型プログラミングでも「コードの再利用」「依存関係の明確化」「責務の分割」などの課題が同様に存在し、幾多の設計手法やパラダイムを模索する中で徐々に解決策が体系化されてきました。

ソフトウェア開発の分野では、ドメイン駆動設計 (DDD) やクリーンアーキテクチャ、マイクロサービスといった高度な設計・アーキテクチャパターンが生まれ、変化の激しい大規模システムにも耐えられる仕組みが整備されてきました。一方、IaC は比較的新しい領域であり、こうしたソフトウェアエンジニアリング的な知見や設計手法が 十分に体系化・普及していない と感じます。

たとえば Terraform の module 機能は、ソフトウェアの「ライブラリ」や「パッケージ」に相当するもので、再利用やコードの集約を可能にします。しかし、ソフトウェアエンジニアリングで言うところの「レイヤー分割」や「アーキテクチャの抽象化」「ドメインとインフラの切り離し」などの設計手法は、IaC の世界ではまだ一般的ではありません。そのため、モジュールがただ物理構成をそのまま反映するだけになり、結果として論理構成がコード上に表現されにくくなるのです。

論理設計と物理設計を分離するレイヤーの必要性

今後は、論理構成を表す設計レイヤー を追加し、物理設計との分割を意識した IaC が一般化していくと考えられます。すでに一部の先進的なチームでは、

  • インフラ要件（アプリケーションからの要求仕様）をまとめた「論理レイヤー」
  • 具体的な AWS リソースや設定を定義する「物理レイヤー」

という構造を実装し、Terraform モジュールを単なるサービス単位の集まりではなく、「機能モジュール」「基盤モジュール」「ユースケースごとの統合モジュール」など複数の抽象度で扱っている例があります。
しかしこれは、あくまで 高度な設計思想を持ったチームの自主的な実装 に依存しているのが現状で、ソフトウェア開発史における“言語レベルでのサポート”にはまだ及びません。

「できる」と「広く使われる」は別の問題

ソフトウェアの世界でも、オブジェクト指向が台頭する前から C 言語などで疑似的にオブジェクト指向を実現することは不可能ではありませんでした。しかし、それが大きく普及し、多様な開発現場で広く取り入れられるようになったのは、C++ や Java といった オブジェクト指向を明示的にサポートする言語 が登場してからのことです。

同様に、IaC においても「論理構成を追加で表現するレイヤー」を Terraform のモジュール機能などで 「やろうと思えば実現できる」 状態に留まっているうちは、そこまで普及しない可能性が高いでしょう。言語仕様やツールチェーン自体が 論理レイヤーの存在 を前提として設計・開発されることで、初めて多くのチームが導入しやすくなり、業界標準となっていくはずです。

今後への期待と展望

将来的には、既存の IaC ツールが より高度な抽象化機能 を標準で備え、物理構成と論理構成を自然に分割できる仕組みが広がることが期待されます。たとえば、次のような進化が考えられます。

  1. 論理モデルの宣言的記述
    「アプリケーションが必要とする機能」や「ユースケースごとのインフラ要件」を高レベルの宣言的な形で定義する。ツールが自動的に最適な AWS リソース構成へマッピングする。

  2. ドメイン駆動的な IaC
    いわゆる DDD の概念を取り入れ、アプリケーション要件（ドメインロジック）とインフラを繋ぐ「ドメインモデル」のようなものを IaC の中で管理する。変更やリファクタリングがアプリケーション意図に沿って行われる。

  3. 言語レベルでのサポート
    Terraform や Pulumi、AWS CDK のようなツールが、論理レイヤーを明示的に定義する文法やベストプラクティスを提供。ユーザはそのガイドラインに沿って実装するだけで、論理分割が自然に実現される。

このように、ソフトウェア工学で培われてきたノウハウとパラダイムが IaC の分野にも取り入れられることで、インフラコードのスケーラビリティやメンテナンス性は飛躍的に向上していくでしょう。

まとめ

IaC は「インフラをコードで表現する」という点ではソフトウェアに近いものの、まだ歴史が浅く、物理構成をそのままコードに落とし込むやり方が主流であるがゆえに、論理構成の可視化や要件とのトレーサビリティ確保に課題を抱えています。しかし、これらはソフトウェア開発が過去に直面し、部分的に解決してきた問題でもあります。

今後、論理レイヤーを明示的にサポートする IaC ツール が登場し、これまでのソフトウェアエンジニアリングの知見が IaC により深く取り入れられることで、アプリケーションとインフラがより整合的かつ高度に抽象化された構成管理が主流になることが期待されます。ソフトウェア開発の歴史を学びつつ、次世代の IaC の姿を先取りすることで、より持続可能で拡張性の高いインフラ運用が実現できるでしょう。

Discussion