[Mercari Engineer Blog]にて，「マイクロサービスにおける決済トランザクション管理」 というエントリーが結構バズりました．

先日merpayでのマイクロサービス導入に関して直接お話を聴く機会があったので その議事録メモなのです．

Memo

マイクロサービス導入してみての良い点・悪い点

良かった点(メリット)

• チームで平行してプロジェクトを進行させることが可能になった．
• コードが小さくなる．フォーカス領域が小さいので気持ち楽，深く探求できる．

悪かった点(デメリット)

• 運用コストが上がる．運用知識が必要，大変.
• 依存関係がつかみにくい．
• テスト，環境用意するのが大変．障害時，トレーシング大変．
• テスト時，環境が複雑なので環境を複数作らないといけなかったりする．
• ログを残してないと問題発生時モノリシックに比べて把握が難しい．

マイクロサービス分割基準

• あまりちゃんとした基準はない．デザイントークで議論して決めるフローがある．

設計で工夫した点・参考にした情報

• APIはgRPCで実装，特別理由はない．社内に好きな人がいたから．
• Googleのデザインパターンを参考にしている．gRPCだけどrestライクに．
• 各社の手法を頭に入れておく．aripayなど技術を公開している．それらを踏まえてベストプラクティスを考えた．
• rollbackしやすいところは分けて，しにくいところはまとめて
• 冪等性を担保は意識した，大変だった．
• テストでいろいろ失敗入れてdesined failureな設計にしている
  • spanerのトランザクションで失敗時巻き戻せるように
  • 差分で管理しているので巻き戻しが容易にできるようにしている
• 不具合時の調査，，スナップショット・取引ログを撮って何かあったときに調べやすいようにしてる
• reconsle(あとチェック)やってる．ずれた際のリカバーをいかに早く検知・復旧できるかを担保してる．これができないのが最悪．

どのようなテストやってるか

• E2E, 専用QAチームがあって，そのチェックをパスしないとリリースできないフローとなっている．
• ランダムテスト, failure injection
  • ネットワークが切れた，DBがレスポンス遅延，ふつう起きないような難易度の高いテストケースを入れている．
  • timeout, abort. 仕組み化してテストフレームワークでやってる．ステートマシンで回して気づけるように.
• QA環境でも不安定な状態を再現して今後やってみたい．

どんな運用を行っているか

• k8sで簡単に立ち上がるようにはしている．
• あえてすべてBEはGolangで書いている．学習コスト，コミュニケーションコストが減った．
• canary公開して無事だったら広げていく，みたいなことをしている．
• 開発者は運用も同時に．
• 障害発生時は通知くる．GCP入ってデバッグとかすることもある．
  • 基本的にdatadog使って確認している．
• 障害レポートを書くようにしている．
• サービスごとにSLO決めている．paymentは厳しく設定している．

開発でのetc

• Cloud spanner触れたのがよかった
  • spannerいい．1node増やすとちゃんとスケールできる．
  • 全データはspannerで管理している．
  • 単純な追記が主なのでパフォーマンスも問題なかった．
  • key uidで撮ってるのでホットスポットなく．
• エラーケースを網羅するのが難しかった．
• 簡単に考えていたが，いろいろユースケースが考えられて設計が難しかった．
• 決済はゲームと違ってバグが許されないので難しい．
• GCPが使いやすかった．
• ポイント付与時のトラフィックがすごい．reqidなどでトレーサブルにはなってる．
• リファクタリングについて，負債返済をOKRに取り入れてやってる
• まだpaymentサービスを経由しないケースがあるのでそれを直したい．
• サービス間はtoken認証

おわりに

merpayの構成がざっくりと把握できました． 調べればマイクロサービスあるあるは色々出てきますが生の声はすごく説得力があるですね．

時間の都合上あまりセキュリティ周りが聴けなかったのでもうちょい教えてくれるなら 知りたい．