マイクロサービスアーキテクチャ（MSA）でなく、マイクロサービス（MSA）を使ったシステム「の」アーキテクチャ設計についてです。MSA自体がアーキテクチャスタイルの1つですが、そのMSAを採用して実際にどういうシステムのアーキテクチャを設計するのがいいのか、という話です。
この記事は、9/19（水）に行われたJapan Camel User Group主催の書籍『Camel in Action, 2nd Edition』読書会の参加メモです。今回だけは特別回で、海外からRed HatのエヴァンジェリストChristina Linが来てCamel on Cloudについて話をしてくれました。
当日の発表スライドはこちらです。
https://www.slideshare.net/ouobpo/camel-on-cloud-by-christina-lin
アジャイルAPIインテグレーション
大規模なシステムを作るときにシステム間のインテグレーションが必要になりますが、個々のシステム同士をn:nに繋ぐインテグレーション・スパゲッティを避けるために、従来ではESBを中心とするSOAアーキテクチャが推奨されていました。それに対し、MSAでは**"Smart endpoints and dumb pipes"（賢いエンドポイントと単純なパイプ）**というキャッチフレーズの元に個々のマイクロサービスが賢くインテグレーションするやり方に回帰しています。
こうした複雑なアーキテクチャを上手に構築するための指針として、Red HatはアジャイルAPIインテグレーション（Agile Integration）というアプローチを提唱しています。
https://jp-redhat.com/openeye_online/column/middleware-channel/6330/
アジャイルAPIインテグレーションは、「分散インテグレーション」「マイクロサービスコンテナ」「API」の3つの柱で構成されます。
分散インテグレーション（Distributed integration）
要するに"Smart endpoints, dumb pipes"のことなんですが、ESBのように中心にドンと大きなミドルウェアを置くのでなく、個々のマイクロサービスにインテグレーションロジックを分散させようということです。その際に重要なのは、（ESBでもそうですが）EIPパターンをベースにすることと、イベント駆動にして個々のマイクロサービスを疎結合にしようということです。個人的には、このイベント駆動が昔ながらのインテグレーション・スパゲッティ問題を解決する鍵だと思っています。
インテグレーションロジックにはApache Camel（Red Hat Fuse）、イベント駆動にはApache Kafka（Red Hat AMQ Streams）などが使えます。
マイクロサービスコンテナ（Microservices containers）
今となってはもう当たり前ですが、マイクロサービスのデプロイにはDockerなどのコンテナ技術、Kubernetesなどのコンテナプラットフォームを使おうね、ということです。
Red Hatの製品としては、Kubernetesの商用化であるOpenShiftプラットフォームが使えます。
API（APIs）
最後にマイクロサービスで作った機能をどうやって外部に提供するかという話ですが、SwaggerなどRESTベースのよく定義されたAPIとして公開しようということです。APIとして整理して公開しないと、無数のマイクロサービスを末端のクライアントアプリケーションが一々精査してそれらの機能を呼び出さないといけなくなります。この考え自体は、SOA時代のWSDLやUDDIでもあったじゃないかと思うかもしれませんが、ここではサービスを「作る側」よりクライアント／ユーザの「使う側」に重点が移っているのがポイントです。
Red Hatでは3scaleというAPI管理のプラットフォームが提供されています。
以上がアジャイルAPIインテグレーションの3つの柱です。私見ですが、この3つの指針がマイクロサービス時代の新しいACIDと言えるかもしれません。
では、実際にこの3つの柱でどういうアーキテクチャを設計すればいいのか、というのが次のトピックです。
マイクロサービスのアーキテクチャ
マイクロサービスの単位として、ピザ2枚分で賄える規模のチームで1つのマイクロサービスを開発・運用する、などと言われます。その位の規模のチームで1つのドメイン言語の整合性を取ることができ、DDDで言うところの「境界づけられたコンテキスト」＝1マイクロサービスが維持されます。
しかし、実際にはユーザに1つの機能を提供するにも複数のマイクロサービスが連携する必要があり、クロスバウンダリなマイクロサービスをどう位置づけるかといった問題が出てきます。
そこで推奨されるのが、マイクロサービスを次の3層に分けるアーキテクチャです。
- ネットワークゲートウェイ層（Network Gateway Layer）
- コンポジット層（Composite Layer）
- コア層（Core Layer）
クライアントと直接やり取りするネットワークゲートウェイ層は、アクセス制限やプロキシなどの処理を行う層です。中間のコンポジット層がクロスバウンダリなマイクロサービスを扱う層で、ここでApache Camel（Red Hat Fuse）などを使ったインテグレーション専用のマイクロサービスが活躍します。最後にコア層は基本的な最小単位の機能／ビジネスロジックを提供するマイクロサービスが置かれる層です。
Netflixなどマイクロサービスの先進企業では数百ものマイクロサービスが動いているそうですが、個々の機能がどのマイクロサービス群の協調によって提供されているかを可視化すると、このような3層の構造が見えるそうです。
実際に自社でもマイクロサービスを導入しようと検討している企業は、この（新しい）3層アーキテクチャが参考になるでしょう。