高セキュリティ・高耐障害性・サブシステム化。そして2億円

2025年3月7日に開催された「事業成長を加速する技術基盤 5社が語るリプレイス・リアーキテクチャの最前線」 の登壇資料です。
https://timeedev.connpass.com/event/344976/

Transcript

1. 高セキュリティ・高耐障害性・サブシス テム化。そして2億円 2025/03/07 事業成長を加速する技術基盤 5社が語るリプレイス・リアーキテクチャの最前線 株式会社タイミー 工藤 祐
2. 目次 • 自己紹介 • 普段どんな課題と向き合っているか • 報酬振込周りで抱えていた課題感 • 報酬振込周りのサブシステム化 • サブシステム化をして得られたもの
3. 自己紹介 Kudo Tasuku • 株式会社タイミー（2023/11入社） • 5年目のバックエンドエンジニア • IronBankSquad というチームに所属 🏦 • 主にお金周りのドメインの開発に関わる 💰
6. 1 普段どんな課題と 向き合っているか
7. 普段どんな課題と向き合っているか • スポットワークにかかる、すべてのお金の動きの記 録と管理 • 主に、ワーカーへの報酬の振込、企業への請求書発 行、etc… ◦ 今回は「ワーカーへの報酬の振込」に関しての テーマを取り扱います 我々 IronBankSquad に課せられたテーマ 🏦
8. 普段どんな課題と向き合っているか • 報酬獲得体験を死守すること ◦ ワーカーの報酬受け取りに関わるUX（即日振 込、給与振込）を毀損しない ◦ タイミーの根幹に関わる部分であり、振込したの に入金されない、給料日を過ぎているのに振込さ れない、などはあってはならない 報酬振込周りのミッション
9. 2 報酬振込周りで 抱えていた課題感
10. 報酬振込周りで抱えていた課題感 ① 振込の銀行 APIがリクエスト上限に達しそう • タイミーワーカーの増加に伴い、銀行API のリクエスト回数も増えている • 銀行APIにはレートリミットがあり 、この ままだと膨大なリクエスト量を捌ききれな くなってしまい、即金体験が損なわれてし まう 銀行APIにレートリミットがある😭
11. • コードベースを社内の全てのエンジニアが参照・更新できるよう になっていていいんだっけ？ • 他のコードベースと同じルールでマージやデプロイができていい んだっけ？ • 報酬振込周りの秘匿情報の管理は、他の情報と同じレベルでい いんだっけ？ 報酬振込周りで抱えていた課題感 ② セキュリティ的な懸念
12. 外部APIを増やしてAPIを冗長化 しつつ、報酬振込周りの機能を サブシステム化してアクセス権 限を分離すれば良いのでは？
13. 2024年7月、実際にやり遂げました 🎉
14. 3 報酬振込周りの サブシステム化
15. 報酬振込周りのサブシステム化 サブシステム化した後のシステム構成図
16. 報酬振込周りのサブシステム化 • Timee Backend から Timee SubSystem の RailsAPI をリクエスト • Redis に振込を行う Job をエンキューし、一旦 Timee Backend へ HTTP200 を返す
17. 報酬振込周りのサブシステム化 • 振込の銀行APIをもう一つ追加（外部APIの冗長化） • 一定の確率でどちらかの外部APIにリクエストを送り負荷を分散させる
18. 報酬振込周りのサブシステム化 • 振込に失敗した場合は外部APIからWebhookが返ってくる • 外部API → Timee SubSystem → Timee Backend の順番でWebhookの振込失敗を通知する
19. アクセス権限が明確に分離できる • サブシステム化せずに本体APIで要所要所にアクセス制限を設定することもやろうと 思えばできなくはないかもしれない • しかし、情報にアクセスできそうな抜け穴のパターンを全て考えて、その全てに対し て対応方針を決めなければならない → 検討漏れによるセキュリティ懸念や、管理コストの増大 • ならシステムごと分離してアクセス権限を一括管理 してしまった方が楽 給与支払い周りのサブシステム化 サブシステム化して何が嬉しいの？
20. • リポジトリの分離 ◦ コードの参照・更新を主要開発メンバーに限定 ◦ デプロイやスクリプト実行を本体APIよりセキュアなルールで行うことができる • ネットワーク、DB、環境変数の分離 ◦ AWSアカウントレベルで本体APIと分離 ◦ 本番の情報が直接参照できるのはごく一部のメンバーに限定 給与支払い周りのサブシステム化 具体的に何を分離したか？
21. • モジュラーモノリス→マイクロサービス化の先駆けとなる ◦ もし将来的にやるなら、サブシステム化を通して得られた知見 を活かせる • 小さいリポジトリのため技術的な制約を受けにくい ◦ ライブラリバージョンアップや、RBS, Rubocop の新機能を試 して、本体APIにFBをすることもできる • サブシステムのコンテナだけをスケールさせることができるので、効 率的なリソース利用ができる 給与支払い周りのサブシステム化 副次的なメリット Ruby, Rails は最 新バージョンです （ﾄﾞﾔ
22. 4 サブシステム化をして 得られたもの
23. サブシステム化をして得られたもの 銀行APIのリクエスト上限の増加 • 当初の約6倍まで上限が増えた 🎉 • 向こう数年間はリクエスト上限の心配はなくなった ※ 2024年11月に3つ目の銀行APIを新しく追加してさらに上限数が伸びました
24. 銀行APIの振込手数料削減 サブシステム化をして得られたもの • 銀行APIへリクエストを送る度に振込手数料がかかり、年 間にかなりの額のコストがかかっていた • 銀行APIが増えたことにより、振込手数料の高い他行振込 ではなく、同行振込で振込をするように最適化がしやすく なった • 年間で最大2億円のコスト削減ができるようになった 💰💰
25. 耐障害性の向上 • 仮に1つの銀行APIが障害等でダウンしていても、もう一方の銀行APIにリクエ ストすることができるようになった • サブシステム構築時に起き得る障害のパターンを可能な限り洗い出し、その全 てに対して適切なエラーハンドリングと障害対応フローを構築 ◦ 一日数万件のリクエストを捌いているのにもかかわらず、リリースして からHTTP500エラーをほとんど出していない サブシステム化をして得られたもの
26. セキュリティの向上 サブシステム化をして得られたもの • 外部ライブラリ管理 ◦ dependabot を用いた定期更新 ◦ trivy を用いたセキュリティ通知 • 脆弱性診断 ◦ 外部パートナーによる診断を実施、指摘へ対応済み • ログへの漏洩対策 ◦ 全情報についてのセキュリティレベルと取り扱い方針の決定と、実装 への反映
27. 他にも色々 ... サブシステム化をして得られたもの • スクラムのプロセス的な知見 • メンテナンス性、開発者体験向上の取り組み • QAプロセスの知見 • 本番リリースで障害を起こさないためのカナリアリリース • 社内でチームが表彰される🎉 • etc…
28. まとめ • 一部の機能をシステムごと分離することで、セキュリティを向上させつつ、アクセ ス権限の管理をしやすくできた • 銀行APIを冗長化して負荷分散することでレートリミットの軽減や耐障害性を向 上させることができた • 銀行APIへのリクエストを最適化することでコスト削減を実現できた
29. ご静聴ありがとうございました！