B/43 の rails stats

B/43 は2021/4/26にローンチされ、リリースしてから約2.5年経つサービスです。リリース当初からメイン機能のほとんどの機能がRailsで開発され今日に至ります。発表直前のメインで開発しているrepositoryのrails statsを取得してみた結果が下記になります。ちなみにこのRailsはAPIモードで開発されております。

実際のデータベースにあるテーブル数は350以上、モバイルアプリ用や社内管理画面用などを含めたAPIエンドポイントは300にも及び、リリースからまだ2.5年しか経っていないことを考えると、比較的早いスピードでコードベースが拡大していることが分かるかと思います。（テストコードも手厚めに書いているのでモリモリ増えてる！）

またrails statsの結果としてモデル数が多いのは、PORO(Plain Old Ruby Object)の採用や当日のohbaryeの発表にもあった通り、管理画面用のモデルをnamespaceを分離して専用のクラスを用意しているためです。

B/43システムの複雑さの一例紹介

今回は複雑になりがちなFintechサービスの裏側では、どんなロジックや処理を書いているのかを知ってもらうために一例として残高処理の例を紹介させてもらいました。

入金残高の記録と管理について

B/43で提供しているカードはプリペイド式ですので、ユーザーはいくつかある入金方法から選んで入金してもらい、システムはそれを記録して残高に加算していきます。単純に考えれば残高を管理するテーブルに入金した額のレコードを追加して終わりかと思いますが、B/43が取り扱う残高はもう少し詳細に管理する必要があります。

上記の表は一例ではありますが、入金時のユーザーの状態や入金方法によって、弊社が保有する金融免許のうちどれに該当し準拠しなければいけないかが変わってきます。また現金として引き出せるか否かといった機能差もあるので、実態としてはそれぞれの入金方法に加えどの免許に該当した残高かといった情報を細かく内訳としてデータベースに記録している形になります。

残高管理、むっちゃつらそう…。#kaigionrails
— どみにをん525 (@Dominion525) 2023年10月28日

スライドを見ていただいた方からも、残高管理の複雑さが伝わっていたようで、入出金に関する機能を追加する際に、どう管理するかに毎回向き合って開発しております。

残高減算処理の複雑さについて

決済時に残高を減算する場合も管理している残高の性質に応じて減らす優先度が決まっており、決済時にそれを考慮しながら減算処理をしないといけない複雑さがあることも発表させていただきました。

減算のロジックは一度組み上げてしまえばそこまで大きな変更はないですが、入金方法が追加され、それに応じてロジックを修正しないといけないシーンがままあるのと、実際は返金、一部返金といった減らした残高を元に戻すことなども考慮にいれないといけないため、それなりにコードベースは複雑になっています。
こういった決済の処理に起因する複雑さは当日のhiroteaの発表で決済パターンの紹介もありましたので、合わせて見ていただけると理解が深まるかと思います。

B/43 アーキテクチャの紹介

今回ブースも出させていただき、そちらに上記のアーキテクチャ図をパネルとして展示もしていましたので、興味を持って見ていただいたり、質問をしてもらったりと、立ち寄っていただいた方には好評のコンテンツになりました。
当日の発表ではPCI DSSへの準拠の有無を境界として2つ大きく環境が分かれていること、RubyとGoで開発言語を分けながらシステムを構築してることを発表させていただきました。SREチームと連携しながら、比較的最新のバージョンでどちらも運用できているのが良いですね。

PCI-DSS準拠の裏側めっちゃ気になる #kaigionrails
— Manami Nakamura (@mnmandahalf) 2023年10月28日

「アーキテクチャ。規制準拠の有無を境界に、2環境で運用」 PCI DSS 厳しいから分割するの賢い #kaigionrails #kaigionrailsA
— 黒曜@Leaner Technologies (@kokuyouwind) 2023年10月28日

こういう感想もいただけていたので、PCI DSSについて詳しく知りたい方はPCI DSS に準拠したシステム開発 - Speaker Deckのスライドも合わせてご覧いただけると嬉しいです。また、当日の発表スライドからは時間の都合でカットしておりましたが、RubyとGoのそれぞれの採用理由も改めて紹介しておきたいと思います。

スタートアップの初期のシステム構築時にどんなシステムを作るかが解像度高く分かっていることはあまりないかもですが（カード発行やVisa決済NWとの繋ぎ込みは手探りで開発を開始）、当時の作るべき要件から自分は上記のような理由で言語を選択しておりました。

インフラ構成の紹介

PCI DSSへの準拠を意図しているのもありますが、B/43は全面的にAWSを採用してインフラを構築していること、また機能の一部にAWSサービスを活用していることを紹介させていただきました。ここではXで頂いていた感想やご質問に回答していきたいと思います。

fargateもう主流なんだな。。
私が初めてECS検証した時まだ東京リージョン対応してなかったのに。。#kaigionrails
— ▶︎石田 (@aiuhehe) 2023年10月28日

構築当時は ECS on EC2 か ECS on Fargate かで悩みましたが、Fagateの方が運用コストが低い点やPCI DSS準拠を前提としたセキュリティ要件（IDS / IPS）への準拠のしやすさを考慮してFargateを採用しています。

「インフラは全面AWS。ECS on Fargateを運用、GitHub Actionsを使ってB/Gデプロイしている」お、ここはCodePipelineじゃないんだ #kaigionrails #kaigionrailsA
— 黒曜@Leaner Technologies (@kokuyouwind) 2023年10月28日

時間の都合でだいぶ省力して話してしまったのですが、記載いただいてる通りでAWS CodePiplineを使ってデプロイは実現しております。mainブランチへのマージ後、Github Actionsを使ってreleaseブランチを作成し、GithubのwebhookトリガーでCodePiplineを起動、その後は自動でデプロイされるようになっています。また、Jenkins経由で任意のブランチを指定してデプロイできるようにしており、開発中の内容の動作確認も開発やステージング環境ではできるようにしております。
インフラに関しては別エントリーでAWSの選定理由などを詳しく書いていますので、興味があれば是非ご覧ください。

blog.smartbank.co.jp

発表した感想

発表会場となったAホールはほとんど満員で、オンラインでも500名以上の方に聞いていただけていたということで大変嬉しくスポンサーして本当に良かったです！個人的にもKaigi on Railsを盛り上げたい気持ちで孤独のCTOグルメという会場近くのランチ箇所を紹介するコンテンツも割と見切り発車でやってみましたが、コンテンツを見てランチにいきましたといってくれた方もチラホラいて、頑張ってロケしたかいがあり、こちらも嬉しかったです。

#孤独のCTOグルメに今日も乗っかって肉食堂優にやってきました。ハンバーグ！チーズ乗せ！ #kaigionrails pic.twitter.com/I8Pf5SQy1F
— tk0miya (@tk0miya) 2023年10月28日

#孤独のCTOグルメで紹介されてた昆布塩ラーメン屋さんに来てみた。美✨ #kaigionrails pic.twitter.com/87X4f2tsKt
— Manami Nakamura (@mnmandahalf) 2023年10月27日

最後にお礼と宣伝

オフラインで参加した久々の大型のカンファレンスでしたが、懐かしい友人に会えたりB/43のことを知っていただく非常に良い機会になりました。オフラインならではの情報交換や出会いがあり、カンファレンスの醍醐味ってこれだよな〜という気持ちが蘇ってきました。
オフライン&オンライン同時開催で大変だったと思いますが、開催してくれた運営スタッフの方、そしてブースに来てくださった方々に改めてお礼を申し上げます。ありがとうございました！

そして、Kaigi on Railsをまだまだ楽しみたい方へ、11/9（木）にメドピアさん、マイベストさんと共催でアフターイベントを予定しているので、よかったらお越しください！

smartbank.connpass.com

次回、アフターイベントも全て終わったら、また改めて初めてのスポンサーの振り返りをまとめようと思います。お楽しみに。