理屈のうえでは、マイクロサービスは簡単です。疎結合で、互いに独立して開発、テスト、そしてデプロイできるスケーラブルなサービス。すごい話ですよね。さらに、それぞれのサービスはそれぞれの都合に合った言語、また好きなフレームワークで開発を行っても、アーキテクチャの他の部分に影響は与えないときたものです。JavaサービスをNodeやGo、Rubyなどのサービスと合わせて使い、それぞれが別々のデータストアにデータを永続化するようなこともできます。たとえばJavaサービスではKey/Valueストアを使っているかもしれません。もしかするとGoサービスではトラディショナルなRDBMSに永続化していたり。マジで未来が来ています。
…と思っていた時期もありました
現実には、マイクロサービスは開発者たちに新しい課題を投げかけています。われわれの業界はどうも循環しているところがあって、5年とか10年とか前に解決した問題へのソリューションを再発明するようなことがあります。これは必ずしも悪いことではなく、古い問題に新しい答えを創造することで、何年かの間に得られた教訓を織り込むことができます。ソーシャルメディアの勃興と流行により、以前は交わることのなかった開発者コミュニティ間の境界がやや曖昧になり、アイディアが共有されるようにもなってきました。とは言うものの、マイクロサービスがあなたの抱えるモノリシックな問題を即座に解決してくれるようなものではないということを理解しておくのが重要です。マイクロサービスは古くからある問題を解決する新しいやり方を提供してくれますが、それなりの代償もあります。あなたは考え方を変える必要に迫られるでしょうし、これまで揺るぎない常識だと思っていた概念から距離を取る必要も出てきます。データベースでのCHECK制約を用いた参照整合性といったやり方はもう当てはまらないでしょう。プログラマーが最も早い時期に学んできた考え方のひとつであるDon't Repeat Yourself(DRY)はそれほど重要だとはみなされなくなります。
あらゆるものごとにはなんらかの代償があり、これはマイクロサービスに限った話ではありません。Object Relational Mapping(ORM)フレームワークが一般的になったときには、それまで持ち得ていたきめ細かな制御は一定程度失われました。オブジェクトのごく一部のプロパティを選択して取得するのはそれほど簡単ではなくなってしまいました（オブジェクト全部を取得するか何も取得しないか、です）。ORMを用いてオブジェクトグラフに複雑なクエリをかけるのは難しく、パフォーマンスに苦しむことになります。これはほとんどのORMシステムがリフレクションを使っており、もし実装がへぼかった場合、たちの悪いデータベースクエリを実行することになるからです。
一方で、マイクロサービスの人気には疑問を差し挟む余地はありません。お客様からはもしかしたらここ数年の他のいずれのトピックよりもマイクロサービスについて頻繁に質問をいただきます。マイクロサービスについて、カンファレンスでは多くの議論がなされ、ブログポストやビデオも日々公開されています。というわけで私も、パワフルでメンテナンスしやすく、高性能なマイクロサービスを作成するための耳寄りなテクニックを紹介するため、ブログポストのシリーズを投稿することにしました。
言うまでもなく、プロジェクトはそれぞれ異なっています。ひとつのプロジェクトでうまくいったことが、他のプロジェクトでもうまくいくとは限りません。前の会社でやったことが今の会社にとってベストなやり方であるとも限りません。それでいいんです。それこそがこの業界で働くことをエキサイティングにしてくれる一因です。もし全てのプロジェクトに適用できる簡単なソリューションなんてものが存在したら、本当にすぐに仕事は退屈になってしまうでしょうね。私のブログポストシリーズを読む際にはこのことを覚えておいてください。そして、どのアーキテクチャでやると決める前にも、常にビジネス要件の評価を確実に実施してくださいね。
マイクロサービスの定義とは
私が言っている「マイクロサービス」の意味するところをあなたが完全に理解している、なんていう風には思い込むべきではないでしょう。というのも、しばしば「みんな」がマイクロサービスについて知っているような気がしてしまうときもありますが、現実には開発者の中には依然、そのおおまかな概念を理解できていない方もいます。伝統的に、われわれはアプリケーションを今では「モノリス」として知られているパターンでデザインしてきました。つまり、ひとつのアプリケーションにすべてのサービス、ビジネスロジック、モデルとそして通常画面のコードが含まれているというものです。あなたはモノリスはいくぶんか時代遅れであり、「モダン」なソフトウェアの世界にもはや居場所はないのだといった話をしばしば読んだり、聞いたりするでしょう。端的に言ってそういった話は間違っています。アプリケーションが単一のコードベースであることがベストである場合は確実に存在しますし、あなたがある方法でアプリケーションを開発することを決めたことそれだけであなたのソリューションが他のものに劣っているのだと感じる必要なんてないってことです。しかし、ある場合においてはアプリケーションの要件が単一のコードベースにするには複雑にすぎるといったこともあります。もしかするとあなたのところにはいくつかの分散した、異なるスキルセットを持ったチームがあるかもしれません。あるいは他のサービスに比べ突出して利用されているサービスがあるかもしれません。異なる永続化モデルに間借りされるようなデータがあったりとか。（とりわけ）そうした条件では、開発者たちはマイクロサービスパターンを用いることで結合を疎にしたり、個々にサービスをスケールさせたり、管理したりしてきました。Martin Fowlerはマイクロサービスについて2014年のこの記事の中でそのようなことを述べています：
簡潔に言えば、マイクロサービスアーキテクチャスタイルは単一のアプリケーションを複数の小さなサービスのセットとして開発することだ。それらはそれぞれ自身のプロセスの中で可動し、しばしば用いられるHTTPリソースAPIのような軽量な仕組みでコミュニケーションする。これらのサービスはビジネス上の機能に関連づけられて開発され、完全に自動化されたデプロイ機構によって個々にデプロイが可能である。そこでは中央集権的なサービス管理は実に最小限しかなく、サービスはそれぞれ異なったプログラミング言語で書かれていてもいいし、異なったデータストレージを用いていてもよい。
簡単で、でも簡単じゃない…
最初に書いた通り、理屈の上ではとてもシンプルです。でもマイクロサービスの背景にある理屈を理解するところから、実際に実装するまでの道のりは難しいものかもしれませんし、データを管理しようとする段になるといろいろとややこしくなるかもしれません。このブログシリーズでは、小規模なマイクロサービスを作成してデプロイする方法―基盤からコーディングそしてデプロイメント―をご紹介したいと思います。また、マイクロサービスパターンを実装した場合のいくつかのデータ管理方法についても説明し実演していけたらと思います。