ほとんどすべてのエンジニアリングチームが将来的なマイクロサービス移行を検討する一方で、そのアドバンテージには重大なトレードオフも伴う。QCon Londonで、Alexandra Noonan氏は、Segmentが自社のモノリスをマイクロサービスに分解し、その数年後、モノリシックなアーキテクチャに戻った経緯について講演した。Noonan氏によれば、"マイクロサービスが正しく実装されなかったり、あるいはシステムの根本的な問題に対処しない応急措置として使用されたりすると、その複雑さに引っ張られてしまい、新たなプロダクト開発ができなくなる"のだ。
Segmentに最初にマイクロサービスが導入されたのは、同社のモノリスの不十分な障害分離に対処するためだった。しかしながら、同社の事業が成功を収めて、より多くの外部サービスと統合されるようになると、マイクロサービスをサポートするための運用上のオーバーヘッド増加に耐えられなくなってきた。モノリスに戻すという決定は、企業成長に伴うスケールアップに関わる問題点を考慮した、新たなアーキテクチャとともに持ち上がったものだ。モジュール性、環境分離、可視性を犠牲にする一方で、運用上のオーバーヘッドという大きな問題に対処し、エンジニアリングチームが新たな機能開発に戻ることを可能にするための判断だった。
Noonan氏は、Segmentのアーキテクチャ進化における、いくつかのキーポイントについて説明した。同社が直面した問題、その時に下した判断は、経験豊富なソフトウェアエンジニアであれば誰でも聞き覚えのあるものだ。どちらの判断が望ましいものであったのかを語るのは、結果論以外の何ものでもない。Noonan氏はタイムライン上のおもな意思決定点について説明した上で、それぞれの段階におけるシステムアーキテクチャのメリットとデメリットを挙げた。
2013年、Segmentはモノリシックアーキテクチャでシステムを立ち上げた。このシステムは、運用上のオーバーヘッドは低かったが、環境分離が欠けていた。Segmentのシステム機能は、多数のさまざまなプロバイダからのデータの統合が中心となっているのだが、モノリスであったため、ひとつのプロバイダへの接続上の問題が、すべての接続先やシステム全体に悪影響を及ぼす可能性があった。
この分離性の欠如に対して、同社は、接続先毎にワーカサービスを設定するマイクロサービスに移行することで対処した。マイクロサービスは同時にシステム全体のモジュール性や可視性も改善し、キューの長さや問題のあるワーカの特定が簡単にできるようになった。可視性はモノリス内に組み込むことも可能だが、マイクロサービスでは何もしなくても得ることができる、とNoonan氏は指摘する。一方でマイクロサービスには、運用上のオーバヘッドの増大とコード再利用に関わる問題があった。
Segmentが急成長(hypergrowth)を続けていた2016～2017年には、50の新たな接続先が、3ヶ月に1つのペースで追加されていた。サービス毎にリポジトリを用意する方法は、接続先毎のワーカが少ない間は管理可能だが、スケールが大きくなるにつれて問題となる。すべてのワーカが同じような動作をするように、共有ライブラリが開発されたが、これも新たなボトルネックになった。制約のテストがおもな原因となって、共有コードの修正に1週間の開発作業が必要になったのだ。共有ライブラリをバージョン管理することでコード変更の実装は短期間で行えるようになったものの、共有コードの提供によって意図していたメリットが逆転する結果になった。
Noonan氏は、同社のマイクロサービスに対するフリーサイズ(one-size-fits-all)アプローチの限界を指摘する。新たなサービスの追加に必要な作業が大きくなったことで、実装をカスタマイズすることができなくなった。負荷やCPUリソースのニーズが大きく異なるにも関わらず、すべてのサービスに同じ自動スケールルールが適用されていた。また、真の障害分離のためにはキュー毎ユーザ毎にひとつのマイクロサービスを置くことが適切なソリューションだが、それには10,000以上のマイクロサービスが必要だったのだ。
モノリスへ回帰するという2017年の判断は、マイクロサービスのメリットを失うことの容認を含む、すべてのトレードオフを考慮した結果だった。Centrifugeと名付けられた新たなアーキテクチャは、数十の公開APIに毎日送られてくる数十億のメッセージを処理する能力を備えている。コードリポジトリはひとつになり、送信先別ワーカはすべてが同じバージョンの共有ライブラリを使用している。ワーカが大きくなったことで、ロードのスパイクに対する処理能力も向上した。送信先の追加は運用上のオーバヘッドの増加を伴わなくなり、デプロイメントも数分で完了するようになった。ビジネス上で何よりも重要だったのは、新たなプロダクト開発を始められたことだ。これらのメリットはすべて、マイクロサービスであれば手に入れられたモジュール性や環境分離や可視性を失う価値の十分にあるものだ、とチームは考えている。
講演に対するQConの参加者たちの議論は、長期プロジェクトに従事するエンジニアの典型的な意見であるように思われた。"彼らのやったことは、明らかにするべきではないことだ"という当初の意見に対して、ほとんどの判断はその時点で得られる限りの情報に基づいて行われるものだ、という経験に基づいた反論の声もあった。ただし、ひとつ言えるのは、あと数日あるいは数週間かけてさらに分析を行っていれば、修正に数年を要するような状況は回避できたかも知れない、ということだ。