mixi内部でのアプリケーションアーキテクチャ。複雑な依存、多人数開発、パフォーマンスを両立するためにどのようにアプリケーションを構成しているか。その考え方を紹介します。Perlという軽量言語で如何にコンポーネント凝集などを考えるかという珍しいテーマだと思います。

1. inside mixi
ソーシャルネットワークを支える技術
Daichi Hiroki

2. 廣木 大地（@hiroki_daichi）
株式会社mixi
システム本部技術部たんぽぽ開発G
刺身にたんぽぽを乗せる仕事を無くす部隊
火を消したり、火の用心の見回りしたりする
2008年新卒入社
アプリケーションアーキテクチャ
広告関連/技術教育/JavaScript開発支援など

3. Social Graph
Diary Voice Calendar Check
PC向け スマートフォン向け フィーチャフォン向け API Service
mixiについて
多様なデバイスに多様なサービスを
2102万ユーザ(1430万)、297.7億PV/月 (2010/7)

4. mixi ２００４
development
歴史の長いコード
機能間連携多い ２０１０
同一のコードベース
開発者数増 ついにメガプログラミングに

6. 2つのスケーラビリティ

7. 2つのスケーラビリティ
Performance : アクセス数の増加や変動に耐える
Development : 機能追加や多人数開発に耐える

8. memcached
揮発するKVS
汎用キャッシュ
LRU

10. Cacheとは？
Cache DataSource
更新に対して参照が多いデータの参照を高速に
いつ、キャッシュにいれるか、更新されるか
なにを、キャッシュにいれるか
データ参照のホットスポットを発見して適応

11. 通常データ 参照量の多い共通データ
write write
複数台に同時書き込み
keyからketamaで一意のノードから読み書き
プロセスごとに異なるノードに問い合わせ
read read read

12. Cache戦略の考え方
Cache方式 Cache対象レイヤ
リードスルー カラムレベル
ライトスルー レコードレベル
変則ライトスルー ドメインレベル
（１）（２） サービスレベル

13. Cache戦略の考え方
Cache方式 Cache対象レイヤ
リードスルー カラムレベル
ライトスルー レコードレベル
変則ライトスルー ドメインレベル
（１）（２） サービスレベル

14. リードスルー
読み込み時にキャッシュに追加
client memcached data source
読み込み要求
キャッシュ問い合わせ
キャッシュから 特徴：
データソース問い合わせ
実装が簡単。
Aspect
戻り値をキャッシュに保存
Moose::Role
ソースから Class::Method::Modifier
などで関数に透過的に
実装できる。更新時に
書き込み要求
複数の読み込みの
キャッシュ削除
問い合わせがデータ
データソース更新
ソースにいく可能性アリ

15. ライトスルー
書き込み時にキャッシュに書き込む
client memcached data source
書き込み時
キャッシュ書き込み
データソース書き込み
読み込み要求 読み込み時は、リードスルーと同様の実装
特徴：書き込み粒度と読み込み粒度を一致させる必要がある。
共通リソースへの同時書き込みがほぼないデータに有効
キャッシュが存在しない期間がほぼ無い

16. 変則ライトスルー(1)
DBに書き込んでから、マスターを読み出す
client memcached data source
書き込み時
データソース書き込み
データソース読み込み
キャッシュデータ書き込み
読み込み要求 読み込み時は、リードスルーと同様の実装
特徴：書き込み粒度と読み込み粒度を一致させる必要が無い
Master/Slave構成のDBの場合、Masterで読み書きの必要
キャッシュが存在しない期間がほぼ無い
社内オペレーションで操作する共通データなど

17. 変則ライトスルー(2)
incrをうまく使い数を管理する
client memcached data source
書き込み時
incr命令で加算する
データソース書き込み
読み込み要求 読み込み時は、リードスルーと同様の実装
特徴：とりあつかえるのは数量のみ(select countの結果など)
キャッシュが存在しない期間がほぼ無い

18. Cache戦略の考え方
Cache方式 Cache対象レイヤ
リードスルー カラムレベル
ライトスルー レコードレベル
変則ライトスルー ドメインレベル
（１）（２） サービスレベル

19. Cache戦略の考え方
Cache方式 Cache対象レイヤ
リードスルー カラムレベル
ライトスルー レコードレベル
変則ライトスルー ドメインレベル
（１）（２） サービスレベル

20. カラム単位キャッシュ
データ保存の最小単位/粒度最小
id 名前 年齢
user:1:name 大野 1 大野 29
2 櫻井 28
3 二宮 27
特徴： 削除タイミング：
個別に参照頻度が高いデータ。 該当カラムが更新
get_multiなどで必要なカラムを収 データソース系モジュールで削除
集して柔軟に使いたいケー
ス。set_by_keyなど使えると局所性
もコントロールできて高速に。

21. 行単位キャッシュ
レコード単位でキャッシュ
id 名前 年齢
user:1 {name:”大野”, 1 大野 29
age:29} 2 櫻井 28
3 二宮 27
特徴： 削除タイミング：
個別に参照頻度が高いテーブル 該当レコードが更新
カラム追加できない状況だと、 データソース系モジュールで削除
仕様変更に弱い

22. 粒度と意味
行単位でキャッシュする分には代替できる
ケースが多い。ホットスポットを分析して、
キャッシュの粒度は意味に依存するほうがよい

23. ドメイン単位のキャッシュ
一つのモデル領域でデータを保存
Userid 名前 年齢
user:1 { 1 大野 29
name:”大野”,
2 櫻井 28
age:29,
3 二宮 27
program:
[{id:1,’歌のおにいさん’}, id owner_id 出演作品
{id:2,”怪物くん”}]
1 大野(1) 歌のおにいさん
}
2 大野(1) 怪物くん
3 二宮(3) フリーター家をかう
特徴： 更新タイミング：
サービス上のモデル分析の 該当エンティティが更新
妥当性が重要。 モデル管理モジュールで更新
大きすぎる粒度に注意。
その範囲では仕様変更につよい

24. サービス単位
複数のドメイン領域で横断的にデータを保持
Us
日記サービスid
1
2
3
名前
大野
櫻井
年齢
29
28
27
history:1
二宮
id owner_id 出演作品
1 大野(1) 歌のおにいさん
2 大野(1) 怪物くん Us
3 二宮(3) フリーター家を
ユーザデータid
1
2
3
名前
大野
櫻井
年齢
29
28
27
二宮
アプリケーション単位の id
1
owner_id
大野(1)
出演作品
歌のおにいさん
2 大野(1) 怪物くん
表示、リストデータなど Us 3 二宮(3) フリーター家を
通知履歴 id
1
2
3
名前
大野
櫻井
年齢
29
28
27
二宮
id owner_id 出演作品
1 大野(1) 歌のおにいさん
2 大野(1) 怪物くん
3 二宮(3) フリーター家を
特徴： 削除タイミング：
参照データ頻度が大きく Expireのみを期待する。
キャッシュやDBを複数個経由 ドメインごとの更新タイミングに
して出来上がるデータ。 フックポイントを仕込む（後述）
削除タイミングが難しい

25. 粒度と抽象化
View/Controller
Cacheポイント
Service
Model1 Model2
DB1 KVS DB1 Web API
アクセス数や更新頻度に応じて適切に選択
http://blog.nomadscafe.jp/2010/08/re-kazuho-
handlersocket-plugin-mycached-memcached-10.html

26. memcached
揮発するKVS
キャッシュ以外の
使い方

27. リリース時／復旧時にオペレータが制御
リリースと暖めと
アクティベーション write
read read
service [追加時刻,回復時間]
アプリケーション側でユーザ毎に
有効かどうかを計算
キャッシュヒーティング
100
決まった時間で線形にユーザの有効率を
キャッシュ搭載率
有効ユーザ数 あげていき、DB負荷を安定稼働状態まで
75
DB負荷 キャッシュをあたためさせる。
50
25
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14

28. memcached以外のcache
cacheの種類 CPAN Module 備考
ketamaが実装されるのが
デーモン Cache::Memcached::Fast
早かった
mixiでは未使用/
プロセス間 Cache::Swifty/TC
Coherencyを保つの面倒
memcachedコネクション
プロセス内 Class::Data (Inheritable)
一部memoizeとして
DBコネクション/
リクエスト mod_perl2 pnotes Singleton/Flyweight/
memcached戻り値
スコープ内 Scope::Session script/plack/job worker

29. memcached以外のcache
cacheの種類 CPAN Module 備考
ketamaが実装されるのが
デーモン Cache::Memcached::Fast
早かった
mixiでは未使用/
プロセス間 Cache::Swifty/TC
Coherencyを保つの面倒
memcachedコネクション
プロセス内 Class::Data (Inheritable)
一部memoizeとして
DBコネクション/
リクエスト キャッシュ値が一時的 Singleton/Flyweight/
mod_perl2 pnotes
memcached戻り値
にずれるのを許容
スコープ内 Scope::Session script/plack/job worker

30. コードの複雑さを防ぐ
キレイなコードが必要になる瞬間。
今そこにある危機にmixiが取り組んでいること

31. Model/
Social Graph
Service
Diary Voice Calendar Check
PC向け スマートフォン向け フィーチャフォン向け
API Service
View/
Controller

32. Profile
Customer
Support
Diary Calendar
News Social Graph
複雑に各コンポーネントが依存し合うサービス要件
Check
Voice
Ad / Analysis API Service
Home

33. 凝集度 結合度
１つの責任対してモジュールのカバー モジュールのカバーしている責任が、
している範囲が広いか、狭いか。 どの程度結合しているか。
高いほうが良い。 低いほうが良い。
凝集度を高く結合度を低く保つためのアーキテクチャ
凝集度の低い状態 結合度の高い状態
モジュール
モジュール
モジュール
モジュール

34. コンポーネント間の連携を
定義する原則
• ADP (The Acyclic Dependencies Principle)
– 非循環依存の法則
• REP(Release Reuse Equivalency Principle)
– 再利用・リリース等価原則
• SDP(The Stable Dependencies Principle )
– 安定依存原則
• SAP(The Stable Abstractions Principle )
– 安定度抽象度等価原則
• CRP(The Common Reuse Principle )
– 全再利用原則
• CCP(The Common Closure Principle)
– 閉鎖性共通原則

35. システムコンポーネント
抽象度/安定度 基礎ライブラリ
高 use
フレームワーク
低 use
コンポーネントの機能単位の
特徴から依存関係や用途などを サービス
決める。 use use use use
依存性が広範囲で再帰的に register/call
なる状態を避け、
影響範囲を限定的にする。
アプリケーション アプリケーション

36. システムコンポーネント
コンポーネント横断で利用できるAPIを制限する
JobQueueサーバを利用してユーザの行動をフック
個別のアプリケーション
の機能を他のアプリケーションから サービス
利用する方法を制限して、
アプリケーション毎の清潔さを保つ
register/call
アプリケーション アプリケーション

37. 仲介者を通じて公開APIを定義
Apps
Apps
Apps
Apps Apps Broker Apps
Resource File
Apps
Apps
すべてのモジュールの公開メソッド BrokerにおしえたAPIだけ保守すれ
を保守する必要がある ばよい。O(n)個のAPI
namespaceが別途ある言語なら、public interfaceと同義

38. Broker(内部Procedure)
コンポーネント横断で利用できるAPIを制限する
--- diary.yaml
getEntityTitle : Diary::Adapter::Entity
getEntity : Diary::Adapter::Entity
createFeedback : Diary::Adapter::Feedback
登録したAPIはそれを構成する
モジュールよりも安定させる。

39. JobQueueの使いどころ
シェーピング
突発的な負荷を緩衝して、スパイクを避ける
Joinの代替 論理/物理
複数ソースにまたがっている関連情報を一貫させる
副次的な要件の処理
異なる責務領域で必要になる処理

40. JobQueueのシステム構成
Job
Job
WorkerWorkerWorker WorkerWorkerWorker WorkerWorkerWorker WorkerWorkerWorker
Q4M Q4M Q4M Q4M
Job
Job
WebServer
WebServer
WebServer

41. JobQueueでPub-Sub
副次的要件の処理
sub add_diary {
# 本来的な処理
sub add_diary { 日記作成イベントの発火
}
# 本来的な処理
健全化系モジュール処理 JobQueue経由で
関連要件を実行
ニュース系処理
健全化系モジュール処理
広告系処理
ニュース系処理
サービスキャッシュ削除
}
広告系処理
サービスキャッシュ削除
単純な処理に対して、複数の関連する要件が
積み重なりコードが肥大化しやすい

42. Publisher-Subscriber
Brokerの一種で、１つのトピックに
健全化系モジュール処理
複数のサブスクライバが存在し Subscriber
それぞれを知らずに責務を果たす
ニュース系処理
Subscriber
日記作成イベント
Publisher Topic
広告系処理
Subscriber
サービスキャッシュ削除
Subscriber

43. ModelのCRUDにフック
アプリケーション外から
シンプルに見えるように
Create
Read
Update
Delete
個別コードの事情や構成に詳しくなくても利用できる

44. CRUDを捕捉したサービス
Us
赤文字のようにシステム
日記 id
1
2
名前
大野
櫻井
年齢
29
28 日記コメント
3 二宮 27
横断的に利用されるものも
id
1
owner_id
大野(1)
出演作品
歌のおにいさん
日記イイネ！削除
2
3
大野(1)
二宮(3)
怪物くん
フリーター家を それぞれのアプリケーション
Us
のCRUDを捕捉できれば、
Us
フォト 赤文字通知
id 名前 年齢 id 名前 年齢
1
2
大野
櫻井
29
28
1
2
大野
櫻井
29
28
高い粒度のキャッシュを
3 二宮 27 3 二宮 27
id
1
owner_id
大野(1)
出演作品
歌のおにいさん
id
1
owner_id
大野(1)
出演作品
歌のおにいさん シンプルに実現できる。
2 大野(1) 怪物くん 2 大野(1) 怪物くん
3 二宮(3) フリーター家を 3 二宮(3) フリーター家を
Us
通知用DB書き込み
カレンダー
id 名前 年齢
1 大野 29
2 櫻井 28
3 27
id
二宮
owner_id 出演作品 通知用サービスキャッシュ
1 大野(1) 歌のおにいさん
2 大野(1) 怪物くん
3 二宮(3) フリーター家を
通知用サービスキャッシュクリア
Us
通知用DB更新
ボイス id
1
2
名前
大野
櫻井
年齢
29
28
3 二宮 27
id owner_id 出演作品
1 大野(1) 歌のおにいさん
2 大野(1) 怪物くん
3 二宮(3) フリーター家を

45. まとめ
２つのスケーラビリティ
アクセスに耐える構成／機能追加に耐える構成
両方とも最終的には似てくる。
責務の分散構成≒負荷の分散構成
早く（速く）実装したければキレイに書く
設計の負債、ご利用は計画的に。

46. このひとを探しています。
http://career.mixi.co.jp/

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