オブザーバビリティと育てた ID管理・認証認可基盤の歩み / The Journey of an ID Management, Authentication, and Authorization Platform Nurtured with Observability

by 株式会社カミナシ

Slide 1

Slide 1 text

オブザーバビリティと育てた ID管理・認証認可基盤の歩み Manato Takai, Ph. D. Observability Conference Tokyo 2025

Slide 2

Slide 2 text

自己紹介高井　真人株式会社カミナシでID管理・認証認可基盤の開発をしています。好きなRFCは8628。博士（工学） X：@manaty0226

Slide 3

Slide 3 text

カミナシにおけるマルチテナント・マルチプロダクト ID管理・認証認可基盤

Slide 4

Slide 4 text

ノンデスクワーカーの才能を解き放つ Mission

Slide 5

Slide 5 text

カミナシ社におけるID管理・認証認可基盤の立ち位置 “現場の基盤” カミナシ 3つの領域をまたぐデジタルインフラに Method 作業 Man ⼈ Machine 設備電⼦帳票マニュアル‧研修コミュニケーション設備カルテ 1つのアカウントで複数のシステムを利⽤。運⽤の負担軽減とセキュリティ向上。

Slide 6

Slide 6 text

マルチテナント・マルチプロダクトSaaSのID管理・認証認可基盤テナント#1 テナント#n 認証認可ユーザー管理組織マスタ管理 … …

Slide 7

Slide 7 text

マルチテナント・マルチプロダクトSaaSのID管理・認証認可基盤ログイン/ログアウトアクセストークン検証、更新ユーザーやマスタ情報の参照テナント#1 テナント#n 認証認可ユーザー管理組織マスタ管理 … …

Slide 8

Slide 8 text

ID管理・認証認可基盤におけるオブザーバビリティを必要とする課題

Slide 9

Slide 9 text

認証認可基盤における課題サーバーテナント#1 テナント#n … ユーザーやマスタの参照といったリクエストに対しては、一般的なWeb APIサーバーと同様にI/Oがボトルネックとなりやすい

Slide 10

Slide 10 text

認証認可基盤における課題サーバーテナント#1 テナント#n … 認証認可基盤として必要なトークンの発行や検証では、暗号化、署名、ハッシュといった処理が必要で、CPUがボトルネックとなりやすい

Slide 11

Slide 11 text

認証認可基盤における課題サーバーテナント#1 テナント#n … OpenID Connect ライブラリ暗号化ライブラリ署名・検証ハッシュ関数 DBアクセスリクエスト・レスポンス処理セキュリティのコアな処理がライブラリ依存でブラックボックスのため、ボトルネックの発見と改善が難しくなりやすい

Slide 12

Slide 12 text

オブザーバビリティの向上とともに目指したいチームの姿

Slide 13

Slide 13 text

オブザーバビリティの捉え方 Kalmanは1960年の論文で、ある特徴をオブザーバビリティと名付け、数学的制御システムを説明しました。制御理論では、オブザーバビリティとは、外部出力の知識からシステムの内部状態をどれだけうまく推測できるかの尺度として定義されています。引用：C. Majors, Liz Fong-Jones, G. Miranda 「オブザーバビリティエンジニアリング」O’Reilly, Jan. 2023,

Slide 14

Slide 14 text

Software Engineer as a Kalman Filter 真のシステム状態入力真の出力

Slide 15

Slide 15 text

Software Engineer as a Kalman Filter 真のシステム状態入力推定したシステム状態真の出力できるだけ一致させたい

Slide 16

Slide 16 text

Software Engineer as a Kalman Filter 真のシステム状態入力推定したシステム状態真の出力推定した出力できるだけ一致させたい

Slide 17

Slide 17 text

Software Engineer as a Kalman Filter 真のシステム状態入力推定したシステム状態真の出力推定した出力できるだけ一致させたい推定誤差

Slide 18

Slide 18 text

Software Engineer as a Kalman Filter 真のシステム状態入力推定したシステム状態真の出力推定した出力できるだけ一致させたい推定誤差誤差が小さくなるようにフィードバック

Slide 19

Slide 19 text

Software Engineer as a Kalman Filter 真のソフトウェアの状態推定したソフトウェアの状態

Slide 20

Slide 20 text

Software Engineer as a Kalman Filter 真のソフトウェアの状態ユーザーや外部システムの操作推定したソフトウェアの状態シグナル（ログ、トレース、メトリクス...etc.）推測した処理結果

Slide 21

Slide 21 text

Software Engineer as a Kalman Filter 真のソフトウェアの状態ユーザーや外部システムの操作推定したソフトウェアの状態シグナル（ログ、トレース、メトリクス...etc.）推測した処理結果推定の誤り対象のソフトウェアの理解をアップデートソフトウェアの理解をアップデートし、真の内部状態に近づけようとする行為全体がオブザーバビリティ向上の一環

Slide 22

Slide 22 text

ここから話していくこと ● マルチテナント・マルチプロダクトのID管理・認証認可基盤の立ち上げ〜現在までに、どのようにオブザーバビリティスタックを進化させてきたか ● オブザーバビリティを向上し活用した事例 1. コアな処理がブラックボックスな認可機能において、どのようにボトルネックを発見し、改善策を実装していったのか 2. チームメンバーがソフトウェアの内部状態をうまく推定し、ビジネスやプロダクトのスケールにあわせて継続的に性能改善していくために何をしたのか 3. オブザーバビリティの力を、性能や内部品質改善だけでなくエンドユーザーの体験改善にどのようにつなげたのか

Slide 23

Slide 23 text

オブザーバビリティとともに育てた ID管理・認証認可基盤

Slide 24

Slide 24 text

カミナシのサービス開発チーム体制 ID管理・認証認可チームセキュリティエンジニアリングチームレポートチーム … 開発運用カミナシのエンジニアリング組織では、各サービスの開発チームに自律的に動けるようになっている。まだSRE専門チームのような横断的組織はないため、オブザーバビリティスタックはマネージドサービスを駆使しながら、ビジネスやシステムのスケールに合わせて身の丈にあった技術選定をしながら進化させた開発運用

Slide 25

Slide 25 text

認証機能の切り出し〜基盤立ち上げ初期の構成外形的な監視やE2Eの性能は切り出し元のオブザーバビリティツールを利用ログはInfoレベルも含めて厚めに出力メトリクスはエラーなど最低限可用性に関わるもの既存のシングルプロダクトから認証機能を切り出し基盤として立ち上げるフェーズでは、チームメンバーが2名だったこともあり、AWSマネージドの機能を利用して最低限のログとメトリクスを取得。性能については既存プロダクトの監視ツールでクライアント側から外形監視した。 CDN （CloudFront）ロードバランサー（ALB） ID管理・認証認可 APIサーバー（ECS）ログ・メトリクス（CloudWatch）データベース（Aurora）

Slide 26

Slide 26 text

OpenID Connectへの対応によるブラックボックス処理の増加とマルチプロダクト化新規プロダクトが増えた段階でOpenID Connectに対応して、処理のブラックボックス化が進んだことや、チームメンバーが増えたことからトレースを取得して組織的にオブザーバビリティを高めることを意識しはじめた。ログルーター OpenTelemetry Collector トレース（X-Ray）ログ・メトリクス（CloudWatch）独自認証方式からOpenID Connectに対応 →ブラックボックスな処理や署名処理など　が増加可視化・分析（Grafana）

Slide 27

Slide 27 text

ビジネスとシステムのスケールに応じたオブザーバビリティの進化各プロダクトの契約数が増えて大規模なテナントが出てきた中で、例えば大規模テナントに着目して細かくメトリクスのディメンションを設定したり、柔軟にクエリして分析しながら更なるスケーリングに備えるため、アプリケーションメトリクスをPrometheusから取得する構成に変更。ログルーター OpenTelemetry Collector ログ・メトリクス（CloudWatch）トレース（X-Ray）可視化・分析（Grafana）メトリクス（Prometheus）

Slide 28

Slide 28 text

私たちが得た「見る力」、「わかる力」、「伝える力」

Slide 29

Slide 29 text

事例 1 OAuthクライアント認証処理のボトルネック把握と改善

Slide 30

Slide 30 text

事例 1：OAuthクライアント認証処理のボトルネック把握と改善 ID管理・認証認可基盤クライアントトークンリクエストトークンレスポンスログイン時や、セッション継続中のアクセストークンリフレッシュ時に、各プロダクトはアクセストークンやリフレッシュトークンの発行をID管理・認証認可基盤にリクエストする。トークンリクエストに対する応答の間に、CPUバウンドな処理とI/Oバウンドな処理が混在し、処理の殆どはライブラリに隠されているため原因を推し量るのは難しい。クライアント認証認可コード/リフレッシュトークン検証新規トークン生成レスポンス作成リクエスト検証

Slide 31

Slide 31 text

事例 1：OAuthクライアント認証処理のボトルネック把握と改善 ID管理・認証認可基盤クライアント認証認可コード/リフレッシュトークン検証新規トークン生成レスポンス作成リクエスト検証トレースから以下の2つの原因を推測 1.　ライブラリが一連の処理の中でクライアント情報を何度もDBから　　読み出すことによる非効率なI/Oアクセスライブラリ自体をフォークして手を入れたくないので、静的なクライアント情報をキャッシュしてI/Oアクセスを回避ゲートウェイ関数キャッシュ

Slide 32

Slide 32 text

事例 1：OAuthクライアント認証処理のボトルネック把握と改善 ID管理・認証認可基盤クライアント認証認可コード/リフレッシュトークン検証新規トークン生成レスポンス作成リクエスト検証トレースから以下の2つの原因を推測 1.　ライブラリが一連の処理の中でクライアント情報を何度もDBから　　読み出すことによる非効率なI/Oアクセス 2.　ライブラリ処理の中で何らかのCPUボトルネックな処理が発生ライブラリ自体をフォークして手を入れたくないので、静的なクライアント情報をキャッシュしてI/Oアクセスを回避ライブラリのトレース計装が不十分だったため、大まかにボトルネック箇所を特定してローカルで追加計装したうえで、プロファイラも使いながらボトルネックを探索

Slide 33

Slide 33 text

事例 1：OAuthクライアント認証処理のボトルネック把握と改善 ID管理・認証認可基盤クライアント認証認可コード/リフレッシュトークン検証新規トークン生成レスポンス作成リクエスト検証最も大きなボトルネックはクライアントシークレット比較時のハッシュ関数と判明しかし、ハッシュ関数はCPU演算量を増やすことに意味があるため効率化は難しいそこで、クライアント認証方式を変更してハッシュ関数を回避してボトルネックを解消クライアント ID管理・認証認可基盤クライアントID+ シークレットハッシュ計算

Slide 34

Slide 34 text

Slide 35

Slide 35 text

事例 1：OAuthクライアント認証処理のボトルネック把握と改善処理時間のp99が1/5程度に改善最もリクエスト数の多いプロダクトから適用したところ、同時間帯のトークンリクエストに対する処理時間のp99が従来のクライアントシークレット方式に比べて1/5程度まで改善した

Slide 36

Slide 36 text

事例 2 サービスレビューによる組織的な「見る力」「わかる力」の向上とシステムの継続的改善

Slide 37

Slide 37 text

事例 2：サービスレビューによる組織的な見る力、わかる力の向上と継続的な改善 ID管理・認証認可基盤以下の観点で週次レポートを作成傾向の変化や課題を確認 ● パフォーマンス ● エラー ● コストサービスレビューの結果をフィードバックユーザー数や利用パターンの異なる複数のプロダクト、多数のテナントからのリクエストを捌く基盤としてスケーリングしていく中で、組織的にソフトウェアへの理解を高めるために週次でID管理・認証認可基盤のパフォーマンスやエラー、コストを確認し議論するサービスレビューの仕組みを導入チーム内でシステムに対する理解や勘所を継承していく

Slide 38

Slide 38 text

事例 2：サービスレビューによる組織的な見る力、わかる力の向上と継続的な改善パフォーマンス ● パフォーマンスメトリクスにおける先週との比較 ● パフォーマンスメトリクスの長期的（月単位）の傾向 ● 特に時間のかかっているエンドポイントはなにか ● 前週に対処したエンドポイントの状況確認エラー ● 想定していないエラーは出ていないか ● 不要なエラーが出ていないか ● パフォーマンスと関連するエラーの状況コスト ● コストの先週との比較 ● コストの長期的（月単位）の傾向 ● 特にコストのかかっているAWSサービスはなにか ● 前週に対処したコストの状況確認具体的には以下の観点でパフォーマンス、エラー、コストを確認している。課題を発見したら必要なものはチケット化して次以降のスプリントで逐次対処していくことで、サービスがスケールしていく中でもパフォーマンスやコストの改善を図っている。

Slide 39

Slide 39 text

事例 3 ユーザーの操作エラー検知によるプロアクティブなカスタマーサクセス

Slide 40

Slide 40 text

事例 3：ユーザー操作エラーの検知によるプロアクティブなカスタマーサクセス ID管理・認証認可基盤ユーザー情報組織マスタ CSVの情報フォーマットや個々の要素の入力規則に慣れるまで入力起因のエラーが増えるエンタープライズをはじめとして大規模なテナントが増えてくると、大量のユーザー情報やマスタ情報を登録、更新する必要が出てくるため、CSVなどによる一括操作機能が求められる。一方で、Web UIのようにわかりやすくバリデーションをかけて表示したりインタラクションがとれないため、 CSVのカラムフォーマットや個々の要素の入力規則に慣れるまではユーザー入力起因のエラーが増える。

Slide 41

Slide 41 text

事例 3：ユーザー操作エラーの検知によるプロアクティブなカスタマーサクセス ID管理・認証認可基盤メトリクス ● 失敗率が想定より低くなっていないか ● 同じユーザーが極端に何度も失敗していないかログ ● どこでユーザーが失敗しているか ● 同じような失敗を複数のユーザーが繰り返していないか CSVによる情報操作を実行するサーバーのシグナルだけでなく、ユーザーの操作起因で発生するエラーについてもメトリクスを収集したり、改善につながるログを出力

Slide 42

Slide 42 text

事例 3：ユーザー操作エラーの検知によるプロアクティブなカスタマーサクセス ID管理・認証認可基盤サービス開発チーム極端に連続して失敗しているユーザーを把握担当のカスタマーサクセスに連絡プロアクティブにサポートオブザーバビリティをユーザーの操作にも広げることで、サービス利用体験全体のマイナス影響を最小限にしたうえで、プロダクトとして必要な改善へのフィードバックにもつなげる

Slide 43

Slide 43 text

事例 3：ユーザー操作エラーの検知によるプロアクティブなカスタマーサクセス ID管理・認証認可基盤サービス開発チーム極端に連続して失敗しているユーザーを把握担当のカスタマーサクセスに連絡プロアクティブにサポート迅速なサポートによりお客様との関係性をより強固に失敗しやすい箇所を把握しオンボーディング改善機能やドキュメント、 UIの改善オブザーバビリティをユーザーの操作にも広げることで、サービス利用体験全体のマイナス影響を最小限にしたうえで、プロダクトとして必要な改善へのフィードバックにもつなげる

Slide 44

Slide 44 text

まとめ ● ID管理・認証認可基盤におけるオブザーバビリティで解決したい課題 ○ I/OボトルネックとCPUボトルネックの混在 ○ CPUボトルネックを引き起こしやすい暗号化処理などのライブラリによるブラックボックス化 ● めざしたい姿 ○ Software Engineer as a Kalman ﬁlter ○ 可観測性と、ソフトウェア内部状態に対する組織的な推定能力の向上 ○ 定期的なサービスレビューによる推定能力の継承 ● オブザーバビリティと育てたID管理・認証認可基盤 ○ 最初は小さく、ビジネスやシステムのスケールに合わせて徐々に大きく ○ ブラックボックスな処理もトレースから読み解いていく ○ メトリクスやログからユーザー体験も改善していける

Slide 45

Slide 45 text

株式会社カミナシ https://kaminashi.jp