マルチプロダクト戦略を加速させる！ ゼロダウンタイムで挑んだID管理機能移行の道のり 株式会社カミナシ 小松山 凌平 (@kmtym_dev) リプレイスメント・デイ - システム刷新の最前線 -

自己紹介 カミナシについて ID統合プロジェクトの背景 ID統合のプロセス 今後の展望

自己紹介 経歴 2021年、新卒でエンジニアとしてのキャリアをスタート。 社内業務システムの開発や、いくつかのマイクロサービス立 ち上げを経験。 2024年7月にカミナシに入社。 カミナシでの仕事 現場向け帳票作成システム「カミナシ レポート」の開発。 カミナシ レポートのID統合プロジェクトに途中参画しまし た。 (今日はこの話をします) 株式会社カミナシ IDニンジャーズユニット🥷 小松山 凌平 (こまつやま りょうへい)

カミナシについて

会社 & プロダクト紹介 日常はITに溢れているのに、仕事場は紙ばかりで非効率。 今日も作業現場で働く人たちは、十分に才覚を発揮できていない。 そんな3,900万人の埋もれたエネルギーを、私たちが解き放つ。 誰もが享受するべき当たり前を、すべての現場の人たちに届けたい。 効率的な作業、見事な成果、腕のなる仕事、豊かな人生。 これらはきっとつながっているから。 ノンデスクワーカーの 才能を解き放つ Mission

サービスラインナップ for 品質管理 (20年〜) for 現場総務 (24年8月〜) ID for ID管理・認証 (23年〜) 共通ポータルから 各サービスにアクセス 6 for 教育・研修管理　　 (25年2月〜)　 for 設備保全　　　 (25年2月〜）　　　

サービスラインナップ for 品質管理 (20年〜) for 現場総務 (24年8月〜) ID for ID管理・認証 (23年〜) 共通ポータルから 各サービスにアクセス 7 for 教育・研修管理　　 (25年2月〜)　 for 設備保全　　　 (25年2月〜）　　　

サービスラインナップ for 品質管理 (20年〜) 8 ● チェック表など現場管理のための帳票をデジタル化でき る、現場帳票システム ● 帳票のペーパーレス化のみならず、正しい作業手順の徹 底から業務改善など現場の業務効率化をサポート ● カミナシの売上を支えている主力のプロダクト ● マルチプロダクト化を見越して開発されたサービス ● OIDC / OAuth2.0 などの標準仕様に準拠したカミナシ の認証・認可基盤 ● カミナシアカウントの追加・編集などが行える管理画面 も提供している ID for ID管理・認証 (23年〜)

マルチプロダクト化と ID統合プロジェクトの誕生

10 マルチプロダクト化の発表 ☝☝☝

11 ● カミナシ レポートに実装されている認証機能はすでにある ● しかし、認証も含めて最良の体験を作るため、独立したID基盤の立ち上げを決意した ○ カミナシのお客様特有の事情もある ■ ノンデスクワーカーは人材の流動性が高い ■ 入退社が多い現場で毎回複数サービスのID発行を行うのはつらい マルチプロダクト化に向けて... 1アカウントで複数サービスを利用できるようにしたい！

12 マルチプロダクト化に向けて... カミナシの現在地点、 マルチプロダクト化を進めてみての学び 複数サービスを1IDで使えることは競合優位にもなる

13 カミナシ ID リリース ログインページ アカウント管理画面

14 ID統合のゴール カミナシ レポートのログイン機能のリプレイス ● カミナシ IDリリース以降に開発されるプロダクトは認証基盤の存在を前提として開発が できる ● 認証基盤のリリース前に運用開始されたカミナシ レポートも共通認証基盤を使ってログ インできるようにしたい カミナシ レポートのアカウント管理機能をリプレイス ● カミナシ IDリリース以降に開発されたプロダクトのアカウントはカミナシ IDの管理画面 を使って一元管理することができる ● カミナシ レポートのアカウントも含めてカミナシ IDで管理できるようにしたい 🥷 ID 統合プロジェクトの誕生 🥷

15 カミナシ ID を使って以下の状態になることを便宜上「ID統合」と呼んでいます ● 相当の権限を持ったアカウントで1度だけログインすると、複数のカミナシのサービスを 利用できる ● カミナシのサービスにログインできるアカウントを一元管理することができる 複数存在していたアカウントを1つにマージすることはしていません 「ID統合」の定義

16 「アカウント統合」をやらなかった理由 ● 個人向けアカウントと共有アカウントの混在が大きな理由 ● ID統合を進めていた際にお客様にリリースされていたサービス: ○ カミナシ レポート ■ 現場の端末を複数名で利用するユースケースが多い ● 「加熱室A」「製造部XX工程」のようなアカウントが存在する ■ 個人アカウントを使うケースもある (管理者向けの承認など) ○ カミナシ 従業員 ■ チャットや給与明細の配布など、個人にフォーカスしたサービス ● 共有アカウントなのか、個人アカウントなのかは判別が不可能 ● これはアカウント統合をしなかった理由でもあり、しなくても良かった理由でもある ○ そもそもアカウントのオーナーが違うから ○ 「アカウント統合」が必要だったケースもある ■ CSチーム/お客様に頑張ってアカウントの統合作業をやっていただきました

ID統合のプロセス

フェーズ1: 独自認証機能をOpenID Connectベースの認証へ移行する ● ユーザー/テナント情報のダブルライト ● カミナシ IDへの既存データの移行 ● ログイン機能の移行 フェーズ2: アカウント管理機能をカミナシ IDへ移行する ● 共通基盤のユーザー/テナントデータをどう参照するか？ ● ライフサイクルイベントを処理するワーカーの実装 ● ダブルライトを閉じる 18 あらすじ

フェーズ1: 独自認証機能をOpenID Connectベースの認証へ移行する ● ユーザー/テナント情報のダブルライト ● カミナシ IDへの既存データの移行 ● ログイン機能の移行 フェーズ2: アカウント管理機能をカミナシ IDへ移行する ● 共通基盤のユーザー/テナントデータをどう参照するか？ ● ライフサイクルイベントを処理するワーカーの実装 ● ダブルライトを閉じる 19 あらすじ

20 フェーズ1: ユーザー/テナント情報のダブルライト・カミナシ IDへのデータ移行 ● カミナシ IDでログインを行えるようにするため のステップ ● 新規で書き込む自サービスのデータを共通基盤の DBにも書き込むようにした (= ダブルライト) ○ API 経由でカミナシ IDに書き込み ○ 補償トランザクションを使って整合性を高 める実装を行っている ● ダブルライトの有効化後、ユーザー/テナントの 情報をカミナシ IDに移行 ○ データ変換 & 投入用のスクリプトを実行 カミナシ IDですべてのユーザー/テナント情報が参照 できる状態に！

21 フェーズ1: ユーザー/テナント情報のダブルライト・カミナシ IDへのデータ移行 ダブルライトが必要な理由をもう少し深堀り ● カミナシのサービスはユーザーの識別子として「ログインID」を使っている ○ ログインIDはユーザーが決める ○ システムが自動採番するユーザーIDとは別モノ ● マルチプロダクトな世界でログインIDの衝突を防ぐためには、個別のサービス内では なく共通基盤内で重複チェックを行う必要がある ● とはいえ、すべてを移行しきる余裕がなかったため、一時的なワークアラウンドとし て「ダブルライト方式」が採用された ○ 他のサービスの開発・リリースが控えていたため

● 独自に実装していたログインを、カミナシ IDが 提供するOIDCベースのログインにリプレイスす るステップ ● カミナシ IDはカミナシ レポートから移行してき たデータを使ってログイン処理を行う ● ログイン移行までには段階を踏んだ ○ 新旧どちらの認証も通るように ○ Web管理画面に限定してリリース ○ モバイルアプリ向けにリリース ○ 旧認証を使うユーザーが少なくなったのを確認し て旧セッションを削除 ● (本当はもう少し細かくリリースしていったのです が、発表時間の関係で割愛しています) 22 フェーズ1: 既存のログイン機能の移行

Web管理画面にのみ新ログインをリリースしたところ、ログインができなくなったという旨の 問い合わせを受けた。原因は以下の通り: ① ログインIDに含まれる半角スペースが予期せずTrimされていた ● カミナシ レポート側のログインIDカラム (MySQL) の照合順序が末尾の半角スペースを無視して比較す るutf8mb4_general_ciだった ● 旧ログインでは半角スペースを入力せずともログインできていたため、お客様は半角スペースが入った ログインIDを使っていることに気がつけなかった ● カミナシ IDには半角スペース付きのデータが移行されたため、ID/Passが不一致となった ② カミナシ レポート: case insensitive / カミナシ ID: case sensitive ● utf8mb4_general_ciはcase insensitive ● カミナシ ID側はPostgreSQLを使っている。PostgreSQLの文字列は基本的にはcase sensitive ③ ダブルライト対象から漏れていた経路があった ● ダブルライトの対象になっていないが、ユーザーのログイン情報が更新される経路があった ● 過去に使われていた機能で、Webの新ログインリリース時には閉じられていた機能 23 フェーズ1: 既存のログイン機能の移行 - 予期せぬデータの不整合

それぞれに対する対応: ① ログインIDに含まれる半角スペースが予期せずTrimされていた ② カミナシ レポート: case insensitive / カミナシ ID: case sensitive ● カミナシ側で半角スペースを削除 or お客様に正しいログインIDを入力していただくようご案内 ③ ダブルライト対象から漏れていた経路があった ● 新ログインのリリースを切り戻し ● リリース時点でパスワードハッシュが一致していないユーザーの洗い出し ● データ修正 これらの反省を踏まえ、データの整合性チェックを行うスクリプトを1日1回実行するように 24 フェーズ1: 既存のログイン機能の移行 - 予期せぬデータの不整合 (対応)

朝のピーク時の負荷によりトークンの検証に失敗し続ける事象が発生。原因は以下の通り: ● Goのdatabase/sqlはデフォルトでコネクションを2個までしか再利用しないため、ピーク 時にはコネクションの作成処理が増加 ● コネクション作成が場合によって2秒以上かかることがあった ● 一方でカミナシ レポート側で設定しているトークン検証リクエストのタイムアウトは3秒 ● タイムアウトを過ぎるとトークン検証は失敗してしまう 25 フェーズ1: 既存のログイン機能の移行 - ピーク時の負荷上昇

カミナシ ID、カミナシ レポートそれぞれで対応を実施: ● [カミナシ ID] Readerインスタンスへのコネクション周りの設定値変更 ○ MaxOpenConns, MaxIdleConns, ConnMaxLifetime, ConnMaxIdleLifetime ○ コネクションをいい感じにプーリングできるように設定 ○ 細かい設定値の意味はdatabase/sqlのGodocなどを参照してください ● [カミナシ レポート] リクエストのタイムアウトを伸ばし、リトライを入れる ○ トークン検証は毎リクエスト必要なので、上限が大きすぎるのも良くない ○ 短期的な一次対応とした ● [カミナシ ID] トークン検証の結果をサーバーのインメモリにキャッシュしておく ○ データベースへのアクセスを少なくする対応 ○ avg: 25ms → avg: 約10ms (すごい) 26 フェーズ1: 既存のログイン機能の移行 - ピーク時の負荷上昇 (対応)

フェーズ1でやったこと: ● ダブルライトによって認証基盤とデータの同期を取る仕組みをつくった ● 認証基盤でログインに必要なユーザー/テナントのデータを移行した ● 独自実装していたログイン機能を共通基盤のものにリプレイスした 次のフェーズでやること: ● カミナシ IDを使って複数サービスを使うユーザーの管理を一元化する ○ フェーズ1時点ではお客様にはカミナシ IDを使ってもらっていない ○ カミナシ レポート以外のサービスを使っているユーザーはカミナシ IDで管理が可能 ○ カミナシ レポートのユーザーは従来のユーザー管理機能を使って管理 ■ ダブルライトは継続中 27 ここまでのまとめ

フェーズ1: 独自認証機能をOpenID Connectベースの認証へ移行する ● ユーザー/テナント情報のダブルライト ● カミナシ IDへの既存データの移行 ● ログイン機能の移行 フェーズ2: ユーザー管理機能をカミナシ IDへ移行する ● 共通基盤のユーザー/テナントデータをどう参照するか？ ● ライフサイクルイベントを処理するワーカーの実装 ● ダブルライトを閉じる 28 あらすじ

データ移行とログイン移行が完了しただけでは、お客様にカミナシ IDを使ってアカウント 管理を行ってもらえる状態になっていない ● カミナシ レポートでのユーザー操作がカミナシ IDにも反映される ○ 他プロダクトの管理者の預かり知らぬところで情報が更新されてしまう ● カミナシ IDでユーザーを作成/更新してもカミナシ レポートに伝達されない 29 フェーズ2: ダブルライトをやめる必要性

カミナシ IDでデータを一元管理するパターン ● カミナシ レポートでユーザー/テナントのデータが欲しい 時はカミナシ IDのAPIを呼び出す ● データ管理の責務が区切られていてシンプル ● だが、既存のユーザー/テナントの取得処理に影響がある データの変更を検知し同期するパターン ● 自サービスのDBのみを参照しつづける方法 ● 既存のユーザー/テナントの取得処理には影響が少ないが、 データを同期するために何らかの仕組みを作る必要がある 30 フェーズ2: ユーザー/テナントの情報をどのように管理するかの検討

カミナシ IDでデータを一元管理するパターン ● カミナシ レポートでユーザー/テナントのデータが欲しい 時はカミナシ IDのAPIを呼び出す ● データ管理の責務が区切られていてシンプルだが、既存の ユーザー/テナントの取得処理に影響がある 👇こちらのパターンを採用👇 データの変更を検知し同期するパターン ● 自サービスのDBのみを参照しつづける方法 ● 既存のユーザー/テナントの取得処理には影響が少ないが、 データを同期するために何らかの仕組みを作る必要がある 31 フェーズ2: ユーザー/テナントの情報をどのように管理するかの検討

データを都度取得する方式は実現コスト/リスクが高すぎたため採用しなかった ● ユーザーテーブルのSELECTやJOINをAPI呼び出しに変える ○ 雑に調べたところ、ユーザーが絡むクエリは約50種類 ● もともと持っていたユーザー/テナントの識別子をカミナシ IDが発行する識別子に変 更する必要がある ○ 例) ユーザーへの外部キーとして reports.user_id を使っていたところを reports.kaminashi_id_user_id 的なカラムを生やして使う必要がある ● それに伴ってAPIのパラメータ類も変更が必要になる ○ カミナシ レポートのAPIはクライアントが4種類いる ■ Web管理画面、記録アプリ(iOS版/PWA版)、社内向け管理画面 ○ それぞれのクライアントの動作を担保しつつ、APIのインターフェイスを変更していくのは かなりハード 32 フェーズ2: ユーザー/テナントの情報をどのように管理するかの検討

カミナシ IDでデータを一元管理するパターン ● カミナシ レポートでユーザー/テナントのデータが欲しい 時はカミナシ IDのAPIを呼び出す ● データ管理の責務が区切られていてシンプルだが、既存の ユーザー/テナントの取得処理に影響がある データの変更を検知し同期するパターン ● 自サービスのDBのみを参照しつづける方法 ● 既存のユーザー/テナントの取得処理には影響が少ないが、 データを同期するために何らかの仕組みを作る必要がある 33 フェーズ2: ユーザー/テナントの情報をどのように管理同期するかの検討

● カミナシ ID側でユーザー/テナントのライフサイク ルイベントを定義 ○ ユーザー更新/削除/サービス利用権割当... ○ テナント更新/削除/契約サービス追加... ● カミナシ IDでの操作に応じたイベントが発火 ● イベントをSNS→SQSに伝播させて、それに応じた 処理を行うワーカーを実装 ● イベントのパブリッシュ、ワーカーの処理が失敗す ると、それぞれのAWSアカウントに用意されたデッ ドレターキューにメッセージが積まれる ○ デッドレターキューのメトリクスをCloudWatchで監視 ○ アラームをSlack通知し、開発者が手動でリカバリを行う 運用になっている フェーズ2: イベントの発生を検知して共通基盤とのデータを同期する 34

フェーズ1: 独自認証機能をOpenID Connectベースの認証へ移行する ● ユーザー/テナント情報のダブルライト ● カミナシ IDへの既存データの移行 ● ログイン機能の移行 フェーズ2: アカウント管理機能をカミナシ IDへ移行する ● 共通基盤のユーザー/テナントデータをどう参照するか？ ● ライフサイクルイベントを処理するワーカーの実装 ● ダブルライトを閉じる 35 [再掲] あらすじ

今後の展望

カミナシ IDが取り組む課題と未来 ノンデスクワーカーにも活用してもらえるアイデンティティプロバイダ（IdP） デスクワーカー向けのIdPはIDaaSやOSSなど様々なソリューションがあります。しかし、 従業員の入れ替わりが激しくID管理に不慣れなノンデスクワーカーが働く企業に最適な機能やUXとはいえません。 デスクワーカー向けの認証基盤にはない困難な課題に取り組んでいる デスクワーカー文脈ではパスキーが有力なパスワードレス認証の決定打になりつつある中、 マスクや手袋をした現場作業者に対して有効な選択肢はまだ世の中にありません。 37

カミナシ IDが取り組む課題と未来 共用端末アカウント 共有アカウントを廃止して 端末自身を認証するように パスワード不要 定期ログイン操作不要 パスワード漏洩リスク 定期ログイン操作要 エンタープライズグレードの セキュリティと統制 ・共用端末アカウントの認証強化 ・多要素認証の種別の追加 ・不正なアクティビティの検出 ・監査ログ ・複数テナントへのログイン ・テナントのグループ化（親子など） セキュリティレベルの向上 ガバナンス（統制）の向上 アカウント利用の深化 38

39 ご清聴ありがとうございました！ We are hiring! エンジニアブログ 採用情報