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連携基盤を切り出す

　 スタートアップの初期モノリス からの移⾏⽅式

　 ● 最初のサービスは機能提供スピードを重視し、１つのモノリスサービス に機能が集約される ● ２つ⽬のサービスが開発される際にはサービス共通の機能‧データを初 期モノリスの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からの脱却

No content