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.1k
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
420
Other Decks in Technology
See All in Technology
自作Cコンパイラ 8時間の奮闘
soukouki
0
750
社内の学びの場・コミュニティ形成とエンジニア同士のリレーションシップ構築/devreljapan2024
nishiuma
3
240
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
300
LLVM/ASMを使った有限体の高速実装
herumi
0
120
不動産tech Product Night#2_AIことはじめ_GA橋本
takehikohashimoto
0
120
Agile in Automotive Industry, puzzles and lights.
hiranabe
2
580
2024年版 運用者たちのLLM
nwiizo
3
570
Oracle Cloud Infrastructure IaaS 新機能アップデート 2024/6 - 2024/8
oracle4engineer
PRO
0
110
「家族アルバム みてね」における運用管理・ オブザーバビリティの全貌 / Overview of Operation Management and Observability in FamilyAlbum
isaoshimizu
4
150
AWS SAW を広めたい @四国クラウドお遍路
kazzpapa3
0
220
AWSを始めた頃に陥りがちなポイントをまとめてみた
oshanqq
1
3.4k
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
0
13k
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
48
13k
How to train your dragon (web standard)
notwaldorf
85
5.6k
Build The Right Thing And Hit Your Dates
maggiecrowley
30
2.3k
Optimising Largest Contentful Paint
csswizardry
30
2.8k
The Cost Of JavaScript in 2023
addyosmani
42
5.2k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
157
15k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
Art, The Web, and Tiny UX
lynnandtonic
294
20k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.3k
Adopting Sorbet at Scale
ufuk
73
8.9k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
326
21k
GraphQLとの向き合い方2022年版
quramy
43
13k
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