(Photo by：tec_estromberg)
はじめに
マイクロサービスアーキテクチャ（マイクロサービス）は、以前から存在していましたが、バズワードになってからにわかに人気が出てきました。NetflixやAmazon(AWS)、クックパッドなどの大企業が自社のサービスに適用して成功を収めています。”SOA（サービス指向アーキテクチャ）の再来か？”と思った方もいるでしょう。しかし、SOAとマイクロサービスは似て非なるものです。
この記事では、マイクロサービスアーキテクチャ（マイクロサービス）の概要を知りたい方のために、マイクロサービスの概要とメリット・デメリット、適用する際の要点などをお伝えします。流行に飛びつく前に、どんなものかしっかり理解しておきましょう。
マイクロサービスアーキテクチャ（マイクロサービス）とは？
マイクロサービスアーキテクチャとは、サービス全体をひとつのモノリシックサービスとして開発するのではなく、それぞれが独立した軽量なサービスの集まりとして構築するアーキテクチャパターンです。各サービスが通信し合い、全体としてひとつのサービスを成します。
各サービス間の通信には、HTTP（REST API）やRabbitMQなどのメッセージングプロトコルを使います。また、各サービスは単一のホストで実行することもできますし、複数のホストに分けて実行することも可能です。サービスの要件によって自由に決めることができます。
マイクロサービスの特徴的なところは、サービスが他のサービスから独立していることです。もちろんこれは自動的にそうなるわけではありませんから、独立性を持つようにサービスを分割しなければなりません。そのため、サービスごとにデータベースを持つ場合もあり、デプロイもサービスごとに独立して行います。
マイクロサービスアーキテクチャを導入するメリット
サービスごとに異なる技術を採用できる
他のサービスと通信することができれば、すべてのサービスが同じ技術や言語で開発されている必要はありません。サービスを担当するチームが得意な技術で開発を進めることができ、生産性の向上が期待できます。とはいえ、あまり多くの技術を使いすぎるのは考えものです。
障害耐性・保守性が高い
各サービスの依存性を排除できれば、（クリティカルな部分ではない）一部のサービスが停止してもサービス全体としては継続させることができます。また、メンテナンスするサービスのみを一時的に停止するといったこともできるようになり、保守性も高まります。
スケール・冗長化が容易
各サービスを別々のホストで実行すれば、サービスごとにスケーリングや冗長化ができるようになります。負荷が高いサービスのみをスケールアウトしたり、ミッションクリティカルなサービスのみを冗長化したりといったことが可能です。
開発チームを小さくできる
サービスが大きくなると、必然的に関わるエンジニアの数が増えていきます。チームが大きくなればなるほどコミュニケーションパスが増大し、バグが発生しやすくなっていきます。サービスごとに小さなチームに分割することにより、品質の低下を防ぐことができます。
サービス一つ一つが小さいため把握が容易
モノリシックサービスは、コードベースが大きくなるにつれて全体を把握するのが難しくなっていきます。マイクロサービスでは、一つ一つのサービスが小さいため、把握しなければいけないことが少なく済みます。
サービスの再利用性が高くなる
個々のサービスをシンプルに保つことで、別のプロダクトを開発する際に再利用できる可能性が高くなります。また、サービスと通信すればよいだけなので、再利用する際も実装が容易です。
マイクロサービスアーキテクチャを導入するデメリット
モノリシックサービスよりも複雑になる
複数のサービスに分割することにより、一つ一つのサービスはシンプルになりますが、サービス全体としてはモノリシックサービスよりも複雑になります。マイクロサービスは銀の弾丸ではないので、これはアーキテクチャ上のトレードオフです。
サービスに分割するのが難しい
マイクロサービスを新規プロダクトに適用する場合、初期の段階ではドメイン領域の理解が浅いため、そもそもサービスに分割することが難しくなります。適切でないサービスに分割してしまうと、サービス同士が依存関係を持ってしまい、マイクロサービスの利点が失われてしまいます。最初から分割することが難しいようであれば、一旦モノリシックサービスとして開発した後で、改めてマイクロサービスとして開発し直すことも検討してみてください。
デバッグ、バグの原因究明が難しくなる
ひとつのクライアントからのリクエストでも複数のサービスが関連するため、デバッグがしづらく、バグの原因究明が難しくなりがちです。そのため、各サービスでログを残すようにし、エンドツーエンドで一貫したトランザクションIDをログに記録して、デバッグをしやすくすることをおすすめします。
マイクロサービスで失敗しないために重要なこと
サービス同士を疎結合にする
マイクロサービスでは、サービス同士を疎結合にすることが最重要です。サービス同士が密結合してしまうと、独立してデプロイできなくなりモノリシックサービスに逆戻りしてしまいます。また、複数のサービスを同時にデプロイしていると、サービス同士が密結合してしまっていることに気づきにくくなります。デプロイはサービスごとに行いましょう。
サービスの内部実装を隠す
サービスの実装上の詳細が外部に露出していると、サービス同士の結合度が高くなり、本質的に影響のない変更でも他のサービスに影響を与えてしまいます。そうなってしまうと、サービスを変更することに消極的になり技術的負債を生んでしまいます。内部実装を隠蔽し、サービスの外部インターフェースのみに依存するようにしましょう。
サービスの障害が全体に影響しないようにする
マイクロサービスは複数のサービスで構成されているため、ひとつのサービスの障害が全体に影響しないようにしないと、モノリシックサービスよりも可用性が低下してしまいます。Hystrixなどのサーキットブレーカーを導入して連鎖的なサービス障害を防ぎましょう。
まとめ
マイクロサービスアーキテクチャは、どちらかといえば複雑な大規模サービスに向いています。小規模なサービスでは、導入コストの方が高くなってしまうでしょう。しっかりとメリット・デメリットを見極めて、慎重にプロダクトに適用するか検討しましょう。
本ブログは、Git / Subversionのクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
エンタープライズ向け Git / Subversion 導入や DevOps による開発の効率化を検討している法人様必見！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
