昨年秋にTwilioが32億ドルで買収した新興企業Segmentは、2015年に軌道に乗り始めたばかりだったが、スケーリングの問題に直面した。急速な成長を遂げたため、プラットフォーム上でマーケティングデータを処理するために構築したツールが、当初のシステム設計の範囲を超え始めていたのだ。
何もしなければ、会社は技術的な壁に突き当たると経営陣は危惧していた。アーリーステージのスタートアップは皆、成長を切望しており、セグメントも例外ではなかった。しかし同時に、データプラットフォームのレジリエンスを高める方法も検討する必要があり、そうでなければシステムを通じてやり取りされるデータを処理できなくなる事態に陥る可能性があった。これは、まさに若い企業にとって存亡の危機だった。
Segmentのエンジニアリングチームは、より堅牢でスケーラブルなシステムのあり方について真剣に検討を始めました。結果として、彼らのビジョンは2015年末から今日までの間に様々な形で進化を遂げ、そのたびにリソースの割り当てとシステム内を移動するデータの処理効率が飛躍的に向上しました。
彼らの努力から生まれたプロジェクトは「Centrifuge」と呼ばれ、その目的は、Segmentのデータパイプを通じて、顧客が必要な場所に迅速かつ効率的に、そして最小限の運用コストでデータを移動させることでした。これは、そのシステムがどのようにして実現されたかという物語です。
成長痛
システム上の問題は、よくあるように、顧客からの苦情が出た時に顕在化した。2015年末、セグメントの最高製品開発責任者であるティド・カリエロ氏が就任すると、彼は解決策を見つける任務を負った。問題は当初のシステム設計に関係していた。スタートアップ企業の初期のイテレーションに多く見られるように、将来の成長をほとんど考慮せずに製品を市場に投入することだけを目的とした設計であり、技術的負債の返済期限が迫っていたのだ。
「当初の統合アーキテクチャは、様々な面で拡張性が全くない設計になっていました。急速な成長を遂げていた当時、CEOのピーター・ラインハルトは1ヶ月の間に3回ほど私のところにやって来て、顧客やパートナーから指摘された様々な拡張上の課題を報告してきました」とキャリエロ氏は語ります。
顧客とパートナーが急速にプラットフォームに引き寄せられていたことは朗報だったが、この力強い成長を支えるために基盤となるシステムアーキテクチャを改善していなければ、すべてが崩壊する可能性があった。キャリエロ氏の報告によると、それはストレスの多い時期だったという。しかし、Dropbox出身の彼は、企業のテクノロジープラットフォームを完全に再構築し、それを生き延びることが可能であることを理解していた。
テッククランチイベント
サンフランシスコ | 2025年10月27日～29日
「Dropboxでの経験から学んだことの一つは、ビジネスの根幹に関わる問題に直面した時、ある時点で、世界で自分だけがこれほどの規模で同じ問題を抱えていることに気づき始めるということです」と彼は語った。Dropboxの場合、それはストレージに関する問題であり、Segmentの場合は大量のデータの同時処理に関する問題だった。
構築か購入かという問題において、キャリエロ氏は自ら構築する以外に解決策がないことを悟っていました。セグメント特有のスケーリング問題を解決できるものは他にありませんでした。「当然のことながら、この状況について少し違った視点で考える必要があると確信し、Centrifuge V2アーキテクチャが誕生したのです」と彼は言います。
不完全な獣を作る
同社はシステムパフォーマンスの測定を開始し、当時は1秒あたり8,442イベントを処理していました。アーキテクチャのバージョン2の構築を開始すると、その数値は平均1秒あたり18,907イベントにまで増加しました。
2016年にシステムパフォーマンスの問題が表面化し始めたものの、AWS上のデータベースプールを用いたスケーリングアーキテクチャを採用したプラットフォームの次期バージョンを構築するまでには、1年間の調査と設計期間が必要でした。これはスケーリングの問題を解決する巧妙な設計でしたが、会社はすぐにこの設計には大きなコストがかかることに気付きました。
Centrifugeプロジェクトを率いた主任サイト信頼性エンジニアのアキル・ルーセル氏は、同社が大きな問題を抱えていることを認識していましたが、それはエンジニアが喜んで取り組むシステム設計の課題でした。最初のステップは、既存のシステムを理解し、それがセグメントの成長をどのように阻害しているかを理解することでした。
「問題領域を本当に深く理解した後、設計モードに入り、既存システムのすべての[良い]特性を維持しながら、すべての欠陥に対処し、今後数年間の成長を可能にするソリューションを考案することができました」とルーセル氏は説明した。
Robloxが技術スタックを根本から変革した方法
新システムの中核は、AWSのコンテナ管理サービスであるAmazon ECSとAmazon Auroraデータベースプールを用いたコンテナ化でした。「具体的には、最初の基盤技術としてAuroraを採用し、Aurora上で稼働するMySQLデータベースプールを管理していました。最終的には、Amazon RDS（クラウドリレーショナルデータベース）上で運用するようになりました。これがシステムを支える中核データベース技術であり、ECSは当時私たちが選択していたコンテナスケジューラでした。つまり、システムは基本的にこの2つの構成要素の上に構築されていたのです」と彼は言います。
2018年初頭にV2が完全導入された時点で、1秒あたり68,000件以上のイベント処理が可能でした。この新システムは、以前のバージョンで同社が抱えていたスケーリングに関する主要な問題の一部は解決しましたが、クラウドベースのスケーリングにはコストがかかるという、独自の問題もいくつか抱えていました。さらに、Segmentが構築できるプールデータベースの数には厳格な制限がありました。さらに、運用が非常に複雑だったため、システムの保守に新たな人材を投入することが困難でした。
これが、2019 年の初めに開始されたプロジェクトである V3 を構築するというアイデアにつながりました。
正しく理解する
コスト効率の問題はエンジニアリングチームを驚かせ、Amazonとのクラウド利用料金の増加を抑えるために機能を追加することを余儀なくされました。「システムを本番環境に導入した時、実際にどれだけのコストがかかっているかに気づき始めました。本番環境で運用しても収益が上がるようにするには、コスト管理に多大な労力を費やす必要がありました」とルーセル氏は語ります。
また、新しいシステムにも独自の制限があり、以前のシステムで遭遇したものと同様のスケーリングの問題があることにも気づき始めました。
彼らは再び、V2の設計上の限界に直面する前に、その限界を克服する方法を見つけなければならないという状況に直面しました。「1年後、私たちが導入した設計の限界が見え始めました。特に、数百のMySQLデータベースプールを自動スケーリングするという技術的な選択によって、一度に起動できるデータベースの数に物理的な制限が生じていたのです。」と彼は述べ、それがスケーリング速度の限界であることを認識し、その解決策を検討することが不可欠だと述べました。
この時点で、彼らはオープンソースのストリーミングイベントプラットフォームであるKafkaに目を向けました。これは、社内システムの一部に使用していたものです。今後は、AWS上で稼働するMySQLデータベースプールへの依存を解消するため、ソリューションの中核としてKafkaを活用する予定です。
「データベースを廃止することを決めた後、業界の動向や社内にどのような専門知識があるのかなど、選択肢を検討する必要がありました。Kafkaは非常に強力な構成要素として浮上しました。既にKafkaに多額の投資を行っており、優れた自動化と非常に高いコスト効率を実現していたため、Kafkaに再度投資することで、既に獲得したメリットをさらに活用できると考えました」と彼は語った。
また、ECSからAmazonのマネージドKubernetesサービスであるEKSに移行しました。新しいシステムは大幅にコスト削減され、インフラコストは10分の1に削減されました。最も重要なのは、同社が無限にスケーラブルなシステムを構築したため、V1やV2で直面したようなスケーラビリティの壁に直面することはないだろうということです。
実際、2019年9月にシステムが導入された時点では、1秒あたり157,000件以上のイベントを処理していました。最新の測定では、この数値は1秒あたり400,000件以上に増加しており、新システムの拡張性が実証されています。
同社はTwilio傘下となったことで、将来のアーキテクチャ計画はTwilioの計画とより密接に絡み合うことになるが、そのプロセスはまだ始まったばかりだ。キャリエロ氏によると、小規模なスタートアップ企業として、彼らは現在のプロジェクトまでしか見通せなかったが、Twilioのような上場企業は5年単位で物事を考えるという。
新しい親会社に何が起ころうとも、セグメントは、どれだけ成長しても回復力と拡張性を備えて将来へと進むためのシステムを構築しており、それは良いことです。
AWSから移行してから3年、Dropboxのインフラは進化を続けている
