“Visa決済”ができるウォレットサービス「Kyash」の技術スタックと目指すべき場所

Kyashの今とこれから

松田優貴氏（以下、松田）：こんばんは。Kyashの松田です。「Kyashの今とこれから 〜Walletの学びとDirectへの挑戦〜」ということで発表させていただきます。

まず簡単に自己紹介をさせてください。実は私、2018年4月までYahoo! JAPANにいたので、久々のLODGEでだいぶ変わった感じと知った顔が後ろにいっぱいいて、ワクワクしています。私は2019年2月から株式会社Kyashでお世話になっておりまして、現状はサーバサイドの開発をしながら、最近ですとテックリードやスクラムマスターとしてプロジェクトをサポートしております。

本日お話しすることは、まずKyashを知らない方もいると思いますので、Kyashについて簡単なご紹介をしたあとに、サーバサイドの今とこれからをお話しさせていただければと思っております。

Kyashは「価値移動のインフラを創る」というミッションを持っていまして、2つの事業を展開しております。1つがtoCのWallet事業、もう1つがtoBの決済プラットフォーム事業です。

みなさんの中にはご存知の方もいらっしゃると思うんですけど、toC向けではWalletアプリ「Kyash」を展開しております。こちらは個人間送金やVisa決済を提供しています。

スライド真ん中にカードの絵があると思うんですけど、Kyashの特徴はVisaのプリペイドカードを発行していて、それをVisaの加盟店で使えることです。

もう1つ特徴的なのは、チャージする方法がいろいろございまして、クレジットカード・デビットカード、コンビニ、銀行口座、ポイント、売上金などからチャージをして、Visaの加盟店やQUICPayで決済でき、それを個人間送金をすることもできます。

もう1つの事業が、これは現在立ち上げ中で4月ぐらいに発表した「Kyash Direct」になります。to Bサービスなのですが、簡単に言うと、Kyashの機能をAPIを通じて利用企業様に解放していきます。

通常ですと、カード発行は銀行やカード会社、決済された際に裏で動くシステムはシステムベンダー、アプリなどのサービス企画はスタートアップ企業を含む事業会社がそれぞれ対応しています。それを一気通貫で機能提供しているのがKyashの特徴だと思っております。

Wallet事業で培ったノウハウやテクノロジーをAPIを介して開放するのが、「Kyash Direct」というto B向けの決済プラットフォーム事業になります。

どんなことができるのかというと、利用企業様のニーズに合わせたオリジナルのカードを発行することができます。このようにバーチャルカードやリアルカードを発行することができます。

Wallet事業の技術スタック

そんな2つの事業をやっているKyashなんですけど、「サーバサイドの今」ということで現状のお話をさせていただきます。現状なのでWallet事業のお話です。

Walletのシステムの全体像はこのような簡略図になっております。下にKyashのシステム群がありまして、ここはマイクロサービスアーキテクチャを採用しております。

外から受けるところが2つありまして、1つがアプリのAPI、リクエストですね。みなさんから見てスライド左側からの受け口になります。インターネットを経由してAPIに入ってきて、その中でマイクロサービス同士が通信をして結果を返します。

もう1つが右側のVisa決済です。Visa加盟店で決済をすると、Visaのネットワークを通ってFepと呼ばれるフロントエンドプロセッサのサーバにリクエストがきて、あとは同じように各マイクロサービスが通信をして結果を返します。

Walletの技術スタックとしては、すべてGo言語で書いており、インフラはAWSを使っています。資料を後ほど展開するので、ご興味ある方は見ていただけたらなと思います。

世の中にはモバイル決済アプリはたくさんある中で、個人的にはVisa決済がなかなかおもしろいなと思っております。こちらがカード決済におけるステークホルダーになります。

みなさんが右下の加盟店でカードを使って決済をしていただくと、加盟店を管理しているアクワイアラにきまして、その後に国際ブランドのVisaやMasterCardに通信がいきまして、その後にカード発行会社に通信がくるかたちになっています。

カード発行会社の処理を内製できる

ここのカード発行部分でやらなきゃいけない部分は、ほとんどKyashで内製をしております。大きく言うと、みなさんがカードを切ったときに「この売上金って使えるんですか？」というオーソリ、仮売上処理。そのあとに売上を確定したり清算処理というものをすべて内製しております。

とくにオーソリゼーションと言われている、カードを切ったときにいろいろなチェックが走ってまして、例えばカードの有効期限はいいのか？　そのユーザは不正ユーザじゃないのか？　加盟店だったらその加盟店は大丈夫なのか？　など、実に数十のチェックをしています。

そのようなやり取りは、Visa特有のメッセージとして通称「電文」を通して行われます。僕もまだ入社して半年です。ふだん読むことのないVisaのドキュメントがあるんですけど、それと格闘しながら日々開発を行っています。

みなさん決済を使っていて、カードを切ったあとにすごく待たされることはあまりないと思うんですよね。なので、そのために数秒でレスポンスを返す必要がありまして、自社システムの処理時間との格闘があったりします。

こういう内製をしているからこそ、できることもたくさんあります。みなさんから見て左側にある写真のような、利用利益をリアルタイムで反映することができます。通常、クレジットカードだと見に行っても、決済が確定するまで、反映されていなかったりすると思うんですけど、Kyashの場合はリアルタイムで反映ができます。

もう1つが自動チャージで、残高が0の状態でもカードを切ると、登録してあるクレジットカードからチャージをしてそのまま決済をすることができます。その他にみなさんから見て右側のリアルタイム通知、プッシュ通知等もできます。このような開発を自社でやっておりますので、開発からリリースまで自分たちの計画を持ってスピーディに実施をすることが可能となっております。

とは言え、課題も多いです。履歴の作成処理が各マイクロサービスに分散してしまっていて「そのサービスでその履歴を作る必要ってあるんだっけ？」「責務多寡なんじゃないか」などの問題があります。

あとはいろいろなマイクロサービスが存在するので、APIが神のような力を持っていて、なんでも知っている存在になってしまっているのも課題です。

Kyashの「これから」

そんな中で「Kyashのこれから」ということなんですけど、もう1つの事業ですね。to BのDirectというサービスで新たなチャレンジをしようと思っています。ちょっと前置きなんですけど、こちらは今絶賛開発中です。

なので、これからお話する内容は必ずしもこのかたちでリリースされるかはわからないということと、私もこのアーキテクチャに入って理解度がまだまだであることを承知の上で聞いていただけると助かります。

キーワードとしては大きく6つあります。このような6つのキーワードをもとにDirectの開発を行っています。その中でも本日は上の2つ、CQRSとChoreographyについてお話させていただきます。

CQRSという言葉を聞いたことのある人もいらっしゃると思うんですけど、コマンド・クエリ責務分離です。システム全体を更新系であるコマンドと参照系であるクエリに責務を分けて処理を最適化するものです。

なぜこのアーキテクチャを採用したかというと、先ほどの課題でありました履歴ですね。タイムラインのようなものの作成で分散・責務多寡になっているものを解決しようと思い、このアーキテクチャを採用しております。

それぞれ決済・送金・チャージと3つの処理が分かれています。それぞれがタイムラインを作る責務を負うのはちょっと重いので、それぞれの決済や送金、チャージは各サービスで処理をします。それがコマンドの処理ですね。更新処理のみを行います。

タイムラインをどう表示するかはクエリ側に責務を持っていただいて、表現を変えることなどは全部クエリ側が責務を負って修正をしていくものです。

もう1つがChoreographyです。マイクロサービスの各サービスのやりとりを完全に非同期で連携するものです。現在のWallet事業はこのChoreographyに対比するOrchestration型といえると思います。そのWalletの課題である「APIが神のような機能を持ってしまう」ということを解決したくて、このアーキテクチャを採用しています。

各マイクロサービスが自分たちのことを知って通信をするのではなく、各サービスを必要なEventと呼ばれるメッセージを参照しまして、関心がある、自分が処理すべきEventが飛んできたら、そのEventに応じて必要な処理を実行し、お互いの詳細を知ることなく自律性と独立性を保つことを目指しております。

Directの全体像

文字で言うと「なんじゃそりゃ？」と思われると思うので、簡単なアニメーションを用意させていただきました。Directの全体像がこのようなかたちになっております。みなさんから見て、上が更新系のコマンドの処理で、下にあるクエリと呼ばれるものが参照系の処理になります。これで完全に処理を分けております。

どのようなかたちで処理が進むのかというと、例えばAPIに更新系の処理がいくと、更新系の処理なので上のコマンドに入っていきます。中間地点にEventを管理するEvent BusにEventが飛んできます。そうするとそのEventに関心のあるところにSQS経由で処理が渡っていき、必要な処理を行うかたちになります。

例えば、何かが更新されると他も更新しなければいけない場合、Orchestration型ですと、各マイクロサービスごとにAPIを更新して、結果を待って別のサービスを更新をするというフローを取る必要があります。Choreographyの型ですと、今更新した内容が「こういう更新が行われたよ」とEventを投げます。そうすると、そのEventに関心のある各サービスが、勝手に拾って勝手に処理をしていく流れになります。

このように関心のあるところが関心のあるEventを監視して、それを拾って処理をするかたちで独立性を担保しています。なので、今の絵のように各サービス間は一切通信を行いません。Eventのみを監視して処理をしていくものになります。

先ほど、下にEventが流れてきて、クエリも必要なデータを拾って必要なデータを整形して表示しやすいようにしてあげるように、責務を分離するかたちになります。

そのDirectの技術は同じようにすべてGo言語で開発をしております。もちろんインフラもAWSを使っておりまして、とくにSQSやSNSなどは非常に多様しております。

これは今まで開発をしてきての感想です。あくまで会社としてではなく僕個人の感想です。この作りで良いなと思ったのは、今まではOrchestration型で同期的に通信して、処理してきたんですけど、今回ですと完全に非同期なので、意図通りに動いたときの気持ち良さが今までの比じゃなかったです。

「これとこれが連動して動いて、結果こうなる」ということが、頭の中のイメージとしてはあるんですけど、それが実際に動いたときの気持ち良さはすごかったです。あとは各サービスが基本的にEventをサブスクライブしておいて、その処理をするので一つひとつの処理が小さくなります。

共通の基盤さえできてしまうと、あとは各ドメインのロジック、各サービスのロジックに集中できるのは良い点かなと思いました。

悩ましい点なんですけど、非同期的に動くので挙動が1箇所でもおかしくなると「どこがおかしいんだ？」ということをデバッグがすごい大変でした。そこに関しては、今はDatadog等のトレーシング機能を使って現状を追えるようにしています。

もう1つが処理するEventですね。Eventの順番がずれると整合性を保つのが非常に難しくなります。本来はこの順番で更新をするとデータが正しく保たれるものが、1個でも順番がずれると変なデータになってしまうところが難しいかなと思いました。そこはEventのバージョンチェック等を各サービス内で実施することで現状は対応している状況です。

再度の掲載になるんですけど、絶賛チャレンジ中です。なのでこの内容が必ずしもそのままリリースされるかわからないということをご了承いただければなと思います。

むしろこのようなキーワード、CQRSやイベントソーシングなどを使ってチャレンジしている方がいらっしゃいましたら、ぜひお話をさせてください。「こういうところにハマりポイントがあるから、気を付けてね」とかを教えていただけると助かります。

今回はキーワードが2つぐらいだったんですけど、さらなる詳細を「builderscon tokyo 2019」で弊社社員がお話ししますので、ご興味ある方はぜひこちらに起こしいただけたらなと思います。

このようなDirectとWalletの事業をガリガリ開発していくエンジニアを我々は募集しておりますので、ご興味のある方はご連絡いただければと思っております。

以上、ご清聴ありがとうございました。

（会場拍手）