分散されたモノリスになってしまうマイクロサービス

Microservices Practitioner SummitでFacebookのエンジニアのBen Christensen氏氏が、バイナリの依存関係でマイクロサービス同士が密結合になってしまうという、ますます一般的になりつつあるアンチパターンについてプレゼンをした。

FacebookでソフトウェアエンジニアをしているChristensen氏は、共有ライブラリをサービスが動作する上で必須のライブラリと定義している。"プラットフォーム"と呼ばれるのが一般的だ。Spring、Guava、またはルーティングやロギングで使われている共通ライブラリのことだ。最終的には数百のライブラリに依存するシステムになる場合もある。これらのライブラリが全て使えなければ使えないサービスをChristensen氏は、分散されたモノリスと読んでいる。一枚岩のシステムをネットワーク上にばらまいて、分散システムと同様のコストを払いながら、マイクロサービスの利点は享受できないという状態だ。異なる技術を組み合わせてサービスを構成できるという利点も失われ、また、組織や技術の疎結合化もできない。権威が許可なしでチームが技術的進歩を推進することができなくなるのだ。

Don’t Repeat Yourself (DRY)という頭字語は開発者の世界ではとてもよく知られている。共有されているコードの中にビジネスロジックがある場合、分離した状態でデプロイできるというメリットは少なくなる。そのコードを使っているサービスすべてが影響を受けるからだ。コードの共有はサービスの境界内では完全に正しい、とChristensen氏は強調する。しかし、境界の外に漏れたら、それは潜在的な密結合だ。氏はSam Newman氏とその著書Building Microservicesに言及している。この本でNewman氏は次のように書いている。

サービス間の過度な密結合が引き起こす問題は、コードの重複が起こす問題よりも悪質です。

Christensen氏が提唱する代替案は、規約とプロトコルだ。サービスは実装の詳細を隠蔽し、データの規約とネットワークプロトコルだけを公開する。サービスの実装へ依存しないようにすることで、利用者はどんな技術でもどんな言語でも使え、自分たちのペースで進化させられる。これは、インターネットの原理と同じだ。氏はロギングや分散トレース、ルーティングのような領域には標準化することに対する合理的なニーズがあることを認めているが、これらは、利用者が使うか使わないか選択できる、独立したライブラリで実現するべきだと主張する。

Christensen氏の考えでは、このような失敗に陥る理由は明白だ。開発者は共有ライブラリの使い方を知っており、短期的な最適化を図ろうとする。そのほうが生産的に感じるからだ。疎結合にするための遅延コストは大きく、開発者は解決策を知っているが、最初から解決策を適切に用意しておくのは追加の努力と思慮が不可欠だ。しかし、適切に用意さえすれば、その解決策はそのまま活用される。それゆえ、Christensen氏は短期的な簡単さを超えた視点を持ち、バイナリでの結合を避け、規約とプロトコルを使ってマイクロサービスアーキテクチャの利点を享受することを推奨する。

また、氏は、ひとつのサービスの中で大規模なフレームワークを利用することについては問題ないと考えている。しかし、システム全体で単一の大規模フレームワークを導入することには反対している。長期的な密結合が生まれるからだ。