マイクロサービスが最近話題になっており、噂も生まれている。10年以上に渡り、重たく、扱いにくいSOAソリューションが続いたが、マイクロサービスはそれを置き換える待望のソリューションなのだろうか。それとも単に一枚岩のソリューションズよりも単純なだけなのか。
この問題を議論する前に、マイクロサービスの定義を紹介しておいたほうがいいだろう。James Lewis氏とMartin Fowler氏はMicroservicesという記事でマイクロサービスという設計スタイルを以下のような手法として定義している。
小さなサービスの組み合わせによって単一のアプリケーションを開発する方法で、各サービスはそれぞれのプロセスで動き、軽量な仕組みで通信します。通常はHTTPです。また、各サービスはビジネスの可能性の周辺に構築され、完全自動化された配置の仕組みで独立して配置できます。最低限の中心的な管理システムがあり、このシステムはそれぞれ、異なるプログラミング言語、異なるデータストレージ技術で書かれています。
マイクロサービスには明らかな利点がいくつかある。
- 各マイクロサービスはシンプルでそれぞれのビジネスの要件に特化している。
- 各マイクロサービスは異なるチームで独立して開発できる。
- 各マイクロサービスは緩やかに結合する。
- 各マイクロサービスは異なるプログラミング言語、異なるツールで開発できる。
これらの利点を見るとマイクロサービスは完璧のように思えるが、欠陥はあるのだろうか。
ContinoのCTOであるBenjamin Wootton氏は現在、マイクロサービスをベースにしたシステムを設計しており、多くのの難点に直面している。氏は詳細をMicroservices - Not A Free Lunch!という記事にまとめている。以下の通りだ。
オペレーションのオーバヘッド
フェールオーバ後、20のサービスが40から60のプロセスになり、サービスの弾力性を加味するとさらに同等のプロセスが増える。ロードバランシングやメッセージングミドルウエアを使いした場合はもっとプロセスが増える。これらのサービスを運用し、編成するのは“うんざりするタスク”だ、Wootton氏は言う。
すべてのサービスを運用するには高品質な監視とインフラ運用が必要です。アプリケーションサーバを動かし続けるということはフルタイムの仕事ですが、私たちは現在、数十、数百のプロセスが起動し続けていることを保証しなければなりません。ディスクスペースが枯渇しないようにしなければなりません。デッドロックが起きないように、性能が劣化しないように、しなければなりません。これはうんざりする仕事です。
運用は自動化されていなければならないが、“自動化に合うフレームワークやオープンソースツールがない”ため、“マイクロサービスを運用するチームはスクリプトをカスタマイズしたり、プロセスを管理するための開発をした後に、ビジネス価値を生み出すコードを書く必要があります。”
DevOpは必須
Wootton氏はマイクロサービスを実装する組織にはDevOpが必須だ。なぜなら、
マイクロサービスで作られたアプリケーションをそのまま運用チームに渡すわけにはいきません。開発チームが運用に着目する必要があります。マイクロサービスを使ったアプリケーションは環境に過度に依存するからです。
多くのサービスが独自のデータストアを必要とするので、開発者は“NoSQL製品の配置や実行、最適化などについて詳しく理解しておく必要があります”。
インターフェースのミスマッチ
サービスはサービス間の通信に利用されるインターフェースに依存する。ひとつのサービスのインターフェースを変更するにはほかのサービスも変更しなければならない。
片方のシンタックス、セマンティクスを変更すると、ほかのサービスもこの変更を知る必要があります。マイクロサービスの環境では、単純な変更でも多くのコンポーネントを修正しなければならない可能性があるということです。そして、連携しながらリリースしなければなりません。
もちろん、後方互換性をたもつアプローチで変更を回避することはできます。しかし、ビジネス駆動の要件の場合は段階的なリリースができないのはよくあることです。
コラボレーションしているサービスを同期しないようにすると、メッセージフォーマットの変更の影響は視覚化しにくくなります。
コードの重複
“システムの同期的な結合”さけるため、Wootton氏はある特定のコードを異なるサービスに入れるのが便利な場合があるという。しかし、こうすると、コードの重複が発生する。コードの重複は、“すべてのコードのインスタンスはテストされメンテナンスされなければならない、という考えからすると、まずいことです。”解決策としては、サービス間で共有のライブラリを使うという方法があるが、“さまざまな言語が使われている環境ではうまくいかないでしょうし、結合が導入され、サービスを平行してリリースし、サービス間のインターフェースを維持しなければならなくなるかもしれません。”
分散システムの複雑さ
マイクロサービスには分散システムとしての複雑さがあり、注意しなければならない課題がある。例えば、“ネットワークの遅延や耐障害性、メッセージのシリアライゼーション、信頼できないネットワーク、非同期性、バージョニング、アプリケーションの各層に対するロードなど”だ。
非同期性
Wootton氏の考えでは、マイクロサービスは非同期プログラミングやメッセージング、並列処理を普通に活用する。しかし、これらの技術は複雑で、“相関するIDを管理したり、分散トランザクションで複数のアクションをまとまる必要があるとき”のような“同期やトランザクションを保証しなければならないとき”は複雑になってしまう。
テスト
マイクロサービスの場合、テストも課題になる。というのは、“一貫した方法でテスト環境を再作成するのは、手動でも自動でも難しい”とWootton氏は書いている。
非同期性と動的なメッセージ負荷によって、テストし、ある一群のサービスがリリースしても大丈夫だという確信を得るのが難しくなります。
個別のサービスはテストできるのですが、動的な環境では、わずかな振る舞いがサービスに対するインタラクションで発生します。これは把握するのが難しく、テストしにくいのです。
Wootton氏の記事にコメントしているBrady氏は、一枚岩のアプリケーションからマイクロサービスへ移行した自身の経験に基づいて、コメントを寄せている。
一枚岩のアプリケーションからマイクロサービスへ移行するというプロジェクトで働いていたのですが、この記事で書かれているような障害に次々に直面しました。最終的にはたくさんのコードの重複が生まれ(各サービスは異なる言語、フレームワーク上で動いていたため)ましたが、ユーザのデータをふたつのサービス間でマッピングするというような"暗黙の規約"は少なくなり(すべてのサービスで同じデータを使う必要はない)ました。また、明らかな利点もあります。しかし、何の計画もなしに飛び込めるような利点ではないでしょう。私たちは最終的には一枚岩のアプリケーションをモジュール化して(コードリポジトリ、配置、モジュール間のコードを共有化しつつ、十分に疎結合のコンポーネントを保つことができました)、それぞれの独立したマイクロサービスでそのモジュールを利用し、必要なときにだけそれらのマイクロサービスを配置/管理するようにしたのです。
Dennis Ehle氏も自身の経験から、マイクロサービスにはある程度のコストもある、と結論づけている。
私たちは継続的デリバリのパイプライン自動化フレームワークをクライアント向けに開発しています。そのクライアントは450人の開発者が50のサービス(マイクロサービス)で働いています。このアーキテクチャの最も優れた点だと思うのは、この450人の開発者が顧客向けのインターフェースを一切作る必要がないということです。顧客向けUXは完全に別のグループが担当できます。
顧客が享受している柔軟性やリスク低減、コスト削減はすばらしいものであり、一枚岩のアプリケーションを捨てた直接の成果ではありますが、確かにあなたの記事にあるように、多くの要因から"マイクロサービス税"を支払わなければならないのは確かです。
一方、Steve Willcox氏はマイクロサービス導入によって生まれる難点の中にチャンスを見ている。
モノリジックなJavaアプリケーションをSOAの実装に移管する仕事のリードをつとめることで、私はあなたが列挙した課題に直面したことがありますが、問題と捉えるより、優れたソフトウエアを構築するための機会と捉えました。
"しっかりとしたDevOpのスキルが必要"だと書いていますが、私はこのスキルが必要になることはよいことだと思います。コードを書いている人に運用環境での動作に責任を与えることができるからです。SOAの実装では、DevOpを脱中心化し、サービスを開発するチームの開発者がDevOpまで手がけるようになりました。従来の運用チームに"丸投げ"とは違います。運用にまで責任を持つ開発チームというのはとてもよいチームです。
モノリジックなアプリケーションよりもビルド、テスト、デプロイしなければならないサービスの数は多いのですが、これらの作業は自動化できます。自動化されているなら2つと20でも大きな違いはありません。
コードの重複については、悪いことではないとWillcox氏は考えている。
私もかつてはこの領域では純粋で、すべてのコード重複は悪だと考えていました。しかし、このような純粋さはときとしてコストになり、複雑なソリューションになってしまうことに気づいたのです。誰も得をしない理想論だということです。今はより実利的です。私はこの件に関してRichard Gabriel氏がThe Rise of Worse is Betterで書いていることがとても好きです。
マイクロサービスは多くの魅力的な利点を持っているが、難点も理解しておいたほうがいいだろう。