Talk

ライブエンタメのチケット販売や会場物販、ECでは、熱狂的なファンが販売開始と同時にアクセスし、販売プラットフォーム全体で数分間に100万件を超えるリクエストが発生します。一方、クラウドプラットフォームの提供するオートスケーリングでは、アクセス増加の検知からコンテナ起動まで約5分かかり、増設が完了する頃にはピークを過ぎてしまいます。

そこで、外部ID基盤とのプロトコル変換で販売開始時のログインを支えるRailsアプリケーションに、Fiberを活用するRack対応アプリケーションサーバ「Falcon」を使えないか検討しました。Pumaは外部API待ちにもスレッドを使いますが、FalconはFiber Scheduler対応のHTTP通信を待つ間に別のFiberへ処理を切り替えられます。定常時のコンテナ数を増やさず、短時間のピークを効率良く処理できる点に着目しました。

このトークでは、既存のRailsアプリケーションへのFalcon本番導入を紹介します。既存のgemとHTTP通信の見直し、PumaとFalconを並行稼働させた段階導入、切り戻せる状態で比較・評価を進めた方法をお話しします。Falconと新しいHTTPクライアントを組み合わせた構成のレイテンシとCPU使用量、移行中の500エラー、運用上の注意点を、具体的な本番データで共有します。