こんにちは、最近Alexaに好きな音楽を伝えるとそればっか再生されて飽きてきたので、どうAlexaに伝えれば傷つかないかを考えている志水です。
「APN AWS Top Engineers/APN Ambassadors Week」の3日目の記事になります。といっても、特にTop Engineerに関係ない話をします。
Architecture as Codeという言葉をご存知でしょうか？2019年のAWSのブログでArchitecture as Codeという言葉が出て、そこから一部のマニアックな方が言及されているのですが、イマイチ浸透せず可愛そうな状況になっています。個人的には面白い概念だと思い、かつ最近Architecture as Codeの概念を継承しているサービスのAWS Copilot/AWS Amplifyが盛り上がっているため、改めてまとめようと思います。

Infrastructure as Codeとは

Architecture as Codeを説明する前に、まずInfrastructure as Code(以降IaC)について説明します。IaCには、広い意味と狭い意味の二種類あり、一般的に使われているのは狭い意味の方になります。それぞれの意味は下記になります。

広義
- 自動化、バージョン管理、テスト、継続的インテグレーションといった、ソフトウェア開発のプラクティスをシステム管理に応用するための方法論
狭義
- 個々のインフラリソースをコード化してプロビジョニングすること

広義のほうは、インフラをコード化することにより、ソフトウェア開発のエッセンスを享受し、応用する 方法論 になります。概念的な言い方ですね。狭義のほうは、目的がプロビジョニングになっていて、ChefやAnsibleなどのサーバプロビジョニングツールや、AWSのクラウドリソースプロビジョニングツールのCloudFormationなども有名ですね。本記事ではこの狭義をIaCとして定義します。

IaCについては下記書籍が非常によく説明されていて勉強になるのでオススメです。

Architecture as Codeとは

次に、Architecture as Code(以降AaC)について説明します。
AaCとは「クラウドアーキテクチャをモデル化・コード化しプロビジョニングすること」になります。IaCはそれぞれ個々のリソースについてコード化していたのに対し、AaCでは、リソースが組み合わされ、モデル化された構造をコード化することになります。よく、マイクロサービス化すると、同じようなパターンのサービスが点在することになり、そのような類似したパターンをコンポーネントとして再利用可能にして、各サービスに展開できます。

AaCのメリットは下記になります。

スピード感のある開発が可能
- 記述量が少ない
- 類似した構造をすぐ作れる
ベストプラクティスに沿った構築が行われる

AaCで代表的なAWSのサービスとして、AWS Copilot/AWS Amplifyがあります。

AWS Copilot

Copilotとは、最近出たGithubのツールではなくAWSのツールです。（検索しづらくなるなぁ。。）Amazon ECSをベストプラクティスに基づき、デフォルトでモダンかつプロダクションレディなインフラを構築するツールです。ECSを一から構築すると非常に煩雑で躓くポイントが多く大変です。また、こちらの記事のようにIAMロールの設定箇所も多く、最小権限を求めると非常に難しいです。

そこで、Copilotを使えば、下記のような構築したい構成を決めて、いくつかパラメータを与えれば、サクッとECSの環境が出来上がります。

リクエスト駆動型Webサービス
ロードバランス型Webサービス
バックエンド型サービス
定期ジョブ型サービス
パイプライン

また、本番環境や開発環境なども同じ構成でデプロイでき、クロスアカウントへのデプロイも対応している高機能なプロビジョニングツールです。個人的には、CICDパイプラインをサクッと作れるのが素晴らしいと思います。CodePipelineも考えるところが多いので非常に助かります。

AWS Amplify

AWS Amplifyについては古田さんの記事が分かりやすいです。（後編が楽しみですね）基本的にはアプリケーションを作る上で必要なAWSリソースをサクッと作れてアプリからライブラリを利用して使えるサービスで、アプリケーション志向なツールです。こちらをインフラ観点で見るとリソースのプロビジョニングツールと捉えることができて、下記のようなユースケースに沿ってリソースがデプロイされます。

静的サイト
REST API
GraphQL API
認証
ストレージ

こちらもCopilotと同じように、CICDパイプラインが自動で作られるし、IAMについて深く考えなくてもベストプラクティスで作成されるので非常に簡単に最適な環境が手に入ります。

AWS Cloud Development Kit(CDK)

CDKとは、今までCloudFormationからyaml/jsonを書いてプロビジョニングしていたものをプログラミング言語を書いてプロビジョニング出来るようにしたツールです。利用できる言語は下記になります。

JavaScript
TypeScript
Python
Java
C#
Go(開発者プレビュー)

また、こちらから、追加されるかもしれない言語が見れます。Ruby/Kotlin/PHPの順に人気そうで、Goが開発プレビューで出たので、次はRuby辺りがきそうですね。

CDKはベースがCloudFormationなので基本的には個々のリソースのプロビジョニングを行えるIaCとして利用されます。ただ、一部AaC的な動きをする部分があります。例えば下記のようなものがあります

ALBベースのコンテナサービス
NLBベースのコンテナサービス
キューベースのコンテナサービス
定期ジョブ型サービス
リダイレクトパターン

上記のようなパターンを作成して、そのパターンに追加で修正したい場合もパターンのコードから追加・修正が可能なので、柔軟性が高い状態でAaC的なメリットも受けられます。

IaCとAaCの分類

IaCとAaCを自分なりに分類してみたのが下記になります。

AaCとしてはAmplify/Copilotになり、そこからIaC側にCDKやTerraformなどがあり、IaC側にCloudFormationがあります。IaCにいくほど柔軟性が高くなり、AaCにいくほど構築スピードが上がります。IAMを設定しなくなれば立派なAaCという感覚がしてます。

ツールの選び方

私が考える、ツールの選択方法は下記の通りです。

AaCを選ぶケース
- 要件が合致して、変更予定もない
- 要件をAaC側に寄せられる
IaC&AaCを選ぶケース
- 変更出来ない要件でAaCで対応できない
- 要件の変更が出てくる

要件が合致するか要件をツール側に合わせれるならAaCのツールが良いかと思います。譲れない要件がありAaCツールでは出来ないことが分かってるものは、IaC&AaCのラインを利用するのが良いかと思います。その中でも個人的にはAaCに近いCDKが好きなのでオススメです。

ここでAaCにするかどうかのポイントで重要なのは要件的に出来るかどうかの部分になります。Amplify/Copilot共にある程度柔軟性は有りますが、やはりそれ以外のツールよりは多少柔軟性が落ちます。そこで、出来ない事を調べるというのも重要で、その調べ方としては、Github Issueが良いです。下記がそれぞれのIssueになるので、まずは要件から出来そうかどうか調べてみましょう。また、出来なかったよブログも重宝されるので、是非書いていきましょう。