为什么驾考宝典选择APISIX Ingress Controller

Kubernetes（略してK8s）の普及に伴い、公式のデフォルトであるNGINX Ingress Controller以外にも選択肢が増え、Apache APISIX Ingress Controllerも多くの企業にとって人気のある選択肢となっています。ますます多くの企業が、Ingress ControllerをAPISIX Ingress Controllerに置き換えつつあります。

背景

武漢ムカン科技有限公司は2011年に設立され、主な製品は「駕考宝典」などの数十の自動車アプリケーションです。10年以上前に設立されて以来、同社は技術のトレンドに従い、2019年にクラウドネイティブを採用し始め、社内のさまざまなプロジェクトがKubernetesに乗り出しました。

しかし当時、K8sが登場したばかりで、トラフィックのエントリーポイントが少なかったため、デフォルトのIngress ControllerであるNGINX Ingress Controllerをほぼ4年間使用していました。しかし、その期間中にNGINX Ingress Controllerがもはや我々のニーズを満たせなくなっていることが明らかになり、新しい選択を迫られました。主流のIngress Controllerを比較した後、Apache APISIXを会社のエントリーゲートウェイとして使用することを決定しました。

NGINX Ingress Controllerの問題点

当社のサービスはHTTPプロトコルとTCPプロトコルを使用しており、NGINX Ingress Controllerを通じてTCPプロキシを設定する方法を正確に知っているのは運用エンジニアだけでした。しかし、運用の人的リソースは限られています。基本的なNGINXの操作と設定の一部を開発チームに任せることが最善であり、それによって運用コストを削減できます。

それ以外にも、以下の問題に直面しました：

一部の設定変更にはリロードが必要；
TCPプロキシの使用コストが高く、あらゆる種類のトラフィックのシナリオをカバーできない；
ルーティングやトラフィック操作はannotationsでしか定義できず、意味的に設定を定義して再利用できない；
リライト、サーキットブレーカー、リクエスト転送などの操作はannotationsを通じて実装される；
管理プラットフォームがなく、運用スタッフはYAMLを通じて操作する必要があり、エラーが発生しやすい；
移植性が低い；
コンテナプラットフォームとの統合に適していない。

これらの理由から、以前のIngress Controllerを新しいものに置き換えることを決定しました。

APISIX Ingress Controllerを選んだ理由

Apache APISIXや他のIngress Controllerを調査し、パフォーマンス、使いやすさ、拡張性、プラットフォーム統合の観点で比較した結果、最終的にAPISIX Ingress ControllerをK8sのトラフィックエントリーゲートウェイとして選択しました。その理由は以下の通りです。

拡張性が良い；
設定のホットリロードをサポート；
高性能；
多くのプラグインを提供；
自社開発のコンテナプラットフォームとの統合のためにCRDをサポート。

全体アーキテクチャ

それでは、ゲートウェイの全体アーキテクチャを見てみましょう。実際のビジネスシナリオでは、ユーザーはまずSLB（Server Load Balancer）を通じてトラフィックを転送し、K8sにトラフィックが入ると、各サービスはAPISIXクラスターを通じて呼び出されます。また、ゲートウェイ側で多くの一般的な機能（カナリアリリース、フロー制御、APIサーキットブレーカー、トラフィックセキュリティ制御、リクエスト/レスポンストラフィック制御など）を実装し、サービスの統一管理、ビジネスの複雑さの軽減、コスト削減を図っています。

アーキテクチャ図

デプロイ方法

当社のビジネスは異なるクラウドプラットフォーム（Huawei Cloud、Tencent Cloud、Alibaba Cloud）にデプロイされており、APISIX Ingress ControllerがサポートするHelm Chartを通じて迅速にビジネスをオンラインにすることができます。APISIX Ingress Controllerを使用する際、改善できる機能があれば、PRを提出してコミュニティの機能更新とイテレーションを支援しています。実際のデプロイプロセスでは、ビジネスの特性に応じていくつかの設定をカスタマイズしました。例えば：

K8sを通じてNameSpaceを作成し、APISIXとAPISIX Ingress Controllerを異なるNameSpaceにデプロイし、製品ラインとサービスの重要度に応じてトラフィックを分離；
APISIXのinitContainerでLinux TCPカーネルパラメータを最適化；
製品ラインとサービスの重要度に応じてトラフィックを分離する必要があるため、K8sのClassName情報を設定。

異なる製品ラインと重要度でトラフィックを分離することで、ソフトウェア障害による損失を最小限に抑えることができます。

CRDを使用した自社開発コンテナプラットフォームとの統合

APISIX Ingress Controllerは現在多くのCRDリソースをサポートしているため、CRDリソースを使用してAPISIX Ingress Controllerを自社のコンテナプラットフォームと統合できます。ただし、APISIXはJava Clientを提供していないため、K8sが提供するコード生成ツールを使用してModelを生成し、CustomObjectApiを使用してCRDを管理する必要があります。ApisixRouteオブジェクトはコンテナプラットフォームアプリケーションと関連付けられ、コアオブジェクトと構造化されているため、運用スタッフとプロジェクトマネージャーの両方がコンテナプラットフォームで操作できます。

アプリケーションシナリオ

認証

Apache APISIXを使用する前は、Istioゲートウェイに基づいて認証を実装していましたが、Apache APISIXに移行後はforward-authプラグインを使用することを選択しました。このプラグインは、認証と認可のロジックを外部の認証サービスに巧妙に移動します。ユーザーのリクエストはゲートウェイを通じて認証サービスに転送され、認証サービスが20x以外のステータスで応答すると、元のリクエストがブロックされ、結果が置き換えられます。これにより、認証が失敗した場合にカスタムエラーレポートを返したり、ユーザーを認証ページにリダイレクトしたりすることが可能です。

クライアントがアプリケーションにリクエストを送信すると、まずAPISIXのforward-authプラグインによって処理され、forward-authを通じて外部の認証サービスにリクエストが転送され、結果が最終的にAPISIXゲートウェイに返されます。認証が成功すると、クライアントはサービスを正常にリクエストできます。認証が失敗すると、エラーコードが返されます。

フロー制御

会社のビジネス特性上、毎年5～6ヶ月のピークトラフィックがあります。リクエストが多すぎると、手動でキャパシティを拡張する必要がありますが、リクエストが滞留すると、拡張後にサービスが起動できない可能性があり、全リンクの雪崩的な崩壊を引き起こす可能性があるため、クラスターのフローと速度を制限する必要があります。

そのため、APISIXのlimit-conn、limit-req、limit-countプラグインを使用してリクエストを制限し、雪崩的な崩壊を防ぎます。プラグインを変更することでフローと速度を制限するのが容易で、APISIXのホットリロードメカニズムにより、プラグインを設定する際に再起動する必要がないため、すぐに有効になります。トラフィックを制御することで、悪意のある攻撃を防ぎ、システムのセキュリティを保護することもできます。また、K8sプラットフォームでHPA（Horizontal Pod Autoscaler）を実装し、トラフィック量が多すぎたり少なすぎたりすると自動的にスケールアップ/ダウンし、APISIXのフローとレート制限プラグインを使用して大規模な崩壊を防ぎます。

可観測性

可観測性に関しては、現在SkyWalkingを通じてプラットフォーム全体のトラフィックを監視しています。APISIXのSkyWalkingプラグインにより、既存のSkyWalkingプラットフォームと直接インターフェースでき、SkyWalking UIを使用してパフォーマンスを消費しているリンクノードを簡単に確認できます。また、監視ポイントがゲートウェイ側に位置しているため、ユーザーに近く、時間のかかるポイントを簡単にチェックできます。

kafka-loggerプラグインを使用すると、APISIXによって生成されたアクセスログとエラーログをApache Kafkaクラスターに直接書き込むことができます。この利点により、APISIXクラスターはステートレスで水平にスケーリングでき、ディスクのフォーマット、ログのローテーション、その他の操作を行う必要がありません。ログがローカルに保存されている場合、追加の操作が必要であり、迅速なスケーリングを実現できません。ログをApache Kafkaクラスターに送信することで、ログをリアルタイムで分析し、分析結果に基づいてシステムを改善および最適化することもできます。

結論

APISIX Ingress Controllerはまだリリースされたばかりで、多くのアプリケーションシナリオはまだありません。我々は引き続きアプリケーションシナリオを掘り下げ、コミュニティにさらなる使用例を提供していきます。

ますます多くのチームがApache APISIX Ingress Controllerを本番環境で使用しています。もしあなたもAPISIX Ingress Controllerを使用しているなら、ぜひコミュニティで使用例を共有してください。