こんにちは。株式会社カミナシの認証認可ユニットで『カミナシ ID管理』の開発に携わっているトモ=ロウです。
「マルチプロダクトにおける共通ID基盤」というテーマは、これまで多くのSaaS事業者が向き合ってきた、あるいはこれから向き合っていくべき課題であることは間違いないでしょう。しかし、実際の移行プロジェクトを経験した開発者の視点からの記録は、まだまだ少ないと個人的に感じています。
本記事では、カミナシが単一プロダクトから複数プロダクトへと事業を拡大する過程で、いかにして共通ID基盤を構築し、既存システムを統合していったのか、その道のりとそこで得た知見を、ありのままにお伝えしようと思います。本記事が少しでも同じような課題に直面している、あるいはこれから向き合うであろう皆さんの参考になれば幸いです。
前編後編に分かれており、本記事は前編です。
はじめに
なぜ、共通ID基盤が必要だったのか
カミナシは2024年8月に『カミナシ 従業員』がリリースされるまで、『カミナシ レポート』という単一のプロダクトを提供してきました。
プロダクトが一つだけだった時代、ID管理や認証の仕組みは、『カミナシ レポート』のアプリケーション内に組み込まれており、それで十分機能していました。ユーザー情報もパスワードも、すべてが同じデータベースに集約された、典型的なモノリシックアーキテクチャです。
しかし、カミナシがマルチプロダクト化に向けて動き出したとき、このモノリシックな構成は、未来の成長を阻害する潜在的な課題を抱えていることが明らかになりました。このまま突き進めば、ユーザーはプロダクトごとに別のアカウントを持つことになり、煩雑なユーザー体験を強いることになります。また、各プロダクトが独自に認証機能を実装することは、開発工数の肥大化やサービス間で一貫性のないセキュリティポリシーなどの問題を生むことになります。
ユーザーにシームレスな体験を提供し、効率的な開発体制を構築するためには共通ID基盤が必要不可欠でした。
ID統合プロジェクトの概略図
第1章：認証機能の切り離しと段階的な移行戦略
2023年4月、私たちは『カミナシ ID管理』の開発に着手しました。プロジェクトの最初のステップは、『カミナシ レポート』から認証機能を切り離すことでした。
この段階で、私たちはあえてユーザーデータの移行を後回しにするという戦略を選択しました。これは、認証機能のオーナーシップを早期に確立するためです。開発の責任範囲を明確にし、意思決定を迅速に行うことができる体制づくりを優先しました。
また、この意思決定にはリスクを段階的に管理する狙いもありました。一度にすべての変更を加えるのではなく、小さな変更から着手することで、もし問題が発生してもその影響範囲を限定し、問題が発生した際のロールバックを容易にしようと考えました。この判断は、今振り返っても正しかったと思います。
認証機能の切り離しのステップでは小規模な問題が発生しました。切り離し直前のテスト通信の際、『カミナシ レポート』のピーク時のトラフィック量が想定していたよりも多く、当時の『カミナシ ID管理』のインフラ構成ではリクエストが捌ききれないことが分かったのです。もちろん事前に『カミナシ レポート』のメトリクスを確認し、ピーク時のトラフィック量を想定した負荷試験も行っていましたが、メトリクスが10秒単位で均されていたため、より細かい期間で瞬間的に発生するスパイクトラフィックを想定できていなかったのです。
このような問題にすぐに対応できたのは、段階的な移行戦略を採用したことが大きな要因だったと考えています。
第2章：ゼロダウンタイム移行「ダブルライト」への挑戦
2023年7月、次の大きな課題であるユーザーデータの移行が始まりました。『カミナシ レポート』は深夜も稼働する工場などでも多数利用されているため、深夜メンテナンス等でシステムを長時間停止することはお客様の業務を止めてしまうことに繋がります。
そこで採用したのが、私たちが「ダブルライト」と呼んでいた手法です。これは、新しいユーザーデータを『カミナシ レポート』と『カミナシ ID管理』の両方のデータベースに同時に書き込むというものでした。
この手法は、実装の複雑性が伴います。エラーハンドリングや、データの不整合が起きた際の補償トランザクションなど、細部にまで注意を払う必要がありました。
例えば上記のシーケンス図において、『カミナシ ID管理』から『カミナシ レポート』へのレスポンスがエラーだった場合は「『カミナシ レポート』データベース」上で開始したトランザクションをロールバックする必要があります。
また、『カミナシ ID管理』へのリクエストが成功した後に何らかの理由でトランザクションのコミットに失敗した場合、状況はより複雑になります。その時点で「『カミナシ ID管理』データベース」への書き込みは完了しているため、何らかの方法で書き込みをなかったことにする必要があります。私たちは『カミナシ ID管理』に向けて最初に書き込んだ内容と逆のリクエスト（補償トランザクション）を再度送信することでこの問題に対処しました。
- 作成の場合は削除リクエストを送信
- 更新の場合は更新前のデータで更新リクエストを送信
- 削除の場合は作成リクエストを送信
また、これらの補償トランザクションの実行にも失敗した場合には、アラートを発火させて手動でのリカバリを行う運用としました（幸いにも一度も手動でのリカバリは行わなくて済みました）。
このように「ダブルライト」方式は複雑なエラーハンドリングが要求されるため、実装コストはやや高くなりますが、一方で、データの移行と認証時のユーザーデータの参照先の切り替えを同時に行う必要がないという大きなメリットがありました。これにより、もしユーザーデータの参照先を切り替える際に何らかの問題が発生したとしても、データは両方のシステムで整合性が保たれているため、安心してロールバックできる状態を作ることができました。
ただ、この「ダブルライト」の実装は技術的な複雑さだけが課題ではありませんでした。すでに多くのユーザーを抱える既存プロダクトに、ダブルライトのロジックやそのエラーハンドリングなどを実装することになります。万が一、不具合でサービスを止めてしまうようなことがあれば、お客様のビジネスに直接的な影響を与えてしまいます。このような大きな変更を他チーム（認証認可ユニット）のメンバーが行うことは通常避けるべきで、仮にやるとしてもステークホルダーとの綿密な情報共有が必要です。
そして、ここに私自身の反省点がありました。私は認証認可ユニットへ異動する前は『カミナシ レポート』の開発に携わっていたため、『カミナシ レポート』のアプリケーションの内部構造や、チーム内の物事の進め方がある程度分かっている状態でした。そのことは上述した「ダブルライト」のロジック実装をする際には大いに役に立ったのですが、一方で、その状況に甘んじて「このくらいの説明で十分伝わるだろう」と、『カミナシ レポート』チームとの調整や説明をかなり省略してしまいました。
私が実装した「ダブルライト」処理は結果的に概ね問題なく動いてくれましたが、振り返ればここで各ステークホルダーへの説明を十分に行わなかったことはプロジェクト全体を通してボディーブローのようにじわじわと効いていたと思います。一連のID基盤統合プロジェクトの中心となる「『カミナシ レポート』の関係者」にプロジェクトの全貌を正確に把握する機会を提供しないまま物事を進めてしまったのです。実際にこのことが原因で技術的な問題が発生したこともありました（詳細は後編で紹介します）。
この時の経験は今でも大きな学びとして心に残っています。
紆余曲折ありましたが、最終的に約1ヶ月間のダブルライト期間を経て、2023年10月には全ユーザーデータの移行が完了しました。両システム間でデータに不整合がないことを確認し、既存データの移行完了を宣言しました。反省点はありましたが、チームが一つの大きな山を越えた瞬間でした。
第3章：共通基盤としてのはじめの一歩
ID統合プロジェクトが進む中、同時に『カミナシ ID管理』そのものを進化させてきました。
前章で紹介したデータ移行プロジェクトを進める傍ら、『カミナシ ID管理』をOpenID Connect（OIDC）準拠のIDプロバイダへと進化させるプロジェクトも同時に進行しており、2023年12月にリリースされました。
OIDCはOAuth 2.0をベースとした業界標準のプロトコルです。セキュリティのベストプラクティスが確立されている点や、さまざまな拡張仕様があり、それらを利用することでよりノンデスクワーカーのユースケースに合った認証認可フローが提供できそうな点に期待して採用しました。
『カミナシ レポート』は開発スケジュールの都合からOIDC準拠のログインフローへの対応に時間がかかることが分かっていました。したがってこの時点では『カミナシ レポート』は第1章で切り離した独自の認証方式を継続して利用しつつ、『カミナシ レポート』の後に開発された『カミナシ 従業員』などの新規プロダクトでは全て最初からOIDC準拠のログインフローを利用することになりました。
さらに、2024年2月には『カミナシ ID管理』の管理画面が誕生しました。
これは、複数のプロダクトのユーザーを一元管理するための重要な準備でしたが、当時の『カミナシ レポート』は独自のユーザー管理機能を持っており、お客様への説明や現行の『カミナシ レポート』ユーザー管理機能と『カミナシ ID管理』の機能ギャップによるハレーションを考えた結果、『カミナシ レポート』のお客様は『カミナシ レポート』のユーザー管理画面を利用し、新規プロダクトのお客様は『カミナシ ID管理』を利用することを選択しました。
次回予告
2023年4月にプロジェクトが発足してから2024年2月に『カミナシ ID管理』の管理画面が誕生するまでの10ヶ月間、さまざまな成功と失敗がありました。
- 『カミナシ レポート』の認証機能を分離
- 『カミナシ レポート』のユーザーデータを『カミナシ ID管理』に移行
- 『カミナシ ID管理』にOIDC準拠のIDプロバイダー機能を追加
- 『カミナシ ID管理』のユーザー管理画面を提供
これらの作業を進めてきましたが、これで終わりではありません。真のID基盤になるために必要な作業はまだ残っています。この時点では『カミナシ レポート』はまだ独自のログインフローを利用していますし、『カミナシ レポート』のユーザーは『カミナシ ID管理』の管理画面を利用していませんでした。当然認証機能が複数あったり、ユーザーを複数の場所で管理できる状態は健全ではありません。そんな状況でも何とか破綻させないために様々なワークアラウンドが存在していました。それらの問題を全て解決して初めて『カミナシ ID管理』は「カミナシの共通ID基盤」になるのです。
そして2024年3月、私たちはこれらの課題を解決するべく新たなプロジェクトを始動させました。
このプロジェクトの詳細については、後編で詳しくお伝えする予定です。技術的な課題と解決方法、そしてマルチプロダクト化で新たに見えてきた課題について、より深く掘り下げていきます。
おわりに
マルチプロダクト化を進める企業にとって、共通ID基盤は、事業の持続的な成長を支える「縁の下の力持ち」のような存在です。
『カミナシ ID管理』は、これからも私たちの事業成長を支える重要な基盤として、進化を続けていきます。もし、本記事で紹介した取り組みを「面白そう！」と感じた方がいれば、私たちと一緒に取り組んでみませんか？
カミナシの認証認可ユニットでは、ソフトウェアエンジニアを募集しています！
それでは、後編でまたお会いしましょう。
