IaCツールの多様性とその魅力
はじめに
株式会社GoalsのインフラでSREをやってます。今回は入社エントリでもさらりと触れたIaC（Infrastructure as Code）について掘り下げていきたいと思います。現代のソフトウェア開発の世界では、インフラストラクチャをコードとして管理することが、もはや一般的なスキルとなっています。IaCツールは、インフラストラクチャを効率的に管理し、再利用可能なコードを作成するのに役立ちます。実際に使用し、その特性と利点を体験した3つの主要なIaCツール、Terraform、CDK、そしてCDK for Terraformについて記述します。
自身のIaCキャリア
自身のIaCのキャリアとしては以下になります。そのためある程度偏った知識になるかもしれないですが、ご了承ください。
Terraform歴 前職で提案から導入、運用までを実施。実績は2年。
CDK歴 現職で業務としては初（自身の検証用途では経験あり）、期間は半年間
CDK for Terraform 提案と運用の評価中。期間は2ヶ月。
前職でTerraformを選定した理由
前職では一部インフラストラクチャをCloudformationで管理していましたが、他のリソースはAWSマネージメントコンソールやCLIで実施しており、コード管理もされていない状態でした。Cloudformationでの運用を拡張していく方向もありましたが、jsonやymlでの管理は辛かったので別のIaCツールの選定をしました。当時はTerraformの他、CDK、Pulumiも検討段階にあがりましたが、なぜTerraformを選択したかというと既存リソースの管理(import)にすることと管理から外すこと(state rm)が容易だったからです。いざとなればTerraform毎捨てることができる、というのが魅力的に思えました。Terraformのメリットとしてマルチプロバイダというのがよくあげられますが、管理リソースの管理のしやすさというのが僕自身メリットとして大きかったです。ちなみに当時CDKでは既存リソースのimportはサポートされていませんでした。
実行イメージ
複数のAWSアカウントで運用していたためaws-vaultでAWS Profileを指定しているようにしていました。
awsprofile AWSアカウントで起動しているEC2インスタンスをimport
aws-vault exec awsprofile -- terraform import aws_instance.web i-12345678 awsprofile AWSアカウントで起動しているEC2インスタンスをTerraform管理外にする
aws-vault exec awsprofile -- terraform state rm aws_instance.web CDKに触れてみて
AWS Cloud Development Kit（CDK）はAWSのリソースを管理するためのオープンソースのIaCツールで、TypeScriptなどの一般的なプログラミング言語を使用してインフラストラクチャを定義できます。CDKの最大の利点は、開発者が既に習熟している言語を使用できることで、学習曲線を緩和します。また、CDKはAWSのサービスとの統合が深く、AWSの全範囲をカバーしています。僕自身今まで言語という言語には触れたことがなかったのですが、作成されたリソースとCDKのコードの中身を見比べることによって「この定義でこのリソースができるのか」と理解しやすい状況であったと思います。API GatewayやCloudfrontなどTerraformで定義するのが結構しんどかったりするのですが、CDKであればAWS側でよしなに抽象化して設定してくれるので楽に思えました。
CDK for Terraformの導入
CDK for Terraform（以降CDKTF）はTerraformの機能をCDKのフレームワーク内で利用できるようにするツールです。CDKの利便性とTerraformのプロバイダー中立性を組み合わせ、一般的なプログラミング言語を使用してマルチプロバイダー（AWSに限らずDatadogなど）定義することが可能になります。前職のTerraformの経験と現職CDKの経験から導入はしやすかったと思います。ただ、まだ現時点ではメジャーバージョンがリリースされておらず破壊的な変更がある可能性を考慮し、現状CDKやTerraformで管理されているのはそのままとし、Cloudformationで管理されているリソースやそもそもIaCで管理されていないものをCDKTFで管理していく方針にしました。
複数のIaCツール運用で意識したこと
実行方法の差異
terraform、CDK、CDKTFではそれぞれ実行方法が異なります。
CDKでのDryRun
envで環境名指定 引数に対象のStackを指定
aws-vault exec awsprofile -- npx cdk diff -c env=develop TargetStackTerraformでのDryRun
environmentsディレクトリ単位で環境を分けているためchdirで指定するようにしています。
aws-vault exec awsprofile -- terraform -chdir=environments/develop planCDKTFでのDryRun
ちなみにサブコマンドはterraformと互換性がありdiff指定の箇所はplanでも同じ結果が得られます。
aws-vault exec awsprofile -- cdktf diff developただこのままだと実行時に混乱する可能性がありあまり開発者体験が良いとはいえません。なのでここはMakefileでラップすることで実行方法に差異がでないようにしました。
make _ENV=develop diff
とはいえ、本来ローカルで実行しないようにせず、CI/CD化（PullRequestが作成されたらdiff mergeされたらdeploy）するのが本質ではあると考えておりますがまだ道半ばの状態ではいます。一部リソースではtfcmtを利用させていただき、diffの結果をPullRequestのコメントに追記するといった運用もしています。
管理リソースの明確化
あと懸念していたのがマネージメントコンソールなどで確認するときになんのIaCツールで管理されているかわからなくなることでした。これは単純にタグ設定で Key:IaC Valueに cdk or terraform or cdktf を付与するようにすることで明確になりました。 特にterraformとcdktfはdefaulttagsが利用できるので楽に付与することができました。
現代のクラウドスキルのディファクト
弊社はAWSで ECS RDS stepfunctions などを利用しております。現状のクラウドスキルのディファクトともいえるCDK、Terraform、Container、AWSに加えCDKTFを身につけることができる環境や職場はなかなかありません。これらのスキルを持つことは、現代のソフトウェア開発業界での競争力を大幅に向上させることができます。これらのツールを使用する機会を得たことで、インフラストラクチャ管理の効率性と再利用性を実感し、自身のスキルセットを大幅に拡張することができました。これらのスキルを身につけることは、自身のキャリアを大きく前進させることができたと感じています。特定のツールを限定して使うというのもメリットとしてはあるとは思いつつ以下の面でデメリットも少なからずあると考えました。
限定的な機能: そのツールが提供する機能に限定されてしまいます。例えば、特定のクラウドプロバイダやサービスに特化した機能を持つツールを使用している場合、他のプロバイダやサービスを利用する際にはそのツールが対応していない可能性があります。
柔軟性の欠如: そのツールが提供するフレームワークや方法論に縛られてしまい、柔軟性が欠如します。例えば、特定のプログラミング言語やDSL（ドメイン特化言語）でしかインフラストラクチャを定義できないツールを使用している場合、他の言語やDSLを使いたいときに制約を感じることがあります。
ツールの進化と更新: 一つのツールに依存していると、そのツールが更新されない、または開発が停止した場合、新しいテクノロジーや機能を取り入れるのが難しくなる可能性があります。
実際の例として AWSの親和性が高いと思われていたCDKよりもterraformのほうがAurora Serverless V2のサポートが早かったりすることもありました。もちろんその逆の例もあると思います。
まとめと問題定義
本内容はTerraform、CDK、そしてCDK for Terraformといったクラウド技術を使って、インフラストラクチャをコードで管理する実際の運用について記載させていただきました。IaCツールを使うことで、インフラストラクチャの状態を管理し、変更を追跡し、必要に応じて状態を再現または変更することができます。これらのスキルは、現代のクラウドネイティブな開発環境で非常に価値があると考えています。しかし、ここで一つ問題を定義しておきたいと思います。それは、「今まで問題なかったから、例え非効率だったとしてもそのやり方を踏襲する」という状況です。これは、テクノロジーの世界では特によく見られる現象で、これを「過去の成功からの囚人」とも言います。つまり、過去の成功体験が現在の行動を縛ってしまい、新しいアプローチやツールを試す機会を失ってしまうということです。テクノロジーは日進月歩で進化しており、過去の成功が未来の成功を保証するわけではありません。この記事で述べたTerraformやCDK、クラウドプラットフォームのAWSも例外ではなく、それらより効率的な方法や、より良い結果を得るものがでてくる可能性があります。そのため、常に新しいツールやアプローチに対してオープンであり、最適なツールを選択する自由度を持つことが重要だと考えています。
蛇足
本記事は以下のような環境で書きました！（嘘）
ロケーションとしてはいいんですが、水辺の近くで電子機器を開くとなんかそわそわするのは自分だけですかね。。
ワーケーションしたいなー。