Azureでのマイクロサービスのインフラ選定
ドメインモデルができたら、次に、各ドメインに対応するマイクロサービスをマッピングし、各マイクロサービスのクラウド機能を設計していく。
マイクロサービスの設計フロー。ドメインモデルができたら次はサービスマッピング
マイクロサービスの実装において、「必ずではないが」（成本氏）、コンテナー化するメリットは大きい。各マイクロサービスをコンテナーイメージとして配布し、レジストリを経由してホスティング環境に手軽にデプロイできるためだ。
Azureでは、コンテナーオーケストレーターとして、Kubernetes、Docker Swarm、DC/OS、Azure Service Fabricが選択肢になる（Kubernetes、Docker Swarm、DC/OSはのクラスター管理をマスターノードで行う、Service Fabricはマスターノードとクライアントノードを区別しない）。Azure上でのマイクロサービスの設計では、市場シェアが大きいKubernetesか、.NETのツールと親和性が高いService Fabricのどちらかを推奨している。
Azureでのコンテナーオーケストレーターの選択肢
マイクロサービスを運用するコンピュートの選択肢には、ACS Engineを利用する「Azure Container Service（ACS）」、マネージドのKubernetesサービス「Azure Container Service（AKS）」、秒課金で使えるコンテナーサービス「Azure Container Instance（ACI）」、前述のAzure Service Fabric、FaaSの「Azure Functions」がある。「ACSは間もなくAKSになる。ACIは専用VMのインスタンスを持たずにコンテナーを直接管理するサービスだが、Kubernetesのフル機能がない。簡単に使いたい場合はACI、プロダクトで使うならAKS」（成本氏）。また、Service Fabricは.NETの世界でやりたい人向け、Azure FunctionsはイベントドリブンのFaaSで実装できる簡単な処理の選択肢になる。
Azureでのコンテナーインフラの選択肢
マイクロサービスではすべてをコンテナー化する必要はないが、ただし、AKSとAzure Functionsを組み合わせたアプリケーションの場合、AKSのサービス間連携は同一のクラスターで行われているのに対して、AKSとFunctionsの連携はクラスター外で行われる。「クラスター外通信が多いとレイテンシで損をする」（成本氏）。
ワークフロー管理、サービスメッシュの選定
マイクロサービスでは、各サービスを連携して動作させるワークフロー管理、サービス間通信も重要な要素になる。Azureでのマイクロサービスのワークフロー管理ツールとしては、「Logic Apps」、Azure Service Fabricのほか、マイクロソフトリサーチがオープンソース化した「Orleans」、オープンソースの「Akka」などが選択肢になる。成本氏が作成したドローン配送サービスのシナリオでは、「毎秒1万リクエストを管理する仕様を想定したため」（成本氏）、Akkaを採用している。ほとんどのケースではそこまで必要なく、ノンコーディングで使えるLogic Appsでも十分対応できるという。
Azureでのワークフロー管理ツールの選択肢
サービス間通信は、プロトコルをどうするか、サービス更新直後の他サービスとの連携はどうするか（どうマイグレートするか）、呼び出し先のサービスが応答しなかったときにリトライ（サーキットブレイキング）する仕組みをどうするかといった検討が必要になる。このような、サービス間通信のモニタリングと制御の処理に担うのがサービスメッシュと呼ばれるテクノロジーであり、Kubernetesの機能に内包されているほか、オープンソースの「Istio」や「Linkerd」などもサービスメッシュの機能を提供する。ドローン配送システムのシナリオでは、各サービスを検証したところIstioが遅かったためLinkerdを採用している。
Azureでのサービスメッシュの選択肢
以上のようなサービス選定をした結果のアーキテクチャが次のとおりだ。
ドローン配送サービスのマイクロサービスアプリケーションアーキテクチャ
ACS（まもなくAKSへ移行）のKubernetesクラスター上に、コアとなる「デリバリースケジューラー」のマイクロサービス、スケジューラーに呼び出される5つのマイクロサービスが実装されている。さらに、宅配完了などのイベントをトリガーにメール配信や課金を行うマイクロサービスをAzure Functionsに実装しており、計7つのマイクロサービスで1つのドローン配送アプリケーションを構成している。
デリバリースケジューラーは、Azure Event HubsとAkkaで構成される。アプリケーションは毎秒1万リクエストをコンスタントに処理する設計になっているが、ピーク時には10万リクエストを受け付ける想定になっている。「1万リクエストを超過した分はEvent Hubsにバッファとしてためておく。AkkaがEvent Hubsからの呼び出しの速度を落としてくれる」（成本氏）。
また、このアプリケーションでは、デリバリースケジューラーからの1トランザクションでバックエンドの5つのサービスを呼び出す処理を行う。「5つのサービスの呼び出しののうち1つでも失敗したらどうするか、マイクロサービスではこの仕組みを必ず実装しておかなければいけない」（成本氏）。ここではバックエンドを呼び出すトランザクションをAzure Service Busに入れておき、失敗した際のリトライ、連続リトライに失敗したらキャンセルするなどの処理を行っている。
＊ ＊ ＊
Azureアーキテクチャセンターには、今回紹介したマイクロサービスの設計パターンのほかにも、Azureを初めて導入検討する初心者向けの導入ガイドから、マイクロサービスを含む各種アプリケーションアーキテクチャガイド、データアーキテクチャガイド、コンピューティングとデータストアーの選択を助ける情報、AWSプロフェッショナルのためのAzureガイドなど、入門から応用まで幅広い情報が掲載されている。間もなく、成本氏の新作としてIoTの設計パターンが公開されるそうだ。
