builderscon 2019 day1 メルペイ
microservice
4つのレイヤ
Client
人
API Gateway
うまくちゃんと扱うのは大変なので共通化。
API Service
クライアントとのメッセージに責任を持つ。
req validation
backend aggrigation
client互換性 AB test
Backend Service
自分のドメインに特化した返答をする。
transactionがつらい。
支払い方法の数が多い+組合せも可能。
組み合わせ爆発
エラー処理を例外とせずにうまくやる必要がある。
お金の処理
増やすのと減らすのが基本的操作
増やすのは常に成功
減らすのはコケる可能性がある
どんなエラーが出ても基本的にリトライする。
二重処理されないように全ての処理に羃等性を与える。
継続不能なエラー(残高不足とか)の時のみリトライを諦める。
減算のインターフェース
Try: 引けるかを確認/確保。
Confirm: 確保していたものを確定。
Cancel: 確保を解放。
全てのTryが成功したらConfirmしていき、どれかがコケたらCancelしていく みたいな感じでいける。
状態遷移モデル
あらゆる処理は意図せず途中でコケる可能性がある。
処理単位で状態を記録していき、途中で落ちてもそこから再開すれば良い。
決済とは口座間のお金の移動。
会計とはお金の移動に意味をつけること。
リコンサイル
会計上のお金と残高のお金とかが一致してるかの確認
不正検知
メルペイの登場によって店舗での出金が可能になったので、ほぼリアルタイムでの不正検知が必要になった。
トランザクションモニタリング
決済マイクロサービスの処理をPubSubで受けて確認
安定性をどこまで求めるか。
お気持ちの話だと大変なのでSLOとかの話に寄せていく。
負荷テスト
新規機能には必須。
目標性能の見積りとその根拠を残す。
カナリアリリース
本番環境に入れるのはSREのみ、auditもあり。
メルカリでは運用が開発チームがするので、普通は入れる。
うまいこと安全な形でログを開発チームが見れたりするようにはする。
メルカリ
強くチャレンジ
メルペイ
より高い安定性