マイクロサービスアーキテクチャで目指すもの

2014年にジェームス・ルイス（James Lewis）氏とマーチン・ファウラー（Martin Fowler）氏が提唱したマイクロサービスは、一時はバズワードと呼べるほどトレンド化しました。特にクラウドの世界ではデフォルトのアーキテクチャスタイルに位置付けられ、キャッチコピーとして雑誌／Webの記事やアナリストレポートにも登場し、近年では政府のシステム入札案件の要件としても見かけるようになってきました。筆者が執筆する連載「AWSで実践! 基盤構築・デプロイ自動化」の第1回でもマイクロサービスアプリケーションのメリットについて触れましたが、提唱された当初と比べて、マイクロサービスが実現を目指す領域は広がりつつあります。

従来、マイクロサービスでは、下図のような構成によって、以下に示すメリットが得られるアーキテクチャを目指してきました。

• 開発チームごとに分担した各サービスの疎結合性／独立性が向上し、開発のアジリティが向上する
• 使用頻度の高い特定の機能を、サービス単位でスケールできるため、アプリケーションパフォーマンスが向上する
• 独立したサービスの集合でアプリケーションが構成されるため、特定のサービスが障害などで機能不全に陥ってもシステム全体が機能不全に陥ることはなく可用性が向上する

近年では下図のように、Webアプリケーション、モバイル、運用端末といったマルチクライアントに加え、サードパーティサービスに利用されることを想定し、ビジネスロジックを切り出してAPI化したマイクロサービスアーキテクチャを検討する動きも目立ち始めています。

こうしたさまざまなサービスを組み合わせて新たな付加価値を付ける試みは、SOA(Service Oriented Architecture)やマッシュアップなど、マイクロサービスが提唱される以前からありました。しかし、サービス連携時のセキュリティ対策の複雑さや多数のクライアントが接続するための拡張性に難があるなど、広く普及させるには障害となる多くの問題を抱えていました。

近年このような潮流が再び巻き起こっているのは、クラウド化によってスケーラビリティが容易に確保できるようになったことや、OAuth2、OIDCなどの標準化されたセキュリティ技術の普及により、技術的なハードルが下がってきたことが背景にあります。

一方で、このようなマイクロサービスアーキテクチャでアプリケーションを構築するのは容易ではありません。サービス分離によるトランザクションの分割／通信エラーの発生や、データベースが分離された構成での一貫性担保の問題、揮発性のあるサーバ環境での永続化処理の実行、各サービス自体のスケーラビリティの確保、さまざまなクライアントから実行される場合の認証／認可といったセキュリティ対策など、アプリケーション実装も相応に複雑になります。

例えば、もともとモノリシックだったWebアプリケーションのドメインロジックを分離して、上記の図のようにBackend Service APIとして切り出した場合、以下のようなアーキテクチャ上の検討課題が浮上します。

こうしたなかで、AWSではマイクロサービスアーキテクチャベースのアプリケーション構築をサポートする以下のサービスが提供されています。

ただし、当然これらのサービスがマイクロサービスアーキテクチャにおける課題を全てカバーしてくれるわけではありません。必要に応じて、さまざまなオープンソースのプロダクトを組み合わせながらアプリケーションを構成／実装していく必要があります。

本連載では、AWSのマネージドサービスを駆使しながら、マイクロサービスのメリットを最大限享受できる、SpringBootをベースとしたアプリケーションアーキテクチャの実装例を紹介していきます。いまだにこの分野の技術は栄枯盛衰が激しく、各プロダクトの機能追加や新たなサービスの登場によってベストプラクティスは変わっていくので、AWSクラウド上での実装例の1つとして捉えていただくと良いと思います。

次回以降は、マイクロサービスアプリケーションを構築していく上で難しいハードルの一つである認証／認可処理について、その実現方法の全体像を解説します。