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

2025/10/27
Observability Conference Tokyo 2025
https://o11ycon.jp/

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

高井 真人
エンジニアリングマネージャー

Transcript

1. オブザーバビリティと育てた ID管理・認証認可基盤の歩み Manato Takai, Ph. D. Observability Conference Tokyo 2025
2. 自己紹介 高井　真人 株式会社カミナシでID管理・認証認可基盤 の開発をしています。 好きなRFCは8628。 博士（工学） X：@manaty0226
3. カミナシにおける マルチテナント・マルチプロダクト ID管理・認証認可基盤
4. ノンデスクワーカーの 才能を解き放つ Mission
5. カミナシ社におけるID管理・認証認可基盤の立ち位置 “現場の基盤” カミナシ 3つの領域をまたぐデジタルインフラに Method 作業 Man ⼈ Machine 設備 電⼦帳票 マニュアル‧研修 コミュニケーション 設備カルテ 1つのアカウントで複数のシステムを利⽤。運⽤の負担軽減とセキュリティ向上。
6. マルチテナント・マルチプロダクトSaaSのID管理・認証認可基盤 テナント#1 テナント#n 認証認可 ユーザー管理 組織マスタ管理 … …
7. マルチテナント・マルチプロダクトSaaSのID管理・認証認可基盤 ログイン/ログアウト アクセストークン検証、更新 ユーザーやマスタ情報の参照 テナント#1 テナント#n 認証認可 ユーザー管理 組織マスタ管理 … …
8. ID管理・認証認可基盤における オブザーバビリティを必要とする課題
9. 認証認可基盤における課題 サーバー テナント#1 テナント#n … ユーザーやマスタの参照といったリクエスト に対しては、一般的なWeb APIサーバーと 同様にI/Oがボトルネックとなりやすい
10. 認証認可基盤における課題 サーバー テナント#1 テナント#n … 認証認可基盤として必要なトークンの発行や検証 では、暗号化、署名、ハッシュといった処理が 必要で、CPUがボトルネックとなりやすい
11. 認証認可基盤における課題 サーバー テナント#1 テナント#n … OpenID Connect ライブラリ 暗号化ライブラリ 署名・検証 ハッシュ関数 DBアクセス リクエスト・レスポンス 処理 セキュリティのコアな処理がライブラリ依存で ブラックボックスのため、ボトルネックの発見と 改善が難しくなりやすい
12. オブザーバビリティの向上とともに 目指したいチームの姿
13. オブザーバビリティの捉え方 Kalmanは1960年の論文で、ある特徴をオブザーバビリティ と名付け、数学的制御システムを説明しました。制御理論で は、オブザーバビリティとは、外部出力の知識からシステム の内部状態をどれだけうまく推測できるかの尺度として定義 されています。 引用：C. Majors, Liz Fong-Jones, G. Miranda 「オブザーバビリティエンジニアリング」O’Reilly, Jan. 2023,
14. Software Engineer as a Kalman Filter 真のシステム状態 入力 真の 出力
15. Software Engineer as a Kalman Filter 真のシステム状態 入力 推定した システム状態 真の 出力 できるだけ一致させたい
16. Software Engineer as a Kalman Filter 真のシステム状態 入力 推定した システム状態 真の 出力 推定した 出力 できるだけ一致させたい
17. Software Engineer as a Kalman Filter 真のシステム状態 入力 推定した システム状態 真の 出力 推定した 出力 できるだけ一致させたい 推定誤差
18. Software Engineer as a Kalman Filter 真のシステム状態 入力 推定した システム状態 真の 出力 推定した 出力 できるだけ一致させたい 推定誤差 誤差が小さくなるようにフィードバック
19. Software Engineer as a Kalman Filter 真の ソフトウェアの状態 推定した ソフトウェアの状態
20. Software Engineer as a Kalman Filter 真の ソフトウェアの状態 ユーザーや 外部システム の操作 推定した ソフトウェアの状態 シグナル （ログ、トレース、 メトリクス...etc.） 推測した 処理結果
21. Software Engineer as a Kalman Filter 真の ソフトウェアの状態 ユーザーや 外部システム の操作 推定した ソフトウェアの状態 シグナル （ログ、トレース、 メトリクス...etc.） 推測した 処理結果 推定の 誤り 対象のソフトウェアの理解をアップデート ソフトウェアの理解をアップデートし、真の内部状態に近づけようとする行為全体が オブザーバビリティ向上の一環
22. ここから話していくこと • マルチテナント・マルチプロダクトのID管理・認証認可基盤の立ち上げ〜現在までに、 ど のようにオブザーバビリティスタックを進化させてきたか • オブザーバビリティを向上し活用した事例 1. コアな処理がブラックボックスな認可機能において、どのようにボトルネックを発見 し、改善策を実装していったのか 2. チームメンバーがソフトウェアの内部状態をうまく推定し、ビジネスやプロダクトの スケールにあわせて継続的に性能改善していくために何をしたのか 3. オブザーバビリティの力を、性能や内部品質改善だけでなくエンドユーザーの体験改 善にどのようにつなげたのか
23. オブザーバビリティとともに育てた ID管理・認証認可基盤
24. カミナシのサービス開発チーム体制 ID管理・認証認可 チーム セキュリティエンジニアリングチーム レポートチーム … 開発 運用 カミナシのエンジニアリング組織では、各サービスの開発チームに自律的に動けるようになっている。 まだSRE専門チームのような横断的組織はないため、オブザーバビリティスタックはマネージドサービスを 駆使しながら、ビジネスやシステムのスケールに合わせて身の丈にあった技術選定をしながら進化させた 開発 運用
25. 認証機能の切り出し〜基盤立ち上げ初期の構成 外形的な監視やE2Eの性能は切り出し元の オブザーバビリティツールを利用 ログはInfoレベルも含めて厚めに出力 メトリクスはエラーなど最低限可用性に関わるもの 既存のシングルプロダクトから認証機能を切り出し基盤として立ち上げるフェーズでは、 チームメンバーが2名だったこともあり、AWSマネージドの機能を利用して最低限のログとメトリクス を取得。性能については既存プロダクトの監視ツールでクライアント側から外形監視した。 CDN （CloudFront） ロードバランサー （ALB） ID管理・認証認可 APIサーバー （ECS） ログ・メトリクス （CloudWatch） データベース （Aurora）
26. OpenID Connectへの対応によるブラックボックス処理の増加とマルチプロダクト化 新規プロダクトが増えた段階でOpenID Connectに対応して、処理のブラックボックス化が進んだことや、 チームメンバーが増えたことからトレースを取得して組織的にオブザーバビリティを高めることを意識し はじめた。 ログルーター OpenTelemetry Collector トレース （X-Ray） ログ・メトリクス （CloudWatch） 独自認証方式からOpenID Connectに対応 →ブラックボックスな処理や署名処理など　 が増加 可視化・分析 （Grafana）
27. ビジネスとシステムのスケールに応じたオブザーバビリティの進化 各プロダクトの契約数が増えて大規模なテナントが出てきた中で、例えば大規模テナントに着目して細か くメトリクスのディメンションを設定したり、柔軟にクエリして分析しながら更なるスケーリングに備え るため、アプリケーションメトリクスをPrometheusから取得する構成に変更。 ログルーター OpenTelemetry Collector ログ・メトリクス （CloudWatch） トレース （X-Ray） 可視化・分析 （Grafana） メトリクス（Prometheus）
28. 私たちが得た 「見る力」、「わかる力」、「伝える力」
29. 事例 1 OAuthクライアント認証処理の ボトルネック把握と改善
30. 事例 1：OAuthクライアント認証処理のボトルネック把握と改善 ID管理・認証認可基盤 クライアント トークンリクエスト トークンレスポンス ログイン時や、セッション継続中のアクセストークンリフレッシュ時に、各プロダクトは アクセストークンやリフレッシュトークンの発行をID管理・認証認可基盤にリクエストする。 トークンリクエストに対する応答の間に、CPUバウンドな処理とI/Oバウンドな処理が混在し、 処理の殆どはライブラリに隠されているため原因を推し量るのは難しい。 クライアント認証 認可コード/リフレッ シュトークン検証 新規トークン生成 レスポンス作成 リクエスト検証
31. 事例 1：OAuthクライアント認証処理のボトルネック把握と改善 ID管理・認証認可基盤 クライアント認証 認可コード/リフレッ シュトークン検証 新規トークン生成 レスポンス作成 リクエスト検証 トレースから以下の2つの原因を推測 1.　ライブラリが一連の処理の中でクライアント情報を何度もDBから 　　読み出すことによる非効率なI/Oアクセス ライブラリ自体をフォークして手を入れたくないので、 静的なクライアント情報をキャッシュしてI/Oアクセスを回避 ゲートウェイ関数 キャッシュ
32. 事例 1：OAuthクライアント認証処理のボトルネック把握と改善 ID管理・認証認可基盤 クライアント認証 認可コード/リフレッ シュトークン検証 新規トークン生成 レスポンス作成 リクエスト検証 トレースから以下の2つの原因を推測 1.　ライブラリが一連の処理の中でクライアント情報を何度もDBから 　　読み出すことによる非効率なI/Oアクセス 2.　ライブラリ処理の中で何らかのCPUボトルネックな処理が発生 ライブラリ自体をフォークして手を入れたくないので、 静的なクライアント情報をキャッシュしてI/Oアクセスを回避 ライブラリのトレース計装が不十分だったため、大まかに ボトルネック箇所を特定してローカルで追加計装したうえで、 プロファイラも使いながらボトルネックを探索
33. 事例 1：OAuthクライアント認証処理のボトルネック把握と改善 ID管理・認証認可基盤 クライアント認証 認可コード/リフレッ シュトークン検証 新規トークン生成 レスポンス作成 リクエスト検証 最も大きなボトルネックはクライアントシークレット比較時のハッシュ関数と判明 しかし、ハッシュ関数はCPU演算量を増やすことに意味があるため効率化は難しい そこで、クライアント認証方式を変更してハッシュ関数を回避してボトルネックを解消 クライアント ID管理・認証認可基盤 クライアントID+ シークレット ハッシュ計算
34. 事例 1：OAuthクライアント認証処理のボトルネック把握と改善 ID管理・認証認可基盤 クライアント認証 認可コード/リフレッ シュトークン検証 新規トークン生成 レスポンス作成 リクエスト検証 最も大きなボトルネックはクライアントシークレット比較時のハッシュ関数と判明 しかし、ハッシュ関数はCPU演算量を増やすことに意味があるため効率化は難しい そこで、クライアント認証方式を変更してハッシュ関数を回避してボトルネックを解消 クライアント ID管理・認証認可基盤 クライアントID+ シークレット クライアント ID管理・認証認可基盤 ハッシュ計算 アサーショントークン生成 署名検証
35. 事例 1：OAuthクライアント認証処理のボトルネック把握と改善 処理時間のp99が1/5程度に改善 最もリクエスト数の多いプロダクトから適用したところ、同時間帯のトークンリクエストに対する処理時間 のp99が従来のクライアントシークレット方式に比べて1/5程度まで改善した
36. 事例 2 サービスレビューによる 組織的な「見る力」「わかる力」の向上 とシステムの継続的改善
37. 事例 2：サービスレビューによる組織的な見る力、わかる力の向上と継続的な改善 ID管理・認証認可基盤 以下の観点で週次レポートを作成 傾向の変化や課題を確認 • パフォーマンス • エラー • コスト サービスレビューの結果をフィードバック ユーザー数や利用パターンの異なる複数のプロダクト、多数のテナントからのリクエストを捌く基盤 としてスケーリングしていく中で、組織的にソフトウェアへの理解を高めるために週次でID管理・認 証認可基盤のパフォーマンスやエラー、コストを確認し議論するサービスレビューの仕組みを導入 チーム内でシステム に対する理解や勘所 を継承していく
38. 事例 2：サービスレビューによる組織的な見る力、わかる力の向上と継続的な改善 パフォーマンス • パフォーマンスメトリクスにおける先週との比較 • パフォーマンスメトリクスの長期的（月単位）の傾向 • 特に時間のかかっているエンドポイントはなにか • 前週に対処したエンドポイントの状況確認 エラー • 想定していないエラーは出ていないか • 不要なエラーが出ていないか • パフォーマンスと関連するエラーの状況 コスト • コストの先週との比較 • コストの長期的（月単位）の傾向 • 特にコストのかかっているAWSサービスはなにか • 前週に対処したコストの状況確認 具体的には以下の観点でパフォーマンス、エラー、コストを確認している。 課題を発見したら必要なものはチケット化して次以降のスプリントで逐次対処していくことで、 サービスがスケールしていく中でもパフォーマンスやコストの改善を図っている。
39. 事例 3 ユーザーの操作エラー検知による プロアクティブなカスタマーサクセス
40. 事例 3：ユーザー操作エラーの検知によるプロアクティブなカスタマーサクセス ID管理・認証認可基盤 ユーザー情報 組織マスタ CSVの情報フォーマットや 個々の要素の入力規則に慣れるまで 入力起因のエラーが増える エンタープライズをはじめとして大規模なテナントが増えてくると、大量のユーザー情報や マスタ情報を登録、更新する必要が出てくるため、CSVなどによる一括操作機能が求められる。 一方で、Web UIのようにわかりやすくバリデーションをかけて表示したりインタラクションがとれないため、 CSVのカラムフォーマットや個々の要素の入力規則に慣れるまではユーザー入力起因のエラーが増える。
41. 事例 3：ユーザー操作エラーの検知によるプロアクティブなカスタマーサクセス ID管理・認証認可基盤 メトリクス • 失敗率が想定より低くなっていないか • 同じユーザーが極端に何度も失敗して いないか ログ • どこでユーザーが失敗しているか • 同じような失敗を複数のユーザーが繰 り返していないか CSVによる情報操作を実行するサーバーのシグナルだけでなく、ユーザーの操作起因で発生するエラーについ てもメトリクスを収集したり、改善につながるログを出力
42. 事例 3：ユーザー操作エラーの検知によるプロアクティブなカスタマーサクセス ID管理・認証認可基盤 サービス開発チーム 極端に連続して失敗している ユーザーを把握 担当のカスタマーサクセスに連絡 プロアクティブにサポート オブザーバビリティをユーザーの操作にも広げることで、サービス利用体験全体のマイナス影響を最小限に したうえで、プロダクトとして必要な改善へのフィードバックにもつなげる
43. 事例 3：ユーザー操作エラーの検知によるプロアクティブなカスタマーサクセス ID管理・認証認可基盤 サービス開発チーム 極端に連続して失敗している ユーザーを把握 担当のカスタマーサクセスに連絡 プロアクティブにサポート 迅速なサポートによりお客様との関係性をより強固に 失敗しやすい箇所を把握しオンボーディング改善 機能やドキュメント、 UIの改善 オブザーバビリティをユーザーの操作にも広げることで、サービス利用体験全体のマイナス影響を最小限に したうえで、プロダクトとして必要な改善へのフィードバックにもつなげる
44. まとめ • ID管理・認証認可基盤におけるオブザーバビリティで解決したい課題 ◦ I/OボトルネックとCPUボトルネックの混在 ◦ CPUボトルネックを引き起こしやすい暗号化処理などのライブラリによるブラックボックス化 • めざしたい姿 ◦ Software Engineer as a Kalman filter ◦ 可観測性と、ソフトウェア内部状態に対する組織的な推定能力の向上 ◦ 定期的なサービスレビューによる推定能力の継承 • オブザーバビリティと育てたID管理・認証認可基盤 ◦ 最初は小さく、ビジネスやシステムのスケールに合わせて徐々に大きく ◦ ブラックボックスな処理もトレースから読み解いていく ◦ メトリクスやログからユーザー体験も改善していける
45. 株式会社カミナシ https://kaminashi.jp