シェアードナッシング型 Web アプリケーションと Kinesis Firehose による大規模データストリーム処理

2017/07/05 AWS Solution Days 2017 ～ AWS DB Day

Transcript

2. Summary オンラインゲームの定常 状態におけるデータベー スへの同時接続数 数十万～数百万 本セッションでは、ゲームアプリを事例として、 Amazon EC2上のシェアードナッシング型Webアプ リケーションと、Amazon Kinesis Firehose、 Amazon SQSを組み合わせることにより、数十分 間で約１テラバイトものデータストリームを処理す るスケールアウト・アーキテクチャを紹介
3. Introduction of Cygames  2011年5月設立。「最高のコンテンツを作る会社」を企業理念とし、 ゲーム企画・開発・運営、アニメーション製作、投資支援などを 手がけています。  神撃のバハムート、グランブルーファンタジー、シャドウバース や、他社との共同開発タイトルでも数多くのヒットタイトルを企 画・開発。シャドウバースを筆頭に積極的にグローバル展開中。
4. 自己紹介 株式会社Cygames 技術顧問／Cygames Research所長 倉林修一 慶應義塾大学大学院 政策・メディア研究科 博士課程修了。博士（政策・メディア）。 慶應義塾大学環境情報学部専任講師を経たのち、2016 年より 政策・メディア研究科 特任准教授。2015年よ り、Cygames技術顧問。 2016年、Cygames Research設立に伴い所長に就任。 専門は、ビッグデータ処理技術、データベースエンジ ン技術、情報検索用UI技術。
5. 弊社グランブルーファンタジーは、2014年3月10日の 配信開始以降、2017年6月現在の登録者数が1500万人 を突破。サービスを急激にスケールアウトさせるノウ ハウがゲーム分野には蓄積。 Online games are one of the most insightful examples of cloud comp. 0 2,000,000 4,000,000 6,000,000 8,000,000 10,000,000 12,000,000 14,000,000 16,000,000 0 5 10 15 20 25 30 35 The number of registered users months after release
6. Mobile gaming is an important subject of DB Technology Research  モバイルゲームは、利用者がゲーム内でアクションを起こす たびに、データベースを更新する必要がある。  そのため、従来の高頻度トランザクションシステムや、SNS との比較においても、極めて高い頻度でのデータベース書き 込みを必要とする。 東証 arrowhead Twitter 55,000/sec （ピーク） Mobile Game 100,000/sec（常時） 200,000/sec（ピーク） ※1日2億7千万のトランザクション （取引時間で割ると、約15,000/sec） 参考文献： 富士通株式会社, “東証の株式売買システム 「arrowhead」をリニューアル”, http://pr.fujitsu.com/jp/news/2015/09/24-1.html, 2015年9月24日. 参考文献：NTTデータ, “1月15日 バルス祭りのツイート 全量をリアルタイム計測・中継！” http://imatsui.com/staff_tweets/post_48/
7. Architecture Design Principle 急激に成長するビジネスの現場においては、スケーラビリティの達成方法をサービス のモデルに合わせて柔軟に構築する、“アーキテクチャ設計”が最も重要なファクター Consistency Availability Partition- tolerance Partitioning … Live Storage Layer MySQL (master) MySQL (slave) MySQL (log) replication Cluster Set 1 Sharding Cluster Set 2 MySQL (master) MySQL (slave) MySQL (log) Cluster Set 3 MySQL (master) MySQL (slave) MySQL (log) Cluster Set 32 MySQL (master) MySQL (slave) MySQL (log) Fusion-io Fusion-io Fusion-io Fusion-io Data Mining Environment Customer Support DB Analytics Layer Data Warehouse Systems and Statistical Analysis Systems Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server … Apache success.txt mod_cgi Client Amazon Kinesis Agent (Log Crawler) https + Basic Authentication Amazon ELB (Classic Load Balancer) Unix Shared Memory fail.txt MySQL ユーザ操作に（ポイントの チェックなど）に応じて、 ポイント取得結果を参照 App Server Atomic & Lock- Free Write Checkin.cgi Checkin.cgi checkin.cgi Amazon Kinesis Firehose キューイングによるリクエスト実 行処理とDBへの反映処理の分離 （Separation of Exec/Write） 事例① ゲームに適したリアルタイムの一貫 性と可用性を実現するアーキテクチャ設計 事例② TV連動型アプリに適した高可用性と結 果整合性を実現するアーキテクチャ設計 分散システム分析の諸理論（e.g. CAP定理）を用いて、自社ビ ジネスに要求される、一貫性、可用性、分断耐性を分析・判断 本発表では、ゲーム用 アーキテクチャを簡単に紹介 他ビジネスへの応用可能性が高い、 高可 用性アーキテクチャの事例を詳細に紹介
8. Enemy-E 攻撃 (HP-=200) ゲームに適したアーキテクチャ設計とは ゲームにおいて、データベースはゲーム世界の秩序そのもの であり、強い一貫性をリアルタイムに維持していく必要がある。 Player-B Player-A (HP=150) Enemy-E 攻撃 (HP-=200) Player-A is alive! (HP=50) Player-A is Knocked Out… (HP=0) 攻撃を受ける前に治癒できた （Player-Aは生き残る） 攻撃を受けた後に治癒はできない （Player-Aは戦闘不能） 治癒 (HP+=100) Player-B Player-A (HP=150) 治癒 戦闘 不能
9. ゲーム用のストレージの技術要件 Insert Update Select Real-time Consistency Query Type Legacy Web (e- commerce) Small Small Large No Strong Consistency Dynamic (mutable) SNS(Large Scale Web Apps) Large Small Massively Large No Eventual Consistency Dynamic (mutable) IoT (Stream DB) Massively Large no Small Yes Application- Dependent Static (immutable) Social Game Small Massively Large Massively Large Yes Strong Consistency Static (immutable) 強い一貫性と、高頻度Update、高頻度Select、そしてリ アルタイムの4つを同時に要求される環境においては、ク ラウド（AWS）を活用するアーキテクチャが必要
10. Partitioning … Live Storage Layer MySQL (master) MySQL (slave) MySQL (log) replication Cluster Set 1 Sharding Cluster Set 2 MySQL (master) MySQL (slave) MySQL (log) Cluster Set 3 MySQL (master) MySQL (slave) MySQL (log) Cluster Set 32 MySQL (master) MySQL (slave) MySQL (log) Fusion-io Fusion-io Fusion-io Fusion-io Data Mining Environment Customer Support DB Analytics Layer Data Warehouse Systems and Statistical Analysis Systems Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server … Amazon EC2を用いたスケーラブルWebアーキテクチャ 一貫性制御は、時間方向に極めて高価な処理であるため、複数のアプリケーションサーバにまたがった 一貫性のある情報を保持できるデータベース（二次記憶）は、メモリ（主記憶）よりも、貴重な資源と とらえることができる。
11. Primitive Unit（サーバシステムの最小構成単位） LAMP環境1セットを最小構成単位とし、各サーバにインストールされた memcachedがゲーム内の静的データのキャッシュとして機能している。 MySQLはリアルタイムに更新される動的なデータを格納している。 Partitioning MySQL (master) MySQL (slave) MySQL (log) replication Cluster Set 1 Fusion-io Web Server memcached PHP MySQL stores status data, which are updated in a real-time manner. Main memory, memcached stores static data shared among all the PHP processes. This bandwidth is the most precious resources.
12. Combination of sharding and partitioning DBはSharding（データの水平分割）とPartitioning（垂直分 割）を組み合わせ、データアクセスを局所化する。 JOINに代表される高コスト処理はマスターDB上では行わない。 Partitioning … Live Storage Layer MySQL (master) MySQL (slave) MySQL (log) replication Cluster Set 1 Sharding Cluster Set 2 MySQL (master) MySQL (slave) MySQL (log) Cluster Set 3 MySQL (master) MySQL (slave) MySQL (log) Cluster Set 32 MySQL (master) MySQL (slave) MySQL (log) Fusion-io Fusion-io Fusion-io Fusion-io Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server Web Server … Sharding＆ Partitioning
13. Storage & Analytics Layers JOINを伴うデータマイニング処理は、マスターデータベースか ら非同期に複製されるレプリケーションデータベースを対象と して行う。 Partitioning … Live Storage Layer MySQL (master) MySQL (slave) MySQL (log) replication Cluster Set 1 Sharding Cluster Set 2 MySQL (master) MySQL (slave) MySQL (log) Cluster Set 3 MySQL (master) MySQL (slave) MySQL (log) Cluster Set 32 MySQL (master) MySQL (slave) MySQL (log) Fusion-io Fusion-io Fusion-io Fusion-io Data Mining Environment Customer Support DB Analytics Layer Data Warehouse Systems and Statistical Analysis Systems データ マイニング処理
14. https://skycompass.granbluefantasy.jp/ AWS利用事例： TV連動型アプリに適したアーキテクチャ設計事例と しての、「グランブルーファンタジースカイコンパス」
15. Visual Check-In System for Integrating TV and Web 二次元バーコード等を用いずに、TV放送コンテンツそのものを認識し、 チェックインするサービスを大規模展開。 不正防止メカニズムに よるクライアント側 CPUを活用した映像分 析前処理により、約10 万人のユーザからの、 約30万件のリクエスト をリアルタイムに処理 するシステムをAmazon EC2インフラ上に構 築・運用。
16. TV放送と同期するシステムでは、リクエスト負荷が特定時間に必ず集中 地上波、BS放送、インターネット放送（AbemaTV） をカバーしており、日本全国の視聴者が、土曜24時の 放送に合わせて一斉にチェックインする。 http://anime.granbluefantasy.jp/
17. 0 500 1,000 1,500 2,000 2,500 3,000 0:00:00 0:00:30 0:01:00 0:01:30 0:02:00 0:02:30 0:03:00 0:03:30 0:04:00 0:04:30 0:05:00 0:05:30 0:06:00 0:06:30 0:07:00 0:07:30 0:08:00 0:08:30 0:09:00 0:09:30 0:10:00 0:10:30 0:11:00 0:11:30 0:12:00 0:12:30 0:13:00 0:13:30 0:14:00 0:14:30 0:15:00 0:15:30 0:16:00 0:16:30 0:17:00 0:17:30 0:18:00 0:18:30 0:19:00 0:19:30 0:20:00 0:20:30 0:21:00 0:21:30 0:22:00 0:22:30 0:23:00 0:23:30 0:24:00 0:24:30 0:25:00 0:25:30 0:26:00 0:26:30 0:27:00 0:27:30 0:28:00 0:28:30 0:29:00 0:29:30 0:30:00 0:30:30 4月2日 4月9日 4月16日 4月23日 4月30日 5月7日 5月14日 5月21日 5月28日 6月4日 6月11日 6月18日 6月25日 30分間のTV放送時間内における1秒当たりのリクエスト数 TV番組放送時間の最初の5分間に 全体の80%以上の負荷が集中 （3,000 req/sec） 1秒当たりのリクエスト数 30分の放送時間（左：開始0分後、右：開始30分後）
18. システム構築の課題 コンテンツの視聴を妨げないように、高負荷時において も50ms以内にレスポンスを返すべき。 短期の施策であるため30台以下のサーバ数で、ピーク時の 3,000 req /sec以上の負荷に対応可能であるべき。 ① レスポンス速度 ② スケーラビリティ ③ 一貫性 1ユーザにつき、1種類のコンテンツで1回のポイントを取得 する。多重のポイント付与が行われないよう管理するべき。
19. Consistency Availability Partition- tolerance C: Consistency of data After data has been updated, if something else references that data, it will always be guaranteed that the updated data can be referenced. A: Availability of the system No matter what the current situation, the system will continue to operate. P: Tolerance to network partitions Messages can be dropped. CAP Theorem References:  E. Brewer, "Towards Robust Distributed Systems," Proc. 19th Ann. ACM Symp.Principles of Distributed Computing (PODC 00), ACM, 2000, pp. 7-10  E. Brewer, "CAP twelve years later: How the "rules" have changed," in Computer, vol. 45, no. 2, pp. 23-29, IEEE, Feb. 2012.
20. A Concept of “Separation of Exec/Write” Shared-Nothing Architecture using “Closure-like CGI” Amazon EC2 Apache success.txt mod_cgi Client Kinesis Agent (Log Crawler) https + Basic Authentication Elastic Load Balancing LBレイヤで暗号化(TLS)を行い、下位レベルに暗号化処理を見せない。 Apacheは、Basic認証、および、リクエストサイズの制限のみを行う。 Unix Shared Memory fail.txt 画像分析処理をクライアントサイドで行う。クラウドから受け取る パラメタ情報がないと、正しく画像を分析できず、かつ、メタデー タの偽造を行うことが不可能であるため、クライアントサイドでの 画像分析が可能になっている。 MySQL ユーザ操作に（ポイントの チェックなど）に応じて、 ポイント取得結果を参照 App Server 映像 メタデータ コンフィグ データ Atomic & Lock- Free Write Checkin.cgi Checkin.cgi checkin.cgi チェックインに必要なすべてのデータをC++ソースとして自動生成 し、UNIXの共有メモリ上に乗せ、全CGIプロセスでオンメモリ化を 行う。また、CGIは結果出力以外の、一切の外部リソースにアクセス しないようにし、完全単独動作可能な、Closure-LikeなCGIとして動 作させる。これにより、メモリ効率の最大化と並列性の最大化を実現 Amazon Kinesis Firehose Amazon SQS Amazon Kinesis FirehoseとAmazon SQSを組み合わせ、各ノードか ら収集したチェックイン成功情報をキューイングし、非同期的に MySQLへ反映する。大量のチェックインリクエストが発生しても、 DB部分は輻輳しない。 キューイングによるリクエスト実行処理とDBへの反映 処理の分離（Separation of Exec/Write）
21. Solution: “Closure-Like CGI” & “Separation of Exec/Write” ① レスポンス速度 ② スケーラビリティ ③ 一貫性  Amazon Kinesis FirehoseとAmazon SQSを用いた非同期 ポイント付与処理（結果整合性）  Closure-Like CGI を用いた、SIMD命令の活用、二次 キャッシュの効率利用による、CPU利用の高効率化  Closure-Like CGI を用いたシェアード・ナッシング・アー キテクチャによるAmazon EC2インスタンスの柔軟な増減  Amazon SQSのキューイングによる、リクエスト実行処理 とDBへの反映処理の分離（Separation of Exec/Write）
22. Read-Only Memory Sharing between Native CGI Processes Closure-LikeなCGIとは、処理に必要なデータ を実行バイナリの.rodataセクション（定数値 を格納するセクション）に格納し、外部デー タにアクセスせずに、すなわち、Shared- Nothingでリクエストを処理可能にしたもの Command Line Args and Environment Variables Stack Heap .bss .data .rodata .text Higher address lower address .rodataセクションは、同一プログラムでは 完全に同一の内容になるため、UNIX上で CGIが複数起動した場合に、同一のメモリア ドレス上にマップされ、共有される。すなわ ち、実質的に、共有メモリとして機能する。
23. Read-Only Memory Sharing between Native CGI Processes .rodataセクションは、放送時間に応じてレイ アウトされているため、同時刻に起動され並行 動作するCGIは、ほぼ同じメモリアドレスを読 み込むことになる。これによりCPUキャッシュ のヒット率を上昇させる。 Command Line Args and Environment Variables Stack Heap .bss .data .rodata .text Higher address lower address 放送開始0分後のデータ 放送開始5分後のデータ 放送開始10分後のデータ … .rodata の デ ー タ が CPU キャッシュで再利用され、 メモリアクセスのオーバー ヘッドを除去 放送開始24分後のデータ
24. Server-Side Parallelization: Intel AVX2 Instructions on C4 Instances Amazon EC2におけるC4世代のインスタンスは、256bitのSIMD命令であ るIntel AVX2をサポートしており、大規模行列演算を高速に実行可能。 C++で書かれたCGIでは、このAVX2命令を容易に使用でき、さら に、.rodataセクションの行列データのアラインメント指定により、AVX2 に適したメモリレイアウトを用いて、CPUの並列性を最大化可能。 floatデータ配列 通常のCPU命令では、512個のfloatのデータ 配列を処理するとき、512回ループする 0 1 2 3 4 5 6 7 forループなどで繰り返し処理 floatデータ配列 0 1 2 3 4 5 6 7 256bitのデータ（floatなら8個）を一度に処理 Intel AVX2命令では、512個のfloatのデータ配 列を処理するとき、64回のループで完了 通常のCPU命令 SIMD（Intel AVX2）命令
25. What we found ① Amazon EC2 has very powerful computation capability. Intel AVX2 instruction set is fully supported in C4 instances. ② Closure-Like CGI and Shared-Nothing Architecture is great. Old school CGI works very fine even today. ③ Combination of Amazon Kinesis Firehose and Amazon SQS have contributed greatly to prevent congestion of large-scale requests.
26. まとめ  急激に成長するビジネスの現場においては、スケーラビリティ の達成方法をサービスのモデルに合わせて柔軟に構築する、 “システム・アーキテクチャ設計”が最も重要なファクター  Cygamesは、今後もクラウドを活用し、最高のコンテンツを 安定したプレイ環境で、グローバルに提供していく  Cygames Researchは、そのコンテンツ開発を支えるための次 世代の技術開発を大学・企業と連携しながら推進していく