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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© PLAID, Inc.　|　Conﬁdential ⾃⼰紹介 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.　|　Conﬁdential 2 https://blog.plaid.co.jp/n/ne59bc83b6438

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© PLAID, Inc.　|　Conﬁdential 主な提供プロダクト/サービス⼀覧 © PLAID, Inc.　|　Conﬁdential 5 領域プロダクト / サービス名概要オンサイトマーケティングオンライン上の顧客⼀⼈ひとりの「今」を可視化。解析結果に応じた⾃由⾃在なアクション設計により企業のマーケティング業務を⽀援。オンサイトマーケティングウェブサイトのあらゆる要素をBlockに分解、スピーディーな改修/ 仮説検証/効果測定を可能にすることで、継続的なパフォーマンス向上とリーンなサイト運営を実現。データ統合顧客が持つデータをKARTEに繋げ、社内外に点在するデータをビッグデータのまま統合/分析/可視化することで、より⾼度なセグメンテーションやアクションを実現。カスタマーサポートオンライン上でサポートを必要とする顧客⼀⼈ひとりの課題を可視化。 FAQ等の適切なサポートチャネルにマッチングさせることで、課題の早期解決を実現。広告 KARTEで蓄積されたデータ等の各種広告媒体との連携を通じて、サイト内外⼀貫した顧客コミュニケーションを実現。マーケティングオートメーション独⾃開発したカスタマージャーニー機能を⽤いて、メールやSMS等によりサイト外にいる顧客コミュニケーションを実現するKARTE版マーケティングオートメーション。

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© PLAID, Inc.　|　Conﬁdential 従来の認可の問題点 © PLAID, Inc.　|　Conﬁdential 11 ● 認可ミドルウェアの実装は社内独⾃の仕組みによってシンボリックリンクで共有されており、それがいくつかの問題を引き起こしていた ○ コードを変更すると全てのサービスに同期的な影響が出る ○ 変更を反映するために全てのサービスをビルドし直す必要がある ● サービスの実装に使える⾔語とフレームワークが制限される ● 認可ミドルウェアを含むライブラリの読み込みに時間がかかっており開発効率を下げている

Slide 12

Slide 12 text

© PLAID, Inc.　|　Conﬁdential 従来の認可の問題点 © PLAID, Inc.　|　Conﬁdential 12 ● 認可ミドルウェアの実装は社内独⾃の仕組みによってシンボリックリンクで共有されており、それがいくつかの問題を引き起こしていた ○ コードを変更すると全てのサービスに同期的な影響が出る ○ 変更を反映するために全てのサービスをビルドし直す必要がある ● サービスの実装に使える⾔語とフレームワークが制限される ● 認可ミドルウェアを含むライブラリの読み込みに時間がかかっており開発効率を下げている

Slide 13

Slide 13 text

© PLAID, Inc.　|　Conﬁdential 従来の認可の問題点 © PLAID, Inc.　|　Conﬁdential 13 ● 認可ミドルウェアの実装は社内独⾃の仕組みによってシンボリックリンクで共有されており、それがいくつかの問題を引き起こしていた ○ コードを変更すると全てのサービスに同期的な影響が出る ○ 変更を反映するために全てのサービスをビルドし直す必要がある ● サービスの実装に使える⾔語とフレームワークが制限される ● 認可ミドルウェアを含むライブラリの読み込みに時間がかかっており開発効率を下げている

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© PLAID, Inc.　|　Conﬁdential 2つの⼤まかな⽅針 © PLAID, Inc.　|　Conﬁdential 15 ● デプロイの影響範囲は⼤きく、全てのサービスに影響する可能性がある ● 管理は中央集権的になり、サービス数が増えても⼀括して扱える ● デプロイの影響範囲は⼩さく、影響範囲を特定のサービスに絞ることができる ● 管理はサービスごとになり、サービス数が増えるとメンテナンスコストが懸念される

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© PLAID, Inc.　|　Conﬁdential アーキテクチャを決めるまでの議論 © PLAID, Inc.　|　Conﬁdential 17 ● どちらの案も⼀⻑⼀短がある ○ ここでは開発スピードを考慮して、デプロイの影響を⼩さくとどめられるアーキテクチャを採⽤した ● 最終的には「後から⽅針転換が必要になったとしても、分散しているものを束ねる⽅が変更が容易だろう」という考えが決め⼿になった ○ 双⽅のアーキテクチャのメリットとデメリットは表裏⼀体であり、どちらが吉と出るか⾒通すのは難しい

Slide 18

Slide 18 text

© PLAID, Inc.　|　Confidential 従来の⽅法との⽐較 © PLAID, Inc.　|　Confidential 18 ● 認可の設定は config で与える ● 認可時にデータベースから取得したデータはリクエストヘッダに乗せてアプリケーションで利⽤する ● 認可の設定はアプリケーションの実装で決まる ● 認可時にデータベースから取得したデータはミドルウェア間で受け渡してアプリケーションで利⽤する

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© PLAID, Inc.　|　Confidential 設定ファイルの管理⽅法の検討 © PLAID, Inc.　|　Confidential 21 ● 設定ファイルの管理において考慮したいポイントは以下の3つ ○ アプリケーションの開発時に変更を加えられること ○ デプロイやロールバックが容易にできること ○ 複数のリポジトリにまたがって⼆重管理になるのを避けること ● いくつか⽅法はありそうだが... ○ コンテナイメージに設定ファイルを同梱する? ○ karte-ops リポジトリに ConfigMap を作る? ○ Init Containers でよしなに初期化する?

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© PLAID, Inc.　|　Confidential 他の案はどうだったのか © PLAID, Inc.　|　Confidential 23 ● karte-ops リポジトリに ConfigMap を作る ○ 設定⾃体は開発時にも扱うので karte リポジトリに置くが、 karte-ops リポジトリにマニフェストを作るタイミングで同期を取るというアイデア ○ マニフェストは Kustomize を使って管理されているのでプラグインを書くこともできる ○ デプロイフローがわかりにくくなるのが難点 ● Init Containers が配置した設定を karte-gateway で読み取る ○ Pod の中には三種類のコンテナが含まれることになる ○ 開発環境は docker-compose で作られているので、同じことを実現しようとすると複雑になるのが難点

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© PLAID, Inc.　|　Conﬁdential KARTEにおける認可の重要性 © PLAID, Inc.　|　Conﬁdential 25 ● 認可基盤のバグや設定ミスがあった場合、以下の2種類の問題が起こりうる ○ リクエストを過剰に拒絶してしまい、本来はアクセスできるはずの画⾯が⾒えなくなる ○ リクエストを過剰に許容してしまい、本来はアクセスできないはずの画⾯まで⾒えてしまう ● KARTE にはエンドユーザー (= お客様のお客様) の個⼈情報が詰まっているため、特に後者は極めて重⼤な事故になる可能性が⾼く、確実に防がなくてはならない

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© PLAID, Inc.　|　Conﬁdential 既存の実装と同様の設定を作る © PLAID, Inc.　|　Conﬁdential 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"

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© PLAID, Inc.　|　Conﬁdential 現状と今後の展望 © PLAID, Inc.　|　Conﬁdential 31 ● 主要なサービスへの導⼊が完了して運⽤が始まった段階 ○ これからどのような問題が起きるかは未知数 ○ アーキテクチャや設定⽅法について、選択した⽅針の負の側⾯が現れるとしたらこれから ○ 詳細な挙動や仕様を開発者が把握できるよう、ドキュメントを整備してメンテナンスし続けるのも重要 ● 管理画⾯に対するリクエストは karte-gateway を通過することになるので、監査ログを収集するための機構も実装中