18 a-6 ameba pigg backend practice 20110217

6,806 views

Published on

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,806
On SlideShare
0
From Embeds
0
Number of Embeds
1,083
Actions
Shares
0
Downloads
115
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

18 a-6 ameba pigg backend practice 20110217

  1. 1. Ameba Pigg Backend Practice 株式会社サイバーエージェント 株式会社サイバーエージェント アメーバ事業本部プラットフォームディビジョン アメーバ事業本部プラットフォームディビジョン 事業本部 システムディベロップメントグループ CA Developers Connect 桑野 章弘
  2. 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. 自己紹介この人この人が来るはずだったんですが。 るはずだったんですが。 3
  4. 4. Ameba 4
  5. 5. アジェンダアメーバピグって?アメーバピグって? ってアメーバピグのアメーバピグのアーキテクチャ 全体構成アメーバピグのアメーバピグのデータストア データストアの データストアの構成 データストアの データストアのプラクティス 5
  6. 6. アメーバピグって?アメーバピグ 2Dアバターサービス 2Dアバターサービス 着せ替え ペット ゲーム( カジノなど など) ゲーム(釣り、カジノなど) 動画 6
  7. 7. アメーバピグって? 7
  8. 8. アメーバピグって?アメーバピグ 2009/02/19オープン 2009/02/19オープン 会員数600万人(2011/02現在 600万人 現在) 会員数600万人(2011/02現在) 8
  9. 9. アメーバピグのアーキテクチャ:全体構成通常のWebサービスとは大きく異通常のWebサービスとは大きく異なっています サービスとは 通常のWebアプリケーション 通常のWebアプリケーション Web AP DBの3層構造 DBの アメーバピグ Flashを使用したリアルタイム処理 したリアルタイム Adobe Flashを使用したリアルタイム処理 Flashから直接TCP通信を Flashから直接TCP通信を行う事によって実現しています から直接TCP通信 によって実現 実現しています 9
  10. 10. アメーバピグのアーキテクチャ:全体構成 BackEnd ユーザの ユーザの FrontEnd Flashデータ データの Flashデータの 保存など 保存など Web+APサーバ Web+APサーバ Socketサーバ Socketサーバ Storageサーバ Storageサーバ ユーザ/ ユーザ/エリア 等の状態デー 状態デー Flashデータ Flashデータ 必要なデータ 必要な タ リクエスト/ リクエスト/取得 の取得HTTP DBサーバ DBサーバ 独自プロトコル 独自プロトコル ・ユーザ情報 ユーザ情報 ユーザ/エリア ユーザ/ ・チャットデータ 状態デー 等の状態デー ・ゲームデータ 現在は タ(現在は無) リクエスト/ リクエスト/取得 KVSサーバ KVSサーバ ユーザ ブラウザ) (ブラウザ) 10
  11. 11. アメーバピグのアーキテクチャ:全体構成 BackEnd ユーザの ユーザの FrontEnd Flashデータ データの Flashデータの 保存など 保存など Web+APサーバ Web+APサーバ Socketサーバ Socketサーバ Storageサーバ Storageサーバ このあたり ユーザ/ ユーザ/エリア 等の状態デー 状態デー Flashデータ Flashデータ 必要なデータ 必要な タ リクエスト/ リクエスト/取得 の取得HTTP の話をして DBサーバ DBサーバ いきます 独自プロトコル 独自プロトコル ・ユーザ情報 ユーザ情報 ユーザ/エリア ユーザ/ ・チャットデータ 状態デー 等の状態デー ・ゲームデータ 現在は タ(現在は無) リクエスト/ リクエスト/取得 KVSサーバ KVSサーバ ユーザ ブラウザ) (ブラウザ) 11
  12. 12. アメーバピグのデータストア運用するうちに一番大きく変わった部分運用するうちに一番大きく変わった部分 するうちに一番大きくサービス当初 自作KVS 使用/サービス当初は自作KVSを使用/運用 当初は KVSを現在はRDBMS(MySQL)のみで運用現在はRDBMS(MySQL)のみで運用 前面にキャッシュあり 前面にキャッシュあり 12
  13. 13. アメーバピグのデータストア:KVS構成 DBへの更新 DBへの更新 への 確認後に 確認後にKVS 更新 更新 DBサーバ DBサーバSocketサーバSocketサーバWeb+APサーバWeb+APサーバ 参照 KVSサーバ KVSサーバ オンメモリ処 オンメモリ処 理 13
  14. 14. アメーバピグのデータストア:RDBMS構成 更新、 更新、参照共 更新 DBサーバ サーバで にDBサーバで KVSサーバは KVSサーバは サーバSocketサーバSocketサーバ 処理に の処理に変更 一時撤廃 DBサーバ DBサーバWeb+APサーバWeb+APサーバ 参照 FusionIO搭載 FusionIO搭載 KVSサーバ KVSサーバ したサーバ したサーバ 14
  15. 15. データストアのプラクティスバックエンドに依存しないモデルバックエンドに依存しないモデル しない正確な負荷テスト 差分テスト テスト! テスト!正確な負荷テスト!差分テスト!プロダクトのプロダクトの選定基準 15
  16. 16. バックエンドに依存しないモデルサービスの開始はサービスの開始はスモールスタート 最初は流行るか分 最初は流行るか分からない るか 将来的な えるとスケールアウト 仕組みは スケールアウトの みは欲 将来的な事を考えるとスケールアウトの仕組みは欲しい と、思って作っても負荷がいきなり10倍になっても上手く動くかはわ って作っても負荷がいきなり10倍になっても上手く 負荷がいきなり10 上手 からない! からない! 同じ物を使っていく訳には行かないこともある っていく訳には行 16
  17. 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. 18. バックエンドに依存しないモデルIndexPersister アメーバピグのデータ取得部分の仕組み アメーバピグのデータ取得部分の仕組み 取得部分 データストア部分 抽象化されているため労力をかけずに データストア部分が抽象化されているため労力をかけずに 部分が されているため労力 切替が可能(Get,Put,Renge取得なども変わらず行える) 取得なども 切替が可能(Get,Put,Renge取得なども変わらず行える) 実際に 月程度で 分散KVS 実際に2ヶ月程度で、分散KVSを全てMySQLのみのアクセ KVSを MySQLのみの のみのアクセ スへ置き換える事ができた える事 18
  19. 19. アメーバピグのデータストア: IndexPersister この部分は この部分はアクセ 部分 からは意識 意識し ス側からは意識し ていない データストア部分 データストア部分 選択は の選択は自由 MySQL 更新SocketサーバSocketサーバ IndexPersister mongoDBWeb+APサーバWeb+APサーバ 参照 NDI 19
  20. 20. バックエンドに依存しないモデルいざと言うときにすぐに他 プロダクトに移行できるよいざと言うときにすぐに他のプロダクトに移行できるようにしておくでもそんなこといっても怖いじゃんでもそんなこといっても怖いじゃん 20
  21. 21. 正確な負荷テスト!差分テスト!テストデータでいくらやっても不安はぬぐえない、、、テストデータでいくらやっても不安はぬぐえない、、、 でいくらやっても不安はぬぐえない 正確な負荷テストが選定の後押しをする 正確な負荷テストが選定の後押しをする テストピグの負荷テスト用フレームワークをピグの負荷テスト用フレームワークを作成 テスト 実サーバでデータ操作のログを取得 サーバでデータ操作のログを 操作 本番に りなく近 環境を作成しログを完全トレース 本番に限りなく近い環境を作成しログを完全トレース実行 トレース実行 21
  22. 22. アメーバピグのデータストア: ログ取得 更新/ 更新/参照 本番環境 Socketサーバ Socketサーバ Socket 操作ログを 操作ログを取 ログ テスト環境 テスト環境 得 操作ログを 操作ログを元 ログ 負荷テスト に負荷テスト を実行 22
  23. 23. 正確な負荷テスト!差分テスト!置換前には本番での差分テストを置換前には本番での差分テストを実施 には本番での差分テスト KVS & RDBMSの両者に書き込みを行い差分をチェック RDBMSの両者に みを行 差分を 確認<=>修正のフェイズを2週間以上毎日繰り返し 確認<=>修正のフェイズを 週間以上毎日繰り <=>修正 チェック方法も複数実施しました チェック方法も複数実施しました 方法 書き込み時のデータチェック(両者に書き込んでいるデータが同じ データチェック(両者に んでいるデータが データ かどうか) かどうか) データチェック(新旧DB データ比較 DBの 比較) 書き込み後のデータチェック(新旧DBのデータ比較) 読み込み時のデータチェック(負荷考慮してサンプル抽出1/1000) データチェック(負荷考慮してサンプル抽出1/1000) してサンプル抽出1/1000 ここまでやって安心できました ここまでやって安心できました 安心 23
  24. 24. アメーバピグのデータストア:差分テスト 両者のデータが 両者のデータが正 両者のデータが 両者のデータが正 しいかのチェック しいかのチェック しいかのチェック しいかのチェック (動的チェック) 動的チェック) チェック 静的チェック チェック) (静的チェック) DBサーバ DBサーバ 更新 KVSサーバ KVSサーバSocketサーバSocketサーバ 両者の取得データ 両者の取得データ しいかチェック が正しいかチェック (動的チェック: 動的チェック チェック: 1/1000ランダム ランダム) 1/1000ランダム) DBサーバ DBサーバ 参照 KVSサーバ KVSサーバ 24
  25. 25. プロダクトの選定基準プロダクトのプロダクトの選定基準 今回はMySQL+FusionIOという構成をとっています 今回はMySQL+FusionIOという構成をとっています という構成 分散KVSでやっていた頃 分散KVSでやっていた頃に比べるとコストとしては掛かって KVSでやっていた べるとコストとしては掛 コストとしては います 今回でも Cassandra等 分散KVS 選択する可能性も 今回でも、Cassandra等の分散KVSを選択する可能性も でも、 KVSを する可能性 あったはずですが、 あったはずですが、選んでいません バックエンドは でもいいんじゃね のかフ ーブ バックエンドは何でもいいんじゃねーのかブーブー 決めては実現性と理想形です めては実現性と理想形です 実現性 25
  26. 26. プロダクトの選定基準事業として、サービス視点を重視する事業として、サービス視点を重視する として 視点 理想的なプロダクトかどうか 理想的なプロダクトかどうか 実現性、実現工数が 実現性、実現工数が高いかどうか 26
  27. 27. プロダクトの選定基準プロダクトのプロダクトの選定基準 実現性: 実現性:高 実現性: 実現性:低理想形:理想形:近 ○ ×理想形:理想形:遠 △ 問題外 例え泥臭い方法でもそれが解決 泥臭い方法でもそれが解決 でもそれが に一番近いのであれば 一番近いのであればそれを選択する事が事業への貢献それを選択する事 事業への貢献 選択する への 27
  28. 28. プロダクトの選定基準事業として必要事業として必要な として必要な仕様の仕様のライン 実現までの工数 実現までの工数 までの 実現までの工数 実現までの工数 までの この場合ソ 理想との との乖離 理想との乖離リューションB 理想との との乖離 理想との乖離の方が事業貢献できている ソリューションA ソリューションB ソリューションA ソリューションB 28
  29. 29. プロダクトの選定基準データストアのプロダクト選定基準データストアのプロダクト選定基準 今の形はデータストアとしての理想形とは思っていない データストアとしての理想形とは思 としての理想形とは MySQLというプロダクトは というプロダクト べて格段 安定していた 格段に MySQLというプロダクトは他と比べて格段に安定していた 適材適所の 適材適所の考え方 安心できないプロダクトは部分的から適用する 安心できないプロダクトは部分的から適用する できないプロダクト から適用FusionIOの選定基準FusionIOの 使わなくても出来た わなくても出来た 出来 ただ使わなければサーバ台数が サーバ台数 ただ使わなければサーバ台数が膨れ上がっていた 運用コスト改善は えないけど重要 運用コスト改善は見えないけど重要 コスト改善 実際にテストしての信頼性の 実際にテストしての信頼性の高さ しての信頼性 29
  30. 30. まとめ柔軟なプロダクトに対応するための仕組みを用意す柔軟なプロダクトに対応するための仕組みを用意す するための仕組みを用意ることで事業 システムの未来がることで事業、システムの未来が開ける 事業、最後まで確認したそのもう一歩先を確認する最後まで確認したそのもう一歩先を確認する事が安 まで確認したそのもう一歩先 する事定したシステム改善に必要 したシステム改善 システム改善に事業貢献できる での一番理想的 ソリューションの できる中 一番理想的な事業貢献できる中での一番理想的なソリューションの選択を選択を行う 30
  31. 31. この後は弊社根本へ弊社根本へアメーバのストレージに するプラクティスアメーバのストレージに関するプラクティスを語っても プラクティスをらいます さあどー さあどーぞ! 31
  32. 32. Ameba Pigg Best Practice~画像ストレージ構築・運用編~ 株式会社 サイバーエージェント アメーバ事業本部プラットフォームDiv システムディベロップメントグループ 根本英明
  33. 33. 自己紹介根本 英明2008.4入社(中途)担当システム画像ストレージシステムAmebaピグ/ブログ/MBゲームHW周りが多少得意 33
  34. 34. アメーバピグと画像ストレージこんなところで使われているストレージです・・・(ピグとの関連は、ちょっと薄いです) 34
  35. 35. アメーバピグと画像ストレージ 35
  36. 36. アメーバピグと画像ストレージメインはブログのユーザ画像ストレージです 36
  37. 37. アメーバピグと画像ストレージ 37
  38. 38. 画像ストレージシステム紹介2008年10月リリース当初は鬼の不安定さ!!障害件数多数データロストもしましたm(__)m過去最も夜中に起こされた過去最もDC対応をしたシステム 38
  39. 39. とっても印象の悪いシステムです 39
  40. 40. 画像ストレージシステム紹介なぜリリースしたか当時のストレージ容量 >70%だったHW選定~検証まで2カ月しかとれず・・・ 可能な限りの検証を実施 ご迷惑をおかけして大変申し訳ありません 40
  41. 41. が、 41
  42. 42. 苦節2年安定化させることが できました 42
  43. 43. 得られた「Practice」を 紹介します 43
  44. 44. どのくらい捌いてますか?Traffic ??? Gbps投稿容量 約??? GB/dayアクセス数アクセス数 約???億/day(ユーザ画像) ???億/day(ユーザ画像 画像) 44
  45. 45. どのくらい捌いてますか?Traffic Gbps弱 3 Gbps弱投稿容量 約120 GB/dayアクセス数アクセス数 /day(ユーザ画像 画像) 約3億~4億/day(ユーザ画像) 45
  46. 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/146
  47. 47. ストレージ構築の実践Practiceコンポーネントを列挙するコンポーネントを列挙する怪しい部品は交換する! しい部品は交換する 部品 する!思い切る!!複数対策同時進行データの れを考データの流れを考える をよく見物をよく見る!!! 47
  48. 48. ストレージ構成 Server RAID Controller Mini-SAS cable Enclosure HDD(SATA) 1TB x 8(RAID6) 48
  49. 49. ストレージ構成 Server RAID Controllerこの構成の至るところ(全部) Mini-SAS cableに不安定要因が・・・ Enclosure HDD(SATA) 1TB x 8(RAID6) 49
  50. 50. 障害内容Server – RAID間の通信断からのFS破壊によるデータロスト突然HDDを認識しなくなる障害。あわわ。 50
  51. 51. 改善内容安定化まで、、、サーバ改善RAIDカード改善mini-SASケーブル改善Enclosure改善HDD改善 51
  52. 52. 改善内容安定化まで、、、サーバ改善RAIDカード改善mini-SASケーブル改善Enclosure改善HDD改善 52
  53. 53. サーバ改善リリース当初 DELL PE R200を利用(注)DELL推奨構成での利用ではありません!!! 53
  54. 54. サーバ改善リリース当初 DELL PE R200を利用(注)DELL推奨構成での利用ではありません!!! 障害超多発 54
  55. 55. サーバ改善全コンポーネントを列挙・調査 55
  56. 56. サーバ改善全コンポーネントを列挙・調査RAID Controller定格温度:55℃ 56
  57. 57. サーバ改善全コンポーネントを列挙・調査RAID Controller定格温度:55℃動作環境:7X℃ 57
  58. 58. サーバ改善DELL R200 温度:7X℃ 58
  59. 59. サーバ改善DELL R200 温度:7X℃DELL R300 温度:5X℃ 59
  60. 60. サーバ改善DELL R200 温度:7X℃コンポーネントは列挙する!DELL R300 温度:5X℃ 60
  61. 61. その後・・・諸々の対策を打つも、 突然HDDを認識しなくなる 障害。あわわ。の完全解決に至らず、最後の対策を・・・ 61
  62. 62. 最後は、HDD全入替1台のストレージあたり、1TB × 8台が、16セット = 144台入替 62
  63. 63. しかも、以前某A社のリコール級問題で、全台リプレイス後・・・ 63
  64. 64. ちょーやりたくない・・・・と思いつつリプレイス 64
  65. 65. そして・・・・ 65
  66. 66. 安定!!!! 某社製 66
  67. 67. 安定!!!!怪しい部品は交換する! 思い切る!! 某社製 67
  68. 68. 苦節2年弱安定するストレージを構築することができた 68
  69. 69. 苦労した点安定化するまでのみちのり沢山対策(効果なしも含め)• RAIDカード交換• FW/Driver update• Enclosure交換• Cable交換動作確認、難しいんです 69
  70. 70. 苦労した点安定化するまでのみちのり沢山対策(効果なしも含め)RAIDカード交換 複数対策同時進行FW/Driver updateEnclosure交換Cable交換動作確認、難しいんです 70
  71. 71. ストレージ構築の実践Practiceコンポーネントを列挙するコンポーネントを列挙する怪しい部品は交換する! しい部品は交換する 部品 する!思い切る!!複数対策同時進行データの れを考データの流れを考える をよく見物をよく見る!!! 71
  72. 72. おしまい 72
  73. 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. 74. Ameba Water と エンジニアの紹介冊子を配布中!! 74
  75. 75. 質疑応答 75

×