GMO Pepabo, Inc. Ryo kuroda @lamanotrama 2015/08/29 第3回ペパボテックカンファレンス MogileFS をバックエンドとした Private S3の作り方
黒田 良 @lamanotrama > 技術基盤チーム > インフラ担当
前半 (自分) • 全体アーキテクチャ • インフラ 後半 (@hiboma) • APIアプリケーション
前半アジェンダ > 何故Private S3？ > アーキテクチャ > 大規模MogileFSの運用 > Gatewayの仕組み > データインポート
何故Private S3
全社的にサービスインフラを オンプレミスから Private Cloud(Open Stack)に移行
課題
静的コンテンツの保存、配信 > 主に画像 > 容量がそれなりに大きい > 各サービスがそれぞれ違った仕組みで独自に構築している > Nyah(IaaS)上に各サービスが再構築するのは非効率 > 可用性 > スケーラビリティ > 構築、運用コスト...
ペパボのオブジェクト ストレージと言えば
30days Album
30days Album > 2008年リリース > 大規模分散オブジェクトストレージ > perl製のMogileFSを使用 > 総容量: 750TB > 累計オブジェクト数: 22億
高いデータ耐久性、稼働率 > 7年間でデータロストは一回(4個) > (不幸なレア条件が重なったため。鋭意シス テム改善中!) > 計画メンテを除いたサービスダウンは ほぼ無い > (以前は不安定な時期もありました)
vs OpenStack Swift OpenStackにもオブジェクトストレージを提供するコンポー ネントはあるが… > 大規模分散オブジェクトストレージを安定運用するのは甘 くない > 30days AlbumのMogileFSは十分に安定...
vs AWS S3 フルマネージドのS3でいいじゃん？ > 容量や転送量のコスト面でオンプレの方が明ら かに優位 > 同程度の規模だと容量課金のみで数百万円/月 > 長年のノウハウ蓄積によってMogileFSの運用 コストはかなり下がった
名称 ペパボストレージ
名称 ペパボストレージ Bayt ロゴが欲しい
アーキテクチャ
30days
30days + Bayt
Bayt ① ②
1. gateway > Nginx + ngx_mruby > インターネット、インターナルからリク エストを受ける > http(s)://<bucket_name>.hitmitsu.no.domain/ > http://bayt.30...
2. api > Rails + Unicorn > mogilefsd、メタデータdbとのや りとり > 詳細は後半で
この2つを作れば 基本的にはOK
と、その前に 既存システムコンポーネントの 強化、安定化
安定稼働しているとはいえ、全社的 に使うには心もとない部分もある
メトリクスの充実化、可視化
storageサーバの高集積化 自作サーバ期など、紆余曲折を経て 今は/dev/sdarまであるみっしり筐体がメイン
DB(MySQL)サーバのリプレース > 2台→3台 (総入れ替え) > MySQL5.1→MySQL5.5 > MHA導入 短時間のダウンタイムを許容できるなら2台 でもいけなくはない。 が、メンテナンス性がとにかく悪い。
mogilefsdクラスタの強化 負荷が高くなるのは明白なのでスペッ クアップ&台数++
問題発生
mogilefsdがスケールしない mogilefsdはマスタープロセスからワーカ を生やすpreforkモデル _ mogilefsd _ mogilefsd [monitor] _ mogilefsd [replicate] _ mogil...
mogilefsdがスケールしない 子が少ないうちは大丈夫
mogilefsdがスケールしない 増やすと親が子からのメッセージに応答し なくなる(約700プロセスを境に) ❌ ❌ ❌
mogilefsdがスケールしない スループットが大幅に低下。 困った。 ❌ ❌ ❌
mogilefsdがスケールしない 親に気合をいれてみた。 renice -20 -p 親 ❌ ❌ ❌
mogilefsdがスケールしない 元気でた。
副作用 mogilefsdサーバがコンスタントに高負荷で 落ちる。 1. 稀に子の調子がわるくなり、親から殺される 2. 新しく生まれた子は-20の子なので-20 3. 過負荷で不安定になる 4. 更に子が死ぬ 5. -20っ子がモリモリ増える...
過剰なやる気
mogilefsd起動直後と、その後もこ まめにcronで親子のnice値の面倒を みることで解決。 (もうちょい綺麗になんとかしたい…)
DB刺さる問題 1. MySQL5.5化以来、コンスタントにDBが刺さる (デッドロック) 2. 負荷がじりじり上がる 3. MHAマネージャからのヘルスチェックがコケて、 自動でマスターフェイルオーバー 4. 復旧 入れててよかったMHA…と...
雑に解決 > クエリの実行計画が変わったことで、元々使わ れていなかったindexが使われるようになった ことが原因 > mogilefs.file_to_replicate nexttry > 要らんからdrop 色々調査、検証したけど長くなる...
既存の画像配信の品質向上 Bayt GWの仕組みと共通するため、まずは既存(30days)の画像配信周り (Nginx)の改善。 > Keep Alive (client - nginx - unicorn) > Last-Modifiedヘッダ...
gateway
(再度構成図)
実URLへのreproxy処理 gw api storage
実URLへのreproxy処理 GET http://mybucket.domain/a/b.jpg GET http://192.168.1.3/a/b.jpg Host: mybucket.domain gw api storage
実URLへのreproxy処理 X-Accel-Redirect: /reproxy X-Reproxy-URL: http://192.168.1.4/dev1/123.fid http://192.168.1.6/dev8/123.fid gw...
実URLへのreproxy処理 gw api storage GET http://192.168.1.4/dev1/123.fid
実URLへのreproxy処理 gw api storage ❌
実URLへのreproxy処理 gw api storage GET http://192.168.1.6/dev8/123.fid
実URLへのreproxy処理 gw api storage
1. apiへproxy
2. 内部リダイレクトとproxy
3. 2つ目のURLへフォールバック
ややこしいけど便利
apiに届かなかった場合のエラードキュメント S3互換にしないとクライアントで困る。 bodyだけでなくstatus codeも。
ngx_mruby の活用
Serverヘッダ変更 Server: Bayt で帰ってくるとかっこいい。 (add_headerディレクティブでは変更できない)
リクエストUUID(ぽいもの)の発行 Railsまで届かなかった場合でもclient、gw、apiでユ ニークなリクエストIDを共有する為にgwで発行。
apiでHMAC認証をskipさせるヘッダを付与 特定の条件を満たすリクエスト > internalリクエスト > 認証未対応のクライアントからの特定バケットへのリクエスト (S3とは関係ないBayt独自仕様)
ngx_mrubyのオーバーヘッド ほぼ無い(実質的に問題にならない) リクエストトータル で掛かった時間 (mrubyの処理が介 在しない)upstream へのリクエストのみ で掛かった時間
太らない 活発な開発。劇的改善。@matsumotory ++ (スパイクはNginxと関係ないバッチ処理によるもの) ngx_mruby v1.12.14
既存データの import
S3互換なので > 既存のS3クライアント実装をそのままつ かえる > 某サービスの場合だと画像サーバ上のデー タpathをそのまま s3cmd sync
DBメンテ祭り import検証中に発覚した問題への対応。 > ETag(md5値)保存用のカラム追加 > インデックスの追加 > path(object key)カラムのサイズを255→512に変更 > pathをcase sensitive...
粛々とインポート、移行 > 適当な単位でCDNからのOrigin指 定を切り替え > 3TB、1億オブジェクトを移行済 絶賛安定稼働中
今後 > 全サービスのデータを移行 > マルチロケーション(DC)化 > ディザスタリカバリ > サービスエンドポイントの冗長化 > 動的画像リサイズ機能 > URLパス、クエリパターンで動的にリサイズ、 配信
以上。後半に続く。
MogileFSをバックエンドとしたPrivate S3の作り方
Upcoming SlideShare
Loading in...5
×

MogileFSをバックエンドとしたPrivate S3の作り方

247

Published on

第3回ペパボテックカンファレンス

Published in: Engineering
0 Comments
2 Likes
Statistics
Notes
no profile picture user

  • Be the first to comment

No Downloads
Views
Total Views
247
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

MogileFSをバックエンドとしたPrivate S3の作り方

  1. 1. GMO Pepabo, Inc. Ryo kuroda @lamanotrama 2015/08/29 第3回ペパボテックカンファレンス MogileFS をバックエンドとした Private S3の作り方
  2. 2. 黒田 良 @lamanotrama > 技術基盤チーム > インフラ担当
  3. 3. 前半 (自分) • 全体アーキテクチャ • インフラ 後半 (@hiboma) • APIアプリケーション
  4. 4. 前半アジェンダ > 何故Private S3？ > アーキテクチャ > 大規模MogileFSの運用 > Gatewayの仕組み > データインポート
  5. 5. 何故Private S3
  6. 6. 全社的にサービスインフラを オンプレミスから Private Cloud(Open Stack)に移行
  7. 7. 課題
  8. 8. 静的コンテンツの保存、配信 > 主に画像 > 容量がそれなりに大きい > 各サービスがそれぞれ違った仕組みで独自に構築している > Nyah(IaaS)上に各サービスが再構築するのは非効率 > 可用性 > スケーラビリティ > 構築、運用コスト → 求められる大統一オブジェクトストレージサービス
  9. 9. ペパボのオブジェクト ストレージと言えば
  10. 10. 30days Album
  11. 11. 30days Album > 2008年リリース > 大規模分散オブジェクトストレージ > perl製のMogileFSを使用 > 総容量: 750TB > 累計オブジェクト数: 22億
  12. 12. 高いデータ耐久性、稼働率 > 7年間でデータロストは一回(4個) > (不幸なレア条件が重なったため。鋭意シス テム改善中!) > 計画メンテを除いたサービスダウンは ほぼ無い > (以前は不安定な時期もありました)
  13. 13. vs OpenStack Swift OpenStackにもオブジェクトストレージを提供するコンポー ネントはあるが… > 大規模分散オブジェクトストレージを安定運用するのは甘 くない > 30days AlbumのMogileFSは十分に安定している 最初からS3互換APIを備えているというメリットはあるが、 長い目でみるとそこの開発コストは十分相殺されると考えた。
  14. 14. vs AWS S3 フルマネージドのS3でいいじゃん？ > 容量や転送量のコスト面でオンプレの方が明ら かに優位 > 同程度の規模だと容量課金のみで数百万円/月 > 長年のノウハウ蓄積によってMogileFSの運用 コストはかなり下がった
  15. 15. 名称 ペパボストレージ
  16. 16. 名称 ペパボストレージ Bayt ロゴが欲しい
  17. 17. アーキテクチャ
  18. 18. 30days
  19. 19. 30days + Bayt
  20. 20. Bayt ① ②
  21. 21. 1. gateway > Nginx + ngx_mruby > インターネット、インターナルからリク エストを受ける > http(s)://<bucket_name>.hitmitsu.no.domain/ > http://bayt.30d.lan/<bucket_name>/ > apiにproxy > apiだけでは出来ないあれこれ(後ほど)
  22. 22. 2. api > Rails + Unicorn > mogilefsd、メタデータdbとのや りとり > 詳細は後半で
  23. 23. この2つを作れば 基本的にはOK
  24. 24. と、その前に 既存システムコンポーネントの 強化、安定化
  25. 25. 安定稼働しているとはいえ、全社的 に使うには心もとない部分もある
  26. 26. メトリクスの充実化、可視化
  27. 27. storageサーバの高集積化 自作サーバ期など、紆余曲折を経て 今は/dev/sdarまであるみっしり筐体がメイン
  28. 28. DB(MySQL)サーバのリプレース > 2台→3台 (総入れ替え) > MySQL5.1→MySQL5.5 > MHA導入 短時間のダウンタイムを許容できるなら2台 でもいけなくはない。 が、メンテナンス性がとにかく悪い。
  29. 29. mogilefsdクラスタの強化 負荷が高くなるのは明白なのでスペッ クアップ&台数++
  30. 30. 問題発生
  31. 31. mogilefsdがスケールしない mogilefsdはマスタープロセスからワーカ を生やすpreforkモデル _ mogilefsd _ mogilefsd [monitor] _ mogilefsd [replicate] _ mogilefsd [replicate] _ mogilefsd [replicate] _ mogilefsd [replicate] _ mogilefsd [queryworker] _ mogilefsd [queryworker] _ mogilefsd [fsck] _ mogilefsd [fsck] _ mogilefsd [reaper] _ mogilefsd [delete] …
  32. 32. mogilefsdがスケールしない 子が少ないうちは大丈夫
  33. 33. mogilefsdがスケールしない 増やすと親が子からのメッセージに応答し なくなる(約700プロセスを境に) ❌ ❌ ❌
  34. 34. mogilefsdがスケールしない スループットが大幅に低下。 困った。 ❌ ❌ ❌
  35. 35. mogilefsdがスケールしない 親に気合をいれてみた。 renice -20 -p 親 ❌ ❌ ❌
  36. 36. mogilefsdがスケールしない 元気でた。
  37. 37. 副作用 mogilefsdサーバがコンスタントに高負荷で 落ちる。 1. 稀に子の調子がわるくなり、親から殺される 2. 新しく生まれた子は-20の子なので-20 3. 過負荷で不安定になる 4. 更に子が死ぬ 5. -20っ子がモリモリ増える 6. もう無理
  38. 38. 過剰なやる気
  39. 39. mogilefsd起動直後と、その後もこ まめにcronで親子のnice値の面倒を みることで解決。 (もうちょい綺麗になんとかしたい…)
  40. 40. DB刺さる問題 1. MySQL5.5化以来、コンスタントにDBが刺さる (デッドロック) 2. 負荷がじりじり上がる 3. MHAマネージャからのヘルスチェックがコケて、 自動でマスターフェイルオーバー 4. 復旧 入れててよかったMHA…とか言ってる場合ではない。
  41. 41. 雑に解決 > クエリの実行計画が変わったことで、元々使わ れていなかったindexが使われるようになった ことが原因 > mogilefs.file_to_replicate nexttry > 要らんからdrop 色々調査、検証したけど長くなるので省略…
  42. 42. 既存の画像配信の品質向上 Bayt GWの仕組みと共通するため、まずは既存(30days)の画像配信周り (Nginx)の改善。 > Keep Alive (client - nginx - unicorn) > Last-Modifiedヘッダ取り回しのバグ修正 > TLSオプティマイズ > upstream、reproxyのフォールバック設定見直し > storage(WebDAV)サーバのメモリバッファ上限引き上げ、worker数の調整 等などで、 30%程度高速化。レスポンスタイム、スループットの安定化。 @cubicdaiya さんの資料が大変参考になりました。 https://speakerdeck.com/cubicdaiya/nginxfalsepahuomansutiyuningu
  43. 43. gateway
  44. 44. (再度構成図)
  45. 45. 実URLへのreproxy処理 gw api storage
  46. 46. 実URLへのreproxy処理 GET http://mybucket.domain/a/b.jpg GET http://192.168.1.3/a/b.jpg Host: mybucket.domain gw api storage
  47. 47. 実URLへのreproxy処理 X-Accel-Redirect: /reproxy X-Reproxy-URL: http://192.168.1.4/dev1/123.fid http://192.168.1.6/dev8/123.fid gw api storage
  48. 48. 実URLへのreproxy処理 gw api storage GET http://192.168.1.4/dev1/123.fid
  49. 49. 実URLへのreproxy処理 gw api storage ❌
  50. 50. 実URLへのreproxy処理 gw api storage GET http://192.168.1.6/dev8/123.fid
  51. 51. 実URLへのreproxy処理 gw api storage
  52. 52. 1. apiへproxy
  53. 53. 2. 内部リダイレクトとproxy
  54. 54. 3. 2つ目のURLへフォールバック
  55. 55. ややこしいけど便利
  56. 56. apiに届かなかった場合のエラードキュメント S3互換にしないとクライアントで困る。 bodyだけでなくstatus codeも。
  57. 57. ngx_mruby の活用
  58. 58. Serverヘッダ変更 Server: Bayt で帰ってくるとかっこいい。 (add_headerディレクティブでは変更できない)
  59. 59. リクエストUUID(ぽいもの)の発行 Railsまで届かなかった場合でもclient、gw、apiでユ ニークなリクエストIDを共有する為にgwで発行。
  60. 60. apiでHMAC認証をskipさせるヘッダを付与 特定の条件を満たすリクエスト > internalリクエスト > 認証未対応のクライアントからの特定バケットへのリクエスト (S3とは関係ないBayt独自仕様)
  61. 61. ngx_mrubyのオーバーヘッド ほぼ無い(実質的に問題にならない) リクエストトータル で掛かった時間 (mrubyの処理が介 在しない)upstream へのリクエストのみ で掛かった時間
  62. 62. 太らない 活発な開発。劇的改善。@matsumotory ++ (スパイクはNginxと関係ないバッチ処理によるもの) ngx_mruby v1.12.14
  63. 63. 既存データの import
  64. 64. S3互換なので > 既存のS3クライアント実装をそのままつ かえる > 某サービスの場合だと画像サーバ上のデー タpathをそのまま s3cmd sync
  65. 65. DBメンテ祭り import検証中に発覚した問題への対応。 > ETag(md5値)保存用のカラム追加 > インデックスの追加 > path(object key)カラムのサイズを255→512に変更 > pathをcase sensitiveにする為にcollationを変更 約9億レコードのテーブルへのALTERで最長25時間。 MHAのオンラインマスター切り替えを利用したメンテナンスで 全てサービスダウンタイムは無し。
  66. 66. 粛々とインポート、移行 > 適当な単位でCDNからのOrigin指 定を切り替え > 3TB、1億オブジェクトを移行済 絶賛安定稼働中
  67. 67. 今後 > 全サービスのデータを移行 > マルチロケーション(DC)化 > ディザスタリカバリ > サービスエンドポイントの冗長化 > 動的画像リサイズ機能 > URLパス、クエリパターンで動的にリサイズ、 配信
  68. 68. 以上。後半に続く。

  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×