Affamative Way

前向きにグダグダいいながらコード書く

ベルフェイスのIDPを支えるアーキテクチャ

はじめに

この記事は🎄bellFace Advent Calendar 2021🎄の15日目の内容です。

adventar.org

自己紹介

今年の5月にベルフェイス株式会社にCTO室長としてJOINしてました id:cos31 こと北上です

bs.bell-face.com

外向けの文章なんて、ウン年ぶり*1のせっかくの機会なので、みんなが Notionづいている中で、今後の継続を込めてここで書きます!

ブログの空白期間としては、KLab → DeNAリクルート → ベルフェイス と各所で頑張っておりました

CTO室としての取り組みは @zigorou さんの一年の振り返りを見てもらうとして zigorou.super.site

現在取り組んでいる ID基盤刷新にまつわるアーキテクチャをご紹介させていただきます

ID基盤とは

詳細は省き、簡単にいうとこんな役割です

  • 安全に複数サービスに対しての横断的な認証・認可の仕組みを提供する
  • ユーザ、クライアント毎に権限設定を一元管理する
  • システム間の責務分担を明確にし、適切で必要な権限を用いて利用可能とする

今回は要件的に、IDaaS を利用せず OpenID ConnectOpenID Provider を自社で作ることを選択しました

既存の認証の必要だったシステムを Relying Party として利用する形式をとります

システムアーキテクチャ

いわゆる、BFF アーキテクチャを採用し、Backend API を呼び出す形です

f:id:cos31:20211214233253p:plain
Component Architecture

現フェーズではコンポーネント間をまたいだDBへの参照及び、Queueへのジョブ追加を許容し、書き込みに関しては各コンポーネントに閉じて実施しています

Identity API は、OpenID Connect Session Management として、 ステートレスなAPIではなく認証状態の管理を行います*2

Frontend

Express Custom Server の一部を Next.js を SSR*3利用し、BFF*4 として構築しています

f:id:cos31:20211214232423p:plain

また、OIDC*5特有の 一部のエンドポイントではUIなしでの処理をするフローも存在しています

frontendの技術顧問として参画いただいている @quramy に実装基盤を作成していただきました

採用ライブラリ

Backend

レイヤードアーキテクチャによる go な APIサーバー を採用しました

Layered Architecture

レイヤーで責務を分けることで、テストを容易にし、かつそれぞれのパッケージや構造体をシンプルに、依存の方向もシンプルかつ最小限となることを期待して採用しています

採用ライブラリ

goの技術顧問として参画いただいている @gami に実装基盤を作成していただきました

現在は別の進化を遂げていますが、ベースとなったものは公開されていますので、詳細はご参考ください

github.com

Frontend と Backend の並走開発

Frontend と Backend にて技術スタック別にメンバーを分担して開発を進めていました 接合点として、Frontend と API を設計をした Design Doc*6*7 にて合意します

DesginDocシーケンスのイメージ

Design Doc の API のふるまいをベースに、個別でスキーマ定義を行い、両チームがブロッカーとならないようにしています

  • Backend は OpenAPI 形式のコード生成
  • Frontend は agreed による Type定義 及び スタブサーバーの起動

スキーマ定義は、お互いの関心が、違うため自由度を持つためにあえて個別化しています

  • Backend では、IF定義と実データの振る舞いが重要
    • ポータブルでコード生成しやすい定義ファイルがほしい
  • Frontend では、API 応答のバリエーションを持つスタブと型定義
    • DBには興味はないので、柔軟なエラーやレスポンスのバリエーションを持ったスタブサーバがほしい

初期開発は自身の領域に集中して取り組み、Frontend と Backend 結合期間にて、細かい調整を行いました

なお、別のスキーマ定義があることが多重管理されることの懸念となりますが、agreed は Open API 定義を出力可能できるので、今後のフローとしては、Desgin Doc → agreed → Open API となります

まとめ

Open ID Connect 実装という、なかなかこってりした仕組みのため、UI と 認証のビジネスロジックをわける過程の整理・設計は大変でした。。

しかし、その甲斐あって、分担して開発していくフェーズでは、お互いに知らなくていことは把握せずとも、個別の開発進行ができました!*8

WE ARE HIRING!

OpenID Connectや、go な API & Next.js で 開発しながら爆発的成長したいエンジニアの皆様 hrmos.co

顧客が本当に欲しかったものを考えることが好きなプロダクトマネージャ、営業領域におけるDXを推進してみたい営業など、様々な職種で募集しております! hrmos.co

まずは、カジュアルに話すところから始めませんか?*9 meety.net

Who's NEXT

デザインチームの皆様での、リバースモデリングの話 です

個人的にも非常に楽しみにしてます!

adventar.org

*1:まともな記事としては10年ぶりという。。

*2:RP-Initiated Logoutなどを実装するので、Session Management が必要 https://openid.net/specs/openid-connect-rpinitiated-1_0.html

*3:Server Side Rendering

*4:Browser for Frontend

*5:Open ID Connectの略称

*6:Design Docs at Google https://www.industrialempathy.com/posts/design-docs-at-google/

*7:上級エンジニアになるための Design Doc 超入門 https://www.atmarkit.co.jp/ait/articles/1606/21/news016.html

*8:もちろん間に立って両方を把握する人もいます

*9:と、いいつつ僕がいないのでご用命あれば、twitterで気軽に呼んでください