モノリス開発の名残から脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と 堅牢性を追求した認可基盤刷新の過程と工夫

Takumi Ishii (株式会社プレイド)
https://www.cnia.io/pek2024/sessions/eaeeab94-9927-417a-992e-59f635221f83/

2024.07.09 Platform Engineering Kaigi 2024
https://www.cnia.io/pek2024/

Transcript

1. © PLAID, Inc.　|　Confidential 2024.7.9　　｜　　Platform Engineering Kaigi 2024 モノリス開発の名残から脱却、マルチプロダクト開発 における多様な開発者のニーズに応える使い勝⼿と 堅牢性を追求した認可基盤刷新の過程と⼯夫 株式会社プレイド Takumi Ishii © PLAID, Inc.　|　Confidential
2. © PLAID, Inc.　|　Confidential ⾃⼰紹介 Takumi Ishii 株式会社プレイド GitHub : ta9mi141 X (Twitter) : @PLAID_Tech ハッシュタグ : #PEK2024 ⼤学を卒業しました 2022.3.31 株式会社プレイドに⼊社しました 2022.4.1 認可基盤の刷新に取り組んでいます 2024.7.9 PEK 2024 にて登壇中です 2024.7.9 © PLAID, Inc.　|　Confidential 2 https://blog.plaid.co.jp/n/ne59bc83b6438
3. © PLAID, Inc.　|　Confidential KARTEについて © PLAID, Inc.　|　Confidential 3 CX(顧客体験)プラットフォーム
4. © PLAID, Inc.　|　Confidential KARTEについて © PLAID, Inc.　|　Confidential 4 CX(顧客体験)プラットフォーム ⼀⼈ひとりに合わせた 顧客体験を提供 WebやAppの訪問者の⾏動を 顧客ごとにリアルタイムに解析
5. © PLAID, Inc.　|　Confidential 主な提供プロダクト/サービス⼀覧 © PLAID, Inc.　|　Confidential 5 領 域 プロダクト / サービス名 概 要 オンサイト マーケティング オンライン上の顧客⼀⼈ひとりの「今」を可視化。解析結果に応じた ⾃由⾃在なアクション設計により企業のマーケティング業務を⽀援。 オンサイト マーケティング ウェブサイトのあらゆる要素をBlockに分解、スピーディーな改修/ 仮説検証/効果測定を可能にすることで、継続的なパフォーマンス向上と リーンなサイト運営を実現。 データ統合 顧客が持つデータをKARTEに繋げ、社内外に点在するデータを ビッグデータのまま統合/分析/可視化することで、より⾼度な セグメンテーションやアクションを実現。 カスタマー サポート オンライン上でサポートを必要とする顧客⼀⼈ひとりの課題を可視化。 FAQ等の適切なサポートチャネルにマッチングさせることで、課題の 早期解決を実現。 広 告 KARTEで蓄積されたデータ等の各種広告媒体との連携を通じて、 サイト内外⼀貫した顧客コミュニケーションを実現。 マーケティング オートメーション 独⾃開発したカスタマージャーニー機能を⽤いて、メールやSMS等により サイト外にいる顧客コミュニケーションを実現するKARTE版マーケティング オートメーション。
6. © PLAID, Inc.　|　Confidential 本⽇のアジェンダ 1. KARTE のアーキテクチャ 2. 従来の認可の⽅法と問題点 3. 新たな認可基盤のアーキテクチャ 4. 新たな認可基盤の設定⽅法 5. 認可基盤の移⾏ 6. 現状と今後の展望 © PLAID, Inc.　|　Confidential 6
7. © PLAID, Inc.　|　Confidential 本⽇のアジェンダ 1. KARTE のアーキテクチャ 2. 従来の認可の⽅法と問題点 3. 新たな認可基盤のアーキテクチャ 4. 新たな認可基盤の設定⽅法 5. 認可基盤の移⾏ 6. 現状と今後の展望 © PLAID, Inc.　|　Confidential 7
8. © PLAID, Inc.　|　Confidential 管理画⾯のアーキテクチャとチーム構成 © PLAID, Inc.　|　Confidential 8
9. © PLAID, Inc.　|　Confidential 本⽇のアジェンダ 1. KARTE のアーキテクチャ 2. 従来の認可の⽅法と問題点 3. 新たな認可基盤のアーキテクチャ 4. 新たな認可基盤の設定⽅法 5. 認可基盤の移⾏ 6. 現状と今後の展望 © PLAID, Inc.　|　Confidential 9
10. © PLAID, Inc.　|　Confidential 従来の認可の⽅法 © PLAID, Inc.　|　Confidential 10
11. © PLAID, Inc.　|　Confidential 従来の認可の問題点 © PLAID, Inc.　|　Confidential 11 • 認可ミドルウェアの実装は社内独⾃の仕組みによってシンボリックリンク で共有されており、それがいくつかの問題を引き起こしていた ◦ コードを変更すると全てのサービスに同期的な影響が出る ◦ 変更を反映するために全てのサービスをビルドし直す必要がある • サービスの実装に使える⾔語とフレームワークが制限される • 認可ミドルウェアを含むライブラリの読み込みに時間がかかっており 開発効率を下げている
12. © PLAID, Inc.　|　Confidential 従来の認可の問題点 © PLAID, Inc.　|　Confidential 12 • 認可ミドルウェアの実装は社内独⾃の仕組みによってシンボリックリンク で共有されており、それがいくつかの問題を引き起こしていた ◦ コードを変更すると全てのサービスに同期的な影響が出る ◦ 変更を反映するために全てのサービスをビルドし直す必要がある • サービスの実装に使える⾔語とフレームワークが制限される • 認可ミドルウェアを含むライブラリの読み込みに時間がかかっており 開発効率を下げている
13. © PLAID, Inc.　|　Confidential 従来の認可の問題点 © PLAID, Inc.　|　Confidential 13 • 認可ミドルウェアの実装は社内独⾃の仕組みによってシンボリックリンク で共有されており、それがいくつかの問題を引き起こしていた ◦ コードを変更すると全てのサービスに同期的な影響が出る ◦ 変更を反映するために全てのサービスをビルドし直す必要がある • サービスの実装に使える⾔語とフレームワークが制限される • 認可ミドルウェアを含むライブラリの読み込みに時間がかかっており 開発効率を下げている
14. © PLAID, Inc.　|　Confidential 本⽇のアジェンダ 1. KARTE のアーキテクチャ 2. 従来の認可の⽅法と問題点 3. 新たな認可基盤のアーキテクチャ 4. 新たな認可基盤の設定⽅法 5. 認可基盤の移⾏ 6. 現状と今後の展望 © PLAID, Inc.　|　Confidential 14
15. © PLAID, Inc.　|　Confidential 2つの⼤まかな⽅針 © PLAID, Inc.　|　Confidential 15 • デプロイの影響範囲は⼤きく、全てのサービスに 影響する可能性がある • 管理は中央集権的になり、サービス数が増えても ⼀括して扱える • デプロイの影響範囲は⼩さく、影響範囲を特定の サービスに絞ることができる • 管理はサービスごとになり、サービス数が増える とメンテナンスコストが懸念される
16. © PLAID, Inc.　|　Confidential 新たな認可基盤 (karte-gateway) のアーキテクチャ © PLAID, Inc.　|　Confidential 16
17. © PLAID, Inc.　|　Confidential アーキテクチャを決めるまでの議論 © PLAID, Inc.　|　Confidential 17 • どちらの案も⼀⻑⼀短がある ◦ ここでは開発スピードを考慮して、デプロイの影響を⼩さく とどめられるアーキテクチャを採⽤した • 最終的には「後から⽅針転換が必要になったとしても、分散している ものを束ねる⽅が変更が容易だろう」という考えが決め⼿になった ◦ 双⽅のアーキテクチャのメリットとデメリットは表裏⼀体であり、 どちらが吉と出るか⾒通すのは難しい
18. © PLAID, Inc.　|　Confidential 従来の⽅法との⽐較 © PLAID, Inc.　|　Confidential 18 • 認可の設定は config で与える • 認可時にデータベースから取得したデータは リクエストヘッダに乗せてアプリケーションで利 ⽤する • 認可の設定はアプリケーションの実装で決まる • 認可時にデータベースから取得したデータは ミドルウェア間で受け渡してアプリケーションで 利⽤する
19. © PLAID, Inc.　|　Confidential 本⽇のアジェンダ 1. KARTE のアーキテクチャ 2. 従来の認可の⽅法と問題点 3. 新たな認可基盤のアーキテクチャ 4. 新たな認可基盤の設定⽅法 5. 認可基盤の移⾏ 6. 現状と今後の展望 © PLAID, Inc.　|　Confidential 19
20. © PLAID, Inc.　|　Confidential KARTEを取り巻くリポジトリ © PLAID, Inc.　|　Confidential 20 • デプロイの管理は GitOps で ⾏われている • アプリケーションコードと Kubernetes マニフェストを置く リポジトリは別
21. © PLAID, Inc.　|　Confidential 設定ファイルの管理⽅法の検討 © PLAID, Inc.　|　Confidential 21 • 設定ファイルの管理において考慮したいポイントは以下の3つ ◦ アプリケーションの開発時に変更を加えられること ◦ デプロイやロールバックが容易にできること ◦ 複数のリポジトリにまたがって⼆重管理になるのを避けること • いくつか⽅法はありそうだが... ◦ コンテナイメージに設定ファイルを同梱する? ◦ karte-ops リポジトリに ConfigMap を作る? ◦ Init Containers でよしなに初期化する?
22. © PLAID, Inc.　|　Confidential 認可基盤の設定⽅法 © PLAID, Inc.　|　Confidential 22 • 開発時に変更できるように 設定は karte リポジトリに置く • サービスごとの設定と karte-gateway-base を組み合 わせたイメージをデプロイする • Nginx のイメージに設定だけ カスタマイズして投⼊するのと 同じ要領
23. © PLAID, Inc.　|　Confidential 他の案はどうだったのか © PLAID, Inc.　|　Confidential 23 • karte-ops リポジトリに ConfigMap を作る ◦ 設定⾃体は開発時にも扱うので karte リポジトリに置くが、 karte-ops リポジトリにマニフェストを作るタイミングで同期を 取るというアイデア ◦ マニフェストは Kustomize を使って管理されているので プラグインを書くこともできる ◦ デプロイフローがわかりにくくなるのが難点 • Init Containers が配置した設定を karte-gateway で読み取る ◦ Pod の中には三種類のコンテナが含まれることになる ◦ 開発環境は docker-compose で作られているので、同じことを 実現しようとすると複雑になるのが難点
24. © PLAID, Inc.　|　Confidential 本⽇のアジェンダ 1. KARTE のアーキテクチャ 2. 従来の認可の⽅法と問題点 3. 新たな認可基盤のアーキテクチャ 4. 新たな認可基盤の設定⽅法 5. 認可基盤の移⾏ 6. 現状と今後の展望 © PLAID, Inc.　|　Confidential 24
25. © PLAID, Inc.　|　Confidential KARTEにおける認可の重要性 © PLAID, Inc.　|　Confidential 25 • 認可基盤のバグや設定ミスがあった場合、以下の2種類の問題が起こりうる ◦ リクエストを過剰に拒絶してしまい、本来はアクセスできるはずの 画⾯が⾒えなくなる ◦ リクエストを過剰に許容してしまい、本来はアクセスできないはずの 画⾯まで⾒えてしまう • KARTE にはエンドユーザー (= お客様のお客様) の個⼈情報が 詰まっているため、特に後者は極めて重⼤な事故になる可能性が⾼く、 確実に防がなくてはならない
26. © PLAID, Inc.　|　Confidential 安全な移⾏のために © PLAID, Inc.　|　Confidential 26
27. © PLAID, Inc.　|　Confidential 安全な移⾏のために © PLAID, Inc.　|　Confidential 27 • karte-gateway が不正アクセスを許していたらアラートを鳴らす • 認可の適⽤漏れがないかどうかもチェックする
28. © PLAID, Inc.　|　Confidential 安全な移⾏のために © PLAID, Inc.　|　Confidential 28 • 最終的にアプリケーションコードから認可ミドルウェアを削除する
29. © PLAID, Inc.　|　Confidential 既存の実装と同様の設定を作る © PLAID, Inc.　|　Confidential 29 • 既存の認可ミドルウェアはアプリケーションコードの様々な箇所で利⽤されており、 ⼿動で同等の設定を書き起こすのは⾮現実的 • アプリケーションコードを静的解析して実装と同等の設定を書き出すツールが 作られ、安全かつ⾼速な移⾏が可能になった // アプリケーションコードの例 app.use('/service/api/view, auth_user(), auth_role("VIEWER"), view_router, ) app.use('/service/api/admin', auth_user(), auth_role("ADMIN"), admin_router, ) # karte-gateway の設定の例 routes: - path: "/service/api/view" middlewares: AuthUser: AuthRole: role: "VIEWER" - path: "/service/api/admin" middlewares: AuthUser: AuthRole: role: "ADMIN"
30. © PLAID, Inc.　|　Confidential 本⽇のアジェンダ 1. KARTE のアーキテクチャ 2. 従来の認可の⽅法と問題点 3. 新たな認可基盤のアーキテクチャ 4. 新たな認可基盤の設定⽅法 5. 認可基盤の移⾏ 6. 現状と今後の展望 © PLAID, Inc.　|　Confidential 30
31. © PLAID, Inc.　|　Confidential 現状と今後の展望 © PLAID, Inc.　|　Confidential 31 • 主要なサービスへの導⼊が完了して運⽤が始まった段階 ◦ これからどのような問題が起きるかは未知数 ◦ アーキテクチャや設定⽅法について、選択した⽅針の負の側⾯が 現れるとしたらこれから ◦ 詳細な挙動や仕様を開発者が把握できるよう、ドキュメントを 整備してメンテナンスし続けるのも重要 • 管理画⾯に対するリクエストは karte-gateway を通過することに なるので、監査ログを収集するための機構も実装中
32. © PLAID, Inc.　|　Confidential KARTEのアーキテクチャ © PLAID, Inc.　|　Confidential 32
33. © PLAID, Inc.　|　Confidential KARTEのアーキテクチャ © PLAID, Inc.　|　Confidential 33
34. © PLAID, Inc.　|　Confidential 当⽇のブースの写真を貼る We are hiring! https://recruit.plaid.co.jp/platform-engineering-kaigi-2024 プレイドではエンジニアの ご応募をお待ちしています © PLAID, Inc.　|　Confidential 34