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

1. 1 4ペタバイトを超えるオブジェクトストレージを ハードウェアからアプリケーションにかけて 運用するノウハウ 三上烈史（みかみ　つ し） / GMO PEPABO inc. 2023.03.19 YAPC::Kyoto 2023
2. まずは自己紹介 2
3. 3 自己紹介 三上　烈史（みかみ　つよし） https://twitter.com/rsym1290 GMOペパボ株式会社 技術部プラットフォームグループ 2016年9月入社 担当している業務 - SRE - インフラ 趣味 - ランニング・マラソン
4. 4 会社紹介 GMOペパボ株式会社 https://pepabo.com/ 主な事業 - ホスティング - EC支援 - ハンドメイド - そ 他
5. 本題へ 5
6. 6 - 弊社では独自にオブジェクトストレージを保有しています - ほとんどの人はオブジェクトストレージを使うことはあっても、オブジェクトストレージ自体を作って運用 す ことはあま ないかなと思います - 弊社ではどの うにオブジェクトストレージを作 、そして運用してきたのかその知見を「ハードウェアの レイヤか アプリケーションのレイヤにかけて」広く紹介したいと思います 本発表で伝えたいこと
7. 7 - ペパボのオブジェクトストレージ - オブジェクトストレージのアーキテクチャ - ハードウェアの運用ノウハウ - オブジェクトストレージのAPIの実装 - 今後のオブジェクトストレージ/S3移設 アジェンダ
8. ペパボのオブジェクトストレージ 8
9. 9 ペパボのオブジェクトストレージ 弊社では2つのサービスでオブジェクトストレージを運用しています
10. 10 ペパボのオブジェクトストレージ - 写真や動画をアルバム形式で共有でき サービス - 大量の写真・動画保存す ためにオブジェクトストレージを用 いています - 2023/3/16時点で約8.7億枚の写真をお預か しています 30daysAlbum https://30d.jp/
11. 11 ペパボのオブジェクトストレージ 30daysAlbum https://30d.jp/ - YAPC::Kyoto 2023のスペシャルサンクスとして掲載させていただいてお ます - 過去の写真が30daysAlbumにアップロードさ ています - YAPC::Tokyo 2019：https://30d.jp/yapcjapan/4
12. 12 ペパボのオブジェクトストレージ - ペパボ独自のプライベートなオブジェクトストレージ - ペパボ 各サービスから利用される社内向け サービス - S3 REST API互換（一部だけ実装） - 主な用途 - ショップ・ホームページ用 コンテンツ - 商品画像・ホームページ用 画像など Bayt(ベイト)
13. 13 とこ で
14. 14 現代におけるオブジェクトストレージといえば？ ペパボのオブジェクトストレージ
15. 15 - 30daysAlbumは2008年に開始したサービス - MogileFSを使って写真や動画を保存するため ストレージを構築した - Baytは2015年に運用を開始 - それまで サービスごとプラットフォーム・ストレージを持っていた - 各サービス 成長に伴い大統一なオブジェクトストレージも必要になった - 30daysAlbumで培ったMogileFSを用いたオブジェクトストレージ 運用知見をBaytに応用 - S3も選択肢になったが自前で運用した方がコスト面で大きなメリットがあった なぜ自前でオブジェクトストレージ？ ペパボのオブジェクトストレージ
16. 16 - コストを重視す な Bayt - S3と比べて非常に安価 - 豊富な機能を重視す な S3/GCS - 利用できるS3 REST API 一部だけ - CloudFrontやLambdaなどと 連携における柔軟性 （Baytも連携できるが柔軟性で劣る） BaytとS3/GCSとの使い分け ペパボのオブジェクトストレージ
17. オブジェクトストレージのアーキテクチャ 17
18. 18 - Perlで実装さ たスケーラブルな分散ストレージを構築でき OSS - https://github.com/mogilefs/MogileFS-Server MogileFS(モガイルエフエス)とは？ オブジェクトストレージのアーキテクチャ
19. 19 - 以下の要素で構成さ - client： - リクエストを発行する - tracker： - クライアントから リクエストを受け付ける - database： - オブジェクト 保存場所やストレージを構成するサーバ・デバイス 情報を格納したデータベース - storage node： - 実際にオブジェクトが格納される場所 - 弊社で C言語で実装されたcmogstoredを利用 - https://yhbt.net/cmogstored/ MogileFSとは？ オブジェクトストレージのアーキテクチャ
20. 20 MogileFSとは？ オブジェクトストレージのアーキテクチャ tracker client storage node database storage node storage node リクエスト オブジェクト 取得・格納 （HTTPを利用） オブジェクト 保存先 オブジェクト
21. 21 弊社のサービスに当てはめてみます
22. 22 30daysAlbumでのMogileFSの利用 オブジェクトストレージのアーキテクチャ HDD HDD HDD HDD HDD HDD cmogstored tracker 30daysAlbum用 API MogileFS用DB オブジェクト用 メ タデータ worker フロントエンド アプリ リバースプロキシ DBサーバ ストレージサーバ APIサーバ 画像処理サーバ フロントエンドサー バ https://30d.jp
23. 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を追加
24. 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
25. ハードウェアの運用ノウハウ 25
26. 26 みなさんが運用してい サービスで ハードウェアって意識してますか？
27. 27 - クラウドの活用が当た 前な昨今、ハードウェアを意識す 場面は減 つつあ - でもクラウドの中身を支えてい のは紛 もなく「ハードウェア」 - 弊社のオブジェクトストレージも例外ではない ハードウェアの運用ノウハウ オブジェクトストレージを構成するハードウェアについて深掘りしていきます
28. 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ペタバイト
29. 29 - 2023/3/16現在で総容量4.58ペタバイト - オブジェクトを預か ことができ だけの容量を常に維持す 必要があ - 大容量を確保するために大量 HDDが必要 オブジェクトストレージに必要な総容量は常に増える ハードウェアの運用ノウハウ
30. 30 - ラックを無尽蔵に増やすことはできない - サーバもHDDも寿命があ - サーバの性能は相対的に劣化す ただサーバ・HDDを増設すれば良いわけではない ハードウェアの運用ノウハウ
31. 31 - サーバラック代は高い - 1ラックあたり月額20〜30万円（データセンターによる） - サーバを闇雲に増やすとサーバラックの追加も必要 - 運用コストがどんどん増えていく ラックを無尽蔵に増やすことはできない ハードウェアの運用ノウハウ
32. 32 - サーバもHDDもいつか壊 - 壊 ＝ストレージの総容量が減 ・故障に対す 対応が増え - 壊 前に廃棄す 必要があ サーバもHDDも寿命がある ハードウェアの運用ノウハウ
33. 33 HDDを廃棄す とこうな ます サーバもHDDも寿命がある ハードウェアの運用ノウハウ
34. 34 - 時の流 と共に 高性能なサーバが出現す - 当時導入さ たサーバは相対的に性能が不足していく サーバの性能は相対的に劣化する ハードウェアの運用ノウハウ
35. 35 ライフサイクルを意識した ハードウェアの運用が必須
36. 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 増設
37. 37 - HDDの収容能力と筐体サイズのバランス - 収容能力が高い＝限られたラックスペースを有効活用できる - 採用しているストレージサーバ 収容能力 - 2U 16Bayサーバ - 4U 36Bayサーバ - cmogstoredを動かすサーバの性能要件 - 実 CPU/メモリ そこまでいらない ストレージサーバの増設・サーバの選定 ハードウェアの運用ノウハウ ※ Bay(ベイ)：HDDを収容できるスペース こと
38. 38 - 採用してい HDD - データセンタ向けHDD - フォームファクタ：LFF(3.5inch) - 回転数：7200rpm - 書き込み方式：CMR - SSDではない理由 - 1ドライブあたり データ容量 HDD 方が圧倒的に優れている - SSD HDDに比べて容量単価が高い - Bayt 要件として HDDでもIO性能 十分足りる HDDの選定 ハードウェアの運用ノウハウ
39. 39 参考：HDDの記録密度は現在も増え続けている ハードウェアの運用ノウハウ PC Watch 『東芝、30TB超のニアラインHDDを開発へ。11枚の多層化技術を活用』 https://pc.watch.impress.co.jp/docs/news/1455334.html
40. 40 余談ですが...
41. 41 - 半導体不足前は、納期2ヶ月前後で安定してました - 今は、在庫がなけ ば半年〜1年かか ます 半導体不足の影響を受けてます😢 ハードウェアの運用ノウハウ 納期から逆算した発注計画を立てる必要があります
42. 42 - 海外製のサーバを採用す と円安の影響を受けやすい - 調達時の為替レートに って費用が変動（予算へのインパクト） 為替の影響を受けることもあります😢😢 ハードウェアの運用ノウハウ Bloomberg 『ドル・円また下落シグナルか、移動平均線がデッドクロスへ』 https://www.bloomberg.co.jp/news/articles/2022-11-30/RM5ABJT1UM0Y01
43. 43 話を戻します 🙇
44. 44 - リリースした そ で終わ ではない - サーバやHDDに 寿命がある - 時間 流れ・サービス 成長につれて当時十分な性能だったサーバ 相対的に性能不足になる - リリース・退役・廃棄まで面倒をみ 必要があ - 古くなったサーバを”壊れる前に”退役させて廃棄するまでが運用 - 壊れてからで 遅い ストレージサーバの退役 ハードウェアの運用ノウハウ 古いサーバを棄てることで初めて新しいサーバを取り入れることができる
45. 45 - とはいえどうしても壊 こともあ - smartmontoolsを利用したHDDの監視 - https://www.smartmontools.org/ - HDD 不調・故障を検知すると自動的に issueを起票する仕組みを導入 HDDの故障 ハードウェアの運用ノウハウ
46. 46 - MogileFSでは以下のステータスで各デバイス(HDD)を管理してい - deadというステータスを利用することでそ デバイスをオブジェクトストレージから切り離す MogileFSの機能を利用した古いHDD・故障HDDの切り離し ハードウェアの運用ノウハウ GET PUT DELETE 用途 alive ◯ ◯ ◯ 平常時 これをつかう drain ◯ × ◯ 新規オブジェクト PUTだけ止める場合 （あまり使わない） readonly ◯ × × 書き込みを一時停止する場合 （あまり使わない） down × × × サーバ・ディスク メンテナンスなど (alive/drain/readonlyに復帰可能) dead × × × 該当デバイスを2度と使わないようにする (alive/drain/readonlyに復帰不可)
47. 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
48. 48 こういった運用を継続した結果
49. 49 4ペタバイトを超えました😅 運用ノウハウ：ハードウェア編 もう一回ストレージを増設すると 5ペタバイトをこえそう 退役で容量が減っている 赤線が青線に触れないように運用
50. オブジェクトストレージのAPIの実装 50
51. 51 BaytのAPI設計/実装 （S3 REST API）
52. 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の実装
53. 53 - 実装してい API - GetBucket - GetObject - HeadObject - PutObject - CopyObject - DeleteObject - GetObjectACL - PutObjectACL 全てのAPI・オプションを実装しているわけではない オブジェクトストレージのAPIの実装
54. 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の実装
55. 55 S3 REST APIの実装
56. 56 インターフェースを満たしていれば実装は自由 オブジェクトストレージのAPIの実装
57. 57 BaytはMogileFSをバックエンドとしてREST APIを実装 オブジェクトストレージのAPIの実装 Ruby on Railsで実装
58. 58 Baytの構成図に当てはめると オブジェクトストレージのAPIの実装 HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ https://<Bayt URL>/ interface API MogileFS
59. 59 GetObjectを例に流 を追ってみます
60. 60 GetObjectの流れ オブジェクトストレージのAPIの実装 GET /sample/object HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ
61. 61 GetObjectの流れ オブジェクトストレージのAPIの実装 メタデータ取得 - Content-Type - Content-Length - Etag HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ オブジェクト格納先 問い合わせ GET /sample/object
62. 62 GetObjectの流れ オブジェクトストレージのAPIの実装 HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ オブジェクト 格納先を検索 検索結果に基づいてオブジェクトを取得 GET /sample/object
63. 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
64. 64 GetObjectの流れ オブジェクトストレージのAPIの実装 X-Reproxy-URLに記載されたパスへオブジェクトを 取りに行く HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ
65. 65 GetObjectの流れ オブジェクトストレージのAPIの実装 レスポンス - Content-Type - Content-Length - Etag - Body(オブジェクト) HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用 メ タデータ リバースプロキシ
66. 今後のオブジェクトストレージ/S3移設 66
67. 67 今後のオブジェクトストレージ/S3移設 - S3へ移設す ことにな ました - これまで コストを重視して Baytを利用してきましたが、サービス 成長に伴い機能面を重視するた めS3を利用する方針に切り替えました - 弊社のテックブログもご覧ください - 『プライベートなオブジェクトストレージから S3へ 移設で直面した 2つ 課題』 https://tech.pepabo.com/2022/12/16/bayt-to-s3-goope/ 2015年から運用されていたBaytですが
68. 68 今後のオブジェクトストレージ/S3移設 - 今後もストレージはどんどん成長していくことでし う - 5ペタバイト、6ペタバイト... - とはいえ課題もあ ます - 運用 属人化 - ハードウェア・MogileFS 有識者が限られている - そ 他 アプリケーションも同様 - サービス全体 レガシー化 30daysAlbumの運用は今後も続きます
69. 69 今後のオブジェクトストレージ/S3移設 - 今後の取 組み - サービス 成長を今後も支えていく - 属人化 対策 - 運用 toil削減・自動化による運用負担 軽減 - ドキュメント 充実 - オンコールトレーニングを通じた関係者 障害対応力 向上 - プラットフォーム 見直し - オンプレミス中心 アーキテクチャからクラウド・オンプレミス ハイブリット構成へ - ハードウェア 運用を最小限にするため - コストバランスを踏まえてストレージ 引き続きオンプレミスで 運用を継続 30daysAlbumの運用は今後も続きます
70. 70 今後のオブジェクトストレージ/S3移設 - 弊社のオブジェクトストレージを運用してきたのか、その知見を紹介しました - MogileFSを用いたオブジェクトストレージ アーキテクチャ - ハードウェア 導入から退役まで ライフサイクル - S3 REST API 実装 - 30daysAlbum/Baytそ ぞ の今後についてもお話ししました まとめ
71. 71 最後に
72. 72 YAPC::Kyoto 2023の写真をぜひ 30daysAlbumへ！
73. ご清聴ありがとうございました！ 73