【Mercari Tech Conf 2018 レポート】メルペイの進める決済処理のマイクロサービス化についてのセッション『どうして僕らは決済処理をマイクロサービス化しようとしているのか』#mtc18
どうして僕らは決済処理をマイクロサービス化しようとしているのか
メルカリの売上金も電子マネーとして使えるようになるメルペイ。もちろんメルカリでの買い物でも使える予定ですが、そこで問題となったのがメルカリ上での決済処理。増築に増築を重ねたモノリシックなプログラムが、新しい決済手段の導入の前に立ちはだかります。そこで、私達はGO BOLDにMicroservice化で解決しようとしていますが、その中で認められた問題点と解決策を示していきます。0) なぜMicroservices化に踏み切ったのか1) 複雑に絡み合ったswitch文となった業務フローを読み解く2) 分散トランザクションで発生するであろうエラーとの戦い3) 会計システムへの影響をいかに減らすか
スライド
なぜマイクロサービスに踏み切ったか
- メルカリのバックエンドはモノリスなアプリ
- 国ごとにコードをフォークする前は全部の国の実装が入っていたりもした
決済について
- 成長の足かせになる可能性があった
- スケールしない既存の決算処理
- 一方で新しい電子決済を加える必要がある
- 限られた人しか決済処理を理解していない
複雑に絡み合った switch 文となったコード
- 注: 擬似コードです
カード決済のだけのとき
コンビニ決済が増えた
携帯キャリアの決済も増えた
月1払いという概念も増えた
- 限られた与信枠の中であとでコンビニなどで支払う
ここにメルペイの電子決済の case を追加するか
- したくない
問題
- 現状の決済処理はスケールしない
- 開発中の電子決済サービスとの間で疎な結合を取る必要がある
解決策
- 疎結合化に伴い gRPC のインタフェースを用いたマイクロサービス化
- 決済処理を再実装
- 開発組織構造を疎にする
- スケールしやすい
- 組織の問題はリファクタでは改善できない
=> マイクロサービスを選択
得られた効果
- 保守性の向上
- 責務の分離
- 決済手段を容易に増やせるようになった
- 決済処理の再実装を行うことで決済処理の理解者が増えた
分散トランザクション
既存のモノリス
- ロールバックするだけでよかった
マイクロサービス
- 分散トランザクションになる
処理の結果はそれぞれのシステムで独立する
- 処理が独立することによる問題が発生する
解決策: 分ける
PaymentService に "一部" 障害が起きた場合
- ネットワーク越しに処理を呼び出す
- モノリス(さくらDC) から -> マイクロサービス(GCP) に通信するため
- それぞれのシステムは同じネットワークではない
- 通信経路に障害が起きたり, 処理が追いついていなかったら……?
- 正常に終了はする"かも"しれない
- 顧客の UX は悪化する
解決策: ステートマシン
- テスト書くのが超難しい
- Go で並行処理をいい感じに行なっている
- DB は Spanner で可用性を保っている
移行時に会計システムへの影響をいかに減らすか
- 現システムと新システムで同じ結果を並行で書き込むようにした
- 完全に移行するまでは現システムに全てのデータが集まっているように
まとめ
マイクロサービス化による保守性の向上
- 責務の分離
- 柔軟な拡張
- 属人性排除
- 組織とシステムを疎に結合し開発速度を高める
分散トランザクションの性質を理解して実装
- 元の状態に戻せる方法を担保する
- 冪等性を担保する処理
- ステートマシンでリトライと補償トランザクション
移行
- 現システムと新システムで並行に書き込む
おわりに
マイクロサービス化をした理由、メリットだけでなく、実際にマイクロサービスにすることでどのような問題が起きたか、どのようにモノリスからの移行を進めるかなどの知見を発表していただいてとてもためになるセッションでした。実際に私も業務でマイクロサービスを開発しているのですが、マイクロサービスならではの問題はたくさんあり、難しいなと日頃から思っているので、もっと知識を身につけていきたいです。
その他の『Mercari Tech Conf 2018 レポート』記事
【Mercari Tech Conf 2018 レポート】メルカリ Web の新アーキテクチャについてのセッション『Web Application as a Microservice』#mtc18