クラウドネイティブ データレイク アーキテクチャにおけるサーバーレス Kafka

[[418139]]

[51CTO.com クイック翻訳]データレイクを補完する動的データを処理するには、ハイブリッドクラウド上でクラウドネイティブでサーバーレスの Apache Kafka を活用する方法を理解する必要があります。 Kafka は、Web サイト上の消費者のすべてのアクション ストリーム データを処理できる、高スループットの分散型パブリッシュ/サブスクライブ メッセージング システムです。

現在、Apache Kafka は動的データを処理するための事実上の標準となっています。 Kafka はオープンで柔軟性があり、スケーラブルですが、多くのチームにとって運用上の課題ももたらします。理想的には、企業の IT チームはサーバーレス Kafka SaaS 製品を使用してビジネス ロジックに集中できます。ただし、ハイブリッド シナリオは、運用上の負担を軽減するための自動化および弾力性ツールを提供するクラウド ネイティブ プラットフォーム上で実行する必要があります。この記事では、ハイブリッド クラウド アーキテクチャでクラウド ネイティブおよびサーバーレスの Kafka 製品を活用する方法と、データ レイクの保存データの観点からそれが Kafka の移動データとどのように関係するかについて説明します。

1. 静的データは依然として適切なアプローチでしょうか?

保存データとは、データベース、データ ウェアハウス、またはデータ レイクに保存されているデータのことを指します。つまり、多くのユースケースでは、Kafka などのリアルタイム ストリーミング コンポーネントがデータを取り込んだとしても、データの処理が遅すぎることになります。データ処理は依然として Web サービス呼び出し、SQL クエリ、またはマップ削減バッチ プロセスであり、発生した問題は解決されません。

保存されているデータは悪いことではありません。レポート (ビジネス インテリジェンス)、分析 (バッチ処理)、モデル トレーニング (機械学習) などのいくつかのユース ケースでは、このアプローチが必要です。

（1）Clouderaデータレイクの間違い

何年も前に、Cloudera と Hortonworks は、IBM などのパートナーと協力して、ほとんどの企業にデータ レイク テクノロジーを導入しました。これらの企業はすべて、ビッグデータを導入するというビジョンを持っています (ただし、そこからビジネス価値を引き出す方法がわかっていません)。データ レイクは 20 を超えるさまざまなオープン ソース フレームワークで構成されています。

新しいフレームワークが登場すると、データ レイクが最新の状態に保たれるように追加されます。それで、主な問題は何でしょうか?商業的価値はありません。さらに、ベンダーと連携するための適切なビジネス モデルが存在しない可能性があり、特に 2 つの非常に類似したベンダーが競合し、最終的に Cloudera が Hortonworks と合併する場合には、販売サポートだけでは機能しない可能性があります。

Cloudera は、Storm、Kafka、Spark Streaming、Flink などのイベント ストリーミング プラットフォームだけでなく、多くのデータ レイク テクノロジーを含む、さまざまなフレームワークのサポートも引き続き提供しています。この比較的小さな会社がどのようにしてこれを成し遂げたのか、人々は驚いています。多くの人は各フレームワークについてある程度理解しているだけであり、時代遅れの Hadoop エコシステムについてのみ深く理解している可能性があるため、このビジネス モデルは機能しません。今年まで、Cloudera には真の SaaS 製品がありませんでした。これは驚くことではありません。20 を超えるフレームワークを使用して真の SaaS 製品を構築するのは簡単ではないためです。

比較的小規模な企業の場合、すべてを実行しようとするよりも、1 つのことだけを実行する方がよいことが判明しました。

（２）AWSのレイクハウス戦略

世界の主要なクラウドプロバイダー (AWS、GCP、Azure、Alibaba)、MongoDB、Databricks、Snowflake などのクラウド コンピューティング ベンダーが協力してデータ レイクを構築する必要があります。それぞれに固有のユースケースとトレードオフがありますが、共通点が 1 つあります。それは、データ レイク向けにクラウド ファースト戦略とサーバーレス SaaS 製品を提供していることです。

ここでは、健全なビジネス モデルを備えた AWS の最新のクラウド ネイティブ戦略が今年どのようになるかを見てみましょう。

パブリッククラウド インフラストラクチャの世界的なマーケットリーダーとして、AWS は定期的に新しいインフラストラクチャ カテゴリを開発し、リリースしています。たとえば、EC2 インスタンスはクラウド時代の幕開けとなり、俊敏で弾力性のあるコンピューティング機能を提供しました。 S3 はオブジェクト ストレージの事実上の業界標準になりました。現在、AWS には何百もの革新的な SaaS サービスがあります。

（３）AWSのデータレイク戦略は、新しい人気の用語「レイクハウス」に基づいている。

周知のとおり、重要な情報は解決策ではありますが、すべての問題に対する答えではありません。さらに重要なのは、これらの問題はすべて、クラウドネイティブでサーバーレスな AWS ソリューションを通じて解決できることです。

これは、パブリック クラウドで提供されるクラウド ネイティブ データ レイクのイメージです。どうやら、GCP や Azure などの他のクラウド プロバイダーのサーバーレス サービスも同じ方向に進んでいるようです。

ただし、ネットワーク遅延、セキュリティ、コストなどの理由により、パブリック クラウドはすべての問題に対する理想的なソリューションではありません。

（4）ハイブリッドクラウドとマルチクラウドが標準になる

近年、多くの新しい革新的なソリューションが、エッジ コンピューティングとオンプレミス インフラストラクチャという別の市場をターゲットにしています。例としては、AWS Local Zones、AWS Outposts、AWS Wavelength などがあります。 AWS は、ソフトウェア カテゴリの提供に新しいインフラストラクチャと革新的なアプローチを設定することが多く、ほとんどのクラウド コンピューティング プロバイダーは非常に類似したサービスを提供しています。多くの場合、AWS がこれをリリースし、他の企業も多かれ少なかれこれを模倣しました。

そうは言っても、各クラウド コンピューティング プロバイダーにはそれぞれ独自の強みがあります。 Google Cloud Platform (GCP) は、Kubernetes や Tensor Flow などのオープンソース サービスにおける業界リーダーとして知られています。 IBM と Oracle は、自社製品向けのサービスとインフラストラクチャの提供に優れています。

ユーザーは、複数のクラウド プロバイダーからのサービスを採用することに対する要求が高まっています。ほとんどの企業は、AWS と、Azure、GCP、IBM、Oracle、Alibaba などの他のプロバイダーを使用したマルチクラウド戦略を採用しています。さまざまなクラウド コンピューティング ベンダーのクラウド サービスを使用する理由は、コスト、データの場所、ベンダー間での災害復旧、ベンダーの独立性、歴史的な理由、クラウド固有の特殊なサービスなど、数多くあります。

幸いなことに、サーバーレス Kafka SaaS Confluent Cloud はすべての主要なクラウドで利用できます。したがって、同様の例を使用して、Azure および GCP クラウド プラットフォームで完全に管理された Kafka エコシステムを使用できます。

2. 「静的データ」から「動的データ」へ

ここまで紹介しましたが、Serverless Kafka に戻りましょう。このような背景があって初めて、動的データの増加とクラウドネイティブおよびサーバーレス サービスの必要性を理解することができます。

まずは重要な情報から始めましょう:

• 業界全体のほとんどのユースケースでは、リアルタイム データは動きの遅いデータよりも優れています。
• 最新のデータ レイクと同じクラウド ネイティブなアプローチがイベント ストリーミングにも必要です。
• イベント ストリーミングとデータ レイク テクノロジーは競合するものではなく、補完し合うものです。

Apache Kafka を活用したイベント駆動型アーキテクチャと移動中のデータの台頭により、企業はリアルタイムのインフラストラクチャとアプリケーションを構築できるようになりました。

（１）Apache Kafka：動的データのデファクトスタンダード

つまり、付加価値のほとんどは、静的データを保存して後で処理する（手遅れになる可能性がある場合）のではなく、関連する動的データを処理することによって生まれます。 Forrester のアナリスト Mike Gualtieri 氏は、次のグラフでこれをわかりやすく説明しています。

Kafka API は、Amazon S3 がオブジェクト ストレージ用であるのと同様に、移動中のデータ用の事実上の標準 API です。

Snowflake や MongoDB などのベンダーは移動データビジネスに参入したいと考えていますが、それは意味がないかもしれません。 Cloudera について上で説明したように、1 つのことに集中してそれをうまく行うことが最善です。そのため、Confluent はクラウド プロバイダーだけでなく、Snowflake や MongoDB ともより緊密に連携しています。

Apache Kafka は、移動中のデータを処理するための、実証済みの拡張可能なオープン ソース フレームワークです。しかし、それはむしろ車のエンジンに似ています。

3. 完全なサーバーレス Kafka プラットフォーム

クラウドコンピューティング、サーバーレス、AWS などについて話すとき、「Amazon MSK を使用できるのに、なぜ AWS 上の Kafka を検討する必要があるのか​​」と自問するかもしれません。この質問に対する答えは、Amazon MSK は PaaS であり、完全に管理されたサーバーレスの Kafka SaaS サービスではないということです。

次の製品のうちどれを購入したいですか?

① 完全にテストされた自動車エンジン（車輪、ブレーキ、ライトなどは除く）

② 完成車（成熟した自動化されたセキュリティ、安全性、メンテナンスを含む）

③ 自動運転車（ハンドル操作、燃料補給、ブレーキ操作、製品リコール等の操作を必要としない安全な自動運転を含む）

Kafka の世界では、Confluent から自動運転車を入手できます。これは販売やマーケティングの売り込みではありません。それは事実です。その他のクラウド コンピューティング製品はすべて、ユーザーに自己管理型の製品を提供しており、企業はエージェントの選択、エラーの修正、パフォーマンス調整などを自ら行う必要があります。 AWS MSK についても同様です。したがって、「フルマネージド」または「サーバーレス」がマーケティング用語なのか事実なのかを理解するために、さまざまな製品を評価することをお勧めします。

データ レイク/レイク ハウス アーキテクチャを構築する場合でも、他のサードパーティ アプリケーションと統合する場合でも、新しいカスタム ビジネス アプリケーションを構築する場合でも、サーバーレスはクラウド コンピューティングの方向性です。

（1）サーバーレス、フルマネージドKafka

企業がパブリック クラウドを導入する場合、運用作業を心配する必要がない、完全に管理されたサーバーレス サービスが最適な選択肢です。代わりに、消費ベースの価格設定とミッションクリティカルなサービス レベル契約 (SLA) を備えた従量課金モデルを使用して、ビジネス上の問題の解決に重点を置き、サポートします。

真に完全に管理されたサーバーレス サービスでは、企業はサーバー インフラストラクチャにアクセスできません。 AWS S3 オブジェクトストレージまたは Snowflake サーバー構成にアクセスすることは可能ですか?そうではありません。そうすると、そのような操作によってクラスターが影響を受けたり、破壊されたりする恐れがあるからです。

（２）セルフマネージドクラウドネイティブKafka

すべての Kafka クラスターがパブリック クラウドで実行されるわけではありません。したがって、一部の Kafka クラスターは、企業の運用保守チーム自身によって管理される必要があります。多くの企業は、特にユースケースがデータ レイクへのデータの取り込みだけではなく、重要なトランザクションまたは分析ワークロードである場合、Kafka の管理に苦労しています。

クラウドネイティブの Kafka は自動化を通じて運用チームをサポートし、企業のリスクと作業負荷を軽減します。たとえば、自己バランス型クラスターはパーティションの再バランス処理を引き継ぎます。自動化されたローリング アップグレードにより、企業はコストとリスクの高い移行プロジェクトを実行する代わりに、新しいバージョンごとにアップグレードできます。コンピューティングとストレージの分離 (階層型ストレージを使用) により、テラバイトまたはペタバイト単位のデータを含む大規模でありながらコスト効率の高い Kafka クラスターがサポートされます。

ちなみに、クラウドネイティブの Kafka クラスターは Kubernetes 上で実行する必要はありません。 Ansible またはプレーン コンテナー/ベア メタル デプロイメントは、企業のデータ センターまたはエッジに Kafka をデプロイするための他の一般的なオプションです。しかし、Kubernetes は、弾力的なスケールによる自動化に関して最高のクラウド ネイティブ エクスペリエンスを提供します。そのため、ベンダーはここ数年、Kubernetes 用の Confluent や Red Hat の Strimzi など、さまざまな Kafka Operator (CRD ベース) を開発してきました。

4. Kafka は単なるメッセージングとデータ取り込み以上のもの

最後に、Kafka は単なるメッセージングとデータ取り込み以上のものであることを明確にすることが重要です。今日のほとんどの Kafka プロジェクトでは、データ統合に Kafka Connect を活用したり、継続的なデータ処理に Kafka Streams/ksql DB を活用したりしています。したがって、Kafka を使用すると、分散型でスケーラブルなインフラストラクチャでデータのメッセージング、ストレージ、統合、および処理をサポートできます。

完全に管理された Kafka プラットフォームは、Kafka だけでなくエコシステム全体を運用します。たとえば、完全に管理されたコネクタを使用すると、S3、Redshift、Lambda などのネイティブ AWS サービスや、MongoDB Atlas、Salesforce、Snowflake などの非 AWS システムとのサーバーレスデータ統合が可能になります。さらに、ksqlDB を使用した完全に管理されたストリーミング分析により、大規模な継続的なデータ処理がサポートされます。

完全な Kafka プラットフォームは、セキュリティ (ロールベースのアクセス制御、暗号化、監査ログ)、データ ガバナンス (スキーマ レジストリ、データ品質、データ カタログ、データ リネージ)、およびグローバルな回復力、柔軟な DevOps 自動化、メトリック、監視などの他の多くの機能を含むエコシステム全体を提供します。

（１）例１：イベントストリーム＋データレイク／レイクハウス

次の例は、さまざまな Confluent コンポーネントと AWS Lakehouse サービスとの統合を使用して、完全なプラットフォームをリアルタイム分析に使用する方法を示しています。

①摂取と処理

スキーマ レジストリを使用して、一貫したデータ構造を持つイベント ストリームをキャプチャし、ksqlDB と軽量 SQL 構文を使用してリアルタイム ETL パイプラインを開発し、Kafka Connect コネクタを使用してリアルタイム ストリームとバッチ処理を統合します。

② 保管と分析

事前に構築された Confluent コネクタを使用してデータを AWS データレイクまたはデータ ウェアハウスにストリーミングし、大量のストリーミング データに対してクエリを実行して、リアルタイムおよびバッチ分析を実行します。

この例は、データ レイクまたはレイク ハウス サービスとイベント ストリーミングがどのように相互に補完できるかを示す優れた例です。すべてのサービスはSaaSです。統合（Kafka Connect を利用）もサーバーレスです。

（２）例２：サーバーレスアプリケーションとマイクロサービスの統合

次の例は、完全なプラットフォームを使用して、既存のアプリケーションとサーバーレスマイクロサービスをさまざまな Confluent および AWS サービスと統合し、新しいアプリケーションを構築する方法を示しています。

①サーバーレス統合

何も管理したり操作したりすることなく、既存のアプリケーションとデータ ストアを繰り返し接続します。 Apache Kafka と Schema Registry により、アプリケーションの互換性が維持されます。 ksqlDB を使用すると、SQL 構文を使用してリアルタイム アプリケーションを開発できます。 Kafka Connect は、Lambda およびデータ ストアとの簡単な統合を提供します。

②AWSサーバーレスプラットフォーム

コンピューティング、データベース、ストレージなどのバックエンド コンポーネントのサーバーのプロビジョニング、保守、管理を停止し、開発チームの俊敏性とイノベーションの向上に集中できるようにします。

5. Kafka はクラウド、オンプレミス、エッジなどあらゆる場所で利用可能

パブリック クラウドはデータ センターの未来です。しかし、すべてをパブリック クラウド インフラストラクチャで実行しない主な理由が 2 つあります。

• ブラウンフィールド アーキテクチャ: 多くの企業は、データ センターに多数のアプリケーションとインフラストラクチャを保有しています。メインフレームと同様に、ハイブリッド クラウド アーキテクチャが唯一の選択肢です。
• エッジユースケース: スマートファクトリーなどの一部のシナリオは、コスト、レイテンシー、セキュリティ、または法的な理由により、パブリッククラウドでは意味をなさない場合があります。

Apache Kafka のマルチクラスターおよびデータセンター間の展開は、例外ではなく標準となっています。災害復旧、分析の集約、クラウド移行、ミッションクリティカルな拡張展開、グローバル Kafka など、複数のシナリオでマルチクラスター ソリューションが必要になります。

さまざまな AWS インフラストラクチャが、パブリッククラウド外での Kafka のデプロイをサポートしています。 Confluent プラットフォームは AWS Outposts で認定されているため、さまざまな AWS ハードウェア製品で実行できます。

（１）例３：Kafkaネイティブクラスタとのハイブリッド統合

ブラウンフィールドの近代化の例を以下に示します。

①接続

事前に構築されたコネクタは、エンタープライズ データ ウェアハウス、データベース、メインフレームなどのオンプレミスの既存のサービスから貴重なデータを継続的に取り込みます。また、必要に応じて双方向の通信も可能です。

②ブリッジング

Hybrid Cloud Streams は、一貫性と信頼性のあるリアルタイムのレプリケーションを可能にし、新しいアプリケーションやファーストパーティおよびサードパーティの SaaS インターフェースとの統合のための最新のイベント駆動型アーキテクチャを構築します。

③近代化

パブリック クラウド インフラストラクチャにより、アプリケーションを市場に投入する際の俊敏性が向上し、総所有コストが削減されるとともに、サーバーの管理ではなく価値を生み出す活動に集中するためのリソースが解放されます。

（２）例４：AWS Wavelength上のクラウドネイティブ5Gインフラストラクチャを使用した低レイテンシーKafka

低遅延データ ストリーミングには、エッジ マシン、デバイス、センサー、スマートフォン、その他のインターフェースの近くで実行されるインフラストラクチャが必要です。 AWS Wavelength は、こ​​れらのシナリオ専用に構築されています。企業はエッジに独自の IT インフラストラクチャをインストールする必要はありません。

次のアーキテクチャは、Confluent、AWS、Verizon によって構築された例を示しています。

（３）ライブデモンストレーション：ハイブリッドクラウドレプリケーション

業界の専門家が、オンプレミスの Kafka クラスターと Confluent Cloud 間のストリーム レプリケーション (ksqlDB を使用したスト​​リーム処理、KafkaConnect (完全に管理された AWS S3 コネクタを使用) を使用したデータ統合など) を示すライブ デモを実施しました。

6. リバース ETL とデータレイクおよび Kafka との関係

おそらく聞いたことがある用語「リバース ETL」について調べてみましょう。この流行語はまだ開発の初期段階にありますが、ますます多くのベンダーの間で注目を集めています。つまり、これは、好みの長期ストレージ (データベース、データ ウェアハウス、データ レイク、レイク ハウス) にデータを保存し、その後、そこからデータを再度取り出して他のビジネス システムに接続することを意味します。

Kafka の世界では、これは Change Data Capture (CDC) と同じです。つまり、リバース ETL は新しいものではありません。 Confluent は、Oracle、MongoDB、Salesforce など、多くの関連システム用の CDC コネクタを提供します。

前述のように、データ ストレージ プロバイダーは動的なデータ サービスを提供しようとします。業界の専門家は、イベント ストリーミング プラットフォームが、エンタープライズ アーキテクチャ内で移動中のデータを処理するのに最適な場所であると考えています。このようにして、すべてのアプリケーションがデータをリアルタイムで使用できるようになります。

7. AWS と Confluent を使用したサーバーレスでクラウドネイティブな Kafka

クラウドファースト戦略は、今日の企業が採用している主要な戦略です。ユースケースが新しいグリーンフィールド プロジェクト、ブラウンフィールド統合アーキテクチャ、またはハイブリッド展開による最新のエッジ シナリオのいずれであっても、Kafka は移動中のデータを処理するための事実上の標準になります。ただし、Kafka はパズルの 1 ピースにすぎず、ほとんどの企業は完全なクラウド ネイティブ サービスを採用することを好みます。

AWS と Confluent は、パブリッククラウド内のサーバーレス Kafka やパブリッククラウド外のクラウドネイティブ Kafka など、あらゆる場所で Kafka 環境をデプロイおよび実行するための、業界全体のさまざまなユースケースで実証された組み合わせです。この記事では Confluent と AWS の関係に焦点を当てていますが、Confluent は大量の移動データを配信するために GCP および Azure とも同様に強力なパートナーシップを結んでいます。

原題: クラウドネイティブ データ レイク アーキテクチャにおけるサーバーレス Kafka、著者: Kai Wähner

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。