Java、Scala用マイクロサービスフレームワーク「Lagom」でシンプルなAPI実装：リアクティブプログラミング超入門（4）（1/2 ページ）
本連載では、リアクティブプログラミング（RP）の概要や、それに関連する技術、RPでアプリを作成するための手法について解説します。今回は、マイクロサービス向けフレームワーク「Lagom」について解説します。
リアクティブプログラミング（RP）の概要や、それに関連する技術、RPでアプリを作成するための手法について解説する本連載「リアクティブプログラミング超入門」。前回の「リアクティブプログラミングにおけるPlay、Akka、Akka Streams」では、「Lightbend Platform」を構成するプロダクト、「Play framework」「Akka」「Akka Streams」を紹介しました。
今回はマイクロサービス向けフレームワーク「Lagom」について解説します。
なお、本稿のサンプルプログラムを動かしたい場合、連載第2回にセットアップ方法を記述してあるので、それを参考に環境を作成しておきましょう。
まずはマイクロサービスについて簡単に解説しておきます。
マイクロサービスとは（モノリシックとの違い）
マイクロサービス（マイクロサービスアーキテクチャ）とは、ThoughtWorks社のマーティン・ファウラー氏によって提唱された、複数の小さなサービスを組み合わせてアプリケーションを構築するアーキテクチャです。
また、マイクロサービスとは反対に、システム全体が単一のユニットとして構築されていることを「モノリシック（一枚岩）」と呼びます。
例えば、従来のよくあるWebアプリを考えてみましょう。一般的なWebアプリは、下記の3要素で構成されます。
- ユーザーインタフェース（HTMLやクライアントサイドのJavaScript）
- サーバサイドのアプリ
- データベース（RDBMSやKVSなどのデータストア）
クライアントから送られたHTTPリクエストをサーバサイドで受け取り、ロジックを実行してデータストアとデータのやりとりをします。データストアから取得したデータをパースし、HTMLのビューを作成します。この一連の処理を、全て同じサーバインスタンス上で行います。こういったシステムがモノリシックなアプリです。
このアプリの場合、システムの規模が大きくなればロードバランサーを使用して複数のサーバインスタンスを動かすことでスケール可能です。また、このシステムのどこかに修正を行う場合には新しいバージョンのアプリをサーバにデプロイする必要があるでしょう。
こういったこと自体は普通のことですが、アプリの変更（デプロイ）が頻繁に行われる場合、どんな小さな変更だとしてもシステム全体のビルドとデプロイが必要になります。
アプリが大きくなるに従ってモジュール構造は複雑化し、一部の機能だけが大きなリソースを必要とする場合でも、システム全体のスケールが必要になってしまいます。
こういった問題点を解消するためのアーキテクチャが、マイクロサービスです。マイクロサービスは、巨大なシステムを独立した小さいサービスに分割することで「保守性やメンテナンス性を高める」「開発速度を速める」というメリットがあります。先述した「一部機能が大きなリソースを必要とする場合」でも、対象のサービスだけをスケールすることができます。
マイクロサービスの構造と特徴
マイクロサービスの特徴をもう少し具体的に見てみましょう。
上記のシステム例では、各機能を独立したサービスとして構築しています。各サービス同士は、RESTなどの方法で連携可能ですが、基本的に他のサービスの変更や状態に依存せず、それぞれが独立して動作します。
こういった構造になっているため、マイクロサービスには下記のような特徴があります。
・各サービスが他のサービスに影響せずスケールやデプロイが可能
マイクロサービスでは、アプリケーションを小さなサービスとして実装し、サービスはそれぞれのプロセス上で独立して動き、データストアもそれぞれ持つことが多くなっています（※複数のマイクロサービスが同一のデータストアを参照するのはあまり良くないとされています）。そのため、サービスごとに適したサイズでスケールしたり、デプロイしたりすることが可能です。
・サービス同士が疎結合になる
先述したように、サービス同士を連携させる場合には、RESTやAMQPなどの非同期処理で軽量な方法を使うことが多いです。こうすることで、システム同士の依存が簡素化し、変化に強くなります。
・各サービスのアーキテクチャや開発言語、運用方法なども統一する必要がない
各サービスが独立して動き、サービス同士の連携もRESTで行う場合は、そもそも同じ言語、構造で実装する必要がありません。サービスの要件や運用方法に応じて適切な技術を採用することが可能になります。
以上のような特徴からも分かりますが、今までのモノリシックなアプリへのアンチテーゼとして、マイクロサービスが注目されている部分もあると思います。マイクロサービスは単一の責務で構成されるため、エンジニアはサービスごとに小さなチームで、素早く開発を進めることができるでしょう。
実際にマイクロサービスは、スタートアップでの採用が進んでおり、「なるべく早くリリースする」「必要に応じてサービスをスケールしていく」という、スタートアップの要望にも比較的応じやすいのではないでしょうか。
なお、有名どころだとNetflixやAmazon、日本ではクックパッドなどが、数年前からマイクロサービスを採用しています。
マイクロサービスとリアクティブシステム
では、マイクロサービスとリアクティブシステムは、どのような関係になっているのでしょうか。
以前リアクティブシステムについては、「即応性」「耐障害性」「弾力性」「メッセージ駆動」を備えているシステムと解説しました。
マイクロサービスも、モジュールが疎結合であったり、非同期なメッセージ駆動であったりといった特徴を持っています。ここから分かるように、マイクロサービスとして設計されたシステムは、リアクティブシステムの特徴を持っているといえるでしょう。
ただし、リアクティブ化するということは分散システムになって、可用性が下がったり、ネットワーク間のレイテンシの問題が生じたりする可能性があります。この問題に対してアプリ側で対応する方法の1つが、マイクロサービスフレームワーク「Lagom」です。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
Java EE 8/9はマイクロサービス、リアクティブに向かう――MVCは生き残れるのか
デジタルトランスフォーメーション時代に生き残れるエンジニアに求められるものとは何か。長らく、日本のJavaコミュニティで存在感を示し続け、現在は日本マイクロソフトでJavaエバンジェリストとして活動する寺田佳央氏に聞いた。
EJB、SOA、マイクロサービスへと至る大規模システム向けアーキテクチャの変遷
2000年前後からのアプリケーションアーキテクチャやEJB、SOAに触れながら、今後、大規模システム構築で主流になるであろう「マイクロサービス」アーキテクチャの意義と価値を考える。