YAPC::Kyoto 2023 登壇レポート -Vol.02 / 開発者向けブログ・イベント

Perlを中心としたIT関連カンファレンス「YAPC::KYOTO- 2023」が3月19日に京都市の京都リサーチパークで開催されました。Perlに限らないさまざまな技術情報が満載のイベントです。今回は「try/catch」をテーマにしたということで、初めて現地とオンラインというハイブリッドでの開催となりました。

GMOインターネットグループからは、GMOペパボの技術者が参加して講演を行いました。今回はその講演から『4PB（ペタバイト）を超えるオブジェクトストレージをハードウェアからアプリケーションにかけて運用するノウハウ』をお届けします。

登壇者

三上烈史（みかみつよし）　@rsym1290
GMOペパボ株式会社技術部プラットフォームグループ

30days Albumを支えるオブジェクトストレージ

三上が今回のテーマとして取り上げるのは、写真共有サービス「30days Album」とプライベートなオブジェクトストレージ「Bayt」です。

GMOペパボでは、独自にオブジェクトストレージを保有しており、複数のサービスで活用しています。一般的なサービスでオブジェクトストレージを利用することも多くなっていますが、自らオブジェクトストレージを作って運用することになるという例はなかなかないのでは、と三上は話します。そうしたことから、どのようにオブジェクトストレージを構築して運用してきたのか、そのノウハウも含めて紹介されました。

GMOペパボのサービス内で、特にオブジェクトストレージが重要な役割を果たしているのが、30days AlbumとBaytという2つのサービスです。この2つのサービスには密接な関係があります。

GMOペパボの提供するサービス一覧。この中でも特にオブジェクトストレージを活用しているのが30days AlbumとBaytです。

低コストの自前オブジェクトストレージ

30days Albumは、撮影した写真や動画をアップロードして共有できるアルバム形式のサービスで、パスワードではなく「合い言葉」という形で認証して共有できます。2008年にスタートしたサービスで、2023年3月16日の時点でおよそ8.7億枚の写真を保管しているそうです。

30days Albumは写真や動画の共有サービス。約8.7億枚の写真を保管しています。

Baytは、GMOペパボ独自のプライベートなオブジェクトストレージです。GMOペパボの各サービスがアップロード先として利用していて、S3互換であることが特徴の1つです。AmazonS3で利用できるGetObjectやPutObjectといった一部のAPIを実装していて、S3と同じような感覚で利用することができるようになっています。

GMOペパボでは、ECサイト作成支援「カラーミーショップ」で商品画像のアップロード先や、ホームページ作成サービス「グーペ」のコンテンツのアップロード先などで利用されています。

S3やGCS（Google Cloud Storage）といった既存のオブジェクトストレージを使わずに、なぜわざわざ自前で開発しているかというと、その理由として30days Albumの運用を通じて培った知見とコストが関係していると三上は説明します。

前述の通り30days Albumのスタートは2008年。サービスの特性上、オブジェクトストレージが必要になるので、まずはPerl製のMogileFSを使ってオブジェクトストレージを構築しました。その後、2015年頃になると、カラーミーショップなどほかのサービスを含めて事業規模が拡大し、各サービスでもオブジェクトストレージのニーズなどが高まってきたそうです。

当初はOpenStack SwiftやS3を使うといった案があったものの、最終的にはS3互換のAPIを実装することでオブジェクトストレージ提供することにしたそうです。理由としては、この時点で30days Albumで7年間かけて自前のオブジェクトストレージで運用した実績があり、コストがかからない、実装の手間が削減できる、運用も安定する、という点があったそうです。

こうして生まれたのがBaytで、それまでサービスごとにストレージが異なっていたのを、統一されたオブジェクトストレージに統合できるようになりました。

とはいえオブジェクトストレージをBaytだけに限定したわけではなく、コストを重視するならBayt、機能を重視するならS3／GCSという使い分けになっています。最低限のオブジェクトストレージの機能でアップロードするだけでいい場合などはBayt、それで機能が足りなければS3などを使うという形になっているとのこと。

MogileFSとBaytの構成

BaytのベースとなったMogileFSは、スケーラブルな分散ストレージを構築できるOSSで、4つの要素で構成されています。

client：リクエストを発行する
tracker：クライアントからのリクエストを受け付ける
database：オブジェクトの保存場所やストレージを構成するサーバー・デバイスの情報を格納したデータベース
storage node：実際にオブジェクトが格納される場所で、GMOペパボではC言語で実装されたcmogstoredを利用

続いて30days Albumに当てはめた構成について説明されました。前段階としてユーザーが利用するフロントエンドとしてのアプリケーションがあり、アップロードされた画像のサムネイルを作成するなどの画像処理のためのサーバーがあります。続いて30days Album用のAPIがあり、これが「client」に相当します。

さらにtrackerやdatabase、storage nodeが存在しており、storage nodeではたくさんのHDDを並べてストレージサーバーが構築されています。

Baytの場合、MogileFS運用の知見をそのまま生かすため、こうした構成をそのまま利用しました。ここに、Baytとして必要なアプリケーションやフロントのリバースプロキシなどを追加して実装しています。

つまり、フロントは分かれているけれどもバックエンドは共有されているということで、物理的には30days AlbumとBaytのそれぞれのオブジェクトが混在している形になっています。1つのHDDの中に30days Albumでアップロードされた画像も、Baytにアップロードされたコンテンツが保管されているわけです。

ここでMogileFSのドメインという仕組みを利用して、あるオブジェクトが30days Album、カラーミーショップなどのいずれに属しているかを論理的に区別しています。また、複数のストレージサーバーを構成していることで、HDDが1つだけでなくストレージサーバー自体が1つ壊れても復旧できるよう冗長性も確保しています。

30days AlbumとBaytのオブジェクトはバックエンドで共有化されていて混在していますが、ドメインの仕組みによって論理的に区別されています

ハードウェアはやみくもに増やせない、その3つの課題

続いて三上はハードウェアに関して取り上げます。S3やGCSのようなクラウド全盛時代になると、ハードウェアを意識することは少なくなってきます。しかし、クラウドを支えているのはハードウェアなので、運用側は意識する場面があると三上は話します。

GMOペパボの場合、ストレージサーバーとして15台を運用しており、その中にHDDが386本存在（3月16日時点）。総容量は4.58ペタバイトという容量になっています。しかもこうした容量は常に増え続けるため、十分な容量を常にキープし続ける必要があります。そのため、大容量HDDを確保して増設していくことになります。

ストレージサーバーの台数は15台、HDDは386本となり、総容量は4.58ペタバイトに達しています

しかし、やみくもにただ増設すればいいというわけではないと三上は指摘します。そこにある課題は3つです。

サーバーラックは無尽蔵に増やせない
基本的にはサーバラックは月額払いでの契約が一般的で、「データセンターにもよりますが、1ラックで月額20～30万円」と三上は言います。ラックの追加もむやみにできるわけではなく、サーバラックを増やせば増やすほど運用コストも上がります。
サーバーもHDDも寿命がある
ハードウェアはいずれ壊れるものです。HDDが壊れればストレージ総容量が減るし、それを見据えた増設が必要です。壊れたあとの対処は大変なので、できれば壊れる前に廃棄するのが理想です。
サーバーの性能は相対的に劣化する
ハードウェアに関する技術は日々進歩しており、年々より高性能なサーバーが登場します。こうしたサーバの登場により、導入した当時のサーバは時間の経過に伴い相対的に性能面で劣ることになります。また、サービスを長年運用するとサービスが成長し、導入当時の性能だけではいずれ耐えきれなくなることが考えられます。そのため、単にサーバーを導入すればいいというわけではないと三上は言います。

こうした課題に対して三上は、「ライフサイクルを意識したハードウェアの運用が必要」と指摘します。

ライフサイクルを意識して4ペタバイトまでストレージを運用

GMOペパボでは、ストレージサーバーの帯域や容量のライフサイクルを作って運用しています。

例えばサーバーラックに3台のストレージサーバーがあり、HDDが288TBの容量だった場合に、6TB×16ベイのサーバーを1つ廃棄すると、容量は192TBに減少します。しかし、ラックのスペース自体は確保できるので、容量の大きいより良いストレージサーバーを導入することができます。例えば18TB×16ベイのストレージサーバーを増設すると、トータル容量も480TBに拡大できます。

サーバーの選定も重要です。オブジェクトストレージは容量が命なので、1U、2Uといったサーバーのサイズの中でどれだけHDDを搭載できるかが重要になります。GMOペパボでは、2Uサイズで16ベイのHDD、または4Uで36ベイのHDDを搭載したサーバーを中心に利用していると三上は説明。

30days AlbumとBaytの運用経験から、cmogstoredはCPUやメモリの性能はそれほど求められていないということが分かり、サーバーを選択しやすいというメリットもあるそうです。30days AllbumとBaytでは、CPUはインテル Xeon Bronze系、メモリは8GB程度であれば運用可能とのことです。

HDDはデータセンター向けの製品を採用。常時稼働が前提なので耐久性の高いものを選択しています。保証期間も3～5年の保証期間で利用できるため、データセンター向けHDDが基本になります。

ちなみに、1ドライブ当たりのデータ容量が大きく、容量単価が安いという点からSSDではなくHDDを採用しているそうですが、Baytの要求水準からすると、IO性能はHDDでも十分とのことでした。

三上は余談といいつつ、ここ最近の半導体不足の影響を受けてストレージサーバーの納期が延びている点を指摘します。今までは2カ月程度だった納期が、在庫がない場合は半年から1年先になってしまっているそうで、納期から逆算した発注計画が必要だと言います。

為替もインパクトがあり、海外製サーバーを採用した場合に円安の影響を受けやすい点も課題です。前年の段階で予算計画を立てても、為替の変動で想定していたサーバー構成だと予算オーバーしてしまう場合もあるため、こうしたリスクもあるとのことです。

こうして運用していくストレージサーバーですが、ハードウェアの寿命があるため最終的には退役、廃棄までが運用になります。壊れてからでは遅いので、壊れる前に退役・廃棄をして、それによって新しいストレージサーバーを入れられるようになります。

とはいえ、HDDが急に壊れてしまうことはあるので、その対策も必要になります。GMOペパボではsmartmontoolsを利用したHDDの監視を行っています。これによって不良・故障を検知しており、問題を検知すると自動でメールが送信されます。これを使って自動でissueを立てるという仕組みになっているそうです。

壊れたHDDの切り離しはMogileFSの機能を利用。MogileFSではHDDを5つのステータスで管理しており、切り離す場合にはdeadフラグを設定して使用できなくします。保存されているデータは冗長構成で他のドライブにも保存されており、MogileFSは切り離しでHDDが減っても、冗長性を維持するよう自動でレプリケーションをやり直してくれるという機能もある点も特徴です。

こうして運用した結果、4PBを超える容量に達したオブジェクトストレージ。実際の利用状況を見ながら、使用量を上回るHDD容量を維持し続け、その中で退役や廃棄を行ってきていたそうです。

リアルタイムで計測してきたというストレージ容量。実際の使用量である赤線が総容量の青線に達しないように運用を続けており、退役で一時的に容量が減っても右肩上がりに容量が上がっています。

BaytにおけるS3 REST APIの実装例

前述の通り、BaytはS3のREST APIを一部導入したオブジェクトストレージです。S3のAPI Referenceに従って実装したREST APIを備えていますが、すべてのAPIやオプションではなく、頻繁に利用されるAPIに限定していて、オプションも必要最低限に絞っています。基本的にはS3と同じようにBaytを利用できるという形になっています。

実際の実装では、MogileFSをバックエンドとして、BaytはRuby on Railsで実装、フロントにREST APIが提供されているという構成です。GetObjectを例にすると、まずはBaytのAPIにリクエストが送信されたのちに、APIがデータベースを参照してオブジェクトのコンテンツタイプやファイルサイズなどのメタデータを取得します。

このデータベースはMogileFSとは別に用意してあり、同時にMogileFSに対してオブジェクトの格納先の問い合わせが行われます。その格納先が抽出されると、そのパスが返ってきたらリバースプロキシが実際のオブジェクトを取得してレスポンスとして返す、という流れになります。

BaytはS3へ、30days Albumもハイブリッドに

実はBaytは、今後S3へ移設することを予定しています。コストを重視したBaytを採用してきましたが、2015年以来サービスが成長を続けており、予算をさらにかけてより機能面を重視しようという方向になってきたといいます。すでにグーペではS3への移管が完了しているとのこと。しかし、30days Albumに関しては同様の運用を継続する方針です。

とはいえ、まだ課題があると三上は話します。1つ目が運用の属人化で、これまで説明してきたハードウェアのライフサイクルの運用やMogileFSに関しても、詳しい人間が限られていて、その人間に運用が集中しているそうです。

対策としては、SREとして運用のtoil削減や自動化による運用負担の軽減を模索。ドキュメントを充実させるほか、オンコールトレーニングによる障害対応力の向上を図ります。こうした話は、同じYAPCにおけるGMOペパボ技術者の講演（https://developers.gmo.jp/31489/）でも話していた内容です。

また、2008年からという長いサービスであるがゆえに、30days Albumのサービス全体がレガシー化しているというのも課題です。30days Albumは、ストレージ以外の部分もオンプレミス中心の設計になっており、ストレージ以外のハードウェアも管理しなければならないため、これをクラウドとのハイブリッドにすることでハードウェアの運用負荷の軽減を図りたい考えです。

最後にYAPC::Kyoto 2023の写真を30days Albumへぜひ投稿してくださいという挨拶で締めくくられました。アルバムは実際に https://30d.jp/yapcjapan/5 で公開されているのでぜひご覧ください。