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

「TROCCO®」の概要

株式会社primeNumberの創業は2015年で、現在10年目を迎えるスタートアップ企業です。従業員数は現在100人程度が在籍しています。

私たちは「あらゆるデータをビジネスの力に変える」というビジョンを掲げており、主力サービスとして「TROCCO®」というデータ基盤の構築と運用を支援するSaaSを提供しています。主にデータ基盤構築・運用の「統合」の部分を担うサービスです。また、そこから派生する形で、最近「COMETA®︎」というデータカタログサービスを提供開始しました。

両サービスはどちらもデータのビジネス活用をサポートするSaaSとなっていますが、TROCCO®はデータ統合に軸を置いており、COMETAはデータ活用に焦点を当てたサービスとなっています。

主要機能

TROCCO®でメインとなるのがデータ転送機能です。OSSのEmbulkを主に使用しています。機能スタックは、日夜動き続けるジョブ系の機能と、それらを管理する機能に大別されます。 データ転送機能の仕組みですが、UIで転送の設定を作成すると、転送実行のタイミングで入力情報をもとにEmbulk用のYAMLファイルが生成されます。その後、実行単位でコンテナが立ち上がり、Embulkコマンドを実行し、終了後に破棄するというアーキテクチャになっています。


また、もう1つの主要機能であるワークフロー機能では、転送設定をGUIで依存関係を定義し、実行順序を制御することができます。ループや、フロー自体の入れ子など、複雑な構成にも対応できるようになっています。

サービスの特徴

TROCCO®は2024年現在、毎日20万件以上の転送ジョブが実行されるプラットフォームに成長しています。24時間365日絶え間なく稼働し続けており、常に何らかのジョブが実行されている状態です。

負荷パターンには特徴的な傾向があります。まず、毎時0分に大きなスパイクが発生します。これは多くのお客様がcronを0分に設定する傾向があるためです。また、日付が変わった後の深夜1時頃にも2つ目のピークが観察されます。これは日次バッチ処理のための設定と考えられます。

お客様がサービスに求めているのは、設定した時間にジョブが正常に起動し、想定どおりにデータが配置されることです。そのため、それを実現するジョブ基盤には強固な信頼性が求められます。一方で、設定をいかに容易に行えるかという点も、SaaSに求められる重要な価値の一つだと考えています。

このようにTROCCO®の開発においては、PaaSに求められる信頼性を第一に確保しつつ、SaaSとしての利用体験を向上させる機能をいかに効率的にデリバリーしていくかが課題となっています。

これまでの取り組み

TROCCO®の開発は2018年6月に開始し、同年11月に初期リリースを実施しています。この段階では、自社での使用や、お付き合いのあるお客様へのトライアル提供を行い、プロダクトの市場ニーズを探る段階でした。開発体制としては、エンジニア1〜3人程度で開発。社内の技術スタックとしては、主にAWS上でRuby on Railsを動かしていました。

黎明期のアーキテクチャ刷新

当時のアーキテクチャは、右側にジョブを実行するECSタスクが配置され、ジョブのQueueをポーリングして、メッセージを受信次第Embulkを実行するという、シンプルな構成でした。そして、この構成にはさまざまな課題がありました。

例えば、ジョブが長時間実行されている場合にスケールインができない、また、新バージョンのデプロイ時に長時間実行中のジョブがあるとECSのローリングアップデートができないといった問題がありました。



利用者が少なかった当時は、試行錯誤しながら何とか運用を続けていました。ですが、徐々に有償契約のお客様が増加し始め、それに伴い1日あたりのジョブ数が急増していきました。当初は1日約40件程度だったジョブ数が、2019年4月には1,000件まで増加し、このままでは立ち行かなくなるだろうという危機感が芽生え始めたのです。

ちょうどその頃、AWS EKSが東京リージョンに導入されました。これは採用するしかないと判断し、ジョブ基盤の部分を全てKubernetesを使ったアーキテクチャに刷新しました。特徴的な点として、Dispatcher層を設けて、SQSのポーリングとポーリングして受け取ったメッセージをKubernetesのジョブとして登録するまでを担当する層を設置しています。


ジョブの管理はKubernetesに委託する形とし、登録後は自動的に立ち上げまでを実行してくれます。それまでの課題だったスケーリングについては、Cluster Autoscalerで効率的に解決できるようになりました。

一方、UI部分については従来通りECSでの運用を継続しています。これは、TROCCO®が他のBtoB SaaSと比較してトラフィックが比較的少ないという特徴があり、安定して運用できていればいるほど、ユーザーが特に意識せずに画面操作をしなくなるという背景があるためです。

データ基盤構築・運用のサービスへ

基盤の安定化に伴い、機能拡充に時間を割けるようになり、その後の数年間はさまざまな機能を次々と開発していくフェーズとなりました。データ転送機能以外にも、データ基盤構築のためにサポートすべき機能は多数存在します。例えば、近年主流となっているデータウェアハウス（DWH）上での変換を行うELTといった機能や、それらのジョブを管理するオーケストレーションツールといった機能の必要性も出てきました。

ワークフロー機能の開発にあたっては、まずデータ転送機能におけるEmbulkのように、既存のOSSを活用するか否かが重要な論点となりました。例えば、ワークフローエンジンとしてはAirflowや、Embulkと同じ作者によるdigdagなどが候補として挙げられます。

ここで、OSSの仕様と密結合になってしまうという問題が判明しました。これはデータ転送機能のスキーマ設定画面なのですが、データ型の選択が必要で、これはEmbulkの世界での型を選択しなければなりませんでした。


お客様としては、Embulkのマネジメントサービスを使うために契約しているわけではなく、データを転送したいために契約しているので、このような実装の詳細が表面に出てくるのは望ましくないという課題がありました。

また、さまざまなデータソースへの対応において課題がありました。たしかにデータ転送機能はOSSを活用することでかなりのレバレッジが効きます。ですが、ワークフロー機能は実行順序の制御が主な機能です。OSSを採用してもそれほど大きな恩恵は得られないだろうという判断から、結果としてスクラッチでの開発を選択しました。

テスト戦略の試行錯誤

データ転送機能も継続的に成長を続けており、データ転送の送信元と送信先、私たちが「コネクタ」と呼んでいるものが約100種を超えるまでに増加しています。コネクタの種類も、データベースやストレージといった基礎的なものから、広告やSaaSまで、幅広いユースケースに対応できるように変化してきています。また、基盤が安定してきたことで、常に多種多様なジョブが稼働している状況であり、変更頻度が高く、多くのユーザーが利用しているコネクタも存在します。

一方、TROCCO®は1日1回のデプロイを行っており、デプロイ時のアプリケーションレイヤーの信頼性が求められます。お客様のデータパイプラインに組み込まれるというプロダクトの性質上、リリース後の数時間をテスト期間とするようなデプロイ方式は採用できません。

また、TROCCO®の中核機能は外部サービスとの通信です。そのため、一般的なユニットテストでよく使用されるモックだけでは不十分です。実際の外部サービスと通信を行うインテグレーションテストを重視する必要があります。

初期の頃は、ステージング環境に設定を登録し、本番リリース前に一括実行して動作確認を行っていました。しかし、この方法では処理の終了ステータスしか確認できず、データが正しく転送されたかどうかまでは検証できないという課題があったのです。
そこで、TROCCO®自身の機能を使ってテストを行うアイデアが生まれました。TROCCO®に実装されたデータチェック機能を活用し、テストを自動化したのです。この機能はクエリの実行結果に基づいてエラー判定を行い、ワークフローに組み込むことができます。


このアプローチにより、データの転送結果を実際に検証できるようになり、SQLさえ書ければテスト作成が可能なため、QAテスターでも対応できるようになりました。一方で、テスト構成が複雑で、ステージング環境でしか実行できず、ローカル開発時の検証が困難という課題も残りました。

これらの課題に対応するため、現在は複数のテスト手法を組み合わせています。通常のテストに加え、実際のジョブ接続確認やカナリアリリースなど、多層的な品質保証の取り組みを行っています。

SREによる信頼性向上の取り組み

1人目のSREの入社を機にSREチームが発足し、それまで機能開発を優先していたTROCCO®の運用面を改善していきました。主な取り組みを2つご紹介します。

サスペンドモード

DBメンテナンス時、24時間動き続けるジョブがエラーになってしまうという課題がありました。このような場合、お客様に事前にお伝えして了承を得ていたのです。

これに対し、Redisにサスペンドフラグを設置し、DBへの書き込み前に一時停止する仕組みを導入しました。この対応により、DBへの書き込みは若干遅れますが、Embulkのプロセスは継続して動作し、ジョブ自体がエラーになることを防げるようになりました。

事前スケールアウト

毎時0分にジョブが集中する特性から、クラスターのスケールアップに時間がかかり、ジョブの開始が遅延するという課題がありました。そこで、スパイク前にリソース確保用のPodを配置し、事前にNodeを立ち上げておく仕組みを実装しました。これにより、0分ちょうどに設定されたジョブを遅延なく実行できるようになりました。

このようにSREチームの取り組みにより、TROCCO®の運用品質と安定性が大きく向上しました。

TROCCO®のこれから

TROCCO®は大きく成長し、開発体制も1チームから5〜6チームへと拡大しました。さらに韓国とインドへの海外展開も実現し、一部の機能は独立して新しいプロダクトへと発展しています。

海外展開

韓国とインドでの事業展開が決定した際、各国のデータローカライゼーション要件に対応する必要がありました。そこで、東京リージョンで構築したTROCCO®のアーキテクチャを、ソウルリージョンとムンバイリージョンでも構築することにしました。

この過程で、Terraformのモジュール化に関する課題が見つかりましたが、リファクタリングを実施したことで、2リージョン目以降の構築をスムーズに進めることができました。

コネクタ開発

コネクタの開発では、海外展開に伴う新たな需要への対応と、開発生産性の向上などの課題に直面しています。特に海外展開後は、日本市場では見られない独自のコネクタニーズが発生しており、対応の必要性が高まっています。

これまでのコネクタ開発はJavaベースのEmbulkプラグインを使用していましたが、この方式ではJavaとEmbulk両方の専門知識を持つエンジニアが必要です。オフショア開発が始まったこともあり、より簡単に開発できる仕組みが求められています。

そこで現在は、Embulk input httpプラグインを活用した新しい開発手法を確立しようとしています。APIの仕様を宣言的なYAMLで記述すれば、フォームやYAMLファイルが自動生成される仕組みの構築を進めています。

この新しい開発手法の最大のメリットは開発プロセスの分業化です。APIの仕様を調査する人、その調査結果をYAMLに変換する人、そして変換の基盤を実装する人と、それぞれの役割を明確に分けることができる。役割を分担することで、各担当者は自身の専門分野に集中でき、コネクタ開発の生産性を大幅に向上させることができるでしょう。

モジュール分割

チームとプロダクトの拡大に伴い、Railsのモノリス構造による課題が顕在化してきました。大規模なモノリスでは、機能変更時の予期せぬ影響やコードの理解が困難になるという問題があります。そこで、新プロダクトCOMETAの分離を契機に、モジュール分割に着手することにしました。

分割にあたっては、モジュラーモノリスというアプローチを採用しています。具体的には2つのライブラリを活用しています。一つはpacks-railsで、これによりRailsのMVCコンポーネントをディレクトリ単位で分割できます。このツールの利点は、参照元の書き換えが不要で、変更の可逆性が高いことです。

もう一つはShopify製のpackwerkで、これはモジュール間の依存関係を検知する静的解析ツールです。この2つを組み合わせることで、段階的なモジュール分割とその妥当性の検証が可能になりました。

最後に、機能面の拡充の話をして終わりにしたいと思います。TROCCO®はエンジニアをターゲットユーザーとしているSaaSです。その特性を活かし、パブリックAPIの拡充とTerraformプロバイダの公開を行いました。これにより、お客様からの要望が強かった設定のコード管理が可能になりました。

TROCCO®の開発はこれからも続きます。ご清聴ありがとうございました。