re:Invent 2024: AWSのIaCチームによるCloudFormation進化の1年
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - AWS infrastructure as code: A year in review (DOP201)
この動画では、AWSのInfrastructure as Code製品チームによる、CloudFormationを中心としたIaCポートフォリオの最新アップデートが紹介されています。CloudFormationの高速化により最大40%のスタック作成時間短縮を実現した技術的詳細や、Cloud Control APIを活用したNetflixの革新的なインフラ管理事例が共有されています。また、Infrastructure as Codeの開発速度向上、安全なデプロイ、ガバナンスという3つの重点分野における進展として、CloudFormation Hooks、IaC Generator、Change Setsの機能強化などが解説されています。特に、Resource Registryを基盤とした標準化により、AWS全体で97%のリソースカバレッジを達成し、より柔軟なリソース管理を実現している点が印象的です。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
re:Inventセッション開始：Infrastructure as Codeの紹介
re:Inventの初日へようこそ。多くの方にとって、これが最初のセッションとなるでしょうし、私にとっても今回のイベント初のセッションです。今日、このように熱心なInfrastructure as Codeファンの皆様にお集まりいただき、ありがとうございます。私はAWS Infrastructure as Code製品チームのBen Perakです。一緒に登壇するのは、チームのPrincipal EngineerのJames Hood、そして私たちのインフラストラクチャレイヤーを活用した興味深い取り組みについてお話しいただくNetflixのStaff Security EngineerのNick Slowです。
このスライドに入る前に、少し告白させていただきたいことがあります。皆様はre:Inventとこのセッションに、一流の講演者を期待してお越しになったことと思います。 正直に申し上げますと、本来このトークを一緒に行う予定だった方が週末に体調を崩してしまい、私が代役を務めることになりました。お気に入りの選手が出場できないスポーツ観戦のような状況ですが、精一杯努めさせていただきますので、一緒に楽しい時間を過ごしましょう。
AWSのInfrastructure as Codeツールの概要
それでは、Infrastructure as Codeについて本題に入りましょう。これが何なのか知りたい方のために説明すると、その名の通り、コードを使ってインフラストラクチャを宣言的に定義するものです。この簡単な例では、S3バケットを作成し、シンプルな名前とタグを付けています。そして、Infrastructure as Codeツール（基本的には大規模なオーケストレーションエンジン）を使用します。 このツールが、インフラストラクチャをプロビジョニングするために必要なAPIを判断し、はい出来上がり、タグ付きの素敵なログバケットの完成です。つまり、Infrastructure as Codeが、望んだ状態の設定を適用するための重作業を全て行ってくれるのです。
今日のトークの大部分は、この1年の振り返りです。主に今年リリースした機能について焦点を当てていきます。また、AWS Infrastructure as Codeが提供しているものについてもお話ししたいと思います。多くの方がご存知のCloudFormation以外にも様々なツールがあります。私たちが提供している異なるツールの概要を説明し、今年リリースした興味深い機能について時間を割き、来年に向けて考えていることについても少しお話しさせていただきます。
どのようなツールを提供しているのでしょうか？少し見づらい図かもしれませんが、私たちはこれをレイヤー構造で捉えています。過去にも様々な形で説明してきました。最下層には200以上のAWSサービスがあります。その上のレイヤーには、Resource Registryと呼ばれるものがあります。AWS IaCの主力であるCloudFormationがあり、さらにその上には特定のユースケースを解決するための専用ツールという抽象化レイヤーがあります。また、後ほどお話しするCloud Control APIという素晴らしい機能もリリースしました。
CloudFormationとCDKの進化と特徴
AWSにおけるIaCポートフォリオについて、私たちはこのように捉えています。中心部分から外側に向かって説明していきましょう。先ほど申し上げた通り、CloudFormationは私たちのInfrastructure as Codeの主力です。2011年にローンチされました。当初は必要に迫られての立ち上げでした。クラウドが登場し、人々はリソースをプロビジョニングし、それを複製する必要がありました。手作業でスクリプトを書くのは非常に困難になってきたため、より良い方法が必要とされ、そこからCloudFormationが生まれたのです。
その後、デプロイをより安全に行えるよう、多くの機能を追加していきました。自動ロールバック、結果整合性チェック、その他の機能を実装し、より信頼性の高いアップデートを実現しています。 ユーザーは他のコードと同じように使い始めました。バージョン管理を行い、バージョン管理システムに格納し、インフラストラクチャを簡単に複製できるようになりました。 私たちはこれを、大規模なクラウドアジリティを実現するための必殺技だと考えています。つまり、IaCを使ってインフラストラクチャを宣言的に定義し、それを様々な環境に展開し、それを繰り返すことで、素早く作業を進めることができるのです。
CloudFormationの後、お客様が解決したい特定のユースケースが見えてきました。CloudFormationは素晴らしいものでしたが、Serverlessアプリケーションのために長大なYAMLファイルを書きたくないというニーズがありました。そこで、Serverless Application Modelを開発しました。これは専用のCLIと、Serverlessアプリの作成を容易にする優れたTransform機能を備えています。また、AmplifyチームはフロントエンドのモバイルWebアプリを構築するためのより良い方法が必要だと考え、CloudFormationの上に独自のレイヤーを構築しました。Amplifyのユーザーは、実はCloudFormationのユーザーでもあるのです。そしてもちろん、Cloud Development Kit（CDK）もあります。
他にもたくさんあります。Elastic Beanstalkを使用する場合も、内部的にはCloudFormationを使用しています。Control Towerを使用する場合も同様です。SageMakerのような他のサービスでも、SageMakerノートブックを起動するたびに、実は裏でCloudFormationが動いています。このように、お客様向けサービスだけでなく、社内でも強力なデプロイメントオーケストレーションエンジンとして機能しています。
では、CDKについて少し詳しく見ていきましょう。CDKをご存知の方はどれくらいいらっしゃいますか？予想通りのパターンですね。明らかに、CDKに移行する人が増えてきています。インフラストラクチャを定義する素晴らしい方法です。PythonやTypeScriptなど、好みのプログラミング言語を使用できます。IDEでの作業や、コード補完など、好きな開発環境での利点を活用できます。
また、CDKは構造化の面でも優れています。Constructsは、CDKの強力なコンポーネントです。単一のリソースにデフォルト値を設定する場合でも、複数のリソースを扱う場合でも、さらにはLayer 3と呼ばれる完全なマイクロサービスまでも、ベストプラクティスを定義することができます。これは、インフラストラクチャを作成する上で非常に優れた方法です。CDKをご存知の方なら、これがCloudFormationテンプレートに変換され、CloudFormationを通じてデプロイされることをご存知でしょう。
Resource RegistryとCloud Control APIの重要性
さて、上層のCloudFormationについて説明しましたが、その下層についてはどうでしょうか？最下層にあるのが、 Resource Registryと呼ばれるものです。これは基本的に個々のリソースの集まりです。リソースとは、基本的に基盤となるサービスとやり取りする方法です。AWSでは、新しいサービスや新しいコントロールプレーンAPIが立ち上がるたびに、Resource Registryでリソースカバレッジのサポートが必要になります。私たちはこれをCloudFormationのリソースカバレッジと呼んでいますが、私はAWSリソースカバレッジと呼ぶことを好んでいます。なぜなら、AWSのリソース中心のツールがこのリソースモデルを標準として採用し始めているからです。
設定をチェックするリソース中心のツールであるConfigも、同じリソースモデルを使用しています。Resource Explorerも同じリソースモデルを使い始めています。同じリソースモデルを使用する新機能もいくつかリリース予定です。このResource Registryに基づいて、AWSがリソースをどのように定義するかの標準化が進んでいるのがお分かりいただけると思います。簡単な背景として、私たちは多くのリソースを移行してきました。過去のセッションに参加された方や、ブログをご覧になった方はご存知かもしれませんが、既存のリソースを全て標準的なRegistryに移行しようとしています。現在、標準モデルでの使用率は約97%に達しています。
熱心なCloudFormationユーザーの方は、リソースのインポートやドリフト検出などのサポートが増えてきていることにお気づきかもしれません。リソースがRegistryに追加されるたびに、ドリフト検出などの機能のサポートが得られます。リソースモデルの標準化を進めていく中で、CloudFormationを使用してテンプレートを書いて送信する方法が唯一の操作方法でした。私たちは、標準的なリソースが全てあるのなら、そのためのインターフェースを作ってはどうかと考えました。そこで開発したのが、Cloud Control APIです。
Cloud Control APIは、まさにその名の通り、基盤となるリソースとやり取りするための標準的なコントロールプレーンAPIインターフェースです。環境内のIAMロールを確認したい場合は、単にCloud Control API list IAM roleと指定するだけです。特定のDynamoDBテーブルの状態を知りたい場合は、Cloud Control API read DynamoDBと指定します。これにより、様々なユースケースや自動化を構築することが非常に容易になります。ここで他のサードパーティのIaCツールについても触れていますが、これらはCloud Control APIを使用したプロバイダーをリリースしています。Terraformは今年、Cloud Controlプロバイダーの一般提供を開始しましたが、特筆すべきは、これが自動生成されているという点です。
サービスチームが新機能をローンチする際、リソースのカバレッジを提供する必要がありますが、それは標準モデルを使って構築され、Cloud Control APIに公開されると、これらのツールがすぐに活用できるようになります。これにより、CloudFormationだけでなく、TerraformやPulumiなどのツールのカバレッジも加速することができます。さらに社内では、Configも同じリソースモデルを標準化してCloud Control APIを使用することで、より多くのリソースを追加し始めています。
AWSのInfrastructure as Code改善の3つの柱
お客様からのご要望について説明し、私たちが注力している分野についてお話ししましょう。主な3つの柱があります。1つ目は開発です。これは、テンプレートの作成方法、デプロイ方法、テンプレートの開発テストに関するすべてを含みます。これまでCloudFormationは必ずしも扱いやすいツールではなかったことは承知しています - デプロイに20分かかり、失敗した場合はさらに20分かけてロールバックする必要があったりと。そこで私たちは、コアエンジンの改善から失敗の数を減らすこと、トラブルシューティングまで、開発テストを加速するための多くの改善を行ってきました。
2つ目は安全なデプロイです。インフラストラクチャをデプロイする際、それが安全で、本番環境に障害が発生しないことを確認したいはずです。予定している変更が実際の変更と一致していることを知りたいはずです。私たちは、これらを安全に行うために、変更内容の可視性を確保することに重点を置いています。最後にガバナンスです。皆様の多くは、インフラストラクチャのプロビジョニングの主要な方法としてInfrastructure as Codeを標準化していることでしょう - これは素晴らしい制御ポイントを提供します。正しい設定を確保したい場合、プロビジョニングの時点でチェックすることが最適ではないでしょうか？私たちは、設定の正確性をチェックし、セキュリティとコンプライアンスのベストプラクティスを強制するためのコントロールを作成する機能の提供に多くの取り組みを行ってきました。
これらが今年の重点分野でした。ここからはJamesに引き継ぎます。彼がこれらの異なるカテゴリーについて、より詳しく説明してくれます。
開発スピード向上のための機能と最適化
私はJames Hoodです。Amazonのプリンシパルエンジニアとして働いています。会社には15年在籍しており、その大半をAWSで過ごしましたが、リテール部門でも働いていました。CloudFormationチームには約5年在籍していますが、その前の5年間はAmazon社内でCloudFormationのユーザーでした。そのため、この分野に非常に情熱を持っています。今年のさまざまなローンチについてお話ししたいと思います。まずは開発スピードというテーマから始めましょう。
まず、Infrastructure as Code（IaC）へのプロジェクトのオンボーディング速度を向上させることについてお話ししましょう。このセッションにご参加の皆様は、IaCの重要性と価値についてよくご理解されていることと思います。ちょっとお聞きしたいのですが、コンソールやCLI、SDKを通じて、IaC以外の方法でリソースを作成したことがある方は手を挙げていただけますか？そうですよね。そういうことは起こり得ます。コンソールは新しいサービスを理解し、試してみるのに最適な方法です。アプリケーションの規模によっては、あるいはアプリケーションを始めたばかりの時は、手動でリソースを作成することもあるでしょう。しかし、ある時点でIaCへの移行を検討することになります。
つまり、IaCテンプレートを手作業で構築する必要があるということです。これがIaC導入における大きな障壁となっています。非常に手間のかかるプロセスで、手動で行った設定と完全に一致するIaCの仕様を逆エンジニアリングするのは困難な場合があります。 そこで、手作業での構築の代わりに、今年2月にCloudFormationのIaC Generatorをリリースしました。これがその重労働を代わりに行ってくれます。このツールは、ClickOpsからIaCへの移行をサポートすることを目的としています。
使い方としては、アカウント内のリソースカタログを閲覧し、IaCテンプレートにコピーしたいリソースを選択します。このツールは選択したリソースを検査し、関連する可能性のある他のリソースも特定します。例えば、DynamoDBコンソールでテーブルを作成する場合、気付かないかもしれませんが、バックグラウンドでアラームも作成されています。IaC Generatorは、そのテーブルを選択すると、自動的にそれらのアラームを検出し、インポートするかどうかを確認します。 このように、見落としていた可能性のある必要なリソースを追加できます。そして、ツールはCloudFormationテンプレートを生成し、新しいStackとしてインポートするか、既存のStackにインポートするかの選択肢も提供します。このように、IaC Generatorは、プロジェクトをIaCに移行する際の最初のハードルを乗り越えるのを支援する方法なのです。
次に、開発速度についてお話ししましょう。私はソフトウェア開発に20年以上携わってきました。開発者と一緒に仕事をしてきましたが、編集やテスト、プルリクエストやコードレビューの準備が整うまでの変更を行う、その密接な内部ループの中で、「もっとゆっくり進めたい」と言う開発者を聞いたことがありません。その内部ループをできるだけ高速にしたいものです。IaC開発でも同じことが言えます。IaC開発における内部ループには、テンプレートの編集、開発環境でのプロビジョニング、エラーのトラブルシューティングやデバッグ、そしてその繰り返しが含まれます。この内部ループで速度を低下させる主な要因は、テンプレートのプロビジョニングにかかる時間、エラーが返されるまでの速度、そして開発者が問題をトラブルシューティングするのにかかる時間です。
私たちはこの内部ループのあらゆる側面に焦点を当て、それぞれに生産性の改善を実現してきました。今年の第1四半期には、Stackの作成時間を最大40%短縮したことを発表しました。エンジニアとしてre:Inventに参加することの素晴らしさの一つは、re:Inventが始まって以来、その核心が学びのカンファレンスであることです。エンジニアリングやDevOps、その関連分野の方は手を挙げていただけますか？そうですね、参加者の大多数ですね。だからこそ、エンジニアとして参加するのが大好きなんです。なぜなら、この改善がどのように実現できたのかという詳細について、じっくりと掘り下げて説明する時間を取ることができるからです。この改善は、リソースの並列作成を増やすという、デプロイメント戦略の根本的な変更の結果でした。
この変更以前、CloudFormationは独立したリソースを並列で作成していました。例えば、3つの独立したSQSキューを含むStackを作成する場合、CloudFormationはそれらを並列でデプロイします。しかし、テンプレートで宣言されたリソースは、他のリソースに依存関係を持つことがあります。 ここでは、複数のリソース依存関係を持つコンテナ化アプリケーションの例を示します。ECS Serviceリソースは、ECS Task Definition、ECS Cluster、そしてVPCネットワークリソースに依存しています。さらに、ECS Task DefinitionはECRリポジトリに依存しています。
CloudFormationがこれらのリソースをデプロイする際、ECRリポジトリとECS Clusterは独立しているため、並列でデプロイを開始できます。しかし、ECS Task Definitionのデプロイを開始する前に、ECRリポジトリのプロビジョニングが完了するのを待つ必要があります。同様に、ECS Serviceのデプロイを開始する前に、ECS Task Definitionの完了を待つ必要があります。 これらの依存関係の連鎖は、Stackの作成時間に直接的な影響を与えます。
この処理をどのように高速化できるかを理解するために、個々のリソースのプロビジョニング中に実際に何が起きているのかをより詳しく見てみる必要があります。例としてIAM Roleを取り上げてみましょう。AWSコンソールでIAM Roleを作成したり、CLIやSDKを通じてCreate Role APIを呼び出した場合、APIは平均して1秒未満のレイテンシーで応答を返します。しかし、CloudFormationを使用してプロビジョニングする場合、IAMサービス内の結果整合性を考慮するため、より長い時間がかかります。Create Role APIが応答を返すタイミングと、IAMサービスがバックグラウンドで追加の非同期処理を実行するタイミングには差があるのです。
リソースの作成を2つの重要なマイルストーンに分けることができます。1つ目は「Configuration Complete（設定完了）」と呼ばれるもので、Get Role APIを呼び出すと、行った変更が反映されている状態です。これは通常、最初のAPI呼び出しの直後に発生します。しかし、CloudFormationはさらに追加の時間を待ち、非同期の作業が完了してリソースが使用可能になる「安定化」を待ちます。
CloudFormationは、次の依存リソースに進む前にリソースが完全に安定化するまで待つという、非常に保守的なアプローチを取っていました。しかし、重要な発見として、次のリソースに進むために完全な安定化を待つ必要が必ずしもないということがわかりました。代わりに、Configuration Completeのマイルストーンに到達するまで待ち、その後、楽観的に次のリソースの作成を開始することができます。このデプロイメント戦略を「Optimistic Stabilization（楽観的安定化）」と呼んでいます。
この新しい戦略では、ECRリポジトリの設定が完了した時点でECSタスク定義のプロビジョニングを開始します。同様に、依存関係のあるリソースがConfiguration Complete（設定完了）の状態に達した時点で、ECSサービスの作成を開始します。これにより、より高度な並列処理が可能となり、スタック作成にかかる全体的な時間が短縮されます。この戦略は本質的に楽観的なアプローチであるため、次のリソースを早すぎるタイミングで試みた場合の失敗にも対応する必要があります。
早期にプロビジョニングを試みたリソースでエラーが発生した場合、依存するリソースが完全に安定するまで待ち、その後操作を再試行します。ここでご覧のように、ECSサービスが最初の試行で失敗した場合、CloudFormationはECSタスク定義が完全に安定するまで待ってから、もう一度試行します。このエラーケースでも、時間の節約は可能です。時間の節約の程度は、このリソース依存関係チェーンの長さと、楽観的な作成の試みが成功したかどうかによって異なります。私たちは、このデプロイメント戦略をバックグラウンドで変更しただけでなく、新しいスタックイベントと詳細なステータスフィールドを追加し、リソースがConfiguration Completeステータスに達したタイミングをお客様が確認できるようにしました。これは、スタックのプロビジョニングプロセスの可視性を向上させるためです。
安全なデプロイメントのためのChangeSetとHooksの進化
また、このDetailedステータスをスタックレベルでも追加しました。下位互換性の観点から、実際のスタック操作が完了した時点で、すべてのリソースが完全に安定しているというお客様の期待を維持する必要があります。私たちは、スタック内のすべてのリソースが少なくともConfiguration Completeの状態に達したことを示すこのステータスをスタックレベルで表示したいと考えました。これは、迅速な開発テストサイクルなどのユースケースで、Configuration Completeの状態を確認してすぐに次のステップに進みたい場合に役立ちます。
先ほどの例で、スタックのConfiguration Complete をモニタリングし、CLIを使用してスタックレベルでこの詳細なステータスをポーリングすると、さらに大きな時間の節約が見込めることがわかります。これがあなたのユースケースに当てはまるかどうかは状況によります。例えば、AWS Amplifyのようなツールでは、開発テストの内部ループにいる状況を認識して、自動的にこの機能を統合しています。これは、AWSマネージドサービスの価値を示しています。私たちは、コアエンジンの根本的な変更となるこの作業を行い、毎週多くのスタックをデプロイし、数ヶ月かけて非常にゆっくりとロールアウトする必要がありました。
私たちは、お客様が特別な操作やオプトインを行うことなく、この高速化のメリットを提供したいという強い思いがありました。私がここでお客様としてお話しするのは楽しいことですが、バックグラウンドでエンジニアチームが皆様の作業をより良くしようと努力していることの価値を感じていただければと思います。PowerPointでタイムラインを描くのは楽しいのですが、同じタイムラインをより直感的に表示できればと考えました。約1ヶ月前、AWSコンソールでこの新しいタイムラインビューを公開し、リアルタイムでこのタイムラインを確認できるようになりました。これにより、スタック操作のオーケストレーションがより見やすくなり、どのリソースがプロビジョニングされているか、リソース間の依存関係を理解しやすくなりました。
スタック操作の可視性が向上し、依存関係や処理時間をより深く理解できるようになることを願っています。まだリリースされて間もないにもかかわらず、お客様からの大きな反響と採用をいただいています。興味深いエピソードとして、テンプレートを修正することで自身のデプロイメントを最適化できることに気づいていなかったお客様もいらっしゃいました。プロビジョニングの速度向上以外にも、反復的な開発テストサイクルを加速する要素があります。 その1つが、エラーをより早く検出し、開発者が修正に早く取り掛かれるようにすることです。リソースのプロパティに無効な値を設定したり、必須のプロパティの設定を忘れたりした場合、実際にリソースをデプロイしようとする段階になってはじめてそれに気づくことがあります。そうなると、余分な時間がかかるロールバックを待たなければなりません。
今年、私たちは実際のデプロイを開始する前に、一般的なテンプレートのエラーをチェックする機能の追加を始めました。これらの変更により、中央値で6.2倍、P90ケースで17倍のエラー応答時間の短縮を実現することができました。 もう1つの改善点は、Custom Resourceに関連するものです。この機能により、独自のリソースを作成し、独自のコードを実行して管理することができます。Custom Resourceのデフォルトタイムアウトは1時間に設定されていたため、Custom Resourceの開発中にコードにバグがあり、Lambda関数がCloudFormationに応答する前にエラーを投げてしまった場合、CloudFormationがタイムアウトするまで1時間、さらにロールバックに1時間待たなければならないことがありました。これは開発テストサイクルを大幅に遅らせていたため、Custom Resourceにタイムアウトの設定機能を追加しました。現在では、Lambda関数が迅速に完了するべき場合、長時間待つ代わりに5秒のタイムアウトを設定することができます。
また、エラーが発生した後のトラブルシューティングもサポートしています。昨年、root causeに素早くアクセスできる「detect root cause」ボタンをリリースしました。 Benが説明していたように、リソースレイヤーはAWS APIの抽象化です。例えば、AWS S3 Bucketリソースタイプは、多くのAPIコールの抽象化です。作成や更新を行う際には、多くのAPIコールを実行する可能性があります。
お客様からのフィードバックとして、特定のトラブルシューティングシナリオにおいて、実際の基盤となるAPIコールとその詳細なエラーメッセージをCloudTrailで確認できると便利だという声がありました。そこで、CloudTrailの該当タイムスタンプに直接アクセスして、それらのイベントをすぐに確認できる機能を追加しました。また、最近「diagnose with Amazon Q」という機能もリリースしました。 これにより、root causeエラーを分析し、Amazon Qとの対話を通じて、エラーメッセージをより人間が理解しやすい形で説明を受けることができます。さらに、「help me resolve」ボタンをクリックすることで、CloudFormationのエラーを解決するためのアドバイスを得ることもできます。
テンプレート作成時の生産性を向上させるための多くのツールについて、簡単にご紹介したいと思います。 最初は、CloudFormationのLinterツールである「cfn-lint」です。cfn-lintの使用状況について尋ねたところ、それほど多くの手が挙がりませんでした。cfn-lintは非常に時間を節約できるツールです。私が初めて発見したときは、まさにゲームチェンジャーでした。今年、このツールのGA版をリリースしました。デプロイする前にテンプレートをチェックし、エラーや警告を返すことができ、デプロイ時まで気づかないような多くのエラーを検出できます。非常に人気のあるツールなので、IDEプラグインも提供しており、IDEで入力しながらエラーを検出することができます。
CloudFormation Rainは、テンプレートの作成とデプロイのワークフローをサポートする、もう一つの便利なCLIツールです。このツールを使用すると、テンプレートのフォーマットや整形、ローカルアーティファクトのパッケージング、そしてリアルタイムの更新による対話的なデプロイメント体験が可能になります。最後にご紹介したいのは、AWSコンソールやIDEから利用できる生成AIを活用したシステム、Amazon Qです。VS CodeやJetBrainsでサポートされています。もしまだ試していない方は、特にIaCテンプレートとの連携が素晴らしいですよ。IDE上で新しいテンプレートを生成できるだけでなく、テンプレートの特定の部分をハイライトして、その部分が何をしているのかをQ Developerに説明させたり、テンプレートの一部を編集させたりすることもできます。
例えば、プロパティをあまり設定していないSNSトピックを作成した場合、Amazon Qは、そのSNSトピックのデータを暗号化するためにカスタマー管理のKMSキーを使用することをベストプラクティスとして推奨します。そのトピックをハイライトしてカスタムKMSキーを追加するよう指示すると、テンプレートにキーを追加し、そのトピックから参照するように設定してくれます。 最初にCDKユーザーの方が多くいらっしゃったので、今年のCDKの新機能について少しお話ししたいと思います。まず、サブネット設定を含むVPC用の新しいL2コンストラクトがリリースされました。VPCは、L2コンストラクトを持っていない最も使用頻度の高いコンストラクトでした。CDKに馴染みのない方のために説明すると、CDKにはL1、L2、L3と呼ばれる異なるレベルがあります。L1は生のCloudFormationリソース層で、L2はスタックでプロビジョニングできる様々なリソースに対して、より開発者フレンドリーで人間工学的な体験を提供します。今回導入されたVPC用のL2コンストラクトは、L2コンストラクトの利便性と、基盤となるVPCリソースの完全な設定可能性とパワーを兼ね備えています。
また、Origin Access Controlを備えたCloudFrontコンストラクトもリリースしました。これにより、S3バケット、ELBV2ロードバランサー、その他のドメイン名からCloudFrontディストリビューションのオリジンを作成できるようになり、これはCDKユーザーから最も要望の多かった新しいL2リクエストでした。さらに、開発者プレビュー段階の2つの新しいL2コンストラクトがあります：Kinesis Data Firehoseデリバリーストリームを定義できるKinesis Data Firehose用のコンストラクトと、ユーザーに他のAWSサービスへのアクセスを許可できるCognito Identity Pools用のコンストラクトです。
品質改善も行われました。CDKにはアセットという概念があり、これはLambda関数のコードを保持するS3オブジェクトやECRコンテナイメージなどです。使用されなくなった古いアセットが不要なコストを発生させていたため、ガベージコレクション機能を追加し、自動クリーンアップを設定できるようになりました。また、CDKがIAMロールを引き受けた際に、デプロイメントが1時間以上かかると、そのセッションがタイムアウトする問題がありました。CDKチームは、より長時間のデプロイメントをサポートするためにIAMロールセッションタグで対応しました。
以上がデプロイメントの速度に関する内容でした。次は、デプロイメントの安全性についてお話しします。内部ループの速度は非常に重要ですが、実際にプロダクション環境にデプロイする外部ループに到達すると、その時点で安全性が最も重要になります。 cfn-lintのような検証ツールは、プロビジョニング前にテンプレートが構文的に正しいことを事前に検証するのに役立ちますが、実際にデプロイした際に具体的に何が変更されるのかが必ずしも明確ではありません。 スタックの更新を実行して全てが計画通りに進むことを期待するのではなく、CloudFormationにはChange Setsという概念があり、これを作成することで実際に行われる変更のセットを確認し、デプロイ前にそれらをレビューすることができます。
CloudFormationはこれまでもChangeSetを提供してきましたが、それはリソースレベルでリソースが追加、変更、削除されることを示すだけで、それ以上の詳細な情報は提供していませんでした。今年の第2四半期に、リソースのプロパティと属性の変更前後の値を表示するChangeSetの機能強化をリリースしました。ここに、Lambda関数をプロビジョニングするCloudFormationテンプレートコードの一部があります。handlerや関数名など、一部のプロパティには具体的な値が設定されていますが、他のプロパティは動的な値となっています。関数のメモリサイズはテンプレートパラメータへの参照で、デフォルト値は128ですがデプロイ時に上書きすることができます。また、関数のランタイムはSSMパラメータ値への動的参照によって設定されています。
このテンプレートを新しい変更として送信したとしましょう。ソースコントロールでdiffを確認すると、このように表示されるかもしれません。ソースコードのdiffだけを見ると、runtimeプロパティとroleプロパティが変更されると予想されますが、CloudFormationがデプロイ時にこれらの動的な値をどのように解決するかまでは分かりません。この例で見られるように、ChangeSetは予想とはかなり異なる結果を示しています。runtimeプロパティは確かに変更されており、ChangeSetではその具体的な変更後の値を確認できます。roleプロパティは、ソースコードでは変更されているものの、GetAttribute関数が同じ値を返すため、実際には変更されません。また、テンプレートソースでは変更していないメモリサイズのプロパティが変更されていることも分かります。これは、この値がテンプレートパラメータから取得されており、前回のデプロイ以降に誤って値が変更された可能性があるためです。
これは、ChangeSetがいかに強力で、デプロイによって何が具体的に変更されるのかを確実に把握できることを示しています。昨年、GitHub Sync統合機能をリリースし、GitHubプロバイダーからCloudFormationへの直接同期が可能になりました。このChangeSetの機能強化の一環として、最近、Pull Requestのコメントに自動的にChangeSetを投稿する機能をリリースしました。Pull Requestを作成すると、バックグラウンドで自動的にChangeSetが作成され、Pull Requestにコメントとして投稿されます。これにより、レビュアーはPull Requestを承認してマージする前に、具体的に何が変更されるのかを確認できます。
ここで、ChangeSetの興味深い顧客の使用事例を紹介したいと思います。この事例では、顧客はAmazon自身です。CloudFormationは、Amazon社内でAWSインフラストラクチャをデプロイするための事実上の標準ツールとなっており、CloudFormationチームは社内のBuilder Toolsチームと緊密に連携しています。彼らはAmazonのビジネスを支えるソフトウェアを構築する社内エンジニアリングチーム向けのツールを作成しています。運用の優秀性は常にAmazonの重要な焦点であり、私たちはBuilder Toolsチームと協力して、安全なインフラストラクチャデプロイメントのための新しいイノベーションを実験しています。
今年、彼らと取り組んでいる重要なプロジェクトの1つがChange Guardianです。Change Guardianは、CloudFormationのChangeSetに対して一連のルールを実行し、潜在的なハイリスクな変更にフラグを立て、それらの変更をブロックするか、確認を求めるツールです。このルールを実行することで、データを保持している可能性のあるステートフルなリソースの誤削除や、パブリックアクセスを持つバケットを誤って作成するなどのセキュリティ関連の問題といった、潜在的に危険な変更を特定することができます。CloudFormationチームにいる利点の1つは、長年にわたって私たちを使用してきた顧客が同じ会社の一部として非常に身近にいることです。使用中のリソースの誤削除による障害や同様の問題について、独自の洞察を得ることができます。これらのルールを社内で実験し、これらの実験的な機能について協力しながら、最も優れたものをCloudFormationに追加して、すべての顧客がそれらの恩恵を受けられるようにすることを計画しています。
ガバナンスとコントロールの強化：CloudFormation Hooksの活用
クラウドの黎明期から、皆さんは次のようなトレードオフと向き合ってきました：開発者に自由と俊敏性を与えて速く進むか、それともコントロールを実装するか。ここで手を挙げていただきたいのですが、「開発者の俊敏性を重視して速く進もう」という立場の方はどのくらいいらっしゃいますか？「いや、コントロールが必要で、すべてが正しくなければならない」という方はどのくらいですか？このように意見が分かれているということは、この綱引きが現実に存在していることを示しています。
お客様がこの課題に対処しようとする際によく見られるパターンの1つが、Golden Pathです。ベストプラクティスのテンプレートやConstructsを提供するGolden Pathを導入している方はどのくらいいらっしゃいますか？これは一般的なパターンですよね？これは開発者が速く進むことを可能にする素晴らしい方法です。「これらは事前承認済みのテンプレートですよ」と伝え、それを使えばすぐにデプロイできます。「これらがConstructsで、これらがModulesです。どうぞ速く進めてください」というわけです。このアプローチは、そのパターンが完全にニーズを満たさない微妙なケースが出てくるまではうまく機能します。そしてGolden Pathのカスタマイズをどう扱うかというボトルネックが発生するのです。
もう1つよく見られるパターンが、Detective Controlアプローチです。つまり、プロビジョニングを許可しておいて、事後的に問題を検出するというものです。これは設定ミスを検出する良い方法として知られていますが、多くの場合、修正にはコード変更が必要になります。これらの問題が見つかった時の対応コストは非常に高く、変更のためにデプロイ期間や停止時間が必要になるかもしれません。開発者は設定ミスの修正にも時間を費やさなければなりません。つまり、少し遅すぎるし、少しコストがかかりすぎるのです。
私たちが好む対処方法は、CloudFormation Hooksと呼ばれる機能を通じたものです。 CloudFormation Hooksをご存じない方のために説明すると、これはCloudFormationサービス内のコントロールポイントだと考えてください。つまり、CloudFormationに「DynamoDBテーブルを見かけたら、設定をチェックして、ベストプラクティスに合致しているか確認してください」と指示するのです。
もし合致していれば、続行を許可します。合致していなければ、その処理を許可しません。これは、プロアクティブなチェックを実行し、ベストプラクティスの設定を強制する非常に強力な方法だと考えています。多くの方がインフラストラクチャのデプロイの主要な方法としてInfrastructure as Codeを標準化していると申し上げましたが、これはプロアクティブなコントロールを強制する非常に良い方法となります。
私たちは約18ヶ月前にHooksをローンチしましたが、作成プロセスが非常に難しいということが分かりました。ユーザーからのフィードバックは「プリミティブは気に入っているが、開発者体験が良くない」というものでした。そこで今年は、Hooksを簡単に作成できるようにすることに注力しました。最初に実装したのは、単にLambda関数を指定するだけでHookを作成できるようにすることでした。Lambda関数の作成は、私たちのお客様の間でよく見られるパターンです。仕組みとしては、CloudFormationに対して、S3バケットの作成やIAMポリシーの作成など、特定のアクションを見かけたら、Lambda関数を実行するように指示します。そうすると、完全に解決されたリソースのペイロードがLambda関数に送信されます。この時点で、Intrinsic関数の値などは含まれていません。
完全に解決されたリソース情報がLambda関数に渡され、Lambda関数がそれを評価します。多くのお客様は既に社内にポリシーエンジンを持っているので、プロビジョニングされる内容を確認して、それが適切かどうかを判断するだけで済みます。これは、AWS Managed HookまたはAWS Managed Lambda Hookと呼ばれるものです。このHookは追加料金なしで利用できます。もちろんLambdaの使用料は発生しますが、Hook自体の実行に対する課金はありません。
私たちはCloudFormation Guardというポリシーアズコードツールを提供しています。ご存じない方のために説明すると、これはオープンソースのポリシーアズコードツールで、宣言的なドメイン固有言語でポリシーを記述し、CloudFormationテンプレートをスキャンしてルールに合格するかどうかを判断します。Hookの作成を簡素化するために、単にGuardルールのセットを追加するだけで済むようにしました。オープンソースのGuardリポジトリには多くの優れたGuardルールが公開されています。Control Towerは、Guardを使用して250以上の優れたマネージドコントロールを公開しています。これらのGuardルールをS3バケットに配置し、このタイプのリソース操作が発生するたびにこれらのルールを実行するようにHookを有効化するだけで済むようになりました。
これまでは、Resource Hooksと呼ばれるものがありました。これはリソースがプロビジョニングされる直前に実行されるものでした。Jamesがオーケストレーションエンジンについて説明したように、キューをプロビジョニングする時が来たら処理を停止してHookを実行していました。これは完全に解決されたリソース情報を得られるという点で良かったのですが、お客様からは複数のリソースを一度に評価したい、あるいはテンプレート全体を評価したいというフィードバックがありました。多くのお客様は既にテンプレートスキャンソリューションを持っており、パイプライン内でそれを管理するのではなく、CloudFormationに管理を任せたいと考えていました。
そこで、新しいタイプのHook実行ポイントを導入しました。最初のものはCloud Control APIです。Cloud Control APIについては既に説明しましたが、これは新しいインターフェース、リソースと対話する新しい方法です。TerraformやPulumi、Ansible向けの新しいプロバイダーをローンチし、これらのリソース変更操作はすべてCloud Control APIを通じて行われます。そして今回、HooksをCloud Control APIにも拡張しました。つまり、CloudFormationと同様に、プロアクティブなチェックをCloud Control APIにも適用できるようになりました。実際、評価するリソースとペイロードは全く同じものです。
次に私たちがリリースしたのはStackのためのHooksでした。このHookを実行すると、テンプレート全体を取得できます。これは、テンプレートをスキャンする既存の方法をお持ちで、独自のパイプラインを実行・管理したくない場合に非常に強力な方法です。今ではそれをHookとして実行し、よりサービスマネージド型のHookとして利用できます。つまり、Create、Update、Delete操作が発生するたびに、Hookはテンプレートのペイロードすべてを取得できます。私が最も期待しているのは実はChangeSetsです。Jamesは可視性を向上させるためにChangeSetsをどのように強化しているかについて詳しく説明しました。一般的なパターンとして、デプロイメントを実行し、ChangeSetを作成し、そのChangeSetのレビューを行うというものがあります。例えば、運用チームがDynamoDBテーブルを削除していないかチェックするというRunbookを持っているかもしれません。今では、そのChangeSetに対してHookを実行できるため、これらのステップの一部を自動化できるようになりました。
全体として、2つの新しいマネージドHook、より簡単なオーサリング、そしてCloud Control API、Stack、ChangeSetのための新しい呼び出しポイントを提供しています。私たちはこれらの機能に大変期待しており、さらなる革新を続けていきます。完全に新しいコンソールデザインも用意しました。最近CloudFormationコンソールをご覧になった方はお分かりかと思いますが、ナビゲーションペインでHooksをより上位レベルに位置づけ、これらを試せる非常に使いやすいワークフローを提供しています。これらは数週間前にリリースされたばかりですので、ぜひご覧になって、お試しください。繰り返しになりますが、マネージドHooksは追加料金なしでご利用いただけます。
Hooksは段階的に導入できるよう、異なるモードで実行できます。そして、まさにそれを実践しているお客様についてお話ししたいと思います。
Cox AutomotiveはAWSを全面的に採用している企業です。Kelley Blue BookやAutotraderといった素晴らしいツールを提供しています。 彼らは、これらのプロアクティブなチェックを加速する方法を探していました。彼らは堅牢な検知スキャンソリューションを持っていましたが、それにはコストがかかり、より良い方法が必要だと私たちに相談してきました。 彼らのアプローチは、私が気に入っているのですが、非常に体系的で分かりやすいものです。最も一般的な検知コントロールの失敗を分析し、それをプロアクティブなコントロールに変換する方法を決定します。同じルールをCloudFormation Hookに変換し、Warmモードで設定します。
Hooksには完全な失敗またはWarmモードがあるため、突然デプロイメントが失敗してアプリケーションチームのデプロイメントパイプラインを完全に中断させるのではなく、フィルターモードでHookを有効にして何が起きているかを学習できます。運用を妨げることなく、これらの違反がどの程度の頻度で発生しているかを確認できます。彼らは適切な変更管理プロセスを実装し、30日後にはこの操作が防止されることをチームに通知し、これにより検知コントロールの違反を排除します。これは、ビジネスを中断することなく、検知コントロールアプローチからプロアクティブコントロールアプローチへ移行するための非常に効果的な方法です。
さて、ついにNickの番が来ました。Nickはここで辛抱強く待っていてくれました。先ほど紹介した通り、NetflixのStaff EngineerであるNickをお迎えできることを大変嬉しく思います。彼はCloudFormationではなく、先ほど説明した基盤層の機能について、非常に革新的な取り組みを行っています。では、Nickにバトンを渡したいと思います。
NetflixのCloud Control API活用事例：Managed Cloud Resources
こんにちは、NickといいますNetflixのCloud Infrastructure Securityチームに所属しています。最近、私たちはCloud Control APIを様々な用途で活用していますが、特に一つのプロジェクトについて、AWSのエコシステムを通じて大きな価値を見出しています。Netflixのインフラ管理について少し背景をお話しすると、私たちは可能な限り、サービスやプラットフォームを抽象化してラップすることを心がけています。私たちは、Golden PathあるいはPaved Roadアプローチと呼ばれる方法を強く信じています。
多くのサービスにおいて、エンジニアの前に抽象化レイヤーやUIを配置し、それを通じてインフラストラクチャーにアクセスしたり管理したりしています。IAMに関しては、ConsoleMeというオープンソースツールを使用しており、これが社内のIAM変更の大部分を管理しています。EC2関連のすべて、つまりコンピュート、ストレージ、ネットワーキングについては、Spinnakerというもう一つのオープンソースツールがあり、ほとんどの人がこれを使って変更を行っています。しかし、多くのサービスについては、まだ何も用意できていません。私たちは、Core Cloud Infrastructure Primitivesと呼んでいるS3バケット、SQS、SNSトピック、DynamoDBテーブルなどを頻繁に使用しています。
これらの多くのサービスにPaved Roadがないという課題を認識し、これまではエンジニアに任せていました。コンソールを使う人もいれば、CloudFormationやTerraformなどのツールを使う人もいて、それぞれが自分なりの方法を見つけていました。そこで、セキュリティやインフラの観点から、私たちの意見やベストプラクティスをユーザーにセルフサービスの形で提供する方法を見つけたいと考えました。私たちの目標は、最小限のPaved Roadを作ることでした。より多くのサービスタイプに対応していく必要があることは分かっていましたが、小規模なセキュリティチームの立場からすると、スケールさせるのが難しくなることが予想されました。また、既存の体験をNetflixらしい方法で構築したいと考えていました。AWSコンソールを再構築したくはありませんでしたし、AWS CloudFormationを一から作り直すことは絶対に避けたかったのです。そこで、Managed Cloud Resourcesというソリューションを考案しました。これは、Cloud Control APIをバックエンドに使用して、幅広く、かつ増え続けるリソースを管理するものです。
では、これがどのように見えるのか、簡単なデモをお見せします。まず、Infrastructure as Codeテンプレートを見ていきましょう。これはNetflix流のもので、テストアカウントの1つのリージョンに新しいS3バケットを作成し、Example Appというアプリケーションにそのバケットからの読み取り権限を付与するものです。
ここで最も興味深いのはAWSの部分でしょう。Lifecycle ConfigurationとTagsを設定しているところです。これをコミットしてソースコントロールにプッシュしていきます。
プッシュが完了したら、社内のUIツールであるSpinnakerを確認すると、このリソースが「updating」状態になっているのが分かります。これは調整プロセスが進行中であることを示しており、バックグラウンドでは設定を有効化するために必要な変更を行い、Cloud Control APIに処理を引き継いでいます。
バケットを確認してみると、まず、ベストプラクティスに従って新しい名前が生成されているのが分かります。また、多数のTagも追加されています。先ほど指定したTagに加えて、このバケットの用途を示す様々なメタデータや詳細な情報を含む追加のTagが設定されています。さらに、バケットポリシーを明示的に指定していないにもかかわらず、自動的に生成されていることが分かります。このポリシーはTagベースのABAアプローチを使用して、先ほど言及したExample Appにアクセス権を付与し、所有アプリがバケット内のすべてにアクセスできるようにしています。管理画面では、指定したLifecycle Policyも正しく設定されていることが確認できます。
では、これはどのように構築されているのでしょうか？Cloud Control APIをどのように活用しているのでしょうか？これは私たちの社内KubernetesプラットフォームであるInfraAPIと統合されています。Benが先ほど説明したように、CloudFormationレジストリ（標準モデル）を取得し、そのスキーマをCloud Control APIが理解できる形式に変換してKubernetesリソースを生成し、社内で利用しています。開発者のワークフローは他のIaCツールと非常によく似ており、開発者はYAMLテンプレートから作業を開始します。
私たちのチームは特に、様々なチェックと調整を行っています。このリソースに対して操作を許可すべきかどうかの認可を実施し、リソースの起動方法に関する私たちの考えに基づいたセキュアなデフォルト設定を適用し、設定をチェックし、先ほど見たような多くの属性を自動生成しています。その後、Cloud Control APIにこれらを引き渡して処理を実行します。今説明したプロセス全体を通じて、Lifecycle Configurationの設定方法やTagの設定方法、バケットの作成方法などを具体的に知っているコードは一切ありません。開発者の意図を受け取り、それをパッケージ化してAWSに引き渡し、処理してもらうという形になっています。
なぜCloud Control APIを選んだのでしょうか？なぜこのテクノロジーを選択したのでしょうか？ まず第一に、カバレッジの観点があります。私たちは多くの新しいリソースタイプに対応し、将来的にもさらに拡張していきたいと考えていました。そのため、AWSネイティブで、新しいリソースや属性にすぐに対応できるものに標準化したいと考えました。また、非常にカスタマイズされた体験を構築したいと考えていました。Cloud Control APIはCloudFormationの基本要素で構成されているため、それが可能でした。Stacksのような特定の構造や、リソースをCloudFormationにインポートしたり後で出力したりする必要があるなど、CloudFormationではうまく機能しない部分がありました。
Cloud Control APIを使用することで、そのほとんどを解決できることがわかりました。独自の構造や独自のセマンティクスを定義できます。コンソールで作成したリソースをIaC管理に移行するプロセスは非常に簡単でした。Stack stateの概念もなく、Terraformのstateのようなものもありません。また、Cloud Control APIのエコシステムには、使いたいと思う強力な機能がたくさんありました。Drift管理は大きな要素の一つでした - 私たちは望む方法でDriftを検出し、場合によっては修正したいと考えていました。また、多くのコントロールを導入したいと考えていました。つまり、ワークフローの中間部分で、すべてのリソースの作成とすべてのリソースの変更の間に介入したいと考えていました。
全体として、これは私たちのツールキットにおける非常に強力な新しいツールとなっています。私たちはこれを使用し、他の場所でも面白い使用例を見つけています。従来なら必要だった量のコードのごく一部で、インフラストラクチャ管理のための新しい体験を構築することができています。もしこれらの問題に共感できる方、自社でIaCソリューションを構築している方がいらっしゃいましたら、ぜひ検討してみることをお勧めします。
AWSのInfrastructure as Codeの未来と結びの言葉
では、お返しします。ありがとう、Nick。私たちがCloudFormationだけに縛られているわけではないということを示せたのは、とても素晴らしいことだと思います。このリソースレイヤーを公開する必要性を認識し、そのためのインターフェースを作成しました。そして、Cloud Control APIを最初にローンチしたときには思いもよらなかった、エキサイティングな新しいユースケースが開かれています。このパートナーシップに感謝しています。
私たちは、これら3つの主要な領域に引き続き注力していきます。より高速に、より安全に、そしてもちろん、ガバナンスコントロールを継続していきます。今年ローンチした機能について話しましたが、それらの機能についても引き続きイノベーションを続けていくことをお約束します。
興味深いのは、環境を一貫して読み取り、リソースの設定を確認できる標準リソースモデルについてです。従来の方法では、一方向の操作、つまりテンプレートを作成してCloudFormationに送信し、リソースをプロビジョニングするという流れでした。純粋な状態では、CloudFormationだけを使用する場合、これは素晴らしく機能します。しかし、変更管理のドリフトが発生し、さまざまな理由で人々が異なる操作を行います。時にはConsoleに行かなければならず、緊急のバグ修正が必要な場合もあり、そうして変更が発生するのです。
私たちが目指しているのは、リソースの双方向的な柔軟な管理の実現です。例えば、誰かがConsoleで変更を行い、その変更をリアルタイムで特定できれば、CloudFormationがその変更を認識して「あなたのテンプレート、つまり望ましい状態に変更が加えられましたが、これでよろしいですか？どのように修正しますか？どのように同期を取り戻しますか？」と問いかけることができます。このフルライフサイクルのリソース管理が可能になったのは、共通のリソースレイヤー、環境を一覧表示して読み取る共通の方法、そして管理下にあるリソースの変更を特定する共通の方法を持つようになったからです。
私たちは今でも、CloudFormationを主要な方法として推奨していますが、CloudFormation以外でも変更が発生することを認識しています。そのような場合、お客様が同期状態を取り戻すのは非常に困難です。私たちが目指す方向性は、ClickOpsで何かを行った際に、それがシームレスにCloudFormationテンプレートに統合されるという、境界線があいまいな体験です。CloudFormationがそれを認識し、素早く同期状態に戻れるようサポートします。この分野では、来年にかけて多くのドリフト管理機能を提供する予定です。
私たちには多くの役立つリソースがあります。CloudFormationとCDKのワークショップがありますので、ぜひチェックしてください。また、私たちが活発に活動しているDiscordチャンネルもあり、もちろんCDK Slackチャンネルでも多くの良いオープンソースに関する議論が行われています。以上で終わりとなりますが、ご清聴ありがとうございました。ちょうど時間となりました。素晴らしいre:Inventイベントをお楽しみください。初日ですが、足元には気をつけて、水分をたくさん取ってください。質問がある方のために、もう少しこの場に残っていますので、よろしくお願いします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion