re:Invent 2024: AWSスタートアップチームが語る1000万ユーザーへのスケーリング戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Scaling on AWS for the first 10 million users (ARC201)
この動画では、AWSのスタートアップチームのSolutions ArchitectであるChristineとSkye Hartが、1,000万ユーザーまでスケールするためのアーキテクチャパターンを解説しています。初期段階ではAmplify Hosting、AWS Fargate、Amazon Aurora Serverless v2を組み合わせた3層アーキテクチャから始め、1万ユーザーを超えると段階的にアーキテクチャを進化させていきます。特に100万ユーザーを超える段階では、Read Replicaの活用やRDS Proxyの導入、ElastiCacheによるキャッシング、そしてMicroservicesへの分割が重要となります。また、Event-drivenアーキテクチャへの移行においては、Amazon SNS、SQS、EventBridge、Kinesis Data Streamsなど、目的に応じた使い分けのポイントも具体的に解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
1,000万ユーザーへのスケーリング：AWSアーキテクチャの基本
こんにちは。AWSのスタートアップソリューションアーキテクトのChristineです。同じくスタートアップチームの上司であるSkye Hartと一緒に登壇させていただきます。私たちは多くのスタートアップからスケーリングについての相談を受けています。スタートアップにとって非常に一般的な課題ですので、本日は1,000万ユーザーまでスケールするためのAWS上での一般的なアーキテクチャパターンとガイダンスについてご紹介できることを嬉しく思います。
まずは状況設定からお話ししましょう。 Skeyeとわたしがスタートアップの創業者で、ゼロからアプリケーションを立ち上げようとしているとします。具体的な実行方法はまだ決まっていませんが、1,000万ユーザーにサービスを提供できるようにしたいと考えています。 まず、アプリケーションとは何かを定義することが重要です。大企業であれば、製品群の中の1つの製品を指すこともあれば、スタートアップの場合は製品全体を指すこともあります。今回のセッションでは、3層構成のWebアプリケーションについて話をします。具体的には、モバイルアプリやブラウザとインターフェースできるフロントエンド、すべてのビジネスロジックを持つバックエンド、そしてすべてのデータを保存するデータストレージ層を持つものを想定してください。皆さんの中には、現在このようなアプリケーションを開発していない方もいらっしゃるかもしれませんが、ここでご紹介するパターンを自身のビジネスやアイデアに応用していただければと思います。
続ける前に、現在の技術トレンドについて触れておく必要があります。テクノロジーの状況は常に変化しています。最新のフロントエンドフレームワークはJavaScriptを使用し、開発を容易にするフルスタックフレームワークが存在し、多くのスタートアップが自前のインフラストラクチャから、クラウドやマネージドサービスへと移行しています。インターネットやソーシャルメディアの影響で、アプリケーションは数日どころか数時間で急激にバイラルになる可能性があるため、急速なスケールに対応できる必要があります。初日から高いスケーラビリティを備えたアーキテクチャを設計することは難しいですが、今回はそれに挑戦してみましょう。
最初のアーキテクチャが最終形ではないという考え方を持つことが非常に重要です。最初に構築したアーキテクチャは、1年後、2年後、そしてそれ以降の本番環境のアーキテクチャとは異なる可能性が高いのです。私たちは「Build-Measure-Learn」というサイクルを繰り返します。最初のアーキテクチャから始めて、ユーザーのフィードバックに基づいてそのアーキテクチャのパフォーマンスを測定し、そこから学んでアーキテクチャに変更を加えていきます。これは継続的な改善のサイクルであり、後ほどご覧いただくように、1つのアーキテクチャから始めて、スケールに応じて構築と改善を重ねていきます。
Day 1アーキテクチャ：フロントエンドとバックエンドの設計
では、1日目から始めましょう。現時点で私たちが知っているのは2つです：3層構成のWebアプリケーションを構築すること、そして「今は構築して、後で改善する」というマインドセットを持つことです。 1日目は、おそらくSkeyeと私だけが使用し、1、2人のベータテスターがいるかもしれません。この時点では、大量のトラフィックは想定していません。 では、もう少し深く掘り下げて、どのように構築していくか考えてみましょう。フロントエンド、バックエンド、データストアを1つの大きなインスタンスで実行する代わりに、デカップリングについて考えていきます。まず、フロントエンドとバックエンドのデカップリングから始めましょう。
それでは、フロントエンドについてどのように考えていけばよいか見ていきましょう。これまでは、多くの人がAmazon EC2から始めていました。EC2上でWebサーバーをホストし、必要に応じて需要に対応するためにAuto Scaling groupを設定し、共有ストレージレイヤーとElastic Load Balancerを配置する、といった具合です。
Elastic Load Balancerはトラフィックを効率的に分散でき、Amazon CloudFrontのようなCDNを使用することで、キャッシングを通じてページの読み込み速度を向上させることができます。 先ほど見たように、人気のあるフレームワークには変化が起きています。開発者体験を向上させ、フロントエンド技術に適応するため、フロントエンドホスティング専用のサービスやツールが登場してきました。そこで活躍するのがAmplify Hostingです。
Amplify Hostingはサーバーレスサービスなので、基盤となるインフラストラクチャの管理を心配する必要はありません。コードを書くことに集中するだけで、ニーズや要件に合わせて自動的にビルドやスケーリングが行われます。最新のフロントエンドフレームワークとの深い統合により、開発者体験が大幅に向上し、始めるのも非常に簡単です。 Amplify Hostingでは、GitHubなどのリポジトリに接続し、ユニットテストなどのビルド設定を行うだけで、面倒な管理作業なしにアプリケーションをデプロイできます。これだけで、スケーラブルなフロントエンド環境を実現できるのです。
AWSでは常にカスタマーから発想を始めており、 この場合は特に開発者の視点に立っています。開発者からのフィードバックと経験に基づいて、Amplify Hostingの機能セットを構築しました。Amazon S3での静的Webページホスティングだけでは実現できない、ブランチデプロイメントやアトミックデプロイメントなどの機能が利用できます。ここでも、フロントエンドホスティング専用サービスの台頭が見られます。現在、多くの初期段階のスタートアップがAmplify Hostingを利用しており、 これは3つのタイプのアプリケーションをサポートしています：Reactアプリのようなクライアントのブラウザで読み込まれるClient-side renderedアプリケーション、Nextのようなフレームワークを使用してブラウザに送信される前にサーバー上でレンダリングされるServer-side renderedアプリケーション、そしてCDNと組み合わせてホストできる静的コンテンツ用のStatic site generatorアプリケーションです。
バックエンドとデータベースの選択：スケーラビリティを考慮して
フロントエンドについて説明しましたが、バックエンドについてはどうでしょうか？バックエンドのホスティングには何を使うべきでしょうか？ コンピュートには複数のオプションがあります。クラウド上の仮想マシンを提供するAmazon EC2について説明しましたが、コンテナエコシステムとしてAmazon ECS、KubernetesのためのAmazon EKS、AWS Fargateがあり、さらにイベント駆動型アーキテクチャ向けのサーバーレスコンピュートオプションとしてAWS Lambdaがあります。
コンピューティングのオプションを評価する際、 Amazon EC2をバックエンドとして使用するだけでもかなりのことができます。多くの人がこのアプローチから始めます。しかし、欠点も明らかになってきます。つまり、バックエンド全体を単一のインスタンスで実行することで、いわば「卵を一つのかごに盛る」ようなものです。確かにそれでも機能はしますが、フェイルオーバーや冗長性に課題が生じます。データベースもそこに置く場合、個々のコンポーネントをスケールできないため、バックエンドがデータ層を圧迫したり、逆にデータ層がバックエンドを圧迫したりする可能性があります。
それに加えて、 インスタンスの管理も課題となってきます。スケールアップやダウンを考えると面倒な作業になるかもしれません。より大きなインスタンスサイズに移行することもできますが、やはり冗長性の課題は残ります。そこで私たちが推奨するのは、バックエンドにマネージドコンピューティングを活用することです。
コンピューティングオプションを選択する際、EC2が最適な選択とは限りません。Amazon ECSやAmazon EKS - つまりコンテナエコシステムについてはどうでしょうか？アプリケーションの設定方法やスケーリングの制御など、考慮すべき点が多くあります。Fargateは、サーバーの管理を気にしたくない人にとって素晴らしいサービスです。そして、コードに集中し、インフラストラクチャのプロビジョニングや管理なしで実行したい人のためにAWS Lambdaがあります。
これらのサービスを見ると、より意見の強いサービスが上位に、より柔軟なサービスが下位にあります。このリストを下に行くほど、マネージドコンピューティングに関して考慮すべき事項が増えていきます。AWS Lambdaでは、アプリケーションコードだけを気にすれば良いのですが、Fargate、Amazon ECS、Amazon EKS、Amazon EC2と下に移動するにつれて、追加のタスクを担当する必要が出てきます。私たちのガイダンスとしては、中間点あたりから始めることをお勧めします。
具体的には、 フルマネージドのコンテナオーケストレーターである、Amazon ECS（Elastic Container Service）をお勧めします。AWSサービスやDockerなどのサードパーティツールと統合されており、チームが環境自体ではなくアプリケーションの構築に集中しやすくなっています。基盤となるコンピューティングとして、Amazon EC2インスタンスまたはAWS Fargateを使用できます。今回は、AWS Fargateを使用していく予定です。
AWS Fargateは、サーバーの管理を気にする必要のないサーバーレスコンピューティングエンジンです。仮想マシンのグループのプロビジョニング、設定、スケーリングを心配することなく、アプリケーションの構築に専念できます。Fargateは、Fargateタスクと呼ばれる概念を中心に設計されています。タスクとは、アプリケーションの実行方法に基づいて実行されるコンテナの単一インスタンスを表します。Fargateでは、特定の数のインスタンスを割り当てることを心配する必要はありません。環境に基づいたタスクごとの全体的なコンピューティングとメモリの要件だけを考慮すればよいのです。
まとめると、フルマネージドのコントロールプレーンとしてAmazon ECSがあり、基盤となるコンピューティングとしてAWS Fargateがあります。セキュアな設計で自動スケーリングも容易なため、AMIのパッチ適用やアップグレードを心配する必要はありません。これはバックエンドの一側面ですが、フロントエンドにビジネスロジックを公開するにはどうすればよいでしょうか？
APIを構築する際には、いくつかの選択肢があります。最も一般的なのは、REST API向けに特別に設計されたAmazon API Gatewayです。レイヤー7プロキシであるApplication Load Balancerや、GraphQLベースのAPIをホストするためのAWS AppSyncもあります。 APIの選択は要件次第です。WebSocketやスロットリングなどの機能が必要な場合は、Amazon API Gatewayを選択できます。単一のAPIメソッドだけであれば、Application Load Balancerの使用を検討してください。また、処理する必要のあるリクエスト数も考慮すべきです。これらはすべて、APIフロントサービスを選択する際に考慮すべき重要な問題です。
では、全体を見てみましょう。フロントエンドではAmplify Hostingサービスを使用し、バックエンドではAWS Fargateを使用しています。すべてがフルマネージドで運用の負担を心配する必要がなく、素晴らしい構成になっています。ビルトインのスケーリング機能があるため、アプリケーションのスケーリングを心配する必要もなく、全体的に開発者体験に適した構成となっています。
1万ユーザーから100万ユーザーへ：スケーリングの課題と対策
では、データベースについてはどうでしょうか？ 大きな問題は、リレーショナルデータベースを使うか、非リレーショナルデータベースを使うかということです。現在では、想像できるほぼすべてのデータベースに対応するサービスが存在します。NoSQLの非リレーショナル、時系列データベース、グラフデータベースなどがあります。では、どのデータベースを使うべきでしょうか？ 私たちのガイダンスは、SQLデータベースから始めることです。 SQLは確立された、よく知られた技術です。多くの大学の授業で取り上げられ、コミュニティには豊富な資料や情報が既に存在しています。そして、最初の100万ユーザーでSQLデータベースが破綻することはありません。簡単に始められながら、最初の100万ユーザーまでサービスを提供できる利点があるのです。
リレーショナルデータベースは大量のデータを扱えないから使えないと主張する人たちがいるでしょう。 「そうそう、大量のデータって言ったでしょう。うちがまさにそうなんです。リレーショナルデータベースじゃ対応できないから、今のうちに最適化しておく必要があります」と言う方もいるかもしれません。 でも、「大量のデータ」って具体的にどのくらいの量なのでしょうか？1年目から複数テラバイトのデータを扱う予定ですか？データ処理の負荷が非常に高いワークロードになりますか？もしそうであれば、NoSQLが必要かもしれません。ですが、Build-Measure-Learnのサイクルに立ち返って考えると、アーキテクチャの最適化は時間をかけて進めることができます。最初の1年で確実に複数テラバイトのデータを扱うことが分かっているのでない限り、今すぐ非リレーショナルデータベースを検討する必要はないのです。
では、NoSQLや非リレーショナルデータベースが必要となる他のケースを見てみましょう。例えば、高頻度取引のような超低レイテンシーが求められるアプリケーションでは、非リレーショナルデータベースが必要かもしれません。ただし、これはかなり特殊なワークロードです。確かに超低レイテンシーが必要なアプリケーションは存在しますが、99%のケースではそこまでの低レイテンシーは必要ありません。また、高度に非リレーショナルなデータを扱う場合や、本質的にスキーマレスなデータを扱う場合にもNoSQLデータベースが必要になることがあります。ただし、これらもかなり特殊で限定的なユースケースです。このような要件が絶対に必要だと分かっている場合を除いて、基本的にはSQLデータベースから始めることをお勧めします。
今回使用するSQLデータベースは、Amazon Auroraです。Amazon AuroraはMySQLとPostgreSQLをサポートするリレーショナルデータベースで、データはリージョン内の3つのAvailability Zoneにまたがって保存される耐久性の高いサービスです。さらに、完全マネージド型のサービスなので、パッチ適用やデータベースのセットアップ、バックアップについて心配する必要がありません。マネージドデータベースサービスとして、本当に優れたサービスと言えます。 より具体的には、Amazon Aurora Serverless v2を使用します。私たちは常にサービスの改善と進化を続けています。
Amazon Aurora Serverless v2の特徴は、データベースクラスターのコンピュートとストレージを分離していることです。これにより、キャパシティの需要やアプリケーションのニーズに応じて、コンピュートとストレージをそれぞれ個別にスケールできます。
では、これまでの内容をまとめてみましょう。 フロントエンドにAmplify Hosting、バックエンドにAWS Fargate、そしてデータベースにAmazon Aurora Serverless v2を使用します。このスタックなら、インフラストラクチャの管理を最小限に抑えながら、かなり長く使っていけます。スケーラビリティはすでに組み込まれており、スケーリングを助けるための調整機能も備わっているので、あまり心配する必要はありません。さらに、シングルリージョンでのMulti-AZ構成により、高可用性も確保されています。
アプリケーションを構築し、テストを行った後、ベータテスターを1人か2人導入するかもしれません。口コミで広がり、時間とともにユーザー数が数百人、あるいは数千人に達することもあります。そして、アプリケーションは順調に成長していきます。すべてが順調に見えますが、1万人のユーザーに達すると、問題が発生し始める可能性があります。
ここからの規模拡大について、Skyeに説明を譲りたいと思います。ありがとうございます、Christine。皆さん、聞こえていますでしょうか？私はSolutions Architect Managerを務めているSkye Hartです。これから、1万ユーザーから1,000万ユーザーへの拡張について説明させていただきます。Christineが初期アーキテクチャの基本要素について素晴らしい説明をしてくれましたが、私は問題が発生し始めるところから説明を引き継ぐことになり、とてもワクワクしています。
皆さんはご存じないかもしれませんが、Amazon.comも最初はモノリシックでした。私たちも自社のビジネスで、問題が発生し始める様子を目の当たりにしてきました。Amazon.comで当初見られた主な問題の1つは、新しい製品機能が複雑になり、開発者同士が互いの作業を妨げ始めたことでした。次に、アプリケーションの一部での性能低下が他の層に影響を与え、大量のデータベースクエリがフロントエンドに影響を及ぼすようになりました。そして当然ながら、データ量が増加するにつれて、この設計したアーキテクチャは、スケールと成長フェーズを通じて持続可能ではなくなっていきました。
100万ユーザーを超えて：データベースとバックエンドの進化
Christineと同様に、フロントエンド、バックエンド、データストレージ層について詳しく説明していきますが、その前に非常に重要なことについてお話ししたいと思います。会場の皆さんは手を挙げていただけますが、アプリケーションを開発している方で、「アプリが遅い」「レイテンシーの問題がある」「スループットの問題がある」と顧客から言われたことはありませんか？社内のお客様や社外のお客様が不満を持っているのはなぜでしょうか？私は数え切れないほど多くのお客様から「なぜこんなことが起きているのか」と聞かれ、「ログを見せていただけますか」とお願いすると、ログを取っていないということがありました。
スケーリングを始める前の基本的なステップとして、アプリケーションのあらゆる側面の可観測性とモニタリングについて話す必要があります。AWSには、可観測性とモニタリングの取り組みをサポートする多くのサービスがあります。ここでいくつか紹介させていただきます：Amazon CloudWatchとAWS X-Rayです。X-Rayはアプリケーション全体のエンドツーエンドのトレーシングに特化しています。CloudWatchは皆さんの強い味方となり、ロギング、ダッシュボード、パフォーマンスなどのアラートを設定する際に、あらゆる段階で重要な役割を果たします。
それでは、スケールに向けたチューニングについて、データインサイトの観点からお話ししていきましょう。これは先ほどの「何が起きているのか」というお客様の質問に関連します。今やダッシュボードがあり、可視性が確保できているので、スケーリングを始める前にこれらを有効にしておくことをお勧めします。多くの場合、お客様は「コンピュートを増やそう」「ノードを追加しよう」といった一時しのぎの対応を考えがちです。しかし、適切なチューニングを行い、実際に何が起きているのかを理解することで、より良い方法で問題に対処できます。単にお金をかけて問題を解決するのではなく、アプリケーションの根本的な問題に取り組むことができるのです。
それでは、各コンポーネントについて詳しく見ていきましょう。まずはフロントエンドから始めます。実は先日、Amplify Hostingチームと話をする機会があり、「限界点はどこにあるのか」「Amplifyはどこまで対応できるのか」という質問をしました。
彼らの説明によると、理論上の限界はないとのことでした。なぜなら、Amplifyは世界中に550のポイントオブプレゼンスを持つCDNであるCloudFrontを基盤としているからです。CloudFrontは15年以上の実績があり、世界中のお客様により近い場所で情報を提供することができます。Amplifyのスケーリングに関しては、自動スケーリングの多くを自動的に処理してくれます。私の画面で示しているように、キャッシュヒット率など、調整可能な要素もあります。お客様によく利用される画像のキャッシュ設定を調整したり、フロントエンドコードをチューニングしたりすることでパフォーマンスを向上させることができます。
私は以前データベースエンジニアをしていました。特に、これまで以上にデータ量が増える段階では、スケーリングが非常に重要になってきます。スケーリングには垂直スケーリングと水平スケーリングという複数のアプローチがあります。垂直スケーリングについて、私はこれまでのキャリアでPostgreSQL RDSを使ってきました。Auroraの強みは、コンピュートレイヤーとストレージレイヤーが分離されていることです。この分離により、両レイヤーを個別に自動検出してスケーリングします。Auroraは ACUをベースに構築されており、下位層は2ギガバイトのメモリを持つ1 ACUから始まり、最大で128 ACUまで拡張できます。また、後ほど説明する複数のRead Replicaを持つことができます。
Auroraはスケーリングの際にどのような要素を考慮しているのでしょうか？CPU使用率、メモリ使用率、ネットワーク使用率など、様々なインサイトを常時測定しており、スケールアップだけでなくスケールダウンも行います。Black Fridayセールなどのピーク時にはスケールアウトし、その後の低負荷時期にはスケールバックダウンする必要がありますが、これらのパターンを自動的に識別します。最終的に、垂直スケーリングの限界に達すると、スケールアウトが必要になります。Auroraは最大15のRead Replicaをサポートし、ReadとWriteのプライマリに合わせたTier 0と1のシステムを使用します。これにより、社内向けデータベースと、より重要な外部向けデータベースのように、重要度に基づいてデータベースを分類することができます。また、Auroraはマルチ AZに対応しており、高い稼働時間、回復力、耐久性を実現します。
Auroraのスケールアウトにおいて、 RDS Proxyを追加することになります。RDS Proxyはしばらく前から利用可能で、15個のRead Replicaクラスターと多数のオープン接続がある場合に必要不可欠となります。Proxyはアプリケーション層とデータベース層の間に位置し、これらの接続を集約してパフォーマンスを向上させます。アーキテクチャ上でどのように組み合わさるのか、お見せしましょう。 Primaryと複数のRead Replicaがデータ層の横に接続された形で、RDS Proxyが配置されているのがわかります。このようにスケールアウトを続けることができますが、最終的に 15個のReadノードと最大ACUに達した後は、追加のソリューションが必要になります。
データベースエンジニアとしての経験から言えば、最高のデータベースクエリとは、頻繁に実行する必要のないクエリです。これは キャッシングによる自動化につながります。Amazon ElastiCacheは、この目的のための専用サービスで、MemcachedとRedisという2つのオプションを提供しています。ElastiCacheは手動での設定が必要ですが、セルフヒーリング機能を備えています。全体を組み合わせると、データベースからElastiCacheを配置し、アプリケーションとバックエンド間に RDS Proxyを設置し、そこからRead Replicaを拡張していく形になります。この構成により、より多くのトラフィックとデータスケールを処理できるようになります。
ここで、データ層をスケールする3つの主要な方法をまとめましょう：ノードサイズを増やす垂直スケーリング、アプリケーションの軽微な変更を必要とする水平スケーリング、そして最も頻繁に実行されるクエリを特定して理解し、それらをエンドユーザーの近くにキャッシュする方法です。これらがデータ層をスケールアップする3つの主要な方法です。
ここで少しバックエンドについて話しましょう。 AWS Fargateに関して、実際にKubernetesを大規模に使用していたお客様と仕事をした経験があります。彼らはKubernetesに非常に情熱的でしたが、アプリケーションを迅速に移行する必要がありました。お客様は、Fargateが多くの管理タスクを担当するため、最も迅速にデプロイできる方法だと述べました。Fargateで600%のスケールを達成できました。スケールアップ後、実際に彼らはKubernetesに戻りました。迅速なデプロイの観点から、Fargateは簡単な設定と セルフヒーリング機能、Auto-scaling機能を提供します。セルフヒーリングとは、不健全な特定のタスクを識別して置き換えることができる機能です。 マネージドサービスに詳しい方はご存知の通り、多くの基盤となる設定を管理する必要があり、そのような制御とスケールは、アーキテクチャがさらに発展するまでは必要ないでしょう。
ここでバックエンドのスケーリングについて、 スケールアウトできる3つの異なるコンポーネントと方法があります：遅いデータベースクエリの削減、CodeGuruのようなツールを使用したコードのプロファイリングによるプロセスの自動化、そして可能な限りのキャッシング。私たちは10万ユーザーを抱え、期待が高まり、バイラルな広がりを見せ始めました。Read Replicaを活用した3層アーキテクチャだけで、100万ユーザーまで達成することができました。 ある時点で、複雑さの限界を超えることになります。100万ユーザーの場合、アプリケーションの複雑さと将来の成長を考慮する必要があります。amazon.comを例に考えてみましょう - ショッピングカート機能、プロファイリング、パーソナライゼーションなど、これらすべての機能が、データベース書き込みを使用する異なる部門の理解を必要とし始めます。Primaryは1つしかないため、それがボトルネックになり始め、そこで目的別データベースについて検討する必要が出てきます。
1,000万ユーザーへの道：マイクロサービスと非同期処理の導入
re:Inventでは、Microservicesとモノリシックアーキテクチャに関する多くの講演が行われていますが、アプリケーションをMicroservicesに分割し、デカップリングする方法について、私たちがお客様にアドバイスしている主な2つのアプローチを簡単にご説明します。それは、データドメインマッピングとビジネス機能マッピングです。データドメインマッピングは、データベースを見て、データ構造やスキーマの共通点を特定し、それを分離・分割します。2つ目のビジネス機能マッピングは、ビジネスの異なる領域や組織のパターン、構造を考慮するアプローチです。
データベースフェデレーションも非常に重要になってきます。ここでVPCを見ていただくと、ユーザーデータベース、製品データベースなど、異なるデータベースがあります。リレーショナルデータベースを異なる機能ごとに分割していく様子がわかります。これは、利用するさまざまなスキーマやテーブルに関して、クエリの面でも負荷分散の面でも役立ちます。多くの人がこのコンポーネントを見落としがちです。
次に、機能をNoSQLに移行する話題に移りましょう。DynamoDBの使用に関して多くの質問を受けました。ホットテーブルが必要な場合や、ペタバイト規模のデータが入ってくる場合に、リレーショナルデータベースがNoSQLに移行するのは一般的なパターンです。また、キーストアやIoTデータ用のタイムシリーズデータベースなど、より目的に特化したデータベースへのシフトも見られます。Data LakeやData Mesh、非構造化データと構造化データの活用が増えていく傾向にあり、特にAI/MLアプリケーションの台頭とともにその傾向は強まっています。一つのソリューションですべてを解決できるわけではありませんし、そうあるべきでもありません。目的に応じて特別に設計されたデータベースがあり、 それらの異なるタイプを組み合わせて使用することになるでしょう。
さて、ここからバックエンドの分割を始めていきます。私はいつもデータから始めて、そしてアプリケーションがそれに従う形で進めています。新しいフェデレーテッドサービスに分割したり、どのマネージドコンピューティングが最適かを見直したり（私のお客様はFargateから始めて、最終的にチームが最も慣れているものを選択しました）、あるいはLambdaをServerlessアーキテクチャで使用したり、どのビジネスロジックを内部サービスに移行できるかを検討したりします。
Serverlessアーキテクチャにおける同期処理から非同期処理への移行について話しましょう。 一般的な同期コマンドパターンでは、クライアントがサービスAを呼び出し、サービスAがサービスBを呼び出し、そしてサービスBからの応答がサービスAを経由してクライアントに戻ってくるまでに時間がかかります。一方、より多くの設定と時間を必要とする非同期の考え方では、クライアントがサービスAを呼び出し、サービスBに行く必要がある前にサービスAが応答を返します。
Order ServiceとInvoice Serviceの例を通じて、サービス間の呼び出し方とその非同期的な考え方への移行について考えてみましょう。 このようなビジネスの移行は、すべて機会費用の観点から考える必要があります。パターンや通信方式、設定の変更を理解するには確かに時間がかかりますが、Event-drivenアーキテクチャへの移行を進める上で、長期的には大きな助けとなります。
実装方法についてですが、主要な4つのサービスがあります： Amazon Simple Notification Service（Amazon SNS）、Amazon Simple Queue Service（Amazon SQS）、基本的にバスとして機能するAmazon EventBridge、そして高速なデータ移動を支援するAmazon Kinesis Data Streamsです。これらのサービスをどのように選択すればよいのか疑問に思われるかもしれません。 そこで、簡単な選択ガイドをご紹介します。大規模なスループットとデータの順序付けが必要な場合は、Kinesis Data Streamsが非常に強力です - Kinesisファミリー全体がストリーミングデータに適しています。最小限のファンアウトとリクエストのバッファリングには、Amazon SNSとAmazon SQSを使用します。1対多のファンアウトには、Amazon EventBridgeが適しています。これらのサービスは組み合わせて使用することができ、機能の重複は大きいものの、それぞれが特定のアーキテクチャのニーズに合わせて設計されています。
ここで、一見すると複雑に見えるスライドをお見せしますが、心配する必要はありません。これは実際の顧客の例ではありませんが、よく見られるパターンです。フロントエンドからバックエンドまで、Purpose-builtなデータベースやEventBridgeを使用した通信システムへとファンアウトしていく様子が分かります。この段階では、ビジネス要件や製品のニーズに基づいて、それぞれ独自のアーキテクチャを構築することになります。
そして、ついに1,000万ユーザーに到達しました！ この規模になると、顧客のシステムは大きな差別化と独自性を持つようになります。内部Microservicesに対するさまざまなニーズが生まれ、スタック全体のパフォーマンスを深く分析して改善点を見つける必要が出てきます。自己管理型のコンピュートへの移行を開始し、全階層でのキャッシング戦略を評価することになるでしょう。
最後に、今日お話しした3つの重要なポイントをまとめたいと思います。 第一に、私たちは現在、より良い立場にいます - 同僚のChrisは13年間このプレゼンテーションを行ってきましたが、製品や機能の継続的な改善と進化が見られます。活用できるスケーラビリティが組み込まれており、コンピュートとストレージを分割・分離するためのリソースも増えています。第二に、スケーリングの成功の大部分は、より少ない作業で達成されます - マネージドサービスを活用することで、インフラのチューニングや自己修復に時間を費やすのではなく、アプリケーションやコード開発により多くの時間を費やすことができます。第三に、リファクタリングは慎重に評価してください - 簡単に達成できる改善点を選び、ニーズに最適なPurpose-built技術を探し、継続的にテストと改善を行っていくことが重要です。
本日のプレゼンテーションにご参加いただき、また1,000万ユーザーを目指す私たちの旅にお付き合いいただき、誠にありがとうございます。皆様がre:Inventで素晴らしい時間をお過ごしになることを願っております。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion