Slide 1

Slide 1 text

進化する事業とデータ構造 ~Cloudbaseの場合~
 Cloudbase株式会社
 tockn (佐藤 琢斗)
 1 どう設計しておけばよかった?各社事例で振り返る データ構造x技術負債LT
 © Cloudbase Inc. All rights reserved

Slide 2

Slide 2 text

自己&事業紹介 
 このLTでわかること
 ・Cloudbaseの事業がどう進化し、ある機能において求められるデータ構造がどう変化したかわかる
 ・データ構造変化のマイグレーションをどう行ったかがわかる
 ・将来を予見したデータ設計の勘所がわかる
 2 © Cloudbase Inc. All rights reserved

Slide 3

Slide 3 text

© Cloudbase Inc. All rights reserved 3 00 / はじめに
 目次
 1. 自己紹介&事業紹介
 2. 事業の進化とデータ構造の変化
 3. どのようにマイグレーションしたか
 4. どう設計しておけばよかった?
 5. まとめ


Slide 4

Slide 4 text

4 © Cloudbase Inc. All rights reserved 自己紹介&事業紹介 01.

Slide 5

Slide 5 text

自己&事業紹介 
 自己紹介
 5 © Cloudbase Inc. All rights reserved 佐藤 琢斗(tockn)
 ・20新卒で株式会社ディー・エヌ・エー
  ・ライブ配信サービスの開発、立ち上げに携わる
 ・22年8月にCloudbase株式会社へJOIN
  ・初期のスキャナ、アプリケーションを開発
  ・現在はアプリケーションチームのエンジニア
 tockn_s
 tockn


Slide 6

Slide 6 text

自己&事業紹介 
 Cloudbaseについて
 ・パブリッククラウド向けリスク検出・対応サポートSaaS
 ・設定ミス、脆弱性スキャンがある
 ・βリリースは2022/03
 
 ・スタートアップ
  ・2022/08 シード 1.3億調達
  ・2024/02 シリーズA 11.5億調達
 6 © Cloudbase Inc. All rights reserved

Slide 7

Slide 7 text

7 © Cloudbase Inc. All rights reserved 事業の進化とデータ構造の変化 02.

Slide 8

Slide 8 text

事業の進化とデータ構造の変化 
 はじまりは設定ミススキャン
 ・クラウドのセキュリティを守るSaaSとしてまずは設定ミススキャンを提供
  ・パブリック公開されているS3バケット
  ・SSHポートが解放されてるSecurity Group
  ・暗号化されていないEBS
 ・市場に受け入れられ、順調に導入企業が増加
 8 © Cloudbase Inc. All rights reserved

Slide 9

Slide 9 text

事業の進化とデータ構造の変化 
 脆弱性スキャンへの進出
 ・設定ミスだけでなく、ワークロードに潜む脆弱性にも課題がありそう
  ・既存のお客様からの要望もあった
 9 © Cloudbase Inc. All rights reserved

Slide 10

Slide 10 text

事業の進化とデータ構造の変化 
 脆弱性スキャンへの進出
 ・設定ミスだけでなく、ワークロードに潜む脆弱性にも課題がありそう
  ・既存のお客様からの要望もあった
 ・会社として今脆弱性領域へ踏み込むべきか?
  ・当時社員は8人くらいだった
 10 © Cloudbase Inc. All rights reserved

Slide 11

Slide 11 text

事業の進化とデータ構造の変化 
 脆弱性スキャンへの進出
 ・設定ミスだけでなく、ワークロードに潜む脆弱性にも課題がありそう
  ・既存のお客様からの要望もあった
 ・会社として今脆弱性領域へ踏み込むべきか?
  ・当時社員は8人くらいだった
  → まずはコンテナイメージの脆弱性スキャン機能で市場を伺ってみる
 11 © Cloudbase Inc. All rights reserved

Slide 12

Slide 12 text

12 © Cloudbase Inc. All rights reserved 事業の進化とデータ構造の変化


Slide 13

Slide 13 text

13 © Cloudbase Inc. All rights reserved 脆弱性スキャンの進化とテーブル設計の変化

Slide 14

Slide 14 text

事業の進化とデータ構造の変化 
 コンテナスキャンのデータ構造v1
 ・クラウド上のコンテナイメージをスキャンし、脆弱性を検出
 ・スキャン結果のデータ構造
  ・スキャン対象のコンテナリポジトリ&イメージと、それに紐づく脆弱性を表したテーブル設計
 14 © Cloudbase Inc. All rights reserved コンテナイメージテーブル 
 
 イメージ1, リポジトリ1
 イメージ2, リポジトリ1
 ︙
 コンテナイメージの検出脆弱性テーブル 
 
 イメージ1, CVE-2021-44228
 イメージ1, CVE-2022-22965
 イメージ2, CVE-2021-44228
 ︙
 ⚠ かなり抽象的なイメージです 
 コンテナリポジトリテーブル 
 
 リポジトリ1, name-1,
 リポジトリ2, name-2
 ︙


Slide 15

Slide 15 text

事業の進化とデータ構造の変化 
 リリースした結果
 ・新規契約獲得など、市場に受け入れられた!
 15 © Cloudbase Inc. All rights reserved

Slide 16

Slide 16 text

事業の進化とデータ構造の変化 
 リリースした結果
 ・新規契約獲得など、市場に受け入れられた!
 ・VMスキャンもやりたい
 16 © Cloudbase Inc. All rights reserved

Slide 17

Slide 17 text

事業の進化とデータ構造の変化 
 VMスキャンのデータ構造v1
 ・Amazon EC2などのVMに潜む脆弱性を検出
 ・スキャン結果のデータ構造
  ・スキャン対象のVMと、それに紐づく脆弱性を表したテーブル設計
 17 © Cloudbase Inc. All rights reserved VMテーブル
 
 VM1, hoge-server
 VM2, fuga-server
 ︙
 VMの検出脆弱性テーブル 
 
 VM1, CVE-2021-44228
 VM1, CVE-2022-22965
 VM2, CVE-2021-44228
 ︙
 ⚠ かなり抽象的なイメージです 


Slide 18

Slide 18 text

事業の進化とデータ構造の変化 
 リリースした結果
 ・新規契約獲得など、市場に受け入れられた!
 18 © Cloudbase Inc. All rights reserved

Slide 19

Slide 19 text

事業の進化とデータ構造の変化 
 リリースした結果
 ・新規契約獲得など、市場に受け入れられた!
 ・Functionスキャンもやりたい!
 19 © Cloudbase Inc. All rights reserved

Slide 20

Slide 20 text

事業の進化とデータ構造の変化 
 リリースした結果
 ・新規契約獲得など、市場に受け入れられた!
 ・Functionスキャンもやりたい!
 ・検出された脆弱性の横断検索もやりたい!
 20 © Cloudbase Inc. All rights reserved

Slide 21

Slide 21 text

事業の進化とデータ構造の変化 
 Functionスキャンのデータ構造????
 ・AWS LambdaなどのFunctionに潜む脆弱性スキャン
 ・スキャン結果のデータ構造????
  ・スキャン対象のFunctionと、それに紐づく脆弱性を表したテーブル設計…????
 21 © Cloudbase Inc. All rights reserved Functionテーブル???
 
 Function1, hoge-function
 Function2, fuga-function
 ︙
 Functionの検出脆弱性テーブル??? 
 
 Function1, CVE-2021-44228
 Function1, CVE-2022-22965
 Function2, CVE-2021-44228
 ︙
 ⚠ かなり抽象的なイメージです ??


Slide 22

Slide 22 text

ちょっと待った!
 22 © Cloudbase Inc. All rights reserved

Slide 23

Slide 23 text

事業の進化とデータ構造の変化 
 Functionスキャン…?ちょっと待った!
 ・スキャンの種類毎にデータが独立
 ・冗長!横断検索もできない!
 23 © Cloudbase Inc. All rights reserved コンテナイメージテーブル 
 
 イメージ1, リポジトリ1,
 イメージ2, リポジトリ2
 ︙
 コンテナイメージの検出脆弱性テーブル
 
 イメージ1, CVE-2021-44228
 イメージ1, CVE-2022-22965
 イメージ2, CVE-2021-44228
 ︙
 VMテーブル
 
 VM1, hoge-server,
 VM2, fuga-server
 ︙
 VMの検出脆弱性テーブル 
 
 VM1, CVE-2021-44228
 VM1, CVE-2022-22965
 VM2, CVE-2021-44228
 ︙
 Functionテーブル
 
 Function1, hoge-function,
 Function2, fuga-function
 ︙
 Functionの検出脆弱性テーブル 
 
 Function1, CVE-2021-44228
 Function1, CVE-2022-22965
 Function2, CVE-2021-44228
 ︙
 ⚠ かなり抽象的なイメージです 


Slide 24

Slide 24 text

事業の進化とデータ構造の変化 
 Functionスキャン…?ちょっと待った!
 ・スキャンの種類毎にデータが独立
 ・冗長!横断検索もできない!
 
 データ構造を変えよう!
 24 © Cloudbase Inc. All rights reserved コンテナイメージテーブル 
 
 イメージ1, リポジトリ1,
 イメージ2, リポジトリ2
 ︙
 コンテナイメージの検出脆弱性テーブル
 
 イメージ1, CVE-2021-44228
 イメージ1, CVE-2022-22965
 イメージ2, CVE-2021-44228
 ︙
 VMテーブル
 
 VM1, hoge-server,
 VM2, fuga-server
 ︙
 VMの検出脆弱性テーブル 
 
 VM1, CVE-2021-44228
 VM1, CVE-2022-22965
 VM2, CVE-2021-44228
 ︙
 Functionテーブル
 
 Function1, hoge-function,
 Function2, fuga-function
 ︙
 Functionの検出脆弱性テーブル 
 
 Function1, CVE-2021-44228
 Function1, CVE-2022-22965
 Function2, CVE-2021-44228
 ︙
 ⚠ かなり抽象的なイメージです 


Slide 25

Slide 25 text

事業の進化とデータ構造の変化 
 データ構造を変更
 ・脆弱性スキャン対象のリソースを表す抽象的なテーブル
  ・脆弱性検出結果はその抽象リソーステーブルに紐づける
  ・要はCTI (Class Table Inheritance)
 ・扱いやすく、横断検索も可能に
 25 © Cloudbase Inc. All rights reserved ⚠ かなり抽象的なイメージです 
 脆弱性スキャン対象リソーステーブル 
 id , type
 リソース1, コンテナ
 リソース2, コンテナ
 リソース3, VM
 リソース4, VM
 リソース5, Function
 リソース6, Function
 ︙
 検出脆弱性テーブル 
 
 id-1, CVE-2021-44228
 id-2, CVE-2022-22965
 id-3, CVE-2021-44228
 ︙
 コンテナイメージテーブル 
 
 リソース1, リポジトリ1,
 リソース2, リポジトリ2
 ︙
 VMテーブル
 
 リソース3, hoge-server,
 リソース4, fuga-server
 ︙
 Functionテーブル
 
 リソース5, hoge-function,
 リソース6, fuga-function
 ︙


Slide 26

Slide 26 text

26 © Cloudbase Inc. All rights reserved どのようにマイグレーションしたか? 03.

Slide 27

Slide 27 text

どのようにマイグレーションしたか? 
 データの特性を考える
 ・スキャン結果はスキャン時にしか更新されない(それはそう)
 ・スキャン結果はステートレス
  ・前回のスキャン結果が今回のスキャン結果に影響を及ぼさない
 ・Scanner, Loaderでコンポーネントが分かれている
 27 © Cloudbase Inc. All rights reserved

Slide 28

Slide 28 text

どのようにマイグレーションしたか? 
 データの特性を考える
 ・スキャン結果はスキャン時にしか更新されない(それはそう)
 ・スキャン結果はステートレス
  ・前回のスキャン結果が今回のスキャン結果に影響を及ぼさない
 ・Scanner, Loaderでコンポーネントが分かれている
 
 ダブルライトできるね
 28 © Cloudbase Inc. All rights reserved

Slide 29

Slide 29 text

どのようにマイグレーションしたか? 
 ダブルライト
 ・新設計のテーブルを新たに用意
 ・Loader v2を開発
  ・Loader v1, v2を同時に動かす
 ・整合性が確認されるまで、アプリケーションではv1を返す
 29 © Cloudbase Inc. All rights reserved

Slide 30

Slide 30 text

どのようにマイグレーションしたか? 
 ダブルライト
 ・新設計のテーブルを新たに用意
 ・Loader v2を開発
  ・Loader v1, v2を同時に動かす
 ・整合性が確認されるまで、アプリケーションではv1を返す
 30 © Cloudbase Inc. All rights reserved ↑どうやって確認する? 


Slide 31

Slide 31 text

どのようにマイグレーションしたか? 
 整合性を確かめたい
 データのパターンが膨大
 ・クラウドプロバイダ
 ・対象サービス
 ・検出項目
 ・脆弱性
 31 © Cloudbase Inc. All rights reserved AWS
 Google Cloud
 Azure
 CVE-2021-44228
 CVE-2022-22965
 GCE
 ECS
 ECR
 GCR
 EC2
 Key Vault
 Windows
 Ubuntu
 Amazon Linux
 RHEL
 S3
 IAM
 検出対象・環境は多岐に渡る
 CVE-2023-44487
 SSHポート解放
 ストレージ公開


Slide 32

Slide 32 text

どのようにマイグレーションしたか? 
 整合性を確かめたい
 データのパターンが膨大
 ・クラウドプロバイダ
 ・対象サービス
 ・検出項目
 ・脆弱性
 32 © Cloudbase Inc. All rights reserved AWS
 Google Cloud
 Azure
 CVE-2021-44228
 CVE-2022-22965
 GCE
 ECS
 ECR
 GCR
 EC2
 Key Vault
 Windows
 Ubuntu
 Amazon Linux
 RHEL
 S3
 IAM
 検出対象・環境は多岐に渡る
 CVE-2023-44487
 → 事前に検証データを用意するのは難しい
 SSHポート解放
 ストレージ公開


Slide 33

Slide 33 text

どのようにマイグレーションしたか? 
 不整合チェッカーを開発
 ・本番環境のデータで検証する
 ・v1, v2の集計値を比較し、不整合が無いかをチェックするツール
  ・検出数サマリなど
 ・デイリーで検証し、異常があればSlack通知
 (Platform Teamが開発してくれた)
 
 ・不整合があれば修正し、潰しきったのを見てv2へ切り替え
 33 © Cloudbase Inc. All rights reserved

Slide 34

Slide 34 text

34 © Cloudbase Inc. All rights reserved どう設計しておけばよかった? 04.

Slide 35

Slide 35 text

どう設計しておけばよかった? 
 なぜデータ構造が負債化するのか
 ・一般的に、大きく分けて2つ(と勝手に僕は思っている)
  ・そもそも要件を満たす設計ができていなかった
  ・設計当時の要件から変化・拡張があった
 35 © Cloudbase Inc. All rights reserved

Slide 36

Slide 36 text

どう設計しておけばよかった? 
 なぜデータ構造が負債化するのか
 ・一般的に、大きく分けて2つ(と勝手に僕は思っている)
  ・そもそも要件を満たす設計ができていなかった
  ・設計当時の要件から変化・拡張があった
 36 © Cloudbase Inc. All rights reserved

Slide 37

Slide 37 text

どう設計しておけばよかった? 
 なぜデータ構造が負債化するのか
 ・一般的に、大きく分けて2つ(と勝手に僕は思っている)
  ・そもそも要件を満たす設計ができていなかった
  ・設計当時の要件から変化・拡張があった
 
 → 常に要件の変化・拡張を完璧に考慮した設計をすればよい
 37 © Cloudbase Inc. All rights reserved

Slide 38

Slide 38 text

どう設計しておけばよかった? 
 なぜデータ構造が負債化するのか
 ・一般的に、大きく分けて2つ(と勝手に僕は思っている)
  ・そもそも要件を満たす設計ができていなかった
  ・設計当時の要件から変化・拡張があった
 
 → 常に要件の変化・拡張を完璧に考慮した設計をすればよい?
   ほんとうに。。。?
 38 © Cloudbase Inc. All rights reserved

Slide 39

Slide 39 text

どう設計しておけばよかった? 
 設計時の視点と予見
 ・ある機能要件の開発時、3種類の予見が潜んでいる(と勝手に僕は思っている)
  ・将来的に開発予定だが今はやらない機能要件
  ・将来的に開発するかわからないが、何となくやりそうな機能要件
  ・思いも寄らない機能要件
 39 © Cloudbase Inc. All rights reserved

Slide 40

Slide 40 text

どう設計しておけばよかった? 
 設計時の視点と予見
 ・ある機能要件の開発時、3種類の予見が潜んでいる(と勝手に僕は思っている)
  ・将来的に開発予定だが今はやらない機能要件
  ・将来的に開発するかわからないが、何となくやりそうな機能要件
  ・思いも寄らない機能要件
 40 © Cloudbase Inc. All rights reserved どこまで設計対象に含めるか?


Slide 41

Slide 41 text

どう設計しておけばよかった? 
 将来的に開発予定だが今はやらない機能要件
 ・基本的には考慮するべき
 ・ただし「今考慮することのコスト」vs「将来考慮することのコスト&マイグレーションコスト」との天秤
   ・例えばマイグレーションコストが低い予想が付き、現段階で要件定義をすることのコストが高いのであれば
    設計スコープから外すべき
 41 © Cloudbase Inc. All rights reserved

Slide 42

Slide 42 text

どう設計しておけばよかった? 
 将来的に開発するかわからないが何となくやりそうな機能要件
 ・考慮しないほうがよい場合が多そう
 ・こちらも「今考慮することのコスト」vs「将来考慮することのコスト&マイグレーションコスト」との天秤
 ・ただしこの解像度の低さから要件定義をするコストは高く付きがち
  ・諦めて要件定義が曖昧な状態での設計をするとギャンブル性を持ったオーバーエンジニアリングになる
 42 © Cloudbase Inc. All rights reserved

Slide 43

Slide 43 text

どう設計しておけばよかった? 
 思いも寄らない機能要件
 ・考慮するべきではない
 ・確実にオーバーエンジニアリングだと思う
 43 © Cloudbase Inc. All rights reserved

Slide 44

Slide 44 text

どう設計しておけばよかった? 
 今回のケースで考えてみる
 ・VMスキャン、Functionスキャンは「将来的に開発予定だが今はやらない機能要件」
  ・今回はやらないが、脆弱性領域に本格的に踏み出すならば開発することはわかっていた
 ・横断検索は「将来的に開発するかわからないが何となくやりそうな機能要件」
  ・「横断検索あったら便利だろうな〜」くらいの気持ちはあった
 44 © Cloudbase Inc. All rights reserved

Slide 45

Slide 45 text

どう設計しておけばよかった? 
 コストの天秤
 ・「今考慮することのコスト」vs「将来考慮することのコスト&マイグレーションコスト」
 45 © Cloudbase Inc. All rights reserved

Slide 46

Slide 46 text

どう設計しておけばよかった? 
 コストの天秤
 ・「今考慮することのコスト」vs「将来考慮することのコスト&マイグレーションコスト」
 ・今考慮することのコスト
  ・VMスキャン、Functionスキャンの仕様、技術的制約の明確化が必要
   ・脆弱性市場をまずは見に行くという目的の上では、コスト高
 46 © Cloudbase Inc. All rights reserved

Slide 47

Slide 47 text

どう設計しておけばよかった? 
 コストの天秤
 ・「今考慮することのコスト」vs「将来考慮することのコスト&マイグレーションコスト」
 ・今考慮することのコスト
  ・VMスキャン、Functionスキャンの仕様、技術的制約の明確化が必要
   ・脆弱性市場をまずは見に行くという目的の上では、コスト高
 ・将来考慮することのコスト&マイグレーションコスト
  ・スキャンの仕様、技術的制約の明確化コスト自体は今も将来も変わらない
  ・性質上、ダブルライト可能でマイグレーションコストが低
 47 © Cloudbase Inc. All rights reserved

Slide 48

Slide 48 text

どう設計しておけばよかった? 
 コストの天秤
 ・「今考慮することのコスト」vs「将来考慮することのコスト&マイグレーションコスト」
 ・今考慮することのコスト
  ・VMスキャン、Functionスキャンの仕様、技術的制約の明確化が必要
   ・脆弱性市場をまずは見に行くという目的の上では、コスト高
 ・将来考慮することのコスト&マイグレーションコスト
  ・スキャンの仕様、技術的制約の明確化コスト自体は今も将来も変わらない
  ・性質上、ダブルライト可能でマイグレーションコストが低
 48 © Cloudbase Inc. All rights reserved

Slide 49

Slide 49 text

どう設計しておけばよかった? 
 結果的に
 ・どう設計しておけばよかった?
  ・この設計で良かったと言えそう(ただし、非常に結果論的である😇)
  ・マイグレーションを推進してくれたメンバーに感謝
  ・不整合チェッカーのようなマイグレーションを楽にする基盤作りも大切
 49 © Cloudbase Inc. All rights reserved

Slide 50

Slide 50 text

50 © Cloudbase Inc. All rights reserved まとめ 05.

Slide 51

Slide 51 text

まとめ
 まとめ
 ・脆弱性スキャンの領域拡大と共に求められるデータ構造が変化した
 ・変化に対応するためにダブルライトと不整合チェッカーでマイグレーションした
 ・将来の機能要件も潜む中、コストの天秤を見て設計のスコープをコントロールすることが大切
 51 © Cloudbase Inc. All rights reserved

Slide 52

Slide 52 text

52 © Cloudbase Inc. All rights reserved We are hiring!
 Cloudbase Engineer Entrance Book