11
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

metapsAdvent Calendar 2022

Day 11

チケット販売サイト アクセス集中対策

Last updated at Posted at 2022-12-10

はじめに

株式会社メタップスのアドベントカレンダー11日目の記事です。

メタップスの子会社であるメタップスペイメント社のチケット販売サービス「チケットペイ」では、販売するイベントによっては販売申し込み開始時に大量のサイトへのアクセスが発生します。

本記事では、チケットペイにて行っている負荷対策についてご紹介します。

環境

RDB: MySQL

基盤: AWS

本記事で登場するAWSサービス: CloudFront, Aurora MySQL, SQS, ALB, ECS

CDN(CloudFront)の利用

CloudFrontの利用がアクセス負荷対策の効果が一番大きいです。

全リクエストの大体4/5がCloudFrontから返却されるようになっています。

ビヘイビア設定では、パスパターンにjs,css,画像のパスを指定し、S3上にファイルがある場合はS3にリクエストさせ、ホストに配置してあるファイルはキャッシュ上から取得させるようにしています。

キャッシュポリシー CachingOptimizedAllQuery は、デフォルトである CachingOptimized のポリシーをベースにしており、クエリ文字列が異なる場合は実際のファイルを取得するようにしています。※ファイルアクセス時にクエリ文字列まで含めてリエスとさせており、ファイル更新時はクエリ文字列部分が変更されるような更新運用を行っています。

image.png

その他は、エラーページ設定を行っております(後述)

image.png

RDB(MySQL)のパラメータ設定

以前アクセス集中し、DBへの負荷が上昇した際、

以下の記事にある server has gone away のエラーが発生したため、記事に記載されているように max_allowed_packet の値を 20M に設定し wait_timeout も 60 に設定しました。

この設定変更により、同様のエラーは発生しなくなりDBアクセスが安定しました。

スケールアップ・スケールアウト対応

アクセス集中することが予め分かっているような場合は、事前にスケールアップ・スケールアウト計画を立て、当日に実行します。アクセス集中するのはチケット販売開始直後の僅かな時間なので、アクセスが落ち着いてきたらスケールダウン・スケールインさせます。コストを最小限に抑えるためにこのような手法を採っています。

ALB

ALBについては事前に暖機申請を行います。

参考:

直前に申請を行っても対応できないこともあるので、余裕を持って申請する必要があります。

ECS

Fargateではなく、 ECS on EC2を利用しているので、Auto Scaling グループにて容量(台数)を増加します。

台数は過去実績を元に、ある程度余裕を見て決めます。

インスタンスタイプをスケールアップする場合は、新たな起動テンプレートを作成しAuto Scaling グループに設定します。

RDB

通常、xlargeのインスタンスをライター1台リーダー1台で稼働させています。

アクセス集中時はインスタンスタイプをスケールアップさせ、リーダーインスタンスは2〜4台程度に増加させます。

ライターをスケールアップする際はフェイルオーバーが必要ですので、その間は一時的にALBにてサイトをメンテナンス状態に変更します。

アプリケーション側の対策

RDBへの接続は、ライターに負荷が集中しないよう、参照系のクエリはリーダーインスタンスに接続するように制御しています。これでリーダーインスタンスの台数を増やすことによって負荷分散が行えます。

また、アプリケーション処理時に外部へ接続するような場合はその外部サイトへの負荷がかかり、処理遅延になってしまう可能性があります。

そこで、外部へ接続するような処理の場合は同期処理から、AWS SQSを利用し非同期処理になるよう実装を変更しました。

AWS SQSの選定理由としては、AWSマネージドであることと、他にもSQSを利用しており実績もあり実装にも慣れているため実装コストもそこまでかからなかったためです。

その他の対策

基盤設定も重要ですが、他にも対策できることがあります。

例えば、チケット申し込みには会員登録が必要になっているため、事前に会員登録をしていただくようアナウンスをして登録を促しておくことも対策です。

また、「抽選」の申し込みであればチケット販売開始時に殺到して申込みをする必要はないので、販売事前説明にて申込みタイミングによって抽選結果は変わらないことを伝えておくようなことも有用だと思われます。

万が一、予想を超えるような負荷が発生し、502 Bad Gateway のようなエラーになってしまう場合、Sorryページにはメッセージだけではなく、デザインを入れておくことによりユーザの心象を損なわないようにするようなことも必要です。

sorryページの設定は前述のCloudFront上で行っております。

image.png

11
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?