HAProxyを介したA / Bテストを使用して支払いサービスを変更する

Avitoでは、世界中のその他の分類の開発を厳密に追跡しています。 そしてもちろん、請求などの複雑なシステムで作業するベストプラクティスに興味があります。 今日、私はグループNaspers （Avitoもその一部です）の同僚であるDubizzleのソフトウェアエンジニアであるM. Rafay Alemの投稿の翻訳を公開しています。 これは、OLXグループの一部であるUAEの主要なクラシファイドWebサイトで、45か国で最大のオンライン市場のネットワークであり、19億を超える訪問、370億のページビュー、5400万の月間広告があります。 このトピックは、自分の支払いサービスの作成と開発に携わるすべての人を対象にしています。

さまざまな実用的な理由で新しい支払いサービスプロバイダーに切り替えるには、既存のWebサービスを書き換える必要があると想像してください。 最初の考えは、おそらく古いゲートウェイを新しいゲートウェイに完全に置き換えて起動することです。 しかし、これは、特に、サービスレベル契約、サービスバンクとの契約、リスクや詐欺を検出するためのスクリプトなどを備えた支払いゲートウェイを使用する場合、少し単純です。 これらの要因により、運用、収益、顧客維持、そして最終的にはビジネスの成功に関して、移行プロセスのリスクが高まります。 この投稿では、支払いゲートウェイを変更する際のリスクを軽減するために取ったアプローチと、それがなぜそれほど重要なのかを検討します。

Dubizzleチェックアウトページ

それはすべて古い支払いサービスから始まります...

私たちの古い支払いシステムはPython 2で書かれており、古い支払いゲートウェイと密接に関連しています。 最初に問題を取り上げたとき、新しい支払いゲートウェイを既存のフロー、URL、 Python Bottleに簡単に統合できると考えました。 最初のプロトタイプの作業を開始すると、これら2つの支払いゲートウェイのAPIフローが完全に異なるため、スパゲッティコードを作成していることに気付きました。 古い支払いゲートウェイのAPIは異なりました。RedisとGeventは 、ユーザーと支払いの処理を最適化するために大幅に使用され、新しいゲートウェイのAPIでこれを繰り返す必要はまったくありませんでした。

古い支払いゲートウェイの支払いサービス

A / Bテストは優れていますが、簡単です。

A / Bテストは、製品開発における意思決定にとって非常に重要です。 Dubizzleでは、このようなテストは、原則として、ユーザーが遭遇することに焦点を合わせています。ページ間の遷移、ページ上のコンポーネントとその場所、機能です。 ただし、相互依存度の高い基本システムをテストする場合は、状況が複雑になります。

プロトタイプの作業中に、新しいゲートウェイを同じユーザーマッピングとストリームに何らかの方法で統合できたとしても、Optimizelyなどのツールを使用して実行したいA / Bテストを実行しないでください。 そして、ここに理由があります。

• クレジットカード情報をキャプチャできる外部のJavaScriptコードを支払いサービスで使用することは、大きなセキュリティリスクです。
• Optimizelyアプローチを使用するには、すべてのトランザクションマッピングからのリクエストがCookieを使用して目的の支払いゲートウェイに送信されるようにするために、Webサービスの表示ごとにA / Bテストロジックを実装する必要があります。 これには、ディスプレイごとに次のコードが必要であり、見栄えがよくありません。

if cookie == 'OLD': use old payment gateway API else: use new payment gateway API 

• 同じ名前空間（たとえば、Redis）を使用して2つの異なる支払いゲートウェイをデバッグする場合、UUIDの生成と登録には必然的に問題があり、それらを即座に解決する必要があります。

ユーザーが制御グループA（古い支払いゲートウェイと対話するWebサービス）になった場合、このWebサービスは、このユーザーの支払いプロセスが、開始されたのと同じ支払いゲートウェイで継続することを確認する必要があります。 そのため、Webサービスは古い支払いゲートウェイでトランザクションを開始して、新しい支払いゲートウェイでトランザクションを完了しようとするべきではありません。 この問題は、OptimizelyおよびHAProxyでサポートされているスティッキーセッションを使用して解決できます。

2つの支払いサービスの物語

直面している問題を理解し始めたとき、新しいゲートウェイと統合された新しい支払いサービスを開発し、A / Bテスト（50/50）を使用してパフォーマンスを比較することにしました。 A / Bテストは、少なくとも次の要件を満たしている必要があります。

• 新しいサービスでの支払いカードデータ入力フォームの外観は、操作に違反しないように古いフォームと正確に一致する必要があります。 この場合、操作とは「Pay」ボタンをクリックすることです。
• 内部サーバータスクやAPI呼び出しによって、古いサービスと比較して新しいサービスのトランザクションエラーの数が増えることはありません。 つまり、ユーザープロセスのほとんどは、基本的に古いゲートウェイを使用するのと同じ方法で処理する必要があります。

新しい支払いゲートウェイと統合された支払いサービス

HAProxyを使用したA / Bテスト

Optimizelyを除き、テストにはHAProxyを使用することにしました。 OSIネットワークモデルの第4および第7レベルの強力なロードバランサーであり、幅広い機能を備えています。 これらの機能の1つは、第7レベルでCookieを使用してリクエストをバックエンドにバインドする機能です。
3つのバックエンド用にHAProxyを構成しました。

• メインバックエンド（メイン）
• 古いサービスのバックエンド
• 新しいサービスバックエンド

以下は、HAProxyバックエンドの例です。

 backend main balance roundrobin cookie SERVERID insert indirect nocache maxlife 2h option forwardfor option http-server-close option http-pretend-keepalive timeout queue 5000 timeout connect 5000 timeout server 50000 server old-service-old-pg old-service.eu-west-1.elasticbeanstalk.com:80 weight 128 cookie old_v1 check server new-service-new-pg new-service.eu-west-1.elasticbeanstalk.com:80 weight 128 cookie new_v1 check backend old_service option forwardfor option http-server-close option http-pretend-keepalive timeout queue 5000 timeout connect 5000 timeout server 50000 server old-service-old-pg-static old-service.eu-west-1.elasticbeanstalk.com:80 check backend new_service option forwardfor option http-server-close option http-pretend-keepalive timeout queue 5000 timeout connect 5000 timeout server 50000 server new-service-new-pg-static new-service.eu-west-1.elasticbeanstalk.com:80 check 

おそらくあなたは考えた：なぜ静的バックエンドが必要なのか？ これは、フロントエンドHAProxyに到達すると明らかになるので、最初にメインバックエンドを見てみましょう。

old-service-old-pgとnew-service-new-pgの負荷を分散するために、Weighted Round Robin（WRR）を選択しました。 これは、A / Bテストでは意味があります。A/ Bテストでは、グループAとBの間でトラフィックを分割する必要があります。 これを実現するには、HAProxy cookieディレクティブを使用します。 トランザクションを開始するユーザーが2時間以内に完了すると仮定して、2時間後にCookieが削除され、WRRの結果に基づいて新しいCookieが作成されるようにHAProxyを構成しました。

これにより、2つの非常に重要な結果が得られました。

• A / Bテストで重みを調整し、セッションまたはユーザーフローを中断することなく2時間すべてのユーザーを対象にすることができました。
• A / Bテスト全体で、ユーザーが両方のサービスでトランザクションを試行する可能性が増加しました。 これにより、あるゲートウェイが別のゲートウェイによって以前に受け入れられていたクレジットカードの受け入れを拒否したという事実に関連する問題を特定することができました。 いくつかのカスケードシステムが異なる大陸に関係しているときに、すべてが大規模に崩壊し始める方法を見て驚きました。

私たちのスキームには、おそらくまだ気づいていないと思われる小さな脆弱性があります。 次のスキームを検討してください。

HAProxyを介した支払いプロセス

ユーザーは、Cookieを受け取ってから約45分後に古い支払いサービスでトランザクションを開始します。 その後、1時間59分で3-Dセキュアバンクページに移動し、2時間後に支払い成功ページのURLにリダイレクトされます。 HAProxyは2時間maxlife cookieに設定されているため、HAProxyはセッションcookieをキャンセルし、支払い成功ページのURLにリダイレクトした後に新しいcookieを挿入しようとします。 幸運でない場合、WRRは新しいセッションを、古いサービスによって開始された成功した支払いページへのリダイレクトを処理する方法を知らない新しい支払いサービスに関連付けることができます。

私たちのケースでは、トランザクションを開始したユーザーは通常2時間以内に完了することを経験から知っていたため、この問題を無視することにしました。 しかし、 maxlifeパラメーターをたとえば1分に設定すると、どのような問題が発生するか想像してみてください。

mainだけでなくold_serviceとnew_serviceを使用した理由について話をold_serviceましょう。 HAProxyは通常、すべてのアクセス制御リスト（ACL）を処理するfrontendプロキシを構成します。 この場合、次のようになりました。

 frontend all bind *:80 timeout client 50000 default_backend main acl is_old_webhook path_reg ^\/webhook-old.* acl is_refund path_reg ^\/refund-endpoint.* acl is_new_webhook path_reg ^\/webhook-new.* use_backend old_service if is_old_webhook use_backend new_service if is_refund use_backend new_service if is_new_webhook 

これらのwebhookとエンドポイントは、構成で確認でき、外部ゲートウェイからの要求を処理するために必要な特定のルールを表します。 古いサービスと新しいサービスは相互の支払いゲートウェイと相互作用できないため、WRRを使用して負荷を分散すると、ほとんどすべてのリクエストで404番目または400番目のエラーが発生することになります。 さらに、これらの要求は支払いゲートウェイから送信されるため、さまざまなルールをカバーするシナリオが含まれていないため、永続化する必要はありません（すべての要求はコード200を受信するとすぐに処理されます）。

この問題を解決するのに最適な場所はバランサー自体であるため、静的バックエンドold_serviceおよびnew_service介して対応するアプリケーションサーバーに要求のフローを向けるようにACLを構成しました。 つまり、支払いゲートウェイとHAProxyの間には一種の会話があり、適切なアプリケーションサーバーにリクエストをリダイレクトする必要があります。

支払いゲートウェイ：こんにちは。古い支払いゲートウェイから内部リクエストがあり、支払いを正常に受け取ったと報告しています。
HAProxy：こんにちは、知っています。 old_serviceドアを通過して、ターゲットアプリケーションにアクセスします。
対象アプリケーション：こんにちは、私はあなたと一緒にいる方法を知っています。 このユーザーの注文を有効にしましょう。 このために、コード200を提供します。

要求フロー監視

すべての問題が解決したので、このような複雑なA / Bテストの実装をテストする方法を自問する必要があります。

HAProxyは、複雑なシステムをデバッグするための非常に詳細なログを保持しています。 A / Bテストのいくつかの例を見てみましょう。

 Feb 22 09:16:39 ip-1-xxx haproxy[9046]: 1.xac:2459 [22/Feb/2017:09:16:25.623] all main/new-service-new-pg 13783/0/0/101/13884 200 8241 - - --NI 22/22/0/1/0 0/0 "GET /step1/1725770 HTTP/1.1" Feb 22 09:18:23 ip-1-xxx haproxy[9046]: 1.xac:2629 [22/Feb/2017:09:18:12.291] all main/new-service-new-pg 7223/0/1/3881/11105 200 327 - - --VU 19/19/0/1/0 0/0 "POST /step2/1725770 HTTP/1.1" Feb 22 09:19:30 ip-1-xxy haproxy[9402]: 1.xbz:59238 [22/Feb/2017:09:19:26.761] all main/new-service-new-pg 3714/0/1/45/3760 200 4711 - - --VN 34/34/0/1/0 0/0 "GET /success-redirect/1725770 HTTP/1.1" Feb 22 09:16:51 ip-1-xxx haproxy[9046]: 1.xac:2459 [22/Feb/2017:09:16:49.146] all new_service/new-service-new-pg-static 2047/0/0/5/2052 200 226 - - ---- 29/29/0/1/0 0/0 "POST /webhook-new HTTP/1.1" 

1つの注文識別子に対する各リクエストのNI、VU、およびVNフラグに注意してください。 これらのフラグにより​​、クライアント、サーバー、およびHAProxyがどのようにCookieを処理したかを理解できます。 これは、テストとデバッグの際に注意する必要がある最も重要な情報です。
HAProxyのドキュメントを引用します 。

-： Cookieバインディングは無効です。 これは、A / Bテストを実施しない場合です。
NI： Cookieはクライアントによって設定されず、応答で生成されました。 これは通常、各ユーザーからの最初のリクエストで発生し、実際のユーザーの数を計算できます。 WRRはユーザーグループを定義します。
VU：クライアントが提供するCookie。 最終訪問日が古いため、応答として更新されたCookieが提供されます。 日付がまったくない場合、または日付が指定されているが、maxidleパラメーターが設定されておらず、Cookieを無期限に設定できる場合も可能です。
VN：クライアントが提供するCookie。 クライアントが既にCookieを持っている場合、ほとんどの応答で発生します。 そのため、HAProxyはユーザーの現在のグループを見つけ、対応するバックエンドにそれを向けます。

HAProxyがnew-service-new-pgサーバーを選択してCookieを設定すると、このユーザーからの以降のすべてのリクエストはmainバックエンドを介してnew-service-new-pg送信されることに注意してください。

要求がACLの1つと一致する場合、HAProxyはCookieを設定せずに要求を送信します。 また、ボットからのHTTP呼び出しによってA / Bテスト結果が歪まないようにします。

A / Bテストアーキテクチャ

A / Bテストアーキテクチャ

DNSとエッジノードは、すべてのマイクロサービスに共通です。 A / Bテストのすべての魔法は、トラフィックがより高いロードバランサー（HAProxyも）を通過した後に始まります。

おわりに

このソリューションは可能な限り最善の方法で機能しましたが、Cookieバインディングを使用するだけでなく、より困難なバランスを取るための多くの方法があります。 Shopifyは、 ブログでNginxとOpenRestyを使用してソリューションを非常によく説明しています。

翻訳者から

ここでの翻訳と出版に親切に同意してくれた著者に感謝します。 あなたはツイッターで直接彼に連絡することができます： mrafayaleem 。 そのようなサービスを開発したい場合は、My Circleの空室をご覧ください。Avitoでは、課金開発者を含む負荷の高いシステムの開発者が必要です。

そのようなタスクを処理する必要がありましたか？ コメントで議論しましょう。