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

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.

Developers Summit 2015

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

19-A-3

February 19, 2015

Toru YamaguchiSenior ArchitectPlatform System DivisionDeNA Co., Ltd.



自己紹介

会社

⁃ 株式会社ディー・エヌ・エー

組織

⁃ システム本部プラットフォームシステム部

役職

⁃ シニアアーキテクト

活動

⁃ 前 Japan Perl Association 理事

⁃ Perl Monger

⁃ Identity Conference 設立メンバー

• OAuth 2.0, OpenID Connect

インターネット上のアカウント

⁃ @zigorou (Twitter)

⁃ zigorou (Facebook)

2



[AD] Web+DB PRESS Vol.82

Web+DB PRESS Vol.82 に「Web API デザインの鉄則」という記事を書きました

実践的な API 設計の解説を試みているので未読の方がいらっしゃいましたら、是非バックナンバーをお求め下さい

3



Abstract –今日の主旨

一応 Story というカテゴライズなので、技術の話で突っ込んだ話はしません

概要は話します

アーキテクトという役割において、しばしば直面する「技術選択」について、その判断基準をこれまでの自分の過去を振り返りながら説明していきます

「技術選択」をする時だけでなく、未来を見つめる事にフォーカスを置いて改めて、「アーキテクトの役割」を明らかにしていきたいと思います

4



Abstract –アジェンダ

Mobage Open Platform のリリース

Y!Mobage のリリース

新UIと Activity Streams/Notification/Wall

5



Mobage Open Platform のリリース


6



Open Platform がリリースされる前のビジネス的な背景

Open Platform のローンチは 2010/01 です

⁃ 先月晴れて5周年を迎えました

Mobage がまだモバゲータウンだった頃です

主なビジネスモデルは 2D アバターのアイテム販売

⁃ ゲームはあくまで無料が原則で集客ツールだった頃

⁃ 但し一部 DX ゲームというモデルはあり、ゲーム内のアイテム課金自体はやっていた

入社 (2009/01) 時点では 3D アバターを投入しててこ入れしようという頃合い

モバイルサイトとしてのトラフィックは既に国内でも有数のサイトだった

7



Open Platform プロジェクトの始動

プロジェクトの開始は 2009/07 頃

Sandbox (開発会社向け開発環境) のリリースは 2009/09 頃

ローンチは 2010/01

プロジェクトの立ち上げ時はメンバーは三人

⁃ 現在のシステム本部長木村と自分とあと一人

⁃ 全体のアーキテクチャは木村と自分で相談して決定していました

⁃ 早々に一人追加

Open Platform の立ち上げに際して色んな技術選択がありました

⁃ ここではそこでの技術選択について触れてみます

8



当時のMobageの大まかなアーキテクチャ

アプリケーションは巨大な Monolithic なシステム

MySQL や memcached には社内独自の構成管理を元に運用されていた

9

WAFMobaSif (Perl)

SNS Avatar DX API

App Server

MySQLCluster

memcachedCluster

Configuration Discovery Library

Discovery Service(memcached)

Discovery Service(MyDNS)



当時のお題 – OpenSocial WAP Extension

後に OpenSocial WAP Extension として仕様化されるアーキテクチャに則りたかった

⁃ 先行する mixi Platform との親和性を重視した

10

ProxyServer

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



初期の技術選択

大きく分けると3択でした

⁃ 前述の DX ゲームのスキームを解放する

⁃ OpenSocial WAP Extension ベースでやる

• MobaSiF を使う

• スクラッチで構築する

結果的に選択したのは「スクラッチで開発する」でした

まずはここに至る経緯を説明します

11



DX ゲームのスキームと課題

DX ゲームは大きく分けて二つの開発スキームがあった

⁃ いずれのケースも、開発会社ごとに開発用のサーバーを用意するモデル

⁃ これが当時はスケールしない状態だった

12

WAFMobaSif (Perl)

SNS DX API

WAFMobaSif (Perl)

SNS DX API

Game

Game Server

MobaSiF拡張モデル

DX API連携モデル



MobaSiFの課題

MobaSiF とは

⁃ 特に Feature Phone (いわゆるガラケー) 向けウェブサイトを構築するのに特化した Thin な Web Application Framework です

⁃ モバゲータウンという会社の中核事業を支えるフレームワークで、現在も改良を続けながら現役です

課題

⁃ 前述の通り、超巨大な Monolithic なアプリケーション

• しかもバージョン管理も当時はまともに出来ていなかった

• 一方で日に数回、本番デプロイが行われるような状況

⁃ さらに Feature Phone に特化しているので、作りがドメスティックだった

• 例えば RESTful API にありがちな PATH を作りたければ Rewrite Rule (Apache) を記述しないと実現不可能

⁃ テストが無いし、書きにくかった

13



スクラッチで書く際の課題

MobaSiF からスイッチ出来ない理由の一つはミドルウェアへの独自のアクセス方法が他に無い事が主要な要因

14

WAFMobaSif (Perl)

SNS Avatar DX API

App Server

MySQLCluster

memcachedCluster

Configuration Discovery Library

Discovery Service(memcached)

Discovery Service(MyDNS)



技術選択 –素朴な願い

当時を振り返った時に素朴にこうなれば良いという願いが幾つかありました

⁃ CPAN モジュールを積極的に使いたい

⁃ OSS にも副産物として貢献していきたい

⁃ モダンな開発スタイルを取りたい

⁃ etc …

こう考えると

⁃ 自分が理想とするエンジニアリング像を実現したいという事が主な願いだったと思います

⁃ また一緒に仕事をするエンジニアもかくあるべしという気持ちも強かったと思います

15



技術選択 –課題の洗い出しからビジョンへ

それぞれの否定からストーリーを描き、ビジョンとし実現する為のアイテムを揃えましょう

(例) 開発会社向けの開発環境がスケール可能で、Mobage 本体の開発に影響を与えず、バージョン管理可能で車輪の再発明を極力行わずプラットフォームを構築する

⁃ 開発環境 (Sandbox) は開発会社が増えても問題無いように

⁃ Mobage 本体と切り離した開発を行う

⁃ 利用出来る OSS は可能な限り用いる

16



組織の常識を変えるのは難しい

既知の良さは強い

⁃ DX スキームは既に運用していて一定の収益を挙げている

⁃ MobaSiF はみんなが慣れていて大規模トラフィックをさばく事が出来る

既知の良さは踏襲しつつ未知の良さを実現する

⁃ DX スキームのように開発者に対して開発環境を提供したい

• 但し都度構築しないような形で

⁃ MobaSiF のように大規模トラフィックに耐えうるシステムを作りたい

• ミドルウェアへのアクセス方法をなんとかする

• その他大規模トラフィックをさばく為のコンセプトは踏襲し、モダンな仕組みを導入する

結論

⁃ 無いものは自ら作るという事で自分たちの方針を押し通した

17



具体的にやった事

Sharding されたデータベースへのアクセス手段を作った

⁃ 既存の物より高機能かつ OSS 化

⁃ ☆ オープンソースへの取り組みの走りになった

社内独自の memcached のクラスタ管理に則ったアクセス手段を作った

⁃ フレームワークから独立させ、ライブラリとしてどこからでも使えるようにした

⁃ ☆ 社内ライブラリの走りになった

OSS のデプロイツールを拡張して使えるようにした

⁃ ☆ カジュアルな OSS の利用事例を打ち立てた

CPAN モジュールを使いやすくする為、独自の yum レポジトリと rpm 化の手順を構築した

External FastCGI Server 化する為に、lighttpd を採用した

⁃ Web App のシステム管理も刷新

単体テストを充実させた

18



その技術選択は何をもたらしたか

究極的にもたらした物は、既知の慣れ親しんだ手法とは違う選択肢が実現出来るという事を示した

⁃ しかもプロジェクト開始からローンチまでの期間で言えば、わずか半年ほどの短期間

⁃ 社内でそういうスタイルで開発したいと内心思っていた人にも新たな光をもたらした

それまでの DeNA という会社は OSS とはほぼ無縁の会社だったが、プラットフォーム開発を行った結果、多様な人材が参画する事になった

⁃ 現在のイメージからはむしろ想像付かないのではないでしょうか

多数の開発会社が参入可能なプラットフォームを展開し、会社の一大事業に育った

19



OSS との付き合い方

オープンソースにする事の意義

⁃ 使って貰った上でフィードバックを貰う事

⁃ 作る際に外部のリソースを期待出来る事

当時の DeNA は OSS を出すという観点では無知に等しかった

⁃ 自分たちのノウハウを万人が使える状態にして出す事には一定のスキルが必要

⁃ 従ってプラットフォームを作る際に自分だけでなくメンバーにもノウハウを OSS として体裁を整えて出すという事を最初から意図していた

組織を変えるには実例が必要

⁃ 「○○ってフレームワークが使いたい」

• 自分たちで実例を作って下さい

• 無責任なのは駄目、絶対。

20



何故、短期間で出来たか

やりたい事を先に考えた上で大きな課題の解決に集中したから

⁃ 大局観を持ちやるべき事とやらない事を見分けるのが肝要

良くある失敗

⁃ 目先の課題に対して、その課題の大小に問わず全力投球し結果的にスケジュールの大半を煮ても焼いても食えないタスクに浪費すること

21



アーキテクトの役割

素朴な願い

⁃ まず、ビジョンが先行すべきです

⁃ どういったスタイルが望みか、周りの人々との仕事にどういう変化をもたらすか

大局観を持つ

⁃ より大事な課題を浮き彫りにし、集中させる

出来る事を示す

⁃ 既存の価値観を打ち破り新しい事を出来るという事を示す

未来を見つめる

⁃ 今までではなし得なかった未来を実際に実現出来るようなソリューションを提案、実現する

技術選択とは

⁃ これらを確からしくしていく為の選択肢

22



Y!Mobage のリリース


23



当時のミッション

Feature Phone での成功の余韻、醒めやまぬ中で早速 PC 展開を模索

⁃ DeNA はこの辺のスピード感が突き抜けております、はい

Y!Japan さんとの協業がもの凄い勢いで決定、PC 展開へ

PC でのソーシャルゲームの実績は、Feature Phone 以前に mixi さんが十分に実績を積んでいるので選択として OpenSocial 一択に。

24



Y!Mobageとは

Y!Mobage は OpenSocial 1.0 (対外的には 0.8) に則った OpenSocialContainer です

⁃ OpenSocial は Gadget と呼ばれる HTML アプリケーションが動作する枠組みの事です

⁃ 2010/07 Sandbox リリース、2010/10 サービスリリース

Backend

⁃ Shindig 拡張や修正

⁃ JavaScript API の拡張や修正

⁃ Social API の全て

Container

⁃ Shindig 連携

25



Shindig とは

当時の OpenSocial のリファレンス実装

⁃ ベースは Google の OpenSocial 実行環境(iGoogle とか)で使っていたプロダクトがオープンソースになった物だと記憶しております

Shindig の持つ機能

⁃ Gadget のレンダリング

• Gadgets XML から JS API を埋め込んでレンダリングする機能

⁃ 外部コンテンツの取得

• XHR の Same Origin Policy でも外部コンテンツが取得出来るような形

⁃ JavaScript API の Serve

⁃ Social API のひな形

• 但し Y!Mobage では使っていない

26



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




Gadgets XML や Security Token などをパラメータとして Shindig に渡す

28

<iframe>

</iframe>

Shindig

Gadgets XML

yahoo-mbga.jp


example.com




Shindig は Gadgetx XML を http(s) 経由で取得

⁃ ちなみに Y!Mobage では間に Squid を入れています

29

<iframe>

</iframe>

Shindig

Gadgets XML

yahoo-mbga.jp


example.com




Shindig は Gadgets XML を受け取ります

30

<iframe>

</iframe>

Shindig

Gadgets XML

yahoo-mbga.jp


example.com




Gadgets XML から該当するコンテンツを HTML として出力する

JavaScript API などを埋め込む

31

<iframe>

</iframe>

Shindig

Gadgets XML

yahoo-mbga.jp


example.com




これで Gadget のレンダリングがおしまい

32

<iframe>

</iframe>

Shindig

Gadgets XML

yahoo-mbga.jp


example.com



Y!Mobageの構築時に必要だったこと

世界的に見ても OpenSocial Container の実装例は両手で数えられる程度の事例しか無かった (参考)

⁃ OpenSocial 環境でアプリケーションを作る事例は腐るほどある

OpenSocial Gadget Server も Shindig 以外の現実的な選択肢は無かった

つまり必要だったのは以下

⁃ OpenSocial Container を作る方法を知る

• 当然後ろの Gadget Server との連携方法を知る

⁃ OpenSocial Gadget Server の拡張の仕方を知る

この辺は自分を含めた三名で調査しました

OpenSocial Container と Gadget Server との連携に必要なライブラリは自ら書きました

33

http://ja.wikipedia.org/wiki/OpenSocial



当時の Gadgets Server の構成

Shindig 自体も Social API のひな形があるが、Perl で書いた方が早かったので L7 分散して OpenSocial 0.9 相当の API を書く事にした

⁃ JavaScript API は JSON-RPC による呼び出しを期待してるので、このとき始めて JSON-RPC を提供する事になりました

34

Shindig

API Server

lighttpd

/gadgets


/social

• Gadgets XML の取得とレンダリング• JS API のサーブ• 外部コンテンツの取得

• Social API の提供 (Security Token で呼び出し)



API Server の刷新 –課題

Feature Phone 時代に作った API Server がありましたが、これを契機に新しく作り直す事にしました

⁃ 学習コストの面

⁃ パフォーマンスの面

FP 時代の API の課題

⁃ 学習コストの面

• 当時の Perl 界隈で流行っていた Catalyst (RoR みたいな奴) ベースで作られていたが、お作法が必要以上に多かった

• 但しスタンドアローンの FastCGI Server や HTTP Server として動作する他の選択肢が無かったので当時は断念

⁃ パフォーマンスの面

• WAF や中で用いられているライブラリが必要以上にインスタンスを大量に生成する

35



API Server の刷新 –アプローチ

2010 年頃の Perl 界隈

⁃ Rack (Ruby), WSGI (Python) に当たる PSGI (Perl) の環境がだいぶ充実しつつあった

⁃ WAF を作る為の部品 (Router だとか) がだいぶ充実してきた

RESTful API と JSON-RPC に特化したドメインスペシフィックで軽量なサーバーを構築する事にした

⁃ 極力、CoW (Copy on Write) の恩恵に授かれるようにした

• モジュールだけでなくインスタンスも。

⁃ 動的にインスタンスを量産しないようにした

⁃ オブジェクトコンテナごと設定に応じて切り替えられるようにした

⁃ etc …

36



API Server の刷新 –技術選択

使ってみたいという選択は素人

⁃ 選択した上で何をもたらすかを明確にするべき

• ここでは学習コストが低く軽量に動作する REST/JSON-RPC 特化というコンセプトにした

その後の人の関わりや今後の展開をイメージすべき

⁃ その後何人で開発を進めて行くのか、今後プロジェクトにどういった展開が考えられるか

• 今の所は3人だが、今後10人くらいになるかもしれない

• 今は Feature Phone や PC のみだが、スマホが普及するにつれスマホ対応もあるだろう

37




R&D

⁃ 出来るに必要十分なリサーチと開発力がしばしば必要です

• その後の技術選択に大きな影響が出ます

⁃ 使える物は使う、作るべき物を作る

技術の見直し

⁃ 今後の開発体制やプロジェクトの展開は求められずとも、事前に予測しそれらに十分耐えうるシステムか、常に疑問に持つ

⁃ 必要であればスクラップ＆ビルドも辞さない

技術選択とは

⁃ 事前の R&D から導かれる物であり、今後の予測に基づく判断であると言えます

38



新UIと Activity Streams/Notification/Wall


39



新 UI とは？

Mobage の SmartPhone Web 版の UI リニューアルの事です

⁃ 2011/11 頃にリリース

そもそも Mobage の SPWeb 対応は他社に比べてもの凄く遅かった

⁃ ノウハウがまったくない

• PC サイトではなく FP サイトに特化した開発ばっかりだった

⁃ そんな中で CTO がかっとなって SPWeb 対応の枠組みを作った

• まずは Feature Phone 向けのサイトをそれなりに Smart Phone でも見れるようにした

一方、FP で展開してきたオープンプラットフォーム事業も SPWeb に展開し上手く立ち上がった

⁃ ここは一気に新しい UI を作ろうじゃないか！と立ち上がったのが新 UI プロジェクトなのでした

40



新 UI とバックエンド

ユーザー向けのサービス UI 上で表示するデータの提供はこれまでもやっていました

その延長線上として、ゲームとユーザーを繋ぐような API を作り、それをマイページなどで表示したいというのをコンセプトにねじ込みました

そのコンセプトに沿ったデータが以下です

⁃ Activity Streams

⁃ Wall

⁃ Notification

41



ユーザーから見たデータの流れ

人々のコミュニケーションを上記のように流したいと考えた

Activity Streams にはアプリケーション上での出来事も載せる

42

ActivityStreams

Wall

Notification

友達のタイムラインへ

自分の投稿

通知自分の周囲の情報

自分への反応

自分への反応



Activity とは (1)

Activity とは文章です

Subject が Target に Verb した

⁃ 「zigorou さんがグランブルーファンタジーを始めた」

Subject も Target も Object

Verb は行為

43

Person Gameplays

S V O



Activity とは (2)

プラットフォーム上で表現される対象を全て Object と見なす

⁃ facebook は全てに id を振っている

Subject は user とは限らない

⁃ OAuth2 を例に取ると

• Authorization Code Grant (3者間) の subject はユーザー

• Client Credentials Grant (2者間) の subject はクライアント

⁃ データの見え方が今までとは異なる

44



Activity Streams と Sharding (1)

ざっくりとまずはテーブルの用途の説明です

activity テーブル

⁃ activity の文書構造を保存したテーブル

user_activity_streams テーブル

⁃ 個々のユーザーが見るべき activity を時系列に保持するテーブル

⁃ フレンド・タイムライン処理の原理と実践で言う所の PUSH 型に相当するテーブルです

以降、このような PUSH 型のデータを構築する際のシステムと何故そういう技術選択をしたかについて説明します

45

http://labs.cybozu.co.jp/blog/kazuho/archives/2008/06/friends_timeline.php




Activity が発生したらまずは Activity だけ全系統にばらまく

⁃ 正確に言えば自らの user_activity_streams だけ書き込む

46

activity

user activity

activity

user activity

activity

user activity

activity

user activity

Q4M

Worker

Activity




見るべき相手(=フレンド全員)に Activity を通知するために、フレンドの user_activity_streams テーブルに書き込む

⁃ このデータは Sharding されている

47

activity

user activity

activity

user activity

activity

user activity

activity

user activity

Q4M

Worker




何故最初に Activity を記載し、自分の Streams にのみ PUSH するか

⁃ 自らが発生させた Activity は即時反映しないとおかしいから

フレンドの Streams の書き込みをさらに非同期化した意図は何か

⁃ フレンドの数が膨大なケースがあるのと、そこまで即時性を求められないから

単なるシステムとして見るのではなく、ユーザーにどう見せたいかが先行してこういうシステム構成になった

48




この Sharding は activity は全部同じデータが記載されている事を期待している

⁃ 場合によっては特定の系統が失敗するかもしれないので、結果整合性 (Eventually Consistent) が担保されるような Queue になっている

⁃ 何故全部に書き出したいかと言えば SQL で JOIN したいから

• あの系統からデータとった上で、別の系統に IN() で当てるとか面倒ですよね

• データサイズ的には問題にならない

一方で誰がどの activity を読むべきかのデータ(user_activity_streams) は莫大

⁃ この部分は何度か障害を起こしました

⁃ データ流量を調整

49




コンセプトメーカーたるべし

⁃ ユーザーにどう使って欲しいか、どう見せたいか

⁃ ユーザーにどのタイミングで伝えるべきか

⁃ これらをイメージした上でどのようなシステム構成が最適かを考える

データのフローを俯瞰的に見る

⁃ システム全体を捉え、個々のサービスは小さく保ち、どのようにデータが流れて加工されていくかをデザインしていく

50



グローバル展開と Leaderboard/Remote Notification


51



Mobageのグローバル展開

SDK は共通の実装で Localize し、API の実装は別々

⁃ インターフェースの統一を行い実装は別

⁃ インターフェースは JP/US で議論して合意

52

JP KR CN TW West

Japan China US

SDK

API Impl API Impl

Common API Interface



インターフェースの統一の困難 (1)

異なる実装で同じインターフェースはかなり厳しい

言語の壁

⁃ I cannot speak English!

データ型の定義が曖昧

⁃ id は String じゃ曖昧

• 文字列長は？どういうパターン？

• The length of the field equals or greater than 10 bytes and …

⁃ やってられるかw

⁃ この辺のやりとりが厳格にならず、軽量の Schema があると良いなと思った

• 後の JSON Schema 導入に繋がる

53



インターフェースの統一の困難 (2)

挙動に関してはもっと曖昧

⁃ 特定のリクエストに対して 400 を先に返すか 401 を先に返すか

• 後に Activity Diagram で正確に仕様化する事に繋がる

実装も異なれば、データベースも異なる上に、リージョンごとに表現したい事や実現したい事があるので、しばしば妥協による合意が必要だった

54



グローバル展開で生まれた API たち

Bank API

⁃ アイテム課金系の API 群

Remote Notification API

Leaderboard API

⁃ ランキング

55



Remote Notification (1)

ユーザーは端末を持つ

端末を特定する為に Token がある

⁃ APNS : Device Token

⁃ C2DM/GCM : Registration ID

⁃ 仮定の話としてブラウザだったら Cookie がそのような概念になるだろう

つまりシステムとしては

⁃ 配信したいユーザーがいて

⁃ そのユーザーに紐づく Token があり

⁃ それぞれ配信する手段が違うであろう

これらを満たすシステムを作るというコンセプト

一斉配信もありそう

56




APNS への Remote Notification 送信時はなるべく常時接続にして下さいとの事

⁃ 一方で App ごとに異なる Cert を使って接続しないといけない

⁃ Prefork Worker との相性が悪い

• 無意味に各プロセスで Idle 中の接続を app 数持たねばならない

57

App App App

APNS

Cert Cert Cert

Connection




Worker プロセスを fork(2) して生成する事を Spawn と言います

事前に Spawn しておくのが Prefork です

fork(2) は直前までの親プロセスのメモリを Copy on Write (CoW) で共有します

⁃ プロセスがメモリの内容を変更するとその部分をプロセスごとに持つようになるのが CoW の特徴

⁃ 変更されないデータは CoW の対象となるように Spawn 前に生成する

58

Parent

Child Child Child Child

Spawn




前述の 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




往々にして前提条件という物が存在します

⁃ 既存システムや外部システムなどが依存関係として前提条件となります

その上でシステムとしてどこまで考えるか、どう設計したいか

⁃ APNS/C2DM とから始めて GCM も追加した

⁃ 仮に別の概念が来ても対応出来るような設計になっている

制約を解決するための引き出しをちゃんと持とう

⁃ 一度得た知識はどんな事に使えるか想像してみよう

⁃ 知っているだけ、ウォッチしてるだけでは意味はありません

⁃ 得た知識を使う思考トレーニングをしよう

• 例えば Bloom Filter の応用などはかなり面白いです

• ここで Mutex や Semaphore が使えるとか

⁃ memcached を利用してネットワーク越しに実装するには add とかincr が使えそうだとか

60



Leaderboard (1)

突然ですが問題です

上記のクエリの問題点を5秒以内に答えよ

61

SELECT user_id, score FROM user_scoresWHERE app_id = @app_idORDER BY score DESCLIMIT 100 OFFSET 10000;



Leaderboard (2)

MySQL の OFFSET は値が大きくなればなるほど重たい

62

SELECT user_id, score FROM user_scoresWHERE app_id = @app_idORDER BY score DESCLIMIT 100 OFFSET 10000;



Leaderboard (3)

スコアを範囲で区切って、範囲ごとに何人がそのレンジに居るかというデータを組み合わせれば、OFFSET の影響を減らす事が出来ると考えた

⁃ さっきの OFFSET 10000 は右から4番目のレンジだと言うのはすぐ分かりますよね？

さてこの案のまずい点はなんでしょう

63

4200

5500

7600

6100

8700

5700

6600

3600

2100

1000

score



Leaderboard (4)

マズい点は各レンジのレコード数に相当ばらつきが予想される上に、最も母集団が多いレンジにアクセスが集中すると元々の問題が解決出来ない

⁃ じゃあ別の方法を考えよう

そもそもこういったソートに適していて、データの挿入や削除に対しての再構築に限りなくペナルティが少ないデータ構造って無いのかな

⁃ 軽くググる

⁃ SkipList ってのがあるらしい

⁃ SkipList ってどう作るんだろ、えーっと

⁃ Redis の SortedSet がまさに SkipList だ！！！

Redis 採用の瞬間！！！

64



Leaderboard (5)

実は Leaderboard API は新しい score が投稿されると

⁃ Redis に書いて

⁃ MySQL にも書く

理由としては

⁃ 当初 Redis を永続的なストレージとして信用していなかった

⁃ Redis にずっと置いておくべきとも考えていなかった

• メモリ上に SortedSet がずっと展開されててももったいない

何故勿体ないか

⁃ ランキングって得てしてソーシャルゲームだとイベントごとに期間がありますよね？

• 期間が過ぎたランキングはランクを計算して MySQL に持とうと思ったから

⁃ ないしはデイリーランキングとかそういうのを作りたかった

• 結局は作ってないけど

65



Leaderboard (6)

誰でも出来るやり方 ≠ 今までと同じやり方

⁃ この考え方は思考停止です

⁃ もちろん今までと同じやり方が妥当な場合もある

試しに今までと違うやり方も模索しよう

⁃ MySQL 使った方が良いの？

違うやり方を調べる為には責任を持って調べよう

⁃ Skip List の仕組みを人様に説明出来る程度には知ろう

• そして中身を知っていれば同点問題が何故発生するかも理解出来る

⁃ 人に説明するのは責務だし、理解とはそういう事です

• 人に説明出来ないのは理解とは言えないと、何かの数学の参考書だかに書いてあった気がします

66




ネットワークサーバーの典型的なアーキテクチャは抑えておきましょう

⁃ select, poll, fork, prefork, event driven などなど

⁃ Copy on Write の特性

得た知識がどこで使えるかの思考トレーニングは常日頃からやる

⁃ 知識だけでなく課題にもどん欲に反応しよう

未知の仕組みは原理から学ぶ

⁃ 技術選択を確からしくするし、未知の問題点にも対処しやすい

67



mixi Platform 協業


68



mixi Platform とは

お題

⁃ Mobage Platform で開発したゲームが最小工数で mixi Platform にもリリース出来るようにせよ

実際のスケジュール

⁃ プロジェクトの開始は 2012/12

⁃ サービスローンチが 2013/05

69



mixi Platform で目指した物

ただお題を満たすだけではつまらない

やるべき事が決まっている時は出来る限り高い技術的ハードルを儲けるとモチベーションが維持出来ます

⁃ 常日頃からやりたかった事や、今まであまりやっていなかった事を試験的に盛り込んで行く事にしました

70



インドの神様 –三神一体(トリニティ)

Mobage Platform の Microservices 推進の為に、最終的にはこういう世界観にしようと考えた

⁃ ちょうど役目が三つあったのでトリニティという事でコンポーネント名も決定

71

Token

Brahman

Vishnu Shiva

Internal API

Internal API

Client

Resource Owner

Authorization Server

Authorization ProxyServer

Micro Internal API Framework

API call

OAuth 2.0/OpenID Connect



インドの神様 – mixiの場合

mixi Platform 構築では赤字の部分を構築しようと決めた

⁃ 残りはいつかやろうと思ってましたが、結果的に後に始める事となる NBPF プロジェクトで作る事に。

72

Token

mixi

Vishnu Shiva Agni

Mobafy

Resource Owner

Authorization Server

Authorization ProxyServer

Micro Internal API Framework

API call

OAuth 2.0/OpenID Connect

Internal APIfor mixi



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



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

http://tinyurl.com/kzzlgfq

http://www.slideshare.net/zigorou/how-to-bake-delicious-cookie-restful-meetup-03




大規模なシステム連携があったとしても冷静に

⁃ 要点を抑えれば規模の大小は関係ない

お題が決まっている時は率先して技術的なチャレンジをしよう

⁃ お題その物は考えなくて良い分、時間が使えます

既存の常識を疑ってみよう

⁃ 今までのデファクトがいつまでもそうだとは限らない

⁃ 難しい問題に常に向き合い続ける事が優秀なエンジニアである

未来の形をイメージして今どこまで出来るかを考えよう

⁃ そのプロジェクトで閉じずに未来を思い描き、再利用を考える

75



Next Browser Platform


76



Next Browser Platform 構想

略して NBPF と言います

⁃ プロジェクトオーナー兼アーキテクト

目指したこと

⁃ JavaScript SDK を利用した、よりリッチな HTML5 App を提供出来る枠組みの構築

⁃ JavaScript SDK を利用した Mobage の全面的な作り直し

⁃ Native App 一辺倒の世界観に風穴を空ける

• Mobile Web は Apple/Google に見事に壊された現状があるのに、誰も何も不思議に思わない現状にもの凄く苛立っていた

• いつか来るかもしれない Web への揺り戻しに備える

⁃ 今までの延長線上でのプラットフォーム構想の完遂

• そしてそれをどこまで美しく作れるか

77



現状打破の為に

ブラウザタイトルを構築する 1st のニーズをきちんと聞いて、技術面は積極的にサポートする事にした

⁃ 1タイトル出る度にサポート担当のエンジニアを決めて個別にサポート

何もフィードバックが 1st からでなくても良い

⁃ 自分たちも Platform や SDK を使ってアプリケーションを作る

現状を変えたければ自分で動くべし

78



JSON Schema の実践投入

ドキュメントには使っていたけど、バリデーションロジックとして導入したのは始めて

かっとなって実装した

⁃ https://github.com/zigorou/perl-JSV

いざ実際に使いだしたので、様々な PR で JSV の実用性が高まる

実際使いだして、この部分で実装者の意図が介在しなくなったので、開発効率は多分上がったはず

⁃ 僕はプロダクトの実装者じゃないので分かりませんが！！！

得られたメリット

⁃ 実装工数削減

⁃ 定義の厳格化、特に日本語が得意ではない外国人に端的に伝えられる

⁃ テストケースの生成への応用

79

https://github.com/zigorou/perl-JSV



Brahman

OAuth 2.0/OpenID Connect Server

⁃ 最先端仕様を自分たちで実装した

⁃ Session Management (Single Logout を行う枠組み) も取り入れた

新しい Session ID/CSRF Token

⁃ 両方とも JWT を利用

セキュリティには特に注意した

⁃ X-Frame-Options

⁃ Content Security Policy

80



Widget Service

今回は対話型の API を実現するのを予め構想していた

⁃ どんなシチュエーションからも「機能」として「サービス」が再利用出来るように

• これがモジュール単位だといつまでもバラバラな実装が増える

⁃ 我々自身が SDK や Platform を使う事が肝要

81

SavitrUserAgent

window.open() or

iframe

window.postMessage()

Request

Response

http://developers.mobage.jp/blog/core-architecture-overview-of-nbpf



Krishna

いわゆる Web Hooks のような通知ワーカー群

今回のコンセプトは学習して、遅い相手に引っ張られない仕組みを作る事

⁃ 自律的に動くシステム

さらに言えば汎用的でどんな用途でもマッチすれば転用出来るという目的で作った

⁃ JWT を POST

• POST 先は設定可能

⁃ JWT Claims は変更出来る

⁃ 一回作ったので NBPF でこの手の仕組みを入れる際には、インターフェースを合意して少しの労力で組み込むだけで済む

82



Mariamma

まとめて処理バッチ君

⁃ いわゆる queue は順序性を担保したデータ構造

• ただ Prefork ワーカーでやると結果に関して順序性が維持されないので、その点は非同期ジョブの為のメッセージでしかないなと思っていた

• しばしばまとめて処理した方が早い

⁃ GCM/APNS は Bulk で処理する為の枠組みがある

⁃ あとは Bulk Insert なんかも該当する

⁃ 従ってメッセージは InnoDB に貯めて複数件同時に処理させるようにした

• 複数件同時にやるのでマルチプロセスではなくシングルプロセスで淡々と処理する

⁃ シングルプロセスで追いつかない場合は Sharding の戦略に応じてメッセージの格納の仕方を変えるとより効率が良さそう

83



NBPF がもたらした物

フォーラムやみんなの提案広場といった新しいサブサービスを別のシステムで提供出来るようになった

⁃ OpenID Connect と JavaScript SDK の恩恵

⁃ 自ら使い、改善していく良い流れが作れた

84




既存の枠組みに捕われず新しい価値を見いだす

⁃ Validation/Session/CSRF Token/One Time Token など新しい仕組みで汎用化

⁃ JSON Schema の採用で開発効率の向上

最先端の仕組みの理解と設計

⁃ OpenID Connect の対応

小さなサービスで汎用的な設計を行う

⁃ Widget Service/Krishna/Mariamma など

85



The Art of Architecture


86



Architecture とは (1)

Architecture どういった物を実現していきたいかという思想のアウトライン

⁃ アウトラインは要件を並べただけの小さな仕様ではありません！

⁃ 最初に重要な状況を並べて、それぞれ大枠でどう実現していくかを明確化していく

このアウトライン上をブレイクダウンしていった物も Architecture の一つ

⁃ よりシステム的な物になっていく

アウトライン上に何を載せて行くかは日頃から知識を入れて、その知識が何に使えるか思考のトレーニングをし、可能であれば素振り(実際にコードを書く)していつでも使えるようにする

⁃ 実際にアウトラインがあってニーズを満たし、(比較対象に対して)合理的なのであれば恐れずにトライしましょう

87



Architecture とは (2)

一定の美学も必要

⁃ インターフェースが過不足なく一貫性があるのは美しい

⁃ 不測の事態が起きても耐えられる、対応出来る初期設計は美しい

⁃ アウトラインを実際に形にしていった際に、最初のイメージに限りなく近く、また要件を十二分に満たした物が出来るというのも美しいです

手法はあるのか

⁃ 自分の考えが相手に伝わるならば手法は何でも良い

• UML を正しく使えていない事などはまったく問題ではない

⁃ Schema が間違っているのは問題

88



今の延長線ではなく

日頃の業務は大事です

⁃ そしてそれは往々にして Incremental な仕事です

ただ、一回落ち着いて周囲を見渡してみて、今の仕事の連続を忘れて未来を考えてみましょう

未来を考えてどういう形が望ましいか疑問に思って想像してみる癖を付ける

これが板について人に内容を伝えて意図した物が出来るようになると、あなたも立派なアーキテクトです

アーキテクチャは何もシステムだけが対象ではなく、場合によってはビジネス関係や組織のあり方にまで及びます

そんな訳で、要所で「技術選択」を行うアーキテクトは大変楽しい職業です

89



ご清聴ありがとうございました

Any Question?

90

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

Technology

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