くりにっき

フルスタックキュアエンジニアです

今更だけどアイカツ！16話のチケット5万枚を2秒で売り切るシステムについて本気で考察してみた

発端

普通の人は5万枚のチケットを一瞬でさばいた神崎美月さん*1の知名度に着目しがちですが、僕は職業柄システムの方が気になりました。

お前誰よ？

会社でインフラを見ています。業務でのインフラ歴は4〜5年くらい。社内だとAWSとGCP両方分かるマンとして認知されています。

前置き

ネタなので過度なツッコミは禁止

構成

webサーバ

チケット5万枚を2秒で完売させるためには雑な見積もりでサーバ数百台必要だと仮定します。

これだけの規模をオンプレミスで調達するのは大変なのでAWSやGCPなどのクラウドを使うことになると思います。

オートスケール（アクセス数やサーバの負荷に応じて自動でサーバを増減させる）という手もあるのですが、2秒で数百台までスケールさせるのはさすがに厳しいと思います。

参考：自社で運用してるシステムでGKEのオートスケールを導入しているのですがリクエスト数急増でサーバ5台増やすのに10分くらいかかっています。*2

チケット販売開始の日時はあらかじめ決まっているからその日時に合わせてあらかじめサーバをその台数まで増やして待機させておくのがベターでしょう。

これはAWSとGCPのどちらにも言えることですが、1つのAWSアカウントやGCPプロジェクトで作れるサーバの台数には上限があり数百台というのは初期状態では作れないのでサポートに問い合わせて上限緩和申請をすることになります。クラウド事業者や希望台数にもよってサポートでの対応完了日数が変わるのでなんとも言えないけど僕ならバッファ込で2〜3営業日くらいは見込みます。

データベース

チケットの在庫やチケットを販売したという情報を持つためにデータベースは必須です。（以降、データベース = RDBを前提に書きます。FirestoreやDynamoDBのようなKVSは知らん）

webサーバは横に並べることで負荷分散できるのですがデータベースは簡単に増やせないしオートスケールもできないのでここがボトルネックになりがちです。

AWSのRDS, AuroraやGCPのCloud SQLのようなフルマネージドなデータベースを使えばスケールアップ・スケールダウンはできるのですが、あくまでも手動だしスペック変更時に基本的に数分間のダウンタイムが発生するのでこれも予めつよつよスペックにしとく必要があります。

僕なら迷わず一番高いスペックを選びます。

決済システム

今日日自前で決済システムを持つことはあまりなく、決済専用の外部サービスを使うことが多いです。

自分のアプリケーション（チケット販売サイト）が秒間2.5万リクエストに耐えられてもその先の決済システムが耐えられないと思います。（2秒間に5万リクエストとかなんて下手なDDoSより量が多いし普通にネットワークで詰まるのでは...）

負荷試験

神崎美月さんといえばアイカツ界の超メジャーアイドル。そのライブチケットとなれば当然負荷も予測されるので負荷試験も必要でしょう。

負荷試験をしないと実際にどれだけのサーバ台数が必要なのか分からないので僕ならやります。

当日の監視

未曾有のアクセスが来るのが分かってるのであれば当日立ち会っての監視も当然やるでしょう。僕なら絶対やります

まとめ

余談

*1:https://dic.pixiv.net/a/%E7%A5%9E%E5%B4%8E%E7%BE%8E%E6%9C%88

*2:GKEだとpodをオートスケールする Horizontal Pod Autoscaler（通称HPA）とpodを収容してるnode（≒サーバ）をオートスケールするクラスタオートスケーラーの2種類のオートスケールがあるのですがここで言ってるのは後者の方です