Apache APISIXの高度な安定性とフォールトトレランスのメカニズム

APIゲートウェイを選択する際、機能性、スケーラビリティ、セキュリティに加えて、安定性とフォールトトレランスが重要な要素となります。2019年にApache APISIXを設計した際、内部および外部のトラフィックリクエストを処理する際に重大な生産インシデントが発生する可能性を考慮し、安定性とフォールトトレランスが不可欠であると判断されました。

研究者の方々に包括的な理解を提供するため、Apache APISIXの主要な安定性とフォールトトレランスの機能について詳しく見ていきましょう。

コントロールプレーンとデータプレーンの分離

Apache APISIXは、コントロールプレーン（例: etcd、Admin API）とステートレスなデータプレーン（例: APIゲートウェイはオンデマンドでスケーリング可能）を分離したアーキテクチャを採用しています。これらは互いに依存関係がありません。つまり、コントロールプレーンに異常が発生した場合（ネットワーク中断や異常終了など）、データプレーンは正常に動作を続け、新しいトラフィックリクエストを処理できます。この分離により、APISIXの高可用性が確保されます。

データ同期メカニズム

データプレーンとコントロールプレーンの間には、効率的なデータ同期メカニズムが存在します。データプレーンはetcdのWatcherとして機能し、etcdからデータ変更の通知を受け取ります。これにより、設定やルールを適宜更新します。そのため、管理者がAdmin APIを介してetcdに設定を書き込むと、データプレーンは迅速に変更通知を受け取り、設定をメモリに保存します。このメカニズムにより、リクエストごとにetcdから設定を取得する必要がなくなり、システムの負荷が軽減されます。ただし、コントロールプレーンに異常が発生している際にデータプレーンインスタンスを再起動すると、メモリ内の設定が失われる可能性があるため、注意が必要です。

コントロールプレーンの異常

ネットワーク通信の中断

APIゲートウェイとetcd間のネットワークが中断した場合、Admin APIを介してetcdに書き込まれた設定はゲートウェイに到達しません。しかし、ゲートウェイは以前に保存されたメモリ内の設定を使用して新しいトラフィックリクエストを処理し続けるため、etcdとの接続が失われたことによる異常終了を防ぎます。ゲートウェイとetcdの接続が回復すると、ゲートウェイは最新の設定を受け取り、正常に動作を再開します。

etcdの異常クラッシュ

etcdが異常クラッシュした場合、管理者はAdmin APIを介して設定を書き込むことができなくなります。しかし、これはゲートウェイの動作に影響を与えず、ゲートウェイは引き続き動作してトラフィックリクエストを処理します。このシナリオでは、ゲートウェイの動作はネットワーク中断後の状況と同様です。

マルチノードデプロイメントとロードバランシング

高可用性を確保するため、複数のゲートウェイインスタンスをデプロイし、それらの間にロードバランサー（例: AWS Load BalancerやF5）を設定することを推奨します。これらのロードバランサーにはヘルスチェックメカニズムがあり、ゲートウェイインスタンスの健全性を評価します。ゲートウェイインスタンスが故障した場合、ロードバランサーは迅速にそのインスタンスをサービスから外し、新しいゲートウェイノードを追加できます。このマルチノードデプロイメントとロードバランシング戦略により、単一ノードの故障によるビジネス中断を防ぐことができます。

結論

まとめると、Apache APISIXは、コントロールプレーンとデータプレーンが切断された場合でも、優れた安定性とフォールトトレランスを示します。その分離アーキテクチャ、効率的なデータ同期メカニズム、およびマルチノードデプロイメント戦略により、例外的な状況でも高可用性が確保されます。Apache APISIXの設計は、さまざまなネットワークやコンポーネントの異常を考慮しており、企業レベルのトラフィックリクエストを処理する際に非常に優れたパフォーマンスを発揮します。