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

@アーキテクチャConference 2024
https://architecture-con.findy-tools.io/
2024/11/26

Transcript

1. primeNumber Inc. © PaaSとSaaSの境目で信頼性と開発速度を両立する 〜TROCCO®のこれまでとこれから〜 @アーキテクチャConference 2024 2024/11/26 株式会社primeNumber プロダクト開発本部 CTO室 室長 中根 直孝
2. © primeNumber Inc. 2 © primeNumber Inc. 2 会社概要 会社名 代表 創業 メンバー数 累計調達額 オフィス 株式会社primeNumber 代表取締役CEO 田邊 雄樹 2015年11月 約100名 約34億円 東京都品川区上大崎3丁目1番1号 JR東急目黒ビル5F
3. © primeNumber Inc. 3 © primeNumber Inc. 3 あらゆるデータを、 ビジネスの力に変える。 我々は、「あらゆるデータを、ビジネスの力に変える」 データテクノロジーカンパニーです。 データが爆発的に増えていく時代に、 誰もがすばやく、簡単にデータを使える環境を構築し、 データ活用までのプロセスを最適化。 高度なテクノロジーと独自のアイデアで、 世界中のビジネスを支援します。 VISION
4. © primeNumber Inc. 4 データ基盤構築・運用の支援SaaS TROCCO® © primeNumber Inc. 4 詳細は 後ほど
5. © primeNumber Inc. 5 © primeNumber Inc. 5 データカタログSaaS COMETA® 2024年 TROCCO® から派生
6. © primeNumber Inc. 6 TROCCO®とCOMETA® TROCCO®：「統合」を軸にデータ基盤の構築や運用を支援 COMETA®：データの発見・理解・活用を促進するデータカタログ データをビジネスに活用するまでのステップ
7. © primeNumber Inc. 7 たくさんのお客様にご利用いただいております 業界・業種問わず、さまざまな企業や団体にご利用いただいています。
8. © primeNumber Inc. 8 中根 直孝 (@gtnao) 株式会社primeNumber Staff Software Engineer プロダクト開発本部 CTO室 室長 • 2017 エンジニアキャリアスタート • 2018/11 primeNumber入社 ◦ TROCCO®のリリースと同月 • TROCCO®の開発に黎明期から従事 ◦ 2018〜 ゼロイチで色々 ◦ 2023〜 組織横断で色々
9. © primeNumber Inc. 9 AGENDA 01. 本日のお話 02. TROCCO®とは 03. これまで 04. これから
10. © primeNumber Inc. 10 本日のお話 2019 2018 2020 2022 2021 2023 2024 前半 3/4：これまで (当時のアーキテクチャ/課題/意思決定) 後半 1/4：現在進行系、これから (組織/事業/プロダクトが拡大する中での課題) 2018/11 初期リリース 2018/06 開発スタート 海外リージョン展開 COMETA®の リリース 様々な機能拡充
11. © primeNumber Inc. 11 どのような方に向けて？ ※ 色々なトピックを話していくので、それ以外でも何かしらの参考になれば！ 1 2 （主にスタートアップの）様々なフェーズの開発者の方 ジョブ基盤、PaaS的性質を備えたサービスの裏側に興味がある方
12. © primeNumber Inc. 12 AGENDA 01. 本日のお話 02. TROCCO®とは 03. これまで 04. これから
13. © primeNumber Inc. 13 TROCCOの守備範囲 主にデータ基盤構築/運用の「統合」の部分を担う
14. © primeNumber Inc. 14 統合だけ？ 嬉しいの？
15. © primeNumber Inc. 15 TROCCOの価値 1 多様なデータソースの対応 DWH、RDB、ファイル、広告レポート、SaaS… 2 日々の運用 エラー通知、自動リトライ、API Update追従 3 複雑なパイプライン構築 データ基盤を構築/運用する際の辛みを丸っと引き受ける
16. © primeNumber Inc. 16 TROCCOの機能スタック 運用支援 機能 データ転送機能 (use Embulk) Transform系機能 (スクラッチ & use dbt) ワークフロー機能 (スクラッチ) 日夜動き続ける①ジョブ系の機能と、その②管理を支える機能に大別 2 1
17. © primeNumber Inc. 17 メインのデータ転送機能
18. © primeNumber Inc. 18 データ転送機能の概要 UIで転送の設定を作成 TROCCO®のUIフォーム
19. © primeNumber Inc. 19 データ転送機能の概要 転送実行時に、入力情報を元にEmbulkのYAMLを作成 TROCCO®のUIフォーム Embulkのconfig.yml
20. © primeNumber Inc. 20 データ転送機能の概要 データ転送ジョブのフロー 実行単位でコンテナが立ち上がり、終了時に破棄 TROCCO®のジョブ画面
21. © primeNumber Inc. 21 各種ジョブを Orchestrateするワークフロー機能
22. © primeNumber Inc. 22 ワークフロー機能の概要 GUIで各種ジョブの依存関係を定義し、実行順序を制御 TROCCO®のワークフロー機能画面 データ転送設定
23. © primeNumber Inc. 23 ワークフロー機能の概要 変数を切り替えながらのループや、フローのネストなど 複雑なフローも組める ループ実行機能の例
24. © primeNumber Inc. 24 PaaSとSaaSの境目で
25. © primeNumber Inc. 25 ジョブプラットフォームサービスとしての特性 200,000超 / day 1,000 1日あたりのジョブ実行数の年平均 2024年現在 1日あたり20万件以上のジョブが実行される プラットフォームへと成長
26. © primeNumber Inc. 26 ジョブプラットフォームサービスとしての特性 • XX:00にスパイク(スケジュール設定されやすいため) • 深夜1時にピーク • 24/365でなにかしらのジョブが動いている 00:00(JST) 08:00 16:00 1日のジョブ実行傾向
27. © primeNumber Inc. 27 求められる信頼性 お客様がサービスに最も求めていることは 設定した時間にジョブが動き 想定した通りのデータが配置されていること 求められるジョブ基盤の強固な信頼性
28. © primeNumber Inc. 28 SaaSに期待される体験 設定の接続確認 変更時の差分確認 実行プレビュー 一方で 設定をいかにラクに行えるかも期待される価値の一つ
29. © primeNumber Inc. 29 PaaSとSaaSの境目で SaaS PaaS PaaSに求められる信頼性を第一に担保しつつ SaaSとしての体験を高める開発をいかに行っていくか TROCCO®の開発に求められるチャレンジ
30. © primeNumber Inc. 30 AGENDA 01. 本日のお話 02. TROCCO®とは 03. これまで 04. これから
31. © primeNumber Inc. 31 AGENDA 1. 本日のお話 2. TROCCO®とは 3. これまで 3.1. 黎明期のアーキテクチャ刷新 3.2. データ基盤構築/運用のサービスへ 3.3. テスト戦略の試行錯誤 3.4. SREによる信頼性向上の取り組み 4. これから
32. © primeNumber Inc. 32 まずは、誕生時まで遡る
33. © primeNumber Inc. 33 黎明期 • プロダクトの需要があるかを探っているフェーズ • 利用ユーザー ◦ 自社利用、トライアルユーザー 2019 2018 2020 2022 2021 2023 2024 2018/11 初期リリース 2018/06 開発スタート 2019年春頃から 徐々に有償契約いただけるお客様が
34. © primeNumber Inc. 34 体制や技術背景 体制 エンジニア 1 ~ 3人名で開発 社内の技術スタック AWS RubyOnRails での開発が多い 当時の技術動向（主観） Dockerを使った開発が市民権を得てくる Kubernetesはまだエッジな技術 AWS EKSはまだ東京リージョンに来ていない （※開発スタート直後）
35. © primeNumber Inc. 35 当時のアーキテクチャ SQSをポーリングするECS TaskがそのままEmbulkを実行
36. © primeNumber Inc. 36 アーキテクチャの課題 スケールイン デプロイ ECS on EC2 スケールアウト 環境差分 実行中のジョブがノード上に存在するとスケールインできない Lambdaを使ったりと原始的な手法で試行錯誤 実行に長時間かかっているジョブがあると、そのECSタスクを ローリングアップデートできずデプロイが一向に完了しない 2018年当時、ECS on Fargateに10GB以上のボリュームを 割り当てることができず、データ転送サービスとしては致命的に ジョブ基盤側はECS on EC2を選択せざるを得ない ECS Task数 = 同時実行可能数 SQSへの流量を見てスケールアウトするなど試行錯誤 起動に時間がかかる ローカル環境では素のDocker、本番環境ではECSタスク アーキテクチャの差分がある状態での開発 トピック 具体的な課題
37. © primeNumber Inc. 37 徐々に有償契約いただけるお客様が！
38. © primeNumber Inc. 38 1日あたりのジョブ数の増加 40 300 約1,000 /day • 有償契約いただけるお客様が増えるに従って、1日あたりのジョブ数が急増 • 既存アーキテクチャのままでは、今後立ち行かなくなるだろうという危機感 1日あたりのジョブ実行数の月平均
39. © primeNumber Inc. 39 EKS、ap-northeast-1に上陸！ 乗るしかないこの🌊🏄
40. © primeNumber Inc. 40 Kubernetes採用後のアーキテクチャ ジョブ基盤部分をEKS（Kubernetes）を使ったアーキテクチャに刷新
41. © primeNumber Inc. 41 Dispatcher層 • Dispatcher層を新たに設ける • SQSをポーリングし、k8sのJobを登録するまでの責務 • k8sのDeploymentで常時稼働
42. © primeNumber Inc. 42 ジョブ管理 • ジョブの立ち上げはk8sにおまかせ • 転送単位でコンテナが起動し、終わったら破棄
43. © primeNumber Inc. 43 スケールアウト/イン • スケールの課題は、Cluster Autoscalerで解決 ◦ スケールアウトだけでなく、スケールインもよしなに
44. © primeNumber Inc. 44 アーキテクチャの課題解決 スケールイン デプロイ ECS on EC2 スケールアウト 環境差分 Cluster Autoscalerにより、Nodeが空いてるとスケールイン 実行中のJobがある場合にも完了を待ってくれる イメージタグを差し替えるだけでデプロイ可能に 実行中のJobがある場合にも影響を受けない EKSへの乗り換えで脱却 Cluster Autoscalerにより、 Jobを立ち上げるためのNodeリソースがないとスケールアウト ローカル環境でも、 本番同様のKubernetesアーキテクチャで開発可能に トピック Kubernetesアーキテクチャ変更後
45. © primeNumber Inc. 45 リソースの細かな制御 Kubernetes採用における更なる恩恵も k8s JobのYAMLの一部 データ転送ジョブごとに リソースを細かく調整することが可能に リソース増強オプション TROCCO®の一つのオプションとしても提供
46. © primeNumber Inc. 46 見送ったこと UI部分はKubernetes化せず、今まで通りECS(Fargate)で運用 1 画面のトラフィックが少ないサービス 安定運用できているほど画面を触らなくなることも 2 ECSの方が運用は簡単なのは確か 3 積極的な動機がない Why?
47. © primeNumber Inc. 47 200,000超 / day 1,000 1日あたりのジョブ実行数の年平均 変わっていないこと、変わったこと • 大枠のアーキテクチャは2024年現在も変わっていない ◦ 1日のジョブ数は200倍超に ◦ Kubernetesは偉大 • UI部分のECS(Fargate)も現役 ◦ Kubernetesは適材適所
48. © primeNumber Inc. 48 AGENDA 1. 本日のお話 2. TROCCO®とは 3. これまで 3.1. 黎明期のアーキテクチャ刷新 3.2. データ基盤構築/運用のサービスへ 3.3. テスト戦略の試行錯誤 3.4. SREによる信頼性向上の取り組み 4. これから
49. © primeNumber Inc. 49 基盤の安定化 → 機能拡充フェーズへ
50. © primeNumber Inc. 50 大幅な機能拡充期 基盤の安定化により、機能拡充に集中できるように 2019 2018 2020 2022 2021 2023 2024 ワークフロー機能 データカタログ機能 dbt連携機能 チーム機能 データマート機能 フリープラン提供
51. © primeNumber Inc. 51 データ転送以外の ケイパビリティに着手
52. © primeNumber Inc. 52 データ転送機能以外のケイパビリティ • データ転送後に、DWH上で変形するELT(extract load tranfrom)が主流に • それらのジョブをOrchestrateするための機能の必要性 運用支援 機能 データ転送機能 (use Embulk) Transform系機能 (スクラッチ & use dbt) ワークフロー機能 (スクラッチ) 本日はワークフロー機能についてお話しします
53. © primeNumber Inc. 53 ワークフロー機能の技術選定 データ転送機能におけるEmbulkのように 既存のOSSを活用するか否か OSSを活用 👍 初期開発/拡充の工数削減 👎 OSSの仕様と密結合に スクラッチ 👍 柔軟性が高い 👎 工数増/枯れていない 0 → 1 OR
54. © primeNumber Inc. 54 OSSの仕様と密結合に（Embulkの例） TROCCO®のスキーマ設定画面 お客様が Embulkの世界でのデータ型を 意識する必要がある Embulkのデータ型 • long • double • string • boolean • timestamp • json
55. © primeNumber Inc. 55 ワークフロー機能の技術選定 OSSを活用 👍 初期開発/拡充の工数削減 👎 OSSの仕様と密結合に スクラッチ 👍 柔軟性が高い 👎 工数増/枯れていない 0 → 1 OR 様々なデータソースに対応しないといけないデータ転送機能と比較したときに 既存資産を利用することのレバレッジが効きにくいはず Embulkのマネージドサービスから データ基盤構築の総合SaaSを目指すに当たって柔軟性を重視
56. © primeNumber Inc. 56 ワークフローのアーキテクチャ（当時） コンテナ起動 タスクの リストアップ 1 ワークフローを実行すると フローを管理するためのコンテナが立ち上がる 2 タスクのリストアップ (停止位置から実行の場合は直前のstatusを取得) id status requires 1 succeeded [ ] 2 not_running [ ] 3 not_running [1, 2]
57. © primeNumber Inc. 57 実行可能な タスクを抽出 3 実行可能なタスク = 依存するタスクが全て成功しているタスク を抽出 ループ開始
58. © primeNumber Inc. 58 タスクを実行 タスクの同期 4 抽出した実行可能タスクを実行 TROCCO®内の別機能のAPIを叩くイメージ 5 タスクの同期 実際のジョブのステータスを取得 (Reconciliation) id status requires 1 succeeded [ ] 2 error [ ] 3 not_running [1, 2] データ転送ジョブ
59. © primeNumber Inc. 59 終了判定 6 到達可能なタスクが存在しない場合に ループを抜ける ループ終了 一定時間sleep ※ 当時のアーキテクチャ 現在は、ループのidle時間を効率的に使う目的で、一つのPodで複数のワークフローを管理しています
60. © primeNumber Inc. 60 ワークフローのアーキテクチャ 実際にはもっと複雑 • キャンセル • 停止位置からの再実行 • 同時実行制限 • 停止条件 ◦ エラーでも先に進む設定 • ループ機能 • ワークフローからワークフローを呼べる ◦ 上記のトピックについて、多重に入れ子になった際の考慮が必要
61. © primeNumber Inc. 61 AGENDA 1. 本日のお話 2. TROCCO®とは 3. これまで 3.1. 黎明期のアーキテクチャ刷新 3.2. データ基盤構築/運用のサービスへ 3.3. テスト戦略の試行錯誤 3.4. SREによる信頼性向上の取り組み 4. これから
62. © primeNumber Inc. 62 求められる変更失敗率の低減
63. © primeNumber Inc. 63 • DWH、RDBMS、ストレージなど データにまつわる基本的なコネクタ • 既に存在するOSSの Embulkプラグインを利用 データ転送機能のコネクタ数増加 2019年春頃 2022年秋頃 25 100コネクタ • 広告、SaaSなど幅広い ユースケースに対応 • 新たにEmbulkプラグインを開発 初期のコネクタ傾向 拡充されていくコネクタの傾向 約100種の超えるコネクタ ※ コネクタ=「データ転送機能の元/先」
64. © primeNumber Inc. 64 サービス/開発背景 基盤の安定化に伴い 常に、多数/多様なジョブが動いている状況 変更頻度が高く、利用顧客数も多いコネクタの存在 例：Google広告 • 数ヶ月でEOL、1年で廃止になるAPIのバージョン → 変更頻度高 • 広告データ統合のユースケース → 利用顧客数増 1デプロイ/day のルーティン デプロイ時のアプリケーションレイヤでの信頼性が求められる
65. © primeNumber Inc. 65 ジョブプラットフォームサービスとしての宿命 昨今、高頻度デプロイやソフトウェアの潜在的な複雑性から 「リリースしてから数時間もテスト期間」という考え もあるが… お客様のデータパイプラインに組み込まれるTROCCO®は その考え方が通用しないケースも多い
66. © primeNumber Inc. 66 TROCCO®のテスト戦略的特徴 外部サービスとの通信が多いサービス特性 通常、ユニットテストを書く場合は、モックを使うが… インテグレーションテスト層を一般的より厚くする必要性 外部サービスとの連携こそが、 TROCCO®のコアドメイン（価値の源泉） モックを使って済ますだけでは不十分
67. © primeNumber Inc. 67 初期のインテグレーションテスト 管理画面 • 「[QA] 」と名のつく設定を 一括で実行でできる画面 • ステージング環境にて 確認したい設定を各自用意しておく • 本番リリース前などに一括実行 • 原始的で管理が大変 • ジョブの終了ステータスが 「成功」かどうかの判定しかできない ◦ 成功したが転送されたデータが 想定通りではない、といった ケースは防げない 課題
68. © primeNumber Inc. 68 TROCCO®を使って TROCCO®をテストできるのでは🤔
69. © primeNumber Inc. 69 データチェック機能 • ワークフローに組み込み • 1行1列の数値を返すクエリと その条件を設定 • 例 • 重複件数をCOUNTし 1以上の場合にエラーとする
70. © primeNumber Inc. 70 新しいインテグレーションテスト EXPECTED_TABLE ACTUAL_TABLE 事前に用意 一致している ことを確認する クエリ 転送レイヤー 確認レイヤー テスト用のBigQueryテーブルへ転送
71. © primeNumber Inc. 71 新しいインテグレーションテスト 約100種のコネクタで同様のワークフローを作成
72. © primeNumber Inc. 72 新しいインテグレーションテスト（Pros/Cons） ローカル環境では試せない（ステージング 環境に設定を作ってるだけなので） Flakyなものがちょこちょこ発生する 元データの方に行が追加されていたりなど ワークフロー機能に不備があるとテストに ならない 構造化して書けるようになったことで設定 が肥大化。以前よりも複雑性が増した PROS コードを書けなくてもテストを作成可能 QAテスターの方の力を借りて量産 各コネクタごとに作成しネストして管理 見通しが良くなった ワークフローをキックするAPIを用い、CIで ステージングへデプロイのたびに自動実行 データが正しく転送されていることを検証 できる ワークフロー機能自体のテストにもなって いる？ CONS + + + + + - - - -
73. © primeNumber Inc. 73 その他の取り組み リリース後の見守り リリースしたコネクタを利用した ジョブの失敗率が増加していないか redashで確認 インテグレーションテスト層での網羅は不可能 多重に防御する アップデート チェックツール APIアップデート時に 廃止されるフィールドがある （時に想定外のフィールドも） ↓ チェックするツールを作成 Embulkプラグインの カナリアリリース 新旧バージョンをイメージに入れ load pathを切り替え 顧客単位で徐々に適用
74. © primeNumber Inc. 74 AGENDA 1. 本日のお話 2. TROCCO®とは 3. これまで 3.1. 黎明期のアーキテクチャ刷新 3.2. データ基盤構築/運用のサービスへ 3.3. テスト戦略の試行錯誤 3.4. SREによる信頼性向上の取り組み 4. これから
75. © primeNumber Inc. 75 一人目SREの入社！
76. © primeNumber Inc. 76 一人目SREの入社 • 一人目SRE社員を中心にSREチームが誕生 • これまで目を瞑ってきたさまざまな箇所を ひたすらテコ入れしてくれる • 本日はアーキテクチャに関連する改善を いくつかピックアップ ◦ セキュリティ/しくみづくりなどでも活躍してくれています😌🙏
77. © primeNumber Inc. 77 Suspend Mode（課題） どうしても避けられない DBに繋がらない瞬間が発生するメンテナンス もちろん、事前にお客様にアナウンス済みだが… メンテナンス開始時に実行中のジョブはエラーになってしまう お客様側で再実行が必要に
78. © primeNumber Inc. 78 Suspend Mode（ソリューション） • Embulkの実行中に 適宜DBにステータスなどを 書き込み • DBに繋がらず ジョブ自体がエラーに Before
79. © primeNumber Inc. 79 Suspend Mode（ソリューション） • Redisにsuspendフラグを設ける • DBのアクセスが発生する箇所で suspend状態なら一定時間sleep • 実行状況の更新が一時停止するが ジョブはエラーにならない • UIはアクセスできなくなるが 一番守りたいジョブを落とさず に済む ◦ メンテナンスが早めに終了 すれば少しの停止で済む After
80. © primeNumber Inc. 80 事前スケールアウト（課題） XX:00にジョブが一斉に登録される TROCCO®のスパイク特性 Cluster Autoscalerの限界 Nodeが立ち上がるまでに一定時間がかかる お客様が設定した時刻から ジョブの起動までに数分の遅れが発生してしまうことも
81. © primeNumber Inc. 81 事前スケールアウト（ソリューション） スケールアウト前 • Nodeが十分に 立ち上がっていない状態 Node Node 未起動の Node
82. © primeNumber Inc. 82 事前スケールアウト（ソリューション） リソース確保用のPod(Deployment) • Nodeまるまる一台分を占有する リソースを要求 • デフォルトのreplica数は0 • PriorityClassで 他のPodを追い出さず 自身は追い出されやすい preemption設定にしておく
83. © primeNumber Inc. 83 事前スケールアウト（ソリューション） スパイクの数分前 • リソース確保Pod(Deployment)の replica数を事前に立ち上げたい ノード数に • crontabで実行 Control Plane XX:57 リソース確保 Pod kubectl scale crontab
84. © primeNumber Inc. 84 事前スケールアウト（ソリューション） スケールアウト • リソース確保Podにより ノードが起動 • 既にJobが動いている ノードでは立ち上がらない ◦ Jobを追い出さない Node Node 事前に起動 リソース確保 Pod リソース確保 Pod XX:57~XX:00
85. © primeNumber Inc. 85 事前スケールアウト（ソリューション） スパイク • 確保されたノードで Jobが立ち上がる • リソース確保Podが 追い出される Node Node Node リソース確保 Pod XX:00
86. © primeNumber Inc. 86 事前スケールアウト（ソリューション） スパイク後 • リソース確保Pod(Deployment)の replica数を0にする Control Plane XX:00 リソース確保 Pod kubectl scale crontab
87. © primeNumber Inc. 87 事前スケールアウト（ソリューション） スケールイン • 空いているNodeがスケールイン Node Node 空いているNode
88. © primeNumber Inc. 88 自動メンテ実行（課題） 意図せず終了してしまうPodの存在 日に数十万ジョブ動いていると、どうしても発生することがある TROCCO側で管理しているステータスは「実行中」のまま お客様からはまだ動いているように見える。エラーなら通知が来て再実行が可能だが… オンコール担当が管理画面からステータスを更新 オペレーション負荷、対応の遅れ
89. © primeNumber Inc. 89 自動メンテ実行（ソリューション） job_id status 1 executing 2 executing 3 executing job_id 1 3
90. © primeNumber Inc. 90 自動メンテ実行（ソリューション） job_id status 1 executing 2 error 3 executing job_id 1 3 TROCCO DB上のステータスとk8s側のDiffを取って自動でエラーに倒す
91. © primeNumber Inc. 91 信頼性を担保しつつ 日々の開発が行えてきた💪 これにて一件落着？😌🍵
92. © primeNumber Inc. 92 2024年期…
93. © primeNumber Inc. 93 組織の拡大！ 正社員100人規模 エンジニアチームも5、6チームに分割
94. © primeNumber Inc. 94 事業の拡大！ 韓国、インド市場への進出 󰏮󰏝 1日あたりのジョブ実行数は20万件を超える
95. © primeNumber Inc. 95 プロダクトの拡大！ TROCCO®の「データカタログ機能」が に
96. © primeNumber Inc. 96 AGENDA 01. 本日のお話 02. TROCCO®とは 03. これまで 04. これから
97. © primeNumber Inc. 97 AGENDA 1. 本日のお話 2. TROCCO®とは 3. これまで 4. これから 4.1. 海外展開 4.2. コネクタ開発 4.3. モジュール分割
98. © primeNumber Inc. 98 海外展開 • 韓国とインドへの事業展開 • 自国内からデータを出したくない というニーズ
99. © primeNumber Inc. 99 海外展開 東京リージョンと同等のアーキテクチャを ソウル、ムンバイリージョンに構築
100. © primeNumber Inc. 100 Terraformのリファクタリング • 合わせてTerraformのリファクタリング ◦ ２リージョン目の構築工数の軽減に • 詳細はこちらの記事を ◦ https://zenn.dev/primenumber/articles/096db41ddfe039
101. © primeNumber Inc. 101 AGENDA 1. 本日のお話 2. TROCCO®とは 3. これまで 4. これから 4.1. 海外展開 4.2. コネクタ開発 4.3. モジュール分割
102. © primeNumber Inc. 102 コネクタの開発生産性 海外展開による 海外特有のコネクタの需要 国内でもまだまだサポート できていないコネクタが JavaでEmbulkプラグインを 実装できるエンジニアの不足 一部のエンジニアへの レビュー負荷 コネクタ開発の生産性向上が更に求められる オフショア開発のスタート 容易なオンボーディング が求められる
103. © primeNumber Inc. 103 初期のコネクタ開発 コネクタ単位でEmbulkプラグインを都度作る Embulkに読み込ませるYAML例
104. © primeNumber Inc. 104 少し前までのコネクタ開発 データを取得する部分はRubyで実装 ローカルファイルをインプットとしてEmbulkを実行という二段階方式 Embulkに読み込ませるYAML例
105. © primeNumber Inc. 105 直近のコネクタ開発（現在進行形） 汎用的なHTTPリクエストによるデータ取得のためのプラグイン embulk_input_httpを利用する Embulkに読み込ませるYAML例 更に…
106. © primeNumber Inc. 106 直近のコネクタ開発（現在進行形） Embulkに読み込ませるYAML例 設定フォーム コネクタ開発時には APIの仕様に従って YAMLを書く （宣言的） YAMLを元に 動的にフォームや Embulkのconfig.ymlを 作成するメタプロ機構
107. © primeNumber Inc. 107 APIの仕様の調査を担当 YAMLへの落とし込みを担当 変換の基盤を実装を担当 分業してコネクタを開発できる体制を 直近のコネクタ開発（現在進行形）
108. © primeNumber Inc. 108 プラグインも引き続き開発 ・ 従来方式のプラグイン開発も、必要に応じて継続 • 新しいコネクタ開発方式の欠点 ◦ 大容量のデータ転送には不向き ◦ HTTPのAPIが前提 • 直近では、Databricksのin/outに対応
109. © primeNumber Inc. 109 AGENDA 1. 本日のお話 2. TROCCO®とは 3. これまで 4. これから 4.1. 海外展開 4.2. コネクタ開発 4.3. モジュール分割
110. © primeNumber Inc. 110 チームの分割とモノリス 2019 2018 2020 2022 2021 2023 2024 チームやプロダクトの分割の一方で、Railsのモノリスのまま
111. © primeNumber Inc. 111 モジュール分割 • 肥大モノリスあるある話 ◦ 変更時の別機能への意図しない影響 ◦ コードの認知負荷増 • 確実な動機がある箇所から分割を考える ◦ 事業単位 → COMETA®から考える 2019 2018 2020 2022 2021 2023 2024
112. © primeNumber Inc. 112 モジュラーモノリス（packs-rails） packs-rails • app/models,views,controllersなどを packs/<module_name>/app/ 以下に移動することが可能 • 仮想的なnamespace ◦ 参照元を書き換えずに済む • 可逆性が高い ◦ 気に入らなかったら戻すことが容易
113. © primeNumber Inc. 113 実際にやってみた（packs-rails） 変更ファイル数は多いが ほとんどが ディレクトリ移動= rename
114. © primeNumber Inc. 114 モジュラーモノリス（packwerk） packwerk • Shopify製のモジュラーモノリス のためのGem • モジュール間の意図しない依存 などを検知してくれる • Lint（静的解析）ツールの 位置付け • TODOとしてやり過ごすことが 可能 package_todo.yml
115. © primeNumber Inc. 115 漸進的改善 漸進的な改善が行いやすい packs-rails packwerk 仮モジュール間の 依存関係を把握 ファイルを移動して 試行錯誤
116. © primeNumber Inc. 116 可能な限り選択を遅らせる 「Clean Architecture 達人に学ぶソフトウェアの構造と設計」 私の好みは、いざというときのために、サービス を作れそうなところまで切り離すというものであ る。ただし、コンポーネントはできるだけ長い期 間、同じアドレス空間に存在させておく。これ は、サービスの選択肢を残しているのだ。 p.164
117. © primeNumber Inc. 117 APIの拡充、Terraform Providerの提供 ローンチから６年リリース経ち 数年以上継続利用いただいているお客様も 設定の管理が課題になってくる TROCCO® Terraform Provider 以前から要望の多い 設定のコード管理に答える Public APIの拡充 エンジニアを一定の ターゲットとするSaaSとしては まだまだ不足がある課題 API 開発したAPIを利用
118. © primeNumber Inc. 118 To Be Continued…
119. © primeNumber Inc. 119 最後にいくつか宣伝をさせてください
120. © primeNumber Inc. 120 会場 開催日時 東京ミッドタウン・ホール 2024年12月10日（火） primeNumber 主催 01（zeroONE）2024
121. © primeNumber Inc. 121 We Are Hiring ! primeNumberではプロダクトづくりに携わるさまざまな職種を絶賛募集しております！ まずは、お気軽にカジュアル面談からでも！ 募集職種 ・ソフトウェアエンジニア ・SRE ・エンジニアリングマネージャー ・プロダクトマネージャー ・テクニカルライター ・デザイナー 採用サイト
122. © primeNumber Inc. 122 ブース出展しております ! お気軽にお立ち寄りください！ ノベルティも配布しております！
123. Thank you!