こんにちは。スマートバンクでサーバーサイドエンジニアをしている mitani です。
Kaigi on Rails 2021 に社員2名が登壇します でご紹介していただいた通り、2021年10月22日のKaigi on Railsで「監視を通じたサービスの逐次的進化 ~B/43の決済サービスでの取り組み~」というタイトルで発表してきました。
発表スライドはSpeakerDeckにて公開しています。
このブログでは発表の中で紹介させていただいた内容から、個人的に伝えたかったトピックを取り上げてお届けしたいと思います。発表時間の都合上削ってしまった内容や、発表中にはうまく伝えられなかった個人的な監視への"思い"みたいなのを感じ取っていただければと思います。
"監視を通じたサービスの逐次的進化"で伝えたかったこと
「監視」というワードを聞くと、例えばNewRelicやDataDogなどでAPMを使ってコードパフォーマンスやエラーレートを監視したり、SentryやBugsnagなどのツールを使ってバグ改善をしていくような活動をイメージする方も多いかもしれません。 今回の発表ではそういった監視ツールの使い方とは少し逸れて、不確実性の高い機能開発の品質を徐々に高めていくための監視戦略とその具体策について紹介させていただきました。
私は今、B/43というサービスでお金を扱うアプリを開発していますが、前職も含めて決済関連のシステムに長く携わってきました。その中で過去の職場では自分が起こした障害でXX万円の損害を出したり、逆に監視しすぎて監視コストをXX万円増やしてしまったりと、安定したサービスの提供に四苦八苦してきた経験があります。
お金に関わる機能を扱ってるとよく感じるのですが、10分間検索のサービスがダウンする障害よりも、数件の決済エラーでデータ不整合が起きる方が遥かに運用への負荷が高いと思います。例えば検索サービスはエラーを解消し再度検索できる状態に持っていけば障害対応としては完了となることもありますが、決済サービスのデータ不整合はそこからデータを正しい状態に戻していく作業が発生し、ログの調査からデータ修正など作業が不具合修正とは別に発生します。また、そういう正しい状態に戻していく作業は職人芸に近いことも多く、属人化しやすいポイントでもあります。
そういった経験から、リリース前から如何に障害を起こさないようにするかはもちろんですが、起きた時にいかに簡単に対応できるようにするかを気にすることが多くなりました。今回はその経験をシェアしたいと思い、特に難易度の高かった決済サービスを事例に紹介させていただいています。
なぜ決済サービスを事例に取り上げたか
プリペイドカードの決済サービスは、VisaやMastercardなどのブランドがクレジットカードサービス向けに開発した基盤と同じものを使って提供されています。具体的には、下記の図のように、"オーソリゼーション"と"クリアリング"の2つによって決済の仮売上から確定が行われる仕組みになっています。
プリペイドカードとクレジットカードの大きな違いはユーザーに金額が請求されるタイミングで、プリペイドカードの場合は事前に入金していただいた金額からの即時引き落としとなります。そのため、オーソリゼーションとクリアリングのマッチングに不具合があると、その瞬間に2重決済状態になったり、請求金額が変わってしまいます。
一方、クレジットカードの場合は月末の確定処理から引き落としまでの期間があるためデータのマッチングに猶予期間があります。そのためクリアリングが届かなかったオーソリゼーションや不整合状態になった決済を検知し、ユーザーに請求する前に正しい状態に修正した上で請求処理を行うことができます（クレカの仕組みは開発したことがないため多分に予想を含んでおります）。
プリペイドカードではリアルタイムに残高が減るのでユーザーへは予算管理がしやすくなるといったメリットを打ち出せる一方、如何にデータ不整合状態を極小化してユーザーに安心して使ってもらえるかが重要な技術となります。また、リアルタイム性が求められるため、自動化したマッチング処理を高い品質で作り上げるかが運用負荷軽減につながります。
マッチング処理の難易度
発表中には時間の都合上説明できなかったのですが、オーソリゼーションとクリアリングのマッチング処理には様々なパターンが存在し、絶対に不整合状態を生まないマッチング処理を作り上げることは非常に難易度が高いです。
その根本的な原因には、Visaなどのブランドが策定しているルールの強制力の低さがあります。Visaから加盟店に対して売上を取消する場合の方法などのガイドラインはあるのですが、そのガイドラインに沿わないデータを送ることが仕様上可能となっています。
そのため、我々カードを提供する側（イシュアー）から見ると、世の中の数えきれない加盟店のそれぞれのデータ送信パターンに全て対応しなければ不整合状態を完全に0にすることはできません。99%の加盟店がガイドライン通りにデータを送ってきたとしても、1%の加盟店がガイドラインに記載していない方法でデータを送ってきたら不整合状態が生まれてしまうことになります。
また、個別具体的なパターンに関して詳細にガイドラインが準備されているわけではないため、例えば返品や部分返品などのデータ送り方には加盟店それぞれの癖があります。
Visaの決済システムを初めて扱うこともあり、圧倒的な情報力不足からリリース直後から完全なマッチング処理を実装することは諦めて、不整合を許容しつつ如何に精度を高めていけるかに注力してきました。
うまくいったポイントといかなかったポイント
精度を高めるために具体的に行った設計方法や監視方法はアーカイブ動画を見ていただければと思います。ここではその方法を実践してみて、話しきれなかったポイントについて紹介させていただきたいと思います。
不確実性の高いシステムを作る考え方について
開発初期時点で判明しているケースだけを正常扱いにして、想定外な部分は諦める設計にしたことは開発スピードを上げることにかなり貢献してくれました。膨大なパターンを知り尽くす手段がない以上、諦めるところを諦めることは大事だなと思います。
また、パブリックbeta状態で社内メンバーや知人だけに公開し、このタイミングでできるだけパターンを試して行ったことも良かったと思います。リリース前に関係者だけで公開するリリースフローはそれ以降のプロジェクトでもほぼ全て行われており、やっていない方がいらっしゃったら是非検討してもらえるとリリース後の品質をグッとあげる有効な手段になると思います。
監視ツールと改善の流れについて
データ不整合を許容するという設計上、不整合状態の検知はRedashの目視検知にしています。この方法は今は不整合データの件数が人力で確認可能なため成り立っている一方、そろそろ限界を迎えそうな規模になってきているため、今後は方法を変えようか検討中です。
一部Sentryに通知している箇所もあるのですが、エラー原因の特定に時間がかかることも多く課題もあります。クリアリングがファイルでデータ連携され、夜の22時に送られてくるのですが寝る直前にSentryに通知が来て原因調査から対応まで必要となることもあり、如何に詳細にエラー情報を出力するか、また実行時間を勤務時間帯に変えるなど課題点が多くあります。
グラフの形を体で覚える
Redashを使った監視の良いところは、視覚的に異常状態を瞬時に理解しやすいことです。一方で個別のデータの異常が埋もれてしまうこともあり注意が必要です。
なのでこういったミクロな視点でグラフを作りつつ
マクロな視点で見えるようなグラフの両面から見るのがポイントです。
ほぼ毎日同じようなグラフを見ていると、なんかやばそうな時と大丈夫そうな時はグラフを見た時の雰囲気で理解できるようになり、やばそうな時にスイッチを入れるみたいな感覚も生まれてきます。障害やトラブルは初動速度が大事なこともあり、感覚的にやばいと思える感覚を身につけるのにもRedashを使うのはいい訓練だと思います。
負担の軽減
若手エンジニアほど障害が起きた時に責任感を感じ過ぎてしまうことがあったり、何度も発生してしまうと対応ばかりに時間が取られメインの仕事を圧迫してしまう原因になったりすることもあるかと思います。そういった対策として、チーム内でリスクと対応コストを天秤にかけて柔軟に対応してくのが大切だと思います。
今のチームでは運用ルールを決める判断軸がかなり共有されてると感じていて、コミュニケーションがスムーズに進んでいます。また、不具合が発生したとしても、より精度の高い仕組みで改善を行なっていけるので、チームの心理的負担が減ったいい状態になっていると感じています。
まとめ
発表の中で紹介した内容のまとめは下記の通りです。リリース後のことを考えて監視を埋め込んでおくことの重要性やメリットなど、少しでも感じてもらえたら嬉しいです。
最後に
Kaigi on Railsのようなスポンサーがつく大きなイベントで登壇するのは初めての経験で、事前収録からYouTubeでの配信など今までにない経験を得られたことは非常に楽しかったです。Kaigi on Rails運営の皆さん、このような機会をいただきありがとうございました & 本当にお疲れさまでした！ 🙏 来年の開催を楽しみにしています！
発表を聞いていただけた方、このブログを読んでいただけた方、もし弊社ないし同発表に興味を持っていただけたら気軽にカジュアル面談をよろしくお願いします。
