re:Invent 2023: Buy with PrimeがAWS CDKでアーキテクチャをスケール化した方法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Construct your constructs: Use AWS CDK to create architecture at scale (BWP302)
この動画では、Buy with PrimeがAWS CDKを活用してアーキテクチャをスケールアップした方法を紹介します。StephenとJoseph、Madhavが、eコマースの課題に対するBuy with Primeの革新的なアプローチを解説します。AWS CDKを使ったインフラストラクチャのコード化、カスタムコンストラクトの作成、そして50年以上の開発時間を節約した戦略について、具体的な例を交えながら詳しく説明します。エンジニアリングの効率化に興味がある方は必見のセッションです。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Buy with Prime 302: AWS CDKを活用したアーキテクチャのスケールアップ
はい、皆さん、Buy with Prime 302へようこそ。もし間違ったセッションに来てしまったとしても、心配しないでください。私も以前そういう経験がありますから。ドアは機能していますよ。私たちは、Buy with PrimeがAWS CDKを活用してアーキテクチャをスケールアップして展開した方法をお話しできることを楽しみにしています。私はStephenです。こちらはJosephとMadhavです。皆さんは、組織がどのようにAWS CDKを活用して時間を節約し、繰り返しのアーキテクチャ決定を減らし、新しいシステムを展開する際の開発者の自信を高めることができるかを本当に理解したいと思っていらっしゃるのですね。今日は皆さんと共有できることを本当に楽しみにしています。皆さんが時間を割いてくださったことを光栄に思います。それでは、始めましょう。
まず、今日の旅路の概要をお話しします。最初に、Buy with Primeとは何か、Buy with Primeの状況がなぜAWS CDKの使用を必要としたのかを紹介します。これにより、ビジネスの観点からCDKがどのように私たちに影響を与えるかを理解できます。次にJosephが登壇し、Buy with Prime内でCDKが実際にどのように機能していたかについて、パイプラインの例やサービスの展開方法などを含めて詳しく説明します。そしてアーキテクチャ図もいくつか見ていきます。最後に、Madhavが登壇し、さらに一歩踏み込んで、コードスニペットやコンストラクトの例をいくつか紹介し、皆さんの組織で同じことができるようになるためのツールを提供したいと思います。
そのテーマに沿って、GitHubリポジトリも用意しました。セッションの最後に広く公開され、閲覧可能になります。QRコードをお見逃しなく。本当に楽しみにしています。最後に、結論として、Q&Aの時間も設けたいと思っています。もし時間切れになった場合は、外でお会いしてお話しできればと思います。それでは、Buy with Primeの紹介に入りましょう。
Buy with Primeの概要とeコマースへの影響
Buy with Primeは、何百万人ものPrimeメンバーが、Amazonで期待するのと同じ信頼できる体験で、加盟店のストアで買い物ができるようにするサービスです。加盟店は、 JavaScriptのコードスニペットを追加するだけで、商品詳細ページに直接Buy with Primeを追加できます。これにより、このボタンと配送予定日がページに直接表示されます。また、Shopify加盟店の場合は、MarketplaceでShopifyアプリをインストールすることもできます。より高度な統合のために、加盟店が自社のアーキテクチャの決定を理解したり柔軟に対応したりできるよう、APIやイベントの数を増やしています。
eコマースの世界では、多くの加盟店がそれぞれ異なるユースケース、アーキテクチャの決定、レガシーな決定、技術的負債などを抱えていることを私たちは知っています。Buy with Primeは、お客様である加盟店の現状に合わせたいと考えています。そのため、コンポーザブルなアーキテクチャがこれらの興味深い統合を可能にしたことを共有できることを本当に嬉しく思います。つまり、ページやボタン、配送の約束を表示するだけでなく、単なる高速チェックアウトボタンではなく、Primeメンバーがよく知っている迅速な無料配送と簡単な返品を含む注文後の体験も提供しているのです。
これは加盟店のビジネスにとってゲームチェンジャーです。Amazon上でPrimeメンバーが受けるのと同じPrimeの特典を、今や提供できるようになったのです。そして注目すべきは、Buy with Primeによってショッパーのコンバージョンが平均25%、そう25%も増加することが示されているのです。eコマース業界の方々なら、コンバージョンが大きな推進力であることをご存知でしょう。この数字を経験した加盟店は本当に喜んでおり、私たちもこの数字に大変励まされ、わくわくしています。
Buy with Primeのアーキテクチャと複雑なサービス構成
しかし、これらすべてを可能にするためには、配送予定日を出し、注文を作成し、さまざまなシステムと連携して表示する必要があります。そのため、非常に興味深いアーキテクチャの構図が生まれ、それについてもう少し深く掘り下げる必要があります。では、この注文画面の裏側にあるものを見てみましょう。まず明らかなのは、サービスです。Amazonでサービスについて考える際、私たちはサービスメッシュフレームワークを非常に意識しています。
最初に明らかなのは、order serviceです。order serviceは、誰が何をいつ、どれだけの量買ったかということに非常に関心があります。そのための状態マシンである必要があります。例えば、先ほどMikeに会って、最近エナジードリンクを買ったと聞きました。もし私がMikeだとして、エナジードリンクを買うと、11月29日の1時34分にMikeがエナジードリンクを買ったという注文が作成されます。order serviceはこのような情報を非常に正確に扱い、ショッパーの情報を非常に安全な方法で保存する必要があります。
しかし、実際に商品を発送しなければ、注文も意味がありません。 Buy with PrimeはAmazonのmulti-channel fulfillmentサービスを活用して注文を発送します。
つまり、Amazon.comで何かを購入する際に利用するのと同じAmazonのフルフィルメントネットワークを使用しているのです。「この日までに届く」という小さな配送日表示を行うためには、在庫や、その商品がフルフィルメントセンターのどこにあるかなど、多くの複雑な計算が必要です。Amazon.comで同じことを表示する際のすべてのコアロジックを、Buy with PrimeはAmazonのサービス上にカスタム統合を構築して、加盟店が自社サイトで同じ配送予定日を表示できるようにしなければなりませんでした。
それ以上に、私たちが何を販売しているのかわからなければ何もできません。そのため、プロダクトカタログは、Mikeのエナジードリンクを保存できるほど柔軟である必要がありますが、私の靴も同様です。サイズの見積もりや製品属性が大きく異なります。非常に柔軟なプロダクトカタログが必要です。そして最後に、eコマースの分野では、決済から逃れることはできません。FinTech業界の方々の中にはご存知の方もいるかもしれませんが、決済は非常に複雑な世界で、決済プロセッサー、銀行、規制など、多くのプレイヤーが存在し、Buy with Primeもこれらに対応する必要があります。
これら4つの領域は非常に異なります。注文ステートマシン、配送日計算、商品の所在地と顧客への配送速度の把握。そしてそれだけでなく、商品詳細ページで表示する内容に自信を持てるよう、迅速に行う必要があります。これはPrimeメンバー体験の重要な部分であり、商品がいつ到着するかを知ることです。これを実現するために、マイクロサービスの考え方に従い、サービス境界を作成しています。そうすることで、注文サービスはカタログがどのようなアーキテクチャを持っているか、または顧客がどの支払い方法を選択したかを気にする必要がありません。他のサービスに関係なく、そのコアモデルは同じです。
これを各サービスに適用することで、真の関心の分離を実現できます。正直なところ、これら4つのサービスだけでなく、もっと多くのサービスがあります。ここには他のサービスのサンプルサイズを示していますが、これ以上にもっとあります。PowerPointの制限により、全体を見せることはできませんが、非常に複雑になることは想像できるでしょう。そして繰り返しになりますが、技術的な話ではありませんが、サービス間にはネットワークがあり、非常に柔軟なeコマースアーキテクチャを実現しています。なぜなら、私たちは加盟店、つまり顧客のところに行きたいからです。
そのためには、彼らの要件に基づいて柔軟に変更できる必要があり、「ああ、この加盟店は私たちが考えていなかったユースケースを実現する必要がある」と言えるようにしなければなりません。この会場にいる皆さんの中にも、顧客のニーズに応えるために変化する要件セットを持っている方がいると想像します。実際、AWS CDKは、顧客のニーズに応えられるアーキテクチャを作成する力を与えてくれました。では、JDがステージに上がり、注文サービスの例を通して、CDKがどのようにしてサービスだけでなくパイプラインの構築にも使用され、それらを通じてどのようなメリットが得られるかを説明します。
サンプル注文アーキテクチャの詳細解説
いいですね。ありがとう、Stephen。さて、始めましょう。サンプルの注文アーキテクチャを見てみましょう。これはあくまで例ですが、ここに示されている多くのAWSサービスを実際に活用しています。おそらく、このアーキテクチャを見たことがあるでしょう。キャリアを始めたばかりの頃、3層アーキテクチャの作り方をGoogle検索したときや、A Cloud Guruを通じてかもしれません。私たちは皆、そういう経験をしてきました。私も確かにそうでした。正直なところ、今でもそうしています。
Stephenが言及したように、ordersのようなサービスを構築する際には多くのコンポーネントと複雑さがあります。ordersだけでなく、すべてのサービスが高可用性、スケーラビリティ、セキュリティなどを確保するために、エンジニアリングチームによって慎重に設計されています。そのため、私がどんなに欲しくても、あなたの注文が私の住所に届くことはありません。さて、アーキテクチャの最初のレイヤー、APIレイヤー、つまり私の言葉で言えば「クラブの入り口」を見てみましょう。この入り口には、AWS WAFとAWS Shieldという最高のバウンサーとセキュリティガードがいます。また、Amazon Route 53という素晴らしいホストもいます。このレイヤーでは、APIのアクセス制御と保護のためのVIPリストも設定できます。
あなたの注文リクエストが来て、チェックインし、私がここラスベガスでは通らないような雰囲気チェックを通過したら、パーティー、つまりコンピュートレイヤーへようこそ。クラブと同じように、ここは他の人々、つまり私たちの場合は他のサービスと出会い、交流するチャンスです。catalogがcontentと話し、deliveryがfulfillmentと話し、paymentsがダンスフロアでcha-chingを踊っているようなものです。
インフラストラクチャについて言えば、私たちはAWS Fargateを使用しています。なぜなら、サーバーを管理することなくコンテナを使用し、実行できるからです。Yuvalという賢明なマネージャーが私に「友人にサーバー管理をさせてはいけない」と言ったことがあります。クラブの例に戻ると、一般的に特定のタスクや仕事があります。そう、これはFargateの言葉遊びです。ダンスフロアに行くにせよ、バーに行くにせよ、人と話すにせよ、注文リクエストも同様です。電話番号を取得するにせよ、deliveryサービスから配送や住所を取得するにせよ、paymentsからクレジットカード情報を取得するにせよ、タスクがあるのです。
情報を取得したら、それを保存する必要があります。これが最後のレイヤー、私のお気に入りのレイヤー、データレイヤーにつながります。ここで情報が安全かつ確実に保存され、取り出されます。Amazon DynamoDB、Amazon RDS、Amazon ElastiCache、そして予算が潤沢な場合は他のオプションもあります。ここには特別なものはありません。SQLやNoSQLクエリの経験は誰にでもあると思います。
さて、話を戻しましょう。私たちは、適切に設計された分散型のorderサービスを確保する必要があります。繰り返しますが、これはordersだけではありません。すべてのサービスが同じルールに従い、あなたの注文の履行に参加します。しかし、エンジニアリングの決定と開発はそこで止まりません。サービスが顧客のニーズを満たすことを確実にするために、私たちはBuy with Primeのための堅牢なパイプラインを構築しました。
Buy with Primeのパイプラインと各ステージの役割
さて、このプレゼンテーションの性質上、シンプルに保ち、パイプラインの一般的なステージをご案内します。ただし、Buy with Primeのパイプラインについてもっと知りたい方は、本日午後4時に行われる301セッションをチェックすることをお勧めします。そこでは本当にクールな内容が紹介されますので、ハッピーアワーで学んだことを共有できますよ。これはwin-winだと思います。
では、話を戻しましょう。各ステージを詳しく見ていきましょう。まず、sourceステージから始まります。これは開発者のハブで、開発者たちが一緒に魔法を起こすために生活し、呼吸し、コーディングを行う場所です。ここでは、マージ、プル、プッシュといった、私たちのコーディングの旅を定義するキーワードが飛び交います。 コードが完成したら、buildステージに入ります。ここでは筋肉を付けるわけではありませんが、テストの自動化、必要なツールのダウンロード、コンパイル、パッケージングを行います。これは、コードの行をデプロイ可能なサービスに変換するパワーハウスステージです。
コードがbuildステージをクリアすると、pre-productionステージに入ります。このステージでは、アプリケーションの微調整、品質基準の確保、実際のパフォーマンスの確認ができます。これは、本番デビューの夜に自身のコードでつまずかないようにする機会です。最後に、コンセプトから現実へ、真実の瞬間、 productionステージです。ここで、すべての努力、イノベーション、そして献身が形になります。システム設計、インフラ、深夜0時のSlackの通知音、却下されたコードレビュー、そしてマージされた多くのリクエスト。これらすべての努力が報われ、サービスがユーザーに公開される瞬間です。
これでパイプラインのセクションは終わりです。 ここで少し振り返ってみましょう。最初に、サンプルのオーダーアーキテクチャを見て、共通のコアサービスを共有し、層を剥がすように見ていきました。次に、私たちの運用の心臓部であるパイプラインにズームインし、サービスをデプロイするために必要な一般的なステージを共有しました。これら2つのモデル、つまりWell-Architected Frameworksを組み合わせることで、本質的に素晴らしいサービスを作り上げました。しかし、ここには何か非常に重要なものが欠けています。
CDKを活用した効率的な開発とクロスファンクショナルチームの形成
それは、実際の開発と実装の部分です。 魔法が起こるのは、私たちが袖をまくり上げて開発を始めるときです。これら2つのモデルのためにコードを書くのは簡単ではありません。先ほど述べたように、IDEを開き、コードを書き、テストし、デバッグし、数え切れないほどのログ情報ステートメントを書くことから始まり、時間と努力が必要です。ブルーライトカットメガネを経費で購入したり、人生の危機を一度や二度経験したり、手根管症候群になったりすることさえあるかもしれません。これら2つのモデルのための開発は複雑で、チーム全体の努力が必要です。
通常、私たちの開発者はCDKを使ってインフラストラクチャをコードとして記述しています。これは、テストやパイプラインとの統合、プログラミング言語の柔軟性など、使いやすさの面で私たち全員に高く評価されています。C#で書くのが好きな方がいらっしゃるなら、敬意を表します。今日の講義では、CloudFormationのスペースやYAMLのエラーについては触れないでおきましょう。
少し状況を説明させてください。私たちには、インフラストラクチャとそのパイプラインを構築する専任のサービスチームが1つあります。 ここで、100チームや1000チームがあると想像してみてください。これは難しくなりますよね？似たようなアーキテクチャの構築、オンボーディング、学習、知識移転に費やされる時間を考えてみてください。Buy with Primeが成長を続けるにつれて、私たちはスケールアップし、迅速にデプロイする方法が必要になりました。既存のサービスが多数あり、新しいサービスも拡大していたため、構築するインフラストラクチャが他のサービスやチームでも再利用できることを確認する必要がありました。
私たちが行ったことは次の通りです。開発者が自分のサービスを最もよく知っているという前提で、Platform as a Service（PaaS）チームにサービスを構築させるのではなく、 それらのサービスチームから個々のメンバーを集めて、クロスファンクショナルなCDKチームを作りました。 この夢のチームは、さまざまなサービスバックグラウンドを持つエンジニアで構成され、Buy with PrimeのCDKベストプラクティスコンストラクトを集めたリポジトリを協力して作成する責任を負っていました。
その影響は絶大でした。このメンテナンスされているリポジトリは、さまざまなサービスやチームで使用されています。これにより、インフラストラクチャをプロビジョニングするサービスのデプロイ方法が標準化されました。この考え方により、開発者はインフラストラクチャの構築を心配することなく、優れたサービスや製品の構築に集中できるようになりました。 この戦略により、合計50年分のエンジニアリング工数を節約することができました。この数字を覚えておいてください。
それでは、私たちの技術の達人であり、私の技術的な兄弟でもあるMadhavに引き継ぎます。MadhavがCDKコンストラクトについて詳しく説明してくれます。どうぞ、Madhav。
CDKの重要概念とカスタムコンストラクトの構築
ありがとうございます、JD。この分野横断的なチームがどのように戦略を立てたかを見る前に、彼らが使用したCDKの重要な概念のいくつかを詳しく見ていきましょう。 CDKと聞くと、すぐにAWS Construct Libraryを思い浮かべますね。このライブラリには、一般的にAWSサービスを表す基本的なconstructが含まれています。 ご存知の通り、AWSサービスはかなり多いので、ここにもたくさんのconstructがあります。
このライブラリは出発点ですが、主な利点の一つは、これらのサービスを組み合わせて複雑なアーキテクチャを作成し、ニーズを満たすことができる点です。例えば、ネットワーク設定、データベースクラスター、さらには先ほどの3層アーキテクチャなどが挙げられます。Constructは一般的に3つの異なるレイヤーに分かれています。これらの各レイヤーについて簡単に説明していきましょう。
レイヤー1のconstructは、CloudFormationリソース仕様から自動生成されます。これらのリソースはAWSサービスに紐づいており、1対1のマッピングを提供します。
例えば、シンプルなAmazon S3バケットがこれに当たります。 さらに一歩進めて、レイヤー2のリソースは、より高度なサービスconstructと呼ばれるものです。これらのconstructは複数の異なるAWSリソースを表しますが、依然として1つの特定のAWSサービスに紐づいています。また、ユースケースに役立つ様々な推奨デフォルト設定が組み込まれています。先ほどの例で言えば、シンプルなS3バケットがありました。これをレイヤー2のconstructにするには、暗号化やアクセスログなどのデフォルト設定を追加します。
では、レイヤー3のconstructについて説明しましょう。これらは3つの異なるソースによって作成される抽象化です：AWS Construct Library、自身とプライベートライブラリ、またはコミュニティからのサードパーティです。このレベルでは、ユニークな問題を解決するための抽象化が作成されます。先ほどのS3バケットを例にとると、CloudFront distributionのソースにすることで、レイヤー3のconstructにすることができます。組織の戦略は、ユニークなニーズを解決するために、これらの異なるレイヤーを組み合わせて構成されます。Buy with Primeでは、デフォルト設定がベストプラクティスを提供し、それらを強制するのに役立つと考えたため、使用するすべてのAWS constructを共通のリポジトリに集め、そこに強制的なベストプラクティスを設定することにしました。
これらの原則について詳しく説明する前に、いくつか強調したいポイントがあります。まず、「opinionated defaults」という言葉をよく使います。これは単に、Buy with Primeで考慮したベストプラクティスを意味します。これがあなたのベストプラクティスである必要はありません。今日の目標は、Buy with Primeの事例を紹介し、それを出発点として、皆さんが独自のユースケースや組織のニーズを特定するのを支援することです。これを基に、独自の組織戦略を構築できることを願っています。次に、このセッションではコードが多く出てくるので、少しゆっくりとしたペースで進めていきます。
先ほどのサービスアーキテクチャをもう一度見てみましょう。JDが言及したように、ここには再利用可能なコンポーネントがたくさんあります。注文や支払いなど、私たちの様々なアーキテクチャは、これらのサービスの多くを共通して使用できます。では、これらのコンストラクトの1つを詳しく見て、カスタムコンストラクトを構築するには何が必要かを見ていきましょう。特に、JDのお気に入りであるデータベース層、この場合はAmazon DynamoDBから始めましょう。データベースに関しては、対処すべき多くの懸念事項があります。幸いなことに、CDKは私たちのデータベースに様々なデフォルト設定を行う能力を提供してくれます。
今日特に注目したいのは、セキュリティと運用に関連する部分です。主に、これらがどの組織にとっても非常に重要だからです。そこで、課金と暗号化に焦点を当てていきましょう。 DynamoDBのカスタムコンストラクトクラスを作成する例から始めます。この例ではTypeScriptを使用します。CDKは現在、Java、JavaScript、Python、その他多くの一般的なプログラミング言語で利用可能です。個人的に、私はJavaの大ファンです。そう、コーヒーのことも含めてです。ですので、ここではゆっくりとしたペースで進めていきます。
では、コンストラクトクラスを定義していきましょう。このコンストラクトクラスは、DynamoDBテーブルをプロビジョニングするのに役立ち、注文、支払い、課金など、どのサービスチームからも使用されます。このコードが何をしているのか、詳しく見ていきましょう。まず最初に行うのは、AWS CDK DynamoDBテーブルコンストラクトをインポートすることです。これが、カスタムコンストラクトクラスで他のすべてのコンストラクトを構築するための基礎となります。
それができたら、コンストラクトクラスを定義できます。このコンストラクトクラスはCDKコンストラクトを拡張し、それによってAWS CDKから得られるすべてのデフォルトを使用できるようになります。次に、コンストラクタメソッドをオーバーライドできます。そうすることで、これを使用するサービスチームは、デフォルトのDynamoDBデフォルトの拡張 を渡すことになります。これがここに表示されているDynamoDBプロパティです。そのプロパティのセットを持ったら、組み込みのベストプラクティスをすべて含む別の更新プロパティのセットを作成できます。
ここで一旦立ち止まって、これがレイヤー1のコンストラクトであることを説明したいと思います。これは、このカスタムコンストラクトのインスタンスをプロビジョニングするサービスチームは、組み込みのデフォルト設定なしでDynamoDBテーブルを作成することを意味します。「それって実際にどんなメリットがあるの？なぜAWS CDKを使わないの？」と思う方もいるかもしれません。そのとおりです。これを有益なものにするには、レイヤー2のコンストラクトに変換する必要があります。そのためには、コンストラクタにすべてのカスタムロジックを追加します。
DynamoDBとFargateのカスタムコンストラクト実装例
先ほど述べたように、今回は課金モードと暗号化に焦点を当てます。これは多くのコードに見えるかもしれませんが、心配しないでください。これらはすべてGitHubリポジトリで利用可能です。最後にQRコードを表示しますし、質問にもお答えします。では、上から順に見ていきましょう。サービスチームがCDKでサポートされているデフォルト値を渡せるようにし、それらのデフォルト値を選択できるようにしています。この場合、課金モードと暗号化の属性を取り、それらをカスタムロジックに使用しています。
まず、課金から始めましょう。Buy with Primeがシステムを構築してテストしていた際、必要に応じてスケールアウトできるようにしながら、コストを抑えて節約する能力も欲しいと考えました。組織として、デフォルトの課金モードをpay-per-request（オンデマンドモード）にするのが理にかなっていました。とはいえ、サービスチームがプロビジョンドモードを使用することをブロックしたくありませんでした。ユースケースで本当に必要な場合、プロビジョンドモードに関する我々の見解は、最小の読み取りおよび書き込み容量を設定すべきですが、システムリソースの制限によってお客様がサービス停止を経験することを避けるため、最大の読み取りおよび書き込み容量は設定すべきではないというものでした。
次に、別の例である暗号化を見てみましょう。暗号化について、DynamoDBはAWS所有のキーを使用しますが、これはDynamoDBサービスが所有しています。これは保存時の暗号化を提供しますが、悪意のある行為者がDynamoDBサービスにアクセスすると、顧客コンテンツにアクセスできてしまい、これは私たちにとって受け入れられませんでした。これに対処するため、デフォルトでカスタマー管理キーを使用することを好みます。DynamoDBには、暗号化属性がカスタマー管理キーに設定されているが提供されていない場合、自動的に作成する機能もあります。ただし、KMSキーには追加コストがかかります。そのため、ここでもサービスチームが別のオプションを使用することをブロックしたくありませんでした。代わりに、Joseph Decenaが先ほど述べたように、潜在的に安全でない設定にフラグを立てるようにパイプラインを設定しています。
更新されたプロパティのセットを作成し、それを使用してDynamoDBテーブルのインスタンスを作成します。これはレイヤー2のコンストラクトであり、これを使用するサービスチームは、デフォルトでpay-per-request（オンデマンドモード）の課金とカスタマー管理キーを持つことになります。通常のCDKコンストラクトに対して提供する基本的なCDKデフォルトのみを提供すれば良いのです。
必要なのは、これのカスタムインスタンスを作成することだけです。標準化を加えることで、セキュリティチームはもはやデフォルトの属性を気にする必要がなくなります。代わりに、サービスチームによって更新された属性だけを確認すればよいのです。ここで少し立ち止まって考えてみましょう。これを今日ご覧いただいているこれらのコンストラクトすべてに適用したら、どれほどの時間とコストの節約になるでしょうか。
レイヤー3のコンストラクトを見てみましょう。具体的には AWS Fargate です。Fargate の前には通常、ロードバランサーが配置されます。Application Load Balancer か Network Load Balancer のいずれかです。私たちの特定のユースケースでは両方を使用していますが、今日は Network Load Balancer と AWS Fargate の統合に焦点を当てます。Network Load Balancer が Fargate とどのように統合されるかを検討し、Network Load Balancer を通過するリクエストが確実に Amazon CloudWatch を使用してログに記録されるようにするカスタムリレーを作成します。
リレーの作成には多くのコードが必要ですが、Stephen が先ほど述べたように、PowerPoint はコードの可視化ツールとしては最適ではありません。そこで、より高レベルの擬似コードを使用します。完全な例については、プレゼンテーションの最後にある QR コード のリンク先 GitHub リポジトリをご参照ください。この例では、まず AWS CDK から基本的な ECS パターンをインポートします。これがコンストラクトとデフォルトを構築するための基礎となります。次に、Fargate との統合のために特別に作成されたカスタム JLB リレーを定義します。最後に、Construct クラスを拡張し、ニーズを満たすために使用しているリソースのコンポジションである Fargate クラスタークラスを作成します。
ここでデフォルトを追加するプロセスは、DynamoDB の例と似ています。コンストラクターを定義し、オーバーライドして、デフォルトの Fargate プロパティを取り込みます。コンストラクター内で、カスタムリレーを定義し、サービスチームによって渡された他のプロパティと共に更新されたプロパティに設定し、クラスターを初期化します。
ここで、簡単な話をさせてください。Amazon CloudWatch がリリースされたとき、私たちのサービスチームはそれを使用することに興奮していました。クロスファンクショナルな CDK チームが集まり、1週間以内に私たちが望むすべての設定を特定しました。彼らはこのためのカスタムコンストラクトを作成し、Fargate を含む多くのコンストラクトクラスと統合しました。今では、サービスチームがこのコンストラクトのインスタンスをプロビジョニングする必要がある場合、そのプロセスは1日未満で済み、約6日間の時間を節約できます。これを10チームに拡大すると、コスト削減は約2ヶ月分になります。
Amazonの規模で考えると、このモデルを使用することで50年以上の開発時間を節約できたと推定しています。
確かに大きな数字に聞こえますが、これまで話してきた様々なサービスと、それらに必要な多くのチームのことを考えてみてください。このメソッドを使えば、皆さんの組織でも同様の時間節約が可能になると期待しています。
まとめと関連セッションの紹介
さて、約束通り、こちらがGitHubリポジトリのQRコードです。多くのAWS constructsの例や、それらの説明ドキュメントが含まれています。組織戦略を立てる上で、きっと役立つはずです。ありがとうございました。
わあ、すごい。私が登壇したことに拍手をいただき、ありがとうございます。本当に感謝します。これは全て私の功績です。冗談ですよ。でも、あのリポジトリは本当におすすめです。Madhavが素晴らしい仕事をしてくれました。PowerPointのテキスト編集の制限を受けない、非常に具体的な例がたくさんあります。まだ利用可能ですので、ご心配なく。
ここで、私たちが話し合ったことを振り返ってみましょう。Buy with Primeの紹介から始まり、eコマースの現状を理解し、商人への影響を見ました。とてもエキサイティングでしたね。そして、AWS CDKを使って、アーキテクチャだけでなくパイプラインもどのようにデプロイするかについて詳しく説明しました。最後に、Madhavが layer three constructsの実際の構築方法を説明し、これらの節約を実現する方法を示してくれました。
会社の規模によっては、同じ50年の経験を積むことはできないかもしれません。しかし、これらの構築原則を使えば、自分自身や他の人のために時間を節約できることをお約束します。重複や繰り返しのあるアーキテクチャの決定を減らせます。一度決めたら、これらのデフォルトを好んで使い、先に進むのです。そして最後に、開発者の自信を高めることができます。誰かが構築したパイプラインがあるのです。サービス開発者として、私はサービスをいかに速く作れるかを気にしています。DynamoDBの細かいことを毎回考えたくはありません。DynamoDBチームの方がいたらすみません。DynamoDBは大好きですが、サービスを構築するたびにそれについて考えたくはないのです。そしてそれは非常に重要なことです。
さて、ここまで来ました。このセクションでは、他のセッションを紹介し、その後Q&Aに入り、彼らを呼び戻します。先ほど言及したように、他のBuy with Primeのセッションがあります。興味がある方は、実は20分後に別のセッションが始まります。立ち上がって行っても気分を害しませんよ。Amazon Bedrockを使って生成AIをBuy with PrimeのAPIに対して立ち上げる例があります。これも、お客様のいる場所で対応するという観点からのものです。ぜひお勧めします。部屋番号を確認してください。変更されているかもしれません。
そして、本日午後4時からMGM Grandで、Buy with Primeが探求している他の素晴らしい取り組みについてさらに掘り下げます。パイプラインや、すべてが円滑に動作するようにするためのコンセプトについてです。Buy with Primeとビジネスを行うことに興味がある方は、商人としてもパートナーとしても、ぜひinterest listをチェックしてください。心配しないでください、このQRコードをステージに再度表示します。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion