IaCがもたらすインフラ管理のパラダイムシフト ～IaCの概要～
クラウドネイティブNow

はじめに

近年、パブリッククラウド上でのシステム開発ではIaC（Infrastructure as Code）によるインフラ管理が主流となっています。IaCを実施するとインフラリソースのデプロイを自動化することが可能ですが、それだけに留まらずインフラの構成管理、CI/CD、インフラのモジュール化など様々なことが実現可能です。さらに、IaCはこれらの要素を起点として、イミュータブルインフラストラクチャ、GitOps、プラットフォームエンジニアリングなどのより発展的な上位概念へと包括されていきます。

IaCとは

IaC（Infrastructure as Code）とはインフラをコードとして実装し、デプロイを自動化する手法のことです。IaCではクラウドのマネジメントコンソール上でリソースを手動で作成する代わりに、コードで記述したものをテンプレートとして一括デプロイすることが出来ます。これにより、手動での設定や変更が排除され、インフラの設定の再現性や信頼性の向上が実現可能となります。また、コードで実装することによりバージョン管理やコードレビュー、テスト自動化など、ソフトウェア開発で一般的に用いられる手法をインフラ管理にも適用することが可能になります。

IaCツールの種類

IaCツールには様々なものが存在しますが、大きく以下のような三種類に大別されます。

1. インフラの状態をどのように達成するかを手続き的に記述するツール（例: Ansible）
2. 望む最終的な状態を宣言的に記述するツール（例: Terraform, AWS CloudFormation）
3. 汎用的なプログラミング言語を用いてコードを記述するツール（例: Pulumi, AWS Cloud Development Kit (AWS CDK)）

広義のIaCではシェルスクリプト、Dockerfile、Kubernetesのマニフェストファイル、Helmチャート等も含める場合もあります。ただし、近年のパブリッククラウド上での開発という文脈においては、上記のようなクラウドプロバイダの提供するリソースを作成するAPIコールを代替するものをIaCと呼ぶケースが多いです。

ソフトウェア化するインフラ

近年のパブリッククラウド上での開発では、サーバレスのサービスも注目されています。特に中～小規模のアプリケーション開発ではコンテナさえ使用せず、AWS LambdaやAzure FunctionsのようなFaaSをのみを使用したフルサーバレスのアーキテクチャが採用される場合もあります。FaaSはFunction as a Serviceという名前の通りアプリケーションの関数単位でプログラムを実行するので、従来のようなインフラのパフォーマンスチューニング等の設定は極めて矮小化されています。さらに、FaaSではアプリケーションのコード（関数）自体がサービスの設定値と見なされるので、アプリケーションのコードの変更とインフラのライフサイクルが一致することとなります。こうなると、アプリケーションとインフラの境はもはや存在しないと言っても過言ではありません。
上記のようなアプリケーションを扱う場合、汎用プログラミング言語でIaCのコードを記述するPulumiやAWS CDKが有用となります。フルサーバレスなアーキテクチャの場合、アプリケーションのコードとIaCのコードを同一のリポジトリ内で管理するケースもあります。この際、PulumiやAWS CDKを使用するとアプリケーションのフロントエンド/バックエンド～インフラで使用する言語を統一するといったことも実現可能となるため、開発時のコンテキストスイッチや認知負荷を下げることが可能です。加えて、AWS CDKではリポジトリ内に存在するLambdaのコードやDockerイメージなどをバンドルする機能も備わっているため、このようなサーバレスなアプリケーションでの開発に適していると言えます。

その他、PulumiやAWS CDKではプログラミング言語の恩恵を十分に享受することが可能です。
従来のIaCツールではコードを単純なJSONやYAML、TerraformのHCLに代表されるドメイン固有言語で記述していましたが、これらのツールではPythonやTypeScriptのような一般的なアプリケーション開発で使用されるプログラミング言語を使用可能なので、開発者にとっては学習コストも低く扱いやすいです。中でもTypeScriptのような静的型付け言語では変数の型を指定することが可能なので、パラメータに数値や文字列、オブジェクトなど多様な値が代入されるIaCの実装において効力を発揮します。例として、Terraformでは変数の型チェックはterraform planコマンド実行時に行われますが、TypeScriptの型補完を使えば不適切な設定値をIDE上で検出することが可能です。 また、PulumiやAWS CDKではインフラリソースをオブジェクト指向言語のクラスを利用して抽象化することが出来ます。従って、自組織で頻繁に使用するインフラの構成や付随するリソースを一つのクラスに集約すれば、開発者がインフラをソフトウェアのモジュールやライブラリとして扱うことが可能となります。Pulumi RegistryやAWS CDKのConstruct Hubでは、様々なユースケースで必要なインフラのリソースを抽象化したライブラリ群が配布されています。このようなプラットフォーム上では、インフラはNode.jsのnpmやPythonのpipのようなライブラリの一つとして配布されるようになります。こうすれば、インフラの細かいパフォーマンスチューニング等の知識がない開発者でも、既存のライブラリから開発に必要なリソースをデプロイ可能となります。

プラットフォームエンジニアリングでは開発者が出来るだけインフラのレイヤに関与しないように他のチームが実行基盤を構築するイメージですが、汎用プログラミング言語でIaCを実施する場合、開発者自身がアプリケーションのレイヤからインフラにアプローチすることが可能となります。どちらのアプローチが今後主流になるかは不明ですが、汎用プログラミング言語でのIaCの記述というのは大きな可能性を秘めています。

IaCは様々な可能性を秘めていますが、銀の弾丸ではありません。やみくもに実装しようとすると、かえって時間がかかり、手作業でリソースを作成する方が早いケースもあります。IaCを実施する際は開発工数、チーム編成、ツール選定、技術選定、開発・運用ルールなど様々な点を考慮する必要があります。自組織の成熟度に合わせた目標設定を行い、IaCを活用していくことが大切です。

「IaCがもたらすインフラ管理のパラダイムシフト」では、IaCの概要からIaCの導入によって引き起こされる開発手法の変容についてご紹介していきます。

• IaCがもたらすインフラ管理のパラダイムシフト～IaCの概要～
• IaCがもたらすインフラ管理のパラダイムシフト～CI/CD～
• IaCがもたらすインフラ管理のパラダイムシフト～イミュータブルインフラストラクチャ～
• IaCがもたらすインフラ管理のパラダイムシフト～プラットフォームエンジニアリング～

関連情報

当社が提供するDX実現の課題にお応えするハイブリットITサービスの詳細は下記ページをご覧ください。

• FUJITSU Hybrid IT Service