Merpay Tech Talk vol. 2に行ってきた
2019年12月18日、Merpay社主催のTech Talk vol.2に行ってきたので学んだことをまとめる。
Merpay Tech Talkとは
毎回各テーマに興味のあるエンジニアたちが集まり、技術的な知見を共有しあうことを目的とした勉強会です。 - Connpass説明分より
とのこと。 今回のテーマは「マイクロサービスの冪等性」ということで、同じマイクロサービスを扱う身としてどんなことに気をつけて設計しているのか学んできた。
Talk 1: 500万ユーザーを支える残高の冪等性
全体像はこの資料にある模様。 特に強調していたのは冪等性を担保するために検証する要素として冪等性キー(UUID v4を採用)の他にペイロードの中身も検証対象にしているという点で、冪等性キーだけを見て判断するのではなく、リクエスト内容も検証することでたまたま同じ冪等性キーが発行されてしまった場合にも冪等性を担保できることを考えて設計しているとのこと。 しかし、これを実現するにはチームや他のサービスとの協力が必要なので、チーム内外のコミュニケーションは大事である旨も強調していた。
Talk 2: コード決済における冪等性と整合性
エラーが返ってきたはずなのに実際には残高が動いていたとか、特にお金に関わる問題があるとサービスの信頼性を失ってしまうし、マイクロサービスアーキテクチャでサービス間の整合性を保つことはDBの点在など関連する要素が多く非常に難しいので、マイクロサービス間でリトライを何度しても不整合が発生してしまう状況を考えて定期的にバッチで不整合を修復しているとのこと。 ある一定期間は不整合が生じてしまうが、最終的に整合がとれるようにするにはバッチ処理を使った修復は必須だと考えているとのこと。 同期的に処理をするのは決済リクエストを受けてからレスポンスを返す部分だけで、サービスごとに内部的なステートを遷移させる処理は非同期で行っている部分が興味深かった。
Talk 3: バッチ処理と冪等性
バッチ処理は、常に動いていないサービスである分失敗しやすいからリトライしやすいように作っているとのこと。 バッチ処理を冪等に設計するメリットは、なにかバグを発見したときに原因を修正したらもう一回流すことで回復できる部分であるとのこと。たしかに、何度繰り返し処理をしても結果が変わらない設計をしていれば特別なリトライ方法を用意する必要がなくて運用がシンプルになると感じた。
まとめ
冪等生の担保の前に、リトライは必ず必要になるという理解が必要だと感じた。 リトライ処理をいかにシンプルにできるかを考えると、おのずと冪等生確保につながると感じた。 常に冪等性を意識したサービス作りが保守運用をシンプルにしたり、もしものときに回復までの時間を短縮できたりすることに繋がると感じた。
