Enabling high availability for Klaw with NGINXの翻訳です。
2023年7月13日
NGINXでKlawの高可用性を実現する
Klawの高可用性機能を発表し、単一障害点を排除し、ダウンタイムを最小またはゼロにします。
Aivenのオープンソースプロジェクトの1つであるKlawは、多くの組織でApache Kafka®のACLとパーミッションの管理・統制に利用されています。Klawがフォールトトレラントで、シームレスかつ効率的にリクエストに対応できるようにすることが重要です。
いくつかの組織では、Klawが10～100のKafkaクラスタを管理しており、アプリケーションがビジネスクリティカルであることは明らかで、ダウンタイムの重大性を理解する必要があります。このことから、Klawは複数の複製インスタンスで利用できるようにし、フェイルオーバーモードまたはアクティブ/アクティブで実行する必要があります。
なぜKlawを高可用性にするのか？
高可用性とは何かという話に入る前に、なぜKlawにとって高可用性が重要なのかを理解しましょう。KlawはKafkaクラスタの管理と監視に不可欠であるため、潜在的な障害に対する耐性を確保することが最も重要です。ダウンタイムは、わずかな不便から収益の損失や評判の低下まで、悲惨な結果をもたらす可能性があります。Klawの高可用性はこれらの重要な問題に対処します：
- ダウンタイムの最小化： **単一障害点を排除し、システムの冗長性を確保することで、KlawのHAはダウンタイムを最小化または排除します。
- スケーラビリティ： **ワークロードが増加するにつれて、KlawはHA構成のおかげで、増加するユーザーベースに対応し、より多くのリクエストを処理することができます。
- データの可用性： **コンポーネントに障害が発生した場合でも、データが常に利用可能であることを保証することが重要です。HAは、データが異なるサーバー間で複製されることを保証し、データ損失から保護します。
- サービス継続性： **災害やシステム障害が発生した場合でも、HAはサービスの中断がなく、業務が滞りなく継続されることを保証します。
- 一貫した可用性と信頼性は、顧客満足度と顧客維持に不可欠なユーザーエクスペリエンスを向上させます。
高可用性でのKlawの展開
バージョン2.4.0以前では、Klawの内部キャッシュ管理方法のアーキテクチャ上の制限により、Klawを高可用性セットアップでデプロイすることができませんでした。このため、Klawは本番環境でもどのような環境でも1つのインスタンスとしてしかデプロイできませんでした。
Klawは、膨大なデータベースの呼び出しを避けるため、ほとんどの認証関連データをキャッシュに保存します。これにより、待ち時間が効果的に短縮され、ユーザーはアプリケーションから即座に応答できるようになります。
これに対処するため、Klawの開発チームは、高可用性モードで展開されているKlawの利用可能なインスタンスをすべて検出し、それらのインスタンスのキャッシュをリセットする機能を導入しました。
上記の例では、Klawユーザーがインスタンス1に新しいチームを追加（適用）します。Klawはこの情報をキャッシュに保存し、他のインスタンスで新しいキャッシュリセットリクエストをトリガーして、ローカルキャッシュを更新します。
Klawはユーザー、チーム、ロール、パーミッション、クラスタ、環境、トピック情報からなるメタデータに依存しています。Klawのユーザーは、毎日50人から500人以上のユーザーがアプリケーションにアクセスし、トピック、サブスクリプション、スキーマ、コネクターを要求します。データベースのクエリーですべてのリクエストを処理するのは効率的ではなく、データベースにも優しくありません。そこで、Klawはすべての情報を内部メモリーに保存し、変更が要求されるたびにリセットします。これによりKlawはシームレスに動作し、リアルタイムのデータをクエリーしながらユーザーのリクエストに失敗することなく応えることができます。
高可用性の利点
NGINXをロードバランサーとしてKlawを高可用性モードで使用するための具体的な実装パターンについては、Klawブログをご覧ください。
高可用性には以下の利点があります：
- ロードバランシング:**システムがより高いワークロードと膨大なトラフィックを処理できるようにします。例えば、50,000のKafkaトピックとその上のACLが何度も往復するようなリクエストでは、パフォーマンスを維持するためにロードバランシングが必要です。
- クラスタ内のサーバーに障害が発生した場合、別のクラスタにある複製されたサーバーが、最初に障害が発生したサーバーに割り当てられたワークロードをシームレスに引き継ぐことができます。この冗長性により、セカンダリ・コンポーネントが障害発生時にプライマリ・コンポーネントの責任を引き受けるフェイルオーバーが可能になると同時に、パフォーマンスへの悪影響を最小限に抑えることができます。
- 最小接続負荷分散： **最小接続負荷分散は、一部のリクエストの完了に時間がかかる状況において、アプリケーション・インスタンスの負荷をより公平に制御することができます。
詳細はこちら
ApacheKafkaのACLと設定を外部管理するAivenのオープンソースプロジェクトであるKlawについては、KlawプロジェクトのウェブサイトまたはGitHub組織で詳しく知ることができます。Klawに関して何か問題がありましたら、お気軽にGitHub issueを開くか、コミュニティフォーラムを通じてご連絡ください。
Klawチームは、AivenのOpen Source Programs Officeが保守とスポンサーを支援している多くのオープンソースメンテナチームの1つです。Aivenは、PostgreSQL®バックアップサービスのPGHoardやApache Kafka® RESTプロキシのKarapaceにも取り組んでいます。
KlawやAivenの他のオープンソースプロジェクトを試してみたい場合は、Aiven for Apache Kafka®の無料トライアルにサインアップすることをお勧めします。