re:Invent 2024: AWSが紹介するCDKとAmazon Q Developerの活用法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Next-generation CDK development with Amazon Q Developer (DOP215)
この動画では、AWS CDKを活用したInfrastructure as Codeの開発について、AWS Senior TechnologistのAdam KellerとSenior Solutions ArchitectのPahud Hsiehが解説します。CDKのConstructsによる抽象化の利点や、Amazon Q Developerを活用した開発の効率化について詳しく説明されています。特に注目すべきは、Amazon Q DeveloperによるL2 Constructの自動生成のデモで、設計ガイドラインとパターンを基に、20分程度でOpenSearch Service用のL2 Constructを作成し、テストとドキュメントまで生成する過程が示されています。また、CDK DEVというSlackチャンネルやConstruct Hubなど、CDKに関連するコミュニティリソースについても紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Q DeveloperとAWS CDKの概要
Amazon Q Developerを活用した次世代CDK開発についてのセッションへようこそ。この1時間を私たちと共に過ごしていただき、ありがとうございます。Amazon Q、AWS CDK、そしてこれらのConstructsの構築プロセスをどのように加速できるかについて、皆様とお話しできることを大変嬉しく思います。私はAdam Kellerと申します。AWSのSenior Technologistとして約6年半、モダンアプリケーション関連のDevOpsやインフラストラクチャーアズコードに携わってきました。ここ数年は特にCDKに注力しています。では、もうお一方からも自己紹介をお願いします。はい、Pahud Hsiehと申します。Senior Solutions Architectとして、AWS CDKチームをサポートしています。
本セッションでは、まず私たちがこれまでの年月で直面してきた問題や、現在も対処している課題についてお話しします。そして、CDKについてまだ詳しくない方のために、CDKの素晴らしさについて基本的な説明をさせていただきます。Constructsを通じた抽象化の利点についても触れ、その後、Amazon Qという生成AIコーディングコンパニオンを使って、どのように開発のスピードを上げ、本当に重要なことに集中できるようになるのかについて説明します。そして、Pahudが素晴らしいデモを用意しています。 実際の現場での活用例を示すこのデモは、私の説明よりもはるかに説得力があるはずです。
AWSでの開発における課題とCDKの登場
AWSで開発された経験をお持ちの皆様なら、開発の規模の大小に関わらず、様々な課題に直面されたことと思います。インフラストラクチャーアズコードを使用する場合でも、コンソールで作業する場合でも、独自の自動化を行う場合でも、常に新しいサービスや機能に追いついていく必要があります。新しい技術を学ぶ際には、必ず学習期間が必要です。例えば、特定のコンテナ技術に精通していても、新しい技術が登場すると、それを理解し習得しなければなりません。このように、エコシステムは常に進化し、絶え間なく変化しています。
さらに、実際のクラウド環境やAWS上でアプリケーションやワークロードを運用していく中で、問題は必ず発生します。私たちは完璧ではありませんし、ミスも起こります。そしてトラブルシューティングには多くの時間がかかることがあります。ユニットテストやローカルテストの実施、充実したドキュメントの作成は非常に重要だと、私たちは理解しています。でも、私のように少し怠け者な方は、いつもそれらを完璧にこなせているわけではありませんし、追いつくのも大変です。
これは本当に大きな課題となっています。 私は10年以上にわたってAWSでの開発に携わってきましたが、最初の頃 - AWSの登場以前から、物理サーバーのラックマウントやAWSコンソールでのクリック操作による構築など - もちろん、必要なことを達成するためにはどんな方法も否定されるべきではありません。しかし、コンソールでの手作業による構築には課題が多いことがすぐに分かりました。結局のところ、失敗のポイントや問題が多く存在し、ドキュメントの更新も追いつかないことが多かったのです。
そのサービスや機能を構築した担当者が会社を去ってしまい、その仕組みを理解するのに苦労するというケースもあるでしょう。そこで、私たちはスクリプトを導入し始めました。PythonやBash（私たちが大好きなBash）、PowerShellなどを使ってInfrastructure as Codeを構築していましたが、やはりインフラストラクチャやクラウドリソースのCRUD操作の管理は課題となっていました。作成は簡単ですが、更新が必要な場合もあり、べき等性が非常に重要になります。これを独自のスクリプト言語やコードで管理するのは非常に困難です。
ここでInfrastructure as Codeが誕生し、 AWS CloudFormationやTerraformのようなツールによって私たちの生活は格段に楽になりました。なぜなら、構築したいもの、環境に実現したい状態を宣言的に記述するだけでよくなったからです。CloudFormationのようなInfrastructure as Codeエンジンの仕事は、リソースの作成や変更などのCRUD操作を処理することです。そのロジックについて考える必要はなく、望む状態を宣言するだけでOKです。
ここまでできているなら、素晴らしい成果です。Infrastructure as Codeを使用しているということは、正しい方向に進んでいます。時間を節約でき、望む状態をコードで定義できています。できれば、バージョン管理を使用して、環境に加えられた変更の追跡と履歴を適切に管理していることでしょう。
CloudFormationやTerraformなどを使って独自のInfrastructure as Codeを構築する場合、多くの場合、構築するものすべての詳細を知っている必要があります。そのボイラープレートロジック、VPCを一から構築すること、ルートテーブルの作成、適切なAvailability Zoneの選択、NAT Gateway、Internet Gatewayの設定など、面倒で時間のかかる作業になることがあります。必要でない場合は、これらのことを考えたくないし、そのレベルで考える必要もないはずです。
ここでAWS Cloud Development Kitのような抽象化を備えたツールが登場しました。 AWS CDKは、プログラミング言語を使ってInfrastructure as Codeを定義できるだけでなく、強力な抽象化が組み込まれており、私たちが注力したい部分にだけ集中できる、便利なヘルパーメソッドを活用できる、そういった方向性への動きの始まりでした。IAMポリシーを自分で書いたり、VPC全体を一から作成したりする必要はなく、必要に応じて後からそれらを拡張することもできます。
とはいえ、実際の環境では、これらすべてのことを行っているはずです。 おそらく今この瞬間も、オフィスや自宅で誰かがConsoleで手作業での構築を行っているでしょう。また、スクリプトを書いている人もいるはずです。スクリプトは、一回限りのタスクを自動化したい場合、例えばテスト用のS3バケットを毎日空にしたい（使い終わった後に料金を支払いたくない）場合などには素晴らしいツールです。そして、Infrastructure as Codeについても同様です。Amazon Qは、ConsoleでもIDEでも、AWSで構築する際のあらゆる開発段階でサポートしてくれます。Generative AIのコーディングアシスタントを活用できるのです。この点については、すぐ後で詳しくお話しします。
CDKの特徴とConstructsの概念
先ほどCDKについてご存知の方、使用経験のある方を伺ったところ、 定期的に使用している方と初めての方が良いバランスでいらっしゃいました。そこで、CDKについて少しご説明させていただきます。AWS CDK（Cloud Development Kit）は、開発者やビルダーが一般的なプログラミング言語を使用してInfrastructure as Codeを定義できるオープンソースの開発フレームワークです。Python、TypeScript、JavaScript、Java、C#、Goなど、好みの言語でInfrastructure as Codeを作成できます。
よく皆さんと話をすると、「それは素晴らしい」という反応で、CDKの主なセールスポイントだと考える方が多いのですが、私の意見では、CDKの真の力はConstructと呼ばれる抽象化にあります。これらのConstructsは、Intent-based APIを提供します。 非常に読みやすく理解しやすいヘルパーメソッドがあり、必要なものを構築する際に、シンプルな単語やフレーズを使用するだけで済むようになっています。
CDKは状態管理にCloudFormationを使用しています。つまり、Infrastructure as Codeの状態管理について車輪の再発明をする必要はなく、実績のあるCloudFormationを使用しています。CDKは単にプログラミング言語を使用してInfrastructure as Codeを記述できるようにするもので、それをCloudFormationに変換し、CloudFormationがすべてのクラウド操作を処理します。これらのIntent-based APIと抽象化により、多くの時間を節約できます。例えば、IAMポリシーを作成する際、私のような人間は最小権限のIAMポリシーを作成したいと考えますが、それは本当に面倒な作業になりがちです。IAMポリシーを作成し、ロールにアタッチし、そのロールが適切なプリンシパルによって引き受けられることを確認する代わりに、CDKのgrantメソッドを使用すれば、それらすべてを処理してくれます。さらに、CDKを使用してアプリケーションアセットを構築することもできます。私が特に気に入っているプラクティスの1つは、Infrastructure as Codeとアプリケーションコードを組み合わせることです。
特にサーバーレスアプリケーションやAmazon ECSやAWS Fargateのようなコンテナ化されたアプリケーションをデプロイする場合、すべてが1つの場所に存在します。他のリポジトリを探したり、複数のビルドプロセスを管理したりする必要はありません。CDKがアプリケーションアセットのビルド、アセットの保存、そしてデプロイされたコンピュートが最新バージョンのアセットで実行されることを保証してくれます。さらに、セキュリティも非常に重要です。私はPolicy as Codeの大きなファンです。
CDKでは、この1年半の間に、ガバナンスとポリシーを開発者のワークステーションに左シフトできる素晴らしい機能をリリースしてきました。CDKコードを書きながら、Policy as Codeを実行して、コンプライアンス違反やベストプラクティスから外れていないかをすぐに確認できます。これを実現する方法は2つあります：人気のオープンソースツールであるCDK Nagを使用する方法と、CDKアプリケーションでCFN Guardを統合できるPolicy at Synth Timeを使用する方法です。
CDKは非常にコミュニティ主導で運営されています。CDK DEVという名前のSlackチャンネルがあり、そこではAWS外部の方々がコアライブラリに貢献してくださっています。非常に情熱的なコミュニティなので、CDKに興味がある方や、誰かに質問を投げかけたい方は、このSlackチャンネルに参加してください。コミュニティはとても親切で受け入れ態勢が整っていますので、皆さんが構築しているものについて、ぜひお話を聞かせていただければと思います。
CDKの世界で抽象化について話す際、これらはConstructsと呼ばれ、異なるレベルの抽象化を提供する様々なレベルのConstructsが存在します。最初のLevel 1 Constructsは、CloudFormationに直接マッピングされます。L1 Constructsが使用される一般的なケースは2つあります：より高レベルの抽象化やL2 Constructが利用できない場合と、Constructsを構築するチームが完全なコントロールを持ちゼロから作り上げたい場合です。CloudFormationで新しいリソースがローンチされると、数日以内にCDKでL1 Constructとして利用できるようになります。
最も人気のあるのがLevel 2 Constructsです。これらはCDKチームによって慎重に作られており、Intent-based APIと抽象化を提供することで、より迅速な開発を可能にします。面倒な定型作業について考える必要がありません。例えば、DynamoDBテーブル、Lambda関数、S3バケットを作成する際、通常であればIAMロールを作成し、そのロールをLambda関数に割り当て、S3やDynamoDBにアクセスするためのIAMポリシーを作成する必要があります。CDKでは、grantReadのようなヘルパーメソッドを使用することで、必要なポリシーの作成と関連付けを1行のコードで自動的に処理できます。
そして、Level 3 Constructsがあります。これはパターンと呼ばれ、非常に独自の考えが反映されています。多くの場合、プラットフォームチームがL3 Constructsを構築します。確立されたパターンで構成されているためです。この例では、CDKコアライブラリに含まれているApplication Load Balanced Fargate Serviceパターンを見てみましょう。これは56行のCDKコードから800行以上のCloudFormationコードを生成できます。非常に独自の考えが反映されており、VPC、コンテナイメージ、タスク定義、ロードバランサーターゲットグループなど、すべてのコンポーネントを自動的に構築できます。新しいユースケースのテストや試行に非常に適していますが、L3 Constructsについて知っておくべき注意点が1つあります：非常に独自の考えが反映されているため、必要な時にL3 Constructから抜け出すのが難しい場合があります。
L3 Constructを活用する際によく見かけるのは、Escape Hatchesのようなより高度なCDK機能を使用しなければならないケースです。これは扱いが難しくなる可能性があります。そのため、パターンの範囲外のことを行う必要がある場合、L3 Constructsの使用は課題となることがあります。つまり、L3 Constructsは、構築したいものが明確で、非常に強い意見を持っているユースケースに特化しているのです。
Constructsの構築パターンと課題
Constructsの構築方法には、いくつかのパターンがあります。プラットフォームエンジニアリングチームは、開発チームやインフラチームが利用できるConstructsのセントラルライブラリを構築しています。プラットフォームチームが強制したい意見やガードレールがすべてConstructsに組み込まれ、それらを組織全体に配布して各チームがダウンロードしてデプロイできるようにしています。もう一つの一般的な方法は、「DRY（Don't Repeat Yourself）」パターンです。例えば、モノレポを使用している場合や、25個のLambda関数を持つCDKアプリを構築している場合、同じコードを何度も書かないように、そのライブラリ内に汎用的なConstructを作成することをお勧めします。また、L2 Constructが利用できない場合に、自分で構築するというユースケースもあります。
選択する方法によって、理解しておくべき影響があります。選択したパスによって、開発者の自律性のレベルが決まります。パターンを中央で管理したい場合、開発者は一般的に自律性が低くなり、定められた標準に従う必要があります。開発者がConstructsの制約から逸脱できない場合、プラットフォームチームが継続的に再構築を行う必要があり、これは開発者に追いつこうとし続けるトレッドミルのような状況となり、課題となることがあります。
Constructsを拡張するという選択肢もあります。例えば、S3 BucketのL2 Constructを拡張することで、誰かが私たちのS3 Bucket Constructを使用するたびに、暗号化が必ず強制されるようにできます。これにより開発者により多くの自律性が与えられます - 開発者は拡張を通じてルールを強制しながら、そのConstructのネイティブ機能を活用して構築できます。さらに、Policy as Codeという方法もあり、開発者が自由に作業できるようにしながら、CDKのデプロイメントとビルドプロセスにポリシーをコードとして強制し、開発者向けのガードレールを決定するルールを作成することができます。
このように、Constructsの構築は時間がかかり、課題も多いことがわかります。Constructsの構築が初めての場合は学習曲線があり、継続的な構築と保守にも課題があります。ここで、Amazon Qが大きな助けとなります。 Amazon Q Developerは、生成AIを活用したコーディングコンパニオンとして機能します。Amazon Q Developerの素晴らしい点は、AWSコンソールで作業中の内容について質問できるだけでなく、IDEでも開発をサポートしてくれることで、より迅速な開発が可能になることです。
Amazon Qを活用したConstruct開発ワークフロー
Amazon Qを使用したConstructの開発ワークフローについてお話ししましょう。ここに示しているのは一般的なソフトウェア開発ライフサイクルです。これはインフラストラクチャの構築や、 クラウドでの構築、アーキテクチャ設計、デザインなど、あらゆる作業に当てはまります。まず計画フェーズでは、何を構築するのか、どのサービスを使用するのかを決める必要があります。これには、ドキュメントの読み込み、計画、準備、アーキテクチャ設計、図式化などが含まれ、ビジネス上の課題を解決するための適切な選択を行うことを確実にします。次に実際の構築フェーズでは、コードを書き、インフラストラクチャを管理し、期待通りに動作するかテストして、望ましい状態になっているかを確認します。デプロイの段階でさまざまな問題が発生し、それらのトラブルシューティングが必要になり、このサイクルが続いていきます。では、CDKでConstructを構築する際に、Amazon Qがどのように役立つのか見ていきましょう。最初のフェーズは計画フェーズです。
Amazon QをIDEで使用する際に重要なのは、プロンプトの準備です。何を構築しようとしているのかを非常に明確にする必要があります。この場合、L1からL2 Constructを構築しようとしているので、Amazon Qに対して自分が何を構築したいのかを非常に明確に伝える必要があります。
これを実現する一つの方法は、設計ガイドラインを提供することです。AWS CDKライブラリには設計ガイドラインがあり、これをQに提供します。さらに、自分独自のガイドラインも追加します。例えば、自社ではデータを保存するものはすべて保存時に暗号化する必要があると決めているとします。そこで、Amazon Qのプロンプトと設計ガイドラインで、すべてのデータは保存時および転送時に暗号化する必要があることを伝えます。設計ガイドラインを用意したら、コード例も提供します。最適な初回レスポンスを得るために、できるだけ多くのコンテキストをQに提供し、目指す最終状態を明確に伝えることが重要です。
これらをローカルワークスペースで共有すると、Qとのやり取りの中で、そのワークスペースのコンテキストを参照し、それを基にConstructを構築する際の判断に活用できます。 この時点で、Qに設計ガイドラインと構築したいものを正確に伝えました。次に、L2や新しいConstructを生成するようQに依頼します。ここで明確にしておきたいのは、Qは完璧ではなく、最初から正しい回答を提供できるとは限らないということです。それでも構いません。適切なガイドラインを提供すれば、近い結果は得られますが、おそらく何度か繰り返しが必要になるでしょう。
Qとの対話には2つの方法があります。チャットで、ワークスペースの内容を渡し、これらのファイルを参照して設計ガイドラインを確認し、特定のタスクを実行するよう依頼する方法です。もう一つは、Q Dev Agentを活用する方法で、これはより自律的にリソースを構築してくれます。結果を承認するか拒否するかを選択するだけで、構築の進捗状況も表示されます。リソースが構築されたら、必ず検証を行ってください。Qとは何度かやり取りを重ねることになりますが、完璧ではないことを理解し、反復的なプロセスになることを認識しておいてください。
コードを作成したら、次はテストを行いたいところですね。CDK diffを実行し、そのConstructを使用するCDKアプリを構築し、そしてテスト環境にデプロイして動作を確認したいと思います。ここでもQが非常に役立ちます。デプロイして何かが上手く動作しない場合、例えばCloudFormationからリソースの構築方法が間違っているというエラーが出た場合でも大丈夫です。Amazon Qに戻ってそのエラーを入力すれば、問題の解決方法を見つけるのを手伝ってくれます。
私は単体テストやドキュメントを書くのが好きではありませんし、本来はやるべきなのですが、それが課題だと認識しています。でも、もうそれも過去の話かもしれません。なぜなら、今はAmazon Qに単体テストを書いてもらうことができるからです。JavaScriptやTypeScript、Pythonなどのプログラミング言語を使用する利点は、その言語用の特定のテストフレームワークを使用した単体テストを書くようQに依頼できることです。また、READMEファイルに入門ガイドやコードのインラインドキュメントを含むドキュメントを作成するよう依頼することもできます。 本日、Amazon Q Developerの新機能として、テスト機能とドキュメント機能も発表されました。Q内で直接テストを呼び出すことができ、テストを自動生成してくれます。
最後は、トラブルシューティングの側面です。実際の環境で運用される段階になると、エラーに遭遇することもあるでしょう。そのエラーをAmazon Qに入力し、対話を重ねて、ラバーダック・プログラミングのように活用してください。エラーを入力すれば、その回答で解決策が得られる可能性が高いです。新しいサービスがリリースされることも覚えておいてください - 今回のre:Inventでも、多くの新しいサービスや機能、そして本当にクールな機能が発表されました。新しいものを実装したい時は、Amazon Qに聞くだけでOKです。そのサービスのドキュメントのコンテキストを与えれば、新しいサービスの構築と統合を支援し、新しいユースケースでの実装方法についてのガイダンスとフィードバックを提供してくれます。コスト、セキュリティの最適化、パフォーマンスについては、そのデータをQに入力して、アシスタントとして活用してください。
Amazon Qを使ったL2 Constructの実践的なデモ
つまり、Constructを構築し、イテレーションを重ねていく中で、構築、計画、トラブルシューティングなど、あらゆる段階でQがサポートしてくれるということです。
さて、ここからが楽しい部分です。Pahudが登壇して、これをリアルタイムで実践するデモをお見せします。ありがとう、Adam。次のデモでは、まだ存在していないものを構築する方法をお見せします。Qを活用してライフサイクル全体を通して進めていきます。Adamが紹介したように、CDK Constructの生成にQを活用します。このデモでは、 OpenSearch Serviceコレクション用のL2 Constructを構築します。もし見逃していた方のために説明すると、Bedrock Knowledge Baseを使用する場合、ベクトルストアなどとしてOpenSearchを使用してKnowledge Baseをプロビジョニングすることになります。これは非常に人気がありますが、現時点ではL2として存在していません。そこで、これから構築していきます。
これは基本的に空のGitリポジトリです。Git initを実行しただけで、中身は何もありません。スケルトンのリポジトリだけの状態です。 今、stack.typescriptとapp.typescriptを含む空のリポジトリができました。中身は何もない、ただの空のリポジトリです。 ここで本当に必要なのは、documentディレクトリを作成してドキュメントをダウンロードすることです。最初のドキュメントは、 CDKチームが管理している公式GitHubリポジトリにあるデザインガイドラインです。CDKリポジトリから直接ダウンロードできます。CDKの設計に関するすべての内容が記載されており、このドキュメントの先頭にこのようなadsネームを1つ付ける必要があります。
2つ目は、あなた独自のパターンです。これは、あなたの好みやデザインパターンになります。markdownドキュメントを作成して、あなたが望む内容を記述します。例えば、この場合、L2 Constructとは何か、そしてサンプルコードを含めたL2 Constructの形を説明するパターンを私は持っています。 例えば、フルのL2 Constructを構築する場合、まずインターフェースを定義し、 そのインターフェース内の内容を決める必要があります。オプションについては、私はoptionsを好んで使用し、コンストラクタについては、例えばフルコンストラクタの場合、 どのような形になるかを考えます。例えば、fromAttributesのようなメソッドを持つべきで、そのコンストラクタを見ると、 このコンストラクタ内でL1リソースを作成する必要があります。そして、resourceやresource nameのような属性を公開する必要があります。
IAM Roleを作成する必要がある場合、定義されていない場合は、最小限の権限でIAM Roleを生成する方法と、それをプライベートなConstructメソッドにする方法を知る必要があります。すべてをそのドキュメントに記載し、my patternsというadsネームを付けます。これで、design guidelinesとmy patternsという2つのドキュメントが揃いました。次は、Amazon Qと対話する時です。今回の課題は：workspaceとdesign guidelines、そしてmy patternsを使って、L1であるOpenSearch Service CFN Collectionに対するL2 ConstructとしてのOpenSearch Services Collectionを構築することです。つまり、L1の上にL2を構築するようQに依頼しているわけです。
これが最初の生成結果ですが、完璧ではないかもしれません。ただ、それは大きな問題ではありません。まだ確認する必要がありますから。例えば、最初の生成を見ると、CDK Resourceを継承するのではなく、Constructを継承しているため、技術的には L1やL2ではなく、インターフェースも実装していません。満足できない場合は、簡単に確認してください。そして、これが 2回目のプロンプトになります：このクラスはCollectionと呼ばれるべきです。
このクラスはICollectionインターフェースを実装する必要があります。つまり、まずICollectionを定義し、そのあとでConstructがそのインターフェースを実装する必要があるということです。これが2回目のコード生成の結果です。見ての通り、かなり期待に近いものになっています。typeを見ると、enumタイプも含まれています。実装を見ると、CDK Resourceを継承し、ICollectionを実装しており、これはまさに私たちが望んでいたものです。コンストラクタを見ると、基本的にコンストラクタ内で1つを作成し、grantReadやgrantWriteのようなヘルパーメソッドも生成されています。私は実際にはコードを1行も書いていません。ただデザインガイドラインとパターンに従い、IDEにコピー＆ペーストしただけです。多少の構文エラーがあるかもしれませんが、慌てる必要はありません。IDEまでスクロールしてそれらのエラーを選択するだけです。
例えば、このケースでは、このドキュメントで実際に定義されていないenum型を使おうとしています。Command+Iを押してインラインモードを起動し、Amazon Qにこのエラーの修正を依頼できます。すると、Amazon Qのインラインモードがこのドキュメントをスキャンして状況を把握し、修正してくれます。このケースでは、型の定義が不足していたため、ドキュメントの先頭にその型を作成して修正してくれます。これは素晴らしい機能です。次に下にスクロールして、他に問題がないか確認してみましょう。ここではCollection にまだ問題が残っています。慌てる必要はありません。VS Codeからエラーメッセージをすべてコピーして、Command+Iでインラインモードを起動し、そのエラーメッセージをAmazon Qに貼り付けるだけです。Amazon Qが問題を理解して修正してくれます。
ここでも、インラインモードを使ってAmazon Qに修正を依頼しています。ごく軽微な構文エラーや小さなエラーの場合は、インラインモードでQを起動して修正してもらいましょう。少し下にスクロールすると、インラインモードが修正してくれます。VS Codeに未解決のエラーがないことを確認してください。それができたら、アプリケーションのエントリーポイントであるFTSに進むことができます。このように、Stackからのライブラリのインポートを正しく行う必要があります。次に、AWS resourceをプロビジョニングするStackを作成する必要があります。例えば、最初のアプローチとしては、おそらく必要のないものをすべて選択して、Command+Iを押してQに修正してもらいます。
可能な場合、Amazon Qは修正を試みますが、期待通りの結果が得られないこともあります。しかし心配する必要はありません。例えば、このケースでは、次のようにStackを宣言します。export class MyStackをgeneral stackから継承させ、Amazon Qに残りを自動補完してもらいましょう。これが私の宣言で、すべてを自動補完してもらいます。
自動補完を見ると、このMyStackで作成されたCollectionがあります。CollectionタイプとMyStackを確認する際は、MyStackがCDKアプリケーションで実行されていることを確認し、すべてのプロパティが自動補完されることを確認します。これは素晴らしいですね。Vector Store用のCollectionを作成したいので、Vector Store用のCollection typeを簡単に選択できます。プロパティも自動生成されます。
IDEですべてが問題なく見えるので、これをデプロイしていきましょう。デプロイの前に認証が必要なので、AWS SSO loginを実行してIdentity Centerで認証を行います。簡単です - AWS SSO loginを実行するだけです。そして、デプロイの前には必ずsynthを実行して、何が起こるのかを確認します。synthの出力を見ると、2つのリソースが作成されています。1つ目はセキュリティポリシー、2つ目はCollectionに依存するCollectionポリシーです。Amazonが AWS Constructの中での依存関係を把握してくれます。最初にポリシーが作成され、その後に実際のCollectionが作成されます。これは素晴らしいですね。依存関係の管理について心配する必要はありません。
デプロイメントについて見ていきましょう。最初にポリシーが作成され、その後にコレクションが作成されます。デプロイメントが完了したら、コンソールで確認してみましょう。まず CloudFormation に移動して全てが正常であることを確認し、次に OpenSearch コンソールに移動してコレクションリストを確認し、 コレクションを検証します。私のコレクションが作成されたので、そのリソースをクリックして全てが正常か確認します。 警告が表示されても慌てる必要はありません。これはまだ最小限の実装だからです。ここからネットワークアクセスやデータセット設定など、 オプショナルな詳細設定を定義していく必要があります。今は、このConstructのコア機能に焦点を当てています。
次に、ドキュメントとテストが必要なので、Amazon Q Developer エージェントの出番です。Amazon Q を開いて、/dev コマンドを使って Dev エージェントを起動します。README マークダウンの更新と全てのユニットテストの生成をお願いしようと思います。今朝、Amazon Q Developer の新機能が発表され、/dev だけでなく、/doc、/test、/review コマンドも利用できるようになり、テストとドキュメント生成がより強力になりました。今回は、コード生成のために /dev を使用します。ここで起こっているのは、Dev エージェントが現在のコードベースをレビューしているということです。私は Collection AWS Construct をきちんと定義し、アプリケーションには MyStack が定義されており、これがコレクションリソースを作成してくれます。エージェントはリポジトリ内の既存のコードとドキュメントを全てレビューし、意図や懸念に対処するプランを提案します。Dev エージェントが既存の README ファイルと私のライブラリのスタックをレビューし、README を更新しようとしているのが分かります。README が変更され、その AWS Construct 用の全てのユニットテストの生成を開始します。
この処理には数分かかる可能性がありますが、ドキュメントとテストが適切に生成されるので、辛抱強く待ちましょう。ここでは異なるパターンについて説明します。Q については、即座に応答があるチャットについて説明しました。最初にコードを生成する際は、ドキュメントを準備し、プロンプトでチャットを起動して生成をトリガーします。IDE での即時的なインラインエラーについては、インラインモードコマンドを使用して修正します。しかし、ドキュメント生成やユニットテスト生成のような複雑な要件については、DEA エージェントや /do、/test などのコマンドを使用してアセットを生成します。これには時間がかかることがあります。
この生成が完了すると、ユニットテストが全て生成されているはずです。 マニフェストリストを確認できます。例えば、README をクリックすると、変更点を示す素晴らしい差分が表示されます。赤い配列が元のバージョンで、緑が追加されたバージョンです。 全ての機能、使用例、メソッド、そこからの開発方法が確認できます。 これは CDK の公式スタイルドキュメントによく似ています。テストを見ると、実際にはコレクションのみを構築しています。 コレクション用のテストケースがいくつか提案されており、これは CDK のベストプラクティスに従った Jest スタイルのユニットテストです。
シンプルに「コードを承認」をクリックするだけで、そのドキュメントと全てのユニットテストが IDE にマージされます。その後、 下にスクロールして全てが問題ないか確認できます。ユニットテストに移動して、IDE で何かエラーが発生していないか確認する必要があります。例えば、ここでいくつかの小さなインポートの問題が見つかり、 下にスクロールして AI を使って修正する必要があります。例えば、これはインポートの問題です。AWS IAM が必要ですが、CDK AWS IAM を使用してインポートしようとしています。コマンド I を使用して修正しようとしても、 期待通りに動作しないことがありますが、大きな問題ではありません。単なるインポートの問題です。 例えば、IAM のインポートについては、AWS IAM を IAM として正しくインポートして修正することができます。
問題がなさそうであれば、単純にユニットテストを実行 すれば、Amazon Qが生成したすべてのテストが実行され、何が起きているのか確認できます。テストはAmazon Qによって自動実行されるわけではないので、自分で実行する必要があります。また、何らかの理由で1、2個のテストが失敗する可能性も高いでしょう。この時点で、多くの開発者はエラーメッセージをそのままコピーしてAmazon Qに「これを修正してください」と尋ねる傾向がありますが、私としては、ユニットテストの内容をしっかりと理解することをお勧めします。何をテストしているのかを把握する必要があります。例えば、このような小さな問題の場合 、OpenSearch Serviceに関するすべての権限、つまり作成や 更新、削除の権限をテストしようとしていますが、現時点ではそこまで必要ないかもしれません。今は核となる機能に焦点を当てましょう。 つまり、テストをシンプルにし、何をテストしているのかを理解し、可能な限り修正を試みるということです。
例えば、この場合は修正して再度実行してみましょう。はい、すべてのテストがパスしました。これで、使用方法や APIリファレンスについての優れたドキュメントが作成され、基本的なユニットテストで 主要な機能がカバーされました。かなり良い状態になったと思います。これは実際に、CDKの設計ガイドラインと私たちの意見を反映した設計方針に従って、デプロイ可能なアプリケーションとして 構築されています。
ここからスタートするのは非常に興味深いと思います。しかも、私はコードを一切書いていません。すべてAmazon Qによって自動生成されたものです。とはいえ、何を構築しているのかを理解することは依然として重要です。Qは私たちを支援するためにあるのですが、ご覧の通り、行ったり来たりの試行錯誤が必要な場面もありました。最初から完璧というわけにはいきません。そのため、CDKの概念を理解し学び続けることは重要ですが、開発のスピードを上げるためにQを活用することができます。
CDK開発の今後と関連リソースの紹介
Pahudが何もない状態からL1を基にしたL2 Constructを作成し、テストとドキュメントまで備えた状態にするまでが、わずか20分程度だったことを考えると、これは本当に驚くべきことです。プロセスを経る必要はありますが、ご覧の通り、Qの助けによってより速く目標に到達できました。ここで強調したいことが2つあります。まず第一に、どんどんConstructを作成し、CDKを活用してください。先ほど申し上げたように、コミュニティは大きく活発です。CDKについて話し合い、助け合いたいと考えている人がたくさんいます。また、AWSのCDKチームも支援を惜しみません。
問題が発生した場合や新機能の要望がある場合は、CDKのGitHubリポジトリにIssueを提出してください。あなたが直面している問題を教えてください。私たちは、皆さんがAWSで成功し、CDKで良い経験を得られることを望んでいます。そして、それをより良くするために改善を続けています。さしあたって、Pahudのデモから学べる重要な点が2つあります。1つ目は、このトークの直後にローンチする予定のリポジトリに含まれる彼のガイドラインです。これを参考に、自分たちのガイドラインを作成してください。これを、ユースケースに応じたガイドラインを定義する際の指針として活用してください。2つ目は、CDKのGitHubリポジトリです。そこから設計ガイドラインを参照してください。これらのガイドラインは、日々これらを構築しているCDKチームによって維持・管理されているものです。
コンストラクトを公開する方法はいくつかあります。メインのAWS CDKライブラリに貢献することもできますし、新しいL2コンストラクトをテストしてコミュニティの反応を見たい場合は、Construct Hubに公開することができます。constructs.devにアクセスすれば、コミュニティが作成したコンストラクトをすべて確認でき、コンストラクトを構築する際にコミュニティからフィードバックを得る手段として活用できます。また、AWS CDKライブラリ以外のコンストラクトを活用したい場合は、AWS Solutions Constructsがあります。これはAWSのSolutions Architectsによって構築されたもので、常にお客様と接している現場のエキスパートたちが、お客様が実際に使用しているパターンやコンストラクトを作成しています。
また、Open Construct Foundationもあります。これはAWSとは別の財団で、CDKに情熱を持って取り組んでいます。CDKのリーダーたちが運営しており、独自のコンストラクトライブラリを持っています。皆さんが作ったものをぜひ私たちと共有してください。こちらが私たちのソーシャルメディアのプロフィールです。私へは Blueskyで、Pahudさんも Blueskyを使っています。スライドには載せていませんが、PahudさんへはXでも連絡できます。YouTubeチャンネルもあり、CDK Liveでは基本的な概念からCDKの基礎的な内容まで扱っています。今年後半は何も投稿していませんが、2025年からはより多くのコンテンツの制作を始める予定です。Pahudさんのチャンネルもチェックしてください。Pahudさんは素晴らしいコンテンツを配信していますので、ぜひフォローしてください。以上です。本日はご参加いただき、ありがとうございました。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion