インフラ ストレージ Bayt 30days Album

4ペタバイトの巨大ストレージを支える運用について紹介します

インフラ ストレージ Bayt 30days Album

こんにちは。 技術部プラットフォームグループの@rsym1290です。 先月、「S3のAPIと互換性を持ったオブジェクトストレージの運用についてお話します」という記事を公開し、多くの反響をいただきました。 当記事をご覧いただきありがとうございます。

弊社が持つオブジェクトストレージを構成するハードディスクの容量を合計すると4ペタバイト弱で、年内には4ペタバイトを超える見込みです。 今回はこの超巨大なストレージの運用について、特にストレージサーバの視点で紹介したいと思います。

オブジェクトストレージの全体像とストレージサーバの構成

オブジェクトストレージの全体像

オブジェクトストレージを構成するためには、オブジェクトの格納先となるサーバだけでなく、リバースプロキシ/API/データベースなどを提供するサーバもそれぞれ必要になります。 前回の記事でも簡単に触れましたが、改めて記載します。

  • リバースプロキシサーバ:クライアントからの各リクエストをAPIサーバへ振り分けるサーバ
  • APIサーバ:S3互換のAPIを提供するアプリケーションとMogileFSが動いているサーバ
  • DBサーバ:オブジェクトのメタデータやオブジェクトの格納先に関する情報を保有するデータベースサーバ
  • ストレージサーバ:オブジェクトの実際の格納先となるサーバ

今回の記事では、ストレージサーバを中心に記載します。

オブジェクトストレージの全体像

オブジェクトの冗長性の確保

ストレージサーバは大量のハードディスクを保有しているため、ハードディスクの故障とは切っても切り離せない縁にあります。 近年採用しているハードディスクは故障する頻度は減りつつありますが、どうしても一定の件数は発生します。 このとき、オブジェクトの冗長性を確保していないと、故障したハードディスク上のオブジェクトはデータロストとなってしまいます。

オブジェクトの冗長性は下図のようにして確保しています。 一言でいうと「1つのオブジェクトを2台以上のストレージサーバに保管して冗長性を確保」しています。 複数のストレージサーバに保管することでサービスの可用性を向上させています。 冗長性が確保されている範囲であれば、ストレージサーバ本体で障害があってもサービスの運用を継続することが可能です。また、ストレージサーバ単位でのオンラインメンテも可能になります。

オブジェクトの保存先はMogileFSによって決められます。 MogileFSが各ストレージサーバが保有するハードディスクの使用率を確認し、使用率の低いハードディスクとそれを保有しているストレージサーバが、オブジェクトの配置先として指定されます。

オブジェクトの冗長性確保

以上のようにオブジェクトの冗長性を確保しているため、冗長化されたオブジェクトも格納できるだけのストレージの容量が求められます。 単純にすべてのオブジェクトを2冗長で確保する場合は、オブジェクトの総容量の2倍のストレージが必要ということになります。

ストレージサーバの台数と構成

2021年4月現在の各ストレージサーバの構成は以下のとおりです。 なお、採用しているサーバの具体的なモデルは割愛します。

全部で10台ありますが、後述する運用によって1年を通して1〜2台程度の増減があります。 前回の記事の通り、2008年に30days Albumというサービスが開始されてから、このオブジェクトストレージの運用を継続しています。 ストレージの利用状況に応じてストレージを増設しており、その都度採用するストレージサーバの選定をしています。 そのため、様々な構成のストレージサーバが混在しています。

  • 1U1サーバと4U45Bay2エンクロージャをSASケーブルで接続した構成:3台3
  • 1Uサーバと4U44BayエンクロージャをSASケーブルで接続した構成:1台3
  • 4U36Bayのストレージサーバ:5台
  • 4U40Bayのストレージサーバ:1台

各ストレージサーバではRAIDは一切組んでおらず、各ハードディスクをそのままストレージサーバにマウントするだけの構成にしています。 すべてのハードディスクの容量を最大限に活用して、大容量のオブジェクトストレージを実現するためです。 また、先述の通り1つオブジェクトを複数のストレージサーバに配置して冗長性を確保しているため、RAIDを組まなくともハードディスク故障時のオブジェクトのロストを防いでいます。

保有するデバイスの総量とハードディスクの内訳

ストレージサーバに搭載しているハードディスクの内訳は以下のとおりです。 2021年4月現在、375本のハードディスクで構成されています。 先述の通り長年に渡ってオブジェクトストレージを運用してきたこともあり、小さいもので6TB、大きいもので14TBと様々な容量のハードディスクで構成されています。 ちなみに、2021年内もストレージの増設を予定しており、その際には18TBのハードディスクを採用する予定です。

  • 6TB x 51本
  • 8TB x 1本
  • 10TB x 105本
  • 12TB x 93本
  • 14TB x 125本

採用するハードディスクは単体の信頼性や性能よりも、低コストと大容量を目的として3.5inch SATAを利用しています。 多数のハードディスクを運用している場合、例えば1本あたりの年間の故障率が1%であっても、375本あると毎年3~4本故障することになります。 故障したハードディスクは利用できないため、後述する方法でサービスから切り離しています。

ストレージの運用

運用にあたって常に発生する課題

30days Albumへの継続的な画像・動画のアップロード、カラーミーショップやグーペを始めとしたBaytを利用しているサービスの利用者増加に伴い、オブジェクトストレージが保有するオブジェクトの総量は日々増加しています。 そのため、ストレージサーバに対する継続的な増設が不可欠です。 では、定期的に新しいストレージサーバを導入していればそれで良いのか?そんなことはありません。

課題1:限られた物理的なリソースを有効に使う必要がある

例えばデータセンターにあるラックのスペースには限りがあります。 何も考えずにひたすら新しいサーバを導入しようとすると、ラックのスペースが無くなり新しいサーバを導入することができなくなります。 スペースが無くなったからと言って新しいラックを契約しようとすると、それだけで毎月数十万円コストが増加します。 目をつむることのできる金額ではありません。 このように、物理的なリソースが有限であることを考慮しないとコストも膨れ上がってしまいます。

課題2:サーバやハードディスクには寿命がある

サーバやハードディスクの寿命は無限ではありません。 長年運用を続けると、サーバやハードディスクは徐々に経年劣化しいずれ故障します。 つまり、いずれ故障することを視野に入れて運用する必要があります。

課題を踏まえて

2つの課題を踏まえ、「古いストレージサーバが故障する前に退役・廃棄してラックのスペースを確保し、新しいサーバを導入する」というサイクルを回す運用をとっています。

古いストレージサーバを退役させる

古いストレージサーバを廃棄する前に、そのストレージサーバをサービスから切り離して二度と使わない状態にする必要があります(以下、「退役」と呼ぶことにします)。 ですが、古いストレージサーバにも大量のオブジェクトが格納されているので、ただサーバをシャットダウンするだけだとそれらのオブジェクトの冗長性が失われてしまいます。 そのため、対象のオブジェクトを他のストレージサーバで冗長性を確保してから古いサーバを退役させます。

MogileFSでは各ハードディスクのステータスをalive/readonly/drain/down/deadという複数のステータスで管理しています。 通常の運用ではaliveを使い、メンテナンスなどで必要に応じてreadonly/drain/downを使います。 deadというステータスは「そのハードディスクを二度と利用しない」ときに使うもので、ハードディスクの退役や故障ディスクの切り離しで利用します。 対象のハードディスクをdeadにすると、MogileFSによって冗長性が失われたオブジェクトを精査し、自動でレプリケーションしてくれます。

上記の機能を利用して、ハードディスクを一つずつ退役させていき、ストレージサーバ上のすべてのハードディスクを退役させることで、初めてストレージサーバ本体の退役そして廃棄ができるようになります。 ちなみに、ハードディスク1本の退役にかかる時間は半日程度ですが、そのハードディスクの容量やオブジェクトの件数によって前後します。

ハードディスクのサービスからの切り離し

新しいサーバを導入する

続いて、新しいサーバの導入についてです。 どのような観点でストレージサーバを選定しているのか、必要なディスク容量をどのようにして見積もっているのか、それぞれ紹介します。

ストレージサーバ本体の選定

先述の通り、限られたラックのスペースを活用して運用していくことになります。 これを踏まえると、「効率的にハードディスクをたくさん収容できるサーバ」を選定する必要があります。 世の中には4Uで60Bay、さらには100Bayを超える恐ろしい収容力を持ったストレージサーバも存在します。 ですがこれらのサーバは採用していません。

収容力が高すぎると、以下のようなデメリットが発生してしまうためです。

  • 収容力を高めてストレージサーバの台数を減らすとオブジェクトの分散先が減ってしまい、トラフィックが集中してパフォーマンス低下につながる恐れがある
  • 1サーバあたりの収容本数が多すぎると、将来ストレージサーバを退役させるときに膨大な期間を費やすことになる
  • 収容力が高すぎるとサーバ本体のサイズ(特に奥行き)が大きくなり、電源ケーブルやLANケーブルの取り回しに支障が出る

そのため、収容力を重視しつつ上記のデメリットとバランスを取りながらサーバを選んでいます。 最近は4U36Bayを採用していますが、今後の動向次第で別の構成を採用するかもしれません。

ちなみにストレージサーバ自体は特別高いスペックは求められていないため、CPUはXeon Bronze系メモリは32GBと控えめのスペックにすることで、ストレージサーバ1台あたりのコストも節約しています。

必要なディスク容量の見積もり

続いて必要なディスク容量の見積もりです。 ストレージが保有するオブジェクトの量は日々増え続けております。 この増加傾向に注目して「最近半年間の傾向から、数カ月後にストレージの使用量はこれくらいになるだろう」と考えることはできます。 ですが、この視点だけでストレージを増設すると、運用が破綻してしまいます。 先述した古いストレージの退役によって、オブジェクトストレージ全体で保有するディスク容量が減ってしまうためです。

よって、必要なディスク容量を見積もるときは以下の2つの視点が必要になります。

  • 直近の増加傾向に基づいて今後の増加量を予測する
  • 今後ストレージサーバを退役させるによって減少するディスク容量を補う

下図は実際のストレージの総量と使用量を表しています。 赤矢印の傾向と青矢印の傾向をもとに、緑矢印のようにストレージサーバを増設しています。

ストレージの利用状況に基づく必要なディスク容量の見積もり

まとめ

今回はオブジェクトストレージの運用について、ハードウェアの視点で紹介しました。 サービスを立ち上げたり運用するとき「新しものを導入する」という視点は誰しもが持ちますが、それと同じくらい「古いものを棄てる」ことも視野に入れておくことが大事です。 オブジェクトストレージの運用においては、この視点が特に重要と言えます。

このブログを一読頂いた皆さんは「地道な活動」という感想を抱いたかもしれません。 事実、地道な運用を積み重ねてこの巨大なストレージを運用してきました。

本ブログで紹介したこと以外にも必要な運用があります。 詳しくは割愛しますが、日々のストレージの総使用量を採取してスプレッドシートで集計する運用、各サービスがどの程度オブジェクトストレージを利用しているのか統計を取る運用、各ストレージサーバのディスク使用率の偏りを緩和するために必要に応じてオブジェクトの格納先を移動させる運用などがあります。 これらを自動化して運用負担を軽減するなどの取り組みも実施しています。

今後もオブジェクトストレージの運用を通じて、30days Album、カラーミーショップ、グーペなどのペパボの様々なサービスを支えて行きたいと思います。

  1. サーバの高さを表す単位としてU(Unit)が用いられます。1U=1.75inchです。 

  2. HDDを搭載できる差込口をBayといいます。45Bayの場合、HDDを搭載できる差込口を45口備えていることを表します。 

  3. 1Uサーバ1台+4Uエンクロージャ1台の1セットで1台とカウントしています  2