脱SaaS！FDEを支えるプロビジョニングと分離設計

AWS Summit Japan 2026の発表資料です

Transcript

1. © CADDi Inc. 脱SaaS！ FDEを⽀えるプロビジョニングと 分離設計 キャディ株式会社 データプラットフォーム技術責任者 鈴⽊ 健⼀
2. © CADDi Inc. ⾃⼰紹介 2 新卒でNTTデータに⼊社。ミッションクリティカルシステムのアーキ テクチャ設計‧開発に従事した後、より堅牢な開発を求めて、プログ ラミング⾔語理論を研究。その後、Visionalにてサイバーセキュリ ティ事業の⽴ち上げやプロダクト開発を牽引。 ContractSでVP of Development等、ログラスでCTO室⻑等を歴任 し、技術組織の基準を引き上げる役割を担う。 ⽇本のソフトウェアをグローバルへ届けるべく、2026年キャディに⼊ 社し、複雑なビジネスを⽀えるプラットフォーム設計に取り組む。 Kenichi Suzuki 鈴⽊ 健⼀ X: @_knih
3. © CADDi Inc. 01 ソフトウェア提供形態の再定義 02 FDEを⽀えるプラットフォーム 03 宣⾔的⾃動プロビジョニング 04 Cedarによる認可制御と分離設計 05 まとめ 本⽇のお品書き 3
4. © CADDi Inc. © CADDi Inc. ソフトウェア提供形態の再定義 4 01
5. © CADDi Inc. SaaS が届かない領域に、 ソフトウェアを届ける 5
6. © CADDi Inc. 業種 素材 加⼯ 組⽴ 装置 化学 電機 × 部⾨ 設計 調達 ⽣産技術 品質保証 原価企画 保守 × データ構造 BOM 構造 図⾯ルール 変更管理単位 トレーサビリティ 業種‧部⾨‧データ構造、その全てが顧客ごとに違う 製造業の業務は、SaaS の公約数では再現できない深さがある 6 … … …
7. © CADDi Inc. 既存モデルの特性とジレンマ 7 業務にシステムを合わせるか、システムに業務を合わせるか 個社開発 各社固有の業務フローや既存システムとの統 合など、標準機能だけでは解決できない⾼度 な要求。 プロダクト SaaSモデル プロダクトから複数の顧客へ同⼀の機能（体 験）を提供。個別最適化が困難な構造。 顧客 顧客 システム システム システム 業務の深さ‧幅にどう対応しつつ、スケール可能にするには？
8. © CADDi Inc. ⼀からアプリケーションを作ると膨⼤な⼯程が必要 8 顧客 システム システム システム 業務理解‧要件 業務オブザベーション / 業務ドメイ ンモデリング / PRD / 受⼊基準 … アーキテクチャ‧⽅式設計 アプリケーション構造∕設計⽅針∕ ⾮同期⽅式… アプリケーション本体実装 業務集約‧ドメイン / 業務 API / ス キーマ / 業務画⾯ / 連携 … DevOps‧CI/CD‧SRE テナントプロビジョニング / パイプ ライン / 観測 / 脆弱性対応 … QA‧テスト‧性能 テストフレームワーク / E2E / 性能 試験 / 本番準備度ゲート … セキュリティ‧コンプラ 認証‧認可 / 監査ログ/ SOC2 / ISO27001 / 脅威モデリング … … 膨⼤な⼯程∕⼯数を顧客数分だけ都度⾏っていると スケールしない
9. © CADDi Inc. SaaSが届かない領域に当てる、もう⼀つの提供形態 9 顧客の業務⽂脈に深く⼊り、現場の問題を解きつつ、スケールもする プラットフォーム 顧客 共通基盤の上で、現場の問題をソフトウェアで解く App App App FDE （Forward Deployed Engineer) 深さ 広さ
10. © CADDi Inc. © CADDi Inc. FDEを⽀えるプラットフォーム 10 02
11. © CADDi Inc. アプリケーション領域 業務理解‧要件 アプリケーション本体開発 プラットフォーム領域 アーキテクチャ‧⽅式設計 DevOps‧CI/CDパイプライン基盤 モニタリング‧SLO基盤 認証‧SSO‧監査ログ セキュリティ基盤 FDEはアプリケーションに集中 共通化‧抽象化できる⼯程‧機能は、プラットフォームに集約 顧客価値検証 11 ユーザー管理‧テナント管理‧アプリケーション管理 環境プロビジョニング 境界分離‧認可制御 … …
12. © CADDi Inc. アプリケーション領域 業務理解‧要件 アプリケーション本体開発 プラットフォーム領域 アーキテクチャ‧⽅式設計 DevOps‧CI/CDパイプライン基盤 モニタリング‧SLO基盤 認証‧SSO‧監査ログ セキュリティ基盤 FDEはアプリケーションに集中 共通化‧抽象化できる⼯程は、プラットフォームに集約 顧客価値検証 12 ユーザー管理‧テナント管理‧アプリケーション管理 環境プロビジョニング 境界分離‧認可制御 … … テナント∕アプリケーション プロビジョニング Cedarによる認可制御
13. © CADDi Inc. © CADDi Inc. 宣⾔的⾃動プロビジョニング 13 03
14. © CADDi Inc. 異なる要件‧構成の環境をどうするか 個別 共通 テナントやアプリケーションごとに求められるインフラ要件や構成が異なる 14 テナント App テナント App App プラットフォーム プロビジョニング の対象
15. © CADDi Inc. 構成軸 テナントA テナントB テナントC テナントD 契約ティア Enterprise Standard Enterprise Standard 環境形態 占有環境 DB / ストレージ Aurora PostgreSQL Aurora PostgreSQL + S3 Aurora PostgreSQL + S3 DynamoDB ⾮同期処理 SQS + Lambda なし SQS SQS SLO 99.95% 99.9% 99.99% 99.9% 構成例：同じアプリケーションでも、顧客（テナント） × 構成軸 × アプリケーション要件で構成が変わる ⼿動プロビジョニングの限界 15 … C : 考慮すべきバリエーションの総数 N : テナント数 S : 1テナントあたりのアプリケーション数 D : 構成軸数 Vi : i番⽬の構成軸における構成選択肢の数（i=1,2,...,D） … 占有環境 共有環境 共有環境 ※構成はあくまで例であり、実際のメニューとは異なります 個別に⼿動構築では破綻する
16. © CADDi Inc. 16 運⽤が回らなくなる‧‧‧！
17. © CADDi Inc. FDEの責務 What 何が欲しいか、を記述 Platformの責務 How どう組み⽴てるか、を⾃動化 関⼼の分離により、個社別要件が増えてもプラットフォーム側で吸収可能にする 仕様だけを宣⾔して、あとは⾃動構築できるようにしたい 役割を分担 17
18. © CADDi Inc. 構成要件を投⼊するとテナント環境が⾃動で⽴ち上がる 宣⾔的⾃動プロビジョニングの全体像 18 宣⾔ 構成要件を記述 構成を検証‧合 成 検証 構築 完了 リソースを作成 プロビジョニング 完了 FDE Platform
19. © CADDi Inc. deployment: #Shared & { tenant: "sample-tenant" application: "sample-application" version: "3.2.0" tier: "enterprise" region: "ap-northeast-1" apps: { frontend: { role: "web", size: "S", routes: ["/sample-application"] } backend: ... worker: {role: "worker", size: "S"} } data: {primary: "postgres", objectStore: true} sla: "99.9%" ... 構成要件を記述する （不正な設定は起動前に弾かれる） • テナント / アプリケーション識別 • 契約ティア(shared / dedicated) • アプリ構成(CPU / Memory / image) • 機能フラグ etc. VPCやALB等はプラットフォームで吸収し、 アプリケーションに関わるところだけ記載 構成要件の宣⾔ 19 サンプルイメージ CUEによる構成定義
20. © CADDi Inc. 構成のカタログ化 共通定義により構成をパターン化、テナント固有の構成を最⼩化する 20 // tier カタログ: 分離モデル × アカウント の2軸 _tierLayer: [string]: { model: "pool" | "bridge" | "silo" // 分離モデル account: "shared" | "dedicated" // アカウント・トポロジ cmk: bool // 専用暗号鍵 multiAz: bool ... } _tierLayer: { // 共有compute + db-per-tenant trial: {model: "bridge", account: "shared", cmk: false, multiAz: false} // silo + 専用AWSアカウント enterprise: {model: "silo", account: "dedicated", cmk: true, multiAz: true} ... } #Tenant { tier: "trial" | "enterprise" | ... ... example-company: #Tenant & { tier: "trial", ... } カタログ化した構成 実際のテナントの定義 カタログから選ぶだけで構 成が作れるようになる
21. © CADDi Inc. _baseDefaults モジュールを合成して構成をつくる 21 #Tenant: { tenant: string, tier: ..., app: ..., region: ... // ① 合成：モジュールを & で重ねて effective（中間の完成設定） effective: _baseDefaults & _tierLayer[tier] & _appLayer[app] & overrides effective: {region: _region} ... {observability:true} _tierLayer["enterprise"] {isolation:"silo", cmk:true, multiAz:true} _appLayer["helloworld"] {db:"postgres", objectStore:true, async:"queue", sla:"99.95%", cmk:true, apps:{…} } overrides {customDomain: "xxxx.example.com"} 基本設定 契約ティア アプリ設定 個社設定
22. © CADDi Inc. 構築 宣⾔された構成の適⽤にはTerraformを使う 22 approve terraform plan terraform apply 環境 検証 宣言 構築 tf: { resource: { terraform_data: { for n, a in effective.apps { "ecs_\(n)": {input: ... 生成 不正な設定は事前に 弾かれる
23. © CADDi Inc. 環境イメージ 23 Shared領域 Dedicated領域 ECS Cluster DB ALB ECS Cluster DB ALB … … テナントX テナントY VPC Aurora Cluster (共通) Transit Gateway NAT Gateway テナント A テナント B テナント C Network / CloudFront / WAF / Route53 (テナント別 distribution) … 要件に合わせてプール、サイロ、ブリッジを組み合わせる
24. © CADDi Inc. 契約ティア Standard / Enterprise / Premium 環境形態 shared / dedicated ⾮同期処理 なし / SQS / EventBridge / SFN ストレージ Aurora PG / DynamoDB / +S3 / DSQL SLO 99.9% / 99.95% / 99.99% ネットワーク Public / VPC-Only / PrivateLink 異なる要件の環境を⾃動構築‧管理 24 モジュラーな仕様宣⾔により、構成要件や多数のテナント‧アプリケーションをシンプルに管理 … 多数の個別環境でも、要件が⾒通しやすくなる
25. © CADDi Inc. © CADDi Inc. Cedarによる認可制御と分離設計 25 04
26. © CADDi Inc. アプリに if ⽂で書く限界 書き忘れ — action 追加時に制御が漏れる 品質ブレ — アプリ間で実装ブレ、テナント越境の リスク レビュー限界 — 物理的に追えない 不変量を証明できない — 「絶対に X しない」をテ ストで網羅は不可能 監査が困難 — 認可ロジックがコード中に分散 ポリシー⾔語に求める要件 外出し — アプリのコード外で記述‧管理 型安全 — スキーマファースト、typo はビルド時に 検出 形式検証 — 「絶対に X しない」を証明可能 不変量テスト — Property-based testing との相性 シンプルな意味論 — 明確な評価規則 ⾼速‧ステートレス — アプリパフォーマンスの邪 魔にならない アプリの if ⽂/式による制御の限界 26
27. © CADDi Inc. 観点 OPA / Rego Cedar (AWS) 選択 型安全 スキーマレス、ランタイム検証 スキーマファースト。typo はビルド時に検出 型安全 形式検証 困難(表現⼒ゆえ停⽌性問題) SMT で証明可能(Cedar Analysis) 証明可能性 不変量テスト 単体テスト中⼼ Property-based testing と⾼相性 常時検証 評価規則 default deny / allow 等、複数モデル Forbid Overrides Permit ── 安全な基本規則 単純で頑健 運⽤知⾒ 独⽴コミュニティ、K8s 等で普及 AWS IAM の進化形 ── 知⾒をそのまま流⽤ 知⾒流⽤ Cedarによる認可制御 表現⼒ Datalog ベース、強⼒。汎⽤ポリシー⾔ 語 意図的に制限(decidable)。認可特化 制限が必要 27 Regoは強⼒ゆえに検証不能になる Cedarは表現⼒が制限される代わりに、証明可能性を得る
28. © CADDi Inc. 禁⽌ Policy: テナント越境 @id("SYSTEM_007_ORGANIZATION_BOUNDARY") forbid ( principal is Sample::User, action, resource is sample::Tenant ) when { principal.organization_id != resource.organization_id }; Policy で「絶対 xxx しない」を保証する 28 @id("TENANT_001_OWNER_IT_ADMIN_SYSTEM") permit ( principal is Sample::User, action in [ Action::"Tenant::UpdateTenant", Action::"Tenant::CreateSSOConnection", … ], resource is Sample::Tenant ) when { principal in resource && // 自分の所属 ( context.membership_role == "owner" || context.membership_role == "it_admin" ) }; 許可 Policy: オーナー/IT管理者のテナント操作 forbid（禁⽌） は permit （許可）を上書きする ので、他テナントへのアクションは禁⽌される
29. © CADDi Inc. 認可アーキテクチャ 認可とは、誰に‧何に‧何をしてよいか、を判定する仕組み 29 Platform Tenant Application Feature Data 閲覧/編集/承認など、何ができるか どのデータにアクセスできるか 誰がどのアプリを使えるか 誰がテナントに⼊れるか、管理できるか 部品 サプライヤー 原価 P001 P002 X社 Y社 120.0 300.0 Application + Cedar Cedar authz paltform
30. © CADDi Inc. © CADDi Inc. まとめ 30 05
31. © CADDi Inc. • プラットフォームの⼒で、SaaSで届かない領域にアプローチ • プラットフォームでプロビジョニングや認可制御を⾏い、FDEの機動⼒を サポート • 認可は宣⾔とPolicyの構造で守る SaaS で届かない領域に届くための基盤設計で、FDEを⽀える 脱 SaaS は、アプリケーション × FDE × 構造化されたプラット フォームで実現する 31
32. © CADDi Inc.