自社で構築したAPIゲートウェイにより、第三者サービスの利用コストを38%削減することができましたが、地域間の適応に関する問題に直面しました。
先週、私たちの東南アジア向けEコマースツールチームはQ1の技術コストのレビューを行いました。支払いインターフェースを担当する同僚はほとんど驚きのあまり飛び上がりそうになりました。以前使用していた第三者ゲートウェイを自社開発のものに切り替えたところ、月間のAPI呼び出しコストが38％も削減されました。しかし、大規模なプロモーション前のグレーステスト中に、シンガポールのノードでユーザーの支払い成功率が突然6ポイント低下しました。原因を調べた結果、ゲートウェイの地域間のフェイルオーバールールが適切に設定されていなかったことがわかりました。
まずは理解しましょう：自作のゲートウェイとは何か？
簡単に言うと、自分でトラフィックの入口処理を行うプログラムを作成し、すべての外部APIリクエストや第三者のコールバック、サービス間の呼び出しをこのプログラムを通して処理することになります。これにより、以前購入した第三者のゲートウェイサービスの代わりになります。現在使っているバージョンは、4台の2コア4Gの海外のノードサーバー上で動作しており、1台あたり毎秒1200回のリクエストに対応でき、私たちの1日あたりの180万回の支払い処理や商品同期のニーズを完全にカバーしています。
あなたが得られる3つの実際の利点
- まず、コストを大幅に削減できることです。以前使用していた第三者のゲートウェイは呼び出し回数に応じて料金が発生し、月額で2100ドルかかっていましたが、今では自社で構築したサーバーと監視システムを使用しており、月額のコストは1300ドル未満です。さらに、段階的な料金増加の心配もありません。
- 次に、ルールは完全に自分たちで決めることができます。以前は第三者のゲートウェイによる制限が統一されていましたが、大規模なセールの期間中には支払いインターフェースの制限枠を一時的に増やす必要があり、そのたびに3営業日かかるチケット申請が必要でした。しかし今では、バックエンドで設定を変更するだけで10秒で効果が発生します。
- 最後に、データは第三者を通さずに処理します。私たちが電子商取引ツールを開発しているため、多くのユーザーからの支払いのコールバックを受け取る必要がありますが、以前はすべてのリクエストが第三者サービスプロバイダーのネットワークを経由していました。今では、すべての機密データが自社のサーバー内で処理されており、コンプライアンスに関するコストが大幅に削減されました。
急いで作る必要はありません。まずは私たちがこれまでに遭遇した問題や失敗を見てみましょう。
最初の問題は、地域を越えたネットワーク適応の問題でした。当初、ゲートウェイのメインノードをシンガポールに設置していましたが、マレーシアのサイトを開設する際にトラフィックを直接そちらに切り替えました。その結果、ローカルユーザーのリクエストがシンガポールを経由してから再び戻ってくるため、ネットワーク遅延が200msも増加しました。多くのユーザーがその遅延に耐えられずに支払いページを閉じてしまいました。マレーシアのエッジノードを設置するのに1週間かかりました。
二つ目の問題は、セキュリティルールの不備でした。以前は第三者のゲートウェイがデフォルトでDDoS攻撃や悪意のあるリクエストのブロック機能を備えていましたが、自分たちでシステムを構築する際にこの機能を追加するのを忘れてしまいました。その結果、サービスを開始して3日目にクローラーによる無効なリクエストが20万件も送り込まれ、在庫管理のAPIがダウンしてしまうところでした。
第三の問題は、運用コストが予想を上回っていることです。以前は第三者のゲートウェイに問題が発生すると直接カスタマーサービスに連絡していましたが、今では3人のバックエンド担当者が交代で夜勤をしてゲートウェイの監視を行っています。先月だけで、ゲートウェイの障害対応に15％の作業時間が費やされました。
どのようなチームが組み合わせに適しているのか、そうでないチームには時間を無駄にしないでください。
もしもあなたのチームが1日あたりに100万回以上のAPI呼び出しを行っている場合、または大量の機密データを処理する必要がある場合、あるいは第三者のゲートウェイのリミットやチケット処理プロセスにうんざりしているなら、自社でゲートウェイを構築することは間違いなく投資に値します。
しかし、もしあなたのチームにバックエンドが2つ以下しかなかったり、ビジネスがまだ迅速な試行錯誤の段階にあって、インターフェースのルールが毎週変わっているのであれば、そこに時間を費やす必要は本当にありません。まずは第三者のゲートウェイを使って対応し、ビジネスが安定したらその後で変更しても遅くありません。
初めて組み立てる方への3つの実践的なアドバイス
- まずは単一のシナリオから始めましょう。最初から全てを一括で置き換えるのではなく、まずは支払いインターフェースのトラフィックだけを自社のゲートウェイに切り替えてみましょう。2週間問題なく運用できたら、その後徐々に他のインターフェースも移行していきます。問題が発生しても、支払いシナリオだけに影響が及び、サイト全体がダウンすることはありません。
- 地域を越えたストレステストを必ず行ってください。特に海外ビジネスを行っている場合は、ローカルでのテストだけでリリースしないでください。ターゲット市場のテストサーバーで24時間にわたるストレステストを実施し、遅延やパケットロスの問題がないか確認してください。
- 監視パネルは絶対に省略しないでください。少なくともリクエスト数、成功率、遅延という3つの主要な指標をしっかりとチェックし、アラートの閾値を設定しておきましょう。ユーザーからの苦情が来てからではなく、ゲートウェイがダウンしていることに気づくようにしてください。
よくある小さな問題
質問：GoやRustで書く必要があるのでしょうか？
いいえ、私たちの第一版はNode.jsで書かれていますが、ピーク時の処理にも十分対応できます。あなたのチームがどの言語に精通しているかに応じて、その言語を使ってください。パフォーマンスのボトルネックが出たらその時に変更しても遅くありません。
質問：クラウドプロバイダーのゲートウェイと比べて、どちらが良いですか？
クラウドベンダーのゲートウェイは第三者のものよりも柔軟ですが、自分で構築したものほどの自由度はありません。もし特定のクラウドに縛られたくない場合は、自分で構築する方がお得です。
役に立ちましたか？