Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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パス、クエリパターンで動的にリサイズ、
配信
以上。後半に続く。
API編 by @hiboma
MogileFSをバックエンドとしたPrivate S3の作り方
MogileFSをバックエンドとしたPrivate S3の作り方
Upcoming SlideShare
Loading in …5
×

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

11,760 views

Published on

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

Published in: Engineering

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. 以上。後半に続く。 API編 by @hiboma

×