オープンソースの分散ストリームストレージ Pravega が必要な理由は何ですか?

[[254700]]

産業用 IoT、自動車のインターネット、リアルタイムの不正リスク管理に対する需要が急速に高まっています。ますます多くの新しいエンタープライズ アプリケーションは、変化する動作パターンを学習して適応しながら、顧客のニーズに迅速に対応する必要があります。同時に、5G ネットワーク、コンテナ クラウド、高性能ストレージ ハードウェアの継続的な改善により、リアルタイム ストリーム処理の市場展望はますます広がっています。

ストリーム処理は、バッチ処理での蓄積や処理を待たずに、継続的に生成されるデータを分析し、短時間で価値を生み出すことができます。取り込みから結果までの低レイテンシは、ストリーム処理テクノロジーによってもたらされる最も重要な利点です。たとえば、車載システムの分析フィードバック、クラスターパフォーマンスログデータの分析とアラーム、金融詐欺リスク管理の正確な位置特定、モノのインターネットにおけるガス漏れインシデントの処理などのアプリケーションでは、高い同時実行性で 10 ミリ秒の低レイテンシが最も重要なビジネス価値を意味します。

ストリーム処理は、一見すると単純です。データが到着すると、それを迅速かつ継続的にシームレスに処理して操作するだけです。しかし、現実には、ほとんどの企業は PB から EB のデータ ボリュームをサポートし、収集率と障害回復機能を満たすリアルタイム ストレージ/コンピューティング エンジンを持っていません。バッチ処理やリアルタイムのシナリオに適したさまざまなカスタマイズされたストレージやコンピューティング エンジンが登場し、ビジネスが拡大し続けるにつれて、エンタープライズ レベルのビッグ データ システムに複雑さが蓄積され、リソースの大幅な浪費や運用上の困難が生じることは避けられません。

ストリーミングにより、システム設計者は基本的なコンピューティングとストレージの原則を再考する必要が生じます。アーキテクチャに関係なく、現在のビッグデータ処理システムは、「コンピューティングはネイティブ ストリーム コンピューティングですが、ストレージはネイティブ ストリーム ストレージではありません」という共通の問題に直面しています。 Pravega チームは、この基本的なデータ処理とストレージのルールを再考し、このシナリオに合わせて、サンスクリット語で「良いスピード」を意味する「Pravega」と名付けられたネイティブ ストリーム ストレージという新しいストレージ タイプを再設計しました。

Pravega 前のストリーム データ処理

ビッグデータブームの初期段階で MapReduce が登場し、数千台のサーバーのクラスターを使用して、膨大な (TB から PB) データ セットを分散および処理できるようになりました。 1 つ以上の大規模なデータ セットで動作するこのタイプの分散コンピューティングは、多くの場合、バッチ ジョブと呼ばれます。バッチ処理により、さまざまなアプリケーションが生データから価値を引き出すことができるようになり、膨大なユーザーデータを持つ企業の成長に重要な役割を果たします。

大規模なデータ セットのバッチ処理ジョブの完了時間は通常、数分から数時間にわたります。このような長い遅延は、最新のデータを使用することが重要であり、同時に処理の精度も保証する必要がある推奨システムなどの多くのアプリケーションには理想的ではありません。たとえ小さな推奨の失敗であっても、最終的にはユーザーが離脱する原因になる可能性があります。ハードウェア レベルの向上と相まって、すぐに要求も高まり始めました。データが蓄積されてから処理されるのを待つのではなく、データ生成のペースに追いついてデータ処理結果を取得したいと考えています。そのため、低遅延ストリーム処理は徐々に人気を集めています。受信データは基本的にイベント、メッセージ、またはサンプルの連続ストリームであるため、これをストリーム処理と呼びます。

リアルタイム分析に関心のある多くの企業は、MapReduce モデルを放棄することに消極的です。レイテンシの制約に対処するために、一部のアプリケーションではマイクロバッチ処理、つまり、より短い期間に蓄積された小さなチャンクでジョブを実行する処理を使い始めています。 Apache Spark Streaming に代表されるマイクロバッチ処理は、ストリームを秒単位の増分でバッファリングし、メモリ内で計算を実行します。これは実際に非常にうまく機能し、アプリケーションがより短時間でより多くの価値を獲得できるようになります。

ただし、バッファリング メカニズムが存在するため、マイクロ バッチ処理のレイテンシは依然として比較的高くなります。アプリケーションの低レイテンシ要件を満たすために、ネイティブ ストリーム処理プラットフォームの研究開発は過去 5 年間にわたって継続的に行われてきました。以前のシステムには、S4 と Apache Storm が含まれます。 Storm は成熟しており、強力なコミュニティ基盤を持ち、現在でも多くの企業で広く使用されています。 Heron は Twitter が開発した新世代のストリーム処理エンジンで、Storm と互換性があり、パフォーマンスが向上しています。 Apache Samza と Kafka Stream は、効率的なストリーム処理を実現するために Apache Kafka メッセージング システムに基づいています。

バッチ処理システムとストリーム処理システムは異なるフレームワークを使用するため、企業はリアルタイム アプリケーションとバッチ処理アプリケーションの両方のニーズを満たすために、2 つの独立したコンピューティング インフラストラクチャを使用する必要があります。計算結果は、クエリ用のさまざまなフレームワークにも入力されます。 Storm の創設者である Nathan Marz 氏は、ビッグデータ プラットフォームをバッチ処理層、ストリーム処理層、アプリケーション サービス層に分割する Lambda ビッグデータ処理アーキテクチャ (図 1) を提案しました。 Lambda アーキテクチャは、読み取りと書き込みの分離と複雑性の分離の原則に従い、オフライン コンピューティングとリアルタイム コンピューティングを統合し、Hadoop、Kafka、Storm、Spark、Hbase などのさまざまなビッグ データ コンポーネントを統合することで、2 種類の処理を高いフォールト トレランス、低レイテンシ、スケーラビリティの条件下でスムーズに実行できるようにします。

図1: ラムダアーキテクチャ

近年、テクノロジーとアーキテクチャの進化に伴い、エンジニアは、「ストリーム」と「バッチ」という言葉を使用してアプリケーション シナリオを区別し、コンピューティング フレームワークを分類するのは適切ではないことに気づき始めています。実際、2 つの処理方法には多くの類似点があります。多くのシナリオでは、ストリーム処理アプリケーションとバッチ処理アプリケーションは同じ処理ロジックを使用しますが、フレームワークが異なるため、繰り返し開発する必要があります。データが生成されるときには、バッチとストリームの概念はありません。データを処理する方法が異なるだけで、データ属性が異なり、その結果、フレームワークも異なります。

ストリームとバッチの間に境界があってはなりません。

LinkedIn の Jay Kreps (Apache Kafka の作者であり、Confluent の現 CEO) は、バッチ処理層とストリーム処理層を一貫性のあるストリーム処理に簡素化する Kappa アーキテクチャを提案しました。 Google のエンジニア (Apache Beam の中心人物) である Tyler Akidau 氏は、Google の以前の世代の MapReduce を置き換え、バッチ処理 (制限されたデータ フロー) をストリーム処理 (大規模なデータ フロー) の特殊なケースとして扱い、ビッグ データ処理の基本を再定義することを目的とした Dataflow モデルを提案しました。新世代のストリーム処理フレームワークのリーダーである Apache Flink は、データフロー モデルに従って設計されており、バッチ処理とストリーム処理を根本的に統合しています。 Apache Spark は、従来のマイクロバッチ設計を覆し、テーブルと SQL の概念を使用して処理を統合する Structured Streaming を導入しました。

ストリーム処理アプリケーションの成功には、データを効率的に取り込み、提供することが重要です。処理速度と頻度の違いにより、データの取り込みは 2 つの戦略を通じて実行する必要があります。一般的な Lambda アーキテクチャでは、分散ファイルシステム (HDFS など) はバッチ処理アプリケーションに高同時実行性と高スループットのデータを提供する役割を担い、メッセージキューシステム (RocketMQ など) はストリーム処理アプリケーションに一時的なデータバッファリングとパブリッシュ/サブスクライブ機能を提供する役割を担います。データは長期間保存されません。これら 2 つを統合できないことが、現在の Kappa アーキテクチャで履歴データを処理する能力が限られている理由でもあります。

Pravega は、ストリーム用のリアルタイム ストレージ ソリューションとして設計されています。アプリケーションはデータを Pravega に永続的に保存します。 Pravega のストリームは数に制限があり、任意の期間永続的に保存できます。同じ Reader API を使用して、テール読み取り機能とキャッチアップ読み取り機能が提供され、2 つの処理方法の統合を効果的に満たすことができます。

Pravega は、正確に 1 回の処理をサポートし、Kappa アーキテクチャ上にリンクされたアプリケーション要件を実装して、計算を複数の独立したアプリケーションに分割できます。これは、ストリーミング システムのマイクロサービス アーキテクチャです。私たちが構想しているアーキテクチャは、データ処理においてイベント駆動型、継続的、かつステートフルなストリーミング ストレージ コンピューティング モデルです (図 2)。

図2: ストリーム処理のシンプルなライフサイクル

Pravega ストリーム ストレージと Apache Flink ステートフル ストリーム プロセッサを組み合わせることで、図 2 のすべての書き込み、処理、読み取り、およびストレージが独立し、弾力性を備え、到着するデータの量に基づいてリアルタイムで動的にスケーリングできるようになります。これにより、これまでは構築不可能だったストリーミング アプリケーションを構築し、テスト プロトタイプから実稼働環境までシームレスに拡張できるようになります。 Pravega により、Kappa アーキテクチャはパズルのピースを完成させ、統合ストレージと統合コンピューティングの閉ループを形成しました。

ストリーミングストレージの要件

使用するコンポーネントは、達成したいニーズを満たすように設計する必要があります。そうしないと、今日のビッグデータ アーキテクチャのように複雑さが増してしまいます。前述のように、既存のストレージ エンジンでは、両方のデータ読み取りの要件を同時に満たすことはできません。実際のアプリケーション シナリオを組み合わせて必要な機能をまとめると、エンタープライズ レベルのストリーム ストレージ エンジンの実装は、一見矛盾する 3 つのシステム機能が必要になるため、非常に困難です。

• データを有限かつ静的なものではなく、連続的かつ動的なものとして見る能力
• データ収集、保存、処理機能を自動的かつ柔軟に拡張し、負荷に対応して継続的かつ迅速に結果を提供する機能
• 遅延データや順序不同データが存在する場合でも、正確な処理結果を継続的に配信します。

上記の機能を詳しく見て、現在業界で最も広く使用されている分散メッセージング システムである Apache Kafka と比較し、Pravega が現在のストレージでは不可能な方法でこれらの機能をどのように実装しているかを見てみましょう。

データを連続的に扱い、

Kafka は LinkedIn のログ収集システムから生まれ、分散トランザクション ログ アーキテクチャを使用して永続性レイヤーを管理します。したがって、Kafka はファイルの末尾に追加してその内容を追跡することで、継続的でシームレスなデータ ストリームをシミュレートします。ただし、ファイルはこのモード用に最適化されておらず、ローカル ファイル システムのファイル記述子やディスク容量によって制限されることもないため、安全ではありません。データの信頼性のために、Kafka は同期レプリカを使用しますが、これによりストレージがさらに消費され、スループット パフォーマンスも低下します。また、メッセージのヘッダーを使用してメタデータを記録し、データ構造を構築するため、バイト シーケンスほど汎用的ではありません。

これらのアイデアを組み合わせ、データの観点から Pravega がサポートする継続的かつ包括的な機能を考案しました。

• Pravega ストリームは、名前が付けられ、永続的で、追加専用の、安全なバイト シーケンスです。
• 低レイテンシを使用してテール書き込みを追加し、シーケンスの最後から読み取ります (テール読み取り/書き込み)
• シーケンスの古い部分からの高スループットキャッチアップ読み取り

負荷に基づいた自動（ゼロタッチ）の弾性スケーリング（スケールアップ/スケールダウン）

Kafka は、データをパーティションに分割し、個別に処理することで並列処理を実現します。この習慣は長い間続いてきました。 Hadoop はパーティションを使用して、HDFS および MapReduce で並列バッチ処理を実装します。ストリーミング ワークロードの場合、従来のパーティショニングには大きな問題があります。パーティショニングは読み取りクライアントと書き込みクライアントの両方に影響します。順次処理される読み取りおよび書き込み操作に必要な並列度は通常変化するため、固定数のパーティションをリンクすると実装の複雑さが増します。拡張のためにパーティションを追加することは可能ですが、書き込みクライアント、読み取りクライアント、およびストレージを手動で更新する必要があります。高価であり、動的に拡張できません。

動的かつ独立したスケーリングを実現するように設計された Pravega は、以下をサポートします。

• 多くの書き込みクライアントがデータのばらばらのサブセットを同時に追加する
  • データの書き込みは、ルーティングキーに依存して異なるセグメントに書き込み、分離性を確保します。
  • アプリケーションがクライアントに書き込みキーを割り当てるようにする
  • キー空間または書き込みクライアントが変更された場合、対応するストレージに制約や変更を加えることはできません。
• 多数の読み取りクライアントがデータの断片的なサブセットを同時に処理する
  • データパーティションの読み取りは書き込みパーティションに依存しません
  • 読み取られるパーティションはストレージポリシーによって制御されます
  • 物理的なパーティションの代わりにセグメントの概念を使用すると、取り込みフローに基づいて数値が自動的かつ継続的に更新されます。

データを継続的に処理して正確な結果を生成する

正確な結果を得るには、連続計算を正確に 1 回処理する必要があります。一度だけ処理するセマンティクスには、データ保存に関する明確な要件があります。データの書き込みは次の条件を満たす必要があります。

• 持続的
• 整然とした
• 一貫性のある
• トランザクション

これらの重要な属性は、ストレージ システム設計の最も難しい部分でもあります。事前の設計考慮がなければ、これらの機能は後でシステムを再構築することによってのみ実現できます。

耐久性とは、書き込みが確認されると、コンポーネントに障害が発生した場合でもデータが失われないことを意味します。永続性は、障害発生後のデータの再生に関係するため重要です。永続性のないシステムでは、開発者がデータを手動でアーカイブする必要があり、最新のコピーがアーカイブ システム (通常は HDFS) に保存されます。 Pravega ストリーミング ストレージは、データを永続的な階層型ストレージに書き込むことで永続性を確保し、ユーザーがストリーミング データを最も確実に保存できるようにします。

順序とは、読み取りクライアントがデータが書き込まれた順序でデータを処理することを意味し、Kafka はコンシューマー グループ内で順序があることを保証します。ルーティング キーによるパーティション分割を実装する Pravega などのシステムの場合、順序付けは同じキーを持つデータに対してのみ意味を持ちます。たとえば、数百万個のセンサーを備えた IoT システムでは、sensor-ID.metric をキーとして使用し、Pravega の Stream を使用すると、このセンサーから読み取られたデータが書き込まれた順序になることを保証できます。増分更新を使用して計算される集計関数などのアプリケーションでは、順序付けが不可欠です。

一貫性とは、コンポーネント障害が発生した場合でも、ストリームの末尾から読み取る場合でも、追いつく場合でも、すべての読み取りクライアントが特定のキーのデータについて同じ順序付けされたビューを参照することを意味します。永続性と同様に、Pravega の一貫性はストレージ システムの一貫性のみに依存することはできません。 Pravega の場合、書き込みクライアントの書き込み操作はべき等であり、書き込まれたデータも Pravega に対して不透明 (再度変更できない) であるため、強力な一貫性が実現されます。 Pravega の強力な一貫性に基づいて、状態同期 API も抽象化しました。これにより、ユーザーは他の分散システム用の軽量な状態同期を構築できます。

トランザクション書き込みは、リンクされたアプリケーション全体で 1 回だけの正確性を確保するために必要です。 Pravega 自体はトランザクション書き込みをサポートしているだけでなく、Apache Flink の Sink と統合されており、Flink チェックポイント間のトランザクションを確立し、エンドツーエンドのトランザクションと、分散 2 フェーズ コミット プロトコルによる 1 回限りの処理をサポートします。

参照する

公式サイト: http://pravega.io

GitHub リンク: https://github.com/pravega/pravega/

http://blog.pravega.io/2017/04/09/storage-reimagined-for-a-streaming-world/

http://blog.pravega.io/2017/12/14/i-have-a-stream/

著者について Teng Yu: DellEMC の非構造化データ ストレージ チームに所属し、ソフトウェア開発のディレクターを務めています。 2007 年に DellEMC に入社して以来、分散ストレージ分野に注力しています。中国の研究開発チームに参加し、そのリーダーとして 2 世代の DellEMC オブジェクト ストレージ製品の研究開発に参加し、商業的な成功を収めました。 2017 年以降は、ストリーミング ストレージとリアルタイム コンピューティング システムの設計と開発も担当しています。

周 宇民: 復旦大学のコンピューターサイエンスの大学院生。学部在学中から DellEMC 分散オブジェクト ストレージでインターンシップに参加しています。現在、Flink関連分野の研究開発業務に携わっています。