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

by rsym1290

Slide 1

Slide 1 text

1 4ペタバイトを超えるオブジェクトストレージをハードウェアからアプリケーションにかけて運用するノウハウ三上烈史（みかみ　つし） / GMO PEPABO inc. 2023.03.19 YAPC::Kyoto 2023

Slide 2

Slide 2 text

まずは自己紹介 2

Slide 3

Slide 3 text

3 自己紹介三上　烈史（みかみ　つよし） https://twitter.com/rsym1290 GMOペパボ株式会社技術部プラットフォームグループ 2016年9月入社担当している業務 - SRE - インフラ趣味 - ランニング・マラソン

Slide 4

Slide 4 text

4 会社紹介 GMOペパボ株式会社 https://pepabo.com/ 主な事業 - ホスティング - EC支援 - ハンドメイド - そ他

Slide 5

Slide 5 text

本題へ 5

Slide 6

Slide 6 text

6 - 弊社では独自にオブジェクトストレージを保有しています - ほとんどの人はオブジェクトストレージを使うことはあっても、オブジェクトストレージ自体を作って運用すことはあまないかなと思います - 弊社ではどのうにオブジェクトストレージを作、そして運用してきたのかその知見を「ハードウェアのレイヤかアプリケーションのレイヤにかけて」広く紹介したいと思います本発表で伝えたいこと

Slide 7

Slide 7 text

7 - ペパボのオブジェクトストレージ - オブジェクトストレージのアーキテクチャ - ハードウェアの運用ノウハウ - オブジェクトストレージのAPIの実装 - 今後のオブジェクトストレージ/S3移設アジェンダ

Slide 8

Slide 8 text

ペパボのオブジェクトストレージ 8

Slide 9

Slide 9 text

9 ペパボのオブジェクトストレージ弊社では2つのサービスでオブジェクトストレージを運用しています

Slide 10

Slide 10 text

10 ペパボのオブジェクトストレージ - 写真や動画をアルバム形式で共有できサービス - 大量の写真・動画保存すためにオブジェクトストレージを用いています - 2023/3/16時点で約8.7億枚の写真をお預かしています 30daysAlbum https://30d.jp/

Slide 11

Slide 11 text

11 ペパボのオブジェクトストレージ 30daysAlbum https://30d.jp/ - YAPC::Kyoto 2023のスペシャルサンクスとして掲載させていただいておます - 過去の写真が30daysAlbumにアップロードさています - YAPC::Tokyo 2019：https://30d.jp/yapcjapan/4

Slide 12

Slide 12 text

12 ペパボのオブジェクトストレージ - ペパボ独自のプライベートなオブジェクトストレージ - ペパボ各サービスから利用される社内向けサービス - S3 REST API互換（一部だけ実装） - 主な用途 - ショップ・ホームページ用コンテンツ - 商品画像・ホームページ用画像など Bayt(ベイト)

Slide 13

Slide 13 text

13 とこで

Slide 14

Slide 14 text

14 現代におけるオブジェクトストレージといえば？ペパボのオブジェクトストレージ

Slide 15

Slide 15 text

15 - 30daysAlbumは2008年に開始したサービス - MogileFSを使って写真や動画を保存するためストレージを構築した - Baytは2015年に運用を開始 - それまでサービスごとプラットフォーム・ストレージを持っていた - 各サービス成長に伴い大統一なオブジェクトストレージも必要になった - 30daysAlbumで培ったMogileFSを用いたオブジェクトストレージ運用知見をBaytに応用 - S3も選択肢になったが自前で運用した方がコスト面で大きなメリットがあったなぜ自前でオブジェクトストレージ？ペパボのオブジェクトストレージ

Slide 16

Slide 16 text

16 - コストを重視すな Bayt - S3と比べて非常に安価 - 豊富な機能を重視すな S3/GCS - 利用できるS3 REST API 一部だけ - CloudFrontやLambdaなどと連携における柔軟性（Baytも連携できるが柔軟性で劣る） BaytとS3/GCSとの使い分けペパボのオブジェクトストレージ

Slide 17

Slide 17 text

オブジェクトストレージのアーキテクチャ 17

Slide 18

Slide 18 text

18 - Perlで実装さたスケーラブルな分散ストレージを構築でき OSS - https://github.com/mogilefs/MogileFS-Server MogileFS(モガイルエフエス)とは？オブジェクトストレージのアーキテクチャ

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

20 MogileFSとは？オブジェクトストレージのアーキテクチャ tracker client storage node database storage node storage node リクエストオブジェクト取得・格納（HTTPを利用）オブジェクト保存先オブジェクト

Slide 21

Slide 21 text

21 弊社のサービスに当てはめてみます

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 Baytも含めたMogileFSの利用オブジェクトストレージのアーキテクチャ HDD HDD HDD HDD HDD HDD cmogstored tracker 30daysAlbum用 API Bayt用API MogileFS用DB オブジェクト用メタデータ worker フロントエンドアプリリバースプロキシ DBサーバストレージサーバ APIサーバ画像処理サーバフロントエンドサーバリバースプロキシ https://30d.jp https:/// MogileFS 運用知見を生かすためにバックエンドをそままにBaytを追加

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

ハードウェアの運用ノウハウ 25

Slide 26

Slide 26 text

26 みなさんが運用していサービスでハードウェアって意識してますか？

Slide 27

Slide 27 text

27 - クラウドの活用が当た前な昨今、ハードウェアを意識す場面は減つつあ - でもクラウドの中身を支えていのは紛もなく「ハードウェア」 - 弊社のオブジェクトストレージも例外ではないハードウェアの運用ノウハウオブジェクトストレージを構成するハードウェアについて深掘りしていきます

Slide 28

Slide 28 text

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ペタバイト

Slide 29

Slide 29 text

29 - 2023/3/16現在で総容量4.58ペタバイト - オブジェクトを預かことができだけの容量を常に維持す必要があ - 大容量を確保するために大量 HDDが必要オブジェクトストレージに必要な総容量は常に増えるハードウェアの運用ノウハウ

Slide 30

Slide 30 text

30 - ラックを無尽蔵に増やすことはできない - サーバもHDDも寿命があ - サーバの性能は相対的に劣化すただサーバ・HDDを増設すれば良いわけではないハードウェアの運用ノウハウ

Slide 31

Slide 31 text

31 - サーバラック代は高い - 1ラックあたり月額20〜30万円（データセンターによる） - サーバを闇雲に増やすとサーバラックの追加も必要 - 運用コストがどんどん増えていくラックを無尽蔵に増やすことはできないハードウェアの運用ノウハウ

Slide 32

Slide 32 text

32 - サーバもHDDもいつか壊 - 壊＝ストレージの総容量が減・故障に対す対応が増え - 壊前に廃棄す必要があサーバもHDDも寿命があるハードウェアの運用ノウハウ

Slide 33

Slide 33 text

33 HDDを廃棄すとこうなますサーバもHDDも寿命があるハードウェアの運用ノウハウ

Slide 34

Slide 34 text

34 - 時の流と共に高性能なサーバが出現す - 当時導入さたサーバは相対的に性能が不足していくサーバの性能は相対的に劣化するハードウェアの運用ノウハウ

Slide 35

Slide 35 text

35 ライフサイクルを意識したハードウェアの運用が必須

Slide 36

Slide 36 text

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 増設

Slide 37

Slide 37 text

37 - HDDの収容能力と筐体サイズのバランス - 収容能力が高い＝限られたラックスペースを有効活用できる - 採用しているストレージサーバ収容能力 - 2U 16Bayサーバ - 4U 36Bayサーバ - cmogstoredを動かすサーバの性能要件 - 実 CPU/メモリそこまでいらないストレージサーバの増設・サーバの選定ハードウェアの運用ノウハウ ※ Bay(ベイ)：HDDを収容できるスペースこと

Slide 38

Slide 38 text

38 - 採用してい HDD - データセンタ向けHDD - フォームファクタ：LFF(3.5inch) - 回転数：7200rpm - 書き込み方式：CMR - SSDではない理由 - 1ドライブあたりデータ容量 HDD 方が圧倒的に優れている - SSD HDDに比べて容量単価が高い - Bayt 要件として HDDでもIO性能十分足りる HDDの選定ハードウェアの運用ノウハウ

Slide 39

Slide 39 text

39 参考：HDDの記録密度は現在も増え続けているハードウェアの運用ノウハウ PC Watch 『東芝、30TB超のニアラインHDDを開発へ。11枚の多層化技術を活用』 https://pc.watch.impress.co.jp/docs/news/1455334.html

Slide 40

Slide 40 text

40 余談ですが...

Slide 41

Slide 41 text

41 - 半導体不足前は、納期2ヶ月前後で安定してました - 今は、在庫がなけば半年〜1年かかます半導体不足の影響を受けてます😢 ハードウェアの運用ノウハウ納期から逆算した発注計画を立てる必要があります

Slide 42

Slide 42 text

42 - 海外製のサーバを採用すと円安の影響を受けやすい - 調達時の為替レートにって費用が変動（予算へのインパクト）為替の影響を受けることもあります😢😢 ハードウェアの運用ノウハウ Bloomberg 『ドル・円また下落シグナルか、移動平均線がデッドクロスへ』 https://www.bloomberg.co.jp/news/articles/2022-11-30/RM5ABJT1UM0Y01

Slide 43

Slide 43 text

43 話を戻します 🙇

Slide 44

Slide 44 text

44 - リリースしたそで終わではない - サーバやHDDに寿命がある - 時間流れ・サービス成長につれて当時十分な性能だったサーバ相対的に性能不足になる - リリース・退役・廃棄まで面倒をみ必要があ - 古くなったサーバを”壊れる前に”退役させて廃棄するまでが運用 - 壊れてからで遅いストレージサーバの退役ハードウェアの運用ノウハウ古いサーバを棄てることで初めて新しいサーバを取り入れることができる

Slide 45

Slide 45 text

45 - とはいえどうしても壊こともあ - smartmontoolsを利用したHDDの監視 - https://www.smartmontools.org/ - HDD 不調・故障を検知すると自動的に issueを起票する仕組みを導入 HDDの故障ハードウェアの運用ノウハウ

Slide 46

Slide 46 text

46 - MogileFSでは以下のステータスで各デバイス(HDD)を管理してい - deadというステータスを利用することでそデバイスをオブジェクトストレージから切り離す MogileFSの機能を利用した古いHDD・故障HDDの切り離しハードウェアの運用ノウハウ GET PUT DELETE 用途 alive ◯ ◯ ◯ 平常時これをつかう drain ◯ × ◯ 新規オブジェクト PUTだけ止める場合（あまり使わない） readonly ◯ × × 書き込みを一時停止する場合（あまり使わない） down × × × サーバ・ディスクメンテナンスなど (alive/drain/readonlyに復帰可能) dead × × × 該当デバイスを2度と使わないようにする (alive/drain/readonlyに復帰不可)

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

48 こういった運用を継続した結果

Slide 49

Slide 49 text

49 4ペタバイトを超えました😅 運用ノウハウ：ハードウェア編もう一回ストレージを増設すると 5ペタバイトをこえそう退役で容量が減っている赤線が青線に触れないように運用

Slide 50

Slide 50 text

オブジェクトストレージのAPIの実装 50

Slide 51

Slide 51 text

51 BaytのAPI設計/実装（S3 REST API）

Slide 52

Slide 52 text

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の実装

Slide 53

Slide 53 text

53 - 実装してい API - GetBucket - GetObject - HeadObject - PutObject - CopyObject - DeleteObject - GetObjectACL - PutObjectACL 全てのAPI・オプションを実装しているわけではないオブジェクトストレージのAPIの実装

Slide 54

Slide 54 text

54 $ aws s3api get-object --endpoint=http:/// --profile --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の実装

Slide 55

Slide 55 text

55 S3 REST APIの実装

Slide 56

Slide 56 text

56 インターフェースを満たしていれば実装は自由オブジェクトストレージのAPIの実装

Slide 57

Slide 57 text

57 BaytはMogileFSをバックエンドとしてREST APIを実装オブジェクトストレージのAPIの実装 Ruby on Railsで実装

Slide 58

Slide 58 text

58 Baytの構成図に当てはめるとオブジェクトストレージのAPIの実装 HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用メタデータリバースプロキシ https:/// interface API MogileFS

Slide 59

Slide 59 text

59 GetObjectを例に流を追ってみます

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

63 GetObjectの流れオブジェクトストレージのAPIの実装 HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用メタデータリバースプロキシ GET /sample/object オブジェクト格納先をHTTPヘッダに格納して返す - X-Reproxy-URL：http:///path/to/sample/object

Slide 64

Slide 64 text

64 GetObjectの流れオブジェクトストレージのAPIの実装 X-Reproxy-URLに記載されたパスへオブジェクトを取りに行く HDD HDD HDD HDD HDD HDD cmogstored tracker Bayt用API MogileFS用DB オブジェクト用メタデータリバースプロキシ

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

今後のオブジェクトストレージ/S3移設 66

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

68 今後のオブジェクトストレージ/S3移設 - 今後もストレージはどんどん成長していくことでしう - 5ペタバイト、6ペタバイト... - とはいえ課題もあます - 運用属人化 - ハードウェア・MogileFS 有識者が限られている - そ他アプリケーションも同様 - サービス全体レガシー化 30daysAlbumの運用は今後も続きます

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

70 今後のオブジェクトストレージ/S3移設 - 弊社のオブジェクトストレージを運用してきたのか、その知見を紹介しました - MogileFSを用いたオブジェクトストレージアーキテクチャ - ハードウェア導入から退役までライフサイクル - S3 REST API 実装 - 30daysAlbum/Baytそぞの今後についてもお話ししましたまとめ