技術選択とアーキテクトの役割

2. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 自己紹介  会社 ⁃ 株式会社ディー・エヌ・エー  組織 ⁃ システム本部プラットフォームシステム部  役職 ⁃ シニアアーキテクト  活動 ⁃ 前 Japan Perl Association 理事 ⁃ Perl Monger ⁃ Identity Conference 設立メンバー • OAuth 2.0, OpenID Connect  インターネット上のアカウント ⁃ @zigorou (Twitter) ⁃ zigorou (Facebook) 2

3. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 [AD] Web+DB PRESS Vol.82  Web+DB PRESS Vol.82 に「Web API デザインの鉄則」という記事を書きました  実践的な API 設計の解説を試みているので未読の方がいらっしゃいましたら、是非バックナンバーをお求め下さい 3

4. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Abstract – 今日の主旨  一応 Story というカテゴライズなので、技術の話で突っ込んだ話はしません  概要は話します  アーキテクトという役割において、しばしば直面する「技術選択」について、その判断基準をこれまでの自分の過去を振り返りながら説明していきます  「技術選択」をする時だけでなく、未来を見つめる事にフォーカスを置いて改めて、「アーキテクトの役割」を明らかにしていきたいと思います 4

7. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Open Platform がリリースされる前のビジネス的な背景  Open Platform のローンチは 2010/01 です ⁃ 先月晴れて5周年を迎えました  Mobage がまだモバゲータウンだった頃です  主なビジネスモデルは 2D アバターのアイテム販売 ⁃ ゲームはあくまで無料が原則で集客ツールだった頃 ⁃ 但し一部 DX ゲームというモデルはあり、ゲーム内のアイテム課金自体はやっていた  入社 (2009/01) 時点では 3D アバターを投入しててこ入れしようという頃合い  モバイルサイトとしてのトラフィックは既に国内でも有数のサイトだった 7

8. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Open Platform プロジェクトの始動  プロジェクトの開始は 2009/07 頃  Sandbox (開発会社向け開発環境) のリリースは 2009/09 頃  ローンチは 2010/01  プロジェクトの立ち上げ時はメンバーは三人 ⁃ 現在のシステム本部長木村と自分とあと一人 ⁃ 全体のアーキテクチャは木村と自分で相談して決定していました ⁃ 早々に一人追加  Open Platform の立ち上げに際して色んな技術選択がありました ⁃ ここではそこでの技術選択について触れてみます 8

9. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 当時の Mobage の大まかなアーキテクチャ  アプリケーションは巨大な Monolithic なシステム  MySQL や memcached には社内独自の構成管理を元に運用されていた 9 WAF MobaSif (Perl) SNS Avatar DX API App Server MySQL Cluster memcached Cluster Configuration Discovery Library Discovery Service (memcached) Discovery Service (MyDNS)

10. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 当時のお題 – OpenSocial WAP Extension  後に OpenSocial WAP Extension として仕様化されるアーキテクチャに則りたかった ⁃ 先行する mixi Platform との親和性を重視した 10 Proxy Server API Server (1) HTTP Request (3) Signed Request (2) Authentication (5) API Request (Optional) (4) Request verification (6) API Response (Optional) (7) Origin Response (8) Content Filter (9) HTTP Response

11. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 初期の技術選択  大きく分けると3択でした ⁃ 前述の DX ゲームのスキームを解放する ⁃ OpenSocial WAP Extension ベースでやる • MobaSiF を使う • スクラッチで構築する  結果的に選択したのは「スクラッチで開発する」でした  まずはここに至る経緯を説明します 11

12. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 DX ゲームのスキームと課題  DX ゲームは大きく分けて二つの開発スキームがあった ⁃ いずれのケースも、開発会社ごとに開発用のサーバーを用意するモデル ⁃ これが当時はスケールしない状態だった 12 WAF MobaSif (Perl) SNS DX API WAF MobaSif (Perl) SNS DX API Game Game Server MobaSiF 拡張モデル DX API 連携モデル

13. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 MobaSiF の課題  MobaSiF とは ⁃ 特に Feature Phone (いわゆるガラケー) 向けウェブサイトを構築するのに特化した Thin な Web Application Framework です ⁃ モバゲータウンという会社の中核事業を支えるフレームワークで、現在も改良を続けながら現役です  課題 ⁃ 前述の通り、超巨大な Monolithic なアプリケーション • しかもバージョン管理も当時はまともに出来ていなかった • 一方で日に数回、本番デプロイが行われるような状況 ⁃ さらに Feature Phone に特化しているので、作りがドメスティックだった • 例えば RESTful API にありがちな PATH を作りたければ Rewrite Rule (Apache) を記述しないと実現不可能 ⁃ テストが無いし、書きにくかった 13

14. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 スクラッチで書く際の課題  MobaSiF からスイッチ出来ない理由の一つはミドルウェアへの独自のアクセス方法が他に無い事が主要な要因 14 WAF MobaSif (Perl) SNS Avatar DX API App Server MySQL Cluster memcached Cluster Configuration Discovery Library Discovery Service (memcached) Discovery Service (MyDNS)

15. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 技術選択 – 素朴な願い  当時を振り返った時に素朴にこうなれば良いという願いが幾つかありました ⁃ CPAN モジュールを積極的に使いたい ⁃ OSS にも副産物として貢献していきたい ⁃ モダンな開発スタイルを取りたい ⁃ etc …  こう考えると ⁃ 自分が理想とするエンジニアリング像を実現したいという事が主な願いだったと思います ⁃ また一緒に仕事をするエンジニアもかくあるべしという気持ちも強かったと思います 15

16. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 技術選択 – 課題の洗い出しからビジョンへ  それぞれの否定からストーリーを描き、ビジョンとし実現する為のアイテムを揃えましょう  (例) 開発会社向けの開発環境がスケール可能で、Mobage 本体の開発に影響を与えず、バージョン管理可能で車輪の再発明を極力行わずプラットフォームを構築する ⁃ 開発環境 (Sandbox) は開発会社が増えても問題無いように ⁃ Mobage 本体と切り離した開発を行う ⁃ 利用出来る OSS は可能な限り用いる 16

17. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 組織の常識を変えるのは難しい  既知の良さは強い ⁃ DX スキームは既に運用していて一定の収益を挙げている ⁃ MobaSiF はみんなが慣れていて大規模トラフィックをさばく事が出来る  既知の良さは踏襲しつつ未知の良さを実現する ⁃ DX スキームのように開発者に対して開発環境を提供したい • 但し都度構築しないような形で ⁃ MobaSiF のように大規模トラフィックに耐えうるシステムを作りたい • ミドルウェアへのアクセス方法をなんとかする • その他大規模トラフィックをさばく為のコンセプトは踏襲し、モダンな仕組みを導入する  結論 ⁃ 無いものは自ら作るという事で自分たちの方針を押し通した 17

18. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 具体的にやった事  Sharding されたデータベースへのアクセス手段を作った ⁃ 既存の物より高機能かつ OSS 化 ⁃ ☆ オープンソースへの取り組みの走りになった  社内独自の memcached のクラスタ管理に則ったアクセス手段を作った ⁃ フレームワークから独立させ、ライブラリとしてどこからでも使えるようにした ⁃ ☆ 社内ライブラリの走りになった  OSS のデプロイツールを拡張して使えるようにした ⁃ ☆ カジュアルな OSS の利用事例を打ち立てた  CPAN モジュールを使いやすくする為、独自の yum レポジトリと rpm 化の手順を構築した  External FastCGI Server 化する為に、lighttpd を採用した ⁃ Web App のシステム管理も刷新  単体テストを充実させた 18

19. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 その技術選択は何をもたらしたか  究極的にもたらした物は、既知の慣れ親しんだ手法とは違う選択肢が実現出来るという事を示した ⁃ しかもプロジェクト開始からローンチまでの期間で言えば、わずか半年ほどの短期間 ⁃ 社内でそういうスタイルで開発したいと内心思っていた人にも新たな光をもたらした  それまでの DeNA という会社は OSS とはほぼ無縁の会社だったが、プラットフォーム開発を行った結果、多様な人材が参画する事になった ⁃ 現在のイメージからはむしろ想像付かないのではないでしょうか  多数の開発会社が参入可能なプラットフォームを展開し、会社の一大事業に育った 19

20. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 OSS との付き合い方  オープンソースにする事の意義 ⁃ 使って貰った上でフィードバックを貰う事 ⁃ 作る際に外部のリソースを期待出来る事  当時の DeNA は OSS を出すという観点では無知に等しかった ⁃ 自分たちのノウハウを万人が使える状態にして出す事には一定のスキルが必要 ⁃ 従ってプラットフォームを作る際に自分だけでなくメンバーにもノウハウを OSS として体裁を整えて出すという事を最初から意図していた  組織を変えるには実例が必要 ⁃ 「○○ってフレームワークが使いたい」 • 自分たちで実例を作って下さい • 無責任なのは駄目、絶対。 20

21. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 何故、短期間で出来たか  やりたい事を先に考えた上で大きな課題の解決に集中したから ⁃ 大局観を持ちやるべき事とやらない事を見分けるのが肝要  良くある失敗 ⁃ 目先の課題に対して、その課題の大小に問わず全力投球し結果的にスケジュールの大半を煮ても焼いても食えないタスクに浪費すること 21

22. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 アーキテクトの役割  素朴な願い ⁃ まず、ビジョンが先行すべきです ⁃ どういったスタイルが望みか、周りの人々との仕事にどういう変化をもたらすか  大局観を持つ ⁃ より大事な課題を浮き彫りにし、集中させる  出来る事を示す ⁃ 既存の価値観を打ち破り新しい事を出来るという事を示す  未来を見つめる ⁃ 今までではなし得なかった未来を実際に実現出来るようなソリューションを提案、実現する  技術選択とは ⁃ これらを確からしくしていく為の選択肢 22

24. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 当時のミッション  Feature Phone での成功の余韻、醒めやまぬ中で早速 PC 展開を模索 ⁃ DeNA はこの辺のスピード感が突き抜けております、はい  Y!Japan さんとの協業がもの凄い勢いで決定、PC 展開へ  PC でのソーシャルゲームの実績は、Feature Phone 以前に mixi さんが十分に実績を積んでいるので選択として OpenSocial 一択に。 24

25. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Y!Mobage とは  Y!Mobage は OpenSocial 1.0 (対外的には 0.8) に則った OpenSocial Container です ⁃ OpenSocial は Gadget と呼ばれる HTML アプリケーションが動作する枠組みの事です ⁃ 2010/07 Sandbox リリース、2010/10 サービスリリース  Backend ⁃ Shindig 拡張や修正 ⁃ JavaScript API の拡張や修正 ⁃ Social API の全て  Container ⁃ Shindig 連携 25

26. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Shindig とは  当時の OpenSocial のリファレンス実装 ⁃ ベースは Google の OpenSocial 実行環境(iGoogle とか)で使っていたプロダクトがオープンソースになった物だと記憶しております  Shindig の持つ機能 ⁃ Gadget のレンダリング • Gadgets XML から JS API を埋め込んでレンダリングする機能 ⁃ 外部コンテンツの取得 • XHR の Same Origin Policy でも外部コンテンツが取得出来るような形 ⁃ JavaScript API の Serve ⁃ Social API のひな形 • 但し Y!Mobage では使っていない 26

27. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 OpenSocial のアーキテクチャ – Render Gadgets (1)  Container URL から appId を取得  appId から Gadgets XML の URL を DB から取得  Security Token を生成  iframe 要素から /gadgets/ifr エンドポイントを呼び出し 27 <iframe> </iframe> Shindig Gadgets XML yahoo-mbga.jp *.app.mbga-platform.jp example.com

28. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 OpenSocial のアーキテクチャ – Render Gadgets (2)  Gadgets XML や Security Token などをパラメータとして Shindig に渡す 28 <iframe> </iframe> Shindig Gadgets XML yahoo-mbga.jp *.app.mbga-platform.jp example.com

29. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 OpenSocial のアーキテクチャ – Render Gadgets (3)  Shindig は Gadgetx XML を http(s) 経由で取得 ⁃ ちなみに Y!Mobage では間に Squid を入れています 29 <iframe> </iframe> Shindig Gadgets XML yahoo-mbga.jp *.app.mbga-platform.jp example.com

30. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 OpenSocial のアーキテクチャ – Render Gadgets (4)  Shindig は Gadgets XML を受け取ります 30 <iframe> </iframe> Shindig Gadgets XML yahoo-mbga.jp *.app.mbga-platform.jp example.com

31. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 OpenSocial のアーキテクチャ – Render Gadgets (5)  Gadgets XML から該当するコンテンツを HTML として出力する  JavaScript API などを埋め込む 31 <iframe> </iframe> Shindig Gadgets XML yahoo-mbga.jp *.app.mbga-platform.jp example.com

32. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 OpenSocial のアーキテクチャ – Render Gadgets (6)  これで Gadget のレンダリングがおしまい 32 <iframe> </iframe> Shindig Gadgets XML yahoo-mbga.jp *.app.mbga-platform.jp example.com

33. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Y!Mobage の構築時に必要だったこと  世界的に見ても OpenSocial Container の実装例は両手で数えられる程度の事例しか無かった (参考) ⁃ OpenSocial 環境でアプリケーションを作る事例は腐るほどある  OpenSocial Gadget Server も Shindig 以外の現実的な選択肢は無かった  つまり必要だったのは以下 ⁃ OpenSocial Container を作る方法を知る • 当然後ろの Gadget Server との連携方法を知る ⁃ OpenSocial Gadget Server の拡張の仕方を知る  この辺は自分を含めた三名で調査しました  OpenSocial Container と Gadget Server との連携に必要なライブラリは自ら書きました 33

34. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 当時の Gadgets Server の構成  Shindig 自体も Social API のひな形があるが、Perl で書いた方が早かったので L7 分散して OpenSocial 0.9 相当の API を書く事にした ⁃ JavaScript API は JSON-RPC による呼び出しを期待してるので、このとき始めて JSON-RPC を提供する事になりました 34 Shindig API Server lighttpd /gadgets *.app.mbga-platform.jp /social • Gadgets XML の取得とレンダリング • JS API のサーブ • 外部コンテンツの取得 • Social API の提供 (Security Token で呼び出し)

35. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 API Server の刷新 – 課題  Feature Phone 時代に作った API Server がありましたが、これを契機に新しく作り直す事にしました ⁃ 学習コストの面 ⁃ パフォーマンスの面  FP 時代の API の課題 ⁃ 学習コストの面 • 当時の Perl 界隈で流行っていた Catalyst (RoR みたいな奴) ベースで作られていたが、お作法が必要以上に多かった • 但しスタンドアローンの FastCGI Server や HTTP Server として動作する他の選択肢が無かったので当時は断念 ⁃ パフォーマンスの面 • WAF や中で用いられているライブラリが必要以上にインスタンスを大量に生成する 35

36. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 API Server の刷新 – アプローチ  2010 年頃の Perl 界隈 ⁃ Rack (Ruby), WSGI (Python) に当たる PSGI (Perl) の環境がだいぶ充実しつつあった ⁃ WAF を作る為の部品 (Router だとか) がだいぶ充実してきた  RESTful API と JSON-RPC に特化したドメインスペシフィックで軽量なサーバーを構築する事にした ⁃ 極力、CoW (Copy on Write) の恩恵に授かれるようにした • モジュールだけでなくインスタンスも。 ⁃ 動的にインスタンスを量産しないようにした ⁃ オブジェクトコンテナごと設定に応じて切り替えられるようにした ⁃ etc … 36

37. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 API Server の刷新 – 技術選択  使ってみたいという選択は素人 ⁃ 選択した上で何をもたらすかを明確にするべき • ここでは学習コストが低く軽量に動作する REST/JSON-RPC 特化というコンセプトにした  その後の人の関わりや今後の展開をイメージすべき ⁃ その後何人で開発を進めて行くのか、今後プロジェクトにどういった展開が考えられるか • 今の所は3人だが、今後10人くらいになるかもしれない • 今は Feature Phone や PC のみだが、スマホが普及するにつれスマホ対応もあるだろう 37

38. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 アーキテクトの役割  R&D ⁃ 出来るに必要十分なリサーチと開発力がしばしば必要です • その後の技術選択に大きな影響が出ます ⁃ 使える物は使う、作るべき物を作る  技術の見直し ⁃ 今後の開発体制やプロジェクトの展開は求められずとも、事前に予測しそれらに十分耐えうるシステムか、常に疑問に持つ ⁃ 必要であればスクラップ＆ビルドも辞さない  技術選択とは ⁃ 事前の R&D から導かれる物であり、今後の予測に基づく判断であると言えます 38

40. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 新 UI とは？  Mobage の SmartPhone Web 版の UI リニューアルの事です ⁃ 2011/11 頃にリリース  そもそも Mobage の SPWeb 対応は他社に比べてもの凄く遅かった ⁃ ノウハウがまったくない • PC サイトではなく FP サイトに特化した開発ばっかりだった ⁃ そんな中で CTO がかっとなって SPWeb 対応の枠組みを作った • まずは Feature Phone 向けのサイトをそれなりに Smart Phone でも見れるようにした  一方、FP で展開してきたオープンプラットフォーム事業も SPWeb に展開し上手く立ち上がった ⁃ ここは一気に新しい UI を作ろうじゃないか！と立ち上がったのが新 UI プロジェクトなのでした 40

41. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 新 UI とバックエンド  ユーザー向けのサービス UI 上で表示するデータの提供はこれまでもやっていました  その延長線上として、ゲームとユーザーを繋ぐような API を作り、それをマイページなどで表示したいというのをコンセプトにねじ込みました  そのコンセプトに沿ったデータが以下です ⁃ Activity Streams ⁃ Wall ⁃ Notification 41

42. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 ユーザーから見たデータの流れ  人々のコミュニケーションを上記のように流したいと考えた  Activity Streams にはアプリケーション上での出来事も載せる 42 Activity Streams Wall Notification 友達のタイムラインへ自分の投稿通知自分の周囲の情報自分への反応自分への反応

43. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Activity とは (1)  Activity とは文章です  Subject が Target に Verb した ⁃ 「zigorou さんがグランブルーファンタジーを始めた」  Subject も Target も Object  Verb は行為 43 Person Gameplays S V O

44. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Activity とは (2)  プラットフォーム上で表現される対象を全て Object と見なす ⁃ facebook は全てに id を振っている  Subject は user とは限らない ⁃ OAuth2 を例に取ると • Authorization Code Grant (3者間) の subject はユーザー • Client Credentials Grant (2者間) の subject はクライアント ⁃ データの見え方が今までとは異なる 44

45. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Activity Streams と Sharding (1)  ざっくりとまずはテーブルの用途の説明です  activity テーブル ⁃ activity の文書構造を保存したテーブル  user_activity_streams テーブル ⁃ 個々のユーザーが見るべき activity を時系列に保持するテーブル ⁃ フレンド・タイムライン処理の原理と実践で言う所の PUSH 型に相当するテーブルです  以降、このような PUSH 型のデータを構築する際のシステムと何故そういう技術選択をしたかについて説明します 45

46. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Activity Streams と Sharding (2)  Activity が発生したらまずは Activity だけ全系統にばらまく ⁃ 正確に言えば自らの user_activity_streams だけ書き込む 46 activity user activity activity user activity activity user activity activity user activity Q4M Worker Activity

47. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Activity Streams と Sharding (3)  見るべき相手(=フレンド全員)に Activity を通知するために、フレンドの user_activity_streams テーブルに書き込む ⁃ このデータは Sharding されている 47 activity user activity activity user activity activity user activity activity user activity Q4M Worker

48. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Activity Streams と Sharding (4)  何故最初に Activity を記載し、自分の Streams にのみ PUSH するか ⁃ 自らが発生させた Activity は即時反映しないとおかしいから  フレンドの Streams の書き込みをさらに非同期化した意図は何か ⁃ フレンドの数が膨大なケースがあるのと、そこまで即時性を求められないから  単なるシステムとして見るのではなく、ユーザーにどう見せたいかが先行してこういうシステム構成になった 48

49. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Activity Streams と Sharding (5)  この Sharding は activity は全部同じデータが記載されている事を期待している ⁃ 場合によっては特定の系統が失敗するかもしれないので、結果整合性 (Eventually Consistent) が担保されるような Queue になっている ⁃ 何故全部に書き出したいかと言えば SQL で JOIN したいから • あの系統からデータとった上で、別の系統に IN() で当てるとか面倒ですよね • データサイズ的には問題にならない  一方で誰がどの activity を読むべきかのデータ (user_activity_streams) は莫大 ⁃ この部分は何度か障害を起こしました ⁃ データ流量を調整 49

50. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 アーキテクトの役割  コンセプトメーカーたるべし ⁃ ユーザーにどう使って欲しいか、どう見せたいか ⁃ ユーザーにどのタイミングで伝えるべきか ⁃ これらをイメージした上でどのようなシステム構成が最適かを考える  データのフローを俯瞰的に見る ⁃ システム全体を捉え、個々のサービスは小さく保ち、どのようにデータが流れて加工されていくかをデザインしていく 50

52. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Mobage のグローバル展開  SDK は共通の実装で Localize し、API の実装は別々 ⁃ インターフェースの統一を行い実装は別 ⁃ インターフェースは JP/US で議論して合意 52 JP KR CN TW West Japan China US SDK API Impl API Impl Common API Interface

53. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 インターフェースの統一の困難 (1)  異なる実装で同じインターフェースはかなり厳しい  言語の壁 ⁃ I cannot speak English!  データ型の定義が曖昧 ⁃ id は String じゃ曖昧 • 文字列長は？どういうパターン？ • The length of the field equals or greater than 10 bytes and … ⁃ やってられるかw ⁃ この辺のやりとりが厳格にならず、軽量の Schema があると良いなと思った • 後の JSON Schema 導入に繋がる 53

54. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 インターフェースの統一の困難 (2)  挙動に関してはもっと曖昧 ⁃ 特定のリクエストに対して 400 を先に返すか 401 を先に返すか • 後に Activity Diagram で正確に仕様化する事に繋がる  実装も異なれば、データベースも異なる上に、リージョンごとに表現したい事や実現したい事があるので、しばしば妥協による合意が必要だった 54

56. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Remote Notification (1)  ユーザーは端末を持つ  端末を特定する為に Token がある ⁃ APNS : Device Token ⁃ C2DM/GCM : Registration ID ⁃ 仮定の話としてブラウザだったら Cookie がそのような概念になるだろう  つまりシステムとしては ⁃ 配信したいユーザーがいて ⁃ そのユーザーに紐づく Token があり ⁃ それぞれ配信する手段が違うであろう  これらを満たすシステムを作るというコンセプト  一斉配信もありそう 56

57. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Remote Notification (2)  APNS への Remote Notification 送信時はなるべく常時接続にして下さいとの事 ⁃ 一方で App ごとに異なる Cert を使って接続しないといけない ⁃ Prefork Worker との相性が悪い • 無意味に各プロセスで Idle 中の接続を app 数持たねばならない 57 App App App APNS Cert Cert Cert Connection

58. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Remote Notification (3)  Worker プロセスを fork(2) して生成する事を Spawn と言います  事前に Spawn しておくのが Prefork です  fork(2) は直前までの親プロセスのメモリを Copy on Write (CoW) で共有します ⁃ プロセスがメモリの内容を変更するとその部分をプロセスごとに持つようになるのが CoW の特徴 ⁃ 変更されないデータは CoW の対象となるように Spawn 前に生成する 58 Parent Child Child Child Child Spawn

59. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Remote Notification (4)  前述の Cert は App ごとに別という制約があるので Q4M のテーブルを appId で Sharding して enqueue することにして、プロセスごとに見るべき Shard を変えれば良いと考えた ⁃ CoW の通常の発想を逆転させて Spawn 直前にデータを書き換えて Copy させればプロセスごとに見るべき Shard を変えられると気づく • P::PF の before_fork オプションの生まれた理由です (patch 書いた) 59 Parent Child Child Child Child Spawn 1 2 3 4 1 2 3 4

60. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Remote Notification (5)  往々にして前提条件という物が存在します ⁃ 既存システムや外部システムなどが依存関係として前提条件となります  その上でシステムとしてどこまで考えるか、どう設計したいか ⁃ APNS/C2DM とから始めて GCM も追加した ⁃ 仮に別の概念が来ても対応出来るような設計になっている  制約を解決するための引き出しをちゃんと持とう ⁃ 一度得た知識はどんな事に使えるか想像してみよう ⁃ 知っているだけ、ウォッチしてるだけでは意味はありません ⁃ 得た知識を使う思考トレーニングをしよう • 例えば Bloom Filter の応用などはかなり面白いです • ここで Mutex や Semaphore が使えるとか ⁃ memcached を利用してネットワーク越しに実装するには add とか incr が使えそうだとか 60

61. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Leaderboard (1)  突然ですが問題です  上記のクエリの問題点を5秒以内に答えよ 61 SELECT user_id, score FROM user_scores WHERE app_id = @app_id ORDER BY score DESC LIMIT 100 OFFSET 10000;

62. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Leaderboard (2)  MySQL の OFFSET は値が大きくなればなるほど重たい 62 SELECT user_id, score FROM user_scores WHERE app_id = @app_id ORDER BY score DESC LIMIT 100 OFFSET 10000;

63. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Leaderboard (3)  スコアを範囲で区切って、範囲ごとに何人がそのレンジに居るかというデータを組み合わせれば、OFFSET の影響を減らす事が出来ると考えた ⁃ さっきの OFFSET 10000 は右から4番目のレンジだと言うのはすぐ分かりますよね？  さてこの案のまずい点はなんでしょう 63 4200 5500 7600 6100 8700 5700 6600 3600 2100 1000 score

64. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Leaderboard (4)  マズい点は各レンジのレコード数に相当ばらつきが予想される上に、最も母集団が多いレンジにアクセスが集中すると元々の問題が解決出来ない ⁃ じゃあ別の方法を考えよう  そもそもこういったソートに適していて、データの挿入や削除に対しての再構築に限りなくペナルティが少ないデータ構造って無いのかな ⁃ 軽くググる ⁃ SkipList ってのがあるらしい ⁃ SkipList ってどう作るんだろ、えーっと ⁃ Redis の SortedSet がまさに SkipList だ！！！  Redis 採用の瞬間！！！ 64

65. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Leaderboard (5)  実は Leaderboard API は新しい score が投稿されると ⁃ Redis に書いて ⁃ MySQL にも書く  理由としては ⁃ 当初 Redis を永続的なストレージとして信用していなかった ⁃ Redis にずっと置いておくべきとも考えていなかった • メモリ上に SortedSet がずっと展開されててももったいない  何故勿体ないか ⁃ ランキングって得てしてソーシャルゲームだとイベントごとに期間がありますよね？ • 期間が過ぎたランキングはランクを計算して MySQL に持とうと思ったから ⁃ ないしはデイリーランキングとかそういうのを作りたかった • 結局は作ってないけど 65

66. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Leaderboard (6)  誰でも出来るやり方 ≠ 今までと同じやり方 ⁃ この考え方は思考停止です ⁃ もちろん今までと同じやり方が妥当な場合もある  試しに今までと違うやり方も模索しよう ⁃ MySQL 使った方が良いの？  違うやり方を調べる為には責任を持って調べよう ⁃ Skip List の仕組みを人様に説明出来る程度には知ろう • そして中身を知っていれば同点問題が何故発生するかも理解出来る ⁃ 人に説明するのは責務だし、理解とはそういう事です • 人に説明出来ないのは理解とは言えないと、何かの数学の参考書だかに書いてあった気がします 66

67. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 アーキテクトの役割  ネットワークサーバーの典型的なアーキテクチャは抑えておきましょう ⁃ select, poll, fork, prefork, event driven などなど ⁃ Copy on Write の特性  得た知識がどこで使えるかの思考トレーニングは常日頃からやる ⁃ 知識だけでなく課題にもどん欲に反応しよう  未知の仕組みは原理から学ぶ ⁃ 技術選択を確からしくするし、未知の問題点にも対処しやすい 67

69. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 mixi Platform とは  お題 ⁃ Mobage Platform で開発したゲームが最小工数で mixi Platform にもリリース出来るようにせよ  実際のスケジュール ⁃ プロジェクトの開始は 2012/12 ⁃ サービスローンチが 2013/05 69

70. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 mixi Platform で目指した物  ただお題を満たすだけではつまらない  やるべき事が決まっている時は出来る限り高い技術的ハードルを儲けるとモチベーションが維持出来ます ⁃ 常日頃からやりたかった事や、今まであまりやっていなかった事を試験的に盛り込んで行く事にしました 70

71. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 インドの神様 – 三神一体(トリニティ)  Mobage Platform の Microservices 推進の為に、最終的にはこういう世界観にしようと考えた ⁃ ちょうど役目が三つあったのでトリニティという事でコンポーネント名も決定 71 Token Brahman Vishnu Shiva Internal API Internal API Client Resource Owner Authorization Server Authorization Proxy Server Micro Internal API Framework API call OAuth 2.0/OpenID Connect

72. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 インドの神様 – mixi の場合  mixi Platform 構築では赤字の部分を構築しようと決めた ⁃ 残りはいつかやろうと思ってましたが、結果的に後に始める事となる NBPF プロジェクトで作る事に。 72 Token mixi Vishnu Shiva Agni Mobafy Resource Owner Authorization Server Authorization Proxy Server Micro Internal API Framework API call OAuth 2.0/OpenID Connect Internal API for mixi

73. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 mixi でのデータ同期  User だけでなく Client 情報も Sandbox/Service で同期 ⁃ こうする事によって mixi 上でもアプリケーション扱いされカタログや検索などそのまま用いる事ができ、そのクライアントの権限によって API アクセスも可能 73 mixi Authorization Server Hermit mixi Authorization Server Hermit Internal API Internal API App App Application Sandbox Service

74. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 JSON Web Token の実践投入  mixi Platform では Session Cookie に適用した ⁃ ついでに Japan Identity and Cloud Summit 2013 の基調講演で話して来ました ⁃ http://tinyurl.com/kzzlgfq ⁃ 実はボツ版が存在していて、そっちのが面白いです  多分 Session ID に構造化データを入れる例は昔からあったと思いますが、内部ネットワークトラフィック軽減を視野に入れた JWT の利用ってのはかなり先進的な取り組みだったと思います  この辺りの話は How to bake delicious cookie において書いてますが、今までと同じやり方を疑うというポリシーで検討した上で導入した物です 74

75. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 アーキテクトの役割  大規模なシステム連携があったとしても冷静に ⁃ 要点を抑えれば規模の大小は関係ない  お題が決まっている時は率先して技術的なチャレンジをしよう ⁃ お題その物は考えなくて良い分、時間が使えます  既存の常識を疑ってみよう ⁃ 今までのデファクトがいつまでもそうだとは限らない ⁃ 難しい問題に常に向き合い続ける事が優秀なエンジニアである  未来の形をイメージして今どこまで出来るかを考えよう ⁃ そのプロジェクトで閉じずに未来を思い描き、再利用を考える 75

77. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Next Browser Platform 構想  略して NBPF と言います ⁃ プロジェクトオーナー兼アーキテクト  目指したこと ⁃ JavaScript SDK を利用した、よりリッチな HTML5 App を提供出来る枠組みの構築 ⁃ JavaScript SDK を利用した Mobage の全面的な作り直し ⁃ Native App 一辺倒の世界観に風穴を空ける • Mobile Web は Apple/Google に見事に壊された現状があるのに、誰も何も不思議に思わない現状にもの凄く苛立っていた • いつか来るかもしれない Web への揺り戻しに備える ⁃ 今までの延長線上でのプラットフォーム構想の完遂 • そしてそれをどこまで美しく作れるか 77

78. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 現状打破の為に  ブラウザタイトルを構築する 1st のニーズをきちんと聞いて、技術面は積極的にサポートする事にした ⁃ 1タイトル出る度にサポート担当のエンジニアを決めて個別にサポート  何もフィードバックが 1st からでなくても良い ⁃ 自分たちも Platform や SDK を使ってアプリケーションを作る  現状を変えたければ自分で動くべし 78

79. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 JSON Schema の実践投入  ドキュメントには使っていたけど、バリデーションロジックとして導入したのは始めて  かっとなって実装した ⁃ https://github.com/zigorou/perl-JSV  いざ実際に使いだしたので、様々な PR で JSV の実用性が高まる  実際使いだして、この部分で実装者の意図が介在しなくなったので、開発効率は多分上がったはず ⁃ 僕はプロダクトの実装者じゃないので分かりませんが！！！  得られたメリット ⁃ 実装工数削減 ⁃ 定義の厳格化、特に日本語が得意ではない外国人に端的に伝えられる ⁃ テストケースの生成への応用 79

80. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Brahman  OAuth 2.0/OpenID Connect Server ⁃ 最先端仕様を自分たちで実装した ⁃ Session Management (Single Logout を行う枠組み) も取り入れた  新しい Session ID/CSRF Token ⁃ 両方とも JWT を利用  セキュリティには特に注意した ⁃ X-Frame-Options ⁃ Content Security Policy 80

81. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Widget Service  今回は対話型の API を実現するのを予め構想していた ⁃ どんなシチュエーションからも「機能」として「サービス」が再利用出来るように • これがモジュール単位だといつまでもバラバラな実装が増える ⁃ 我々自身が SDK や Platform を使う事が肝要 81 SavitrUserAgent window.open() or iframe window.postMessage() Request Response

82. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Krishna  いわゆる Web Hooks のような通知ワーカー群  今回のコンセプトは学習して、遅い相手に引っ張られない仕組みを作る事 ⁃ 自律的に動くシステム  さらに言えば汎用的でどんな用途でもマッチすれば転用出来るという目的で作った ⁃ JWT を POST • POST 先は設定可能 ⁃ JWT Claims は変更出来る ⁃ 一回作ったので NBPF でこの手の仕組みを入れる際には、インターフェースを合意して少しの労力で組み込むだけで済む 82

83. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Mariamma  まとめて処理バッチ君 ⁃ いわゆる queue は順序性を担保したデータ構造 • ただ Prefork ワーカーでやると結果に関して順序性が維持されないので、その点は非同期ジョブの為のメッセージでしかないなと思っていた • しばしばまとめて処理した方が早い ⁃ GCM/APNS は Bulk で処理する為の枠組みがある ⁃ あとは Bulk Insert なんかも該当する ⁃ 従ってメッセージは InnoDB に貯めて複数件同時に処理させるようにした • 複数件同時にやるのでマルチプロセスではなくシングルプロセスで淡々と処理する ⁃ シングルプロセスで追いつかない場合は Sharding の戦略に応じてメッセージの格納の仕方を変えるとより効率が良さそう 83

85. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 アーキテクトの役割  既存の枠組みに捕われず新しい価値を見いだす ⁃ Validation/Session/CSRF Token/One Time Token など新しい仕組みで汎用化 ⁃ JSON Schema の採用で開発効率の向上  最先端の仕組みの理解と設計 ⁃ OpenID Connect の対応  小さなサービスで汎用的な設計を行う ⁃ Widget Service/Krishna/Mariamma など 85

87. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Architecture とは (1)  Architecture どういった物を実現していきたいかという思想のアウトライン ⁃ アウトラインは要件を並べただけの小さな仕様ではありません！ ⁃ 最初に重要な状況を並べて、それぞれ大枠でどう実現していくかを明確化していく  このアウトライン上をブレイクダウンしていった物も Architecture の一つ ⁃ よりシステム的な物になっていく  アウトライン上に何を載せて行くかは日頃から知識を入れて、その知識が何に使えるか思考のトレーニングをし、可能であれば素振り(実際にコードを書く)していつでも使えるようにする ⁃ 実際にアウトラインがあってニーズを満たし、(比較対象に対して) 合理的なのであれば恐れずにトライしましょう 87

88. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 Architecture とは (2)  一定の美学も必要 ⁃ インターフェースが過不足なく一貫性があるのは美しい ⁃ 不測の事態が起きても耐えられる、対応出来る初期設計は美しい ⁃ アウトラインを実際に形にしていった際に、最初のイメージに限りなく近く、また要件を十二分に満たした物が出来るというのも美しいです  手法はあるのか ⁃ 自分の考えが相手に伝わるならば手法は何でも良い • UML を正しく使えていない事などはまったく問題ではない ⁃ Schema が間違っているのは問題 88

89. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. Developers Summit 2015 今の延長線ではなく  日頃の業務は大事です ⁃ そしてそれは往々にして Incremental な仕事です  ただ、一回落ち着いて周囲を見渡してみて、今の仕事の連続を忘れて未来を考えてみましょう  未来を考えてどういう形が望ましいか疑問に思って想像してみる癖を付ける  これが板について人に内容を伝えて意図した物が出来るようになると、あなたも立派なアーキテクトです  アーキテクチャは何もシステムだけが対象ではなく、場合によってはビジネス関係や組織のあり方にまで及びます  そんな訳で、要所で「技術選択」を行うアーキテクトは大変楽しい職業です 89

技術選択とアーキテクトの役割

Toru Yamaguchi

技術選択とアーキテクトの役割