re:Invent 2023: AWSアーキテクトが語る1000万ユーザーへのスケーリング戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Scaling on AWS for the first 10 million users (ARC206)
この動画では、AWSのSolutions ArchitectureマネージャーのSkye HartとChris Munnsが、アプリケーションのスケーリングについて詳しく解説しています。AWS Amplify、App Runner、Aurora Serverless v2などのマネージドサービスを活用したアーキテクチャの進化を段階的に紹介し、10万ユーザーから1000万ユーザーへのスケーリングの道筋を示します。同期型から非同期型への移行、マイクロサービス化、キャッシング戦略など、実践的なテクニックも満載です。AWSの長年の経験に基づく、スケーラブルなアプリケーション構築の極意が学べる内容です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
アプリケーション開発におけるスケーラビリティの重要性
プレゼンテーションへようこそ。まず最初に言いたいのは、アプリケーションを作る人で「わあ、誰も使わないといいな。プラットフォームにユーザーが一人もいなくて、自分だけだといいな」と思う人はいないということです。いいえ、人々はアプリケーションを役立つものにしようという意図を持って作ります。顧客のサインアップがあり、改善している内部プロセスがあり、外部プロセスもあります。意図を持って作り、スケールすることを目指して作るのです。AWSとAmazonでは、スケールを非常に真剣に捉えています。今日は、ベストプラクティスをご紹介し、アプリケーションを将来にわたって通用するものにするためのツールとリソースをお伝えします。
スケールの旅のどの段階にいるかに関わらず、一晩で10,000人のユーザーにスケールする次世代のAIアプリケーションを構築しているスタートアップの創業者であっても、アプリがダウンすれば人々が気づくようなミッションクリティカルなアプリケーションを構築している大企業であっても、私たちはあなたの成功をサポートします。私はSkye Hartと申します。Amazon Web ServicesのSolutions Architectureのマネージャーです。プレゼンテーションの途中から、尊敬する同僚のChris Munnsが加わります。彼は12年以上のキャリアを持つベテランのAmazonianで、私たちの組織全体のスタートアップリードおよびテックアドバイザーです。
では始めましょう。私たちが大きな会場にいるのではなく、あなたと私が会議室で一緒に座っていて、開発チームが入ってきて「新しいアプリケーションのアイデアがあります」と言ったと想像してください。リーダーとして、いくつかの質問を自問するかもしれません。3つの質問です。1つ目は、どこから始めるか？Amazonには200以上のサービスがあります。では、アーキテクチャに適切なパターンをどのように選べばいいでしょうか？どうやって始めればいいでしょうか？これを構築した場合の投資収益率はどうなるでしょうか？構築しなかった場合はどうなるでしょうか？そして、これらのビジネス上の質問を自問し、ニーズと要件から逆算して考えます。
2つ目の質問は、「わかりました。このアプリケーションを持っていますが、どうやってスケールするように構築すればいいでしょうか？」リスク軽減について話しましょう。時の試練に耐えられるほど十分に回復力があることをどのように確認すればいいでしょうか？そして、10万人のユーザーにスケールアップしたときに、クラッシュしないようにするにはどうすればいいでしょうか？これは、最後の、そして最も重要な3つ目の質問につながります。それは、私たちのユーザーは誰で、彼らを満足させるにはどうすればいいかということです。アプリケーションを開いたらクラッシュして、二度と使わなくなった経験のある人はどれくらいいますか？そうですね、「あー、レイテンシーが高くて、もう使いたくない」と思うでしょう。では、システムが常に稼働し、ユーザーが満足し、最終的に5つ星のレビューを残してくれるようにするにはどうすればいいでしょうか？
フルスタックアプリケーションの定義と開発者の変化する世界
このプレゼンテーションを通して、「アプリ」という概念について話します。アプリは様々な方法で定義できます。このプレゼンテーションの目的では、アプリをフルスタックとして定義します。これにはフロントエンド、バックエンド、そしてデータストレージが含まれます。ユーザーインターフェイス層があり、アプリケーションにログオンするとフロントエンドが見えます。舞台裏にはビジネスロジック層やコンピュート、エンジンがあるかもしれません。そしてもちろん、データストレージもあります。既存のデータをビジネスに活用するにはどうすればいいでしょうか？
本題に入る前に、私たちの世界がどれほど変化しているかを認識しておきたいと思います。まず一つ目は、開発者の経験です。彼らが使用している最新のフレームワークに対応し、時代とともに変化する必要があります。二つ目に挙げたいのは、サーバーレス技術への移行です。これについては後ほど詳しく説明しますが、基盤となるインフラの管理や重労働をAWSに任せることで、イノベーションにより多くの時間を費やせるようになります。最後に言及したいのは、急速なスケールです。これは何を意味するのでしょうか？これまで以上に多くのデータが存在し、そのデータの力をほぼリアルタイムで、ナノ秒単位のアプリケーションでグローバルに活用するという期待が生まれているのです。
ある有名な、あるいは悪名高い引用をご紹介します。「初日から高いスケーラビリティを念頭に置いてアーキテクチャを設計することはないが、私たちは確実にそれを目指す」。私はこれを説明する際、建物を建てる請負業者の例えをよく使います。私は器用ではないので、細かいことは言えませんが、最も重要なのは基礎を築くことです。屋根や窓を取り付ける前に、基礎が時の試練に耐えられることを確認する必要があります。天候の変化やさまざまなシステムに対応できるよう、基礎は準備が整っていなければなりません。
もう一つの考え方のモデルとして、構築の好循環があります。これはMVPやプロトタイピングのプロセスでよく見られるものです。中心にユーザーがいると想像してください。まず開発を始め、開発チームが集まってアプリケーションを構築します。それは素晴らしいことですが、私たちは何を構築しているのかを理解する必要があります。モニタリングや可観測性のツールを使用して、何が起こっているかを積極的に把握する必要があります。アプリケーションのレイテンシーは良好ですか？コンピューティングとリソース利用率はどうでしょうか？コスト効率は良いですか？これらの側面をすべて測定し、潜在的な問題に先手を打つ必要があります。
そして、ユーザーや顧客からのフィードバックループから学び、再び構築します。スケーリングの旅のどの段階にいても、アプリケーションをより効率的でコスト効果の高いものにするために、常に反復と改善のプロセスがあることを忘れないでください。
AWS Amplify Hostingによるモダンなフロントエンド開発
では、初日から始めましょう。会議室に集まり、このアプリケーションの構築を始めます。ベータテスターから始めて、ユーザーを獲得していきます。アプリケーションを使ってもらいましょう。 これに対する現代的なアプローチは、アプリケーションをフロントエンドとバックエンドに分割することです。これはデカップリングと呼ばれ、よく耳にするバズワードですが、後ほど詳しく説明します。
従来のフロントエンドホスティングでは、単一のホストで Amazon EC2 を使用するケースがよく見られます。そこに Auto Scaling グループや Elastic Load Balancing を付加し、CDN に送信するというパターンです。これは非常に一般的なパターンですが、いくつかの制限や課題があります。多くの基盤インフラ、パッチ、バグ修正を管理する必要があり、マネージドサービスではありません。また、すべてが1つのホストにあることによる制限もあり、フェイルオーバーや冗長性に影響します。すべてが結合していると、災害時に逃げ場がなくなってしまいます。
そこで、フロントエンドとバックエンドを分離する、現代的なフロントエンドの考え方に移行します。この現代的なフロントエンドの利点には、最新のフレームワークに対する開発者の期待に応えること、組み込みのスケールと性能、その他の機能が含まれます。後ほど、非常に強力な技術である AWS Amplify について詳しく説明します。
AWS Amplify Hosting は、私たちのスタックで使用できる最もシンプルな技術の1つです。私が Solutions Architect だった頃、多くの顧客とこれを使用しました。使い方は非常に簡単で、まず GitHub などのリポジトリを接続し、ユーザー、ガバナンス、すべての設定を含むビルド設定を行い、最後にアプリをデプロイするだけです。本当にこれだけで、サーバーレスなので基盤インフラを管理する必要もありません。
私たちは開発者からのフィードバックを基に、彼らが一般的に必要とするツールや機能を判断しています。そのフィードバックを元に、これらの AWS Amplify Hosting の機能を開発しました。アトミックデプロイメント、フィーチャーブランチデプロイメント、その他の機能が組み込まれています。先ほど、アプリケーションがスケールする際にグローバルに利用可能である必要性について触れましたが、 複数のアベイラビリティーゾーンにまたがる EC2 インスタンスを設定する代わりに、CDN、特に Amazon CloudFront の考え方に基づいて構築された、グローバルに利用可能なフロントエンドがあります。
フロントエンドフレームワークに馴染みのない方のために、AWS Amplify がサポートする3つのフレームワークを紹介します。1つ目はクライアントサイドレンダリングで、これは基本的にクライアントブラウザで実行されるコンテナのようなものです。2つ目はサーバーサイドレンダリングで、負荷をサーバーに戻します。これは Nuxt や Gatsby のようなフレームワークで人気があります。AWS Amplify がサポートする3つ目のフレームワークは静的サイトジェネレーターです。これは Amazon S3 で静的ウェブサイトをホスティングするようなものですが、多くの顧客は完全なパッケージとデプロイの容易さを提供する AWS Amplify の使用を好みます。
バックエンドのコンピューティングオプションとEC2の制限
さて、バックエンドについてや、コンピューティングオプションの選び方について疑問に思われるかもしれません。ここでは、主に3つのカテゴリーのコンピューティングエンジンについてお話ししたいと思います。まず、2006年に作られたAmazon EC2があります。これは多くの管理が必要ですが、設定に関して最も制御力があるサービスです。次に、コンテナが非常に人気になり、Amazon ECSやKubernetesファン向けのAmazon EKS、そしてサーバーレスコンテナオプションであるAWS Fargateなどのオプションを展開しました。3つ目のカテゴリーは、サーバーレスコンピューティング技術であるAWS Lambdaです。
どこから始めるべきか、どのようにコンピューティングオプションを評価すべきか疑問に思われるかもしれません。 多くの場合、単一のEC2インスタンスで実行することがデフォルトの選択肢となります。しかし、このアプローチには、フェイルオーバーがなく、冗長性がないという制限があります。
現在このようなアーキテクチャを使用している場合でも、問題ありません。これはよく見かけるパターンですが、いわば「卵を一つのかごに全部入れる」ようなものです。何か問題が発生すると、システム全体がダウンし、アプリケーションが停止し、ユーザーは不満を感じることになります。このアプローチでもある程度まで進めることはできますが、別のパターンを検討する必要があります。
これは、バックエンドとデータ層の両方で見られることがあり、EC2上で自己管理データベースをホストするケースがあります。これは私たちが見るアンチパターンの一つです。アプリケーションを立ち上げる際には、できるだけ多くのマネージドサービスを活用したいと考えています。これを別の視点で見ると、このマトリックスのようになります。 これは非常に良いスライドです。写真を撮る時間を設けますが、少し説明させていただきます。
左側のチャートから始めたいと思います。そこには、より意見の強いサービスと、そうでないサービスが示されています。これらのサービスを誇張して説明するのが好きなのですが、意見の弱い方はAmazon EC2になります。これが意味するのは、設定に関して最も制御力があるということですが、大きな力には大きな責任が伴います。つまり、これらすべてを設定、制御、デバッグし、コンピューティングのサイズが適切であることを確認する必要があります。これはコストの観点からも重要な要素です。際限なくスケールアウトせず、本当に必要なものだけを利用するようにしたいものです。
コンピューティングオプションの選択とAWS App Runnerの利点
スペクトルの反対側にはAWS Lambdaがあります。お客様が管理する側を見ると、実際にはアプリケーションコードだけです。これは非常に簡単なので、起動する際には、このスペクトルを考え、ワークロードと経験、快適さのレベルの両方に特化したものを本当に検討する必要があります。
コンピューティングオプションを選択した後、「アプリケーションをインターネットにどのように公開するか？」と考えるでしょう。ここで簡単に3つのサービスについてお話しします。API Gatewayは当社のサービスです。これはREST APIに特化していると思います。2つ目は Application Load Balancer で、これは基本的にLayer 7プロキシのような役割を果たします。API Gatewayのような多くの機能はありませんが、様々な面で非常に強力なサービスです。そして3つ目はAWS AppSyncです。GraphQLに詳しい方には、これは多くのお客様にとって非常に人気があります。
APIフロントエンドを選ぶためのチートシートをご用意しました。ここには多くの重複がありますが、質問がある場合は、後ほどホールで私やChrisを見つけてください。WebSocketsや受信リクエスト数、その他の考慮事項についての良いチートシートです。このチートシートを説明した後、実は別のものをお勧めします。その理由はすぐにお話しします。
App Runnerは、あなたが今まで出会った中で最高の従業員です。これはAPIを公開するために必要な完全なスタック全体を提供するからです。このサービスにはFargate、Auto Scaling、ELB、ECRが組み込まれており、目的に特化していることがわかります。私はスタートアップと多く仕事をしていますが、アプリケーションを展開する最速の方法は、このApp Runnerを利用することです。様々なコンポーネントなどを設定する必要がありません。本当に素早く立ち上げて実行できます。
では、全てをまとめてみましょう。データベースについてはまだ説明していませんが、Amplify HostingとApp Runnerがあります。この時点で、私は基盤となるインフラを全く管理していません。これは私を幸せにします。より多くの時間をイノベーションに費やし、本当に気にかけていることに集中できるのです。
データベース選択の考慮事項とAmazon Auroraの特徴
次の質問は、NoSQLを使うか使わないか？これを5回素早く言ってみてください。これは私がよく受ける質問です。私もデータエンジニアですが、これは議論の的になるトピックです。今回は、SQLデータベースから始めることをお勧めします。その理由を説明しましょう。SQLは非常に人気のあるエコシステムで、PostgresやMySQLなど、皆さんがよく知っているものについて、多くの人からサポートを得ることができます。また、多くのアプリケーションが実際にこのリレーショナルデータ構造に従っています。
会場で私に声をかけて、「でもSkye、私は膨大な量のデータを扱っているんだ」と言うかもしれません。そうですね。時系列アプリケーションを構築している、取引アプリケーションを構築している、数週間で数ペタバイトの大規模なものを構築している。わかりました。その場合はNoSQLや他の目的特化型データベースが必要かもしれません。目的特化型データベースというのは、私たちが持っているデータベースのスイートのことで、それらのトラックの1つをチェックすることをお勧めします。時系列、グラフなど、名前を挙げればあります。NoSQLの他のユースケースとしては、リレーショナルデータセットやそのような構造やスキーマが本当にない場合です。繰り返しになりますが、非常に短期間でペタバイト規模に達するユースケースがある場合、大量のデータを扱う場合は、NoSQLデータベースから始めることを検討すべきです。しかし、おそらくこの部屋にいる皆さんのほとんどはそうではないでしょう。
そこで、SQLデータベース、特にAmazon Auroraから始めましょう。ここで注目すべきは、先ほど言ったように、PostgreSQLとMySQLです。EC2でこれらをホストしている場合は、Auroraを試してみることを強くお勧めします。なぜでしょうか？自動的にスケールするからです。さまざまなパフォーマンス、可用性、耐久性の機能があり、それがあなたの代わりに作業をしてくれます。重労働を担ってくれるのです。AWSがそのすべてを管理します。数分で簡単に立ち上げることができます。私は昔からのデータベース屋ですが、Auroraは本当に簡単です。
AWSでは、私たちのサービスに対して常に新しいイテレーションを出しています。そこで、Amazon Aurora Serverless v2が登場しました。ここで重要なポイントは、コンピューティング層とストレージ層の分離です。これは特にコスト面でスケーリングする際に重要です。これは、ピーク時のワークロードまでスケールアウトしてくれます。例えば、ブラックフライデーのような大規模な需要がある場合、そのピーク需要に合わせてスケールアウトし、その後自動的にスケールバックします。つまり、必要なものと、ユーザーが必要とするものにのみ対価を支払うことになり、これは非常に魅力的です。
ここで全てをまとめますと、この時点では、Serverless、AWS Amplify Hosting、AWS App Runner、Amazon Aurora Serverless v2のみを使用しています。繰り返しになりますが、私は常にこのTCO（総所有コスト）について考えており、これらのマネージドサービスを活用してピーク需要に対応できることが重要です。高可用性、グローバルアプリケーションを構築している場合、これらの機能の多くは、サービスを立ち上げた時点で既に組み込まれています。素晴らしいですね、私たちはやり遂げました。これで、100ユーザーに到達しました。おそらく私は小さなパーティーを開いて、とてもワクワクしているでしょう。そしてエネルギーが高まってきて、1000ユーザーに到達し、そのアプリケーションに多くの注目が集まり始めます。そして10,000ユーザーに到達しますが、突然物事が壊れ始め、システムがダウンし始めます。データベースへの書き込みが多すぎて、処理が異なってきて、物事が壊れ始めます。物事が壊れている時にChrisに渡すのは嫌ですが、ここで本当にあなたの助けが必要です。
スケーリングの課題とアプリケーションの最適化
素晴らしい、ありがとうSkye。セットアップをしてくれてありがとう。Skyeが私たちに初期のアーキテクチャと、考慮すべき初期のパターンについて説明してくれました。そして繰り返しになりますが、新しいアプリケーションを構築する際に最初に考えるべき重要なポイントは、インフラストラクチャの作業を減らし、ビジネスアプリケーションにより多くの時間を費やすことです。そのためにAWSのマネージドサービスとServerlessを活用することを推奨します。再び、この規模に達したとき、仮に数万人のユーザーがいるとしましょう。そうすると、潜在的に何か問題が発生し始める可能性があります。そして、これらの問題は通常、非常に一般的なパターンに当てはまります。
AWSでは長年にわたり、スタートアップや企業と協力してアプリケーションを構築してきました。そのため、アプリケーションの規模が同じようなポイントに達したときに、同じような問題が発生するのをよく目にします。実際に痛点となるのは、ビジネス自体が成長し、製品が成長し、機能や能力が拡大したことで、アプリケーションの異なる部分が互いに影響を与え始めることです。何年も前、2000年代初頭、amazon.comは元々モノリシックなアプリケーションでした。サイト全体が1つのモノリシックなアプリケーションだったのです。そして、私たちが発見したのは、アプリケーションの様々なコンポーネントの要求が、効果的に他のコンポーネントに悪影響を与えていたということです。
通常、これが顕著になるのはデータベースにおいてです。非常に大量のデータを扱う集中的なクエリもあれば、より迅速で簡単なクエリもあります。そして再び、このリソースの競合とアンバランスが時として課題を引き起こすことがあります。そこで私たちがすべきことは、最適化の余地がどこにあるかを理解するために、スタック全体を見直すことです。これらの様々なコンポーネントをどのように組み合わせるか、あるいは分離するか、そしてそれらをさらにどのようにスケールさせるかを考え始める必要があります。そこで、Skyeが概説したように、フロントエンド、バックエンド、そしてデータ層について取り組んでいきます。
しかし、これ以上先に進む前に、必要なものがあります。基本的に、私たちのインフラストラクチャとアーキテクチャ内で何が起こっているかを測定する方法が必要です。アプリケーションを構築・運用してきた方々は、サポート担当者やチームの他のメンバー、顧客から「サイトが遅い」「アプリが遅い」といった声を聞いたことがあるでしょう。そして、「遅いとはどういう意味ですか？何が起こっているのですか？何を見ているのですか？もう少し詳しく説明してもらえますか？」と尋ねたことがあるでしょう。そのため、スケールアップや成長のために必要なデータを得るためのツールや手段が必要なのです。
AWSには、これを支援する多数の製品があります。最も大きな2つの製品群（それぞれが複数のコンポーネントを持っています）は、ほとんどの方がご存知だと思いますが、Amazon CloudWatchとAWS X-Rayです。Amazon CloudWatchはAWSの初期の頃から存在し、現在では私たちの製品ポートフォリオのほぼ全体に深く統合されています。
モニタリングとオブザーバビリティツールの重要性
Amazon CloudWatchには、ログ、メトリクス、アラーム、ダッシュボードに関する様々な機能が組み込まれていますが、フロントエンド関連の側面も支援してくれます。Synthetic Canariesというツールがあり、CloudWatchのインフラを使ってリモートからAPIをテストできます。また、Real User Monitoring（RUM）コンポーネントもあり、これをアプリケーションのフロントエンドに組み込むことでパフォーマンスデータを取得できます。同様に、AWS X-Rayを使用すると、アーキテクチャ全体にわたるトレースが可能になります。現時点では、私たちのアーキテクチャはそれほど分散化されておらず、App Runnerとデータベースだけなので、測定できる範囲は限られていますが、アプリケーションを分解していくにつれて、これらの機能はますます重要になっていくでしょう。
さて、ここ数年で見られるもう一つの傾向は（これは今年の生成AIブームより前からの話ですが）、オペレーションやデベロッパー向けに機械学習を活用したツールがどんどん登場していることです。AWSには現在、この分野で2つの主要製品があります。今週末までにこの分野がどうなっているかはわかりません。もちろん、ここはre:Inventなので、常に多くのことが起こっています。まず1つ目はAmazon DevOps Guruです。名前が示すように、組織内のDevOps担当者にとって便利なツールです。このツールは、インフラストラクチャを分析し、構成要素を理解した上で、AWSが内部で開発したデータと機械学習モデルに基づいてガイダンスを提供します。高レイテンシー、遅いデータベースクエリ、その他インフラの問題を検出し、チェックすべき点について推奨事項を提示します。
次に、Amazon CodeGuruがあります。名前が示すように、これはアプリケーションコードを分析するために使用されます。コードリポジトリを指定してすべてのコードをスキャンさせると、コードの機能、パフォーマンス、潜在的な問題点などを理解し、特定するのに役立ちます。これら2つのツールは、Amazonの数十年にわたる開発とインフラの知見に基づく機械学習モデルを活用しています。現在の取り組みを大幅に強化する強力な手段となり得るでしょう。ここにDevOps Guruのスクリーンショットの例があります。データベース内で発生している遅いクエリや他の問題点をハイライトしています。これらのサービスから得られる情報は豊富で、問題の所在を本当に理解するのに役立ちます。単に「より大きなインスタンスを使おう」とか「もっと多くのインスタンスを実行しよう」というような安易な対応ではなく、他の選択肢を検討することができるのです。
さて、ツールボックスにいくつかのツールが加わったところで、このアーキテクチャのスケーリングについて、どのように考え、少しずつ分解していくかという本題に戻りましょう。フロントエンドに関して、AWS Amplify Hostingを使用している場合、この製品の素晴らしい点の1つは、何もしなくても非常に大きくスケールすることです。Amplify Hostingには、スケールをさらに拡大したり改善したりするために調整できるノブやレバーが実質的にありません。チームとこの点について何度か話し合い、「どこで破綻するのか？限界点はどこ？顧客が課題に直面しているポイントは？」と尋ねましたが、彼らは「理論上、そういった問題は見られない」と答えました。
Amplify Hostingの最大の利点の1つは、Amazon CloudFrontの上に構築されていることです。CloudFrontはAWSで15周年を迎えたばかりです。現在550以上のポイントオブプレゼンスを持つCDNサービスです。何年も前は非常に小規模なサービスだったことを覚えていますが、今では巨大なグローバル容量を持ち、これまで以上に速く簡単にトラフィックや顧客をサイトに導くことができます。フロントエンドでは、実際のパフォーマンスの多くはあなたが行う作業から生まれます。フロントエンドコードの調整、バックエンドデータベースへの呼び出し回数とその遅さの確認などが含まれます。また、CSS、JavaScript、画像、静的コンテンツをどれだけ読み込むかということも関係してきます。
Amazon Aurora Serverless v2とRDS Proxyによるデータベーススケーリング
ここで、CloudFrontのCDNの側面が非常に強力になります。エッジで、つまりお客様により近い場所でリソースをキャッシュすることができるからです。これは、Amplifyが機能を公開している領域の1つです。Amplifyがホストするオブジェクトにカスタムヘッダーを設定する機能があります。ここでは、cache-controlヘッダーを設定し、最大経過時間を指定し、URIの/imageディレクトリにあるすべてのものに対するRegExパターンを設定する例を見ています。静的な画像をキャッシュし、「これらはそれほど頻繁に変更されないので、エッジやお客様のブラウザで可能な限り長くキャッシュしても問題ない」と言っているようなものです。しかし、それ以上のことは、AmplifyやCloudFrontでこれらの設定を変更したり調整したりすることはあまりできません。
バックエンドに移りましょう。バックエンドのデータストレージ、つまりデータベースについて話します。データストレージ領域は、実際に顧客が早い段階でスケーリングの効果を最も得られる部分だと私は考えています。通常、より多くの課題が発生する場所です。
物理的な制約がスケーリングの考え方の障壁になることが多い領域です。現在、Aurora Serverless v2の素晴らしい点の1つ、そして従来のリレーショナルデータベースホスティング製品とは異なるAuroraの主要な特徴の1つは、コンピューティングとストレージを分離していることです。私はAmazon以前から長年にわたってMySQLとPostgresを大規模に運用してきましたが、結局のところ、コンピューティングかストレージのどちらかがボトルネックになります。しかし、Auroraは基本的にこの2つを切り離し、独立してスケールできるようにしています。Aurora Serverless v2は、コンピューティングとストレージを自動的にスケールアウトすることでこのプロセスを自動化します。ストレージについては本当に考える必要がありません。すべてバックグラウンドで処理してくれます。データベースストレージには基本的に共有ストレージモデルを使用しています。しかし、CPU側では少し多くの制御ができます。
Aurora Serverless v2は、全体的なAurora Serverlessモデルに基づいており、Aurora容量ユニット（ACU）という概念があります。1つのACUは、基盤となるデータベースノードの2ギビバイトのメモリを表します。現在、Auroraを手動で設定する場合、最小0.5ACUから最大128ACU（256ギビバイトのメモリ）まで設定できます。そのため、上限では相当大規模なホストや容量スケールについて話していることになります。これは、Auroraクラスターの一部として持つことができる単一ノードのスケールアップです。Auroraがこれを処理してくれるので、Aurora Serverless v2はデータベース内で起こっていることについて多くのメトリクスとデータを見て、自動的にACUをデータベースに追加します。これは完全に透過的に行われ、トランザクションに影響を与えず、バッファプールにも影響を与えないはずです。これらは、コンピューティングとストレージが結合されたAurora以外のモデルでデータベースのサイズを変更する際に通常調整する必要がある項目です。
また、Aurora全体の一部として利用できるもう1つのオプションは、クラスターに他のノードを追加できることです。クラスターに他の読み取りノードを追加し続けることができます。これらの読み取りノードは、実際にAurora Serverlessまたは通常のAuroraを混在させることができます。つまり、これらのハードに設定されたリソースインスタンスまたはノードと、全体的な負荷に基づいてスケールアップおよびダウンできるServerlessノードを混在させることができます。現在、Auroraは最大15の読み取りレプリカをサポートしており、0.5ACUから128ACUまでスケールできます。ここでAuroraが行う興味深いことがあり、これらの一部として異なるティアが記述されているのがわかります。クラスター内には常に書き込みノードがあり、その後に15の読み取りレプリカを持つことができます。これらの読み取りレプリカには「ティア」と呼ばれるものを割り当てる必要があります。これは、Auroraが可用性SLAを処理する方法の一部であり、プライマリノードが失敗または停止した場合、ティアの順序に従ってリーダーを昇格させます。また、これの一部として起こることは、ティア0とティア1のリーダーが常に書き込み側と同じサイズであるということです。
これは非常に柔軟に設定できます。例えば、はるかに低いティアのリーダーを強制的にスケールダウンし、大きくなりすぎないように制限することができます。これは、内部の管理パネルやBIツール、その他のデータ分析ツールなど、Auroraノードのフルサイズの影響を必要としないものに役立ちます。これは、これらのリードレプリカを制御できる唯一の領域です。これらは、アプリケーション全体のニーズに基づいて作成し、追加するものです。さて、これらの様々なリードレプリカを追加し、このクラスターを成長させ始めると、ライトノードはAurora Serverlessによって自動的に成長し、そしてアプリケーションの需要に基づいてこれらのリードレプリカを必要に応じて追加することになります。読み取りと書き込みの需要が20対1から30対1の比率になるのを見ているお客様もいて、そこではこれらのリードレプリカが非常に重要になります。そこで必要になるのが、何らかのデータベースプロキシです。
データベースプロキシは、PostgresやMySQLの世界で長年使われてきました。数年前、私たちはRDS Proxyを発表しました。名前が示すように、RDS Proxyはアプリケーションとすべてのデータベースノードの間に位置するデータベースプロキシです。アプリケーションとライトノード、アプリケーションとすべてのリードノードの間に位置することができます。これが行うのは、接続の処理や接続メモリの消費などを簡素化することです。これは、特にアプリケーション層で何らかの自動スケーリングやサーバーレス性が発生する可能性がある場合に、非常に重要です。RDS Proxyに接続プールを管理させることで、データベースへのリソース需要を実際に減らすことができます。つまり、RDS Proxyを使用することで、アーキテクチャを大きく変更することなく、データベースからより多くのスケールを得ることができます。アプリケーションをプロキシに向け、プロキシがデータベースノードに接続します。
キャッシングの導入とAmazon ElastiCacheの活用
プロキシがデータベースに接続し、そこから始まります。そして、私たちのアーキテクチャはここで少し進化し始めます。ここで行ったのは、Amazon RDS Proxyを実装し、Amazon Aurora Serverless v2クラスター内にプライマリライトノードを配置しました。そして、読み取りトラフィックを分散させるために、いくつかのリードノードを追加することができます。
そして再び、ここで見始めるのは、これを非常に遠くまで持っていける可能性があるというパターンです。もし128 ACUの15のリードノードがあれば、データベースに対して複数テラビットのメモリと整合したCPU容量を持つことになります。これは非常に、非常に遠くまで持っていけるでしょう。そして繰り返しますが、ストレージ層は完全に透過的にスケールするので、必ずしも自分で考慮に入れる必要はありません。
さて、もちろんSkyeは先ほどのプレゼンテーションで素晴らしい引用を紹介してくれましたが、ここにもう一つ私が好んで引用する言葉があります。それは「最高のデータベースクエリは、頻繁に実行しないクエリである」というものです。そして、ここでもう一つのテクニックがありますが、私は意図的にこの順序で紹介しています。それは、データベースの前にキャッシングを追加することです。
長年にわたり、これを実現するための様々な方法やモデルが存在してきました。個人的には、データベースキャッシュをデータベースから切り離し、アプリケーション内で実行しないことを好んでいます。そして今日では、Amazon ElastiCacheという数年前から提供されている製品を使用することで、このキャッシング製品内で主に2つのオプション、正確には2つの主要エンジンを利用できます。1つは、約20年前にLiveJournalによって最初に構築されたMemcachedです。これは多くの大規模インフラストラクチャで使用されており、非常に高いスケールを処理できます。もう1つはRedisで、これも非常に高いスケールのアーキテクチャで使用されているのを見かけます。
ここでElastiCacheについて注意すべき点は、これまで説明してきた他のものとは異なり、リソースのスケールを自分で管理する必要があるということです。つまり、クラスターのサイズについて考慮する必要があります。また、その中のオブジェクトにどのようにアクセスするかについても考える必要があります。そのため、キャッシュ製品を追加することは、おそらく読み取りと書き込みを2つの異なるタイプのデータベースノード間で分割するだけよりも、アプリケーションコードにより大きな変更が必要になる最初のケースでしょう。
つまり、ここでは基本的なアーキテクチャにキャッシュを追加しました。これにより、データベースのスケーリングについて考える必要性を軽減できます。読み取りトラフィックの相当部分をキャッシュに移動させることで、データベースのさらなるスケールアウトにかかる時間とコストを大幅に節約できるのです。 そして、ここで見られるのは、まず「スケールアップ」、そして「スケールアウト」を考えるというモデルです。
Amazon Aurora Serverless v2は自動的にスケールアップします。つまり、ノードを大きくします。読み取りレプリカの追加は考慮する必要があります。Amazon ElastiCacheの場合、ノードを大きくスケールアップし、さらにサービスの背後で表現されるノードのプールに追加することができます。繰り返しになりますが、負荷と需要を軽減するために、様々な他の方法を可能な限り考慮することが重要です。データベースの前にプロキシを置いて接続のオーバーヘッドを削減するのは、シンプルで簡単な勝利策です。アプリケーションのためにデータベース外でキャッシングを行う方法を見つけるのも、同様にシンプルで簡単な勝利策となります。
AWS App Runnerの内部構造とスケーリングメカニズム
では、ここでアプリケーション層、つまりバックエンドについてもう少し詳しく見ていきましょう。 SkyeはAWS App Runnerが提供する機能について簡単に説明しました。これはAmazon ECSとAWS Fargate 、Auto Scaling、Elastic Load Balancing、そして他の多くのコンポーネントの上に構築されており、これらすべてを自分で設定する必要がありません。これをCloudFormationで記述しようとすると、数百行のコードになるでしょう。しかし、この場合はそのようなことを一切する必要がありません。
AWS App Runnerの舞台裏では、いくつかの主要なコンポーネントが動いています。まず、アプリケーションのフロントドアとして、Network Load Balancer（NLB）が配置されます。これは、アプリケーションおよびElastic Load Balancing製品スイートの一部です。その背後には、HTTPトラフィック用のL7リクエストルーターが動作しています。なお、AWS App Runnerは現在、基本的にWebアプリケーション（ポート80またはポート443）の実行のみをサポートしています。さらにその後ろでは、Amazon ECS Fargateタスクを管理しています。つまり、実質的にはFargateを使用し、これらのリソースのスケールを全て管理しているのです。
繰り返しになりますが、Skyeが先ほど述べたように、ユーザーはこれらの内部構造を一切目にすることはありません。コードリポジトリを接続し、アプリケーションをデプロイするだけで、アプリケーションが動作します。内部の仕組みは全て隠蔽されています。ただし、AWS App Runnerは、Amazon Aurora Serverless v2とは少し異なり、スケールに関するノブやレバーを調整するオプションをいくつか提供しています。AWS App Runnerは、実行するFargateタスクを「インスタンス」または「App Runnerインスタンス」と呼んでいます。
App Runnerインスタンスは、特定のメモリとCPUの量で構成されており、これが製品を実行する際のコストに直接関係します。App Runnerは様々な構成を提供しています。現在、0.25 vCPUと0.5GBのメモリから、4 CPUと12GBのメモリまでのオプションがあります。これらは固定の割り当てなので、これらの構成の中から1つを選択する必要があります。これら2つの要素を個別に調整することはできません。そうしたい場合は、コンピューティング集約型、メモリ集約型、あるいはより混合モードの側面を比較して、異なるEC2インスタンスを選択することになります。基盤となるApp Runnerインスタンスのサイズを選択すると、それを自動的にスケールアップ・ダウンしてくれます。
デフォルトでは、各App Runnerインスタンスには、処理できる同時リクエストの最大数が設定されています。これはTPSではなく、同時リクエスト数です。現在、上限は200リクエストに設定されています。これが、App Runnerのインスタンスサイズでのスケールを制限する一つの要因となっています。App Runnerのスケーリングに関わるもう一つの要因は、サービスまたはアプリケーションごとのインスタンス数です。現在、デフォルトのソフトリミットは25です。このチームと話をしましたが、この数値は簡単に引き上げ申請ができます。25に設定されているのは、誤って大きすぎるものを作成しないようにするための安全機構です。
これら2つの数値を合わせると、インスタンスあたり最大200の同時リクエストが可能で、アプリケーションの初期インスタンス数のソフトリミットが25であることから、デフォルトでApp Runnerアプリケーションの最大同時実行数は約5,000となります。App Runnerはこれらのインスタンスのスケーリングを管理します。バックグラウンドでより多くのFargateインスタンスを起動し、設定したヘルスチェックを通過させてL7ロードバランサーに追加し、基本的にリクエストの出入りを監視します。
App Runnerが行う1つの機能は、負荷が低下してインスタンスがそれほど活発に動作する必要がなくなったと判断した際に、インテリジェントにスケールダウンすることです。L7リクエストルーターは、トラフィックを一部のノードから巧みに移動させ、自動的にスピンダウンできるようにします。これは、従来のauto-scalingモデルで人々が直面してきた課題の1つです。EC2の従来のauto-scaleモデルでは、ノードをスケールダウンする際、そのノードが何をしているのか分からないことがありました。このL7リクエストルーターは、App Runnerインスタンスから負荷を取り除き、スピンダウンを容易にするのに役立ちます。
App Runnerが行うもう1つの巧妙な機能は、裏側でFargateタスクを事実上凍結状態に保つことです。メモリをアクティブに保持するので、突然のトラフィックの急増があった場合、非常に迅速に再起動することができます。App Runnerはこれらすべてを自動的に処理し、デフォルトではApp Runnerアプリケーションを単一のインスタンスまでスケールダウンできます。 バックエンドアプリケーションのこの側面を考えると、App Runnerが提供するのは最大5,000の同時実行性です。
アプリケーションの分解とマイクロサービスアーキテクチャへの移行
人々は同時実行性と1秒あたりのトランザクション数を混同することがあります。トランザクションやアクションにかかる時間を考慮し、それを5,000の同時実行性と組み合わせると、スケールについて考えることができます。例えば、1リクエストに2秒かかる場合、1分間に150,000リクエストを処理できることになります。これはかなりの規模です。1秒かかる場合は、1分間に300,000リクエストを処理できます。
アプリケーションについては、ここでは詳しく触れませんが、アプリケーションのパフォーマンスチューニングが重要です。先ほど説明したツールを使用して、アプリケーションのどこが遅いのか、どのコードが遅く実行されているのかを確認する必要があります。よく見られる興味深いヒントの1つで、App Runnerの特徴の1つは、マネージドランタイムを提供していることです。ランタイムの新しいバージョンに移行することで、かなりの速度向上が得られることがあります。これはLambdaでよく見られる現象です。
ここでのスケールについて言えば、おそらく10万人以上のユーザー数を簡単に超え、最初の100万人ユーザーに到達し始めるかもしれません。では、その後何を考える必要があるでしょうか？ある時点で、これまで議論してきたすべてが限界に達し始めます。Auroraデータベースの15個のリードレプリカが最大サイズに達しても、それ以前に直面する可能性が高いのは、ライトノードの競合が最大になることです。どのタイプのリレーショナルデータベースでも、マスター・マスター型の構成のリードレプリカがあったとしても、単一のライトノードに制限されます。
もう一つ注意すべき点は、App Runnerには制限があるということです。現在、私たちのビジネスの複雑さのため、アプリケーションのエンドポイントで、コンポーネントがレイテンシーを増加させ、他の部分に摩擦を引き起こす問題が発生し始める可能性があります。
この問題が本当に痛点となり始めるのは、実は組織的な面においてです。先ほどのamazon.comの例に戻りますが、2000年代初頭に大規模なモノリスを抱えていた時、私たちはその基盤にさまざまな亀裂が入り始めているのを目の当たりにしました。最大の問題の一つは開発チームに関するものでした。開発者たちは、単一のコードベースの中で互いの足を踏み合うようになっていたのです。そのため、このモノリスは、内部で起こる複雑に絡み合った依存関係のために、私たちが必要とするスピードで動くことを妨げる問題となりました。
ここで通常、アプリケーションの分解について話し始めます。サービス指向アーキテクチャやマイクロサービスベースのアーキテクチャ、あるいは他の呼び方をするかもしれませんが。ここでも考え始めなければならないのは、このモノリスをどのように分解するかということです。今週は、異なる戦略や考え方の例について話す多くのセッションがあります。アプリケーションを分解する方法には、主に2つのモデルがあると思います。一つはデータドメインマッピングです。データベース内のデータを見て、ビジネスのニーズや共通点に基づいてグループ化する方法を考えます。もう一つはビジネス機能マッピングです。通常、これらは非常に近いものですが、「アプリケーションとデータの中に、ビジネスの異なるニーズがあり、それをビジネスグループやライン・オブ・ビジネスでグループ化しよう」と考え始めます。
ここで、他のテクノロジーの評価を考え始める領域にもなります。この分解の一環として全く新しいアプリケーションを構築するのであれば、サーバーレスのLambdaの使用を検討したり、EC2で一部を実行したり、Skyが先ほど話していたように、異なるデータベースのニーズがあるかもしれません。ここでも、データベースのスケーリングに関して最も簡単で効果的な最初の手法の一つは、単純により多くのデータベースを持つことです。つまり、データベースの連携です。データドメインマッピングやビジネスドメインマッピングを利用して、データを完全に異なるクラスターに分離します。先ほど、Auroraで単一の書き込みマスターを持ち、最大120 ACUと15のリードレプリカを持つことができると話しましたが、今度はそれぞれを3つか4つ持つことができると想像してください。このように、分解することでスケーラビリティの限界を押し広げ続けることができます。
これにより、いくつかの変化が生じます。一つは、もはや一箇所ですべてのデータをクエリすることができなくなるということですが、おそらくそれほど頻繁には行っていないでしょう。行う場合は、おそらくビジネスインテリジェンスのニーズや他の分析ニーズのためでしょう。そのためには、より適したプロダクトがあります。Amazon RedshiftやAmazon Athena、Snowflakeなどがそうです。目的に特化したBIデータベースツールや分析ツールを考えるのです。このようなアプローチを取ることで、これらの異なる領域に必要に応じて、以前使用したすべてのスケーラビリティパターンやテクニックを継続して適用する能力を得ることができます。
非同期通信モデルとアプリケーション統合サービスの活用
例えば、私のサイトのフォーラムが特に負荷が高いので、そこをもう少しスケールアップする必要があるかもしれません。ユーザーデータベースは重要で不可欠なので、さらにスケールアップする必要がありますが、製品データベースは読み書きの量がもっと管理しやすいので、同じようにチューニングする必要はないかもしれません。繰り返しになりますが、通常、データ領域は顧客とのスケーリングの課題に焦点を当てる部分です。ここで、「特定のデータニーズに対して、目的に合わせて構築されたデータベースを検討する必要があるか」と考えるべき時期になります。実際に、キーバリューストアに入れられる非リレーショナルデータがあるのか、ドキュメントストアに入れるべきドキュメントデータがあるのか、あるいは時系列データがあるのかを考える必要があります。
データをどこに置くか、それに適したデータベース製品は何かを考えることが重要です。繰り返しになりますが、この分野に深い専門知識がない場合は、AWSのチームに頼ることをお勧めします。Solution Architectsがデータディスカバリーやデータマッピングの演習を一緒に行い、ユースケースに基づいて適切な製品を選択するお手伝いをします。通常、データベース層の分割に続いて、アプリケーション層の分割を検討します。私はいつもデータから始めて、それからアプリケーション層に進むことをお勧めします。少し似たようなアプローチになります。例えば、単一のAWS App Runnerアプリケーションがあった場合、今度は複数のApp Runnerアプリケーションを持つことができます。
ここで直面する課題は、これらをどのようにつなぎ合わせるかということです。つまり、異なるサービスをクライアントにどのように公開するかを考える必要があります。Amazon API Gatewayには、ベースパスマッピングと呼ばれる便利な機能があります。これにより、APIの異なる部分を異なるバックエンドにマッピングすることができます。単に異なるLambda関数を持つだけでなく、文字通り異なるチームに委任することができます。「あなたはこのパスを担当し、あなたはAPIのそのパスを担当する」というように。もう一つ考えなければならないのは、完全に異なる技術パターンに移行することです。インフラ内部で内部マイクロサービス用のAPIを公開することが最適ではないかもしれません。APIを使用した同期モデルから、他の方法で接続する非同期モデルに移行することを検討する必要があるかもしれません。
これも、今週のServerlessトラックで非同期について考えるような素晴らしいトークを聞くことができる分野です。Serverlessトラックやアプリケーション統合トラックでも、この話題に関する他のセッションがあります。
従来のモデルを考えると、2つの異なるサービスがあり、同期的な世界にいるとします。Service AがService Bを呼び出し、Service BがService Aに応答し、そしてクライアントに戻ります。ここには密接な結合があり、脆弱性があります。これらの青い矢印の一つ一つが、障害からの回復を考慮しなければならない潜在的な領域となります。
2番目のモデルでは、非同期アプリケーションを使用しています。クライアントがService Aを呼び出し、Service AがService Bを呼び出しますが、Service AはService Bの作業を待たずに応答します。これは、注文サービスと請求書サービスの例で考えるとわかりやすいでしょう。 この非同期モデルでは、注文サービスが請求書サービスを呼び出し、「はい、クライアントさん。処理が完了しました。こちらが注文IDです」というような形で応答します。その後、クライアントは次のサービスに対して別のリクエストを行うことができます。このように分離することで、アーキテクチャ内の密結合を減らすことができます。
以前、私はここでServerlessの開発者アドボカシーをリードしていました。そこでは、お客様と同期型と非同期型について多くの時間を費やして議論していました。Serverlessアプリケーションを構築した優れた企業、例えばLegoのような企業を見ると、彼らが非同期モデルに大きくシフトしたことで、アプリケーションに対する考え方が根本的に変わったことがわかります。これは、スケールについて全く異なる視点で考えることを可能にします。ですので、アーキテクチャ内のコンポーネント間の動きを見直し、同期型から非同期型モデルへの移行を検討することで、密結合を解消できる可能性があることを強くお勧めします。
APIからAPIへの呼び出しだけでなく、 Service AからService Bへイベントを渡すことができる多くのサービスがあります。アプリケーション統合スイートの一部として、Amazon Simple Notification Service（SNS）、Amazon Simple Queue Service（SQS）（実はAWSの最初の製品です。これはトリビアクイズの答えになりますね。2003年にAWSの最初のプレビュー製品として登場しました）、異なるサービス間のメッセージバスハブとして機能するAmazon EventBridge、そして大量の情報を高速で取り込み、スケールアウトできるKinesis Data Streamsなどがあります。
これら4つの製品には重複する部分もあり、ある程度同じように使用することもできます。しかし、それぞれが特に優れている明確なユースケースがあります。今週、ServerlessやApp Integrationのトラックのセッションをチェックすることをお勧めします。そこでは、永続性、耐久性、リトライ、コストモデル、消費モデルについてより深く考える方法が紹介されています。これらの製品の中から、異なるサービス間に配置するものを選ぶ際には、考慮すべき多くの要因があります。
最終的に、私たちのアーキテクチャはより複雑なものへと進化していきます。これは実際の顧客の図ではなく、直接会話から再現したものでもありませんが、このような種類のアーキテクチャを目にすることは十分に考えられます。そして、それに圧倒されたり心配したりする必要はありません。この図で示しているのは、基盤となるインフラストラクチャについて考える必要のない、多数のマネージドサービスです。これらのほとんどすべてが、スケーリングやマルチAZでの復旧オプションなど、自動化された機能を持っています。繰り返しになりますが、これらについて心配する必要はありません。
1000万ユーザー以上のスケーリングと将来の展望
さて、ここで仮定として、私たちはアプリケーションを分解し、これらのマネージドサービスのスケーラビリティ機能を活用しています。サービスを異なるコンポーネントに分割し、フロントエンドは私たちがあまり手を加えなくても引き続きスケールし続けています。そして、AWSで1000万ユーザーを超えるという当初の目標に到達できます。ここからどこへ向かうのでしょうか？この時点以降のことは、少し独特な様相を呈し始めます。
まず最初に、私たちが話してきたパターンをさらに展開していくことです。例えば、Uberのような企業では、全く同じように見える何千ものマイクロサービスがあり、同じタイプのスケーリングパターンに従っています。Amazonの内部でも非常に似たことを行っています。私たちの多くの製品は、内部的には全く同じように見えます。私たちは確立したパターンを何度も繰り返し使用しています。特定のブレークポイントがある場合、それに対応します。
スタックのパフォーマンスを深く掘り下げる能力を常に持っていることが重要です。観測可能性ツール、モニタリングツール、コードプロファイリングツールは、どこをスケールするか、どのようにスケールするかなどを理解する上で非常に重要かつ不可欠になります。そして、「ねえ、実はこの規模でこれらのものを運用する方が理にかなっているんじゃないか」と言う時点に達する可能性もあります。率直に言って、Lambdaは AWSで計算能力を購入する最も高価な方法ですが、TCOと長期間にわたってそれらを管理する必要がないことが非常に素晴らしいため、Lambdaを使用します。しかし、「そうだね、その責任を取り戻したい。活用したい規模の経済がある」と言う時点が来るかもしれません。
ただし、それが意味を持ち始めるのは、スケールラインの本当に先の方になります。
そして、無限大へ。最後に、私はこの講演のバリエーションをAWSで約10年間行ってきました。そして、常に改訂を重ねてきました。10年前や5年前にこの講演で話したことは、今日できることと比べると古めかしく見えるでしょう。サーバーレスと呼ばれるもの、つまり手動のインフラストラクチャ管理から離れ、Auto Scalingのようなリソースを自分で扱う必要がなくなるようなことについて、常に考えることができます。
クラウドにおける今日のスピードは、10年前とは全く異なります。 CPU、ストレージ、メモリ、ネットワークは、かつてないほど高速になっています。そのため、キャッシングのようなテクニックを本当に考慮する必要があります。スケールを考える上で、多くの時間を節約できるのがここなのです。インフラのどこでキャッシュを行えるでしょうか？エッジ、アプリケーション、データベース層などが考えられます。データベースへのクエリを減らし、データベースの負荷を軽減することが、スケールを考える上で最も簡単な勝利の方法の一つとなるでしょう。
素早く簡単に成果を上げる方法として、フェデレーションがあります。安易な手法だと思われがちですが、ほぼ毎回うまくいく安易な手法なのです。「製品のスケールや同時実行性などの限界に達してしまった」というような痛みを和らげるのに本当に役立ちます。ニーズに基づいて最適な技術を探すことが大切です。ここではAWS App Runnerについて多く話しましたが、すでにApp Runnerが自分に合わないことがわかっている方もいるでしょう。それでも構いません。しかし、本当に小規模からスタートする多くの人にとっては、リソースや構築方法について考えなくて済むことの方が有益なのです。
以上で、この月曜日のAWS re:Inventセッションにご参加いただき、ありがとうございました。今週が素晴らしいものになることを願っています。毎年、これは本当に楽しいイベントです。ここにいられて本当にワクワクしています。私たちはこのアンケート結果を重視していますので、ぜひフィードバックをお寄せください。本当に感謝しています。 そして最後に、最も重要なこととして、Skyeに拍手をお願いします。彼女にとって初めてのre:Inventでしたが、素晴らしい発表だったと思います。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion