【ITニュース解説】急激なトラフィックスパイクでも落とさない ― 東京・大阪アクティブ/アクティブ構成×数万rps対応 AWS設計術

ITニュース概要

GMOコネクトが、秒間数万件もの高負荷に対応するAWS環境を構築した。東京と大阪で同時に稼働するアクティブ/アクティブ構成を採用し、急激なアクセス集中でもサービスが停止しないよう設計された技術を紹介する。

ITニュース解説

現代のウェブサービスでは、急激なアクセス集中、いわゆる「トラフィックスパイク」が発生することが珍しくない。例えば、テレビCM放映後や、特定のイベントが開催された際に、瞬時に多くのユーザーがウェブサイトやアプリケーションにアクセスする。このとき、システムが1秒間に数万回ものリクエスト（数万rps）を処理できなければ、応答が遅くなったり、最悪の場合、サービスが完全に停止してしまう事態に陥る。このような高負荷状況でもサービスを安定して提供し続けるためのAWS（アマゾンウェブサービス）を用いたシステム設計が、今回の記事のテーマである。 この設計では、システムの可用性（いつでも利用できること）と耐障害性（障害に強いこと）を極限まで高めるために、東京と大阪の二つのAWSリージョン（地理的に離れたデータセンター群）を同時に稼働させる「アクティブ/アクティブ構成」を採用している。これは、通常時から両方のリージョンでユーザーのリクエストを処理し、もし東京リージョン全体が大規模な障害に見舞われても、大阪リージョンが全ての処理を引き継ぎ、サービスを停止させずに継続できるようにする仕組みだ。これにより、予測不能な大規模災害時でも、ユーザーは常にサービスを利用できる状態が保たれる。 ユーザーがウェブサイトにアクセスする際、まずそのドメイン名（例: example.com）をコンピュータが理解できるIPアドレスに変換する必要がある。この役割を果たすのがAWSのDNSサービス「Route 53」である。Route 53は、アクセス元のユーザーの場所に応じて、最適なリージョン（東京か大阪）へリクエストを振り分ける賢い機能を持っている。これにより、ユーザーは地理的に最も近いデータセンターに接続され、通信の遅延が最小限に抑えられる。 次に、リクエストは「CloudFront」と呼ばれるCDN（コンテンツデリバリーネットワーク）サービスへと送られる。CloudFrontは、ウェブサイトの画像や動画、JavaScriptファイルなどの静的なコンテンツを、世界中のユーザーに近い場所に一時的に保存（キャッシュ）する。これにより、ユーザーはより高速にコンテンツを取得できるだけでなく、オリジナルのサーバーへの直接的なアクセスを大幅に減らすことができる。特にトラフィックスパイク時には、多くのリクエストがCloudFrontで処理されるため、バックエンドのシステムへの負荷が大きく軽減され、システムの安定稼働に貢献する。また、CloudFrontの前段には「AWS WAF（ウェブアプリケーションファイアウォール）」が設置され、悪意のある攻撃からシステムを保護している。 CloudFrontを通過し、動的な処理が必要なリクエストは、「ALB（Application Load Balancer）」というロードバランサーに到達する。ALBは、複数のアプリケーションサーバー（ここでは後述のECS Fargate）に対してリクエストを均等に振り分ける交通整理役だ。特定のサーバーに負荷が集中するのを防ぎ、システム全体の処理能力を高めるだけでなく、サーバーの稼働状況を常に監視し、もし一部のサーバーに異常が発生しても、自動的にそのサーバーへのリクエストを停止し、健全なサーバーにのみリクエストを振り分けることで、サービスの継続性を確保する。 ALBからリクエストを受け取り、実際にアプリケーションのビジネスロジックを実行するのが「ECS Fargate」で稼働するアプリケーションサーバー群である。ECS Fargateは、アプリケーションをDockerコンテナという軽量な仮想環境で動かすためのサービスであり、サーバーのOSや基盤の管理をAWSに任せられるため、運用負荷が大幅に軽減される。さらに、アクセス負荷に応じてサーバーの台数を自動的に増減させる「オートスケーリング」の機能も備えている。これにより、急激なトラフィックスパイクが発生しても、システムが自動的に必要なリソースを確保し、アクセスが落ち着けば自動的にリソースを縮小することで、コスト効率も維持しながら高負荷に対応できる。アプリケーションサーバーは、AWSのネットワーク環境である「VPC（Virtual Private Cloud）」内の「プライベートサブネット」に配置され、インターネットから直接アクセスできないよう、セキュリティが強化されている。 アプリケーションがユーザーのリクエストを処理する際、多くの場合、データはデータベースに保存され、そこから読み書きされる。この設計では、高性能かつ高可用性を持つデータベースサービス「Aurora Serverless v2」が採用されている。Auroraは、大量のデータ処理に強く、データのバックアップや障害回復の仕組みも組み込まれている。特に、データベースへの読み込み処理が多くなる場合、複数の「リードレプリカ」（読み込み専用のデータベースのコピー）を作成することで、読み込み負荷を分散させ、データベースのボトルネックを防ぐ。 さらに、頻繁に参照されるデータをデータベースまで取りに行かずに高速に処理するために、「ElastiCache」というキャッシュサービスが導入されている。ElastiCacheは、高速なメモリ上にデータを一時的に保存することで、データベースへのアクセス回数を減らし、アプリケーションの応答速度を大幅に向上させる。これにより、データベースへの負荷が軽減され、特に高負荷時にはシステム全体のパフォーマンス維持に不可欠な役割を果たす。 ユーザーがアップロードした画像や動画、アプリケーションが出力するログファイルなど、静的なファイルは「S3（Simple Storage Service）」に保存される。S3は、非常に高い耐久性と可用性を持ち、どれだけ大量のファイルを保存しても安定して利用できるオブジェクトストレージサービスだ。 これらのサービスはすべてVPC内で構築され、セキュリティグループやネットワークACLといった機能によって、ネットワークレベルでのアクセス制御が厳重に行われている。東京リージョンと大阪リージョン間の通信は、「Transit Gateway」などのサービスを使ってセキュアに接続され、データの一貫性や同期が保たれている。 このシステム設計の根底には、いくつかの重要な思想がある。一つは「多重化」であり、どのコンポーネントも単一の障害点とならないよう、複数のリソースを用意することで障害耐性を高めている。次に「シンプル化」であり、複雑な構成を避け、運用やトラブルシューティングを容易にすることで、システムの安定性を保つ。そして「フェイルファスト」という考え方だ。これは、障害が発生した際に、その影響が広がる前に速やかに異常を検知し、問題を切り離すことで、システム全体のダウンタイムを最小限に抑えることを目指している。 まとめると、このAWS設計は、急激なアクセス集中やリージョン規模の障害といった、現代のウェブサービスが直面しうるあらゆる困難に対し、極めて高いレベルで対応できる堅牢なシステムを構築するためのものだ。Route 53、CloudFront、ALB、ECS Fargate、Aurora、ElastiCache、S3といったAWSの多岐にわたるサービスを適切に組み合わせ、多重化、シンプル化、フェイルファストといった設計思想を貫くことで、常に安定してユーザーにサービスを提供し続けることを可能にしている。システムエンジニアを目指す者にとって、このようなクラウドを活用した高可用性・高負荷対応の設計知識は、これからの時代に不可欠なスキルとなるだろう。