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そ ぞ の今後についてもお話ししました まとめ

Slide 71

Slide 71 text

71 最後に

Slide 72

Slide 72 text

72 YAPC::Kyoto 2023の写真をぜひ 30daysAlbumへ!

Slide 73

Slide 73 text

ご清聴ありがとうございました! 73

Slide 74

Slide 74 text

74