PaaSとSaaSの境目で信頼性と開発速度を両立する〜TROCCO®︎のこれまでとこれから〜

Slide 1

Slide 1 text

primeNumber Inc. © PaaSとSaaSの境目で信頼性と開発速度を両立する〜TROCCO®のこれまでとこれから〜 @アーキテクチャConference 2024 2024/11/26 株式会社primeNumber プロダクト開発本部 CTO室室長中根直孝

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© primeNumber Inc. 3 © primeNumber Inc. 3 あらゆるデータを、ビジネスの力に変える。我々は、「あらゆるデータを、ビジネスの力に変える」データテクノロジーカンパニーです。データが爆発的に増えていく時代に、誰もがすばやく、簡単にデータを使える環境を構築し、データ活用までのプロセスを最適化。高度なテクノロジーと独自のアイデアで、世界中のビジネスを支援します。 VISION

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© primeNumber Inc. 8 中根直孝 (@gtnao) 株式会社primeNumber Staff Software Engineer プロダクト開発本部 CTO室室長 ● 2017 エンジニアキャリアスタート ● 2018/11 primeNumber入社 ○ TROCCO®のリリースと同月 ● TROCCO®の開発に黎明期から従事 ○ 2018〜ゼロイチで色々 ○ 2023〜組織横断で色々

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© primeNumber Inc. 36 アーキテクチャの課題スケールインデプロイ ECS on EC2 スケールアウト環境差分実行中のジョブがノード上に存在するとスケールインできない Lambdaを使ったりと原始的な手法で試行錯誤実行に長時間かかっているジョブがあると、そのECSタスクをローリングアップデートできずデプロイが一向に完了しない 2018年当時、ECS on Fargateに10GB以上のボリュームを割り当てることができず、データ転送サービスとしては致命的にジョブ基盤側はECS on EC2を選択せざるを得ない ECS Task数 = 同時実行可能数 SQSへの流量を見てスケールアウトするなど試行錯誤起動に時間がかかるローカル環境では素のDocker、本番環境ではECSタスクアーキテクチャの差分がある状態での開発トピック具体的な課題

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

© primeNumber Inc. 44 アーキテクチャの課題解決スケールインデプロイ ECS on EC2 スケールアウト環境差分 Cluster Autoscalerにより、Nodeが空いてるとスケールイン実行中のJobがある場合にも完了を待ってくれるイメージタグを差し替えるだけでデプロイ可能に実行中のJobがある場合にも影響を受けない EKSへの乗り換えで脱却 Cluster Autoscalerにより、 Jobを立ち上げるためのNodeリソースがないとスケールアウトローカル環境でも、本番同様のKubernetesアーキテクチャで開発可能にトピック Kubernetesアーキテクチャ変更後

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© primeNumber Inc. 52 データ転送機能以外のケイパビリティ ● データ転送後に、DWH上で変形するELT(extract load tranfrom)が主流に ● それらのジョブをOrchestrateするための機能の必要性運用支援機能データ転送機能 (use Embulk) Transform系機能 (スクラッチ & use dbt) ワークフロー機能 (スクラッチ) 本日はワークフロー機能についてお話しします

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

© primeNumber Inc. 55 ワークフロー機能の技術選定 OSSを活用 👍 初期開発/拡充の工数削減 👎 OSSの仕様と密結合にスクラッチ 👍 柔軟性が高い 👎 工数増/枯れていない 0 → 1 OR 様々なデータソースに対応しないといけないデータ転送機能と比較したときに既存資産を利用することのレバレッジが効きにくいはず Embulkのマネージドサービスからデータ基盤構築の総合SaaSを目指すに当たって柔軟性を重視

Slide 56

Slide 56 text

© primeNumber Inc. 56 ワークフローのアーキテクチャ（当時）コンテナ起動タスクのリストアップ 1 ワークフローを実行するとフローを管理するためのコンテナが立ち上がる 2 タスクのリストアップ (停止位置から実行の場合は直前のstatusを取得) id status requires 1 succeeded [ ] 2 not_running [ ] 3 not_running [1, 2]

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

© primeNumber Inc. 63 ● DWH、RDBMS、ストレージなどデータにまつわる基本的なコネクタ ● 既に存在するOSSの Embulkプラグインを利用データ転送機能のコネクタ数増加 2019年春頃 2022年秋頃 25 100コネクタ ● 広告、SaaSなど幅広いユースケースに対応 ● 新たにEmbulkプラグインを開発初期のコネクタ傾向拡充されていくコネクタの傾向約100種の超えるコネクタ ※ コネクタ=「データ転送機能の元/先」

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

© primeNumber Inc. 72 新しいインテグレーションテスト（Pros/Cons）ローカル環境では試せない（ステージング環境に設定を作ってるだけなので） Flakyなものがちょこちょこ発生する元データの方に行が追加されていたりなどワークフロー機能に不備があるとテストにならない構造化して書けるようになったことで設定が肥大化。以前よりも複雑性が増した PROS コードを書けなくてもテストを作成可能 QAテスターの方の力を借りて量産各コネクタごとに作成しネストして管理見通しが良くなったワークフローをキックするAPIを用い、CIでステージングへデプロイのたびに自動実行データが正しく転送されていることを検証できるワークフロー機能自体のテストにもなっている？ CONS + + + + + - - - -

Slide 73

Slide 73 text

© primeNumber Inc. 73 その他の取り組みリリース後の見守りリリースしたコネクタを利用したジョブの失敗率が増加していないか redashで確認インテグレーションテスト層での網羅は不可能多重に防御するアップデートチェックツール APIアップデート時に廃止されるフィールドがある（時に想定外のフィールドも） ↓ チェックするツールを作成 Embulkプラグインのカナリアリリース新旧バージョンをイメージに入れ load pathを切り替え顧客単位で徐々に適用

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

© primeNumber Inc. 79 Suspend Mode（ソリューション） ● Redisにsuspendフラグを設ける ● DBのアクセスが発生する箇所で suspend状態なら一定時間sleep ● 実行状況の更新が一時停止するがジョブはエラーにならない ● UIはアクセスできなくなるが一番守りたいジョブを落とさずに済む ○ メンテナンスが早めに終了すれば少しの停止で済む After

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Slide 87

Slide 87 text

Slide 88

Slide 88 text

Slide 89

Slide 89 text

Slide 90

Slide 90 text

Slide 91

Slide 91 text

Slide 92

Slide 92 text

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Slide 98

Slide 98 text

Slide 99

Slide 99 text

Slide 100

Slide 100 text

Slide 101

Slide 101 text

Slide 102

Slide 102 text

Slide 103

Slide 103 text

Slide 104

Slide 104 text

Slide 105

Slide 105 text

Slide 106

Slide 106 text

Slide 107

Slide 107 text

Slide 108

Slide 108 text

Slide 109

Slide 109 text

Slide 110

Slide 110 text

Slide 111

Slide 111 text

Slide 112

Slide 112 text

Slide 113

Slide 113 text

Slide 114

Slide 114 text

Slide 115

Slide 115 text

Slide 116

Slide 116 text

Slide 117

Slide 117 text

© primeNumber Inc. 117 APIの拡充、Terraform Providerの提供ローンチから６年リリース経ち数年以上継続利用いただいているお客様も設定の管理が課題になってくる TROCCO® Terraform Provider 以前から要望の多い設定のコード管理に答える Public APIの拡充エンジニアを一定のターゲットとするSaaSとしてはまだまだ不足がある課題 API 開発したAPIを利用