Upgrade to Pro — share decks privately, control downloads, hide ads and more …

4ペタバイトを超えるオブジェクトストレージを ハードウェアからアプリケーションにかけて 運用す...

rsym1290
March 19, 2023
3.2k

4ペタバイトを超えるオブジェクトストレージを ハードウェアからアプリケーションにかけて 運用するノウハウ

rsym1290

March 19, 2023
Tweet

Transcript

  1. 6 - 弊社では独自にオブジェクトストレージを保有しています - ほとんどの人はオブジェクトストレージを使うことはあっても、オブジェクトストレージ自体を作って運用 す ことはあま ないかなと思います - 弊社ではどの

    うにオブジェクトストレージを作 、そして運用してきたのかその知見を「ハードウェアの レイヤか アプリケーションのレイヤにかけて」広く紹介したいと思います 本発表で伝えたいこと
  2. 12 ペパボのオブジェクトストレージ - ペパボ独自のプライベートなオブジェクトストレージ - ペパボ 各サービスから利用される社内向け サービス - S3

    REST API互換(一部だけ実装) - 主な用途 - ショップ・ホームページ用 コンテンツ - 商品画像・ホームページ用 画像など Bayt(ベイト)
  3. 15 - 30daysAlbumは2008年に開始したサービス - MogileFSを使って写真や動画を保存するため ストレージを構築した - Baytは2015年に運用を開始 - それまで

    サービスごとプラットフォーム・ストレージを持っていた - 各サービス 成長に伴い大統一なオブジェクトストレージも必要になった - 30daysAlbumで培ったMogileFSを用いたオブジェクトストレージ 運用知見をBaytに応用 - S3も選択肢になったが自前で運用した方がコスト面で大きなメリットがあった なぜ自前でオブジェクトストレージ? ペパボのオブジェクトストレージ
  4. 16 - コストを重視す な Bayt - S3と比べて非常に安価 - 豊富な機能を重視す な

    S3/GCS - 利用できるS3 REST API 一部だけ - CloudFrontやLambdaなどと 連携における柔軟性 (Baytも連携できるが柔軟性で劣る) BaytとS3/GCSとの使い分け ペパボのオブジェクトストレージ
  5. 19 - 以下の要素で構成さ - client: - リクエストを発行する - tracker: -

    クライアントから リクエストを受け付ける - database: - オブジェクト 保存場所やストレージを構成するサーバ・デバイス 情報を格納したデータベース - storage node: - 実際にオブジェクトが格納される場所 - 弊社で C言語で実装されたcmogstoredを利用 - https://yhbt.net/cmogstored/ MogileFSとは? オブジェクトストレージのアーキテクチャ
  6. 20 MogileFSとは? オブジェクトストレージのアーキテクチャ tracker client storage node database storage node

    storage node リクエスト オブジェクト 取得・格納 (HTTPを利用) オブジェクト 保存先 オブジェクト
  7. 22 30daysAlbumでのMogileFSの利用 オブジェクトストレージのアーキテクチャ HDD HDD HDD HDD HDD HDD cmogstored

    tracker 30daysAlbum用 API MogileFS用DB オブジェクト用 メ タデータ worker フロントエンド アプリ リバースプロキシ DBサーバ ストレージサーバ APIサーバ 画像処理サーバ フロントエンドサー バ https://30d.jp
  8. 23 Baytも含めたMogileFSの利用 オブジェクトストレージのアーキテクチャ HDD HDD HDD HDD HDD HDD cmogstored

    tracker 30daysAlbum用 API Bayt用API MogileFS用DB オブジェクト用 メ タデータ worker フロントエンド アプリ リバースプロキシ DBサーバ ストレージサーバ APIサーバ 画像処理サーバ フロントエンドサー バ リバースプロキシ https://30d.jp https://<Bayt URL>/ MogileFS 運用知見を 生かすためにバックエンドを そ ままにBaytを追加
  9. 30daysAlbum用 API Bayt用API 24 - フロントエンドは別 てい がバックエンドは共有してい - 物理的に

    30daysAlbum オブジェクトとBayt オブジェクト 混在している - MogileFS ドメイン 仕組みを利用して論理的に区別している - 各オブジェクト 複数 ストレージサーバに複製して配置される 30daysAlbumとBaytのオブジェクト オブジェクトストレージのアーキテクチャ HDD HDD HDD HDD HDD HDD cmogstored HDD HDD HDD HDD HDD HDD cmogstored HDD HDD HDD HDD HDD HDD cmogstored tracker
  10. 27 - クラウドの活用が当た 前な昨今、ハードウェアを意識す 場面は減 つつあ - でもクラウドの中身を支えてい のは紛 もなく「ハードウェア」

    - 弊社のオブジェクトストレージも例外ではない ハードウェアの運用ノウハウ オブジェクトストレージを構成するハードウェアについて深掘りしていきます
  11. 28 - ストレージサーバ:15台 - HDD:386本 - 6TB:14本 - 10TB:76本 -

    12TB:89本 - 14TB:120本 - 18TB:87本 ストレージサーバの台数・構成(2023/3/16現在) ハードウェアの運用ノウハウ Checking devices... host device size(G) used(G) free(G) use% ob state I/O% ---- ------------ ---------- ---------- ---------- ------ ---------- ----- [35] dev459 9312.008 8369.544 942.463 89.88% writeable 0.0 [35] dev460 9312.008 8367.161 944.846 89.85% writeable 0.0 [35] dev461 9312.008 8366.666 945.342 89.85% writeable 0.0 … [49] dev839 16762.008 6854.785 9907.222 40.89% writeable 15.3 [49] dev840 16762.008 6855.121 9906.887 40.90% writeable 6.4 [49] dev841 16762.008 6855.199 9906.809 40.90% writeable 10.0 [49] dev842 16762.008 6854.847 9907.161 40.90% writeable 3.3 ---- ------------ ---------- ---------- ---------- ------ total:4803153.439 4124898.135 678255.304 85.88% 総容量:4.58ペタバイト
  12. 29 - 2023/3/16現在で総容量4.58ペタバイト - オブジェクトを預か ことができ だけの容量を常に維持す 必要があ - 大容量を確保するために大量

    HDDが必要 オブジェクトストレージに必要な総容量は常に増える ハードウェアの運用ノウハウ
  13. 32 - サーバもHDDもいつか壊 - 壊 =ストレージの総容量が減 ・故障に対す 対応が増え - 壊

    前に廃棄す 必要があ サーバもHDDも寿命がある ハードウェアの運用ノウハウ
  14. 36 - 古いサーバやHDDは積極的に廃棄す (一時的にストレージの総量は減 ) - サーバを廃棄す ことでサーバのラックスペースを確保でき - 確保したスペースに大容量HDDを搭載した性能の良いサーバを投入す

    ストレージサーバの増設・退役のライフサイクル ハードウェアの運用ノウハウ ストレージサーバ #1 (6TB HDD x 16) ストレージサーバ #2 (6TB HDD x 16) ストレージサーバ #3 (6TB HDD x 16) ストレージサーバ #2 (6TB HDD x 16) ストレージサーバ #3 (6TB HDD x 16) ストレージサーバ #4 (18TB HDD x 16) ストレージサーバ #2 (6TB HDD x 16) ストレージサーバ #3 (6TB HDD x 16) サーバラック サーバラック サーバラック total:288TB total:192TB total:480TB ストレージサーバ #1 廃棄 ストレージサーバ #4 増設
  15. 37 - HDDの収容能力と筐体サイズのバランス - 収容能力が高い=限られたラックスペースを有効活用できる - 採用しているストレージサーバ 収容能力 - 2U

    16Bayサーバ - 4U 36Bayサーバ - cmogstoredを動かすサーバの性能要件 - 実 CPU/メモリ そこまでいらない ストレージサーバの増設・サーバの選定 ハードウェアの運用ノウハウ ※ Bay(ベイ):HDDを収容できるスペース こと
  16. 38 - 採用してい HDD - データセンタ向けHDD - フォームファクタ:LFF(3.5inch) - 回転数:7200rpm

    - 書き込み方式:CMR - SSDではない理由 - 1ドライブあたり データ容量 HDD 方が圧倒的に優れている - SSD HDDに比べて容量単価が高い - Bayt 要件として HDDでもIO性能 十分足りる HDDの選定 ハードウェアの運用ノウハウ
  17. 44 - リリースした そ で終わ ではない - サーバやHDDに 寿命がある -

    時間 流れ・サービス 成長につれて当時十分な性能だったサーバ 相対的に性能不足になる - リリース・退役・廃棄まで面倒をみ 必要があ - 古くなったサーバを”壊れる前に”退役させて廃棄するまでが運用 - 壊れてからで 遅い ストレージサーバの退役 ハードウェアの運用ノウハウ 古いサーバを棄てることで初めて新しいサーバを取り入れることができる
  18. 45 - とはいえどうしても壊 こともあ - smartmontoolsを利用したHDDの監視 - https://www.smartmontools.org/ - HDD

    不調・故障を検知すると自動的に issueを起票する仕組みを導入 HDDの故障 ハードウェアの運用ノウハウ
  19. 46 - MogileFSでは以下のステータスで各デバイス(HDD)を管理してい - deadというステータスを利用することでそ デバイスをオブジェクトストレージから切り離す MogileFSの機能を利用した古いHDD・故障HDDの切り離し ハードウェアの運用ノウハウ GET PUT

    DELETE 用途 alive ◯ ◯ ◯ 平常時 これをつかう drain ◯ × ◯ 新規オブジェクト PUTだけ止める場合 (あまり使わない) readonly ◯ × × 書き込みを一時停止する場合 (あまり使わない) down × × × サーバ・ディスク メンテナンスなど (alive/drain/readonlyに復帰可能) dead × × × 該当デバイスを2度と使わないようにする (alive/drain/readonlyに復帰不可)
  20. 47 - HDDのステータスをdeadにす ことで古いHDD/故障HDDを切 離す - 各オブジェクト MogileFS 仕組みで複数 ストレージサーバに複製して配置されている

    - HDD ステータスがdeadになるとMogileFSによってオブジェクト 再レプリケーションが実行される MogileFSの機能を利用した古いHDD・故障HDDの切り離し ハードウェアの運用ノウハウ HDD HDD HDD HDD HDD HDD cmogstored HDD HDD HDD HDD HDD HDD cmogstored HDD HDD HDD HDD HDD HDD cmogstored tracker
  21. 52 - REST API - REST 原則を適用したAPI - インターフェースを満たしていれ 実装に制約

    ない - S3のAPI Referenceに従ってREST APIを実装してい - https://docs.aws.amazon.com/pdfs/AmazonS3/latest/API/s3-api.pdf BaytはS3 REST API互換のオブジェクトストレージ オブジェクトストレージのAPIの実装
  22. 53 - 実装してい API - GetBucket - GetObject - HeadObject

    - PutObject - CopyObject - DeleteObject - GetObjectACL - PutObjectACL 全てのAPI・オプションを実装しているわけではない オブジェクトストレージのAPIの実装
  23. 54 $ aws s3api get-object --endpoint=http://<endpoint_of_bayt>/ --profile <profile_of_bayt> --bucket <bucket>

    --key hello.txt hello.txt { "AcceptRanges": "bytes", "LastModified": "2020-01-28T22:58:00+00:00", "ContentLength": 11, "ETag": "\"3cb95cfbe1035bce8c448fcaf80fe7d9\"", "ContentType": "text/plain", "Metadata": {} } $ cat hello.txt hello,world% 実行例(GetObject) オブジェクトストレージのAPIの実装
  24. 58 Baytの構成図に当てはめると オブジェクトストレージのAPIの実装 HDD HDD HDD HDD HDD HDD cmogstored

    tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ https://<Bayt URL>/ interface API MogileFS
  25. 60 GetObjectの流れ オブジェクトストレージのAPIの実装 GET /sample/object HDD HDD HDD HDD HDD

    HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ
  26. 61 GetObjectの流れ オブジェクトストレージのAPIの実装 メタデータ取得 - Content-Type - Content-Length - Etag

    HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ オブジェクト格納先 問い合わせ GET /sample/object
  27. 62 GetObjectの流れ オブジェクトストレージのAPIの実装 HDD HDD HDD HDD HDD HDD cmogstored

    tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ オブジェクト 格納先を検索 検索結果に基づいてオブジェクトを取得 GET /sample/object
  28. 63 GetObjectの流れ オブジェクトストレージのAPIの実装 HDD HDD HDD HDD HDD HDD cmogstored

    tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ GET /sample/object オブジェクト格納先をHTTPヘッダに格納して返す - X-Reproxy-URL:http://<storage>/path/to/sample/object
  29. 64 GetObjectの流れ オブジェクトストレージのAPIの実装 X-Reproxy-URLに記載されたパスへオブジェクトを 取りに行く HDD HDD HDD HDD HDD

    HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ
  30. 65 GetObjectの流れ オブジェクトストレージのAPIの実装 レスポンス - Content-Type - Content-Length - Etag

    - Body(オブジェクト) HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ
  31. 67 今後のオブジェクトストレージ/S3移設 - S3へ移設す ことにな ました - これまで コストを重視して Baytを利用してきましたが、サービス

    成長に伴い機能面を重視するた めS3を利用する方針に切り替えました - 弊社のテックブログもご覧ください - 『プライベートなオブジェクトストレージから S3へ 移設で直面した 2つ 課題』 https://tech.pepabo.com/2022/12/16/bayt-to-s3-goope/ 2015年から運用されていたBaytですが
  32. 68 今後のオブジェクトストレージ/S3移設 - 今後もストレージはどんどん成長していくことでし う - 5ペタバイト、6ペタバイト... - とはいえ課題もあ ます

    - 運用 属人化 - ハードウェア・MogileFS 有識者が限られている - そ 他 アプリケーションも同様 - サービス全体 レガシー化 30daysAlbumの運用は今後も続きます
  33. 69 今後のオブジェクトストレージ/S3移設 - 今後の取 組み - サービス 成長を今後も支えていく - 属人化

    対策 - 運用 toil削減・自動化による運用負担 軽減 - ドキュメント 充実 - オンコールトレーニングを通じた関係者 障害対応力 向上 - プラットフォーム 見直し - オンプレミス中心 アーキテクチャからクラウド・オンプレミス ハイブリット構成へ - ハードウェア 運用を最小限にするため - コストバランスを踏まえてストレージ 引き続きオンプレミスで 運用を継続 30daysAlbumの運用は今後も続きます
  34. 74