はじめに
本稿は、AWS CDK Advent Calendar 2023 14日目の記事です。
re:Invent現地参加組の佐藤智樹です。今回はre:Inventで行われていたセッション「Construct your constructs: Use AWS CDK to create architecture at scale」についてレポートします。
タイトルには出てこないのですが、この発表自体はAmazonが開発している「Buy with Prime」というサービスの裏側について話されているものでした。Buy with Primeは、オンライン小売業者が自社のウェブサイトで商品を販売する際にAmazonの配送ネットワークを利用できるサービスです。Amazonプライム会員は加盟店でAmazonプライムの無料配送や返品などの特典を受けることができます。詳細は以下をご覧ください。
サービス自体は日本で提供されていないので馴染みはなかったのですが、裏側で横断的なCDK専門チームを作って大規模なマイクロサービスの構築を効率よく行えたという話があったので今回記事にしました。本稿では、技術的な内容を中心に絞ってご紹介します。
動画
参考コード
紹介の中で実際にサービス開発で使われたCDK Constructが公開されていたのでこちらに記載します。service-constructsにConstructの実装があって実装のドキュメントがdocumentationに記載されています。今後Constructを組織で作って配布などを考えている組織で参考になりそうです。
登壇者
- Madhuv Gupta: Solution Architect(Buy with Prime)
- Joseph Decena: Solution Architect(Buy with Prime)
- Stephen Godderidge: Solution Architect(Buy with Prime)
内容
前半は、Buy with Primeとは何なのか、その後にCDKチームと実装の説明でした。主に後半部分について深く掘り下げていきます。
Buy with Primeについて
Buy with Prime自体は、小売の加盟店が所属することで画面のようにPrimeボタンを配置でき、Amazonで購入するのと同じ体験で商品を購入することが出来ます。この機能により、コンバージョン率が平均25%上昇したそうです。筆者はデジタルマーケティングに詳しくないですが、調べた限り脅威的な上昇率なので、機能としてかなり成功しているサービスと言えそうです。
ただ上記のサービスにも裏側に配送やオーダー、カタログ、支払いなど様々な機能が必要になります。これら複数のマイクロサービスやデプロイのためのパイプラインを構築する上でCDKが非常に役に立ったと話されていました。
インフラ構成について
まずOrdersサービスのアーキテクチャ紹介から始まりました。サービスでは、セキュリティ要件を満たすためにShiledやWAFなどが必要になり、Route53やCloudFrontなども必要になります。それ以外にもECSやRDSなどサービスを実行するために複数のAWSサービスが必要になります。
またそれ以外にもパイプラインが必要になります。パイプラインの詳細は以下のセッションで語られています。
上記は1つのサービスの話でしたが、実際は100や1000のマイクロサービスがあり、それぞれのチームがあります。それぞれのチームが、CDKやパイプラインを構築すると学習や知識の伝達などにどれほどの時間が費やされるか想像してみてください。Buy with Primeはサービス拡大のため柔軟に拡張できるようにインフラ構成が再利用可能である必要がありました。
そこで、彼らは複数のサービスのチームから人を集めてCross-functional-CDK-teamを結成しました。このチームは各サービスからの知見を集約してベストプラクティスとなるリポジトリを構成する使命を受けました。これにより開発者はインフラの心配をすることなく、優れたサービスと製品の構築に集中できます。
これはまさにAWSが以前ホワイトペーパーで出していた、プラットフォームチームをCDKで実現する具体例だと感じました。(以下参考）
戦略によって、エンジニアの時間を50年分削減できたと話されていました。流石に盛りすぎに感じましたが、最後に数字について補足がありました。
CDK構成の詳細
最初はConstruct Libraryの話から始まりL1~L3 Constructの話に続きます。ここは一般的な紹介だったので割愛します。もしご存知でない場合は、以下をご確認下さい。
まず原則として強調されていたのが、これはBuy with Primeでのベストプラクティスであって、すべてのパターンのベストではないということです。組織の戦略やサービス特性によって異なるので、自分の組織の戦略や状況に合うようにカスタムしてくださいと語られていました。
まずはLayer1構造(注意:これはL1 Constructの話ではないです)の話から始まります。通常のL2 Constructを継承して、propsを受け取りメソッドをオーバーライドできる状態にします。これをLayer1と呼んでいます。
次に、Layer2へ変換していきます。constructorの中を請求とセキュリティに焦点を当てて拡張していきます。例えば、billingModeの設定のデフォルトをPAY_PER_REQUESTモードに変更したり、暗号化については、デフォルトではCMKを使用するよう設定しています。ここから分かるように設計思想として、組織としてのデフォルトを設定するが強制まではしないという考えが伺えます。
最後にLayer3として、Fargateや周辺のALB、CloudWatchなどを例に複数のL2 ConstructをカスタムしL3 Constructとしてまとめる話も紹介されていました。こちらのカスタムの詳細の紹介はなかったので、ソースコードをご確認下さい。確認したところ現在は、ecs-patternsはNLB→ECSの構成でしか使用していないようです。
彼らはCross-functional CDK teamを結成して、1週間で必要なConstructを特定し、カスタムコンストラクトを作成しました、これにより、各開発チームは6日分の時間を短縮でき、10チームで試した場合これは2ヶ月分の削減に繋がります。これはAmazonでの取り組みの規模で考えると50年分に匹敵する削減だと話されていました。大げさに聞こえますが、これまで話したサービス数や複雑さを考えると現実的な話だ、とも話されています。
作成したConstructはGitHub上で公開されているので、この取り組みが他の会社でも生かされることを願いますというの言葉で最後の方の発表は締めくくられました。
所感
Platform Engineeringという言葉は出ませんでしたが、まさにPlatform Engineeringのようなインフラ構成の最適化/再利用をCDKで体現している組織の話が聞けて非常に満足でした。日本でも似たようにマイクロサービスを複数チームで構築するような場合は、CDKに限らず同じようなIaCによるCross-functional teamが重要になってくると感じられるセッションでした。参考になる方がいれば幸いです。
2
