こんにちは。デプロイ王子こと廣瀬一海です。前回はインフラストラクチャアーキテクチャとして、Serverless Computingを取り上げました。今回はソフトウェアアーキテクチャとして話題となっている「マイクロサービスアーキテクチャ（Microservice Architecture）」を取り上げ、そのメリットとデメリットについて説明します。
この数年の間に、私たちが開発するソフトウェアが対象とするクライアントデバイスは多様化し、求められる機能も大幅に増えてきました。クライアントに合わせて、開発言語やフレームワークや手法も異なり、開発製品の一部にクラウドが提供するサービスを活用するケースも多くなってきました。
今回解説するマイクロサービスアーキテクチャは、これらの変化に対応するには「どのような仕組みが良いか？」「どのように分離するのが適切であるか？」というソフトウェア工学におけるSoC（関心の分離）の延長上にある考えです。
マイクロサービスアーキテクチャとは
マイクロサービスという言葉は、ThoughtWorks社のJames Lewis氏が、2012年にポーランドのクラクフで開催されたJava言語のカンファレンス「33rd Degree Conference」にて、“Micro services - Java, the Unix Way” という題で自社のケーススタディとして発表しました。
Microservices』を執筆しました。この記事はマイクロサービスに関する資料として、多くの開発者がエンタープライスソフトウェア開発における指針として参考にするようになりました。
マイクロサービスとモノリシックサービス
マイクロサービスとはどのような仕組みのアーキテクチャなのか、従来のアプリケーションと比較してみましょう。下図の右がマイクロサービス、左が従来型のモノリシックなアプリケーションです。
マイクロサービスとモノリシックサービス
ここで言うモノリシックなアプリケーションとは、エンタープライズ向けのアプリケーションサーバ実装やフレームワークを用いた階層型のマルチティアアーキテクチャを指します。エンタープライズの大規模企業システム向けJava実装であったJ2EEとJavaEEは、この十数年の間、JBoss、WebSphere、WebLogic、GlassFishのような、アプリケーション統合基盤上に展開・実装されてきました。
このようなマルチティアアーキテクチャの特徴は次のとおりです。
- 同一のプログラミング言語
- 単一のプロセス
- プログラミング言語の機能を利用して、クラス、メソッド、名前空間の分離で管理
- テスト環境を用意して慎重にテストを行う
- デプロイメントは一括で行う
- サーバ単位のスケールアウト
マルチティアアーキテクチャのアプリケーション構成
上図の用語の補足ですが、“境界付けられたコンテキスト”とは、ドメイン駆動設計（DDD）の用語で、論理的に作られたグループであるドメインの境界を指すものです。やや乱暴な例えですが、分かりやすくイメージするために、大きな企業組織の各部門を想像してみてください。この場合における“境界付けられたコンテキスト”は各部門のアプリケーションのデータを管理するモデルを指します。
では、マイクロサービスアーキテクチャの場合はどうでしょうか。特徴を以下に挙げてみます。
- アプリケーションを小さな複数のサービスの結合によって構成
- 各サービスは異なるプログラミング言語で良い
- 各サービスは異なるストレージ技術で良い
- 各サービスは独立してデプロイメントが可能
- HTTPを用いた軽量なWeb APIで通信を行う
- 各サービスは独立してスケールアウトが可能
- 各サービスはシンプルであるためDevOpsによる自動化が可能
- パフォーマンス、ログ、例外処理などはAPIゲートウェイで集約管理
マイクロサービスアーキテクチャ
マイクロサービスは、従来1つのフレームワークとライブラリで開発されていたモノリシック（一枚岩）なソフトウェアを、RESTなどのシンプルなWeb APIを用いて業務単位に分割してコンポーネント化し、Web APIのサービス同士を結合することで全体のプロダクトサービスを構成しようとする設計です。また、ストレージもデータの性質に合わせて適材適所で選択することになります。
