Makuakeの認証基盤とRe-Architectureチーム

Transcript

1. Makuakeの認証基盤とRe-Architectureチーム
 
 株式会社マクアケ / 竹内健太（@bmf_san）
 
 サービスの当たり前を支える認証認可　〜マネーフォワードxマクアケ〜
 2023/01/19(木)

2. 竹内健太（Twitter: @bmf_san）
 株式会社マクアケ　開発本部　Re-Architectureチーム所属
 
 - 2019年入社
 - チームリーダー
 - Re-Architectureチームの業務以外は PHP・FWのアップデートプロジェクトだったり、 E2E導入プロジェクトだっ たりやっています
 - Goで何かつくるのが好きです 
 - https://github.com/bmf-san/goblin
 自己紹介
 Copyright © Makuake, Inc. All Rights Reserved.
 2

3. お話すること
 Copyright © Makuake, Inc. All Rights Reserved.
 3
 - Re-Architectureチーム is 何？
 - 認証基盤概要紹介
 - 認証基盤への移行における当たり前事例 

4. 4 Re-Architectureチーム is 何？

5. Re-Architectureチームとは？
 Copyright © Makuake, Inc. All Rights Reserved.
 5
 - ミッション
 - 「Makuakeがスケールし続けるためのシステム・アーキテクチャを実現」
 - マクアケの事業成長に耐えうるシステム基盤を提供する
 - 柔軟なスケーラビリティの担保
 - 機能的なスケーラビリティだけではなく、運用面でもスケーラビリティを担保する
 - 安心・安全に活用できるシステム基盤
 - Makuakeの他サービスやアライアンス先が、安心・安全に利活用できる基盤を 提供する
 - 高い信頼性を担保（可用性）
 - 事業の可能性を広げるReArchitecting
 - 技術基盤の開発・運用により、ビジネスの可能性を広げる

6. やっていること
 Copyright © Makuake, Inc. All Rights Reserved.
 6
 認証基盤だけ専門にやるチームではないのです！
 - Auth
 - 認証基盤
 - OIDC
 - 認可基盤
 - メッセージングサービス（今後取り組む予定）
 - 通知基盤
 
 アーキテクチャのスケーラビリティを担保するという観点で、主にサービス基盤の開発・運用を行っているチー ムです！

7. 7 認証基盤概要紹介

8. 
 - 会員数220万人〜のMakuakeを支える認証基盤（Authサービスと呼称）
 - ユーザー登録・ログインの機能等を提供 
 - Email/Password
 - 各種SNSプロバイダ
 - Facebook / Twitter / LINE / Yahoo! JAPAN / Apple
 - 2021年9月〜　運用開始
 - 運用体制（Authサービスに関わるエンジニア数） 
 - 開発フェーズは〜4人
 - 運用フェーズは現在 4人
 Makuakeの認証基盤とは
 Copyright © Makuake, Inc. All Rights Reserved.
 8

9. Makuakeの認証今昔
 Copyright © Makuake, Inc. All Rights Reserved.
 9
 昔
 - FuelPHPのSessionを利用した認証
 - モノリスでFuelPHPに依存した実装
 - 非コンテナ環境（EC2）※現在はECS
 今
 - JWTを使ったトークンベースの認証
 - マイクロサービスにおける1つのサービスとし て実装
 - コンテナ環境（GKE）

10. なぜ認証基盤をサービスとして切り出したのか？
 Copyright © Makuake, Inc. All Rights Reserved.
 10
 背景
 - モノリスなアーキテクチャからの脱却 
 - マイクロサービス化の推進
 - ”認証”切り出しがマイクロサービス化の最初の 1歩であった
 
 解決したい課題
 - 複雑化したコードベースにおける機能の改修・追加が難しい問題の解決 
 - 複数システム間で使える共通の認証基盤の必要性 
 - ユーザー数の増加を見据えた可用性の担保 
 

11. アーキテクチャ構成（簡略版）
 Copyright © Makuake, Inc. All Rights Reserved.
 11

12. アーキテクチャ構成（簡略版）
 Copyright © Makuake, Inc. All Rights Reserved.
 12
 - GCP上でサービス構築 - Kubernetesをベースとしたサービス構築 - 通信プロトコルはgRPCを採用 - grpc-gatewayでHTTP→gRPCへ変換 - Spannerの採用 - 開発環境向けにもサーバーを用意（認証プロキシに IAPを利用）
13. 13 認証基盤への移行における当たり前事例

14. 当たり前？の例
 Copyright © Makuake, Inc. All Rights Reserved.
 14
 既存認証からAuthサービスへの切り替えをどのように行ったか？ 
 
 
 

15. 当たり前の認証を支えるために・・
 Copyright © Makuake, Inc. All Rights Reserved.
 15
 当たり前に使える認証基盤を提供し続けるために取り組んでいること 
 - ユーザーファースト
 - ユーザーへの影響を最小限に抑える意識や努力 
 - 可用性の担保
 - SLOを定義、目標とするサービスレベルを維持する 
 - 監視
 - アラート・メトリクス監視など
 - 継続的なバージョンアップ
 - システムやライブラリなど定期的に更新。溜め込まない 

16. 当たり前の認証を支えるために・・
 Copyright © Makuake, Inc. All Rights Reserved.
 16
 当たり前に使える認証基盤を提供し続けるために取り組んでいること 
 - ユーザーファースト
 - ユーザーへの影響を最小限に抑える意識や努力 
 - 可用性の担保
 - SLOを定義、目標とするサービスレベルを維持する 
 - 監視
 - アラート・メトリクス監視など
 - 継続的なバージョンアップ
 - システムやライブラリなど定期的に更新。溜め込まない。 
 
 当たり前のことを当たり前にやっている！と思います 

17. サービス移行要件
 Copyright © Makuake, Inc. All Rights Reserved.
 17
 “認証”という当たり前の機能の提供を停止させない 
 - ユーザーへの影響を最小限に抑える必要がある 
 - 認証に何か問題が発生すると、サービス全体への影響に波及する可能性が高い 
 
 要件を満たすために・・・
 - 「データの不整合を防止」 - 「フェイルセーフ」 - 「切り戻ししやすい仕組み」 

18. 当たり前を維持するために取り組んだこと
 Copyright © Makuake, Inc. All Rights Reserved.
 18
 サービス移行を3つのPhaseに分けて、段階的に移行作業を実施 
 - Phase1：ダブルライト
 - データ移行ツールの実行
 - 新規登録のAPIの利用開始（厳密には他のAPIも色々ある） 
 - 移行元DB・移行先DBの両方への書き込み
 - makuake側とAuth側のデータが同期されている状態をつくる 
 - データ整合性チェックツールの定期実行 
 - フィーチャーフラグの実装・運用開始 
 - AuthサービスAPIの利用ON・OFF
 - エラーハンドリングの調整
 - ユーザーへのエラーを返さない

19. 当たり前を維持するために取り組んだこと
 Copyright © Makuake, Inc. All Rights Reserved.
 19
 サービス移行を3つのPhaseに分けて、段階的に移行作業を実施 
 - Phase2：疑似認証
 - Authサービスの認証の仕組み（JWT）の利用開始
 - 既存の認証処理を行いつつ、Authサービス側の認証処理も行う
 - 既存認証で利用しているCookieと認証で利用するCookieを両方保つ
 - Authサービスへの完全切り替え時のログアウト多発を防止 
 - ログイン移行率（Authサービスを利用してログインしているユーザ数）の計測 
 - 各種メトリクスやエラーの監視（性能に問題ないかチェック） 
 - AuthサービスのほとんどのAPIが開放されるため、Authサービスが本格的にトラ フィックを受け付けることになる
 

20. 当たり前を維持するために取り組んだこと
 Copyright © Makuake, Inc. All Rights Reserved.
 20
 サービス移行を3つのPhaseに分けて、段階的に移行作業を実施 
 - Phase3：認証切り替え
 - Authサービスへの完全切り替え
 - ログイン移行率やエラー状況を元に、切り替え判定 
 - このフェーズでは切り戻しができなくなる 
 - 後処理
 - 用済みとなったコードやデータの削除等を実施 
 
 ←とある日に普段の機能リリースのように余りにも自然にリリー スされたの図（着想から3~4年くらいのプロジェクトだったので すが）
21. 21 当たり前の維持は当たり前ではないかも😤

22. まとめ
 Copyright © Makuake, Inc. All Rights Reserved.
 22
 - ReArchitectureチームはマクアケのスケーラビリティを支えるチーム 
 - 認証基盤以外もやっています
 - 認証基盤は独立した1つのマイクロサービス
 - 既知の課題解決や今後のニーズを見据えたサービス 
 - サービス移行でも当たり前を考える 
 - いつでも使える、ユーザー影響を最小限に抑えたサービス切り替え 
 

23. 23 We are hiring!
 ご清聴ありがとうございました！

24. Copyright © Makuake, Inc. All Rights Reserved.