秒間 10,000 リクエストを "簡単に"いなすゲームサーバーを Laravel で作る設計

1秒間に PHP が受信する HTTP リクエストが最大 10,000 回以上———
そんな世界が存在します。その一つが 「ソーシャルゲーム」 です。メンテナンスが明けた瞬間、イベントが始まった・終わる瞬間、様々なタイミングでゲームサーバーは瞬間的に高負荷になります。もちろん、サービスをリリースし PR をたくさん出し始めたその瞬間が、プロジェクトで最も高負荷となるでしょう。それらに耐えうるサーバー構成が求められていますが、「リリース直後にサーバーがダウンした」「限定イベントが始まったらすぐ緊急メンテナンスが始まった」という話はちょくちょく聞こえてきます。その 瞬間的な高負荷(いわゆる "スパイク") に耐えるには、事前準備を怠らないことが重要です。
ソーシャルゲームにおいては、他の Web アプリケーションに比べ 書き込みヘビーなワークロード であることが多いです。読み込みは比較的簡単に分散できますが、書き込みを分散することは容易ではありません。
そういった要件を達成するため、私のチームで行っている、 Laravel による高負荷に耐えるサーバー設計をご紹介したいと思います。

Transcript

1. 秒間 10,000 リクエストを "簡単に" いなすゲームサーバーを Laravel で作る設計 やまゆ - PHPカンファレンス福岡2023
2. こんにちはー - 写真撮影/SNS投稿大歓迎！ - 後でエゴサして全部見させていただきます 👀 - #phpconfuk #hall_fu - 初九州・初福岡です！ - Ask the speaker お待ちしています！
3. 概要 1秒間に PHP が受信する HTTP リクエストが最大 10,000 回以上——— そんな世界が存在します。その一つが 「ソーシャルゲーム」 です。メンテナンスが明けた瞬間、イベントが始まった・終わ る瞬間、様々なタイミングでゲームサーバーは瞬間的に高負荷になります。もちろん、サービスをリリースし PR をたくさん 出し始めたその瞬間が、プロジェクトで最も高負荷となるでしょう。それらに耐えうるサーバー構成が求められています が、「リリース直後にサーバーがダウンした」「限定イベントが始まったらすぐ緊急メンテナンスが始まった」という話はちょ くちょく聞こえてきます。その 瞬間的な高負荷(いわゆる "スパイク") に耐えるには、事前準備を怠らないことが重要です。 ソーシャルゲームにおいては、他の Web アプリケーションに比べ 書き込みヘビーなワークロード であることが多いで す。読み込みは比較的簡単に分散できますが、書き込みを分散することは容易ではありません。 そういった要件を達成するため、私のチームで行っている、 Laravel による高負荷に耐えるサーバー設計をご紹介したい と思います。 - 高負荷案件でも Laravel は使えるの？と疑問に思う方 - どのようにスパイクをさばいているのかを知りたい方
4. 1 リクエスト クライアント サーバ
5. 1 リクエスト HTTP Req ｺﾝﾆﾁ ﾊ クライアント サーバ
6. 1 リクエスト ｺﾝﾆﾁ ﾊ クライアント サーバ ｺﾝﾆﾁ ﾊ HTTP Req HTTP Res
7. 1 リクエスト ﾜｰｲ クライアント サーバ ﾔｯﾀｰ HTTP Req HTTP Res Done!
8. 秒間 1 リクエスト クライアント サーバ
9. 秒間 1 リクエスト クライアント サーバ HTTP Req ｺﾝﾆﾁ ﾊ
10. 秒間 1 リクエスト クライアント サーバ HTTP Req ｺﾝﾆﾁ ﾊ HTTP Res ｺﾝﾆﾁ ﾊ
11. 秒間 1 リクエスト クライアント サーバ HTTP Req ｱﾘｶﾞﾄ ｲｴｲｴ HTTP Res Done!
12. 秒間 1 リクエスト クライアント サーバ HTTP Req HTTP Res Done! — 約 1 秒後 —
13. 秒間 1 リクエスト クライアント サーバ HTTP Req HTTP Res Done! — 約 1 秒後 — HTTP Req ﾏﾀｷﾀ ﾖ
14. 秒間 1 リクエスト クライアント サーバ HTTP Req HTTP Res Done! — 約 1 秒後 — HTTP Req ﾏﾀｷﾀ ﾖ HTTP Res ｿｳﾅﾉ
15. 秒間 1 リクエスト クライアント サーバ HTTP Req HTTP Res Done! — 約 1 秒後 — HTTP Req ﾏﾀｸﾙ ﾈ HTTP Res ｱｲﾖ Done!
16. 秒間 1 リクエスト クライアント サーバ HTTP Req HTTP Res Done! — 約 1 秒後 — HTTP Req HTTP Res Done! 以下続く...
17. クライアント サーバ 秒間 10 リクエスト
18. クライアント サーバ 秒間 10 リクエスト HTTP Req x 10 ｺﾝﾆﾁ ﾊ ｺﾝﾆﾁ ﾊ ｺﾝﾆﾁ ﾊ ｺﾝﾆﾁ ﾊ ｺﾝﾆﾁ ﾊ ｺﾝﾆﾁ ﾊ ｺﾝﾆﾁ ﾊ ｺﾝﾆﾁ ﾊ ｺﾝﾆﾁ ﾊ ｺﾝﾆﾁ ﾊ
19. サーバ 秒間 10 リクエスト HTTP Req x 10 HTTP Res x 10 ﾜｱ クライアント ｱﾘｶﾞﾄ ｵｵｷﾆ ﾀｽｶﾙ ﾔｯﾀ ｾﾔﾅ ｵｹ ﾜｰｲ ﾄﾞｳﾓ ｱｻﾞｽ ｳｨｯｽ
20. クライアント サーバ 秒間 10 リクエスト HTTP Req x 10 ｸﾚ ﾃﾞｰﾀ ﾎｼｲ ﾖｺｾ ﾏﾀﾞｰ ﾊﾖ ﾅﾆｼﾃ ﾝ ﾂｷﾞﾉ ｺﾚ ﾖﾛｼｸ HTTP Res x 10 ﾏﾀｷﾀ Done! HTTP Req x 10
21. クライアント サーバ 秒間 10 リクエスト HTTP Req x 10 ﾖｲｼｮ ﾔｯﾀ ﾄﾞﾓ ｻﾞｯｽ ﾜｰｲ ﾏﾀｸﾙ ﾈ ﾖﾛｼｸ ｺﾚﾀﾞ ﾌﾑ ｻﾗﾊﾞ HTTP Res x 10 ｲｿｶﾞｼ Done! HTTP Req x 10 HTTP Res x 10
22. クライアント サーバ 秒間 10 リクエスト HTTP Req x 10 ﾖｲｼｮ ﾔｯﾀ ﾄﾞﾓ ｻﾞｯｽ ﾜｰｲ ﾏﾀｸﾙ ﾈ ﾖﾛｼｸ ｺﾚﾀﾞ ﾌﾑ ｻﾗﾊﾞ HTTP Res x 10 ﾋｴｰ Done! HTTP Req x 10 HTTP Res x 10 以下続く... Done!
23. クライアント サーバ 秒間 100 リクエスト ｵｵｲﾅ HTTP Req x 100
24. クライアント サーバ 秒間 1,000 リクエスト ﾋｬｰ HTTP Req x 1,000 x10
25. クライアント サーバ 秒間 10,000 リクエスト (x x) HTTP Req x 10,000 x100
26. 秒間 10,000 リクエスト(rps) の負荷って？ - 約 10,000 台のクライアントが一斉にリクエストし始めること - その状態が「ずっと続く」こと - クライアント 1 台と比べて 10,000 倍の負荷がかかること ※以下リクエスト・パー・セカンド「rps」という
27. こんにちは。 やまゆです。
28. 自称赤魔道士系エンジニア ㈱インフィニットループ 
 やまゆ この画像は自撮りでも いつも使っているアイコンでも構いません ☕
29. 最近の主な業務内容 - AWS インフラストラクチャアーキテクト - PHP アプリケーションアーキテクト・実装 - インフラ管理ツール実装 - 初級者・中級者向け教育 - 社内・社外向け広報
30. 本日のお題 - ゲームサーバーとは？ - 負荷をいなすとは？ - 負荷をいなすアプリ設計は？ - Laravel いけんの？
31. 本日の NOT お題 - インフラ構築の仕方は？ - 負荷試験のやり方は？
32. ゲームサーバとは
33. ゲームサーバーとは ※ここでいうゲームとは、スマートフォン向けのソーシャルゲームとする ※リアルタイムサーバーは対象外とする - HTTP(S) 通信サーバー - 非常に大規模かつ素早くスケール - データベースへの高頻度な書きこみ - それ以外は案外と普通の Web サービスとあまり変わらない
34. HTTP(S) 通信サーバー (例) HTTP(S) json/protobuf/… OpenAPI 3.0/gRPC/…
35. HTTP(S) 通信サーバー 現状最も安定してスケールする通信プロトコル json や protobuf のような構造化されたペイロードを送受信する サーバーとクライアントは別会社が担当することもある ペイロード構造の共有が重要 弊社では様々な形式で自動生成しているが、うちは OpenAPI 3.0 を利用 OpenAPI 3.1 では Webhook にも対応 AsyncAPI https://www.asyncapi.com/ というのも登場した
36. 非常に大規模かつ素早くスケール 例) リリース直後 事前にスケールアウト 大量のアクセス
37. 非常に大規模かつ素早くスケール 例) リリース直後 事前登録によりある程度の負荷を予測し、それを超えても大丈夫な程度に大きくス ケールアウト ここでコケると離脱がかなり増えるので、費用はかさむがびっくりするくらい台数増や すことがある（Web数百台とか） 負荷試験の段階で Web サーバーや DB サーバー以外の部分で詰まらないかしっか り確認する必要がある
38. 非常に大規模かつ素早くスケール 例) 平時 柔軟にスケール 波のあるアクセス
39. 非常に大規模かつ素早くスケール 例) 平時 定常的に同じ負荷ではなく、大体一日のプレイサイクルがあるので波が出る ソシャゲだと朝・昼・夕方が負荷高め リソースに遊びがあるとただ費用を垂れ流すだけなので柔軟にスケールする必要が ある 最近だとサーバーレス化してこのスケールを自動化している場合も増えているのでは
40. 非常に大規模かつ素早くスケール 例) 人気イベント開始・終了前後 アクセススパイク 注意してスケールアウト
41. 非常に大規模かつ素早くスケール 例) 人気イベント開始・終了前後 人気イベントの開始時は急激にスパイクする イベントの人気度にもよるが、事前にスケジュールでスケールアウトしておくことで サーバー高負荷を避ける どれくらいの DAU が出るかを予測するのは半分職人芸 また、イベント終了直前は最後に走る人も多いので高負荷が続く
42. 非常に大規模かつ素早くスケール 例) 長く運用していき縮退 段々減るアクセス スケールイン
43. 非常に大規模かつ素早くスケール 例) 長く運用していき縮退 運用が数年続くとどうしてもユーザー数は減る そうすると負荷の波も小さくなっていくのでそれに合わせて台数を減らしく必要がある 計画メンテナンスに入れて DB サーバーなど一旦止めないと動かせないリソースをス ケールダウンしたりもする
44. データベースへの高頻度な書き込み コインを使ってアイテムを購入 ゲームをプレイして報酬を獲得 フレンドの申請 プロフィールの編集 ガチャの実行 …
45. データベースへの高頻度な書き込み ソーシャルゲームではとにかくユーザーの操作によって、その人が持っているリソー スの更新が多い DB は読み込みはスケールしやすいが書き込みはスケールしづらい トランザクションを張ったりするので単体の負荷も読み込みより高い
46. 負荷をいなす？
47. 負荷をいなす means いなせる負荷を かけることができる
48. 負荷試験 多くのユーザーが想定されるサービスでは負荷試験が欠かせない 10,000 rps をいなすには、 10,000 rps の負荷をかけられる必要がある 実際の負荷試験の準備・実施・レポートのやり方については、後日フォローアップ記 事をブログに投稿予定。お楽しみに！
49. 結果: RDB が重い！
50. 書き込み DB の CPU がカツカツ
51. 書き込み DB の CPU がカツカツ 今回は Amazon Aurora を使ったが、これは CPU 80 % 以上いくと急に不安定になる 傾向がある 70 % ならまだ安定稼働するが、これ以上の負荷は厳しい まだまだスケールアップは可能だが、アップには限度があるし何より費用がかさむ
52. コネクション数には限界がある
53. コネクション数には限界がある MySQL の仕様上 max_connections は 1 台あたり 16,000 が限界 今回 10,000 rps で 9,000 ということは、 20,000 rps は耐えられないということ RDS Proxy で改善されるかもしれない？ NewSQL も選択肢？
54. Laravel は正直問題ない コストパフォーマンスを考えると他言語/FWに劣る可能性はあるが、別に安定してス ケールするのでフレームワークレベルで詰まることはなかった
55. 結論:クエリ最適化と コネクション数削減が 実装において 最重要である
56. アプリ設計の要 - クエリ最適化が容易であること - 発行されるクエリが明快であること - ドメイン実装とクエリ最適化を分離して作業できること - ドメインが大規模になってもスケールすること - 疎結合であること - どこで何が実装されているかわかること - 運用を考えて、依存関係のアップデートが容易であること - Framework 等のバージョンアップがしやすいこと
57. 実際のアプリ設計
58. DDD-like Driven Design
59. なにそれ
60. DDD-like Driven Design このスライドを作りながら提唱（？） 軽量 DDD と呼ばれる奴に近い 要約：「DDD 全部は難しいので一部良さ気なとこだけ取り入れる」 さらに要約：「アーキテクトの私がわからん奴はメンバーもわからんくなるやろ」 ※私の DDD の見識は超絶浅いので全然違うこと書いている可能性も
61. DDD-like Driven Design の三つの原則 1. Laravel Frameworkは利用するが、 Framework とドメイン実装は分離すること 2. 責務がネームスペースごとに分離されていること 3. ネームスペースごとの依存関係が明らかで、 片方向になっていること
62. 弊プロジェクトの基本設計図
63. エントリポイントレイヤー
64. CQRS サービスレイヤー
65. CQRS? コマンド・クエリ責務分離のこと 「データの更新（Insert/Update/Delete）」と「データの取得（Select）」は要件が大きく 異なるから分けようぜ 更新コマンド -> 低頻度、トランザクションの管理、安全にデータを更新する 取得クエリ -> 高頻度、最適化された SQL を発行して取得する
66. ドメインレイヤー
67. ドメイン アプリケーションの本質的な実装部分 use Illuminate\...; と書いたら処される ※ Illuminate\Support ネームスペースは除く Domain から Domain 外部方向への依存は基本的に NG 必要であればインターフェースを定義して別の場所で実装
68. エンティティ 一意に識別できる識別子を持ったオブジェクト 大体テーブルと 1対1(UserEntity, UserEquipmentEntity, …) getter/setter が用意され、プロパティの更新が可能 ここにロジックを書くのが望ましいがあんまり書かれていない
69. 値オブジェクト Life や Stamina など、複雑なロジック（例えば時間で回復とか）を持つ値を一つのオ ブジェクトとして表現する手法 immutable なのが特徴的 あまり使われていない。 Identity(AUTO_INCREMENT の値オブジェクト)とか作った方 が良かったと後悔
70. ドメインサービス 複数のエンティティや値オブジェクトをまたいで何かしらの更新を行うロジックの集合 ドメインサービスと呼ばれることは少ない そしてあまり使われていない... 本当はエンティティに書いた方が良いものではある
71. リポジトリインターフェース リレーショナルデータベースのクエリ発行を担当する部分 クエリ発行はもちろん具体的な実装依存が必要なので、実装自体は別の場所で Domain 内ではインターフェースのみを定義している
72. その他インターフェース Domain の実装の中で S3 にアクセスしたい、 Laravel のこの機能を使いたい、などと いった場合は、 Domain で Laravel や S3 を参照するのではなく、単純に欲しいイン ターフェースを定義するだけとする 具体的に接続したりリクエストを送ったりするのは Domain の本質ではないので「イン フラストラクチャ」に分離する ※クリーンアーキテクチャっぽい考え方でもある
73. インフラストラクチャレイヤー
74. インフラストラクチャレイヤー 外部(=ライブラリ、DB、S3、...)と Domain をつなぐ架け橋を担当 クエリの発行、 HTTP リクエストの送受信などは全てここの中で行う Domain で定義したインターフェースを実装する ※名前が長いのでやめたいけど他に良いのが思いつかなかった
75. インフラストラクチャレイヤー 外部(=ライブラリ、DB、S3、...)と Domain をつなぐ架け橋を担当 クエリの発行、 HTTP リクエストの送受信などは全てここの中で行う Domain で定義したインターフェースを実装する ※名前が長いのでやめたいけど他に良いのが思いつかなかった
76. インフラストラクチャレイヤー 外部(=ライブラリ、DB、S3、...)と Domain をつなぐ架け橋を担当 クエリの発行、 HTTP リクエストの送受信などは全てここの中で行う Domain で定義したインターフェースを実装する ※名前が長いのでやめたいけど他に良いのが思いつかなかった そういえば、 Eloquent さんは？
78. 例えば
79. Eloquent を 例えば
80. Eloquent を 投げ捨てる 例えば
81. ※諸注意 大前提として、 Eloquent は Laravel が誇る素晴らしい機能なのは確実です。 Eloquent を使うことで生産性が大きく向上することは間違いありません。 今回の話は、いくつかの課題点からどうしても「使うのが難しい」と判断した結果にな ります。 Eloquent が悪いのではなく、今回は偶然相性が悪かった場合の話をします。
82. Why? - Active Record 型 - 初期実装 - シャーディング
83. Why?: Active Record 型であること Eloquent は Active Record 型 ORM 大規模アプリケーションにおいて Active Record を適切に運用するのは難しい（もちろ ん不可能ではない） 今回の DDD-like DD において大きな課題となった 対照となる Data Mapper 型 ORM の必要性が高まった
84. Why?: 初期実装 初期のプロトタイプ実装に illuminate/database のクエリビルダ(とそれに紐づく illuminate/collection)を採用した それらを活かすため、 Doctrine や Cycle ORM など他の Data Mapper 型 ORM の 採用は難しかった
85. Why?: シャーディング Eloquent 自体には水平シャーディングの機能がない global log user2 user1 user3 user n … 〇 ×
86. じゃあどうやってクエ リ作るの？
87. 自作 ORM で。
88. 自作 ORM
89. 自作 ORM
90. 自作 ORM
91. Why? リレーションを取得出来る ≒ N+1 クエリの危険が出る 幸いこのプロジェクトでは大量のリレーションを管理することが少なかった （最初うまい設計が思い浮かばなかった）
92. まとめ - 秒間 10,000 リクエストをさばくのは Laravel でも安定していける - RDB 負荷をいかに捌くかがキモ - DDD-like DD は結構良いぞ - 例えば Eloquent を投げ捨ててみると道が開けるかも インフィニットループでは、札幌・仙台で働くエンジニアを募集中！ ご清聴ありがとうございました！