Authlete — 日本の銀行向けOAuth/OIDCのSRE
Authleteのデプロイメントを3つのデリバリーモデル（オンプレミス、専有SaaS、共有SaaS）にわたって運用・産業化し、日本の銀行クライアントに提供しました。
- GCP
- Kubernetes
- Helm
- Terraform
- GitLab-CI
- Java
- JUnit
- Ruby
- OAuth 2.0
- OpenID Connect
背景
Authleteは主に日本の銀行向けにOAuth 2.0およびOpenID Connect認証を提供しています。3つのデリバリーモデルが共存：オンプレミス（クライアント側でホスト）、専有SaaS（クライアント専用インスタンス）、共有SaaS。それぞれのモデルにセキュリティ、ネットワーク、コンプライアンス上の制約があります。
課題は、これら3モデルを単一のテンプレート基盤で産業化すること、クライアントが必要とする限りレガシーバージョンをサポート可能に保つこと、そして毎リリースでOAuth / OIDC準拠の基準を維持することでした。
担当した役割
SRE & DevOpsとして、デプロイメントテンプレート、マルチバージョン対応のCI/CDパイプライン、GCP上のSaaS運用を所管しました。
構築したもの
- GCP上のSaaSデプロイメントを日々運用
- KubernetesテンプレートをHelm + Terraformで設計、クラウド非依存にすることで大きなコード分岐なしでオンプレミスクライアントにも提供可能に
- GitLab-CIパイプライン：サービスの全レガシーバージョンを並列でビルド・テスト可能に。銀行クライアントに一夜での移行を求めることはできないため
- JavaのJUnitテストスイート：ユニット + 統合
- Rubyテストスイート：エンドツーエンド + 性能
- OAuth 2.0 / OpenID Connect準拠テストをパイプラインに統合。仕様から逸脱した認証サービスはもはや認証サービスではないため
- 「開発者が修正をプッシュしてから」「その修正がクライアント環境のSaaSで動くまで」の時間を大幅に短縮
最も難しかった点：マトリクス（デリバリーモデル × サポート対象バージョン × ターゲットクラウド）を、管理不能な構成負債に変えずに維持すること。
成果
開発生産性が大幅に向上：変更が手動QAサイクルを待つことなく、自動テストチェーンを通過するようになりました。同じテンプレートベースがSaaSとオンプレミス両方を支え、SREチームの認知負荷が下がりました。