今回の話はポエム寄りの話になります。
クラウドリソースの管理において、Infrastructure as Code（IaC）は今や欠かせない存在となっています。
しかし、IaCの導入や学習には見えない壁が存在します。
今回は、この壁についての持論について述べていきたいと思います。
4つの壁
IaCを導入・学習しようとする際、多くの人が「難しい」「よく分からない」と感じます。
しかし、その難しさの正体は実は複数の層に分かれていると私は考えています。
私は、これを「4つの壁」として捉えており、私が関係している組織ではしばしば同様の説明をしています。
これらの壁は、初めて触れる人には区別がつきにくく、そのため対処が難しくなっています。
では、具体例を交えながら、各壁について見ていきましょう。
ツールの壁
例えば、Terraformを使ってIaCを始めようとした場合、まず直面するのがこの「ツールの壁」です。
- HCL（HashiCorp Configuration Language）の文法
- Terraformの実行モデル（plan, apply, destroy）
- 状態管理（state）の概念
これらはTerraform固有の概念であり、クラウドやインフラの知識があっても、一朝一夕には習得できません。
しかし、この部分を学ぶだけであれば、それほど苦ではないでしょう。
クラウドプロバイダの壁
次に立ちはだかるのが「クラウドプロバイダの壁」です。
AWSを例にとると：
- 膨大なサービス群（EC2, S3, RDS, Lambda, etc.）
- IAMによる複雑な権限管理
- VPCを中心としたネットワーキング
これらの概念や設定の詳細は、AWSを利用する上で避けては通れません。
AWSやGoogle Cloud、Azureなど、各サービスごとに概念が似ているようで似ていなかったり、各リソースごとに全くもって統一感のないAPIやリソース定義、ポリシーなど多くの認識すべき項目があります。
IaCでは、これらをコード化するので理解しなければならないので、4つの壁の中でも大きな壁の1つとも言えます。
ツールとクラウドの統合の壁
TerraformでAWSリソースを管理しようとすると、新たな壁が現れます。
- AWS特有のリソース間依存関係をTerraformでどう表現するか
- 特定のAWSサービスに対するTerraformプロバイダの制約
- Terraformの実行モデルとAWSリソースの作成・更新フローの整合性
これらは、ToolとCloudの両方を理解していないと対処が難しい問題です。
いざ書こうとしても、Terraformでどう表現するのかが難しい点です。
ただし、1,2を理解できているなら、それほど苦ではないのですが、しばしば「クラウドプロパイダの壁」とこの壁は区別されないように思います。
組織のドメインの壁
最後に、見落とされがちなのが「組織のドメインの壁」です。
- 社内セキュリティポリシーとの整合性
- 既存インフラとの統合
- チーム間の責任分界点
技術的には正しくても、組織の文脈で適切でない実装は、現実的には採用できません。
1,2,3で何とか表現方法を理解しても、この壁でどう書くべきか悩ましくなってしまう傾向が見られます。
本当に難しいですね。
ともに壁越えといこうじゃないか
これらの壁を認識したうえで、壁を超えていきましょう。
ここでは、2つのアプローチを簡単に紹介します。
ツールの壁・ツールとクラウドの統合の壁
CDK（Cloud Development Kit）とTypeScriptの組み合わせは、これらの壁を効果的に克服する強力なアプローチです。
- プログラミング言語の活用: TypeScriptの型安全性と豊富なエコシステムを活用し、より柔軟で堅牢なインフラ定義が可能になります。
- 高レベルの抽象化: CDKは低レベルのクラウドリソース設定を抽象化し、開発者が意図を直接表現できるようにします。
- ツールとクラウドの統合: CDKはAWSのベストプラクティスを組み込んだConstructsを提供し、ツールとクラウドの統合の壁を低くします。
- コード再利用性の向上: TypeScriptの機能を活用し、共通のパターンやロジックを容易に再利用できます。
適切にCDK+TypeScriptを利用することで、強力な補完を利用して、これらの障壁を大幅に低減することが見込めます。
私は今のところTerraform派ではありますが、相談を受けた組織の技術スタックによってはCDK+TypeScriptをまず進めることが多いです。
クラウドプロパイダの壁
この壁が1番難しいと言え、中々近道がないのが現状です。
- 段階的学習: クラウドサービスを一度に全て学ぼうとせず、基本的なサービス（コンピューティング、ストレージ、ネットワーキング）から始め、徐々に組織で利用しているサービスへと拡張していきます。
- ハンズオン実践: 公式のチュートリアルやハンズオンラボを活用し、実際に手を動かしながらサービスの挙動を学びます。
- アーキテクチャパターンの理解: クラウドプロバイダが提供する参照アーキテクチャやベストプラクティスを学び、適切なサービスの組み合わせ方を理解します。
- コミュニティの活用: オンラインフォーラムやローカルのユーザーグループに参加し、他の実務者から学びます。多くの場合、実際の運用経験に基づいた貴重な情報を得ることができます。
- 継続的な学習: クラウドサービスは常に進化しています。定期的にクラウドプロバイダのアップデート情報をチェックし、新しい機能や改善点を学び続けることが重要です。
- 認定資格の取得: クラウドプロバイダの公式認定資格の取得を目指すことで、体系的な学習が可能になります。
このように近道といえるようなものは正直ありません。
これらをメンバーが実施しやすいように組織として対策としては以下がオススメです。
- サンドボックス環境を用意し、メンバーが検証や勉強に利用可能にする
- 利用しているサービスを可視化しておき、学ぶべき範囲を狭める
これらの環境が整っているだけでも十分学ぶきっかけを用意することができています。
まとめ
IaCの導入における「見えない壁」を理解し、それぞれに適切に対応することは、クラウドリソース管理の複雑性に効果的に対処する上で非常に重要です。
どのアプローチを選択するにしても、これらの壁を認識した上で、段階的かつ継続的に改善を進めていくことが成功の鍵となります。
今回の話は、クラウドリソースについて焦点を絞りましたが、AnsibleやChef、Kubernetesといったツールなどにも似たような話があります。
もし導入や学習につまづく場合は、どういった壁があるのかを可視化したり、詳しい人に相談してみるといいかもしれませんね。
