inSmartBank

B/43を運営するSmartBank社のメンバーによるブログです

TracePoint活用事例: Sentryのローカル変数キャプチャ機能

"Sentry"、使っていますか?

去る 2021-11-11 にリリースされた sentry-ruby 4.8.0 gem に "exception frame's local variable capturing" という機能が導入されました。良い感じの和訳が思いついてないのですが本記事ではローカル変数キャプチャ機能と呼称します。

これは例外発生箇所のローカル変数を Sentry Web UI で確認できる便利デバグ機能であるだけでなく TracePoint の cool な活用事例でもあります。せっかくなので機能の説明だけでなく、どのようにこの機能が実現されているのか、コードリーディングしつつ解説を試みます。

続きを読む

FinTechスタートアップ企業のインフラができるまで

初めまして!インフラを担当してます上平と申します。 このエントリーではFintech事業を実現するインフラ構築に関して紹介します! スタートアップ企業でイチから構築する大変さや面白さをお伝えできればと思います!

Fintech事業において事業内容にもよりますが、我々のようなカード発行会社の場合、PCI DSSというカード業界における国際セキュリティ基準への準拠が必須となります。 弊社ももちろんPCI DSSに準拠しておりますが、準拠のためにはインフラ構築を始めるタイミングから考えることがたくさんあります。

今回から、選定編構築編運用編と3部に分けて弊社の取り組みを紹介させていただきます。

続きを読む

ストア評価4.5!「あたりまえ」を考えたらApp Storeの評価が大きく改善しました

こんにちは。
プロダクトマネージャーのmoretです。

先日リリースした「B/43」のiOSアプリでStoreKitを利用してアプリを評価してもらうためのダイアログを表示する変更を行いました。

"B/43"はいかがですか?

ストア評価が4.5、評価回数も10倍に!

このリリース以後、App Storeで「B/43」アプリに対するユーザーからの評価が2週間ほどで3.9点から4.5点まで上昇しました。また点数だけでなく評価の回数も大幅に増加しており、週あたりの評価回数はおよそ10回→100回+となっています。

10月20日のリリース以降に数値が急進

続きを読む

Kaigi on Rails 2021 で決済サービスの監視についてトークしてきました!

f:id:smartbank:20211026001139p:plain こんにちは。スマートバンクでサーバーサイドエンジニアをしている mitani です。

Kaigi on Rails 2021 に社員2名が登壇します でご紹介していただいた通り、2021年10月22日のKaigi on Railsで「監視を通じたサービスの逐次的進化 ~B/43の決済サービスでの取り組み~」というタイトルで発表してきました。

発表スライドはSpeakerDeckにて公開しています。

このブログでは発表の中で紹介させていただいた内容から、個人的に伝えたかったトピックを取り上げてお届けしたいと思います。発表時間の都合上削ってしまった内容や、発表中にはうまく伝えられなかった個人的な監視への"思い"みたいなのを感じ取っていただければと思います。

"監視を通じたサービスの逐次的進化"で伝えたかったこと

「監視」というワードを聞くと、例えばNewRelicやDataDogなどでAPMを使ってコードパフォーマンスやエラーレートを監視したり、SentryやBugsnagなどのツールを使ってバグ改善をしていくような活動をイメージする方も多いかもしれません。 今回の発表ではそういった監視ツールの使い方とは少し逸れて、不確実性の高い機能開発の品質を徐々に高めていくための監視戦略とその具体策について紹介させていただきました。

f:id:smartbank:20211025212050p:plain

私は今、B/43というサービスでお金を扱うアプリを開発していますが、前職も含めて決済関連のシステムに長く携わってきました。その中で過去の職場では自分が起こした障害でXX万円の損害を出したり、逆に監視しすぎて監視コストをXX万円増やしてしまったりと、安定したサービスの提供に四苦八苦してきた経験があります。

お金に関わる機能を扱ってるとよく感じるのですが、10分間検索のサービスがダウンする障害よりも、数件の決済エラーでデータ不整合が起きる方が遥かに運用への負荷が高いと思います。例えば検索サービスはエラーを解消し再度検索できる状態に持っていけば障害対応としては完了となることもありますが、決済サービスのデータ不整合はそこからデータを正しい状態に戻していく作業が発生し、ログの調査からデータ修正など作業が不具合修正とは別に発生します。また、そういう正しい状態に戻していく作業は職人芸に近いことも多く、属人化しやすいポイントでもあります。

そういった経験から、リリース前から如何に障害を起こさないようにするかはもちろんですが、起きた時にいかに簡単に対応できるようにするかを気にすることが多くなりました。今回はその経験をシェアしたいと思い、特に難易度の高かった決済サービスを事例に紹介させていただいています。

なぜ決済サービスを事例に取り上げたか

プリペイドカードの決済サービスは、VisaやMastercardなどのブランドがクレジットカードサービス向けに開発した基盤と同じものを使って提供されています。具体的には、下記の図のように、"オーソリゼーション"と"クリアリング"の2つによって決済の仮売上から確定が行われる仕組みになっています。

f:id:smartbank:20211025212320p:plain

プリペイドカードとクレジットカードの大きな違いはユーザーに金額が請求されるタイミングで、プリペイドカードの場合は事前に入金していただいた金額からの即時引き落としとなります。そのため、オーソリゼーションとクリアリングのマッチングに不具合があると、その瞬間に2重決済状態になったり、請求金額が変わってしまいます。

一方、クレジットカードの場合は月末の確定処理から引き落としまでの期間があるためデータのマッチングに猶予期間があります。そのためクリアリングが届かなかったオーソリゼーションや不整合状態になった決済を検知し、ユーザーに請求する前に正しい状態に修正した上で請求処理を行うことができます(クレカの仕組みは開発したことがないため多分に予想を含んでおります)。

プリペイドカードではリアルタイムに残高が減るのでユーザーへは予算管理がしやすくなるといったメリットを打ち出せる一方、如何にデータ不整合状態を極小化してユーザーに安心して使ってもらえるかが重要な技術となります。また、リアルタイム性が求められるため、自動化したマッチング処理を高い品質で作り上げるかが運用負荷軽減につながります。

マッチング処理の難易度

発表中には時間の都合上説明できなかったのですが、オーソリゼーションとクリアリングのマッチング処理には様々なパターンが存在し、絶対に不整合状態を生まないマッチング処理を作り上げることは非常に難易度が高いです。

f:id:smartbank:20211025212451p:plain

その根本的な原因には、Visaなどのブランドが策定しているルールの強制力の低さがあります。Visaから加盟店に対して売上を取消する場合の方法などのガイドラインはあるのですが、そのガイドラインに沿わないデータを送ることが仕様上可能となっています。

そのため、我々カードを提供する側(イシュアー)から見ると、世の中の数えきれない加盟店のそれぞれのデータ送信パターンに全て対応しなければ不整合状態を完全に0にすることはできません。99%の加盟店がガイドライン通りにデータを送ってきたとしても、1%の加盟店がガイドラインに記載していない方法でデータを送ってきたら不整合状態が生まれてしまうことになります。

また、個別具体的なパターンに関して詳細にガイドラインが準備されているわけではないため、例えば返品や部分返品などのデータ送り方には加盟店それぞれのがあります。

Visaの決済システムを初めて扱うこともあり、圧倒的な情報力不足からリリース直後から完全なマッチング処理を実装することは諦めて、不整合を許容しつつ如何に精度を高めていけるかに注力してきました。

うまくいったポイントといかなかったポイント

精度を高めるために具体的に行った設計方法や監視方法はアーカイブ動画を見ていただければと思います。ここではその方法を実践してみて、話しきれなかったポイントについて紹介させていただきたいと思います。

不確実性の高いシステムを作る考え方について

f:id:smartbank:20211025212616p:plain

開発初期時点で判明しているケースだけを正常扱いにして、想定外な部分は諦める設計にしたことは開発スピードを上げることにかなり貢献してくれました。膨大なパターンを知り尽くす手段がない以上、諦めるところを諦めることは大事だなと思います。

また、パブリックbeta状態で社内メンバーや知人だけに公開し、このタイミングでできるだけパターンを試して行ったことも良かったと思います。リリース前に関係者だけで公開するリリースフローはそれ以降のプロジェクトでもほぼ全て行われており、やっていない方がいらっしゃったら是非検討してもらえるとリリース後の品質をグッとあげる有効な手段になると思います。

監視ツールと改善の流れについて

f:id:smartbank:20211025212645p:plain

データ不整合を許容するという設計上、不整合状態の検知はRedashの目視検知にしています。この方法は今は不整合データの件数が人力で確認可能なため成り立っている一方、そろそろ限界を迎えそうな規模になってきているため、今後は方法を変えようか検討中です。

一部Sentryに通知している箇所もあるのですが、エラー原因の特定に時間がかかることも多く課題もあります。クリアリングがファイルでデータ連携され、夜の22時に送られてくるのですが寝る直前にSentryに通知が来て原因調査から対応まで必要となることもあり、如何に詳細にエラー情報を出力するか、また実行時間を勤務時間帯に変えるなど課題点が多くあります。

グラフの形を体で覚える

Redashを使った監視の良いところは、視覚的に異常状態を瞬時に理解しやすいことです。一方で個別のデータの異常が埋もれてしまうこともあり注意が必要です。

なのでこういったミクロな視点でグラフを作りつつ f:id:smartbank:20211025212722p:plain

マクロな視点で見えるようなグラフの両面から見るのがポイントです。 f:id:smartbank:20211025212743p:plain

ほぼ毎日同じようなグラフを見ていると、なんかやばそうな時と大丈夫そうな時はグラフを見た時の雰囲気で理解できるようになり、やばそうな時にスイッチを入れるみたいな感覚も生まれてきます。障害やトラブルは初動速度が大事なこともあり、感覚的にやばいと思える感覚を身につけるのにもRedashを使うのはいい訓練だと思います。

負担の軽減

若手エンジニアほど障害が起きた時に責任感を感じ過ぎてしまうことがあったり、何度も発生してしまうと対応ばかりに時間が取られメインの仕事を圧迫してしまう原因になったりすることもあるかと思います。そういった対策として、チーム内でリスクと対応コストを天秤にかけて柔軟に対応してくのが大切だと思います。

f:id:smartbank:20211025212902p:plain

今のチームでは運用ルールを決める判断軸がかなり共有されてると感じていて、コミュニケーションがスムーズに進んでいます。また、不具合が発生したとしても、より精度の高い仕組みで改善を行なっていけるので、チームの心理的負担が減ったいい状態になっていると感じています。

まとめ

発表の中で紹介した内容のまとめは下記の通りです。リリース後のことを考えて監視を埋め込んでおくことの重要性やメリットなど、少しでも感じてもらえたら嬉しいです。

f:id:smartbank:20211025212927p:plain

最後に

Kaigi on Railsのようなスポンサーがつく大きなイベントで登壇するのは初めての経験で、事前収録からYouTubeでの配信など今までにない経験を得られたことは非常に楽しかったです。Kaigi on Rails運営の皆さん、このような機会をいただきありがとうございました & 本当にお疲れさまでした! 🙏 来年の開催を楽しみにしています!

発表を聞いていただけた方、このブログを読んでいただけた方、もし弊社ないし同発表に興味を持っていただけたら気軽にカジュアル面談をよろしくお願いします。

smartbank.co.jp

Idempotency-Key Headerを使ったリトライと、オンラインイベントの"Kaigi感"

去る2021年10月23日に開催されたKaigi on Rails 2021にて、弊社の@ohbaryeが "Safe Retry with Idempotency-Key Header" というタイトルで発表してきました。

発表スライドはSpeakerDeckにて公開済みです。

後日アーカイブ動画も公開されるとのことですのでそちらも是非ご覧頂きたいのですが、おとなしく30分の動画を視聴できるほど現代人は暇じゃないですよね。なので本記事の前半では忙しい人のために発表内容を1/10ぐらいの密度で解説してみます。

(2021-10-31追記) 動画が公開されました 🎉

www.youtube.com

(2021-10-31追記おわり)

ただ、それだけでは配信動画をすでに視聴いただいた方への新規情報がゼロになってしまうので、後半では発表に関していただいたtweet・質問・感想へのコメントへのリプライを試みたり、Q&Aブースで話したことを私の抱いた"Kaigi感"とともに共有してみます。発表を見た人でも楽しめる、登壇の外側にあるコンテンツもお伝えできればと思います。

続きを読む

Kaigi on Rails 2021 に社員2名が登壇します

こんにちは、CTOの堀井(@yutadayo)です。 今回は社員が登壇するイベントの告知エントリーになります。

今年も2020年から開催されている Kaigi on Rails 2021 が10/22(金)〜23(土)に オンライン開催されます! 昨年からイベント日が追加されていて、全2日程での開催です。 弊社ではRubyもRailsも採用しているので、非常にゆかりの深いイベントですね。

kaigionrails.org

続きを読む

iOSDC Japan 2021 で B/43 の本人確認フロー(eKYC)の構築についてトークしました!

こんにちは。スマートバンクで iOS / Android エンジニアをしている nakamuuu です。 先週からスタートした inSmartBank ブログでは、『家計簿プリカ B/43』のモバイルアプリについてもさまざまなトピックをお伝えできればと考えています!

この記事では 9月17日(金)〜19日(日)に開催された iOSDC Japan 2021 に登壇させていただいた話を書いていこうと思います。

続きを読む