サービス開発部のくればやしです。
AWSの構築と運用にあたっては、IaCツールによるインフラのコード化することが多いと思います。
ツールの選定にあたっては、AWS SAM, CDK, Terraform, Serverless Frameworkあたりが有力な候補になってくると思います。
これらのツールの違いについては、テンプレートの書き方やコマンド体系に焦点が当たることが多いと思いますが、本記事ではそれらよりさらに基本にあたる仕組みの違いについて焦点を当てて解説します。
基本的な仕組みの違い
基本的な仕組みの最も大きな違いは、TerraformはAPIによる操作をベースとしていますが、Terraform以外のツールはCloudFormationをベースとしています。*1
つまり、Terraformでは記述されたテンプレートをデプロイするとき、AWSのAPIを実行してリソースを構築します。一方、それ以外のツールでは、デプロイを実行すると一度CloudFormationのテンプレートに変換された後、CloudFormationのスタックが作成されます。
これらの違いが運用方法やコード化の際の制約になることがありますので、ここをまず意識しておくことが必要です。
状態の管理方法の違い
上記の違いは、状態の管理の方法に違いにつながります。
状態とは
ここでいう「状態」とは主に、テンプレートで記載している論理的なリソースと、実際にデプロイされた物理的なリソースの紐づけを刺します。例えば、以下のようなCloudFormationテンプレートでもS3バケットのデプロイは行われますが、バケット名等が指定されていないので、デプロイしたリソースがどのバケットなのか（あるいはデプロイされているのかいないのか）このテンプレートからは判別できません。
MyS3Bucket: Type: AWS::S3::Bucket
その時に論理的なIDと物理的なIDの紐づけ（状態）をどこかが管理する必要があります。例えば、CloudFormationのスタックを覗くと、それらがスタック内で管理されていることが分かります。
状態の管理方法の違い
CloudFormationをベースとしているツールは、コード化している記述と実リソースの紐づけとの管理をCloudFormationのスタックが行います。 他方、Terraformは状態をTerraform自身で管理する必要があるため、それ用の tfstate というファイルで管理することとなります。
IaCにおいて、必ずしもすべてのリソースをコード化してからデプロイできるとは限りません。 多くの現場では、手動でリソースを変更した後でコードに反映したり、コード化する前から存在していた既存のリソースを後からコードに反映したりといった運用が発生するでしょう。
そうした場合に、実リソースをどのように後からコードに組み込み、状態を管理するかは事前に整理しておく必要があるでしょう。
CloudFormationをベースとするツール（SAM, CDK, Serverless Framework）の違い
上述の通り、TerraformはAPIをベースとしたツールですが、その他の3つはCloudFormationをベースとしています。
後者の3つのツールの違いですが、テンプレートの記載方法等はもちろん違いますが、CloudFormationとの関係性という視点で整理すると分かりやすいため、以降でその観点で違いをみていきます。
CloudFormation だけでは運用が難しい理由
その前にまず、CloudFormationだけでは運用が難しい理由を確認しておきます。
CloudFormationはリソースを一つ一つ定義していくため、細かい部分まで管理できるものの、すべての設定を記述するには冗長すぎるという欠点があります。また、例えばAWS Lambda関数のリソースでは、コードの資材の格納場所をAmazon S3で指定する必要があるため、都度LambdaのコードをS3にアップしてオブジェクトのURLを取得してテンプレートに反映して…という運用は現実的ではありません。したがって、基本的にはIaCツールやデプロイ用のツールを使う必要が出てきます。
IaCツールの違い
AWS SAM
AWS SAMはCloudFormationの拡張セットであり、CloudFormationの仕組み自体に変換の仕組みが存在します。マネジメントコンソールで確認するとイメージしやすいと思います。
SAM用のテンプレートでスタックを作成すると、CloudFormationの画面上でSAM用テンプレートとCloudFormationのテンプレートを変換して表示できます。
Serverless Framework & AWS CDK
Serverless Framework(sls)およびCDKはCloudFormationのビルドツールのようなものと考えてよいのではと思います。各ツールの記法で準備したテンプレートをデプロイすると、CloudFormationテンプレートに変換されてスタックが作成されます。
実際は、Serverless FrameworkとCDKでは、テンプレートの記載方法（宣言的かプログラミング言語か）やスタックのアップデート方法（変更セットを使えるか否か）等違うため、使い勝手はかなり違ってきますが、CloudFormationスタックとの関係性でいえば似た位置づけといえると思います。
IaCツール選定の際のその他の観点
以上、各ツールの基本的な仕組みを概観しました。 実際にツールを選定する際には多角的に評価を行い、構築後の運用も見据えた上で選定する必要がありますが、上記の仕組みを頭に入れておけば各ツールの違いを理解しやすくなると思います。
本記事では触れませんでしたが、その他の観点については、例えば以下のような点で整理すると検討しやすいと思います。
- コード化する対象がAWSのみか、それ以外も含まれるか
- テンプレートの記載方法が宣言的（yaml等）かプログラミング言語か
- プロジェクトや管理するリソースの規模や、学習コストを鑑みてどちらが適切か
- 運用後のメンテナンス手順が想定している業務フロー(CI/CD)と整合しているか（デプロイ実行時に承認フローを準備するか等）
- IaCツールのアップデートが頻繁か（AWSのアップデートに追随出来ているか）
- 利用コストはどの程度になるか（有償か無償か）
- 開発主体はどのような組織か
おわりに
以上、本記事ではIaCツールの基本的な違いに焦点を当てて紹介しました。
プロジェクトの規模や要件によって採用するツールは変わってくると思いますが、選定の参考になれば幸いです。
ちなみに、Serverless FrameworkやSAM CLIが広がる前はサーバーワークスでも自前のCloudFormation変換ツールを開発していた歴史があります。（永田さん最近何かおもしろいもの作ってますか？） sabawaku.serverworks.co.jp
関連
*1:CloudFormationをベースとしているツールでも一部APIによる操作を行っている場合はあります。例えばServerless FrameworkはCloudFormationによるデプロイをベースとしていますが、API Gatewayのログ設定はCloudFormationではなく、Serverless FrameworkのCLIツールからAPIで実行・管理されています。
紅林輝（くればやしあきら）（サービス開発部） 記事一覧
サービス開発部所属。2015年にサーバーワークスにJOIN。クラウドインテグレーション部を経て、現在はCloud Automatorの開発に従事。ドラクエ部。推しナンバーはⅤ、推しモンスターはクックルー。
