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
4.9k
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
320
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
490
Other Decks in Technology
See All in Technology
遷移の高速化 ヤフートップの試行錯誤
narirou
6
2k
20250304_赤煉瓦倉庫_DeepSeek_Deep_Dive
hiouchiy
2
130
DeepSeekとは?何がいいの? - Databricksと学ぶDeepSeek! 〜これからのLLMに備えよ!〜
taka_aki
1
180
どちらかだけじゃもったいないかも? ECSとEKSを適材適所で併用するメリット、運用課題とそれらの対応について
tk3fftk
2
280
Apache Iceberg Case Study in LY Corporation
lycorptech_jp
PRO
0
380
AI自体のOps 〜LLMアプリの運用、AWSサービスとOSSの使い分け〜
minorun365
PRO
9
1.1k
AIエージェント元年@日本生成AIユーザ会
shukob
1
260
User Story Mapping + Inclusive Team
kawaguti
PRO
3
480
事業を差別化する技術を生み出す技術
pyama86
2
540
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
2
120
いまからでも遅くない!コンテナでWebアプリを動かしてみよう!コンテナハンズオン編
nomu
0
180
事業モメンタムを生み出すプロダクト開発
macchiitaka
0
110
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
We Have a Design System, Now What?
morganepeng
51
7.4k
Building Applications with DynamoDB
mza
93
6.2k
Producing Creativity
orderedlist
PRO
344
40k
Scaling GitHub
holman
459
140k
Building an army of robots
kneath
303
45k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
Code Reviewing Like a Champion
maltzj
521
39k
4 Signs Your Business is Dying
shpigford
183
22k
Statistics for Hackers
jakevdp
797
220k
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