Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ID連携基盤のマイクロサービス移行プラクティス(freee技術の日)
Search
てらら
June 03, 2024
Technology
0
3.4k
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
460
Other Decks in Technology
See All in Technology
2024年のModern Data Stackを振り返ろう~分野別の目玉アップデート情報まとめ~
sagara
0
160
品質管理チームのEMとして大事にしていること / QA EM
nihonbuson
0
810
プロセス改善とE2E自動テストによる、プロダクトの品質向上事例
tomasagi
1
3.6k
【ASW21-01】STAMPSTPAで導き出した課題に対する対策立案手法の提案
hianraku9498
0
580
pmconf2024_UPSIDER
upsider_tech
0
7.2k
Ruby on Browser - RubyWorld Conference 2024
tmtms
1
110
Reliability Engineering at Studist
katsuhisa91
PRO
0
120
EthernetベースのGPUクラスタ導入による学びと展望
lycorptech_jp
PRO
0
580
Will Positron accelerate us?
lycorptech_jp
PRO
1
120
Replit Agent
kawaguti
PRO
2
180
WED Company Deck for Engineer
wed
2
3.7k
Autonomous Database サービス・アップデート (FY25)
oracle4engineer
PRO
0
260
Featured
See All Featured
RailsConf 2023
tenderlove
29
920
BBQ
matthewcrist
85
9.3k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
How GitHub (no longer) Works
holman
310
140k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Rails Girls Zürich Keynote
gr2m
94
13k
Code Reviewing Like a Champion
maltzj
520
39k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
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