Slide 1

Slide 1 text

高セキュリティ・高耐障害性・サブシス テム化。そして2億円 2025/03/07 事業成長を加速する技術基盤 5社が語るリプレイス・リアーキテクチャの最前線 株式会社タイミー 工藤 祐

Slide 2

Slide 2 text

目次 ● 自己紹介 ● 普段どんな課題と向き合っているか ● 報酬振込周りで抱えていた課題感 ● 報酬振込周りのサブシステム化 ● サブシステム化をして得られたもの

Slide 3

Slide 3 text

自己紹介 Kudo Tasuku ● 株式会社タイミー(2023/11入社) ● 5年目のバックエンドエンジニア ● IronBankSquad というチームに所属 🏦 ● 主にお金周りのドメインの開発に関わる 💰

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

5

Slide 6

Slide 6 text

1 普段どんな課題と 向き合っているか

Slide 7

Slide 7 text

普段どんな課題と向き合っているか ● スポットワークにかかる、すべてのお金の動きの記 録と管理 ● 主に、ワーカーへの報酬の振込、企業への請求書発 行、etc… ○ 今回は「ワーカーへの報酬の振込」に関しての テーマを取り扱います 我々 IronBankSquad に課せられたテーマ 🏦

Slide 8

Slide 8 text

普段どんな課題と向き合っているか ● 報酬獲得体験を死守すること ○ ワーカーの報酬受け取りに関わるUX(即日振 込、給与振込)を毀損しない ○ タイミーの根幹に関わる部分であり、振込したの に入金されない、給料日を過ぎているのに振込さ れない、などはあってはならない 報酬振込周りのミッション

Slide 9

Slide 9 text

2 報酬振込周りで 抱えていた課題感

Slide 10

Slide 10 text

報酬振込周りで抱えていた課題感 ① 振込の銀行 APIがリクエスト上限に達しそう ● タイミーワーカーの増加に伴い、銀行API のリクエスト回数も増えている ● 銀行APIにはレートリミットがあり 、この ままだと膨大なリクエスト量を捌ききれな くなってしまい、即金体験が損なわれてし まう 銀行APIにレートリミットがある😭

Slide 11

Slide 11 text

● コードベースを社内の全てのエンジニアが参照・更新できるよう になっていていいんだっけ? ● 他のコードベースと同じルールでマージやデプロイができていい んだっけ? ● 報酬振込周りの秘匿情報の管理は、他の情報と同じレベルでい いんだっけ? 報酬振込周りで抱えていた課題感 ② セキュリティ的な懸念

Slide 12

Slide 12 text

外部APIを増やしてAPIを冗長化 しつつ、報酬振込周りの機能を サブシステム化してアクセス権 限を分離すれば良いのでは?

Slide 13

Slide 13 text

2024年7月、実際にやり遂げました 🎉

Slide 14

Slide 14 text

3 報酬振込周りの サブシステム化

Slide 15

Slide 15 text

報酬振込周りのサブシステム化 サブシステム化した後のシステム構成図

Slide 16

Slide 16 text

報酬振込周りのサブシステム化 ● Timee Backend から Timee SubSystem の RailsAPI をリクエスト ● Redis に振込を行う Job をエンキューし、一旦 Timee Backend へ HTTP200 を返す

Slide 17

Slide 17 text

報酬振込周りのサブシステム化 ● 振込の銀行APIをもう一つ追加(外部APIの冗長化) ● 一定の確率でどちらかの外部APIにリクエストを送り負荷を分散させる

Slide 18

Slide 18 text

報酬振込周りのサブシステム化 ● 振込に失敗した場合は外部APIからWebhookが返ってくる ● 外部API → Timee SubSystem → Timee Backend の順番でWebhookの振込失敗を通知する

Slide 19

Slide 19 text

アクセス権限が明確に分離できる ● サブシステム化せずに本体APIで要所要所にアクセス制限を設定することもやろうと 思えばできなくはないかもしれない ● しかし、情報にアクセスできそうな抜け穴のパターンを全て考えて、その全てに対し て対応方針を決めなければならない → 検討漏れによるセキュリティ懸念や、管理コストの増大 ● ならシステムごと分離してアクセス権限を一括管理 してしまった方が楽 給与支払い周りのサブシステム化 サブシステム化して何が嬉しいの?

Slide 20

Slide 20 text

● リポジトリの分離 ○ コードの参照・更新を主要開発メンバーに限定 ○ デプロイやスクリプト実行を本体APIよりセキュアなルールで行うことができる ● ネットワーク、DB、環境変数の分離 ○ AWSアカウントレベルで本体APIと分離 ○ 本番の情報が直接参照できるのはごく一部のメンバーに限定 給与支払い周りのサブシステム化 具体的に何を分離したか?

Slide 21

Slide 21 text

● モジュラーモノリス→マイクロサービス化の先駆けとなる ○ もし将来的にやるなら、サブシステム化を通して得られた知見 を活かせる ● 小さいリポジトリのため技術的な制約を受けにくい ○ ライブラリバージョンアップや、RBS, Rubocop の新機能を試 して、本体APIにFBをすることもできる ● サブシステムのコンテナだけをスケールさせることができるので、効 率的なリソース利用ができる 給与支払い周りのサブシステム化 副次的なメリット Ruby, Rails は最 新バージョンです (ドヤ

Slide 22

Slide 22 text

4 サブシステム化をして 得られたもの

Slide 23

Slide 23 text

サブシステム化をして得られたもの 銀行APIのリクエスト上限の増加 ● 当初の約6倍まで上限が増えた 🎉 ● 向こう数年間はリクエスト上限の心配はなくなった ※ 2024年11月に3つ目の銀行APIを新しく追加してさらに上限数が伸びました

Slide 24

Slide 24 text

銀行APIの振込手数料削減 サブシステム化をして得られたもの ● 銀行APIへリクエストを送る度に振込手数料がかかり、年 間にかなりの額のコストがかかっていた ● 銀行APIが増えたことにより、振込手数料の高い他行振込 ではなく、同行振込で振込をするように最適化がしやすく なった ● 年間で最大2億円のコスト削減ができるようになった 💰💰

Slide 25

Slide 25 text

耐障害性の向上 ● 仮に1つの銀行APIが障害等でダウンしていても、もう一方の銀行APIにリクエ ストすることができるようになった ● サブシステム構築時に起き得る障害のパターンを可能な限り洗い出し、その全 てに対して適切なエラーハンドリングと障害対応フローを構築 ○ 一日数万件のリクエストを捌いているのにもかかわらず、リリースして からHTTP500エラーをほとんど出していない サブシステム化をして得られたもの

Slide 26

Slide 26 text

セキュリティの向上 サブシステム化をして得られたもの ● 外部ライブラリ管理 ○ dependabot を用いた定期更新 ○ trivy を用いたセキュリティ通知 ● 脆弱性診断 ○ 外部パートナーによる診断を実施、指摘へ対応済み ● ログへの漏洩対策 ○ 全情報についてのセキュリティレベルと取り扱い方針の決定と、実装 への反映

Slide 27

Slide 27 text

他にも色々 ... サブシステム化をして得られたもの ● スクラムのプロセス的な知見 ● メンテナンス性、開発者体験向上の取り組み ● QAプロセスの知見 ● 本番リリースで障害を起こさないためのカナリアリリース ● 社内でチームが表彰される🎉 ● etc…

Slide 28

Slide 28 text

まとめ ● 一部の機能をシステムごと分離することで、セキュリティを向上させつつ、アクセ ス権限の管理をしやすくできた ● 銀行APIを冗長化して負荷分散することでレートリミットの軽減や耐障害性を向 上させることができた ● 銀行APIへのリクエストを最適化することでコスト削減を実現できた

Slide 29

Slide 29 text

ご静聴ありがとうございました!