高度にスケーラブルなクラウドネイティブアプリケーションを構築するための 5 つのヒント

マハジャン王子著

ノアが編集

制作 | 51CTO テクノロジースタック (WeChat ID: blog)

クラウド ネイティブ設計を通じて Apache Kafka エンジンのパフォーマンス、可用性、コスト効率を向上させるにはどうすればよいでしょうか?この中心的なトピックに焦点を当てて、この記事の著者は、Kora と呼ばれるイベント ストリーム処理プラットフォームの再設計プロセスと主要な技術革新を紹介します。この記事ではまず、マルチテナントのサポート、容易なスケーラビリティ、データ駆動型管理、顧客間のセキュリティ分離、迅速なイノベーションのサポートなど、成功するクラウドネイティブ プラットフォームに不可欠な機能を指摘します。 Kora は、既存の Kafka プロトコルとの互換性を維持し、マルチクラウド環境全体で一貫したエクスペリエンスを提供しながら、これらのニーズを満たすように設計されています。

Apache Kafka サービスのコアをホストするエンジンの再構築に着手したとき、クラウドネイティブ プラットフォームを成功させるにはいくつかの独自の要件を満たす必要があることがわかっていました。これらのシステムは、最初からマルチテナントであり、何千もの顧客にサービスを提供できるように簡単に拡張でき、主に人間のオペレーターではなくデータ駆動型ソフトウェアによって管理される必要があります。また、ワークロードが予測できない場合でもエンジニアが迅速に革新を続けられる環境で、顧客全体にわたって強力な分離とセキュリティを確保する必要があります。

昨年、私たちは Kafka エンジンの再設計を発表しました。私たちが設計し実装したものの多くは、データベースやストレージ システムなどの大規模な分散クラウド システムを構築する他のチームにも適用できます。私たちは、私たちの経験をより広いコミュニティと共有し、それが他のプロジェクトに取り組んでいる人々の役に立つことを願っています。

1. Kafka エンジンの再設計における重要な考慮事項

当社の大まかな目標は、お客様のクラウドベースのシステムの目標と似ている可能性があります。つまり、パフォーマンスと回復力を向上させ、当社とお客様のコスト効率を高め、複数のパブリック クラウドにわたって一貫したエクスペリエンスを提供することです。 Kafka プロトコルの現在のバージョンとの 100% の互換性を維持するという追加要件もありました。

再設計された Kafka エンジン「Kora」は、AWS、Google Cloud、Azure の 70 を超えるリージョンで数万のクラスターが稼働するイベント ストリーム処理プラットフォームです。すぐにこの規模に到達できないかもしれませんが、以下に説明するテクニックの多くは依然として適用できます。

新しい Kora デザインに実装された 5 つの主要な革新をご紹介します。これらについてさらに詳しく知りたい場合は、2023 International Conference on Very Large Databases (VLDB) で Best Industry Paper Award を受賞したこのトピックに関するホワイト ペーパーを公開しています。

2. スケーラビリティと分離性のために論理「ユニット」を使用する

可用性が高く、水平方向にスケーラブルなシステムを構築するには、拡張可能で構成可能なビルディング ブロックを使用して構築されたアーキテクチャが必要です。具体的には、スケーラブルなシステムによって実行される作業は、システムのサイズに応じて直線的に増加する必要があります。元の Kafka アーキテクチャは、負荷の多くの側面がシステムのサイズに応じて非線形に増加するため、この基準を満たしていませんでした。

たとえば、クラスターのサイズが大きくなると、通常、すべてのクライアントがすべてのブローカーと通信する必要があるため、接続数は 2 乗的に増加します。同様に、各ブローカーには通常、他のすべてのブローカーのフォロワーが存在するため、レプリケーションのオーバーヘッドも 2 乗的に増加します。最終結果として、プロキシを追加すると、それによってもたらされる追加のコンピューティング/ストレージ能力に比べてオーバーヘッドが不釣り合いに増加します。

2 番目の課題は、テナント間の分離を確保することです。特に、パフォーマンスの低いテナントが 1 つあると、クラスター内の他のすべてのテナントのパフォーマンスと可用性に悪影響を与える可能性があります。効果的な制限とスロットルを使用しても、問題となる負荷パターンが常に存在する可能性があります。クライアントが正常に動作している場合でも、ノードのストレージが劣化している可能性があります。クラスター全体にランダムに分散され、すべてのテナントと、場合によってはすべてのアプリケーションに影響します。

私たちは、セルと呼ばれる論理的な構成要素を使用してこれらの課題に対処します。クラスターを、アベイラビリティーゾーンにまたがるセルのセットに分割します。テナントは単一のセルに分離されます。つまり、そのテナントが所有する各パーティションのレプリカは、そのセル内のブローカー全体に分散されます。これは、複製が細胞内のエージェントに制限されることも意味します。セルにエージェントを追加すると、セル レベルで以前と同じ問題が発生しますが、オーバーヘッドを追加せずにクラスター内に新しいセルを作成するオプションが追加されました。さらに、これにより、騒々しい入居者に対処する方法も得られます。テナントのパーティションを独立したユニットに移動できます。

このソリューションの有効性を測定するために、24 個のブローカーと 6 個のプロキシ ユニットからなる実験的なクラスターをセットアップしました (完全な構成の詳細については、ホワイト ペーパーを参照してください)。ベンチマークを実行したところ、クラスター負荷 (Kafka クラスター負荷を測定するために設計したカスタム メトリック) は、セル使用時に 53%、セル未使用時に 73% でした。

3. 階層化アーキテクチャにより、さまざまなストレージタイプの使用を最適化

アーキテクチャを階層化してさまざまなストレージ タイプの使用を最適化することで、コストを削減しながらパフォーマンスと信頼性を向上させます。これは、主に 2 つの側面、つまりオブジェクト ストレージを使用してコールド データを保存し、インスタンス ストレージではなくブロック ストレージを使用してより頻繁にアクセスされるデータを保存するという、コンピューティングとストレージを分離する方法に起因しています。

この階層化アーキテクチャにより、回復力を高めることができ、ホット データのみを再割り当てする必要がある場合にパーティションの再割り当てがはるかに簡単になります。インスタンス ストレージの代わりに EBS ボリュームを使用すると、ストレージ ボリュームのライフサイクルが関連付けられた仮想マシンのライフサイクルから切り離されるため、耐久性も向上します。

最も重要なのは、階層化によってコストとパフォーマンスを大幅に改善できることです。オブジェクト ストレージはコールド データを保存するためのより手頃で信頼性の高いオプションであるため、コストが削減されます。パフォーマンスが向上するのは、データが階層化されると、階層化されていない場合はコストがかかるホット データを高性能ストレージ ボリュームに配置できるためです。

4. 抽象化を使用してマルチクラウドエクスペリエンスを統合する

複数のクラウドで運用する予定のサービスにとって、統一された一貫性のあるクロスクラウドの顧客エクスペリエンスを提供することは重要ですが、いくつかの点で困難です。クラウド サービスは複雑であり、標準に準拠している場合でも、異なるクラウドやインスタンス間では違いが存在します。同様のクラウド サービスでも、インスタンスの種類、インスタンスの可用性、課金モデルは微妙ではあるが重要な点で異なる場合があります。たとえば、Azure Block Storage ではディスク スループット/IOPS を個別に構成できないため、IOPS をスケーリングするには大容量ディスクを構成する必要があります。対照的に、AWS と GCP ではこれらの変数を個別に調整できます。

多くの SaaS プロバイダーは、この複雑さを避けており、一貫したパフォーマンスを実現するために必要な構成の詳細について顧客が心配することになります。明らかにこれは理想的ではないので、Kora ではこれらの違いを解消するための抽象化を開発しました。

クライアントが実装の詳細に煩わされることなく、より高レベルのアプリケーション プロパティに集中できるようにする 3 つの抽象化を導入しました。これらの抽象化により、サービスが大幅に簡素化され、クライアントが独自に回答する必要のある質問が制限されます。

5. パフォーマンス低下に対抗するための自動緩和ループ

障害処理は信頼性にとって重要です。クラウドであっても、クラウド プロバイダーの停止、ソフトウェアのバグ、ディスクの破損、構成エラーなどの理由により、障害は避けられません。これらは完全な障害の場合も部分的な障害の場合もありますが、いずれの場合も、パフォーマンスやシステム アクセスに影響を与えないように、迅速に解決する必要があります。

残念ながら、大規模なクラウド プラットフォームを運用している場合、これらの障害を手動で検出して処理することは不可能です。オペレーターの時間がかかりすぎるため、サービス レベル契約を維持するのに十分な速さで問題が解決されない可能性があります。

これを解決するために、私たちはインフラストラクチャの劣化のあらゆるケースを処理するソリューションを構築しました。具体的には、クラスターからメトリックを収集し、それを使用してコンポーネントに障害が発生したかどうか、およびアクションが必要かどうかを判断する劣化検出コンポーネントを含むフィードバック ループを構築しました。これにより、オペレーターの手動介入なしに、毎週何百もの劣化を自動的に処理できるようになります。

複数のフィードバック ループを実装してエージェントのパフォーマンスを追跡し、必要に応じてアクションを実行します。問題が発見されると、特定のエージェントのヘルス状態がフラグ付けされ、各状態に対して適切な緩和戦略が適用されます。これら 3 つのフィードバック ループは、それぞれローカル ディスクの問題、外部接続の問題、プロキシの劣化の問題を解決します。

• モニタリング: 外部の観点から各エージェントのパフォーマンスを追跡する方法。追跡のために頻繁に検出を実施しています。
• 集計: 場合によっては、他のプロキシと比較して劣化が認識できることを確認するために指標を集計します。
• React: レプリケーション プロトコルからブローカーを除外したり、レプリケーション プロトコルからリーダーシップを削除したりするための Kafka 固有のメカニズム。

実際、当社の自動緩和機能は、3 大クラウド プロバイダー全体で毎月何千もの部分的なパフォーマンス低下を検出し、自動的に緩和することで、貴重なオペレーターの時間を節約し、顧客への影響を最小限に抑えています。

6. パフォーマンスと効率性を考慮したステートフルサービスのバランス

あらゆるステートフル サービスにおいてサーバー間で負荷を分散することは、顧客が体験するサービスの品質に直接影響する難しい問題です。負荷分散が不均一な場合、最も混雑しているサーバーが提供する待ち時間とスループットによって顧客が制限されることになります。ステートフル サービスには通常、一連のキーがあり、クライアントがシステムから最大のパフォーマンスと最低のコストを得られるよう、これらのキーの分散をバランスよく調整して、サーバー全体の負荷が均等に分散されるようにする必要があります。

たとえば、Kafka が実行するステートフル ブローカーは、さまざまなブローカーへのパーティションとそのレプリカの分散のバランスをとる役割を担います。クライアントのアクティビティに応じて、これらのパーティションの負荷は予期しない形で急増したり減少したりする可能性があります。これには、効率と使用率を最大化するためにパーティションをどのように配置するかを決定するための一連のメトリックとヒューリスティックが必要です。これは、複数のブローカーからの一連のメトリックを追跡し、バックグラウンドで継続的に動作してパーティションを再分配するバランシング サービスを通じて行われます。

配分の再調整は慎重に行う必要があります。過度に積極的な再バランス調整は、再割り当てによって発生する余分な作業により、パフォーマンスを低下させ、コストを増加させる可能性があります。再バランス調整が遅すぎると、不均衡が修正される前にシステムが著しく劣化する可能性があります。さまざまなワークロードに対して適切なレベルの応答性に到達するには、多くのヒューリスティックを実験する必要がありました。

効果的なバランス調整の影響は非常に大きくなります。あるお客様では、再バランスを有効にした後、負荷が約 25% 削減されたことがわかりました。同様に、別の顧客も、再バランス調整によりレイテンシが大幅に減少したことを確認しました。

7. 適切に設計されたクラウドネイティブサービスの利点

新しいコードを使用する場合でも、Kafka などの既存のオープン ソース ソフトウェアを使用する場合でも、組織用のクラウド ネイティブ インフラストラクチャを構築する場合は、この記事で説明する手法が、パフォーマンス、可用性、コスト効率の目標を達成するのに役立つことを願っています。

Kora のパフォーマンスをテストするために、同じハードウェア上で小規模な実験を実施し、Kora と当社の完全なクラウド プラットフォームおよびオープンソースの Kafka を比較しました。 Kora は優れた回復力を提供し、スケーリングが 30 倍高速であることがわかりました。当社が自社で管理する顧客や他のクラウド サービスの障害率よりも 10 倍以上高い可用性。セルフマネージド Kafka よりもレイテンシが大幅に低くなります。 Kafka はオープンソースのデータストリーミングシステムを実行するための最良の選択肢であり続けていますが、クラウドネイティブなエクスペリエンスを求める人にとっては Kora は優れた選択肢です。

参考リンク: https://www.infoworld.com/article/3715426/5-tips-for-building-highly-scalable-cloud-native-apps.html