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

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
Developers Summit 2015
技術選択と
アーキテクトの役割
19-A-3
February 19, 2015
Toru Yamaguchi
Senior Architect
Platform System Division
DeNA 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
WAF
MobaSif (Perl)
SNS Avatar DX API
App Server
MySQL
Cluster
memcached
Cluster
Configuration Discovery Library
Discovery Service
(memcached)
Discovery Service
(MyDNS)

当時のお題 – 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

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

DX ゲームのスキームと課題
 DX ゲームは大きく分けて二つの開発スキームがあった
⁃ いずれのケースも、開発会社ごとに開発用のサーバーを用意するモ
デル
⁃ これが当時はスケールしない状態だった
12
WAF
MobaSif (Perl)
SNS DX API
WAF
MobaSif (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
WAF
MobaSif (Perl)
SNS Avatar DX API
App Server
MySQL
Cluster
memcached
Cluster
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) に則った OpenSocial
Container です
⁃ 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

当時の 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
Activity
Streams
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

 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_scores
WHERE app_id = @app_id
ORDER BY score DESC
LIMIT 100 OFFSET 10000;

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;

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 Proxy
Server
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 Proxy
Server
Micro Internal API
Framework
API call
OAuth 2.0/OpenID Connect
Internal API
for 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

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

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

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

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

More Related Content

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