Visa決済基盤にProxyサーバーを導入したお話

こんにちは。Kyash Paymentチームの佐藤です。KyashではVisa、QUICPayの決済基盤の開発をしています。

Kyash PaymentチームではApple Payのリリースや3Dセキュアといったユーザー様にバリューを届けるリリースをさせていただいていますが、その裏では内部で見えない改善を積み重ねています。今回はその中でも大きめな改善であったVisa決済基盤にProxyサーバーを導入したお話をさせていただこうと思います。

KyashのVisa決済処理サーバーが抱えていた問題

リリースの精神的負荷が高い

新しい機能を提供するには当然リリース作業を行うのですがKyashのVisaの決済処理サーバーであるFront-end processor(以下 fep)ではリリース時にある問題を抱えていました。

まず前提としてVisaのサーバーとfepの通信はTCPでコネクションを常時張り続けており、この接続が切れると決済ができずアラートが上がります。そしてこのアラートが上がるのはKyash内部だけではなくいくつかの外部の関係各所でも上がるようになっています。

そのためリリース時のフローに関係各所に前もってリリースするという連絡を入れていました。全体のリリースフローはこのような流れです。

  1. 外部の関係各所にリリース予定日、内容の事前連絡
  2. 当日リリース作業
  3. 確認作業
  4. 外部の関係各所へリリース完了連絡

リリースのたびに連絡をしなければならないというのはかなりストレスであり、リリースすることに躊躇しがちになります。いざリリースせねばという時になると大きな変更のリリースになりがちでした。

解決へのアプローチ

この問題を解決する手段の一つがProxyの導入です。fepとVisaのサーバーの間にProxyを導入することによってリリース時にfepが止まったとしても、Visaのサーバーとの接続を永続化するため、外部の関係各所への連絡が不要になります。

f:id:ar_ciel_sa2:20210701133424p:plain
fepが瞬断してもproxyとVisaのサーバーと接続は維持される

念のため補足させていただきますと、fep自体は複数台で冗長化されており、1台がリリースで止まっていても、他のfepが稼働中なので決済に影響が出ることはありません。リリースは1台ずつ行われるため、サービスは継続されたままリリースできます。

KyashのQUICPay決済処理サーバーの方では後発であったため、すでにProxyが導入されているのでこれは実績のある手段でした。

Proxyサーバーによる決済セッションの永続化

導入したProxyサーバーについて説明します。 Proxyサーバーといえばnginx、HAProxy、EnvoyなどOSSがいくつかありますが、ここで使用しているProxyは内製です。内製という選択をしたのはVisaとの接続に特化するためです。

このProxyサーバーの責務は前述したとおり接続の永続化です。よって、提供する機能は特に難しいものではありません。Proxyがやっていることは以下の通りです。

  • Visaのサーバーへ接続する
  • fepからの接続をlistenする
  • Visaのサーバーから送信された電文をfepへ渡す
  • fepから送信された返信電文をVisaのサーバーへ渡す

f:id:ar_ciel_sa2:20210701133512p:plain
接続時のイメージ

f:id:ar_ciel_sa2:20210701133528p:plain
電文のやり取りのイメージ

fepのリリース時にはfepとProxy間の通信が瞬断しますが、その最中にProxyが電文を受け付けたとしても、Proxyの中で受け付けた電文を保持するキューを持っています。このキューにより世代交代されたfepが立ち上がるまで間わずかな遅延はあるものの、決済には影響なくリリース作業を行うことができます。

またProxyでは電文の解析はしていません。ログ出力のためにメッセージタイプを取得するくらいで、どんな電文でもfepへ素通りさせています。それは電文の解析を行う責務はfepが担当しているからです。

このようにProxyはVisaの電文やりとりに特化しつつ、非常にシンプルな挙動と作りになっています。

Proxy導入の成果

Proxyをリリースしてから以下のメリットを得ることができました。

  • リリース時のオペレーションを削減
    • 外部への連絡が不要になったのでデリバリーへのスピードが向上した
    • 外部への連絡は3日以上前には連絡をする必要があったのでいつリリースしようかといったプランニングが不要になった
  • 改修内容がたまることがなくなった
    • 都度都度リリースすることができるようになった
    • すぐに出したいちょっとした改修でもすぐにリリースできるようになった
    • 様々な改修が混ざったリリースがなくなり、なにか起きてもすぐにどのリリースが問題か特定できるようになった

得られたことは地味かつ当たり前じゃんと言えるようなものではありますが、実際に1月から現在までを通してみるとかなり大きいものでした。チーム内からも「Proxyがあって良かった」という声があがったりもしたので、サービスの健全性を支える良いリリースだったなと感じています。

個人的な面では、通信面でのVisaのサーバーの細かい挙動などを知ることができました。こちらについてはまたどこかでお話できれば良いかなと思います。

Proxyサーバー導入まで

今回のProxyですが、実は今年の1月にリリースされています。これは去年の6月からKyashのTechチームの仕組みである「10%ルール」を使ったりしながら少しずつ進めていたものです。10%のルールというのは、四半期ごとに約5日分を技術的改善や生産性の向上のためにあてることができるという仕組みです。

作業全体の流れはこのような感じです。

  1. 2020/6 ~ : 検証やところどころ改修を加える
    • Proxyサーバーの実装は結構早く整うも、メインで動いていた3Dセキュアなどの案件やPCI DSS監査など優先度の高いタスクにSREチームが集中していたため一旦ペンディング
    • 凍結後も裏で細かい検証をしたりする
  2. 2020/11 ~ : 再始動 Proxy実装後からfepの改修が進んでいるため、再度テストして確認、リリースプランニングを行う。
  3. 2021/1 ~ : リリース

f:id:ar_ciel_sa2:20210701133619p:plain
進行の流れ

去年の6月当時はKyashへ入社して少し経ったくらいの頃で、「Visaとの接続ってどうなっているんだろう」と思っていました。バックログを漁っていたら丁度この案件を見つけて「これは勉強に丁度良いぞ」と思いチームに相談したら、やらせてもらえることになりました。 この相談をしたときに特に印象的だったのは、この案件は技術的側面の改善だったのですが、プロダクトマネージャーの方から「いいね!やろうやろう!」と言ってもらえたことでした。

Paymentチームはプロダクトのエンハンスだけでなく、このProxyをはじめとした技術的な改善もバランスよく行うことができています。これはエンジニアだけでなく、プロダクトマネージャーを含んだPaymentチーム全体で技術的投資の重要性を把握できているため実現できていることです。

まとめ

今回のProxyはリリースオペレーションを最適化するという改善でした。リリースオペレーションを改善することによって、スピードの向上、問題が起きたときの特定をしやすくするなど、サービスの健全性を上げることができました。同時にProxyを入れたのでできること、改善したいことも見えてきました。

Kyashではエンジニアを募集中です!Paymentチームではクレジットカード決済の電文や通信の世界を覗いて関わることができます。一緒に決済の世界に飛び込んでみませんか? ご興味がありましたらぜひこちらを御覧ください。

最後までお読みいただきありがとうございました。