サービスを構成する全サーバが トラックに載って 遠くのデータセンターへ旅立ったお話

Transcript

1. サービスを構成する全サーバが トラックに載って 遠くのデータセンターへ旅⽴ったお話 技術部プラットフォームグループ 三上 烈史
2. ⾃⼰紹介
3. 三上烈史（みかみ つよし） SNS - https://twitter.com/rsym1290 担当している業務 - インフラ - SRE 趣味 - ランニング‧マラソン GMOペパボ株式会社 技術部プラットフォームグループ
4. みなさんは こんな諺(ことわざ)を 聞いたことありますか？
5. “かわいいサーバーには旅をさせよ”
6. ChatGPTによる解説 つまり⼤切なサーバー達を新しい環境に挑戦させることで、 サービスを成⻑させることの重要性を⽰唆している 🤔
7. とうわけで今⽇話すのは • かわいいサーバーの旅⽴ちの様⼦ • サーバーが旅⽴ったことでサービスがどう成⻑したのか
8. (冗談はさておき)
9. 本題へ
10. • 9/26〜9/28にペパボのサービスである30days Albumを新しいデータセ ンタへ移設しました • その⼿段はなんと「全てのサーバーをトラックで⼀⻫に搬送する」と いうものです • 本トークではそのお話をします 本トークで話すこと
11. • 30days Albumのオンプレミス事情 • データセンター移設が決まった経緯 • 移設⽅式 • リスク対策 • 移設メンテの様⼦ • 移設を終えて アジェンダ
12. 30days Albumの オンプレミス事情
13. 30days Album • 写真や動画をアルバム形式で共 有できるサービス • 総アップロード数： ◦ 約9.4億枚(2023/11/24時点) • ⼤量の写真‧動画保存するため にオブジェクトストレージを ⽤ いている https://30d.jp/

14. 30days Albumは⼤規模なストレージが命 2023/9/26メンテ当時の台数 • ラック3台契約 • サーバー19台 • ストレージサーバー14台 • HDD約350本(6TB〜22TBまでたくさん) ◦ ストレージの総容量は4.5PB(ペタバイト)を超えています
15. ストレージの容量推移
16. データセンター移設が 決まった経緯
17. グループで契約しているデータセンターがある • グループ各社はこのデータセンターを利⽤できる • ペパボのサービスの多くはここを使⽤している GMOインターネットグループのデータセンター 30days Albumは使⽤していなかった • 個別に他社のハウジングサービスを契約‧利⽤していた ※ ハウジングサービス データセンター内のラックなどのスペースを貸し出すサービス
18. グループシナジー • グループで契約されたデータセンターで統⼀できる • サービスのアーキテクチャを柔軟に変更しやすい 移設が決まった経緯 より新しいデータセンターの採⽤ • 数年前に運⽤が始まったデータセンターを利⽤できるようになった • より新しい設備での運⽤ができる
19. 移設⽅式
20. 限られた期限と予算 • 移設の話が上がったのは2022年 • 移設期限は2023年3Q • 4PBを超える全データを新データセンターに転送するのは⾮現実的 ◦ パブリック回線は⼀般利⽤のトラフィックも混在する ◦ 専⽤線の確保にはコストがかかる ◦ 新‧旧データセンターの並⾏期間が数ヶ⽉続くことでコスト増加
21. これしかない！
22. リスク対策
23. 交通事故等による全損＝サービス終了 • 可能性はかなり低いとはいえリスクは存在する ◦ 搬送だけでも⼗数時間かかる • オブジェクトが格納されたHDDが⼤量に壊れると復旧不可能 • サービスにとどまらずペパボの経営に対する打撃も⼤きい 搬送する以上破損リスクは完全に回避できない 搬送されても壊れないとは限らない • 搬送中の振動でHDD故障する • 電源を投⼊してもサーバーが起動しない
24. とはいえ全ての画像のバックアップは不可能 • S3へのフルバックアップ ◦ aws cliのsyncコマンドを使⽤したバックアップ ◦ snowballを利⽤したバックアップ • いずれもコスト‧時間の都合で不可能と判断 ◦ 全てバックアップしようとすると ▪ ⽉額約600万円 + イニシャル ▪ バックアップコストだけでサービスが⼤⾚字
25. ストレージ上のオブジェクト再配置 • ストレージを2グループに分けてグループ単位でオブジェクトを冗⻑化 • 1トラック1グループで搬送することでデータロストのリスクを半減 予算と期限が許す限りの対策を実施 可能な範囲でのユーザ画像のバックアップ • 期間‧予算より全てのバックアップは不可能 • 最悪のケースが発⽣した時に可能な限り復元‧返還できるように
26. ストレージ上の オブジェクト再配置
27. オブジェクトストレージはMogileFSで実現している • https://github.com/mogilefs • オブジェクトは2つのストレージサーバーへ冗⻑に格納される • 配置先は使⽤率の低いハードディスクを優先 30days Albumのオブジェクトストレージ MogileFSサーバー DBサーバー storage storage storage storage storage storage tracker フロントエンド 画像処理 APIサーバー database
28. 30days Albumでのオブジェクトの冗⻑化 storage storage storage storage storage storage これはアウト storage storage storage storage storage storage これはアウト データロストの条件 storage storage storage storage storage storage これはセーフ
29. MogileFSでは冗⻑化のポリシーを決められる $ sudo mogadm domain list domain class mindevcount replpolicy hashtype -------------------- -------------------- ------------- ------------ ------- … 30days default 2 HostsPerNetwork(group_a=1, group_b=1) NONE $ sudo mogadm settings list ... network_zones = group_a,group_b zone_group_a = 192.168.XX.0/24 zone_group_b = 192.168.YY.0/24 group_aとgroup_bに1つずつ配置される様にレプリケーション group_aとgroup_bはサブネットで区別する
30. オブジェクトを2グループに再配置 グループA storage storage storage storage storage storage • オブジェクトは2つのサーバーへ冗⻑に格納される • 配置先はハードディスクの使⽤率に依存する • 実質ランダム MogileFSの 機能で再配置 storage storage storage • オブジェクトは2つのグループに冗⻑に格納される • 各グループのどのハードディスクに格納されるかは使 ⽤率に依存する グループB storage storage storage 各グループに必ず1つ オブジェクトがある 従来 再配置
31. 2グループに再配置して搬送の冗⻑化 旧データセンター グループA グループB こちらのオブジェクトは無事 新データセンター 1トラック1グループで搬送できる • 両⽅のグループに必ずオブジェクトが1つずつある ◦ 1台で完全破損があってもオブジェクト⾃体は残る • もう⼀⽅のグループでもディスク故障があると⼀部ロスト
32. リスク対策以外の準備
33. 現地データセンターでのネットワーク疎通テスト • ネットワーク関連の想定が違っていたら元も⼦もない • 事前に検証サーバーを1台搬送して疎通検証 • ついでに搬⼊のリハーサル リスク対策以外の準備 メンテ⼿順の作成 • ペパボ都合だけの⼿順ではメンテは失敗する • 搬送業者、現地データセンターの作業員との連携 • サーバー起動後のサービスの動作検証
34. 移設メンテの様⼦を ちょっとだけ
35. 9/26 21:00~9/28 9:00にかけて実施 1. サービスをメンテに切り替え 2. サーバー全停⽌ 3. 全サーバーのアンラッキング 4. トラックで搬送 🚚💨 5. 全サーバーのラッキング‧ケーブリング 6. 電源投⼊‧動作確認 7. メンテ解除 メンテの実施
36. かわいいサーバー達の旅⽴ち🚚 ※写真はいずれも関係者各位へ許可いただいた範囲で使⽤しています
37. 新データセンターへ移動 サーバー達は旅立ち
 チームメンバーも旅立ち

38. 旅先に到着したかわいいサーバー達 ※写真はいずれも関係者各位へ許可いただいた範囲で使⽤しています
39. ラッキングされたサーバー達 ※写真はいずれも関係者各位へ許可いただいた範囲で使⽤しています
40. ケーブリングの様⼦  ※写真はいずれも関係者各位へ許可いただいた範囲で使⽤しています
41. 物理故障はほとんどなかった
 • サービス影響のないサーバーが1台故障した程度 • HDDに⾄っては1本も壊れなかった 🎉 メンテナンスは無事に終了
 発生したハプニング
 • ストレージサーバー⽤のラックレールが短くて設置できない ◦ 当⽇にラック内⽀柱の位置を調整して対処しました 💦
42. 移設メンテを終えて
43. 精神的なプレッシャーが非常に大きい
 • 限りなく可能性が低いとはいえリスク発⽣時の被害は甚⼤ • 事故‧故障の仕⽅次第ではサービス終了に直結する • 可能な限りの対策をしたとはいえリスクを回避できない 感想
 新しいデータセンターの設備を見るのは楽しい
 • インフラ担当とはいえこういう機会はなかなかないので
44. 新しいラックの恩恵
 • ネットワークが⾼速化してボトルネックが解消された ◦ ユーザ体験の向上 • ラックの耐荷重が増え搭載効率が上がった ◦ 4Uストレージサーバー+36本のHDDで50kg近くあるのです • 利⽤可能な電⼒が増えた ◦ 採⽤するサーバーの幅が増える 移設してよかったこと

45. まとめ
46. トラックに乗ってサーバーが旅立つお話をしました
 • 期限・予算が限られた中で様々な手段の検討を経てトラックでの搬送に踏み 切った
 • ただ搬送するだけでなく想定されるリスク対策をできるだけ実施
 • 故障はほとんどなく無事にメンテを終えられた
 • 新データセンターで30days Albumをもっと成長させたいと思います
 まとめ