著者: Arpit Agarwal
本ブログ記事は「Introducing Apache Hadoop Ozone: An Object Store for Apache Hadoop」(2018/10/15投稿)の日本語翻訳記事です。また、原文の投稿はClouderaとHortonworks合併前に記述されたものであり、いくつかのリンク、リソースにはアクセスできない場合があります。
*訳注: 元記事公開時点では 0.2.1-alpha 版が最新でしたが、日本語翻訳時点(2020/3/31)では0.5.0-beta版が公開されています。
1. はじめに
Apache Hadoop Ozoneは、小さなファイルと大きなファイルの両方を同じように効率良く管理できる分散キーバリューストアです。Ozoneは既存のApache Hadoopエコシステムと共に良好に動作するように設計されており、操作の使いやすさを考慮して設計された新しいオープンソースのオブジェクトストアの要求を満たし、単一クラスターで数千ノード、数十億オブジェクトにスケールします。
前の記事、Apache Hadoop Ozone: Apache Hadoop 用のオブジェクトストアの紹介とApache Hadoop Ozone: オブジェクトストアの概要では、Ozoneの設計哲学と主な概要について紹介しました。この開発者向けの記事ではシステムのアーキテクチャーについて詳しく説明します。Ozoneのブロックの構成について検討し、それらを組み合わせてスケーラブルな分散ストレージシステムを構築できるかどうかを確認します。
2. スケーラビリティの問題を理解する
数十億のファイルのためにOzoneをスケールするには、HDFSに存在する2つのボトルネックを解決する必要がありました。
2.1 名前空間のスケーラビリティ
名前空間全体を単一ノードのメモリに保存しないようになりました。重要な洞察は、名前空間にはリファレンスのローカリティ（局所性）があるので、メモリにはワーキングセットだけを保存できる(*1)ということです。名前空間は Ozone Manager と言うサービスによって管理されます。
*1(訳注)：通常、名前空間にあるすべてのファイルにアクセスするわけではないため、利用しているファイルのリファレンス情報だけをメモリに格納しておけばいいということ
2.2 ブロックマップのスケーラビリティ
これは解決するのが難しい問題です。名前空間とは異なり、ストレージノード (DataNode) はシステムの各ブロックについてのブロックレポートを定期的に送るため、ブロックマップにはリファレンスのローカリティがありません。Ozoneはこの問題を Hadoop Distributed DataStore (HDDS) と言う共有汎用ストレージ層に委任します。
3.ブロックの構築
Ozoneは以下の主要コンポーネントで構成されています。
- 既製のキーバリューストア(RocksDB)を使用して構成されたストレージコンテナ。
- Apache RatisによるRAFT合意プロトコル。RAFTは合意プロトコルです。思想はPaxosに似ていますが、理解と実装を容易にするために設計されています。Apache Ratisは、高スループットに最適化されたRAFTのオープンソースのJava実装です。
- ストレージコンテナマネージャー (SCM: Storage Container Manager)。複製されたコンテナのライフサイクルを管理するサービス。
- Hadoop 分散データストア (HDDS: Hadoop Distributed Data Store)。名前空間を提供しないブロック用の汎用分散ストレージ層。
- Ozone Manager (OM)。Ozone のキー/値の名前空間を実装する名前空間マネージャー。
4. それらを組み合わせる
このセクションでは、これらの構成要素を組み合わせて分散キーバリューストアを作成する方法を紹介します。
4.1 ストレージコンテナ
この組み合わせの最下層では、Ozoneはユーザーデータをストレージコンテナに保存します。コンテナとは、ブロック名とそのデータのキー/値ペアのコレクションです。キーはコンテナ内でローカルに一意なブロック名です。値はブロックのデータであり、0〜256MBまでと様々な値を取ります。ブロック名はグローバルで一意である必要はありません。
各コンテナは、いくつかのシンプルな操作をサポートします。
- PutBlock : <blockName, BlockData>のペアをアトミックにコンテナに書き込む
- ReadBlock : 特定のブロックのデータを読み込む
- DeleteBlock : コンテナからブロックを削除する
コンテナはRocksDBを用いてディスクに保存され、大きな値のためにいくつかの最適化が行われます。
4.2 RAFTレプリケーション
分散ファイルシステムは、個々のディスク/ノードの損失を許容する必要があるため、ネットワークを介してコンテナを複製する方法が必要です。これを実現するために、コンテナのいくつかの追加プロパティを導入しています。
- コンテナはレプリケーションの単位です。その最大サイズは5GBに制限されています（管理者は設定変更が可能です）。
- 各コンテナは、OpenまたはClosedの2つのいずれかの状態になります。 Openのコンテナは新しいキー/値の保存を受け付けられますが、一方 Closed なコンテナはイミュータブルです。
- 各コンテナは3つのレプリカを持ちます。
Openなコンテナの状態の変更(書き込み)はRAFTを使用して複製されます。RAFTとは、ノードのクォーラムが変化に応じて投票する、クォーラム（定足数）ベースのプロトコルです。ある特定の時点では、単一のノードがリーダーとして機能し、変更を提案します。したがって、すべてのコンテナの操作は、少なくともクォーラムのノード (2ノード) にリアルタイムで確実に複製されます。
コンテナのレプリカはDataNodeに保存されます。
4.2.1 コンテナのライフサイクル
コンテナはOpenの状態で開始します。クライアントはOpenのコンテナにブロックを書き込み、コミット操作でブロックのデータをファイナライズします。ブロックが書き込まれる2つのフェーズがあります。
ブロックデータの書き込み。これは、クライアントの速度とネットワーク/ディスクの帯域に応じて、任意の長い時間がかかる場合があります。ブロックがコミットされる前にクライアントが停止した場合、不完全なデータはSCMによって自動的にガベージコレクトされます。
ブロックのコミット。この操作により、ブロックがコンテナでアトミックに見えるようにします。
4.3 ストレージコンテナマネージャー (SCM)
ここまでで、ブロックをコンテナに保存し、ネットワークを介してコンテナを複製する方法がわかりました。次のステップは、クラスター内ですべてのコンテナが保存される場所を把握する中央サービスを構築することです。このサービスがSCMです。
SCMは、すべてのDataNodeから、それらのノードのコンテナのレプリカとその現在の情報についてのレポートを定期的に取得します。SCMは、新しいOpenなコンテナを保存するための3つのDataNodeのセットを選択し、RAFT複製リングを相互に形成するように指示できます。
また、SCMは、コンテナがいつフルになるのかを学習し、リーダーのレプリカにコンテナを「Close」するように指示します。SCMは、不足(under)または過剰(over)レプリケーションのclosedなコンテナを検出し、closedなコンテナごとに3つのレプリカが存在するようにします。
4.4 コンテナ + RAFT + SCM = HDDS!
上記3つの構成要素により、グローバルな名前空間のない、分散ブロックストレージ層であるHDDSを作成するためのすべての要素を持っています。
DataNodeは3つのグループに編成され、各グループはRAFT複製リングで形成されます。各リングは複数のopenコンテナを持つことができます。
SCMは各DataNodeから、各ノードのopenおよびclosedなコンテナのレプリカについての通知レポートを30秒毎に受け取ります。このレポートに基づいて、SCMは新しいコンテナの割り当て、openなコンテナのクローズ、ディスクやデータを損失したclosedなコンテナの再複製のような決定を行います。
SCMのクライアントは新しいブロックの割り当てを要求することができ、その後、割り当てられたコンテナにブロックのデータを書き込みます。同様に、クライアントはopen/closedなコンテナのブロックの読み出しと、ブロックの削除を行うことができます。重要なポイントは、HDDS自身は個々のコンテナの内容について気にしないということです。コンテナの内容は SCM を使用するアプリケーションによって完全に管理されます。
4.5 名前空間の追加 — Ozone Manager
HDDSが適切な場所にある場合、不足している唯一の要素はグローバルのキー/値 名前空間です。これはOzone Manager (OM)によって提供されます。OMは、キー名から対応するブロックのセットをマッピングするサービスです。
クライアントは複数のブロックをHDDSに書き込むことができ、その後それらのキー→ブロックのマッピングをアトミックにOMにコミットして、キーを名前空間で見えるようにします。
OMは、自身の状態をRocksDBデータベースに保存します。
5. Ozone以降のHDDS
別の分散ファイルシステム実装によって、HDDSはブロックストレージ層として使用できます。議論が行われ、将来的に実装されるかもしれないいくつかの例を紹介します。
- HDFS on HDDS (HDFS-10419) — 既存のブロックマネージャーを置き換えることにより、HDDSを使用してブロック空間のスケーラビリティの問題を綺麗に解決することができます。このアイデアは HDFS-5477 の提案に似ています。
- cBlocks (HDFS-11118) — HDDSストレージをバックエンドにした、マウント可能なiSCSIボリュームのプロトタイプ。
- 名前空間もHDDSコンテナに保存する、仮想オブジェクトストア。
そしてさらに… あなた自身による名前空間をお待ちしています。
追記
2020年3月19日現在、Cloudera Data Platform — Data Center (CDP-DC) 7.0.3にはOzone 0.4.0が技術評価版として含まれています。https://docs.cloudera.com/runtime/7.0.3/ozone-storing-data/topics/ozone-introduction.html
謝辞
翻訳レビューを行っていただいたCloudera Japanの有志に感謝します
