クラウドネイティブゲートウェイを使用することでトラフィック処理コストを38%削減できましたが、ブラックフライデーの際にヨーロッパの生鮮食品配送ネットワークをほとんど壊してしまうところでした。

先週のブラックフライデーの大セールの振り返り会が終わったばかりですが、私たち3人で構成されるヨーロッパの生鮮食品配送のバックエンドチームはまだ冷や汗をかいています。予約受付日には、冷蔵配送のリクエストの17%がエラーで直接返却され、ユーザーからの苦情の件数が3倍に増えてしまい、3ヶ月間準備してきた年間大セールを台無しにしそうになりました。

問題は、2年間使用してきた従来のAPIゲートウェイにありました。アドレス解決とコールドチェーン予約の2つのコアインターフェースに統一されたリミット設定をしていたため、ブラックフライデーの日にアドレス解決のリクエストが急増し、ゲートウェイの割り当てられたリソースをすべて使い果たしてしまい、その後の予約リクエストが全く処理されませんでした。以前は、ゲートウェイの交換は大規模なチームでなければ必要ないと思っていましたが、この失敗を経験して初めて、クラウドネイティブなゲートウェイの方が小規模なチームにとってコストパフォーマンスの面でより良い選択肢になる可能性があることに気づきました。

クラウドネイティブゲートウェイとは一体何でしょうか？

一言で言えば、これはK8sクラスター内でトラフィックを処理するためのエントリーポイントであり、別途サーバーを借りてデプロイする必要はありません。ルーティングルールやトラフィック制御戦略だけを管理してください。残りのリソースの柔軟性や運用管理のアップグレードはすべてクラウドプロバイダーが担当します。現在使っているバージョンでは、単一のインスタンスで毎秒2万件のリクエストに対応できます。事前に容量計画を立てる必要はありません。

交換した後に得た3つの実際の収益

予約販売日に障害が発生した後、3日間をかけてクラウドネイティブゲートウェイに切り替えました。ブラックフライデーの本戦当日には、もう一度もリミット制御による誤動作は発生しませんでした。さらに、予想を上回る3つの利点もありました：

• コストは直接削減されました。以前は、従来のゲートウェイを実行するために2つの4コア8Gサーバーを別々にレンタルしました。プラス1つの運用とメンテナンスは、バージョンアップグレードを行うために月に8時間かかり、月額1200ユーロのコストを計算しました。直接で38％のトラフィック処理コストを削減しました。
• 限流戦略がついに理解できました：以前のゲートウェイではグローバルなインターフェースごとに限流閾値を設定するしかありませんでしたが、今では異なるビジネスシナリオに応じて個別のルールを設定できるようになりました。例えば、アドレス解決インターフェースには1秒あたり最大5000回のリクエストしか許可されず、たとえそれが過剰に利用されても、後続の支払いや予約の処理に影響はありません。
• HTTPSのハンドシェイクにかかる時間が直接半分になりました。以前は、私たちのSSL証明書が自社のゲートウェイサーバーに保存されていたため、ヨーロッパの異なる地域のユーザーにとってハンドシェイクの遅延が200msに達することがありました。しかし、今ではクラウドプロバイダーが証明書をエッジノードにキャッシュしているため、ほとんどのリクエストでハンドシェイクの遅延を80ms以下に抑えることができます。

急がずに車に乗ってください。これら2つの落とし穴はもう私たちが踏み越えたところです。

クラウドネイティブなゲートウェイには利点だけがあるわけではなく、移行する過程で2つほど問題に直面し、やり直さなければならないところもありました：

最初の問題は、クールスタートの遅延でした。初日のテストを終えた後、10分間リクエストがない状態が続いた後、最初のリクエストの応答時間が突然300ミリ秒を超えてしまいました。後でわかったのですが、クラウドプロバイダーのエラスティックインスタンスはオンデマンドで起動されるため、コアインターフェースには最小インスタンスを予約する必要があります。そうしないと、空いている時に突然トラフィックが増加するとタイムアウトしやすくなります。

セカンドに、カスタムプラグインの制限があります。以前は自分たちでリクエストの署名検証を行うプラグインを書いて、従来のゲートウェイで動かしていましたが、切り替えたときにクラウドネイティブゲートウェイがWebAssembly形式のプラグインのみをサポートしていることがわかりました。コードを修正して対応するのに2日間かかりました。もし多くのカスタムロジックを使用している場合は、まず製造元のプラグインがサポートしている範囲をよく確認することをお勧めします。

結局、交換するべきかどうか？この2つの基準を直接見てみましょう。

あなたが変更すべき状況：

• チームの規模が5人未満でバックエンドエンジニアがいないため、専門の運用保守スタッフがおらず、ゲートウェイサーバーのメンテナンスやアップグレードに時間を費やしたくありません。
• トラフィックの変動が大きく、例えば大規模なセールの時には通常の3〜10倍になります。そのため、普段は使われないサーバーを事前に大量に借りておいて無駄にお金を使いたくありません。

あなたが変えるべきではない状況：

• コンプライアンス要件が非常に厳しく、すべてのトラフィックは自分が管理できるサーバーを経由しなければならず、クラウドプロバイダーのパブリックノードを使用することはできません。
• あなたのゲートウェイには非常に多くのカスタムされた特殊なロジックが含まれており、市場に出回っているクラウドネイティブなゲートウェイではサポートされていません。自分で改修するコストは、ゲートウェイを自分でメンテナンスするコストよりも高くなります。

初めての方への3つのアドバイス

• 全量を切り替える必要はありません。まずはトラフィックの10%をクラウドネイティブゲートウェイに移して1週間運用し、問題がないことを確認してから徐々に切り替えていきましょう。私たちも最初はアドレス解決インターフェースから切り替えを始めました。問題がなかったので、その後に全量のトラフィックを移行しました。
• 核心インターフェースには最低限のインスタンス数を設定する必要があります。その少しのコストを節約してはいけません。現在、コールドチェーンの予約と支払いの2つの核心インターフェースにそれぞれ常駐インスタンスを2つずつ確保しており、もう冷起動によるタイムアウトの問題は発生していません。
• 最高級のバージョンを購入する必要はありません。ほとんどの中小企業のトラフィック規模には、ベーシック版の機能で十分です。私たちが現在使用しているベーシック版では、QPSが2万を超えない限り追加料金は発生しません。

最後にチーム内でよく質問される問題に答えます：クラウドプロバイダーに縛られてしまうのではないかということですか？

私たちの判断は以下の通りです：10人未満のバックエンドチームにとって、クラウドベンダーとの連携による効率向上は、自分ですべてのコンポーネントを一から構築するコストをはるかに上回ります。。本当にクラウドプロバイダーを変更する必要がある日が来たら、その時には移行作業を行うのに十分なエネルギーがあるでしょう。今はそのことに囚われずにいましょう。