Segment (Twilio Segment)
Segment、140以上のマイクロサービスを1つのモノリスに統合
月3件ペースで増える連携先ごとにマイクロサービスを作った結果、共有ライブラリのバージョンばらつきと運用負荷が限界に達し、単一サービスへ回帰した。
課題
宛先ごとに140以上のマイクロサービスを乱立させ、依存関係管理と運用負荷が限界に達した
アプローチ
Centrifugeで配信を一元化し、Traffic Recorderでテストを高速化、共有ライブラリを単一バージョンに統一
効果
テストが最大1時間からミリ秒単位に短縮、共有ライブラリの改善数も年46件に増加
背景
Segmentは顧客データを様々な宛先（Destinations）に転送するサービスで、秒間数十万件のイベントを処理していた。当初は単一のキューで処理していたが、あるデスティネーションの障害が全体の遅延を招く「ヘッドオブラインブロッキング」が発生したため、140以上のデスティネーションそれぞれに専用のサービスとキューを持たせるマイクロサービス構成へと切り替えた。しかしこの構成は各リポジトリで120個の依存関係を異なるバージョンで運用する状態を生み、共有ライブラリの修正が全サービスに反映されるまで数日から1週間かかるようになった。負荷パターンもサービスごとに異なるため手作業でのスケーリングが必要になり、システム維持だけに3名のフルタイムエンジニアが専従する状態となっていた。
移行のプロセス
Segmentのエンジニアは140以上のマイクロサービスを1つのモノリスサービスへ統合する決断をし、複数の施策を並行して実施した。
- 個別キューに代わって「Centrifuge」という仕組みを構築し、単一サービスへのイベント配信を一元的に担わせた
- テスト環境の再現には既存OSSのyakbakをベースにした「Traffic Recorder」を開発し、HTTP通信を記録・再生することでテスト実行をミリ秒単位まで高速化した
- 宛先ごとにバラバラだった共有ライブラリのバージョンを、全デスティネーション共通の単一バージョンに統一した
結果
統合の結果、複数の指標で改善が見られた。
- テスト実行時間は最大1時間かかっていたものがミリ秒単位に短縮された
- 共有ライブラリへの改善件数はマイクロサービス時代の年32件から、モノリス化後の1年間で46件に増加し、開発生産性が向上した
- デプロイも120以上のサービスへの個別デプロイから単一サービスへのデプロイへと簡素化された
学び
「rock solid testing suite」なしにモノリス化を進めると失敗するとの認識のもと、fault isolation・in-memory caching・依存関係アップデートの柔軟性という3点のトレードオフを受け入れる必要があったと振り返っている。