はじめに
本投稿では、先日入門したEdgeFSについて、その概要をまとめたので紹介します。以前概要をまとめたCephとは異なり、EdgeFSはまだ利用例も少なく、情報がそれほど多くない状況です。また公式ドキュメントには内部構成などの情報が欠けており、都度別の記事から情報を引っ張ってきています。記載内容に誤りがあったときは、ご連絡いただければ幸いです。
EdgeFSとは
※Rook公式ドキュメントより
EdgeFSはGeo-Transparentなデータアクセスを実現する、マルチクラウド時代の分散ストレージシステムとして紹介されます。Kubernetes上であればオンプレ・クラウドいずれの環境でも構築可能であり、EdgeFSノードがコンテナーとしてデプロイされ、分散オブジェクトストレージを提供します。またGeo-Transparentとは、データが常にオンラインであり、地理的に離れたサイト間で、利用者がいつでもアクセスできることを指しています。
EdgeFSでは一つのグローバルな名前空間を作成し、各サイトから接続することで、地理的な分散サイトに無制限に拡張することができます。EdgeFSはスタンダードなストレージプロトコル（NFS/S3/iSCSI）に対応しており、各ローカルサイト内では、ファイル・ブロック・オブジェクトストレージ全てで等しい拡張性を提供します。またリモートサイトにあるデータへの効率的なアクセスも実現し、ステートフルアプリケーション向けに高スループット・低レイテンシのデータアクセスを提供します。
EdgeFSはKubernetes・Rookとの統合を行い、機能拡張を進めています。Kubernetesの機能を利用することでフェイルオーバーへの動的対応などを実現します。またKubernetes上であればどこでもデプロイ可能であり、マルチクラウドへの対応も可能です。さらにKubernetes CSI、Rookと統合することで、クラスター管理の簡便化などをもたらします。
EdgeFSの特徴
EdgeFSの持つ特徴を記載します。
File, Block and Object：ファイル・ブロック・オブジェクトストレージのプロトコルを利用可能です。
Fast & easy deployment：AWS/GCP/Azureなどのパブリッククラウドから、オンプレミス・IoT/Edgeデバイスまで導入可能で、Kubernetes/Rook（あるいはDocker）が導入済みの環境であれば数分でデプロイが完了します。
Data protection：データを複製し、複数の場所に保存します。またデータの冗長化方式としてErasure Codeも提供します。加えてデータの自己修復機能とスナップショット機能により、耐障害性も備えます。
Data Reduction：地理的サイト間でのデータ重複排除と急速な圧縮を提供します。サイト間での通信を減らし、リモートサイトにあるデータへのアクセスを高速化します。
At rest encryption：サーバーサイドでのデータ暗号化を行います。全てのデータ・メタデータはimmutableであり、SHA-3 256/512-bitで暗号化されます。
Multi-Tenancy with QoS controls：地理的情報を考慮したマルチテナントに対応し、ファイル・LUN・オブジェクトの粒度でのQoS機能を備えます。
No SPoF：分散・immutableなメタデータ設計によりSPoF（Single Point of Failure）がありません。またメタデータ専用サーバーが不要です。
Highly-Available：マイクロ秒単位でI/Oフェイルオーバーを解決するような構成を組んでおり、ロケーションに依存しないデータの配置・検索技術を保証します。
※参考リンク：
EdgeFSの登場した背景（ユースケース）
そもそもEdgeFSがどのような理由で開発されたのか、様々な記事上でいくつかのユースケースが紹介されていますが、その中でも一番しっくり来たこちらの記事の内容を紹介します。
レガシーシステムにおけるEdge/Fog Computingの問題点
これまでのレガシーなシステムは、中央集権的なデザインをベースに作られており、このシステムでは、データ容量的には数GB、あるいは数百万レコードを扱う場合、ネットワーク的にはクラウドと接続するネットワークが「適度に早く」、数ギガバイトのデータを数秒でアップロードできる間は機能します。
一方で、ここ20年程で転送速度が10-100倍になっているにもかかわらず、WANのレイテンシはそれほど改善されておらず、いまだ物理的な距離に依存します。例えばダイレクトなFiber Connectを利用した場合でも、東海岸から西海岸までの速度が40ms-100msを上回ることはありません。
また、ネットワークレイテンシの問題だけではなく、データ量が増加する問題もあります。全てのデータがデジタル化され、あらゆるデバイスで生成されるデータが収集されることを考えると、特にEdgeのデータ量は急速に増加することが予測されます。
これらの問題点をまとめると、以下のようになります。
Bandwidth or slow WAN I/O problem：Edgeデータが集めるためにTB・PB級のデータを保存する必要があり、それを実現するうえで問題が発生し始める。またセンサー・5Gの技術が生み出す何億ものレコードを扱うことが難しくなる。
Latency or slow WAN I/O problem：ネットワーク技術の向上にもかかわらず、地理的距離に応じてレイテンシは増加する。アプリケーション側でマルチスレッドなどの技術を利用すれば多少改善はするかもしれないが、その分構成が複雑になり、また結果整合性を扱う必要も生じる。
Data Copy problem：データをコピーしたら、解析などの目的のためにどこかに保存する必要がある。一時的であれ、クラウドストレージ上に数百テラバイトものデータを保存することは、他のリソースと比較するまでもなくコスト増につながる。
Data Management problem：コピーされたデータは重複排除や効率的な圧縮ができないだけでなく、増え続けるデータを管理するコストも発生する。
Data “Silos” problem：規則等の理由で保存が義務付けられたデータを、ビジネス上の理由で複数サイトで所有した場合、制御不能のデータの集まりが「サイロ」を生み出す。サイロは通常管理が難しく、移動やバックアップも容易にできない。
Multi-Cloud problem：異なるクラウドを利用することで、異なる技術・プロトコル・プロセスを扱う必要がある。マルチクラウドにデータが散らばりサイロが発生した場合、その管理は困難になり、結果的にはマルチクラウドの利点を損なうことになる。
EdgeFSによる解決策
上記問題を解決するには、データを地理的なスケールで容易に回収・分散・監視・利用するメカニズムが必要となります。そしてEdgeFSはまさにそのような機能を提供するストレージソフトウェアになります。
EdgeFSを利用することで、上記問題に対して以下のような解決策を提供します。
1. Slow WAN I/O
I/Oがローカルサイトで発生した場合は、すべての処理がスムーズに実行され、またローカルストレージのI/O速度は今ではローカルネットワークI/Oとほぼ同等でレイテンシもほとんど発生しません。そのため、EdgeFSでは、可能な限りローカルのI/O処理を多くする戦略をとります。
EdgeFSではすべての構成物はimmutableであり、Gitと同様に、すべての変更点・変更履歴がグローバルに保存される一方で、ローカルのIOPSパフォーマンスを実現します。EdgeFSではデータ書き込みは常にローカルで行い、バージョンのアップデートはトランザクションの一貫性とともに実行されます。またデータ読みこみの大部分はローカルで行い、その動作は動的な損失データチャンクの読み込み・geo-transparentなキャッシュ機能によって実現します。グローバルなデータのバージョン管理・メタデータのimmutabilityを担保することで、データ読み込みの一貫性などを保証し、ローカルのI/Oに近いパフォーマンスをもたらします。
2. High Cost
余分なデータコピーがある場合、データそのものを保存するコストに加え、データを管理するためのコストが発生します。EdgeFSではこれまでローカルサイトで提供されてきた重複排除・キャッシュ・スナップショットの取得といった機能をグローバルサイトに拡大し、データ保存量や管理コストを削減することができます。例えば、EdgeFSではあるデータが重複していると検出した場合、そのデータは送信しません。またグローバル名前空間の管理は自動的に行われます。
さらにEdgeFSは、隣接するサイトから損失したブロックを読み込むことで自己修復することも可能なため、DRや可用性の担保を容易に実現することができます。
その他ユースケース
上記のような、Edge・IoT環境でのデータ送信・保存・管理にあたって発生するストレージ・ネットワークの問題を解決するだけでなく、以下のようなユースケースでの利用も提案されています。
- マルチクラウドのCDNワークフロー：ローカルキャッシュ機能によるコンテンツの分散配置、マルチクラウドでのデータ同期によるCDNの提供を実現
- クラウド環境でのHA：あるクラウド環境との接続が切れた際、別リージョンのデータセットへ自動的にフェイルオーバーされる
- クラウドをまたいだKubernetes Persistent Volumeの提供
- ジオスケールなNFS/S3データアーカイブ
- 開発者向けデータセットの提供：開発に利用するデータセットがTBサイズであったり、頻繁に変更が走るような場合
※参考リンク：
medium - Dockerized single-node EdgeFS with geo-transparent S3/NFS access
medium - Data Geo-Transparency with EdgeFS on Mac for Developers
コンポーネント
ここからEdgeFSのコンポーネントについて紹介します。なお、以下のコンポーネントの中には、実際にKubernetes上で動作するコンテナも含まれているため、RookとEdgeFSのコンポーネントとを明確に分離できていない部分があります。
- gRPC Manager: NFS/iSCSI CSI pluginを利用している場合、CSI pluginからのリクエストをバランシング・委任する機能を提供します。また
efscliコマンドを実行できるtoolboxとしても機能します。Pod内では以下の3つのコンテナが起動しています。rook-edgefs-mgrgrpc: gRPC-EFSProxyが動作します。ui: EdgeFS Dashboardを提供します。
- Target: EdgeFSにおけるデータノードであり、HDD/SSDを扱います。Pod内では以下の3つのコンテナが起動しています。
- NFS: NFSサービスを提供します。Pod内ではNFS Ganeshaのほか、gRPCプロセスも起動します。
- S3: S3サービスを提供し、Pod内ではgRPCプロセスも起動します。
- S3X: S3Xサービスを提供します。Pod内では
rook-edgefs-s3xs3-proxyの2つのコンテナが起動します。 - iSCSI: iSCSIサービスを提供し、Pod内ではgRPCプロセスも起動します。
- CSI plugin: Rook v1.2時点では、NFS/iSCSI向けのCSI pluginを利用できます。
- ISGW: Inter-Segment Gateway。別クラスターとの接続や各機能を提供します。
※参考リンク：
Corosync - The Corosync Cluster Engine
CCoWとは
Target Pod上で動作するdaemonコンテナ内部ではCCoWというプロセスが起動しています。このCCoWについて、こちらの記事を元に紹介します。
※こちらの記事より
CCoWはCloud Copy on Writeの略称で、バージョン管理されたオブジェクトデータへのアクセスを提供する、オブジェクトストレージシステムです。チャンクベースの分散重複排除機能を備えており、ベアメタルやVMなどにデプロイすることができます。
Object Storage Access Server: クライアントに従来のオブジェクトストレージへのアクセス方法を提供します。リクエストをchunk request・manifest requestに変換し、Chunk Server・Manifest Serverへ転送します。またS3/SWIFTの互換性も持ちます。
Chunk Server: chunk向けのローカルストレージを提供します。以下のような機能を持ちます。
- chunkのput requestに対して、トランザクションID・Chunk IDを付与して保存します。トランザクションIDはManifest Serverから追跡するために付与し、chunk IDは各chunkに付与し、配置するために必要です。
- 各chunkは、圧縮されたchunk payloadの暗号化ハッシュ値によって識別されます。どのchunkかがわかっている場合、payloadを解読することなくchunk Putトランザクションを完了します。
- 別のchunk serverにchunkを複製します。
- それがchunk専用サーバーである場合、または容量が十分でローカルにchunkを保持することが可能である場合、chunkを保持する
- chunkがローカルに保存されたとき、あるいは別のchunk serverから送られたときに検索する
- オブジェクトのリファレンスを維持する
Manifest Server: 各バージョンのオブジェクトに関するメタデータ情報を保持します。オブジェクトはService Directoryという、オブジェクトストレージのバケットのようなものに統合されます。以下のような機能を提供します。
- 各バージョンはバージョン識別機（version identifier）で特定されます。version identifierはグローバルに同期したタイムスタンプ・tiebreakerをベースに、各Manifest Serverで生成されます。各Manifest ServerのIdentifierは一意であり、別のManifest ServerからのVersion Manifestは異なるオーダーで飛んでくることが前提です。一度すべてのトランザクションが全Manifest Serverにアプライされれば、全てのサーバは最終的に同じVersion Manifestを獲得することが想定されます。
- オブジェクトに変更がありVersion Manifestが更新されると、ストレージへの要求が発生します。要求が発生した場合はChunk Server上のchunkリファレンスを更新します。
- 別のManifest ServerにManifest情報を複製します。
- Manifest専用のオブジェクトストレージサーバーを用意することも可能で、その場合は専用サーバーがchunk/version manifestを保持し、localではchunk/version manifestを保持する必要がなくなります。
※こちらの記事より
FlexHash
上記Object Storage Server（Target）間は、Replicastと呼ばれる高パフォーマンス・低レイテンシのUDPベースのプロトコルで接続されます。また各オブジェクトの配置場所の決定には、FlexHashというハッシュテーブルを利用します。
※こちらの記事より
FlexHashはオブジェクト名をハッシュ化（SHA-256）した値を、オブジェクトの保存場所を決定するために利用します。オブジェクトの保存場所・及び検索にはハッシュ値を利用します。オブジェクト名の先頭部分はdigestとして利用し、Negotiation Groupと呼ばれるサーバーのグループをを決定する際に利用します。Negotiation Groupが適切なサーバーを選択し、Rendezvous Groupがデータ転送をスケジューリングします。
FlexHashはローカルサイトで構築され、サーバーメモリに常駐し、EdgeFSにおけるI/Oルーティングを担う重要なコンポーネントです。
Negotiation Group
Negotiation Groupはfailure Domainポリシーに基づくサーバー間・ラック間をまたいだサーバーグループです。クライアントからの要求に対し、どのNegotiation Groupがchunkを受け入れるか、メンバー間でnegotiateして決定します。Negotiation Groupのメンバー間で通信をすることで、ノードやストレージの状態を考慮して最適な保存場所・複製場所を決定することができます。またNegotiation Groupを利用することで、クライアントがサーバーの場所を知る必要はなく、リクエストをNegotiation Groupに送ればよくなります。
Rendezvous Group
Rendezvous Groupは別ストレージサーバへのデータ転送を行います。Object Storage Serverがオブジェクトを受け取ると、まずオブジェクトを複数のchunkに分割し、各送信先に転送します。転送の際、複数のUDPデータグラムに分割して送信し、送信先で再集積し、chunkのSHA-256のハッシュ値とそれを比較します。chunk全体のハッシュ値を利用することでデータの正確性を担保し、データ転送が成功したかを確認するために必要な転送パケットが大きく削減できます。またオブジェクトを変更した場合も、変更した分は、該当のchunkのみを転送すればよくなります。
なお、データの転送が失敗し、再送が必要な場合は、chunk全体を再送する必要があります。しかし、ネットワーク輻輳によりすべてドロップされることに比べれば、転送の失敗・再送は許容できる範囲であると考えられているようです。
また、Chunk Serverからデータを一度転送すれば、複数のストレージサーバーにデータを転送することができます。これにより、ストレージサーバーへデータ転送を行う際のネットワーク利用帯域を抑制し、高パフォーマンス・低レイテンシを実現します。
ISGWとは
※Rook公式ドキュメントより
ISGW（Inter-Segment Gateway）は、EdgeFSにおけるセグメント間・クラウド間のグローバル名前空間同期機能に利用します。ISGWにより、複数サイト間で非同期的にchunk dataを分散し、シームレスでGeo-Transparentなデータアクセスを実現します。ISGWは、以下のような機能を提供します。
ISGWがリンクされているデータのソースサイトでファイル・オブジェクトに修正が走ると、ISGWエンドポイントリンクが検知し、拡散します。これにより転送データ量を削減することができます。
ファイル変更が走っても、そのハッシュ値がグローバルに一意でなければ（他にマッチするものがあれば）転送されません。そのため、グローバル空間で重複排除され、転送データの重複排除を実現できます。
サイト間でのISGW送信方向について、片方向・双方向通信の設定が可能です。双方向通信により、グローバル名前空間全体で同じファイル/オブジェクトの変更を可能にします。また 不要なサイト間の通信や通信方向を制御することもできます。
Geo-Transparentなデータ同期を実現するため、グローバル名前空間全体でデータ変更が確認できます。
メタデータの変更のみを転送することも可能です。これを有効にすると、ユーザーはオンデマンドでデータの変更を読み込めるような効率的なアクセスエンドポイントを構築できます。
最後に
ここまででEdgeFSの概要を眺めてきましたが、個人的には以下のような感想を持ちました。
EdgeFSは地理的スケールでデータを扱うときに生じる問題を解決するために開発された。ネットワーク帯域逼迫・パフォーマンス低下の問題に対しては、不要な通信をしないことで利用帯域を抑えるよう制御し、データ保存によるコスト増に対しては、データの重複排除や管理の自動化により対応する。
EdgeFSはCephとは異なり、完全にコンテナ/Kubernetesに対応したストレージソフトウェアである。Kubernetes上であればクラウド・オンプレ等の環境にデプロイできる。
EdgeFSではNexenta Systems Inc.の開発したプロトコルを多く含んでおり、それらがEdgeFSの構成や機能を形作る大きな要因となっている。
EdgeFSを複数サイトで利用する際はISGWを使うことが前提である。
参考ドキュメント
Rook/EdgeFS公式ドキュメント
medium EdgeFS関連
meduim - Securing and Deduplicating the Edge with EdgeFS
medium - Dockerized single-node EdgeFS with geo-transparent S3/NFS access
medium - Data Geo-Transparency with EdgeFS on Mac for Developers
medium - A Data Layer for Edge/IoT and Fog Computing
medium - Multi-Segment Distributed Storage for Kubernetes
Nexenta関連ページ
nexenta - CCOW-Negotiating Rendezvous Groups
nexenta - Cloud Copy On Write (CCOW)
