More Related Content
Similar to 18 a-6 ameba pigg backend practice 20110217 (20)
More from Akihiro Kuwano (20)
18 a-6 ameba pigg backend practice 20110217
- 1. Ameba Pigg Backend Practice
株式会社サイバーエージェント
株式会社サイバーエージェント
アメーバ事業本部プラットフォームディビジョン
アメーバ事業本部プラットフォームディビジョン
事業本部
システムディベロップメントグループ
CA Developers Connect
桑野 章弘
- 2. 自己紹介
桑野章弘
サイバーエージェント
Ameba を運営しています。
運営しています。
しています
- Blogを中心として様々なサービスがあります。
Blogを中心として様
として サービスがあります。
があります
アメーバピグの運用/構築を
アメーバピグの運用/構築を担当
Twitter
http://twitter.com/kuwa_tw
http://twitter.com/kuwa_tw
Blog
http://d.hatena.ne.jp/akuwano/
http://d.hatena.ne.jp/akuwano/
d.hatena.ne.jp/akuwano
著書/
著書/活動
「MySQLによるタフなサイトの作り方」
MySQLによるタフなサイトの
によるタフ
勉強会(hbstudy, qpstudyほか などでの発表
勉強会(hbstudy, qpstudyほか)などでの発表など
ほか) 発表など
2
- 10. アメーバピグのアーキテクチャ:全体構成
BackEnd ユーザの
ユーザの
FrontEnd Flashデータ
データの
Flashデータの
保存など
保存など
Web+APサーバ
Web+APサーバ Socketサーバ
Socketサーバ Storageサーバ
Storageサーバ
ユーザ/
ユーザ/エリア
等の状態デー
状態デー
Flashデータ
Flashデータ 必要なデータ
必要な タ
リクエスト/
リクエスト/取得 の取得
HTTP DBサーバ
DBサーバ
独自プロトコル
独自プロトコル
・ユーザ情報
ユーザ情報 ユーザ/エリア
ユーザ/
・チャットデータ 状態デー
等の状態デー
・ゲームデータ 現在は
タ(現在は無)
リクエスト/
リクエスト/取得
KVSサーバ
KVSサーバ
ユーザ
ブラウザ)
(ブラウザ)
10
- 11. アメーバピグのアーキテクチャ:全体構成
BackEnd ユーザの
ユーザの
FrontEnd Flashデータ
データの
Flashデータの
保存など
保存など
Web+APサーバ
Web+APサーバ Socketサーバ
Socketサーバ Storageサーバ
Storageサーバ
このあたり
ユーザ/
ユーザ/エリア
等の状態デー
状態デー
Flashデータ
Flashデータ 必要なデータ
必要な タ
リクエスト/
リクエスト/取得 の取得
HTTP の話をして DBサーバ
DBサーバ
いきます
独自プロトコル
独自プロトコル
・ユーザ情報
ユーザ情報 ユーザ/エリア
ユーザ/
・チャットデータ 状態デー
等の状態デー
・ゲームデータ 現在は
タ(現在は無)
リクエスト/
リクエスト/取得
KVSサーバ
KVSサーバ
ユーザ
ブラウザ)
(ブラウザ)
11
- 13. アメーバピグのデータストア:KVS構成
DBへの更新
DBへの更新
への
確認後に
確認後にKVS
更新
更新 DBサーバ
DBサーバ
Socketサーバ
Socketサーバ
Web+APサーバ
Web+APサーバ 参照
KVSサーバ
KVSサーバ
オンメモリ処
オンメモリ処
理
13
- 14. アメーバピグのデータストア:RDBMS構成
更新、
更新、参照共
更新 DBサーバ
サーバで
にDBサーバで
KVSサーバは
KVSサーバは
サーバ
Socketサーバ
Socketサーバ 処理に
の処理に変更
一時撤廃
DBサーバ
DBサーバ
Web+APサーバ
Web+APサーバ 参照
FusionIO搭載
FusionIO搭載 KVSサーバ
KVSサーバ
したサーバ
したサーバ
14
- 17. バックエンドに依存しないモデル
アメーバピグの
アメーバピグの場合
前述した自作KVS「NDI」
前述した自作KVS「NDI」
した自作KVS
オープン当初 2009/02) 機能面で きなメリット
当初( メリットがあった
オープン当初(2009/02)は機能面で大きなメリットがあった
スケールアウトの仕組み AutoBalancing)
スケールアウトの仕組み(AutoBalancing)
キーのソートが保証される KVSでありながらレンジ取得が
キーのソートが保証される=KVSでありながらレンジ取得が可能
される= でありながらレンジ取得
やめましょう!
やめましょう!
MySQL側 保証されたデータが存在(MySQLからのデータの
されたデータ
築機能)これによる運用側
運用側の
築機能)これによる運用側の安心
からのデータ
MySQL側に保証されたデータが存在(MySQLからのデータの再構
2010/07に
2010/07に入りデータ増大によるDB->KVS再構築時間も長
データ増大によるDB->KVS再構築時間も
増大によるDB 再構築時間
期化
遅い時には数時間
には数時間
17
- 18. バックエンドに依存しないモデル
IndexPersister
アメーバピグのデータ取得部分の仕組み
アメーバピグのデータ取得部分の仕組み
取得部分
データストア部分 抽象化されているため労力をかけずに
データストア部分が抽象化されているため労力をかけずに
部分が されているため労力
切替が可能(Get,Put,Renge取得なども変わらず行える)
取得なども
切替が可能(Get,Put,Renge取得なども変わらず行える)
実際に 月程度で 分散KVS
実際に2ヶ月程度で、分散KVSを全てMySQLのみのアクセ
KVSを MySQLのみの
のみのアクセ
スへ置き換える事ができた
える事
18
- 19. アメーバピグのデータストア: IndexPersister
この部分は
この部分はアクセ
部分
からは意識
意識し
ス側からは意識し
ていない
データストア部分
データストア部分
選択は
の選択は自由 MySQL
更新
Socketサーバ
Socketサーバ
IndexPersister mongoDB
Web+APサーバ
Web+APサーバ 参照
NDI
19
- 22. アメーバピグのデータストア: ログ取得
更新/
更新/参照 本番環境
Socketサーバ
Socketサーバ
Socket
操作ログを
操作ログを取
ログ テスト環境
テスト環境
得
操作ログを
操作ログを元
ログ
負荷テスト
に負荷テスト
を実行
22
- 23. 正確な負荷テスト!差分テスト!
置換前には本番での差分テストを
置換前には本番での差分テストを実施
には本番での差分テスト
KVS & RDBMSの両者に書き込みを行い差分をチェック
RDBMSの両者に みを行 差分を
確認<=>修正のフェイズを2週間以上毎日繰り返し
確認<=>修正のフェイズを 週間以上毎日繰り
<=>修正
チェック方法も複数実施しました
チェック方法も複数実施しました
方法
書き込み時のデータチェック(両者に書き込んでいるデータが同じ
データチェック(両者に んでいるデータが
データ
かどうか)
かどうか)
データチェック(新旧DB データ比較
DBの 比較)
書き込み後のデータチェック(新旧DBのデータ比較)
読み込み時のデータチェック(負荷考慮してサンプル抽出1/1000)
データチェック(負荷考慮してサンプル抽出1/1000)
してサンプル抽出1/1000
ここまでやって安心できました
ここまでやって安心できました
安心
23
- 24. アメーバピグのデータストア:差分テスト
両者のデータが
両者のデータが正 両者のデータが
両者のデータが正
しいかのチェック
しいかのチェック しいかのチェック
しいかのチェック
(動的チェック)
動的チェック)
チェック 静的チェック
チェック)
(静的チェック)
DBサーバ
DBサーバ
更新
KVSサーバ
KVSサーバ
Socketサーバ
Socketサーバ
両者の取得データ
両者の取得データ
しいかチェック
が正しいかチェック
(動的チェック:
動的チェック
チェック:
1/1000ランダム
ランダム)
1/1000ランダム)
DBサーバ
DBサーバ
参照
KVSサーバ
KVSサーバ
24
- 27. プロダクトの選定基準
プロダクトの
プロダクトの選定基準
実現性:
実現性:高 実現性:
実現性:低
理想形:
理想形:近
○ ×
理想形:
理想形:遠
△ 問題外
例え泥臭い方法でもそれが解決
泥臭い方法でもそれが解決
でもそれが
に一番近いのであれば
一番近いのであれば
それを選択する事が事業への貢献
それを選択する事 事業への貢献
選択する への
27
- 29. プロダクトの選定基準
データストアのプロダクト選定基準
データストアのプロダクト選定基準
今の形はデータストアとしての理想形とは思っていない
データストアとしての理想形とは思
としての理想形とは
MySQLというプロダクトは
というプロダクト べて格段 安定していた
格段に
MySQLというプロダクトは他と比べて格段に安定していた
適材適所の
適材適所の考え方
安心できないプロダクトは部分的から適用する
安心できないプロダクトは部分的から適用する
できないプロダクト から適用
FusionIOの選定基準
FusionIOの
使わなくても出来た
わなくても出来た
出来
ただ使わなければサーバ台数が
サーバ台数
ただ使わなければサーバ台数が膨れ上がっていた
運用コスト改善は えないけど重要
運用コスト改善は見えないけど重要
コスト改善
実際にテストしての信頼性の
実際にテストしての信頼性の高さ
しての信頼性
29
- 30. まとめ
柔軟なプロダクトに対応するための仕組みを用意す
柔軟なプロダクトに対応するための仕組みを用意す
するための仕組みを用意
ることで事業 システムの未来が
ることで事業、システムの未来が開ける
事業、
最後まで確認したそのもう一歩先を確認する
最後まで確認したそのもう一歩先を確認する事が安
まで確認したそのもう一歩先 する事
定したシステム改善に必要
したシステム改善
システム改善に
事業貢献できる での一番理想的 ソリューションの
できる中 一番理想的な
事業貢献できる中での一番理想的なソリューションの
選択を
選択を行う
30
- 32. Ameba Pigg Best Practice
~画像ストレージ構築・運用編~
株式会社 サイバーエージェント
アメーバ事業本部プラットフォームDiv
システムディベロップメントグループ
根本英明
- 45. どのくらい捌いてますか?
Traffic
Gbps弱
3 Gbps弱
投稿容量
約120 GB/day
アクセス数
アクセス数
/day(ユーザ画像
画像)
約3億~4億/day(ユーザ画像)
45
- 46. Size [GB]
0
20
40
60
80
100
120
140
2008/9/1
2008/10/1
2008/11/1
2008/12/1
2009/1/1
2009/2/1
2009/3/1
2009/4/1
2009/5/1
2008/10 2009/3
2009/6/1
2009/7/1
2009/8/1
2009/9/1
2009/10/1
2009/11/1
2009/12/1
2009/12
2010/1/1
投稿容量の成長
2010/2/1
2010/3/1
2010/4/1
2010/5/1
Total user image uploaded per day
2010/6/1
2010/7/1
2010/8/1
2010/9/1
2010/10/1
2010/11/1
2010/12/1
2011/1/1
2011/1
2011/2/1
46
- 48. ストレージ構成
Server
RAID Controller
Mini-SAS cable
Enclosure
HDD(SATA)
1TB x 8(RAID6)
48
- 49. ストレージ構成
Server
RAID Controller
この構成の至るところ(全部)
Mini-SAS cable
に不安定要因が・・・
Enclosure
HDD(SATA)
1TB x 8(RAID6)
49
- 73. エンジニア募集中!
スマートフォンアプリエンジニア
システムエンジニア
Ameba、AmebaPigg、モバイルゲーム)
(Ameba、AmebaPigg、モバイルゲーム)
インフラエンジニア(ネットワーク、プラットフォーム)
インフラエンジニア(ネットワーク、プラットフォーム)
データベースエンジニア
R&Dエンジニア
R&Dエンジニア
サーチエンジンディベロッパー
社内システムエンジニア
社内システムエンジニア
募集要項詳細は弊社のHPをご確認ください。
募集要項詳細は弊社のHPをご確認ください。 をご確認ください
https://rec-
https://rec-log.jp/site/jobLst.aspx?company_id=5776
※上記以外の職種も募集しております!
上記以外の職種も募集しております しております!
73