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
2.6k
ID連携基盤のマイクロサービス移行プラクティス(freee技術の日)
2024年のfreee技術の日の登壇で使用したスライドです。
配信動画は以下です。
https://youtu.be/Vrhpnizsc3g?t=1795s
てらら
June 03, 2024
Tweet
Share
More Decks by てらら
See All by てらら
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
440
Other Decks in Technology
See All in Technology
Why and Why not of enabling swap in Kubernetes
hwchiu
0
340
APIs for AI: Have we failed?
zdne
0
140
LeSS Yoake 2024 スポンサーセッション
riki_hiraoka
0
240
Brakeman を欺く - Kashiwa.rb #4
kozy4324
1
110
カメラ単体で物体の3次元 座標を扱う方法
kenmatsu4
1
190
外部カンファレンスで登壇しよう! 〜「強い」エンジニアへの一歩を踏み出す〜
logica0419
4
140
エンジニアのドメイン知識獲得コストを低減するアプリケーションデザイン
ryo_nagata_
3
180
最新のWasm事情
askua
5
2.6k
Snowflakeでスロークエリ改善に取り組んだ話
tabata0208
0
150
Rist_Meetup_Kaggleは業務の役にたつ - ビジネスコンテンツ情報を活用する BtoB 事業編 - / rist-meetup-20241012
taro_masuda
1
370
なぜ Rack を理解すべきかプレトーク / Why should you understand Rack - Pre-talk
hogelog
0
250
Amplify Gen 2ではじめる 生成AIアプリ開発入門
tsukuboshi
0
410
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1365
200k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
26
730
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
The Cost Of JavaScript in 2023
addyosmani
44
5.9k
Designing on Purpose - Digital PM Summit 2013
jponch
114
6.9k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.3k
How GitHub (no longer) Works
holman
311
140k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
How STYLIGHT went responsive
nonsquared
95
5.1k
Six Lessons from altMBA
skipperchong
26
3.4k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
350
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