Uber社、Apache Kafkaの階層型ストレージ機能を推進、効率性をめぐる議論に拍車

原文リンク(2024-08-14)

運送会社のUber社が、人気の分散イベントストリーミングプラットフォームApache Kafkaの新たな階層型ストレージ機能追加について、詳細を発表した。本機能は、大規模なKafkaクラスタを運営する組織の直面するスケーラビリティや効率性の課題への対応として3.6.0で追加され、現在、早期アクセスの段階である。

階層型ストレージの使用で、Kafkaのストレージケイパビリティが、ローカルのブローカーディスクだけでなく、HDFS、Amazon S3、Google Cloud Storage、Azure Blob Storageといったリモートストレージシステムまで拡張可能になる。今回の機能強化により、Kafkaクラスタがコンピュートリソースから独立したストレージ拡張を行えるようになるため、コストや運用の複雑さの軽減が見込める。

Uberのブログ投稿によると、今回のプロジェクトは、Kafkaクラスタでの一般化している拡張方法の制限克服を目指している。

「通常、Kafkaクラスタのストレージは、ブローカーノードを追加することで拡張されます。しかし、これでは同時に、クラスタに必要のないメモリやCPUまで追加されるため、古いデータを外部ストレージで保存した場合に比べ、全体的なストレージコストの効率が落ちてしまいます。」

さらに、ノードがより多くなる大規模なクラスタでは、ストレージとプロセスが密結合になることで、デプロイメントの煩雑性や運用コストが増すとのことだ。

階層型ストレージ・アーキテクチャでは、ローカルとリモートの2つのストレージ階層が導入されている。ローカル階層はブローカーのローカルストレージで構成され、リモート階層はHDFSやクラウドオブジェクトストアなどの拡張ストレージで構成されている。両方の階層で、特定のユースケースにあわせた個別保持ポリシーが使用可能である。

Red Hat社の機能の詳細分析記事で、以下のように利点の概要が述べられている。

• 弾力性：コンピュートリソースとストレージリソースの独立拡張が可能に。
• 分離：レイテンシーの影響を受けやすいデータはローカル層から、また過去のデータはKafkaクライアントへの変更なしでリモート階層からアクセス可能に。
• コスト効率：一般的にリモートオブジェクトストレージシステムが高速ローカルディスクと比べて低価格なため、Kafkaストレージはより手頃で、なおかつ実質無制限に。

階層ストレージシステムは、適格なログセグメントがローカルストレージからリモートストレージにコピーされて機能している。ログセグメントの適格性は、終了オフセットがパーティション内の最後にある安定したオフセットより小さいかどうかで判断される。このコピー処理は、トピックパーティションのリーダーとして作動するブローカーで行われる。

Uber社による実装で、このプロセスの簡易化に向けた新たなコンポーネントが導入された。

• RemoteStorageManager：リモートストレージからのコピー、取得、削除を含むリモートログセグメントへの実行処理。
• RemoteLogMetadataManager：セマンティクスの一貫性の高いリモートログセグメントに関するメタデータの管理。
• RemoteLogManager：リモートストレージへのコピー、期限切れセグメントのクリーンアップ、リモートストレージからのデータ取得などを含むリモートログセグメントのライフサイクル管理。

AWSによるAmazon Managed Streaming for Apache Kafka(Amazon MSK)の階層型ストレージの利用で、このコンセプトがさらに発展した。AWSのブログ投稿では、同機能でKafkaクラスタの可用性と回復力が大幅に向上するとされている。投稿したAWSのエンジニアは、いくつかの重要な利点を強調している。

• ブローカーリカバリーの高速化：階層型ストレージでは、データが高速なAmazon Elastic Block Store（Amazon EBS）ボリュームから、より費用対効果の高いストレージ階層に少しずつ自動で移動される。リーダーからローカル階層に保存されたデータを同期させるだけなので、ブローカー障害からの復旧プロセスが短縮される。
• ロードバランシングの効率化：パーティションの再割り当て時に移動するデータが少ないため、階層型ストレージを利用したAmazon MSKのロードバランシングは、より効率的である。プロセス速度が高くリソース集約度が低いため、より頻繁にシームレスなロードバランシングが可能になる。
• スケーリングの高速化：階層型ストレージの実装でMSKクラスタのスケーリングがシームレスになる。大量のデータ転送やパーティションのリバランシングに時間をかけることなく、新たなブローカーをクラスタに追加できる。

AWSは、m7gインスタンスタイプの3ノードクラスタを使用し、これらの利点を実証するための実環境テストを実施した。レプリケーション係数3のトピック作成と、300GBのデータ取り込みが行われた。階層型ストレージを使用しない場合、新しいブローカーを3つ追加してパーティションのすべてを既存ブローカーから新しいブローカーに移動する操作に約75分かかり、CPU使用率も高まった。

同じトピックで階層型ストレージを有効にし、ローカル保存期間を1時間、リモート保存期間を1年に設定した上で、再びテストを行った。すると、パーティションの移動操作は15分弱で完了し、目立ったCPU使用も見られなかった。AWSはこの改善について、あらかじめクローズドセグメントがすべて階層型ストレージに転送されており、階層型ストレージを有効にした状態では小さなアクティブセグメントの移動だけ行えばよいからだと説明している。

しかし、階層型ストレージに意欲的なのは、業界でも一部だけである。WarpStream社のRichard Artoul氏は、より慎重な見方を示しており、階層型ストレージはコスト削減には役立つが、新たな複雑性や潜在的な障害モードをもたらす可能性があると主張している。Artoul氏は、2つのストレージ階層を管理する複雑さが加わることで、運用オーバーヘッドの増加やシステム信頼性へ影響が出る可能性を指摘している。

Artoul氏は、リモートストレージからのデータ取得で、レイテンシーの発生やリアルタイム処理能力など、パフォーマンスに影響が起こる可能性への懸念を示した。同氏は、階層型ストレージによる削減コストが相殺されうるとも示唆している。クラウド環境上のゾーン間ネットワーク費用をはじめとして、リモートストレージシステム上のデータ管理費用やアクセス関連費用が加わるためだ。さらにArtoul氏は、階層型ストレージは、ユーザーが現行のKafkaで抱えている2つの主な問題、複雑さや運用負荷、そしてコスト（とりわけゾーン間ネットワーク費用）の問題に対処する必要があると主張している。階層型ストレージでこうした問題が解決どころか、悪化する可能性があると述べている。

階層型ストレージで潜在的な利点が得られる一方で、現在いくつかある制限に注意することが重要だ。Red Hat社の分析の通り、本機能ではまだ複数のログディレクトリ（JBOD）やコンパクト化されたトピックをサポートする必要がある。加えて、トピックの階層化をオフにするには、元のトピックを削除する前に、データを別トピックや外部ストレージに転送する必要がある。

Uber、Red Hatの両社が、階層化ストレージを利用する際のモニタリングの重要性を強調している。リモートストレージ操作を追跡する新しいメトリクスが導入されたことで、ユーザー側でのアップロードやダウンロードの遅延や、高確率でのエラーといった、潜在的な問題のモニタリングや、アラートの作成が可能になった。

Uber社は本機能を1-2年前からさまざまなワークロードで本稼動させているが、オープンソースリリースのApache Kafka 3.6.0ではまだアーリーアクセス段階とみなされている。採用検討中の組織は、現時点での機能と制限を評価を慎重に行う必要がある。

階層型ストレージの導入で、大規模なデータストリームの管理がより効率的かつコストを抑えられる可能性がある。Amazon MSKにおけるAWSの実装で実証されているように、シナリオによってはクラスタの回復性とスケーラビリティの劇的な向上が見込める。しかし、Artoul氏の批評で、本機能がKafkaユーザーの一部に向けた特効薬に過ぎない可能性が浮き彫りになっている。どのような新機能にもあてはまることだが、特にアーリーアクセス段階では、潜在的なメリットと新たに加わる煩雑性や運用上の課題を天秤にかけながら、本番環境にデプロイする前に、各環境でそれらの機能のパフォーマンスを徹底的にテストし、モニタリングすることをお勧めしたい。