マイクロソフトは、Microsoft Azureでシステムを構築するためのクラウド設計パターン、アプリケーションアーキテクチャガイド、リファレンスアーキテクチャを「Azureアーキテクチャセンター」のサイトで公開している。これらのパターンやガイドは、米マイクロソフトのAzureエンジニアが実際に検証した上で構成サービス/ソフトを選定し、ユーザーにとって失敗が少なく汎用性の高いベストプラクティスをまとめたもので、現在、32の設計パターンと100以上のガイドを公開している。
日本マイクロソフトが2018年3月30日に開催したクラウドアーキテクト/開発者向けセミナー「パターン＆プラクティスセミナー」に、Azureアーキテクチャセンターのクラウド設計パターンを作成している米マイクロソフト AzureCAT patterns & practicesチームの成本正史氏が登壇。自身が作成した「マイクロサービス」のクラウド設計パターンについて、アーキテクチャや設計思想、サービス選定理由などを解説した。
成本氏が作成したマイクロサービスのクラウド設計パターンでは、顧客が荷物の集荷と配送のスケジュールを設定できる「ドローン配送サービス」のアプリケーションを、Azure Container Service（ACS）のKubernetesで管理するコンテナー上に、7つのマイクロサービスで実装している（アプリケーションのリファレンス実装はGitHubに公開されている）。
米マイクロソフト AzureCAT patterns & practicesチームの成本正史氏
マイクロサービスとは何か？
まず、「マイクロサービス」とは何か。従来型のモノリシックなアーキテクチャでは、UI/API、ビジネスロジック、データアクセス、データベースのレイヤーが水平に構築されていたのに対して、マイクロサービスは、「ビジネスファンクションごとに、UI/API、ビジネスロジック、データアクセス、データベースを垂直に切り出したもの」（成本氏）だ。
世の中にはマイクロサービスと呼ばれるものが様々あるが、「例えば、データアクセスの機能のみを水平に切り出したものはマイクロサービスとは言えない。重要なのは、1つのマイクロサービスで、1つのビジネスファンクションが完結すること。UIからプライベートデータベースまで全部もっているものがマイクロサービスだ」と成本氏は説明した。
マイクロサービスとは
メリットより課題のほうが多い
マイクロサービスどうしは、データスキーマ、メッセージスキーマ、シグネチャ、ライブラリやフレームワークのバージョン、共有コンポーネントの依存が起こらず、マイクロサービス単位で頻繁な更新をかけることが可能になる---。1つの機能がダウンしてもほかの機能に影響しない、呼び出し先のサービスがダウンしても呼び出し元のサービスはダウンしない---。1つのアプリケーション内で言語を統一する必要がなくなり、機能ごと（マイクロサービスごと）に可用性の管理ができる---。これらがマイクロサービスのゴールだが、「これらは自動で達成されるものではなく、ゴールを目指してきちんと設計する必要がある」（成本氏）。
現時点では、「マイクロサービスはメリットより課題のほうが多い」と成本氏は言う。主な課題には、サービス間通信が複雑化すること、各サービスが独自のデータベースを持つのでサービス間でデータの一貫性がなくなること、アプリケーション全体の可用性が高まるとは限らないこと（１つのサービスの挙動が悪くなると全体に影響するケースもある、原因究明のために分散トレーシングを実装する必要がある）、統合テストが大変になることなどが挙げられる。「こういう課題を克服して、はじめてマイクロサービスを利用できる。分散システムに詳しくないと失敗する」（成本氏）。
マイクロサービスの価値
マイクロサービスの課題
さらに、組織にDevOpsのカルチャーが醸成されていないと、せっかくマイクロサービスを実装しても意味がない。機能単位で頻繁なリリースが可能になるのがマイクロサービスだが、組織でリリースパイプラインが整っていなければそのメリットは享受できない。「マイクロサービスと、DevOpsのCI/CDはセットと考えることが重要」（成本氏）。
メリットより課題のほうが多いというマイクロサービスだが、チャレンジに成功した企業はビジネスで大きな成功を抑えめていたりする。例えばUberやNetflixは、ユーザーアプリケーションのインタフェースのABテストを1日何十回も実施して、新規顧客獲得、顧客満足度の向上につなげている。これはモノリシックなシステムでは無理な施策だ。
DDDでマイクロサービスの境界を設計
サービス間の依存がなく、サービスごとに頻繁な更新を可能にするマイクロサービスの“ゴール”を達成するためには、（1）すべてが分散されており、（2）ビジネスドメインを起点にサービスがモデリングされており、（3）各サービスが独立してデプロイでき、（4）サービス間でデータを共有していない---。この4つの原則を守って設計する必要があると成本氏は言う。
ここで、（2）の「ビジネスドメインを起点にサービスをモデリングする」のDDD（Domain Driven Design）の設計原則が、マイクロサービスの境界を決定する。「つまり、マイクロサービスはビジネスの言葉を使って、境界を決めていくもの」（成本氏）。
DDD（Domain Driven Design）
マイクロサービスの設計は、ビジネスドメインをラフスケッチし、ドメインモデルを描くことからスタートする。ドローン配送サービスのシナリオでは、「宅配」のドメインをコアに、「ユーザーID管理」、「ドローンの管理」などのアプリケーション全体を構成するドメインを書きだしていく。
ビジネスドメインをラフスケッチ
ドメインモデルを描く
ビジネスドメインとは、ドローン配送サービスの例では、「在庫管理」「オーダー管理」といった単位になる。「その領域内で同一の言語を話す単位（Bounded Context）。例えば、顧客管理において“顧客”が意味するものが同一である必要がある。“顧客”の意味が違う領域にサービスがまたがる場合は、Bounded Contextを分離する（別のマイクロサービスにする）ように」（成本氏）。
Bounded Contextのパターン（Building block）には、Value Object（ヒストリーを管理しない「配送先」「メールアドレス」「電話番号」など）、Entity（IDとIDに紐づく変更されるデータがあるもの）、Aggregate（Value ObjectとEntityの集合体、データ一貫性の境界を定義する）、Domain Services（ワークフローのように複数Aggregateにまたがるもの）などがある。マイクロサービスで重要なのはAggregateとDomain Servicesで、「Aggregateは、フィールドは一貫させながらデータの更新をするというもの。1つのAggregateでEntity（IDなど）は一貫している必要があり、Entityに紐づくデータの更新があった際は1つのAggregate内で一括更新される。つまりマイクロサービスそのもの」「Domain Servicesは、複数Aggregateにまたがるワークフローを管理するもの。ステートはAggregateがもつ」（成本氏）。
Building block
マイクロサービスの境界の決定は、Bounded Context（ビジネスでの言葉の意味が共通になる領域）を定義することから始めて、Building blockを分析して細分化していく作業になる。Building blockのパターンは、AggregateかDomain Servicesが選択肢になる。「Aggregateが正しく設計されていれば、マイクロサービスが正しく設計されていることになる。ここで、Aggregateのサイズが大きすぎるとデータをロードする遅延が無視できなくなる。逆に、サイズが小さすぎると、複数のAggregateに一貫していなければいけないデータが多く発生し無駄が多くなる」（成本氏）。マイクロサービスの粒度は、小さければよいというものではなく、最適なサイズを設計する必要がある。
業務やプロセスの単位で構築したサービスを組み合わせて大規模アプリケーションを構成するアーキテクチャに「SOA（サービス指向アーキテクチャ）」があるが、「SOAは再利用を目的としたもの。それに対してマイクロサービスは頻繁な更新を目的としたものであり、再利用はあまり考慮しない。ほぼ同じ処理を別のサービスどうしでやっていたり、そのような無駄も受け入れるのがマイクロサービス」と成本氏は説明した。
