自社保有のデータセンター、HDDを100本搭載するサーバー、高速なファイル同期の秘密、AI時代の400Gbネットワーク……
【保存版】ファイル1兆個＝470万テラバイト！ 巨大クラウド・Dropboxのインフラを支える最新技術
提供: Dropbox
データセンターネットワーク：400Gb採用による増強計画を進行中
――データセンターのネットワークについても教えてください。ブロックストレージサーバーは100Gb接続とのことですが、データセンター全体が100Gbネットワークで構成されているのですか。
岡崎氏：従来は、100Gbを束ねたデータセンターバックボーン（100Gb×32＝3.2Tb）でしたが、現在は400Gb技術への移行を進めています。次の第7世代サーバーは200Gbになり、AI処理も増えることで、ネットワークの容量が足りなくなるという判断からです。
具体的なネットワーク構成としては、耐障害性を持たせるために16台×2組の400Gbスイッチでネットワークファブリックを構成し、このバックボーンにラック内のスイッチ（ToRスイッチ）を接続する形です。バックボーンは12.8Tb（400Gb×32）の容量となります。
その先の、データセンターからPOPにつながるダークファイバも、6.4Tb×2本で12.8Tbという容量ですね。
――サラッとおっしゃってますが、ネットワークもとんでもない容量なんですね……。
400Gbデータセンターネットワークの全体像（左）と、400Gbスイッチで構成されるネットワークファブリック
ケーブルが美しく整理されたネットワークラック
ソフトウェア：ファイルを細かなブロックに分割するメリットとは？
――コア部分のソフトウェアについても教えてください。全体で1兆個以上のファイルが保存されていて、よく障害も起こさずに管理できるな、と……。ファイル1つ1つのアクセス権限も違うわけですし。
岡崎氏：ちょっと複雑になりますが、基本的な部分を説明してみますね。
先ほど触れたとおり、アップロードされたファイルはまず、4MB単位でデータブロックに分割されます。そして各ブロックのハッシュキー（ユニークなID）を計算し、これをインデックスデータベースに記録したうえで、ブロックそのものはブロックストレージに保存します（下の画像を参照）。
ファイルを構成する各ブロックの保存先（サーバー）がバラバラでも、ハッシュキーはひとまとめに記録していますから、この記録さえあればストレージからブロックを取り出して、元のファイルを再構成できます。
ファイルを4MB単位で分割し、個々のデータブロックのハッシュキーを計算する
――ふむふむ、なるほど。
岡崎氏：それとは別に、ユーザーが作成したフォルダには「ネームスペース」というIDが割り当てられています。ネームスペースIDには「フォルダ名」や「メンバー（アクセス権のあるユーザー）」をひも付けて記録しています。
そして、それぞれのファイルについての「所属するネームスペースID」「ファイル名」「構成するデータブロックのハッシュキー」といった情報が、まとめてデータベースに記録されます。これにより、ファイルそのものだけでなく、ファイルとフォルダの関係、ファイルへのアクセス権限なども正しく扱えるわけです。
フォルダ（ネームスペース）情報を記録するデータベース（上）と、ファイル情報を記録するデータベース（下）。ネームスペースIDで照合することで、ファイルへのアクセス権限が分かる
――うーん、大まかには理解できましたが、なかなか複雑ですね……。ところで、わざわざファイルを小さなデータブロックに分割して保存するメリットは何ですか。むしろ面倒じゃありませんか？
岡崎氏：サイズが小さければ分散／冗長保存や暗号化の処理がしやすいこともありますが、具体的な機能に関わるものとしては「ファイルのバージョン管理」や「更新ファイルの同期」にメリットをもたらします。
Dropboxには「Rewind（巻き戻し）」機能があり、一定期間内であれば、更新したファイルを古いバージョンに巻き戻すことができます。一般には「バージョン管理機能」と呼ばれるものです。
――はいはい、ときどき使ってます。うっかり上書き保存してしまった場合でも、元どおりに戻せて便利ですね。
岡崎氏：ですね。ただ、これを実現するためには、Dropboxが最新バージョンだけでなく“過去のバージョン”も保存しておかなければなりませんよね。更新されるたびにファイルを丸ごと新規保存していたら、ストレージの消費量はあっという間に2倍、3倍……とふくれ上がってしまいます。動画や3Dデータなど、数百MB、数GBといったファイルを扱う機会も増えていますから、これは大問題です。
ここで、ファイルを小さなデータブロックに分割するメリットが生まれます。ファイルが更新されたら、データの変化があったブロック（差分ブロック）だけを新規保存し、ほかの（変化のない）ブロックと組み合わせた構成を“新しいバージョン”として記録するのです。このとき、変更前の古いブロックや、古いバージョンの構成の記録も残しておけば、必要に応じてバージョンの巻き戻しができます。
変更のあったブロックだけを新規保存（ブロック5）し、データベース上で構成ブロックを書き換えて“新しいバージョンのファイル”とする
――つまり、過去のバージョンのファイルを残しても、それほどストレージを消費せずに済むと。
岡崎氏：そうなんです。そのメリットを生かして、Dropbox Rewindでは復元できる対象のファイルを、「○バージョン前まで（○世代前まで）」ではなく「○日前まで」と定めています。これは、ほかのクラウドストレージサービスとの大きな違いです。
――なるほど……。あっ、「更新ファイルの同期」にメリットがあるというのも、同じ理屈ですね。PCで更新されたファイルを丸ごと送信しなくても、変更のあったブロックだけを送ればいいから……。
岡崎氏：そう、通信容量が大幅に減らせるわけですね。ユーザー側では同期が素早く終わって快適ですし、Dropbox側でもネットワーク負荷が抑えられます。これを実現するために、Dropboxのデスクトップアプリ側にも、データブロックへの分割や、ブロックごとのハッシュキー計算といった処理が組み込まれています。
この記事の編集者は以下の記事もオススメしています
過去記事アーカイブ
- 2013年
- 11月