为什么热门住房平台贝壳选择Apache APISIX

こんにちは、私は王輝と申します。中国の住宅取引とサービスを提供するリーディングなオンライン・オフライン統合プラットフォームであるKe Holdings（貝殻）で、APIゲートウェイシステムの開発を担当しています。貝殻では、本番システムのAPIゲートウェイとしてApache APISIXを使用しています。データ駆動型企業として、毎日数百万の本番トラフィックがAPIゲートウェイを通過しますが、Apache APISIXは安定した優れたパフォーマンスを提供しています。最近、Apache APISIXがApacheインキュベーターに参加したことを機に、私たちが最初にApache APISIXを選んだ理由と、使用中の経験を共有したいと思います。

KongかApache APISIXか

ゲートウェイの技術要件として、まずゲートウェイは優れたパフォーマンスと大量のトラフィックをサポートする能力を持っている必要があります。さらに、安定性も重要で、エラーレートはゼロであるべきです。

ベンダー選定の原則は、他のオープンソースプロジェクトを基に、またはそこから学び、より安定したバージョンを再構築して、より多くのトラフィックに対応することです。長所と短所を評価した後、上司とこのアイデアを話し合い、プロジェクトを開始することに決めました。最初に思い浮かんだ選択肢は、もう一つの有名なオープンソースゲートウェイであるKongでした。

Kongの公式サイトを閲覧し、関連記事を読んだ後、Kongはユーザーのニーズのほとんどを満たすことができるため、適切な選択肢だと考えました。パフォーマンスも非常に安定しています。すぐにコードをgit cloneし、読み始めました。しかし、数日間調査した後もかなり混乱していました。Kongがこれほど大きなコードベースを持っている理由は、多くの機能を提供する必要があるからだと推測しました。

突然、いくつかの疑問が頭をよぎりました。Kongを完全に理解するのにどれくらい時間がかかるのか？すべての要件を満たすプロジェクトを構築するのにどれくらい時間がかかるのか？Kongが提供するすべての機能が必要なのか？

数日前、APIゲートウェイApache APISIXのバージョン0.5がリリースされました。学習の姿勢で、このオープンソースプロジェクトをすぐに見てみると、驚いたことに、API分野の専門家である王元生と温明が共同で開発したものでした。これらの専門家の推薦に基づいて、この製品を拒否することはできませんでした。

オープンソースプロジェクトが誕生して間もないため、Apache APISIXがサポートする機能はまだ限られています。しかし、動的ロードバランシング、サーキットブレーカー、認証、レートリミットなど、すべての基本的な機能はすでに実装されています。一方で、比較的小さなコードベースは学習コストを低減します。Kongと比較して、Apache APISIXの勝利を宣言できます。Apache APISIXは、不要な機能について心配することなく、私の初期の機能計画を満たすことができるため、現在の状況により適しています。

しかし、最も重要な問題は、Apache APISIXのパフォーマンスがオープンソースとしての時間が限られているため、短所になる可能性があることです。同じテスト環境でKongと比較したストレステストの結果、Apache APISIXは最終的にKongを打ち負かしました。しかし、Kongははるかに重く、複雑であるため、Kongにとっては公平ではありません。一方で、私のユースケースでは違いはありません。なぜなら、必要なすべての機能がApache APISIXに提供されているからです。Apache APISIXのパフォーマンステストレポートによると、シングルコアCPUで24k QPSに達し、レイテンシはわずか0.7ミリ秒です。

まとめると、私は以下の理由でApache APISIXを選びました：

• プロジェクトのすべてのニーズを満たすことを前提に、Apache APISIXの学習コストが低い
• Kongはコードベースが大きく、コードのメンテナンスが難しい
• Apache APISIXの作者はOpenRestyコミュニティでより活発で、コードの品質が高い
• 最も重要なことは、作者と直接コミュニケーションを取ることで、迅速に質問を解決できること

公式サイトで提供されているAPISIXの理由は以下の図に示されています：

Apache APISIXが提供できる機能

• ホットアップデートとホットプラグイン
• 動的ロードバランシング
• アクティブおよびパッシブヘルスチェック
• サーキットブレーカー
• 認証
• レートリミッター
• gRPCプロトコル変換
• 動的TCP/UDP、gRPC、WebSocket、MQTTブローカー
• ダッシュボード
• 禁止リストと許可リスト
• サーバーレス

Apache APISIXはほぼ10バージョンがリリースされており、ここにリストされているものよりもはるかに多くの機能をサポートしています。アーキテクチャ図はビジネスの状況に応じて描かれています：

APISIXを統合したストーリー

数日間コードを読んだ後、Apache APISIXについて基本的な理解を得ましたが、疑問が浮かびました：私はこれまでオープンソースプロジェクトを開発したことがありません。どうやってそれを達成できるのか？ローカルに3つの異なるブランチを作成しました。1つは上流のオープンソースリポジトリを指すApache APISIXブランチ、もう1つは通常のビジネスイテレーションに使用されるdevブランチ、最後のmainブランチはオンラインアップグレードに使用されます。

2週間の努力の後、私のプロジェクトはいくつかの基本的な構造を持ちました。結果を検証する時が来ました。それがストレステスト段階の始まりです。サービスはTencent Cloudの8コア32GBメモリのサーバーにデプロイされ、上流は通常のクラウド本番環境であるため、過度にテストすることはできません。パフォーマンスレポートは以下の通りです：

パフォーマンスレポートの概要： インターフェースの時間消費が47％減少し、エラーは発生せず、安定性が向上しました。TPSのピーク値は82％増加し、エラーは発生せず、安定性が向上しました。

開発環境が整い、クラウドデプロイの研究を開始しました。Apache APISIXは多くのインストール方法をサポートしています：Docker、RPMパッケージ、Luarocks、ソースコード。悪いニュースは、クラウド環境には何もインストールすることが許可されておらず、ソースコードは固定されたルートパスにしか置くことができないことです。そのため、OpenResty 1.15.8に基づいて開発されているため、多くのApache APISIX機能はサポートされません。どうすればいいのか？コードリポジトリにコンパイル済みファイルが生成され、指定されたディレクトリでコンパイルする必要があり、PCREの静的バインディングを使用することはできません。これには1-2日かかりました。最後に、グレーリリースを調整し、数週間でトラフィックを2％から全量に増やしました。幸い、最終的にはすべてが成功しました。

数週間の監視の後、オンラインサービスは比較的安定しています。Apache APISIX 0.5の多くの機能はAPIインターフェース呼び出しを通じて実装する必要があります。リクエストパラメータは構文エラーが発生しやすく、直感的で便利なページはありません。それに加えて、私たちのビジネスシナリオでは、上流サービスのプローブ機能が必要です。ちょうどその時、Apache APISIXバージョン0.7がリリースされ、バージョン0.7はコンソールと上流サービスの探索をサポートしており、まさに私たちが必要としているものでした。なんて素晴らしいニュースでしょう！私たちはアップグレードしなければなりません！

Apache APISIXブランチは0.7に簡単にアップグレードできますが、コードをどのようにマージするのか？これらの2つのバージョン間のコード変更は非常に大きいです。まずマージを試みましたが、衝突が多すぎ、私たちは非常に危険なペースにあります。衝突を解決する標準的な方法は非現実的で、多くの隠れたバグを引き起こす可能性があります。効率的な解決策はあるのか？オンラインで検索し、ショートカット方法を見つけました：git checkout –oursとgit checkout –theirs（使用したことがない場合は検索してください）、そして数分でAPISIX 0.5から0.7へのアップグレードを完了しました。もちろん、APISIXコードの堅牢性にも感謝すべきで、ビジネスプラグインを追加するだけで、結合は必要ありません。

Apache APISIX 0.7バージョンはコンソールを提供しているため、JSONを手動で入力する必要はありません。すぐにヘルスチェックを確認し、最初は問題なく、上流サービスの状態を感知できました。しかし、上流サービスのログを確認すると、数回の再起動後、ヘルスチェックの頻度が増加し続けていることがわかりました。ヘルスチェックにバグがあるかもしれないと推測しました。ソースコードを読んだ後、各ルーターのチェッカーがグローバルに一意でないことがわかりました。代わりに、すべてのワーカーにチェッカーがあります。作成されたすべてのワーカーに同じ名前を使用することで、この問題を解決できます。小さな修正でも、ホットフィックスPRが必要です。

オンラインビジネスのAPISIXを0.7にアップグレードし、サービスのリソース使用状況を監視しました。結局のところ、これは大きなバージョン変更であり、最初の数時間は何も感じませんでした。前回の0.5変更と同様です。仕事が終わったらもう一度見ます。メモリ使用量が正しくないようです。0.5バージョンは比較的安定していましたが、0.7バージョンはメモリリークがあるようです。メモリ使用量が非常にゆっくりと増加しているため、一晩中監視することにしました。翌日、監視データを比較し、メモリリークがあると判断し、迅速に以前のバージョンにロールバックしました。すべてが終わった後、この問題について元生にフィードバックを提供しました。私が説明したシナリオに基づいて、ストレステストを通じて問題を見つけました。それはラディックスツリーの問題でした。元生が新しいバージョンのラディックスツリーをリリースした後、同じ問題は二度と発生しませんでした。

プロジェクトを再起動した後、Apache APISIX 0.7バージョンはまだ時々驚きを与えてくれます。Apache APISIX 0.5バージョンで使用されていたルーティング依存はlibr3でしたが、Apache APISIX 0.7はラディックスツリーを使用しており、パフォーマンスが向上しています。CPU使用率とメモリ使用率のパーセンテージが両方とも低下しました。Apache APISIX 0.5では、CPU使用率は1-10％、メモリは0.1％でした。Apache APISIX 0.7では、CPU使用率は1-2％に減少し、メモリは0.1％未満で、素晴らしいです。

将来の計画

Apache APISIXは2ヶ月間起動しており、失敗もエラーもありません。これは始まりに過ぎず、将来はサービスプロバイダーにさらに多くの能力を示すために、もっと多くのことができます。ゲートウェイはリバースプロキシを提供し、サービス安定性を確保するために機能を開発する時間がないチームを支援します。これには、レートリミット、サーキットブレーカー、監視、アクセスプラットフォームなどのサービスが含まれます。

最後に、元生と温明にこのような素晴らしい製品を提供してくれたこと、そしてApache APISIXコミュニティに貢献してくれた反復機能に感謝します。現在、ゲートウェイの日次トラフィックは1億を超え、パフォーマンスの問題はありません。お時間とご注目に感謝します！