WEBアプリケーションへのアクセス増加が見込まれるイベントに向けて準備したこと

本記事は  【Advent Calendar 2023】  21日目の記事です。
🎄  20日目  ▶▶ 本記事 ▶▶  22日目  🎅

はじめまして、小島と申します。

普段の業務では、WEBアプリケーションを運用するプロジェクトにリーダーとして参画をしています。

最近、担当しているWEBアプリケーションに対して、アクセス増加が予想されるイベントがありました。

本記事では、そのイベントに向けて準備したことについてまとめてみます。 今回はプロジェクトとして準備したことに絞っているため、アプリケーションの詳細や性能試験の詳細についての話は、省略させていただこうと思います。

はじめに

WEBアプリケーションについて

対象となるWEBアプリケーションの概要は下記の通りです。 24時間365日、誰でもアクセスできるシステムではありますが、通常時はあまりアクセスの多くないシステムになります。

• アプリケーションは、Amazon EKS 上のpodで稼働
• DBは、Amazon Aurora PostgreSQLを使用
• 他にも、Amazon CloudFront や ElastiCache・Elastic Load Balancing などを使用
• Direct Connect 経由でオンプレミスのDBを一部機能で使用

イベントについて

今回のアクセス増加が見込まれるイベントの概要は、下記の通りになります。

• 一般的に多少話題になるイベントであり、開始直後にアプリケーションでエラーが発生すると影響が大きい
• イベント開始のタイミングから数分間がピークとなり、急激にアクセスが増加（通常時の数百倍程度）
• ピークを超えると、徐々にアクセス数は減少するが、通常時よりはアクセスが多い状態が継続

アクセス数の予測と性能要件の設定(イベント当日まで10週間～8週間)

アクセス数（予測値）

事前準備は、まずどれくらいのアクセスが来るのか予測することから始めます。

精緻な予測をすることが難しい場合でも、目標を明確にすることが大切です。目標を設定せずに進んでしまうと、何を達成したら準備完了なのかが分からないため、終わりが見えなくなります。今回は、過去の類似イベントでの実績をベースに予測値を算出しました。

アクセス数（目標値）

どれくらいのアクセスが来るかという予測はできました。

ただし、あくまでも予測なので、当たることもあれば外れることもあります。外れる場合、予測を下回ってくれれば、アプリケーション的には安心ですが、当然予測を上回ってくる可能性もあります。そのため、今回は予測したアクセス数に安全係数（今回は1.2倍）をかけ合わせた値を、目標値として設定しました。

性能要件

最後に、目標値として設定したアクセスが来た際に、アプリケーションとして満たすべき要件です。

ここは、各アプリケーションやプロジェクト、業務要件によって異なってくると思います。今回は下記のような要件としました。

• 全てのリクエストに対してsorry画面やシステムエラー画面を返すことなく、正常に処理すること（エラー率0%）
• レスポンスタイムが、〇〇秒以内に収まること
• CPUやメモリ等の各種リソースの使用率が△△%以内に収まること

イベントの特徴的に、エラー率0%というところが一番重視する要件になります。

性能要件を満たす構成の検討(イベントまで8週間～6週間)

アプリケーションの性能確認

開発環境において、現在のアプリケーションの性能を確認します。

イベント時を想定したシナリオを作成し、JMeterを使用してWEBアプリケーションに対して負荷をかけることで確認しました。結果として、通常時の構成では、秒間〇〇件のアクセスを処理できるということかが分かりました。

性能要件を満たす構成案の検討

ここからは、性能要件を満たすには、どれくらいリソースを引き上げる必要があるかを机上計算で求めます。

精緻な計算は難しいので、目標値と現在の性能から、だいたい通常時の何倍くらいのリソースを準備すれば問題ないかを計算します。ここで作成した構成案が正しいかどうかを、次工程の性能試験で確認していきます。

今回は、下記の2点のリソースを拡張することで、性能要件を満たすことができると判断しました。

• アプリケーションレプリカの数
• RDSのインスタンスタイプ

性能試験(イベントまで6週間～2週間)

ここが、今回の準備のメインになります。

性能要件を満たすことができる構成案ができましたので、実際に目標値相当のアクセス数の負荷をかけて、実際に要件を満たすことができることを確認していきます。

性能試験の詳細や発生した課題への対応などは、まとめるとボリュームが大きくなってしまうため、割愛させていただきます。（また機会があれば別の記事で）

性能試験実施

性能試験は開発環境と本番環境それぞれをリソース拡張したうえで、複数回実施しました。

試験は、アプリケーションの性能確認時と同様、イベント時を想定したシナリオを作成し、JMeterを使用してWEBアプリケーションに対して段階的に負荷をかけていき、性能要件を満たすことができているか確認していきます。

開発環境だけでも、一定の確認はできますが、環境ごとの特性や差異もあるため、可能であれば本番環境での性能試験も実施すべきです。

発生した課題の解消と再試験

性能試験を実施すると、1回で目標を達成できることはあまりなく、いくつか課題が発生します。

今回も、大きいものから小さいものまで本当に多数の課題が発生しました。そして、原因が分からず解消までに時間がかかった課題もありました。

最終的には全ての課題を解消することができましたが、性能試験については十分に余裕をもったスケジュールを立てた方がいいと思います。

性能試験結果

性能試験を実施した結果、検討した構成で十分性能要件を満たすことが確認できました。

性能的には余裕があるくらいで、リソースを拡張する幅をもっと抑えることもできましたが、リスクとコスト面を検討したうえで、当初検討した余裕がある構成でイベント当日に臨むことになりました。

一時的にコストはかかりますが、特定の期間だけ余裕をもった状態にリソースを拡張できることは、AWSを使用することのメリットだと思います。

イベント当日までの準備(イベントまで2週間～1日)

リソース拡張

後はイベント当日までの準備です。

準備は可能な限り前日までに済ませておく方針として、1週間前くらいにpodの追加やRDSのインスタンスタイプ変更を実施しました。 この他にもElastic Load Balancingの暖気申請等も検討しましたが、今回は不要と判断したため実施していません。

このタイミングで、拡張したリソースをいつ通常の状態に戻すかについても決めます。今回は、イベントから1週間後に戻すことになったので、前後1週間ずつ、2週間の間リソースを拡張した状態を維持しました。

イベント当日

イベント当日は、もうやることはほとんどありません。

イベント開始直前に、念のためのアプリケーションのウォームアップと、イベント開始後に行うアプリケーションの状態監視や問題が発生した際の調査の準備をしておくくらいです。

ここまできたら、今までの準備を信じて、後は上手くいくことを祈るだけです。

さいごに

結果として、イベント当日は、目標値を超えるアクセスが発生しましたが、余裕を持った準備をしていたことで、大きな問題なく乗り切ることができました。

今回は、余裕を持ってイベントの約10週間前から準備を開始しましたが、想定外の課題が色々発生し、最終的には余裕がなくなりギリギリの状態でした。 ただ、余裕はなくなったものの、きちんと準備ができたことで、イベントを乗り切ることができたと思います。 このイベントは、今後も発生するイベントになります。次回は今回の実績があるので、もっとスムーズに準備をしていきたいです。