信頼性を担保しながらユーザー体験を向上するTROCCO開発の裏側（アーキテクチャConference 2024講演レポート）
11月26日に開催された、システムの基盤となるアーキテクチャをテーマにした「アーキテクチャConference 2024」。プロダクト開発本部 CTO室長の中根さんが登壇、「PaaSとSaaSの境目で信頼性と開発速度を両立する〜TROCCO®︎のこれまでとこれから〜」と題し、TROCCOの歴史を振り返りながらアーキテクチャについて解説しました。
なお、中根さんの登壇資料はSpeaker Deckに公開されています。講演の詳細を知りたい方はこちらの資料をお読みください
データ基盤構築・運用の辛みを“まるっと引き受ける”のがTROCCOの役割
中根さんははじめにTROCCOの概要を紹介。TROCCOはデータ基盤構築や運用の「統合」部分を担うサービスだとし、「統合だけで嬉しいの？ と思われるかもしれないが、実際にはさまざまなデータソースへの対応や、実装した後の運用や複雑なパイプライン構築といった大変さがある」と説明。「そうしたデータ基盤構築・運用の辛みをまるっと引き受けるのがTROCCO」とのメリットを示しました。
2018年11月にリリースされたTROCCOは、2024年現在1日あたり20万件以上のジョブが実行されるプラットフォームに成長。現在も24時間365日何らかのジョブが動いています。中根さんは「お客様が求めているのは設定した時間にジョブが動いて想定通りのデータが配置されていることであり、そのためにはジョブ基盤の強固な安定性が求められる」と安定性の重要さを語りました。
一方でお客様にとっていかに使いやすくするかも期待される価値であり、そのためにさまざまな設定確認のための機能を搭載。「TROCCOはPaaS（Platform as a Service）として求められる信頼性を担保しながら、SaaS（Software as a Service）としての体験を高める開発をいかに行うかというPaaSとSaaSの境目が開発にとってのチャレンジ」としました。
アーキテクチャをKubernetesに変更、1日20万件のジョブ数も耐えられる環境を構築
続いて中根さんはTROCCOの歴史を振り返りながらTROCCOのアーキテクチャを説明。開発直後の黎明期は自社ユーザーやお付き合いのあるお客さまのトライアルが主で、エンジニアも数名程度の体制だったのが、徐々に有償契約が増えてきて1日当たりのジョブが1,000件近くまで増え始めました。
「このくらいの規模ならぎりぎりさばけていたけどこのままでは立ち行かなくなる」と思っていた時に現れたのが、EKS（Elastic Kubernetes Service）の東京リージョンでの提供で、TROCOはこのタイミングでジョブの部分をEKSを使ったアーキテクチャに刷新。1日のジョブ数が200倍超となった現在も大枠のアーキテクチャは変わっていないそうです。
一方でUI部分はEKSではなくECS（Fargate）で運用。「TROCCOは他のB2Bサービスと比べてトラフィックが少なく、安定運用できているとTROCCOの画面を見なくなるという逆説的な背景がある」とし、運用が容易なECSが今も現役で稼働していると語りました。
ワークフローは柔軟性を重視して新規でスクラッチ開発
これら基盤の安定化が進んだことで、開発もデータ転送以外の機能に着手できるようになった、と中根さんは説明。さまざまな機能拡充の中でワークフロー機能を中心に紹介しました。
ワークフロー機能の技術選定について中根さんは「EmbulkのようなOSSを活用するか、スクラッチで新規開発するかが論点になる」と前置きし、「Embulkを使うとお客様がEmbulkのデータ型を意識する必要がある」という課題を指摘。また、「今後さまざまなデータソースに対応するデータ転送機能を開発する際に、OSSの既存資産を利用するレバレッジが効きにくいはずという考えもあった」と補足し、データ基盤構築の総合SaaSを目指すための柔軟性を重視して新規でのスクラッチ開発を選択したと語りました。
現在、データ転送機能の元/先となるコネクタは約100種で、常に多種多様なジョブが動いてます。中根さんは「Google広告のように利用顧客数が多く変更頻度も高いコネクタにも対応するなど、デプロイ時のアプリケーションレイヤでの信頼性が求められる」と説明。「昨今、リリースしてから数時間はテスト時間という考え方もあるが、お客様のデータパイプラインに組み込まれるTROCCOにはその考え方が通用しないケースも多い」と、高い信頼性を維持する重要さを語りました。
また、外部サービスとの連携が価値の源泉であるTROCCOにとって、開発中のテストはモックを使うだけでは不十分であり、インテグレーションテスト層を一般的より厚くする必要がある、と説明。初期の環境ではQA設定を一括で実行できるステージング環境を本番リリース前などに一括実行していたものの、原始的で管理が大変なことに加え、ジョブの成功は判定できるがデータが正しいかどうかもわからないという課題があったと振り返りました。
そこで考えたのが「TROCCOでTROCCOをテストする」という仕組みで、転送のワークフローにデータチェック機能を組み込み、期待通りに転送されているかどうかを確かめられます。このやり方は設定が以前より複雑になり、ローカル環境で試せないなどの課題はあるものの、データの正確性検証がコードをかけなくてもテストできるようになりました。
SREチームの誕生でプロダクトも日々改善
中根さんはSRE（Site Reliability Engineer）への取り組みにも言及。2022年に入社した1人目のSREを中心にSREチームが誕生し、「これまで目を瞑ってきたさまざまな箇所をテコ入れしてくれている」と感謝を示しながら、SREの取り組みのうちアーキテクチャに関する取り組みを紹介しました。
1つ目はサスペンドモード。メンテナンス期間などでDBにつながらない間、お客様にアナウンスはするものの該当期間中のジョブはエラーになってしまうという課題に対し、データ転送ジョブの中にサスペンドのフラグを入れ、データベースに書き込みが発生する前段で一時停止することで、DBの書き込み自体は遅れるもののジョブはエラーにならない環境を作りました。
また、TROCCOではジョブの設定時刻を毎時0分に設定しているお客様が多いために毎時0分にジョブが集中、Nodeが立ち上がるまでに一定時間がかかってしまい、結果としてお客様が設定した時刻から数分の遅れが発生してしまうケースがありました。これに対しては、リソース確保用にNodeまるまる1台分を占有するリソース確保用のPodを用意しておき、確保しておいたNodeでジョブが立ち上がるとリソース確保Podが追い出される環境を構築することで、事前にスケールアウトできるようになりました。
海外進出などサービスも拡大、開発体制の分業化やモジュール分割にも着手
これら不断の努力によって信頼性を担保しながら開発を続けてきたTROCCOは、2024年に入って正社員が100人規模になりエンジニアチームも5、6チーム体制になるなど拡大。また、韓国やインドといった海外進出、TROCCOの1機能だったデータカタログがCOMETAというプロダクトして拡大するなど、大きな転機を迎えました。
海外展開については「韓国とインドどちらも自国からデータを出したくないというニーズがある」と説明。そのため東京リージョンと同等のアーキテクチャを韓国とインドそれぞれに構築、合わせてTerraformのリファクタリングを行うことで、2リージョン目からの構築工数軽減を図りました。
Terraformのリファクタリングについてはこちらの記事をご覧ください。
コネクタも海外展開したことで「日本ではあまり見ないけど海外では使われているサービスへのコネクタ需要が上がっている」とし、開発体制も一新。これまでEmbulkプラグインを都度作っていた環境から、データ取得部分をRubyで実装し、ローカルファイルをインプットしてEmbulkを実行する二段階方式としたことで、Rubyが書ければプラグインが作れるようになりました。
さらに直近では汎用的なHTTPリクエストによるデータ取得のプラグイン「embulk_input_http」を使った新しいコネクタの開発手法や、コネクタ開発時にAPI仕様に従ったYAMLを書くとフォームやEmbulkのconfig.ymlを生成してくれる環境に着手していると紹介。こうした環境により、API調査や調査結果のYAMLへの落とし込み、変換基盤の実装を分業でき、開発生産性が上げられるとした一方、「この開発体制は大容量のデータ転送に不向きなため、従来方式のプラグイン開発も必要に応じて継続していく」と補足しました。
チームやプロダクトが大きくることで分割していく一方、コードベースはRailsのモノリスのままだったため、中根さんは「大きいモノリスのままだと変更時に別機能へ意図しない影響を与えることもあるし、コードの認知負荷も高まる」との課題を指摘。モジュール分割にも着手しました。
モジュラーの分割はモジュラーモノリスの方式で進めており、その1つが「packs-rails」というgemで、これを使うとRailsのapp以下のファイルを各モジュールごとのディレクトリに分けて移動できます。中根さんによれば「仮想的なネームスペースみたいなものなので、参照元を書き換えずに済み、気に入らなかったら戻せる可逆性が高い」点がメリットだそうです。
また、packs-railsで分けたモジュール間の意図しない依存関係を検知してくれる静的解析ツール「packwerk」というgemも紹介。「packs-railsとgemを組みあわせることで、簡単にファイルを移動してこんなモジュールがいいのでは、と試行錯誤できるのがいいところ。Rails使っている人は試してみてほしい」と呼びかけました。
ローンチから6年近くが経つTROCCOは長期にわたって利用しているお客様も多く、「数年以上使っているお客さまも設定の管理が課題になる」と指摘。TROCCOのパブリックAPI拡充や、コード管理のためのTeffaform Providerという取り組みを紹介、「今後も引き続き開発を進めていく」と講演を締めくくりました。
