押忍ッ！
好きなひらがなは「ぬ」、ぬむるです。

はじめに

JAWS DAYS 2025に行ってきました。

JAWS DAYSとは、JAWS-UGというAWSユーザーが集まった組織が主催する、AWSに関連した大規模なイベントです。

AWSに関わる幅広いテーマでセッションやワークショップが行われます。

私はアーキテクチャ道場に参加してきました。

アーキテクチャ道場は、AWS上での最適なアーキテクチャ設計を学習するための実践的なワークショップです。

 

参加いただいているみなさんで4名1組でチームを組み、講師から出されたお題に対してチームで協力しながらアーキテクチャの設計・検討を進める「グループワーク形式」を採用しています。

クラウドアーキテクチャのベストプラクティスを考慮しながら、限られた時間内でより適切なソリューションを導き出します。

 

参考：https://jawsdays2025.jaws-ug.jp/sessions/D-6

 

そこで出されたお題にあった要件の中から、私が気になったキーワードは…

＿人人人人人人人人人＿
＞ スパイクアクセス ＜
￣Y^Y^Y^Y^Y^Y^Y^Y￣

です。

 

 

 

人は、無知であることは恥ずかしいことではありません。

だって最初は皆、無知から始まりますからね。

恥ずかしいのはそう、

「あ～はいはい、スパイクアクセス（？）ね、はいはい（？？？）………えー、と、、、（泣）（泣）（泣）」

こういう態度です。

 

ええ、私です。

 

当日は元気な返事（はい！分かりました！はい！仰せのままに！）と肯定（めっちゃ良いと思います！うわ、凄いですね！その通りだと思います！素晴らしいです！）しかやれることがなかったので、イベントは終了しましたが今から巻き返しを図りたいと思います。

 

ということで、ここからは

  • スパイクアクセスについて
  • スパイクアクセス対策
  • スパイク対策に有用なAWSサービス

についてまとめていきます。

 

よろしくお願いします！押忍！

 

スパイスアクセスとは

スパイクアクセスとは、短期間でアクセスが急増することです。

アーキテクチャ道場では、水族館の予約システムにおいて、ホホジロザメの人気とともに土日祝の予約可能となったタイミングでスパイクアクセスよるサイト停止が発生していました。

 

人気の結果じゃん！嬉しいじゃん！ハピハピハッピー！♡になりますか？

いいえ、サイトが停止することで困ることも結構あるようです。

 

  1. 経済的損失　
    顧客は予約ができないため、せっかくの機会を失うことになります。
    サイトは注目時こそ見れないと意味がないヨ！仏の顔も三度まで！お客の顔は一度まで！

  2. 信頼性低下
    「あのサイトは繋がりにくい」という噂は嬉しくありません。
    ビジュ（デザイン）とパフォーマンス（安定性）を兼ね備えた、最高のアイドルのごときプロ意識でいきましょう。

  3. 復旧コスト & 運用負担の増加
    サイトが落ちた場合、エンジニアはすぐに対応しなければなりません。
    えッ！仕事増えるの聞いてないよ！私は帰るよ！

 

このように、サイトが見れなくなることによる被害は大きいものになります。
次からは、その原因となるスパイクアクセスへの対策を考えていきましょう！

 

スパイクアクセス対策

有効な対策

  • CDNの導入
    CDNとは、Webサイトやアプリなどのコンテンツをキャッシュサーバーに一時的に保存し、ユーザーの最も近くにある拠点から配信する仕組みです。

    キャッシュサーバーが代理でｴｯﾎｴｯﾎと働くので、Webサーバーはゆったりお茶を飲んでいられます。
    この結果、スパイクアクセス時でも安定したレスポンスを維持することができます。

 

  • 負荷分散
    負荷分散とは、アクセスを複数のサーバーに振り分け、一箇所に負荷が集中しないようにする技術です。

    特定のサーバーが「もう無理です…；；」となったら悲しいので、みんなで分担してチームプレーをします。負荷分散で優しい世界を目指しましょう。

 

  • オートスケーリング
    オートスケーリングとは、サーバーの負荷状況に応じて、インスタンス数を自動で増減させる機能です。

    負荷分散しても、そもそもの仕事量が多かったら意味ありません。スパイク時は助っ人を召喚し、通常時に戻ったら解散します。
    また、手動対応が不要なので運用負担も削減できます。

 

  • 非同期処理
    非同期処理とは、ある処理が終わるのを待たずに、次の処理を進める方式のことです。

    みんなを一気にさばこうとするとサーバーがパンクしてしまいます。
    来た人から整理券を渡しておき、処理を行える状態になったら順番に対応します。

 

あまり有効ではない対策

 

 

こういうことに気を付けて構築を行うと、ユーザーも「あれ…？イイじゃん👍✨」と思ってくれます。
One lookでgive ’em Whiplashされない、盛れてる構成を考えよう！

 

スパイクアクセス対策に有効なAWSサービス

私の指は5本あります。
よって、ここでは5つに絞って、スパイクアクセス対策に有効なAWSサービスをご紹介します。

 

①CloudFront

【どんなサービス？】

  • 静的および動的なウェブコンテンツを迅速かつ安全に配信するCDNサービスです。

 

【メリット】

  • キャッシュを活用し、Webサーバーへのリクエスト数を削減できます。
  • キャッシュサーバー（世界各地のCDN拠点）から配信するため、応答速度が向上します。

 

【設定のポイントは？】

  • キャッシュポリシーを最適化して、どのリクエストをキャッシュするか適切に設定すること。
  • WAF（AWS Web Application Firewall）と組み合わせて、不正アクセスを防止など、セキュリティ強化すること。

 

②ELB

【どんなサービス？】

  • ロードバランサー（負荷分散装置）サービスです。

 

【メリット】

  • リクエストを複数のサーバーに分散し、単一サーバーへの過負荷を防ぎます。
  • システムの可用性とスケーラビリティを向上させます。

 

【設定のポイントは？】

・Amazon EC2 Auto Scalingと組み合わせると、システムの可用性・拡張性がさらに向上します。

 

③AWS Lambda

【どんなサービス？】

  • リクエスト数に応じてオートスケーリングを行うサーバーレス コンピューティングサービスです。
  • サーバーのプロビジョニング（準備）や管理を行わずにコードを実行できるため、運用負担を大幅に削減可能です。

 

【メリット】

  • リクエスト数に応じてオートスケーリングするため、突発的なアクセス増にも即時対応です。同一アカウントの同一リージョンあたり1,000の同時実行が可能です。
  • サーバー管理が不要なため、インフラ運用の手間を削減します。
  • 使用した分だけ課金される従量課金制なので、コスト最適化が可能です。

 

【設定のポイントは？】

  • 「プロビジョンド同時実行数」の設定を行うこと
    • プロビジョンド同時実行数：Lambda関数が即座にリクエストを処理できるよう、あらかじめ指定した数の環境を起動状態にしておく機能のこと。
      通常はリクエストが来た時に初回起動の遅延が発生しますが、プロビジョンド同時実行数を設定することでレスポンス遅延を防ぐことができます。

  • SQSとの連携でスパイク負荷を平準化すること。

 

④Amazon SQS

【どんなサービス？】

  • メッセージキューイングサービスです。
  • 処理を一時的にキューに入れて、バックエンドの負荷を軽減できます。

 

【メリット】

  • 大量のリクエストが発生しても、キューに入れて処理を順番待ちにできます（負荷の平準化）。
  • バックエンドの処理能力を超えるリクエストが直接届かないため、サーバーダウンを防げます。
  • API GatewayやLambdaと連携することで、完全サーバーレスな非同期処理が可能です。

 

【設定のポイントは？】

  • 「FIFOキュー」と「標準キュー」を使い分けること。

FIFO（First-In-First-Out）キュー

    • APIアクションのコール回数は、バッチ処理を使用する場合は 1 秒あたり最大 3,000 件のメッセージを処理し、バッチ処理を使用しない場合は 1 秒あたり最大 300 件のメッセージをサポートします。
    • メッセージの順番を厳密に保持します（予約処理など、順番が重要な場合に使用）。
    • 同じメッセージを重複して処理しません。

標準キュー

    • APIアクションのコール回数は、1 秒あたりほぼ無制限の件数のメッセージをサポートします
    • メッセージの順序は保証されません。
    • 少量のメッセージ重複が発生する可能性があります。

 

⑤API Gateway

【どんなサービス？】

  • APIの作成・管理・運用を行うフルマネージドサービスです。
  • APIを通じてリクエストを処理する際に、認証・認可・アクセス制御・トラフィック管理を一元的に行います。
  • API Gatewayは、デフォルトで10,000リクエスト/秒まで処理可能で、さらに最大5,000リクエストのバースト容量を提供します。

 

【メリット】

  • リクエストを適切に制限し、過剰なアクセスによるバックエンドの負荷を軽減します。

 

【設定のポイントは？】

  • 無制限にアクセスされることを防ぐために使用料プランを作成すること。
    • 使用料プランを作成することで、スロットリング設定として「レート（1秒あたりのリクエスト数）」、「バースト（同時リクエスト送信数）」や、クォータ（特定の期間内のリクエスト可能数）を制限することができます。

 

 

スパイクアクセスに耐える予約システムの構成を考えてみた

ここまでに紹介したAWSサービスを使って、スパイクアクセスに耐える予約システムの構成を考えてみました。
それぞれのサービスの役割と設定のポイントについても解説していきます。

 

CloudFront

CDNサービスとして、静的コンテンツ（画像、CSS、JavaScriptなど）をキャッシュし、オリジンサーバーへのリクエストを削減します。
これにより、応答速度を向上させ、スパイク時の負荷を軽減します。

📝ビヘイビアのキャッシュポリシーにおいて、動的コンテンツ（API Gateway）と静的コンテンツ（S3）への設定を適切に行い、キャッシュの適用範囲を最適化することが重要です。

📝S3バケットへのアクセスはOAC（オリジンアクセスコントロール）を使用することで直接アクセスを禁止し、Cloudfront経由でしかアクセスできないよう制限できます。

 

WAF（AWS Web Application Firewall）

WAFはボットやDDoS攻撃などの不正リクエストをブロックし、システムの安定性を確保するWeb アプリケーションファイアウォールです。
これにより、短時間で大量のアクセスが集中するスパイク時でも、不正なリクエストによる負荷を最小限に抑えることが可能です。

📝レートベースのルールを設定することで、発信元IPアドレスの秒間リクエスト数をカウントし、上限を超えたIPアドレスをブロックすることができます。

📝WAFをCloudFrontに適用することで、エッジロケーションで不正リクエストをブロックし、オリジンサーバーへの負荷を削減できます。

 

API Gateway

API Gateway がバックエンドの入り口となり、リクエストの適切なルーティングやレート制限を実施します。
スパイク時の負荷をコントロールしながら安全に API を管理します。

📝使用料プランを適切に設定することで、予期しない大量のリクエストからバックエンドを保護します。

 

S3

S3は大量のデータを安全・安価に保存できるシンプルなストレージサービスです。
ここではHTML、CSS、JavaScriptなどのフロントエンドの静的ファイルをホスティングします。

📝CloudFrontと組み合わせることで、キャッシュによる高速配信とオリジンサーバーの負荷軽減が可能です。

 

Amazon SQS

予約リクエストをFIFOキューに入れ、バックエンド処理の負荷を平準化します。
スパイクアクセス時でも安定した予約処理を実現します。

📝FIFOキューで設定することで、メッセージの順番を厳密に保持しつつ予約処理が可能になります。

 

Lambda

キューにたまったリクエストを Lambda が順番に処理します。
サーバーレスのため、負荷に応じて自動スケールし、大量のリクエストにも対応可能です。

📝Lambda関数がSQSキューをポーリングする際のスケールアップ速度について、1分間に最大300の同時実行を追加し、最大1,250の同時実行数にスケールアップが可能です。

📝スパイク時、Lambda関数がリクエストを処理できるよう「プロビジョンド同時実行数」を設定します。

 

DynamoDB

予約情報を保存するNoSQLデータベースです。
適切なキャパシティモードの選択により、安定したパフォーマンスを維持できます。

📝オンデマンドキャパシティモードを選ぶことで、新しいテーブルは1秒あたり最大4,000回の書き込みと12,000回の読み込みを維持でき、必要なリクエスト数に応じて自動スケールも行うためスパイクアクセスに対応可能です。

 

 

 

いかがでしょうか？

「Ummm…イイじゃん👍」という声が聞こえてきそうです。

今回はブログの構成上、シンプルなアーキテクチャとなりましたが、処理完了を伝えるメールや通信の暗号化などの要素を盛り込んでみてもいいかもしれません。

とはいえ、スパイクアクセスに耐えられる骨太な構成になったのではないでしょうか。

まだまだブラッシュアップの余地はありますが、「今の自分が考えられるベストなアーキテクチャ」 になったと思います！

 

 

まとめ

今回の学びを通じて、スパイク対策には「適切なAWSサービスの組み合わせ」と「負荷をうまくコントロールする設計」が大切だと改めて感じました。

JAWS DAYS では知識不足でチームの力になれなかったものの、結果的に自分でアーキテクチャを考える良い機会になりました。

今回考えた構成も、なかなかいい感じなのではないでしょうか？ 

道場でも「アーキテクチャに正解はない」と言っていましたが、まさにその通りだと思います。

これからも勉強を続けて、より良い設計ができるようになりたいと思います！

読んでくださった皆さんも、一緒にSo good~~~♪なアーキテクチャを考えてみませんか？