Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ID連携基盤のマイクロサービス移行プラクティス(freee技術の日)
Search
てらら
June 03, 2024
Technology
0
6.3k
ID連携基盤のマイクロサービス移行プラクティス(freee技術の日)
2024年のfreee技術の日の登壇で使用したスライドです。
配信動画は以下です。
https://youtu.be/Vrhpnizsc3g?t=1795s
てらら
June 03, 2024
Tweet
Share
More Decks by てらら
See All by てらら
freeeにおけるOAuth_OIDCの活用とAuthleteへの移行
terara
1
450
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
510
Other Decks in Technology
See All in Technology
LINE 購物幕後推手
line_developers_tw
PRO
0
330
地味にいろいろあった! 2025春のAmazon Bedrockアップデートおさらい
minorun365
PRO
2
550
製造業向けIoTソリューション提案資料.pdf
haruki_uiru
0
140
クラウドネイティブ環境の脅威モデリング
kyohmizu
1
290
Dynamic Reteaming And Self Organization
miholovesq
3
740
意思決定を支える検索体験を目指してやってきたこと
hinatades
PRO
0
390
Linuxのパッケージ管理とアップデート基礎知識
go_nishimoto
1
700
Compose におけるパスワード自動入力とパスワード保存
tonionagauzzi
0
190
C++26アップデート 2025-03
faithandbrave
0
1.2k
Новые мапы в Go. Вова Марунин, Clatch, МТС
lamodatech
0
1.6k
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
220
エンジニアリングで組織のアウトカムを最速で最大化する!
ham0215
1
280
Featured
See All Featured
Making Projects Easy
brettharned
116
6.2k
Music & Morning Musume
bryan
47
6.5k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
19
1.2k
Product Roadmaps are Hard
iamctodd
PRO
52
11k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
How to train your dragon (web standard)
notwaldorf
91
6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
14
1.4k
Scaling GitHub
holman
459
140k
Rails Girls Zürich Keynote
gr2m
94
13k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
34
2.2k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Speed Design
sergeychernyshev
29
920
Transcript
ID連携基盤のマイクロサー ビス移⾏プラクティス てらら 2024年5⽉31⽇
2 てらら • ホラー映画 • 猫 • 兎田ぺこら アカウント基盤部Identity Federationチーム
エンジニア
• freee IDを⽤いた OAuth2.0およびOpen ID Connect Core 1.0 における
認可サーバおよびOpenID Connect Provider ◦ 外部IDと連携する機能や内部システムのアクセス制御を司る機能は対 象外 ID連携基盤の範囲
• 移⾏の歴史と背景 • スタートアップの初期モノリスからの移⾏⽅式 • 今後について 今⽇話すこと
移⾏の歴史と背景
1. freee会計に全プロダクトの認証認可機能が内蔵されていた 2. freee会計のモノリスから認証認可基盤(旧認証認可基盤)が切り出さ れた(共有DB⽅式) 3. 旧認証認可基盤から新認証基盤へ認証機能を移⾏ 4. 旧認証認可基盤からID連携基盤へID連携機能を移⾏する
<- イマココ 移⾏の歴史と背景
freee会計のモノリスから旧認証認可基盤へ freee Developers Hub「これってもしかして……認証基盤が⼊れ替わってる〜?」より
旧認証認可基盤から認証基盤への切り出し freee Developers Hub「これってもしかして……認証基盤が⼊れ替わってる〜?」より
まだ旧認証認可基盤は⽣き残っていた…
旧認証認可基盤からID連携基盤を切り出す
スタートアップの初期モノリス からの移⾏⽅式
• 最初のサービスは機能提供スピードを重視し、1つのモノリスサービス に機能が集約される • 2つ⽬のサービスが開発される際にはサービス共通の機能‧データを初 期モノリスのAPIから利⽤する • ⼀定サービスが増えたときに初期モノリスの機能分離を⾏う際にはデー タ移⾏は慎重になり、アプリケーションサーバのみ分離する
(主にfreeeの場合) スタートアップの初期モノリスとは 「共通機能をいつどう切り出すか」という共通課題
1. 移⾏フェーズを⼆段階に分ける a. アプリケーション情報 b. アクセストークン情報 2. それぞれのフェーズでストラングラーフィグパターンを⽤いて置き換える 3.
それらを依存プロダクト単位に分けてリリースしていく ID連携基盤の移⾏⽅式
移⾏フェーズを⼆段階に分ける ID連携の機能はアプリケーション情報とアクセストークン情報(リフレッ シュトークンやIDトークンなど含む)に分割可能。アクセストークン情報 はアプリケーション情報に依存するが、逆の依存はないため。 そのため、今回はアプリケーション情報を先に移⾏した。
ストラングラーフィグパターンを⽤いる ストラングラーファサードには各サービスに配布している社内ライブラリ = 認証ライブラリを利⽤ 1. 旧サーバのI/Fを write / read
に分類する 2. writeする際に旧サーバと新サーバを直列にリクエストし、レスポンス 結果を⽐較する a. この時点では新旧差分は通知のみ 3. 同じくreadを実施する a. この時点では新旧差分は通知のみ 4. readのプライマリーなリクエストを新サーバに向け、レスポンス結果も 新サーバを採⽤する 5. 同じくwriteを実施する
ストラングラーフィグパターンを⽤いる
ストラングラーフィグパターンを⽤いる プライマリを⼊れ替える
• メリット ◦ モノリス時代から利⽤されていた社内ライブラリを応⽤可能 ◦ プロダクト単位で切り替え可能で切り戻しも柔軟 ◦ 追加I/Fへの対応も認証認可基盤を扱う開発チームがコントロール可 能
• デメリット ◦ プロダクト単位の社内ライブラリバージョン管理、切り替え管理が⾯ 倒 ストラングラーファサードに社内ライブラリを使うメリデメ
• Proxy Server ◦ プロダクト単位の切り替え/管理に⼀⼯夫必要 ◦ Proxy⾃体がSPOFであるため不採⽤ • envoyやmiddleware等のプロダクト前段に置く場合
◦ 現システム構成とギャップがあって出来なかった ◦ 移⾏後に仕様変更した⽅が影響が少ないため不採⽤ その他のストラングラーファサード例
freeeのプロダクト開発はユーザーに提供する価値のスピードにこだわっ ている。⼀⽅、ID連携基盤のようなプラットフォームチームの移⾏案件は そのスピードに寄与しないが、移⾏時にバグを出す(現新I/Fに差異が出 る)場合、プロダクトのスピードが落ちるどころか⽌まる。 I/Fの現新⼀致を担保し続けることでユーザーへの価値提供スピードに間 接的に貢献する。 移⾏⽅式の採⽤理由について補⾜ フェーズ分割‧デプロイ対象プロダクト分割‧差分検証 などの⼿段を取り、⽯橋を安全に渡ることが最重要
• リファクタリングが最重要 ◦ 本ケースでは5年以上前のロジックが未利⽤のまま放置されているこ とも多い ◦ 暫定処置が残っており、特に旧DBのインクリメンタルなIDに依存し ている機能もある ◦
未利⽤のI/Fやデータ‧画⾯項⽬を減らせば移⾏対象も減るため、余 計な機能開発も減るため品質保証対象も減り、トータルコストが下が る • アプリケーション情報を先に移⾏することでアクセストークン情報移⾏ 前にほとんどの課題が消化できた ◦ 社内アプリケーションの例外処理を切り分ける必要があった 気をつけていたこと、やってよかったこと
今後 • toBならではのリソースオーナーの曖昧さを解消していく ◦ リソースによってはオーナーが企業か従業員か。 ◦ 場合によってはアプリケーション操作ユーザーの認可とリソースオー ナーの認可を分ける可能性も。 •
出来たらいいな。リソースオーナーが提供する情報を選択できる⽅式へ • 社内開発者に優しいID連携基盤へ ◦ PublicAPIの実装簡素化、明瞭化 ◦ SPOFからの脱却
None