echo("備忘録");

IT技術やプログラミング関連など、技術系の事を備忘録的にまとめています。

【AWS】IaCツールの比較

Infrastructure as Code(IaC) Serverless Framework terraform AWS CDK

はじめに

お久しぶりです。

今までGitやJavaScriptについて書きましたが、今回は、Infrastructure as Code(以下IaCと記載)のツールについての記事です。

IaCツールに関しては色々あると思いますが、今回触れるのは下記の3つです。

  • AWS CDK
  • Terraform
  • Serverless Framework

上記について、自分なりに感じた特徴やメリット・デメリットなどを記載しようと思います。

前提

  • 今回はゼロベース(新規に一から導入する)観点で書いています。
    • 導入＆実際に運用後はまた違ってくると思うので
  • 自分の経験の関係上、ターゲットとなるクラウドはAWSとなります。

TL;DR

特徴 言語 メリット デメリット 有用なケース
AWS CDK ・プログラミング形式で書ける
・AWS公式		 各種プログラミング言語 プログラミング言語である プログラミング言語である プログラミングをわかる人がIaCも担当する場合
Terraform ・HCLという独自言語で記載
・公開モジュールを利用できる		 HCL(HashiCorp Configuration Language) ・リソースの参照がしやすい
・公開モジュールを利用できる		 パラメータ名が一部CloudFormation(以下Cfnと記載)と異なる クラウドインフラ全般をカバーしたい場合
Serverless Framework ・プラグインで機能拡張ができる
・YAML/JSONで記載できる		 YAML/JSON ・Lambda関連が非常に便利
・プラグインで機能拡張できる		 Lambda関連以外の部分の記載 Lambdaを多く使用する場合

AWS CDK

特徴

プログラミング言語で書ける
AWS CDKはプログラミング言語でコーディングして記載するのが特徴です。(メジャーなのはTypeScriptかな？)
そのため、何かしらの言語を知っていれば、導入の敷居はあまり高くないと思います。

AWS公式ツールである
AWS CDKはAWS公式が出しているツールなので、その点で(謎の)安心感があるかもしれません。(だから何？と言えばそれまでなのですが)

メリット

プログラミング言語で記載
先述の通り、AWS CDKはプログラミング言語で記載するので、いずれかの言語の知識があれば、導入はそれほど難しくありません。
そのため、アプリエンジニアがそのままAWS CDKでIaCを導入する...といったこともできます。

また、プログラミング言語に慣れている人からすれば、YAMLやJSONより構造的で分かりやすくなるかな？という点も個人的にはメリットだと思います。

デメリット

プログラミング言語で記載
メリットと同じ内容ですが、裏を返せば、プログラミング何もわからん...という場合は、導入の敷居が高いかもしれません。

有用なケース

プログラミングをわかる人がIaCも担当する場合
ある程度対応するプログラミング言語がわかるメンバー(アプリエンジニアなど)が複数いる場合、AWS CDKは下記観点で有用だと思います。

  • プログラミング言語で書ける(=導入の敷居が高くない)
  • 複数のメンバーがメンテ対応できる(=属人化を防ぐ)

Terraform

特徴

HCLという独自言語で記載
TerraformはHCL(HashiCorp Configuration Language)という独自記法で記載します。(下記コードを参照)
といっても、そんなに難しいものではないので、そこまで導入に時間はかからないのではと思います。

# S3バケットを定義
resource "aws_s3_bucket" "b" {
  bucket = "my-tf-test-bucket"

  tags = {
    Name        = "My bucket"
    Environment = "Dev"
  }
}

# S3バケットポリシーを定義
resource "aws_s3_bucket_policy" "allow_access_from_another_account" {
  bucket = aws_s3_bucket.b.id
  policy = data.aws_iam_policy_document.allow_access_from_another_account.json
}

公開モジュールを利用できる
Terraformのモジュール(詳しくは前回の記事を参照)は、下記リンク先(公式サイト内)で公開されているものも多く、これらを使うことで、わざわざ自作せずとも、そのまま公開モジュールを利用できます。
そうすることで、定義作成の手間を軽減することができます。

https://registry.terraform.io/browse/modules?provider=aws

メリット

リソースの参照がしやすい
Terraformは、他のリソースの値の参照がしやすい、と個人的に感じました。
例えば先述のソースでbucket = aws_s3_bucket.b.idという記載がありますが、これだけでresource "aws_s3_bucket" "b"のバケット名を参照できるので、例えばRefやFn::GetAttなどを利用しなくていいのは便利です。

また依存関係も、基本的には自動で解決してくれるので、自分で依存関係(=depends_onなど)を定義しなくてもいいのは良いなと思います。(一部、入れないといけないケースはありますが)

その他、外部リソース(アカウントIDやAWS上にあるリソースのARN等)の参照もHCLで記載できるので、わざわざローカルで定義しなくていいのは便利だと感じました。

公開モジュールを利用できる
「特徴」でも書いた通り、公開モジュールを利用することにより、わざわざモジュールやoutputの定義を自作する必要がなくなります。
そのため、公開モジュールを利用すれば、定義の手間を削減できます。

デメリット

パラメータ名が一部Cfnと異なる
一部リソースの一部パラメータ名がCfn構文のそれと異なる場合があるので、その場合はそのパラメータがどれに対応するかを調べる必要があります。(基本的には似通った名前だったり説明を読めばなんとなくわかりますが、たまに分かりにくいものもある)

有用なケース

幅広いリソースをデプロイする場合
Terraformはサポートしている範囲が広いので、数多くのリソースをデプロイする場合に向いていると感じます。(例えば、Fargateでフロント環境もして、RDBやDynamoDBなどのバックエンド環境も同時に作って...など)

別リソース値の参照や依存関係の解決がやりやすい点がその理由です。

またHCLで記載するので、特定のプログラミング言語に依存しない(=プログラミングに詳しくなくても対応できる)という点もメリットかなと思います。
(もちろん、プログラミングに詳しい場合でもTerraformを使用するメリットは大いにあります。)

個人的にはオールラウンダーなイメージで、ちょっと乱暴な言い方かもしれませんが「迷ったらTerraformを選ぶ」みたいな選択もアリなのかな？...とも思っています。

Serverless Framework

特徴

プラグインで機能拡張ができる
下記ページでプラグインが公開されており、標準で対応していないリソース・機能についても、プラグインで対応できる場合があります。

https://www.serverless.com/plugins

YAML/JSONで記載できる
Serverless Frameworkは、基本的にYAMLまたはJSON形式で記載します。
そのため、専用の言語や記法を覚える、ということはないので、その点で導入はしやすいと思います。

またnpmモジュールなので、インストールもnpm(yarn) install 1つで済むのは便利です。

メリット

とにかくLambda周りの定義が簡単
個人的に、Serverless FrameworkはとにかくLambda周りの定義が本当に簡単＆充実しているのが最大のメリットだと思います。
例えば、Web APIでよくあるAPI Gateway+Lambdaの構成は、下記7行(実質6行)だけでできてしまいます。(最低限の設定であれば)

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get

またそれ以外にも、S3, DynamoDBなどのトリガ設定も充実しています。

プラグインで機能拡張できる
「特徴」にも書いた通り、プラグインで機能拡張をすることにより、標準ではサポートしていないリソースにも対応できるケースがあります。
またプラグインでは単体テストなど、リソース定義以外で役立つものもあり、デプロイ以外にも開発全般で有用なものも多いです。

デメリット

Lambda関連以外の部分の記載
逆に、Lambda関連以外のリソースについては、AWS CDKやTerraformに比べるとサポートしていないものもまだまだあります。
その場合は、resourcesセクションに純粋にCfn構文を記載することになるので、そこが煩わしい、と感じることがあると思います。

有用なケース

Lambdaを数多く使用する場合
「メリット」に書いた通り、Serverless FrameworkはとにかくLambda周りの定義が便利＆シンプルなので、(Web APIなど)Lambdaをたくさん使うような環境の場合、非常に有用だと思います。

またLambda以外の部分ですが、プラグインで対応したり、場合によっては他のIaCツールと併用する...というのもありだと思います。(管理は少し煩雑化してしまうかもしれませんが...)

まとめ

以上、IaCツール3つについて、ゼロベースで導入を考えた際の個人的な見解について書きました。

ただ、いろいろあるでしょうが、あくまで上記は考え方の一つであり、最終的にはプロジェクトの特性とか、メンバーの好みで選択するのも全く問題ないと思っています。

なので、あくまで今回の内容はゼロベースで導入を考えた際の参考程度にして頂ければと思います。

それでは、今回はこの辺で。