こんにちは、クラウド事業部の山路です。
AWS re:Invent 2023に参加し、いくつかのセッションを見て回ったのですが、特に行ってみたかったセッションについて紹介します。
このセッションは同じタイトルのものを去年も実施していたのですが、個人的にIaCに関心が強いこともあり、興味深く視聴していました。今年も同じタイトルで発表があることを知り、せっかく現地に行けるのだから聞いてみたい！ということで参加してまいりました。
ただし、私の英語力が足りず当日の発表内容を十分理解できたわけではないため、今回はYoutubeの動画内容＋現地の雰囲気をちょっとだけお伝えする形とします。
動画はこちら。
講演開始
当日はいちおうReservationで行ったのですが、人数的には多少余裕がある感じでした。とはいっても8割くらい？は席は埋まっていた印象です。
発表者はTatiana Cookeさん / James Hoodさん。
冒頭に参加者向けにアンケートなどもしていましたが、さすがに日頃IaCを扱う人が多く参加していたのか、会場の半分くらいは挙手していた印象でした。
さて、今回の発表は大きく3つのテーマからなります。
- AWSのIaCを振り返る: CloudFormationやCloud Control APIの話
- IaCを組織内にスケールするためにどうするか
- AWSにおけるIaCの今後について
1. AWSのIaCを振り返る
まずは1つ目のテーマ。ただしこちらは昨年とほぼ同じような内容に見えたので、一部割愛します。
まずは全体像から。ご存じの通りAWSにはAWS CloudFormationというIaCサービスがあり、それを支えるレイヤーとしてCloudFOrmation resource registryがあります。CloudFormationを抽象化したレイヤーとしてAWS CDK / SAM / Copilot / Application Composerが、さらにその上位にAWS Service Catalog / AWS Amplifyなどが位置します (去年はここにAWS Protonも書いてありました)。
CloudFormationと同じ位置にAWS Cloud Control APIがありますが、これは2年前に公開された、全てのリソースで共通のAPIから操作することを実現する新しいAPIです。Terraform / Pulumiなどのサードパーティ製品もこの恩恵を受けます。
ここで登場したCloudFormation Resource Registryとはリソースを提供するレイヤー (Resource Provider Layer) とも言い換えられますが、このレイヤーはCloudFormationの定義ファイルに書かれた情報をAPIコールの形に変換します。
CloudFormationが出た当初、Resource Registryは存在しませんでした。しかし、サードパーティへの利用、AWSリソースに対するCloudFormationのカバー率の向上、リソース共通で利用することでのAWS内部でのリリース効率向上？などにより、Resource Registryを利用するほうへ移行が始まりました。
2023年末までには、全てのリソースがResource Registryを使用するモデルに変更が完了する予定。
ただし移行はそこまで簡単な話ではありません。後方互換性も気にしながら複数の自動テストを用意したり、部分的な障害を想定したカオスエンジニアリング的なテストを実施したり。
話は変わってCloud Control API。すべてのユーザーがCloudFormationを使ってるわけではないと理解しており、IaCの共通の問題を解決するためにCloud Control APIをローンチした。
例えばTerraformはCloud Control Providerを所有しており、2024年にはこれを公開する予定。
ここから、IaCを利用するうえでどんな道をたどるかの紹介。
IaCを実践する際はいくつかのステップを踏むことになります。コードを書く、テストする、デプロイする、などなど。
IaCにまつわる多くのアップデートがありましたが、ここからは特に注目の機能を各ステップごとに紹介。
まずはIaCを始める段階。
1つ目はApplication Composerのビジュアルエディターの紹介。当初はサーバーレスのみが対象でしたが、その後のユーザーからの声を受け、全てのCloudFormationリソースのサポートを開始しました。これにより新しいアーキテクチャを考えたり、既存のAWSサービスの構成を把握することが、プロジェクトの新規参入者でもやりやすくなります。
次は実際にIaCコードを書く段階。
ここではAmazon CodeWhispererが役に立ちます。つい先日IaCにも対応したため、コードの補完や生成機能を使いながらIaCコードを書くことができます。
次はテストの段階。
ここではAWS Integrated Application Test Kit (IATK) の紹介をしています。AWS Lambdaなどはこのテストライブラリを使うことで自動テストが書きやすくなるとのこと。
※IaCのテストについては、以前私の書いたこちらの記事などもご覧ください。
続いてはデプロイの話。
1つ目は、ChangeSet作成時に既存のカスタムリソースをStackにImportしてくれる機能。
2つ目は、特に大規模Stack向けに、エラー発生時の根本原因を表示してくれる機能の紹介。
次はスケールアップの話。
CloudFormationではStackSetを使うことでリージョンやアカウントに共通のStackを展開することができます。こちらもConcurrencyModeの発表、Suspendedなアカウントをスキップするなどの機能が公開されています。
2. IaCを組織内にスケールするためにどうするか
IaCを採用する組織とIaCの利用方法のパターンは様々あります。最近だとPlatform Engineeringが普及し始めていますが、それも1つのパターンに含まれます。
今はIaCを組織にスケールするのを始めやすい時期だと考えている。Iacを始めやすく、より高速にビルドし、より安全にデプロイする方法がそろっているからです。
これまで開発者がIaCを開発する際、AWSマネジメントコンソールの画面とIaCファイルを行き来しながら行うことが多かった。
既存のリソースのCloudFormationテンプレートを生成する機能が近い将来利用可能になります。これによりCloudFormationで管理されていないリソースが分かるようになり、管理されていないものを選択するとCloudFormationテンプレートが生成されます。
CDKでも同様の機能はサポートされ、既存のリソースをCDKに移行するのがはるかにやりやすくなるとのこと。VSCodeで生成したL1 CDKコードを見ることも可能。
続いては、IaCをチーム内に普及するうえで直面する課題の紹介。
1つ目は、リソースのプロビジョニング時間が異なる可能性があること。例えばコンソールからIAMロールを作成したときは即座に完了するのに、IaCから作成するともっと長い時間がかかるように見えることがあります。
AWSリソースを作成するとき、実際には大きく2つのステップに分けて実行されます。基本的にはConfiguration Completeが完了した時点で、例えばリソースの状態をAPIから取得すると、変更内容が反映された結果を返します。しかし実際は内部的な処理がその後走り、Ready for useの状態になるまで少し時間がかかります。
多くのIaCツールはConfiguration Completeの状態になると作成完了の返り値を返しますが、CloudFormationの場合はReady for useになってから完了とする、保守的なアプローチをとっています。どちらのアプローチがよいかは一長一短です。
2つ目は、コンソールから操作することが多いチームの習慣を変える必要があること。IaCで管理するようにしたのちもコンソールから設定変更を行えばドリフトが発生するため、新しい習慣を身に付ける必要があります。
ただし、これまでと大きく異なる手段をとらなければならない場合、新しい習慣に慣れるまで時間もかかります。例えばCloudFormation Stackを管理するためにS3バケットにテンプレートをアップロードしてから操作する必要がありますが、こういった操作がチームになじみにくい一面もあるでしょう。
そこでGitHub / GitLabを中心としたGit ワークフローをベースに、GitOpsのアプローチをとれるようアップデートしました。
3つ目は、適切なツールを使ってより高速にビルドすること。そのためには抽象化により高レベルでリソースを管理することが助けになります。
SAMのアップデートやCDKの紹介など。
CDKによる事例の紹介。PGAツアーで使われるアプリケーションはCDKをベースにしたマイクロサービスアーキテクチャを採用しており、ツアーが進行中も並行してトーナメント用のサイトを用意したり、古いスタックの削除やアップデート頻度の大幅な向上を達成しています。
IaCの開発者はよりプロアクティブに動くことで、開発・テストのループを短くしたり、より早い段階でバグを検出したり、多くのメリットがあります。
ここでCloudFormation Hookの機能の紹介。何かしら問題があればそれを検知し処理を停止します。このあとGoDaddyでの具体例も紹介されていました。
今年期待しているHookの機能の紹介。ターゲットタイプによるフィルタリングなど。
3. AWSにおけるIaCの今後について
これまでIaCと聞くと、Yaml / Jsonなどのファイルを作成することを考えてきましたが、SAM/CDKなど抽象化する手段が出たり、Application Composerによる作成もできるようになりました。そして2023年には生成AIによるIaCの構築も登場。
今後は、これら複数のインターフェイスをシームレスに行き来できるようになるでしょう。
今後は生成AIを利用しつつ、複数のインターフェイスからIaCを扱うことになるでしょう。例えばApplication Composerで視覚的に見た後、実際のコードを確認し、さらにCodeWhispererで自然言語による入力も可能です。
ここまでの発表で、シームレスに扱うための多くの機能を紹介できたと考えています。
未来を考えるうえでヒントとなる例の紹介。2012年のジェフ・ベゾスの言葉より、「10年後に変わるものが何かよく聞かれるが、10年後に『変わらないもの』はなにか、聞かれることはほとんどない」とのこと。
ではIaCにおいて変わらないものは何か。AWSでは引き続き、IaCによるリソースのカバー範囲と品質を追求します (Consistency) 。またIaCは組織などでクラウドリソースの利用を拡張する手段であると考えており、大規模に実行できるサービスの向上も重要です (Scalability) 。さらにIaCコードの作成方法が多岐にわたるにつれ、それらを安全にデプロイする仕組みも重要になるでしょう (Safety) 。ロールバックやHookなどは注力分野となります。
最後はユーザーの声を待っていますというアナウンスで終了。
さいごに
AWSのIaCの基本から今年のアップデート情報、今後どう変わっていくかの話などなど、内容盛りだくさんのセッションでした。個人的にはCloudFormationがほかのIaCツールと比べてより保守的な作るにしている、という部分がとても興味深く、今後IaCツールを選定する時にも役立ちそうな情報だなと感じました。
また、CloudFormationの内部の話や事例紹介などが興味深いのはもちろんですが、なによりIaC好きな方は興味深く聞けるセッションなのではないかと思います。IaC好きな方はぜひ一度聞いてみてください。
明日以降もAWS re:Invent2023の内容を共有していこうと思います。
