![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](https://image.slidesharecdn.com/18-a-6amebapiggbackendpractice20110217-110218085312-phpapp02/85/18-a-6-ameba-pigg-backend-practice-20110217-46-320.jpg)
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
- 3. 自己紹介 この人 この人が来るはずだったんですが。 るはずだったんですが。 3
- 4. Ameba 4
- 5. アジェンダ アメーバピグって？ アメーバピグって？ って アメーバピグの アメーバピグのアーキテクチャ 全体構成 アメーバピグの アメーバピグのデータストア データストアの データストアの構成 データストアの データストアのプラクティス 5
- 6. アメーバピグって？ アメーバピグ 2Dアバターサービス 2Dアバターサービス 着せ替え ペット ゲーム（ カジノなど など） ゲーム（釣り、カジノなど） 動画 6
- 7. アメーバピグって？ 7
- 8. アメーバピグって？ アメーバピグ 2009/02/19オープン 2009/02/19オープン 会員数600万人（2011/02現在 600万人 現在） 会員数600万人（2011/02現在） 8
- 9. アメーバピグのアーキテクチャ：全体構成 通常のWebサービスとは大きく異 通常のWebサービスとは大きく異なっています サービスとは 通常のWebアプリケーション 通常のWebアプリケーション Web AP DBの3層構造 DBの アメーバピグ Flashを使用したリアルタイム処理 したリアルタイム Adobe Flashを使用したリアルタイム処理 Flashから直接TCP通信を Flashから直接TCP通信を行う事によって実現しています から直接TCP通信 によって実現 実現しています 9
- 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
- 12. アメーバピグのデータストア 運用するうちに一番大きく変わった部分 運用するうちに一番大きく変わった部分 するうちに一番大きく サービス当初 自作KVS 使用/ サービス当初は自作KVSを使用/運用 当初は KVSを 現在はRDBMS(MySQL)のみで運用 現在はRDBMS(MySQL)のみで運用 前面にキャッシュあり 前面にキャッシュあり 12
- 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
- 15. データストアのプラクティス バックエンドに依存しないモデル バックエンドに依存しないモデル しない 正確な負荷テスト 差分テスト テスト！ テスト！ 正確な負荷テスト！差分テスト！ プロダクトの プロダクトの選定基準 15
- 16. バックエンドに依存しないモデル サービスの開始は サービスの開始はスモールスタート 最初は流行るか分 最初は流行るか分からない るか 将来的な えるとスケールアウト 仕組みは スケールアウトの みは欲 将来的な事を考えるとスケールアウトの仕組みは欲しい と、思って作っても負荷がいきなり10倍になっても上手く動くかはわ って作っても負荷がいきなり10倍になっても上手く 負荷がいきなり10 上手 からない！ からない！ 同じ物を使っていく訳には行かないこともある っていく訳には行 16
- 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
- 21. 正確な負荷テスト！差分テスト！ テストデータでいくらやっても不安はぬぐえない、、、 テストデータでいくらやっても不安はぬぐえない、、、 でいくらやっても不安はぬぐえない 正確な負荷テストが選定の後押しをする 正確な負荷テストが選定の後押しをする テスト ピグの負荷テスト用フレームワークを ピグの負荷テスト用フレームワークを作成 テスト 実サーバでデータ操作のログを取得 サーバでデータ操作のログを 操作 本番に りなく近 環境を作成しログを完全トレース 本番に限りなく近い環境を作成しログを完全トレース実行 トレース実行 21
- 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
- 25. プロダクトの選定基準 プロダクトの プロダクトの選定基準 今回はMySQL+FusionIOという構成をとっています 今回はMySQL+FusionIOという構成をとっています という構成 分散KVSでやっていた頃 分散KVSでやっていた頃に比べるとコストとしては掛かって KVSでやっていた べるとコストとしては掛 コストとしては います 今回でも Cassandra等 分散KVS 選択する可能性も 今回でも、Cassandra等の分散KVSを選択する可能性も でも、 KVSを する可能性 あったはずですが、 あったはずですが、選んでいません バックエンドは でもいいんじゃね のかﾌ ｰﾌﾞ バックエンドは何でもいいんじゃねーのかﾌﾞｰﾌﾞｰ 決めては実現性と理想形です めては実現性と理想形です 実現性 25
- 26. プロダクトの選定基準 事業として、サービス視点を重視する 事業として、サービス視点を重視する として 視点 理想的なプロダクトかどうか 理想的なプロダクトかどうか 実現性、実現工数が 実現性、実現工数が高いかどうか 26
- 27. プロダクトの選定基準 プロダクトの プロダクトの選定基準 実現性： 実現性：高 実現性： 実現性：低 理想形： 理想形：近 ○ × 理想形： 理想形：遠 △ 問題外 例え泥臭い方法でもそれが解決 泥臭い方法でもそれが解決 でもそれが に一番近いのであれば 一番近いのであれば それを選択する事が事業への貢献 それを選択する事 事業への貢献 選択する への 27
- 28. プロダクトの選定基準 事業として必要 事業として必要な として必要な 仕様の 仕様のライン 実現までの工数 実現までの工数 までの 実現までの工数 実現までの工数 までの この場合ソ 理想との との乖離 理想との乖離 リューションB 理想との との乖離 理想との乖離 の方が事業貢 献できている ソリューションA ソリューションB ソリューションA ソリューションB 28
- 29. プロダクトの選定基準 データストアのプロダクト選定基準 データストアのプロダクト選定基準 今の形はデータストアとしての理想形とは思っていない データストアとしての理想形とは思 としての理想形とは MySQLというプロダクトは というプロダクト べて格段 安定していた 格段に MySQLというプロダクトは他と比べて格段に安定していた 適材適所の 適材適所の考え方 安心できないプロダクトは部分的から適用する 安心できないプロダクトは部分的から適用する できないプロダクト から適用 FusionIOの選定基準 FusionIOの 使わなくても出来た わなくても出来た 出来 ただ使わなければサーバ台数が サーバ台数 ただ使わなければサーバ台数が膨れ上がっていた 運用コスト改善は えないけど重要 運用コスト改善は見えないけど重要 コスト改善 実際にテストしての信頼性の 実際にテストしての信頼性の高さ しての信頼性 29
- 30. まとめ 柔軟なプロダクトに対応するための仕組みを用意す 柔軟なプロダクトに対応するための仕組みを用意す するための仕組みを用意 ることで事業 システムの未来が ることで事業、システムの未来が開ける 事業、 最後まで確認したそのもう一歩先を確認する 最後まで確認したそのもう一歩先を確認する事が安 まで確認したそのもう一歩先 する事 定したシステム改善に必要 したシステム改善 システム改善に 事業貢献できる での一番理想的 ソリューションの できる中 一番理想的な 事業貢献できる中での一番理想的なソリューションの 選択を 選択を行う 30
- 31. この後は 弊社根本へ 弊社根本へ アメーバのストレージに するプラクティス アメーバのストレージに関するプラクティスを語っても プラクティスを らいます さあどー さあどーぞ！ 31
- 32. Ameba Pigg Best Practice ～画像ストレージ構築・運用編～ 株式会社 サイバーエージェント アメーバ事業本部プラットフォームDiv システムディベロップメントグループ 根本英明
- 35. アメーバピグと画像ストレージ 35
- 37. アメーバピグと画像ストレージ 37
- 39. とっても 印象の悪いシステムです 39
- 40. 画像ストレージシステム紹介 なぜリリースしたか 当時のストレージ容量 ＞70%だった HW選定～検証まで2カ月しかとれず・・・ 可能な限りの検証を実施 ご迷惑をおかけして大変申し訳ありま せん 40
- 41. が、 41
- 42. 苦節２年 安定化させることが できました 42
- 43. 得られた「Practice」を 紹介します 43
- 44. どのくらい捌いてますか？ Traffic ？？？ Gbps 投稿容量 約？？？ GB/day アクセス数 アクセス数 約？？？億/day(ユーザ画像) ？？？億/day(ユーザ画像 画像) 44
- 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
- 47. ストレージ構築の実践Practice コンポーネントを列挙する コンポーネントを列挙する 怪しい部品は交換する！ しい部品は交換する 部品 する！ 思い切る！！ 複数対策同時進行 データの れを考 データの流れを考える をよく見 物をよく見る！！！ 47
- 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
- 53. サーバ改善 リリース当初 DELL PE R200を利用 (注)DELL推奨構成での利用ではありません！！！ 53
- 54. サーバ改善 リリース当初 DELL PE R200を利用 (注)DELL推奨構成での利用ではありません！！！ 障害超多発 54
- 55. サーバ改善 全コンポーネントを列挙・調査 55
- 58. サーバ改善 DELL R200 温度:7X℃ 58
- 59. サーバ改善 DELL R200 温度:7X℃ DELL R300 温度:5X℃ 59
- 60. サーバ改善 DELL R200 温度:7X℃ コンポーネントは列挙する！ DELL R300 温度:5X℃ 60
- 62. 最後は、 HDD全入替 1台のストレージあたり、 1TB × 8台 が、16セット ＝ 144台入替 62
- 64. ちょーやりたくない・・・・ と思いつつリプレイス 64
- 65. そして・・・・ 65
- 66. 安定！！！！ 某社製 66
- 67. 安定！！！！ 怪しい部品は交換する！ 思い切る！！ 某社製 67
- 68. 苦節２年弱 安定するストレージを 構築することができた 68
- 69. 苦労した点 安定化するまでのみちのり 沢山対策(効果なしも含め) • RAIDカード交換 • FW/Driver update • Enclosure交換 • Cable交換 動作確認、難しいんです 69
- 70. 苦労した点 安定化するまでのみちのり 沢山対策(効果なしも含め) RAIDカード交換 複数対策同時進行 FW/Driver update Enclosure交換 Cable交換 動作確認、難しいんです 70
- 71. ストレージ構築の実践Practice コンポーネントを列挙する コンポーネントを列挙する 怪しい部品は交換する！ しい部品は交換する 部品 する！ 思い切る！！ 複数対策同時進行 データの れを考 データの流れを考える をよく見 物をよく見る！！！ 71
- 72. おしまい 72
- 73. エンジニア募集中！ スマートフォンアプリエンジニア システムエンジニア Ameba、AmebaPigg、モバイルゲーム） （Ameba、AmebaPigg、モバイルゲーム） インフラエンジニア（ネットワーク、プラットフォーム） インフラエンジニア（ネットワーク、プラットフォーム） データベースエンジニア R&Dエンジニア R&Dエンジニア サーチエンジンディベロッパー 社内システムエンジニア 社内システムエンジニア 募集要項詳細は弊社のHPをご確認ください。 募集要項詳細は弊社のHPをご確認ください。 をご確認ください https://rec- https://rec-log.jp/site/jobLst.aspx?company_id=5776 ※上記以外の職種も募集しております！ 上記以外の職種も募集しております しております！ 73
- 74. Ameba Water と エンジニアの紹介冊子を配布中！！ 74
- 75. 質疑応答 75