Kubernetesゲートウェイで429エラーを解決し、サーバーコストを30%節約しました。

先月、チームはほぼ崩壊しました。ユーザーアドレス解決リクエストの13%は429を拒否した。バックグラウンドは半日をチェックして、各マイクロサービスに個別に割り当てられたフロー制限ルールがあまりにも死んでいることがわかりました。ロジスティクスクエリモジュールのトラフィックが3倍になり、他の空のリソースは使用することができません。

以前は、Kubernetesゲートウェイは大企業が使用する複雑なコンポーネントだと思っていましたが、穴を踏むまでオンラインに強制され、1週間もかからず、効果は予想以上に良かったです。

Kubernetes Gatewayとは？

簡単に言えば、Kubernetesクラスタ全体の統一トラフィックエントリであり、すべての外部リクエストが最初にそこに来て、対応するバックエンドサービスに転送されます。オープンソースバージョンの単一インスタンスは、毎秒12，000リクエストを運ぶことができ、小さなチームはパフォーマンスのボトルネックに苦しむ必要はありません。

3つの利点があります。

最初の最も直感的なもの：フロー制限ルールは、サービスごとに個別に設定する必要がなくなりました。7つのマイクロサービスの制限フローしきい値を変更する前に、問題の1つを変更する必要があります。ゲートウェイ層で直接動的フロー制限を行うと、空のサーバーリソースは自動的にトラフィックの高いモジュールに傾斜することができます。このクリスマスは私たちの429エラーを直接0に下げました。

2つ目はコスト削減です。ピークを運ぶために、我々は2つ以上の冗長サーバーを持つ3つのコアサービスを与える前に、リソース利用率のほとんどはわずか20%でしたが、ゲートウェイは自動的にロードバランシングを行うことができ、我々は直接6つのサーバーを縮小し、毎月のクラウドコストを30%削減しました。

3つ目は、バックエンドがクロスドメインと認証の共通ロジックを繰り返し変更しないことです。各新しいサービスがオンラインになる前に、バックエンドはJWT検証コードを書く必要があり、今ではゲートウェイ層に直接ルールを設定し、バックエンド3人は毎週少なくとも半日ビジネスコードを書くことができます。

利点だけを聞かないでください、この2つの穴はしっかりと踏んでいます。

最初のピットはデフォルトのタイムアウト設定の太ピットです。我々はアドレス解決要求のタイムアウトの5%を発見した最初の日、ゲートウェイのデフォルトのタイムアウト時間が30秒であることを発見するために半日をチェックしたが、我々のアドレス解決サービス自体は40秒を実行する必要があり、ルールを変更した後、すぐに復元され、オンラインになる前に、自分のビジネスインターフェイスのタイムアウトしきい値をチェックする必要があります。

2つ目の穴は、最初からすべての機能をスタックしないことです。最初は、ログ、ストリーム制限、WAF、グレースケールのすべての機能を一度にリリースしたいと思っていましたが、結果として設定が間違って書き込み、クラスタ全体のエントリが20分間壊れました。その後、ルーティングとストリーム制限のみを開き、3日間実行して安定し、ゆっくりと他の機能を追加し、問題はありません。

使うべきか？私たちの判断基準はシンプルです。

適切な場合：

• マイクロサービスの数はすでに5つを超えており、共通の設定を変更するたびに数回変更する必要があります。
• トラフィックのピークが頻繁に発生し、異なるサービス間のリソースの柔軟なスケジューリングができない
• バックエンドチームは5人未満で、共通ロジックを繰り返し書く時間を無駄にしたくない

状況を混乱させない：

• 2つのマイクロサービスがあり、トラフィックは年間を通じて安定しており、NGINX転送に問題はありません。
• チーム全体がKubernetesの基礎を理解していない、新しい技術に追いつくためにハードに行かないでください。

初めての小さなチームのための2つのアドバイス。

選択をもつれずに、小規模チームはオープンソースのAPISIXまたはKongを直接使用し、完全なサポートドキュメントを使用し、問題を検索する基本的なソリューションがあり、商用版を購入する必要はなく、無料版の機能は完全に十分です。

24時間実行する前にトラフィックの10%をカットし、タイムアウトがあるかどうかに焦点を当て、要求が誤って傍受され、問題なくフルカットし、すべてのトラフィックを一度にしないでください。

最後に、よくある質問：私たちの3つのバックエンドは、誰もゲートウェイを研究したことがなく、公式ドキュメントに2日かかりました。本当にあなたが思うほど複雑ではありません。