Tweet
Tweet

Slide 1

Slide 1 text

30days Album の裏側 後日談 YAPC::Asia Tokyo 2010 2010/10/15

Slide 2

Slide 2 text

はじめに CM をご覧ください

Slide 3

Slide 3 text

自己紹介 • 金子 健介 • 所属 o 株式会社 paperboy&co. o ホスティング事業本部 30days Album チー ム o プログラマ • ハンドルネーム等 o 刺身☆ブーメラン o id:a666666 o @kyanny

Slide 4

Slide 4 text

30days Album とは • http://30d.jp/ • 写真共有・保存サービス • 2008年4月〜 • 期間限定オンラインアルバム • 容量無制限オンラインフォトストレージ

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

本日のアジェンダ • 30days Album の裏側 • MogileFS の運用ノウハウ・苦労話 • 自作サーバの紹介 • Perlbal の運用ノウハウ・苦労話

Slide 7

Slide 7 text

30days Album の裏側 (1) • 表側は Ruby on Rails • 裏側はいろいろ o Perlbal o MogileFS o Gearman o TheSchwartz o Catalyst 実はけっこう Perl を多用してます

Slide 8

Slide 8 text

30days Album の裏側 (2) • 過去のプレゼンテーション o 関西オープンソース2008 http://www.slideshare.net/mizzy/2008-30da o YAPC::Asia Tokyo 2009  http://www.slideshare.net/hiboma/yapc-asia

Slide 9

Slide 9 text

30days Album の裏側 (3)

Slide 10

Slide 10 text

30days Album の裏側 (4) • 疎結合を意識したシステム構成 o 各コンポーネント間は HTTP API でやり取 り o API は Catalyst 製ウェブアプリケーション o REST を意識したシンプルな実装 (GET, PUT)

Slide 11

Slide 11 text

30days Album の裏側 (5) • メリット o 負荷分散 o 開発能率アップ 得意な人に任せられる o メンテナンスのしやすさ  他のコンポーネントへの影響が少ない o 他のサービスからの利用 ログピ http://logpi.jp/ ブクログのパブー http://p.booklog.jp/

Slide 12

Slide 12 text

30days Album の裏側 (6) • デメリット o システム構成の複雑化 一台のサーバが複数の役割を持つと把握 しづらい o サーバ台数の増加 o レイヤーが増えることによるオーバーヘッ ドの増加 o 他サービスへの影響範囲の増大 例: 障害、メンテナンス

Slide 13

Slide 13 text

30days Album の裏側 終わり NEXT: MogileFS の運用ノウハウ・苦労話

Slide 14

Slide 14 text

MogileFS の運用ノウハウ・苦労話 • MogileFS の障害対応の話 • MogileFS のリバランスについて

Slide 15

Slide 15 text

MogileFS の障害対応の話 (1) • ストレージサーバでディスク障害が発生した • LVM で構築していたデータ領域は修復不可 能 • どのように対応したか • MogileFS のストレージプールから切り離 し • サーバを再構築 • ストレージプールに復帰

Slide 16

Slide 16 text

MogileFS の障害対応の話 (2) • 障害発生前 • 複数のサーバに分散して保存されている

Slide 17

Slide 17 text

MogileFS の障害対応の話 (3) • 障害発生時 • 障害発生サーバ上のデータはアクセス不能 • 他のサーバ上のデータにはアクセス可能

Slide 18

Slide 18 text

MogileFS の障害対応の話 (4) • 障害対応中 • ストレージプールから切り離す

Slide 19

Slide 19 text

MogileFS の障害対応の話 (5) • 切り離しの手順 o device を dead にする $ mogadm device mark mogfs5 dev5 dead

Slide 20

Slide 20 text

MogileFS の障害対応の話 (6) • 障害対応中 • コピーがあるのでサービスには影響なし • 他のホストにも自動的にコピーされる

Slide 21

Slide 21 text

MogileFS の障害対応の話 (7) • コピーされていることを確認するには • X-REPROXY-URL ヘッダをみる • dead にした device の URL が外れる • 別の device の URL が追加される • file_on テーブルのレコード数を数える SELECT COUNT(*) FROM file_on WHERE devid = 5; • 他の device へコピーされるたびに減る

Slide 22

Slide 22 text

MogileFS の障害対応の話 (8) • 障害復旧後 • 復旧したサーバをストレージプールへ復帰 • 障害対応中のサービス停止なし

Slide 23

Slide 23 text

MogileFS の障害対応の話 (9) • 復帰の手順 o device を aliveにする $ mogadm device mark mogfs5 dev5 alive

Slide 24

Slide 24 text

MogileFS の障害対応の話 (10) • その他にやったこと o Perlbal を再起動する X-REPROXY-CACHE-FOR をクリア dead な device の URL をキャッシュし てるため Perlbal は X-REPROXY-URL が 200 を返 さないと次の URL をとりにいくため、 必須ではない

Slide 25

Slide 25 text

MogileFS の障害対応の話 終わり NEXT: MogileFS のリバランスについて

Slide 26

Slide 26 text

MogileFS のリバランスについて (1) • リバランスとは o ストレージノード間でデータを平準化する 機能 o バックグランドで走る o 任意のタイミングで開始・終了できる o http://code.google.com/p/mogilefs/wiki/Rebala $ mogadm settings set enable_rebalance 1

Slide 27

Slide 27 text

MogileFS のリバランスについて (2) • リバランスの動作例 (1) • 分散して保存されている

Slide 28

Slide 28 text

MogileFS のリバランスについて (3) • リバランスの動作例 (2) • 使用量が少ない device へファイルを移動

Slide 29

Slide 29 text

MogileFS のリバランスについて (4) • リバランスの動作例 (3) • ストレージの使用量が平準化される

Slide 30

Slide 30 text

MogileFS のリバランスについて (5) • どういうときに使うか • 新しいストレージノードを追加したとき • 残容量が少なくなったとき • class を変更したとき • ファイルのコピー数を制御する仕組み • ファイルの重要度によってコピー数をか えられる • あとで変更することができる

Slide 31

Slide 31 text

MogileFS リバランスについて (6) • 注意点 o MySQL の負荷 MogileFS のバージョンアップで改善し た SELECT クエリが減った

Slide 32

Slide 32 text

MogileFS のリバランスについて (7) • 注意点（続き） o ネットワーク帯域をかなり使う o ストレージノードのディスク I/O も激しい o サーバリソースのモニタリングは必須 Munin を使ってます o サービスへのアクセスが多い夜間はオフに

Slide 33

Slide 33 text

MogileFS リバランスについて 終わり NEXT: 自作サーバの紹介

Slide 34

Slide 34 text

自作サーバの紹介 • 自作サーバをつくりました o MP-100 通称マッパ 「マサキパワー」の略 馬崎 (まさき) さん作なので o ストレージサーバ mogstored o 2010年4月〜 (1号機) o 2010年9月〜 (2号機)

Slide 35

Slide 35 text

※写真は制作中のものです

Slide 36

Slide 36 text

自作サーバのスペック • CPU o Inete Celeron E3000番台 • RAM o DDR2メモリ 2GB(1GBx2) • HDD o データ領域 2TB HDD x 8 o システム領域 Intel製40GB SSD x 1 • マザーボード o Intel製microATXマザー • ポートマルチプライヤ

Slide 37

Slide 37 text

自作サーバの特徴 • HDDの固定にL字金具を使用 • リモート管理可能なマザーボードを採用 • Intel AMT • ポートマルチプライヤーでHDDを8本搭載 • 値段の関係で多ポートRAIDカードは見 送った

Slide 38

Slide 38 text

自作サーバこぼれ話 (1) • パーツ選定の基準 o 値段 > 信頼性 o MogileFS で冗長化できているためパーツ 単体の信頼性は高くなくてもよい 今のところハードウェアに起因する障害 は無し • 設計のノウハウがなく苦労した o 自作サーバカンファレンスで仕入れたネタ がベース o Cerevoさんとはてなさんを参考にさせて頂 きました

Slide 39

Slide 39 text

自作サーバこぼれ話 (2) • MP-100 の 100 って？ o 制作当時、馬崎さんの体重が 100kg だっ た o 現在は省エネ化して 75kg o ちなみに Max 値は 125kg

Slide 40

Slide 40 text

自作サーバの今後 • 次の目標 o HDD 12 本搭載 HDD マウンタの作成が課題 o ストレージ以外の用途も検討 ジョブサーバなど

Slide 41

Slide 41 text

自作サーバの紹介 終わり NEXT: Perlbal の運用ノウハウ・苦労話

Slide 42

Slide 42 text

Perlbal の運用ノウハウ・苦労話 • 2010/10〜 動画アップロードに対応 • http://30d.jugem.jp/?eid=115 • Perlbal と動画配信にまつわる苦労話 o FLV の疑似ストリーミングの話 o Perlbal と Range ヘッダの話

Slide 43

Slide 43 text

FLV の疑似ストリーミングの話 (1) • FLV の疑似ストリーミング o 例: YouTube, ニコニコ動画 o シーク可能であること • 一般的な仕組み o 動画プレイヤーが ?start=**** のようなクエ リストリングつきでリクエストを送る **** の部分はバイト数 FLV ファイルに埋め込まれたメタデータ o サーバ側で **** の部分に応じたデータを返 す FLV ヘッダを付与する必要あり

Slide 44

Slide 44 text

FLV の疑似ストリーミングの話 (2) • 一般的なソリューション o lighttpd の mod_flv_streaming が有名 o http://blog.lighttpd.net/articles/2006/03/09/flv- Apache や nginx にも同様のモジュール がある o 30days Album は Perlbal を使っている

Slide 45

Slide 45 text

FLV の疑似ストリーミングの話 (3) • どうやって解決したか o Perlbal プラグインを書いた Reproxy リクエストに Range ヘッダを 追加 レスポンスヘッダを調整 レスポンスボディに FLV ヘッダを追加 o フックポイントを追加するために本体にも 手を入れた http://github.com/mizzy/Perlbal/commit/cb6

Slide 46

Slide 46 text

FLV の疑似ストリーミングの話 終わり NEXT: Perlbal と Range ヘッダの話

Slide 47

Slide 47 text

Perlbal と Range ヘッダの話 (1) • Range ヘッダつきリクエストを送ると Perlbal がエラーを返す • 原因は X-REPROXY-EXPECTED-SIZE ヘッダ • データが不完全でないかチェックする仕組 み o Perlbal と MogileFS の間のストレージ API で付与している

Slide 48

Slide 48 text

Perlbal と Range ヘッダの話 (2) • Perlbal はどう振る舞うか • ストレージ API へ GET • ストレージ API が X-REPROXY-URL と X- REPROXY-EXPECTED-SIZE を返す o X-REPROXY-URL ヘッダで返された URL を GET o Content-Length と X-REPROXY- EXPECTED-SIZE を比較 o 数値が一致しなければ次の X-REPROXY- URL をとりにいく

Slide 49

Slide 49 text

Perlbal と Range ヘッダの話 (3) • 問題点 o Content-Length と X-REPROXY- EXPECTED-SIZE が常に異なってしまう o ストレージ API が Range ヘッダを考慮 していなかったため o Perlbal は次の X-REPROXY-URL をとりに いく o 全ての URL に対して Reproxy 失敗とみな して 503 を返してしまう

Slide 50

Slide 50 text

Perlbal と Range ヘッダの話 (4) • どうやって解決したか o Range ヘッダがある場合は適切な X- REPROXY-EXPECTED-SIZE ヘッダを返 すようにした o 複数のレンジセットが指定されている場合 は X-REPROXY-EXPECTED-SIZE ヘッダ を返さないようにした 例: Range: bytes=0-100,200-300 参考: 部分的 GET とレンジ単位

Slide 51

Slide 51 text

Perlbal と Range ヘッダの話 (4) 終わり NEXT: まとめ

Slide 52

Slide 52 text

まとめ • MogileFS の運用ノウハウ・苦労話 o リバランスの概要説明 o 障害対応の事例紹介 • 自作サーバの紹介 • Perlbal の運用ノウハウ・苦労話 o 動画配信にまつわる諸問題の事例紹介 o Perlbal プラグインや本体の拡張で対応し た

Slide 53

Slide 53 text

宣伝 • 30days Album PRO プランのクーポンありま す o お手元のノベルティグッズをご覧ください

Slide 54

Slide 54 text

30days Album の裏側 後日談 ご静聴ありがとうございました

Slide 55

Slide 55 text

ご質問はございますか？