講演者略歴

Facundo Agriel氏は現在、Dropbox社のエクサバイト規模のブロブ・ストレージ・システムの技術リーダーを務めている。このチームは何ペタバイトもの容量を持つカスタマイズされたストレージマシンから他のチームが社内で使用するクライアントAPIまで、あらゆるものを管理している。Dropbox社の前にはAmazon社でアマゾンのラストマイル配送チームの様々なスケジューリング問題に取り組んでいた。

講演録

Agriel氏：私はFacundo Agrielで、Dropboxのソフトウェアエンジニアです。今回は、エクサバイト規模のブロブ・ストレージ・システムであるMagic Pocketについてお話します。

Dropboxのすべての顧客データはMagic Pocketに保存されています。また、社内での利用も数多くあります。その中核は、任意の大きさのブロブを取り扱う非常に大きなキーバリューストアです。その可用性は99.99%以上です。私たちは北米の3つの地域で運営しており、書き込みは4メガバイトのブロブに最適化されています。書き込みされたブロックは不変であり、コールドデータにも最適化しています。システム全体では、毎秒数千万以上のリクエストを管理しています。システムの裏で発生しているトラフィックの多くは、検証やバックグラウンド・マイグレーションのものです。現在、60万台以上のストレージ・ドライブが配備されており数千台のサーバーを利用しているのです。

OSD(Object Storange Device)

マジックポケットのもっとも重要なコンポーネントである、OSDと呼ばれるオブジェクト・ストレージ・デバイスについて話そう。これは私たちのデータセンターにある実際のOSDであり、ここにすべてのドライブが見える。通常、ストレージ・マシン1台あたり、OSD1台につき約100台のディスクを搭載しているのだ。私たちはSMR技術を利用しており、各ストレージ・デバイスの容量は2ペタバイト以上である。なぜSMR技術を使うのか、その理由を説明しよう。SMRとはShingled Magnetic Recordingの略である。ディスク全体にランダム書き込みが可能な垂直磁気記録（PMR）ドライブとは異なり、SMRは、ランダム書き込みの代わりにシーケンシャル書き込みを行うことで密度を向上させる。ご覧のように、SMRドライブが詰め込まれているため、ヘッドがトラックを移動すると次のトラックを消去する。この場合でも読み取りはできるが、好きな場所にランダムに書き込むことはできない。これは、先ほど話した作業負荷のパターンに基づくと、私たちのケースにぴったりである。これは、私たちにとって実にうまく機能している。SMRドライブには、トラックの外側に従来の領域もあり、必要に応じてランダム書き込みをキャッシュできる。この従来の領域は、通常ドライブ総容量の約1%未満である。

Magic Pocketの構造

Magic Pocketのアーキテクチャについて話そう。私たちのシステムは、大きく3つのゾーン、西海岸、中央ゾーン、そして東海岸で運営されている。それらはポケットという単位で分類される。ポケットとは、私たちのシステムを構成するすべてのものの論理的なバージョンを表す単位で、Magic Pocketのさまざまなインスタンスを持つことができる。例えばいくつかのバージョンはテスト用かもしれない。開発者用のデスクトップのようなもので、Magic Pocketのインスタンスを実行できるのだ。また、本番ゾーンの前にあるステージポケットもある。データベースやサーバーなどはポケット間で共有されることはない。

ゾーン

ポケットとは何かを大まかに理解したところで、次にさまざまな構成要素について説明しよう。まずゾーンについてである。ゾーン内には、フロントエンドサービスという最初のサービスがあり、これはクライアントが触れる最初の我々のサービスである。すべてのクライアントは、このフロントエンドサービスを通じて私たちとやりとりする。クライアントが通常行うリクエストのタイプは、キーとブロブを指定したPUTリクエスト、あるキーを指定したGETリクエストであり、削除を要求することもある。システムで利用可能なハッシュをスキャンするかもしれないし、特定のキーのメタデータを更新したいかもしれない。GETリクエストは、最初にハッシュ・インデックスを参照しなければならない。 ハッシュ・インデックスはシャーディングされたMySQLデータベースで、すべてがシャーディングされ基本的にブロブのキーになっている。我々は単にそのブロブのSHA256を取るだけだ。内部では、これらのブロックを、ファイルの一部、ファイルの断片、通常は4メガバイト以下のチャンクと呼んでいる。インデックスを見ると、ハッシュはセル（バケット）にマッピングされ、特定のハッシュのチェックサムもあり、セルとは別の分離単位である。ここが実際にすべてのストレージ・デバイスが存在する場所である。インデックス・テーブルは特定のセルとバケットを指し示すだけなので、セル内のどこに行くべきかを指示するもう一つのレベルだ。セルは非常に大きくなり、顧客データで100ペタバイトを超えることもある。しかし、セルを大きくするには限界がある。システム全体としては、容量が不足すれば、新しいセルをオープンすればいいだけである。そうやって私たちのシステムは、もちろんいくつかの制限はあるが、永遠に水平方向に拡張できるのだ。

ゾーンにある他のものについて話そう。ゾーンにあるもう一つのコンポーネントは、クロスゾーン・レプリケーターである。クロスゾーン・レプリケーターとは、マジックポケットの中でクロスゾーン・レプリケーションを、つまりデータを複数のリージョンに保存するものだ。これはバックグラウンドで非同期に行われる。コミットが発生し、データがどこにあるかわかると、自動的にクロスゾーン・レプリケーターにキューイングされ、他のゾーンに移動できる。また、コントロール・プレーンもあり、コントロール・プレーンは基本的にゾーン内のトラフィック調整を管理する。例えば、バックグラウンドでマイグレーションが発生した場合、ライブトラフィックを妨げないようにプランを生成する。また、特定のストレージマシンの再インストールを管理するためにも使用する。例えば、カーネルのアップグレードやオペレーティング・システムのアップグレードをしたい場合、コントロール・プレーンがそれを代行してくれる。また、セルの状態情報も管理する。セルには特定の属性があり、そこに含まれるハードウェアのタイプなどもあり、それがコントロール・プレーンの役割だ。

セル

ハッシュはセルとバケツにマッピングされるという話をしたので、それは何かについて説明しよう。セル内にはバケツがある。セル内に入ってBlobを取り出したい場合、最初にしなければならないことは、バケット・サービスと呼ばれるコンポーネントに問い合わせることだ。バケット・サービスはいくつかのことを知っている。バケットとボリュームである。フェッチするときはいつでも、まずバケットを見つける。そのバケットは実際にはボリュームにマッピングされており、ボリュームはOSDのセットにマッピングされている。ボリュームはオープンにもクローズにもできる。ボリュームには世代が関連付けられておりまた、ボリュームにはさまざまなタイプがある。ボリュームは複製された状態であったり、消去コード化された状態であったりする。バケットを要求すると、そのボリュームがどのOSDにブロブがあるかを教えてくれる。例えば、バケット1に行き、ボリューム10にマップとすると、ボリューム内でこのOSDが見つかる。このOSDに特定のブロブについて質問するだけで、ブロブを返してくれるのだ。これで基本的に、マジックポケットからブロブを取り出す方法は完了である。書き込みを行う場合は少し違うが、基本的には同じである。バケットがあらかじめ作成されているだけである。 フロントエンドサービスは、まずどのバケットが書き込み可能な状態になっているかを把握する必要がある。フロントエンド・サービスは、書き込み可能なオープン・バケットに書き込む。この場合、書き込み可能なオープン・ボリュームであれば、OSDのセットに書き込むことが可能だ。ボリューム内では、この4つのOSDにマッピングされ、そこに特定のボリュームのデータが保存される。

セル内の他のことについていくつか話そう。もうひとつ、非常に重要なコンポーネントがこのコーディネーターだ。コーディネーターはPUTやGETのリクエストの経路にはいない。実際にはバックグラウンドで動作する。コーディネーターの役割は、すべてのバケットとボリューム、そしてすべてのストレージマシンを管理することで、ストレージマシンへのヘルスチェックを常に行っている。ストレージマシンの情報を常に確認し、ストレージマシンからの情報とバケットデータベースのバケットサービスを照合する。他にも、消去コーディングやリペアもする。例えばこのストレージマシンが故障した場合に、データを別のストレージマシンに移すのはコーディネーターの役割である。コーディネーターはデータの最適化をセル内を移動させることで行うのだ。 また、オフラインにする必要があるマシンがある場合は、データを他のマシンに移動させることで、その処理もする。データの移動は、ボリューム・マネージャーというコンポーネントが行う。これは基本的に、データの移動、あるいはデータの移動が必要になったときの新しいボリュームの再作成などを担当するものだ。バックグラウンドのトラフィックについて少し触れたが、多くの検証ステップもセル内とセル外で行われるのでそれについても話す。

バケット、ボリューム、エクステント

バケットとボリュームについて、もう少し詳しく説明しよう。ここにはそれはバケット、ボリューム、エクステントの3つのコンポーネントの概念がある。バケットは論理的なストレージ単位と考えることができる。書き込みを行う場合、ボリュームに関連付けられたバケットに書き込むと説明したが、もう一つエクステントと呼ばれる別の概念がある。エクステントとは、ディスク上にある1〜2ギガバイトのデータのことだ。書き込みを行いたい場合、どのバケットが開いているかを調べる。仮にバケット1が見つかったとすると、それに関連するOSDのセットを取得しなければならない。そして書き込みを行うときは、単にエクステント自体に書き込みをする。バケット内のエクステント情報とボリューム情報は、すべて先ほどお話ししたコーディネータによって管理されている。もしデータが欠落していたりすれば、いつでも他のストレージマシンからデータを入手できるし、コーディネータは削除されたエクステントの新しい配置を見つける役割を果たす。バケットは論理的なストレージで、通常1～2ギガと考える。ボリュームは1つまたは複数のバケットで構成され、タイプによってはOSDのセットとなる。タイプは、レプリケートされているか、消去コード化されているか、またオープンかオープンでないかによって決まり、一度ボリュームを閉じると、二度とオープンされることはない。

#オブジェクトストレージデバイスでブロブを検索する方法

ストレージ・マシンで実際のブロブを見つける方法について説明しよう。ブロブがあり、ブロブをフェッチしたい。ボリュームは分かっていて、関連付けられている。これらのOSDにはブロブがあるはずだ。簡単に言うと、これらのOSDのアドレスを保存し、これらのOSDに直接話しかける。OSDは、ロード時にすべてのエクステント情報をロードし、ディスクオフセットにどのハッシュを持つかのメモリ内インデックスを作成する。たとえば、hogeブロブのハッシュがあれば、それはディスクオフセット19292にある。この場合、このボリュームはレプリケートタイプであり、実は消去コード化されていません。ここで紹介した4つのOSDすべてでフルコピーが利用可能である。これはブロックをフェッチするためのものである。PUTを行いたい場合は、同じタイプで、4xレプリケートされ、単純にすべてのOSD自体に書き込みをする。リクエストは並行して、すべてのストレージマシンで書き込みが完了するまで、私たちはアクションを返さない。

イレイジャーコーディング

レプリケートされたボリュームと消去コード化されたボリュームの違いと、その処理方法について説明する。4xレプリケーションでは、2つのゾーンにボリュームをレプリケートする。これはかなりコストがかかるので、全体としては8倍のレプリケーションになり、これは非常にコストがかかる。システムをより効率的にするために、レプリケーション係数を下げたい。そこで登場するのが消去コードだ。ボリュームがレプリケートされた状態でボリュームがほぼ一杯になると、そのボリュームはクローズされ、消去コードの対象となる。消去コードは、ストレートアップ・レプリケーションと同様の耐久性を持ちながら、レプリケーション・コストを削減するのに役立つのだ。この場合、消去コードをリード・ソロモン（6＋3）とする。6つのOSDがあり、ここに3つのパリティがあり、これをボリューム・グループと呼ぶ。データエクステントの1つに1つのブロブがある。このOSDの1つを失っても、残りのパリティと他のデータエクステントから再構築できるのだ。

ここで消去に関するコーディングについてもう少し詳しく説明しよう。この場合、先ほど述べたように、再構築のためのパリティで他のエクステントから読み取ることができる。ご想像の通り、この領域は実に興味深いものになるのだ。消去に関するコーディングには、オーバーヘッドをめぐるさまざまなトレードオフのもと、多くのバリエーションが存在するだろう。それについて簡単に説明する。消去コーディングは非常に単純なものになる。XORのようなものを使って、他のものから再構成することも可能であり、非常にカスタムな消去コードを使うこともできる。例えば、読み取り回数を減らしたければ、オーバーヘッドが大きくなるかもしれない。また、ボリューム・グループ内で複数の障害を許容したい場合は、オーバーヘッドが大きくなるため、レプリケーション係数も大きくなる可能性がある。これは、Huang氏らによるErasure Coding in Windows Azure Storageというマイクロソフトの非常に興味深い論文である。これは数年前に発表されたものだが、非常に興味深いものであり、Magic Pocketでも実際にしていることとよく似ている。

リード・ソロモン6、3、つまり6つのデータ・エクステントと3つのパリティの例については前に述べた。最小再構成コードと呼ばれるコードには、読み取りコストを最適化する概念がある。リードのエレメント6, 3では、失敗があった場合の読み取りコストは、ここにあるすべてのエクステントのフルセットになる。読み出しのペナルティはここで6になる。彼らは、あるタイプのデータ障害に対して、同じ読み取りコストで、より低いストレージ・オーバーヘッドを実現する等価なコードを考え出した。この例では、ストレージのオーバーヘッド、レプリケーションのファクターはおよそ1.33倍で、リード・ソロモンと同じレプリケーションのファクターは1.5倍になる。大した節約には見えないかもしれないが、非常に大規模な場合、これは最終的にかなりの節約になる。 もちろん、これは本番環境で良く発生するグループ内に1つの障害が発生した場合に最適化されている。もしあなたが十分に素早く修復できるのであれば、ボリューム・グループ内で複数の種類の障害を目にすることはほとんどないだろう。このようなタイプの障害は非常に稀であり、通常、それほど頻繁に起こるものではない。ここでトレードオフをしても構わない。リード・ソロモン・コードと同じでオーバーヘッドが1.33倍である。それは非常に興味深い論文であり、レプリケーション係数を下げ続けることもできる。ここでは、リード・ソロモン・コードをはるかに凌ぐ低オーバーヘッドでありながら、同様の再構成読み出しコストであることがわかる。通常、LRC12, 2, 2の場合、グループ内の3つの故障は許容できるが、4つの故障は許容できない。実際に再構成できるのはそのうちのいくつかだけであり、これは単純に不可能である。

さらに改善できるか？

これよりうまくできるだろうか？クロスゾーン・レプリケーションには2倍のオーバーヘッドがあることに注目してほしい。内部ゾーンのレプリケーション係数は非常に高く、理想的なものだが、それでもマルチリージョンレプリケーションをしている。他に何ができるだろうか？しばらく前、私たちのシステムにあるデータのタイプについて、チームは実に良い観察をした。それは、過去1年間にアップロードされたデータの90％が検索されているというものであった。グラフをご覧いただくと、最初の100日間に80％のデータが検索されていることがわかり、これは非常に興味深いことです。つまり、基本的にあまりアクセスされていない、冷たいデータがたくさんあるということだ。このワークロードを最適化したい。リードの少ないワークロードがある。他のMagic Pocketと同じようなレイテンシーが欲しい。つまり、コールドストレージにライブで書き込む必要はない。それは後で起こるかもしれない。同じような耐久性と可用性の保証を保ちつつ、レプリケーション係数を2倍からさらに下げたい。ここでできるもう一つのことは、複数のリージョンを利用することだ。

コールド・ストレージ・システム

これから、私たちのコールド・ストレージ・システムについて、そしてそれが非常に高いレベルでどのように機能するかについて話す。インスピレーションは、Facebookのウォーム・ブロブ・ストレージ・システムから得たものだ。数年前に書かれた論文に、非常に興味深いアイデアがありそのアイデアとは次のようなものだ。あるブロブがあって、それを半分に分けたとしよう。前半をblob1、後半をblob2として、3つ目のパーツはblob1とblob2のXORになる。これをフラグメントと呼ぶ。これらのフラグメントは、blob1、blob2、blob1 XOR blob2というように、それぞれ別のゾーンに格納される。完全なブロブを得るには、blob1とblob2、blob1とXOR blob2、blob1とXOR blob2の組み合わせが必要だ。フェッチを行うには、2つの領域のいずれかが利用可能である必要がある。書き込みをしたい場合は、すべてのリージョンが完全に利用可能でなければならない。マイグレーションはバックグラウンドで行われるので、ライブで行うわけではない。

コールド・ストレージの勝利

コールド・ストレージの利点について話そう。2xのレプリケーションから1.5xレプリケーションになり、これは非常に大きな節約である。2倍のレプリケーションから約25％の節約になる。もうひとつの利点は、フラグメント自体が内部的に消去コード化されていることであり、マイグレーションはバックグラウンドで行われる。複数のゾーンからフェッチすると、バックボーンの帯域幅に多くのオーバーヘッドが発生する。私たちが行っているのは、リクエストをヘッジして、リクエストが発信元のサービスからもっとも近い2つのゾーンにリクエストを送ることだ。そして、2つのゾーンから応答がない場合、あるいは数100ミリ秒の間に応答がない場合は、残りのゾーンからフェッチする。

リリースサイクル

Magic Pocketの運用に関する議論に移ろう。最初に話したいのは、リリースの方法である。私たちのリリースサイクルは、すべてのゾーンでエンドツーエンドで約4週間だ。私たちはまず、変更をコミットする前に一連の単体テストや統合テストから始める。単体テストと統合テストは通常、Magic Pocketのフルバージョンをすべての依存関係とともに実行する。これは完全にデベロッパーボックスで実行可能だ。また、耐久性ステージもある。耐久性テスターは、すべてのデータの完全な検証を伴う一連の、より長いテストスイートを実行するのだ。大量の書き込みを行い、データがすべて完全にカバーされていることを確認する。1ステージあたり約1週間かかるが、これはそれぞれのゾーンで検証をするためである。通常、メタデータのチェックのための検証はすべて1週間以内にできる。リリースサイクルは基本的にエンド・ツー・エンドで自動化されており、コード変更をプッシュする際に行うチェックがある。アラートなどがあれば、自動的に中止されたり、先に進まなかったりするのだ。ただ、例外的なケースでは、私たちがコントロールする必要がある。

検証

検証に入ろう。私たちのシステムには色々な検証がある。まず、クロスゾーン検証と呼ばれるものだ。この背後にある考え方は、私たちの上流にはデータ、つまりファイルについて知っているクライアントがあり、それが私たちのシステム内の特定のハッシュにどのようにマッピングされるかを知っていることである。クロスゾーン検証は基本的に、これら2つのシステムが常に同期していることを確認する。次に、インデックス検証がある。インデックス検証はインデックス・テーブルをスキャンして、すべてのストレージマシンに、この特定のブロブについて知っているかどうかを尋ねるのだ。実際にディスクからブロブをフェッチするのではなく、単に、最近エクステントからロードした内容に基づいて保存したものがあるかどうか確認するのだ。次にウォッチャーだ。ウォッチャーは、実際のブロブそのものを完全に検証する。ここではサンプリングをしていて、すべてのデータに対してこれを行うわけではない。1分後、1時間後、1日後、1週間後に検証する。次に、Trash inspectorと呼ばれるコンポーネントがある。これは、エクステントが削除されると、エクステント内のすべてのハッシュが実際に削除されたことを確認するものだ。これは最後の確認作業でありさらに、エクステント自体にあるチェックサムをチェックするために、エクステント情報を精査またはスキャンするのである。

オペレーション

より多くのオペレーションについて説明しよう。私たちは多くの移行を扱っている。複数のデータセンターで運用しているため、常に異なるデータセンターからの移行がある。私たちが管理するストレージ・マシンは非常に大規模であり、常に何が起きているのかを把握しておかなければならない。自動化されたカオスがたくさん起こっているので、システムの信頼性をテストするために大量のディザスタリカバリイベントが発生している。この規模でMagic Pocketをアップグレードするのは、システムのアップグレードをするくらい難しい。バックグラウンドのトラフィックを管理する業務もある。バックグラウンドトラフィックはトラフィックとディスクIOPSのほとんどを占めている。例えば、ディスクスクラバーが常にすべてのディスクをスキャンし、エクステントのチェックサムをチェックしているとする。私たちはいくつかのことを行い、サービスごとのトラフィックを異なるトラフィック層に分類できるようにしている。ライブトラフィックはネットワークによって優先される。バックグラウンドのトラフィックは落としても構わない。制御プレーンの話もしたが、データセンターの移行に関する予測に基づいて、多くのバックグラウンド・トラフィックの計画を生成する。マイグレーションの種類は、コールド・ストレージなどである。

故障について、いくつか興味深いメモがある。毎秒4個のエクステントが修復されており、エクステントのサイズは1ギガから2ギガだ。修理に関するSLAはかなり厳しく、48時間以内となっている。これを超えても問題ないが、通常、48時間は耐久性モデルに組み込まれているため、可能な限り低く抑えたいと考えている。OSDはセルのサイズと現在の利用率に基づいて自動的にシステムに割り当てられる。データセンター内に空きプールがあれば、そこで運用される。ある種のSSDが同時に満杯になるなど、現在進行中の単一障害点（single point of failures）との戦いにまつわる話はたくさんあり、そういったことをすべて管理しなければならない。

移行についてについて、もう一つ書いておく。2年前、我々はSJCリージョンから移行した。このようなことが起こるまでには、舞台裏でたくさんの計画があった。SJCからの移行計画のグラフをお見せしよう。これは、SJCから移行しなければならなかったデータ量であり、薄い赤い線がトレンドラインである。青い線は私たちが想定していたものだ。移行を開始した当初は、本当にひどい状況だった。それから時間が経つにつれて、かなり改善された。その後、本当に長いテールエンドのようなものができて、どう対処すればいいのかわからなくなった。数百ペタバイトという非常に大規模なマイグレーションでは、舞台裏で多くの計画が進行する。時間内に終わらせるためには、余分な時間を確保しなければならない。

予測

予測もまた、この規模のストレージシステムを管理する上で非常に重要な部分である。ストレージは常に成長している。時には、予想外の成長を考慮し、システムに吸収する必要があるのだ。例えば、COVIDのようなサプライチェーンの混乱による性能不足の問題が発生することもある。追加の機材を発注し、データセンターに納品するまでには非常に時間がかかるため、即座にというわけにはいかない。問題が発生するとわかったらすぐにバックアップ・プランを用意する必要があるのだ。最終的には、キャパシティ・チームからの情報に基づいて、移行を実行するための予測をコントロール・プレーンに直接反映させるように努めている。

結論

結論として、Magic Pocketを管理するのに役立ったいくつかの注意点は、システムを保護し、検証することだ。常にシステムを検証すること。これには非常に大きなオーバーヘッドがある。このエンド・ツー・エンドの検証を行う価値はある。システムが常に矛盾がないか自分自身を検証していることを知ることは、エンジニアにとって信じられないほどの力になる。この規模では、実際に非常に多く、ゆっくり動くことが好ましい。耐久性は、私たちがシステム内でもっとも重要視していることの1つだ。だから、ゆっくりと、着実に、OK、何かをデプロイする前に検証が行われるのを待つのだ。もうひとつの考え方として非常に重要なのはリスクと何が起こりうるかを常に考えることで、私たちが念頭に置かなければならないことだ。物事をシンプルに保つこと、これがとても重要だ。私たちは非常に大規模なマイグレーションを行っているため、最適化が多すぎると、念頭に置かなければならないことが多くなりすぎて、前もって計画を立てたり、問題をデバッグすることが難しくなるのだ。私たちは常に最悪の事態に備えるようにしている。特にマイグレーションや、システム内で単一障害点が発生した場合、あるいは変更をデプロイする際には、物事が一方通行にならないように、常にバックアップ計画を立てている。

質問と回答

Dropboxは自社でデータセンターを維持しているのか、それともAWSのようなハイパースケーラーと提携してコロケーションしているのか？

実際には両方を少しずつ行っている。北米地域では、実際にデータセンターをリースしており、それ以外の地域では、例えばS3やAWSをコンピュートにも利用している。色々ですね。

Anand氏： S3を活用するのですか？

Agriel氏：はい。例えば、ヨーロッパの一部の地域では、様々なコンプライアンス上の理由から、データをローカルに存在させたいと考えるお客様がいます。そのような場合、私たちはS3を活用しています。

Anand氏： では、保存する前に実際のデータに対して何らかの圧縮をしているのでしょうか？

Agriel氏：保存前にデータを圧縮することはありません。データが実際にアップロードされ、私たちのサーバーに入った時点で、圧縮と暗号化を行います。データは暗号化され、圧縮された状態で保存されます。これには明らかにトレードオフがある。デスクトップからモバイルまで、さまざまなタイプのクライアントがあります。それを行うには、ユーザーにとってかなりのコストがかかる可能性があるのです。

Anand氏： SMRディスクについてお聞きしたいのですが、他のオプションと比べてコストはどうですか？

Agriel氏：私たちは、基本的に常に最新のハードディスク・ドライブ技術を採用するために、さまざまなハードウェア・ベンダーと密接に協力しています。数年前、おそらく5、6年前から、私たちはSMR技術を大いに活用するようになりました。私はトレードオフについて話しました。PMR、つまり従来のドライブと比較すると、SMRは密度を考えるとかなり安価です。1ギガバイトあたりのコストについて正確にお話しできませんが、かなり安くなっています。SMR技術を採用することで、コストを大幅に削減できます。実際に、SMRとPMRの読み取り速度とIOPS性能に関する情報をいくつか公表しました。結局のところ、私たちはシーケンシャルな読み書きをしているため、それほど大きな違いはありませんでした。SMRではレイテンシに若干の違いがありますが、私たちのワークロードを考えると、実際にはPMRとほぼ同等です。繰り返しになりますが、私たちはランダムな書き込みなどをしないので、非常にうまく機能しています。

SMR以外のディスクタイプも将来的に検討する可能性はあるか？

繰り返しになるが、業界は将来的にさまざまな技術に移行するし、SMRは今後数年で容量の限界に達する。SMRを搭載した最新のドライブは今年発売される予定だが、1ドライブあたり約26テラバイトと巨大だ。さまざまなベンダーが3年後、4年後、5年後を見据えているのは明らかだが、レーザー・アシスト技術が次の大きなものになりそうである。例えば、HAMR技術などに注目してほしい。これらのドライブは、今後数年以内に40テラバイトまで密度を高めると予想されている。新しいドライブ技術としては、それが次の大きなものになりそうだ。

Anand氏：ストレージを階層化したり、最近アクセスされたストレージを少なくしたり、裏側でそうしているのですか？

Agriel氏：階層型ストレージは導入していません。以前は、SSDドライブをOSDデバイスごとの書き込み用キャッシュとして利用していました。その結果、書き込みのボトルネックになるという問題が発生しました。私たちは最近これを廃止することで、問題を解消して、全フリートで大幅に書き込みスループットを向上させることができました。もうひとつは、コールド・ストレージ層を利用した、より不活性な書き込みです。これはまだSMRドライブ上にあり、SMRによってバックアップされています。それから、たとえば、SSDをもっと多用することなども検討しました。実際に活用できるかもしれません。ただ、この規模でキャッシングをうまくやるのは、さまざまな理由から、実際には信じられないほど難しい。プロダクション、検証、不整合など、あらゆることがいったん動き出すと本当に大変なのです。これが制限要因のひとつです。コールドストレージ層については、既存のインフラの上に構築したので、その上に構築するのは非常に簡単でした。

Anand氏：ここ数年、システムの進化を見てきましたね。今後、構築してほしいもの、あるいはシステムに組み込んだり設計したりしたいものはありますか？

Agriel氏：私たちにとっては、常にいくつかの異なるものがあると思います。私たちが考えている安定した現状とは、継続的な成長のためにシステムを拡張し続けることです。私たちは年間2桁の成長を続けています。これは通常、3、4年後にはシステム全体のキャパシティを2倍にしなければならないことを意味するのです。それは、私たちのシステムに多くの影響があります。継続的にスケーリングできると思っていたものの、実際にはさまざまな種類の垂直スケーリングの限界に直面するのです。これは来年に向けて積極的に検討しており、もうひとつは、メタデータの柔軟性を高めることです。私たちはMySQLを裏側で使用し、MySQLをシャーディングしていますが、MySQLをこの規模で管理するにはそれなりの問題があります。新しいカラムを簡単に追加したい場合なども、非常に面倒です。さらに規模を拡大しようとすれば、完全に分割しなければなりません。それにはコストがかかるのでほとんどの場合、メタデータ・スタックは来年変わるでしょう。私たちはそれを見据えています。また、最後の1つはハードウェアの進歩で、例えばHAMRが登場すれば、それをサポートできます。

Anand氏： 深夜に起こされたり、ひどい不具合であったり、即対応しなくてはならなかったりして、短期的な解決策や長期的な解決策を考え出さなければならなかったなど、思い当たるエピソードはありますか？

Agriel氏：メモリーの破損については、長年にわたって対処しなければならなかった興味深い話がたくさんあります。システム内で適切な保護がされていない部分が見つかったりとかね。例えば、メモリー破壊は常に起こっていることですが、裏側で検証や保護が行われているため、私たちはそれに気づかないのです。システムは優雅に故障する。たまに、夜中に私たちの知らない新たな破損で起こされることがあるのです。そのうちのひとつが最近起きました。データは多くのリージョンで複製されているから大丈夫です。たとえデータが破損しても、私たちがゴミ箱と呼んでいるところにデータは生き続けています。これはもうひとつの保護メカニズムで、データは削除されますが、自己削除が必要なので、まだ復元可能です。数週間前、それに起因するメンバー総出で対応しなければならない事態に見舞われ、どこに問題があるのかを突き止めるのに夜遅くまでかかりました。もちろん、すべてのログを記録しているわけではないので、どこから問題が発生したのかを突き止めるのは非常に難しいです。今は1つか2つの場所を突き止めたと思います。

Anand氏： ソフト削除は本当の削除ではないので、ゴミ箱がいっぱいになるのが早かったです。

Agriel氏：ゴミ箱には常に7日間データを保管しており、それが問題の一部です。メモリの破損です。たった1つのハッシュ、たった1つのデータが破損しているのを発見しました。そのようなものを追跡するのは非常に難しいということを申し上げたかったのです。たとえ様々な場所で様々なチェックを行っていたとしてもです。

講演録をもっと見る