高スパイク耐性のアプリを少人数で量産 。TwoGate 社がライブエンターテイメント業界で信頼を獲得した秘訣

TwoGate は、会場物販モバイルオーダー「Caravan」、オンラインくじ「Slash Gift +」、ホワイトラベル型チケットプレイガイド「Triple」、ファンアプリ「CRAYON」をはじめとし、50を超えるライブエンターテインメント業界のアプリケーションを提供するスタートアップです。

ライブエンターテインメント業界ではライブの物販・チケット・ファンクラブ運営・デジタルくじ等々、 ファン接点が多様化し、一度のピークアクセスが桁違いに跳ね上がるという難題があります。TwoGate は、社員約 43 名、エンジニア16名、うちインフラ専任のエンジニアは2名というというコンパクトな体制ながら、AWS のマネージドサービスやそのスケーラビリティを活用しその難題を解決、時に秒間50000を超えるスパイクアクセスが発生した際も安定したサービスを提供し、ドーム〜スタジアム級アーティストの全国ツアーを支えてきました。

今回は、アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部 アカウントマネージャーの Sherry Zhu とソリューションアーキテクトの 冨山英佑 が、TwoGate 取締役 CTO の奥本 隼 氏に、TwoGate が少人数ながらも効率的にスケーラブルなアプリケーションを提供する秘訣について、お話を伺いました。

短期間で、落ちないアプリケーションの提供が必要

Sherry：ライブエンターテインメント業界でのソリューション提供には特有の課題があると認識しているのですが、どのようなものがありますか？

奥本：イベントを中心としてその周辺の色々なものが動くところです。イベントがあるから、CD 販売がある。イベントがあるから、事前通販があるといった具合です。それらはイベントを起点として付随的に決まるため、我々がサービスを提供するまでには往々にしてスピード感が求められます。一方で、アーティスト独自の世界観も表現したいという難しさがあります。

TwoGate 社 取締役 CTO 奥本隼 氏

Sherry：大規模アクセスについてはどうでしょうか？

奥本：そうですね、どのタイミングでスパイクアクセスが来るかは予測可能ですが、どれくらいの量のアクセスが来るかは予測不可能です。やはりトラフィックが集中するのは先着販売型の商品の販売開始時刻です。ファンの方々が身構えており、販売開始時刻の直前からお客様のリロードが始まるので、多い時は秒間あたりのリクエストが50000件を超えることもあります。

Sherry：インターネットでの先行販売のほかに、会場販売の方はどうでしょうか？

奥本：イベント当日の販売でも怖い思いをしたことはあります。サーバーの負荷の部分に加えて、決済のレートリミットを超えてしまったり。お客様の温度感が高く、会場の規模に対して想定外に大きなリクエストが来たこともありました。そのような想定外に対してどのようにリカバーできるようにしておくのか対策しておく必要があります。

年間障害0を達成した、スパイク耐性の高いアーキテクチャ構築

冨山：TwoGate さんの開発されたアプリケーションの概観やアーキテクチャについて教えてください。

奥本：一般的な Web 三層アーキテクチャをとっています。入り口の CDN の後段に Application Load Balancer (ALB) があります。Amazon ECS では Fargate でウェブサーバーとアプリケーションサーバーが動いています。バックグラウンドジョブを実行するワーカーは ECS on EC2 で実装しています。データベースには Amazon Aurora PostgreSQL を使用しています。画像系の静的アセットは Amazon S3 + AWS CloudFornt で配信しています。

冨山：スパイクアクセスに耐えるために、アーキテクチャにはどのような工夫をされていますか？

奥本：秒間数万リクエストが来るような際には、CDN の裏の ALB にも秒間約8000リクエストが到達することもあります。最近では ALB は LCU 予約が可能になりましたが、それまでは ALB の暖気申請をあげ、キャパシティを確保していました。Web サーバー・アプリケーションサーバーをホスティングしている ECS on Fargate では、オートスケーリングを有効にしています。加えて、スパイクアスセスにはやはりオートスケーリングでは追いつかないので手動でスケーリングして対策しています。今後、イベント開始時刻から自動的にスケーリングを行う工夫はするかもしれません。それでも予測できないトラフィックの増加が来た際には、たとえスケールが数分遅れたとしても回復する能力を持たせられるよう、オートスケーリングは重要です。実際これまでにもオートスケーリングがなければ危なかったような瞬間がありました。

Sherry：そのような対策を講じることでどのような成果がありましたか？

奥本：試行錯誤を繰り返していくうちに、アーキテクチャがチューニングされていきました。2~3年前は年に2,3回危ない思いをしたことはありましたが、直近１年では障害0に抑えています。東京ドームでの公演だったり、7万人が入る日本最大級の日産スタジアムでの2日間の公演も先日無事に終えることができました。

少人数でも複数のアプリケーション・テナントを効率的にデプロイ・管理

冨山：エンジニア16名、うちインフラエンジニア2名という、比較的少数のエンジニアで、数多くのプロダクト・テナントを管理されているとのことですが、その秘訣は何でしょうか？

奥本：インフラについては社内共通の Terraform があって、必要に応じて部分的にリプレイスしながら再利用しています。また、新しくテナントを追加する上で必要な手続きは、極力、非エンジニアでも実行できるような管理画面を用意しています。管理画面にロゴなどのテナント情報を入力すれば、新しいアーティスト用の箱が動くような工夫をしています。デザインが揃えば、最短で1日でアプリケーションを用意することが可能です。

アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部 アカウントマネージャーの Sherry Zhu （写真左）ソリューションアーキテクト 冨山 英佑（写真右）

Sherry：運用負荷を減らすという側面ではいかがでしょうか？

奥本：基本サーバーレスっぽく動かしたいというのが基本方針です。例えばスケーリングの観点で EC2 と Fargate を比較した際に、EC2 ではホストマシンのスケーリングとコンテナ数のスケーリングの両方を考えなければいけない一方、Fargate はサーバレスのためインフラレイヤーのスケーリングを考慮しなくても済み、EC2 よりもスケーリング速度が速いことがわかりました。そのため、スケールが重要なアプリケーションでは Fargate を使うようにしています。

今後のビジネス的な展望・技術的挑戦

冨山：ビジネス観点での今後の展望はございますか？

奥本：これからますます規模を拡大したいと考えています。また、弊社のアプリケーションはマルチテナントということもあり、他のお客様に迷惑をかけないためにも、システムの安定性というところは我々のミッションだと考えています。

奥本：また、現在はそれぞれのアプリケーションが独立して動いていますが、それらを横断するような共通の会員基盤を開発しています。アプリを横断して個人情報や購買データを管理・分析できるような基盤を実現したいと考えています。

冨山：技術的な観点では、今後の改善予定や、解決したい技術課題などはございますか？

奥本：Aurora for PostgreSQL は、現状ではプロビジョンドオンデマンドインスタンスを使用しており、ハイシーズンに大きめなインスタンスをプロビジョンするなどして対応していますが、夜間などはトラフィックが静かなので、将来的に Aurora Serverless を使用して自動でスケーリングさせることも検討しています。Aurora Serverless のスケール速度がトラフィックのスパイク速度に追いつけるかどうかは今後テストしていこうと考えています。

また、スパイクトラフィックへの耐性だけでなく DR も考えていく必要があると考えています。仮に AWS に障害が起こったとしても今日のイベントは進んでいきますので、それも含めて乗り越えられるような仕組みを構築していく必要があります。我々は約10年AWSを使ってきましたが、幸いにも AWS の障害によって影響を受けたことはほとんどなく、非常に安定していると感じます。この業界では実績ベースで信頼を獲得できる特性もあるため、我々のアプリケーションが安定していることが、お客様に信頼してもらえている理由でもあると感じています。

Sherry：ほかにも今後取り組まれることはございますか？

奥本：開発側では、今後 Amazon Bedrock などを活用して AI を用いた開発にますます取り組んでいこうと思っていたところです。この領域は明日明後日にはまた何か変わっているような世界観なので、まだ体系立てて話せないですが、、。また、お問い合わせ対応に AI を使用して自動化を進め、お問合せ対応に必要な人の手間を減らしていきたいとも考えています。

Sherry：素晴らしい取り組みですね。奥本さん、本日は様々な貴重なお話をお聞かせいただきありがとうございました。