クラウドネイティブ技術を使用したマイクロサービスアーキテクチャの設計例¶

1 はじめに¶

この文章は、『Kubernetesで実践する Platform Engineering』の補章 (クラウドネイティブ技術とマイクロサービスアーキテクチャのつながり) を新しく改訂したものです。

https://www.amazon.co.jp/dp/4798188379

著者のMauricio Salatino氏はマイクロサービスアーキテクチャのアプリケーションを稼働させるクラウドネイティブ技術に着目し、その実践方法を解説してくれました。

クラウドネイティブ技術とマイクロサービスアーキテクチャは相互に影響を与えながら進歩してきた分野です。

CNCFはクラウドネイティブ技術を次のように定義づけており、この技術がマイクロサービスアーキテクチャの構築と実行に適していることがわかります *1 。

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。

このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャー、および宣言型APIがあります。

本書の各章では、以下のように言及しています。

1〜2章：マイクロサービスアーキテクチャのアプリケーションの特徴
3〜4章：CI/CDによるアプリケーションのユーザー提供
5～6章：インフラストラクチャーとプラットフォームの作成
7章：APIによるプラットフォーム機能の開発者提供
8章：さまざまなリリース戦略の活用
9章：パフォーマンスの測定

補章では、マイクロサービスアーキテクチャをさらに深掘りし、マイクロサービスアーキテクチャとクラウドネイティブとの関係性を重点的に取り上げます。

まずは、マイクロサービスアーキテクチャのデザインパターンを取り上げます。

そして、各デザインパターンがどのようなクラウドネイティブ技術で代替できるのかを概説します。

私が現場で見てきた実際のマイクロサービスアーキテクチャの設計、関連書籍、本書のウォーキングスケルトン (1〜2章) などに基づいて、クラウドネイティブ技術を使用したマイクロサービスアーキテクチャの設計例を図で示します。

注釈

*1 https://github.com/cncf/toc/blob/main/DEFINITION.md

2 歴史¶

2.1 クラウドネイティブ技術¶

CNCFの定義のとおり、クラウドネイティブ技術はパブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどでスケーラブルなアプリケーションを実現します。

これまでにAWSなどのパブリッククラウド、Kubernetes、そしてKubernetesを基盤としたクラウドネイティブ技術が登場しました *1 。

表1で代表的なクラウドネイティブ技術の歴史を整理します。

2024年の執筆時点で約20分野のクラウドネイティブ技術が登場しており、今後も増え続けていくでしょう。

表1. クラウドネイティブ技術に関連する歴史

年代	技術	説明
2004-2006	AWS	AmazonはクラウドサービスとしてSQSを公開した。その後、AWSはS3やEC2の提供も始めた *2 。
2008	Google Cloud	GoogleはクラウドサービスとしてApp Engineを公開した *3 。
2009	Heroku	HerokuはPaaSとしてHerokuを公開した *4 。
2010	Azure、OpenStack	MicrosoftはクラウドサービスとしてWindows Azureを公開した 5 。また、Rackspace HostingとNASAはユーザー独自のIaaSを構築できるOpenStackを公開した 6 。
2011	Cloud Foundry	VMwareはユーザー独自のPaaSを構築できるCloud Foundryを公開した *7 。
2013	Docker	dotCloudは仮想化技術としてコンテナを公開した *8 。
2014〜2015	Kubernetes	GoogleはコンテナオーケストレーションツールとしてKubernetesを発表した。またKubernetes v1.0のリリースに合わせて、GoogleとLinux FoundationがCNCFを設立した *9 。
2014〜	約20分野のクラウドネイティブ技術	CNCFでは約20分野に渡るクラウドネイティブ技術が登場した *10 。

注釈

*2 CNCF Overview 2024 (https://docs.google.com/presentation/d/1UGewu4MMYZobunfKr5sOGXsspcLOH_5XeCLyOHKh9LU/edit#slide=id.gc98d72cd14_1_2266)

*3 https://en.wikipedia.org/wiki/Amazon_Web_Services

*4 https://en.wikipedia.org/wiki/Google_Cloud_Platform

*5 https://en.wikipedia.org/wiki/Heroku

*6 https://en.wikipedia.org/wiki/Microsoft_Azure

*7 https://en.wikipedia.org/wiki/OpenStack

*8 https://en.wikipedia.org/wiki/Cloud_Foundry

*9 https://en.wikipedia.org/wiki/Docker_(software)

*10 https://en.wikipedia.org/wiki/Kubernetes

*11 分野の種類は補章3節の表3で取り上げています。最新の分野はCNCF Landscape (https://landscape.cncf.io/) を参照してください。

2.2 マイクロサービスアーキテクチャ¶

マイクロサービスアーキテクチャは、アプリケーションのビジネスロジックを複数の独立したサービスに分割し、アプリケーション全体をサービスの集合体として動作させる設計手法です。

マイクロサービスアーキテクチャに関連するアーキテクチャスタイルがいくつかあります *11 。

表2でマイクロサービスアーキテクチャに関連するアーキテクチャスタイルの歴史を整理します。

マイクロサービスアーキテクチャの登場前に、これの前身となるサービス指向アーキテクチャや後にマイクロサービスアーキテクチャに貢献するドメイン駆動設計 (ドメイン駆動設計) が登場しました。

また、マイクロサービスアーキテクチャ以降にはモジュラーモノリスアーキテクチャなどが登場しました。

マイクロサービスアーキテクチャ特有の問題を解決するために、さまざまなデザインパターンが提唱されています。

2.2 マイクロサービスアーキテクチャの歴史¶

◼︎ 1999年：モノリスアーキテクチャ¶

マイクロサービスアーキテクチャの登場前、1999年頃、アプリケーションはモノリスアーキテクチャで設計することが一般的でした *20 。

モノリスアーキテクチャでは、アプリケーションのすべてのロジックを単一のプロセスで稼働させ、また全体をリリースします。開発組織や対象ドメインが成長初期で小さい場合、機能ロジック追加やリリースは容易です。しかし、開発組織や対象ドメインが成長して大きくなると、機能ロジック追加やリリースによる影響範囲の大きさ、分業のしにくさ、技術スタックの部分最適化のしにくさなどの課題が生じ始めました。のちに提唱されるプレゼンテーションドメイン分離やマイクロサービスアーキテクチャでは、機能／非機能ロジックを細分化することを目指します。

◼︎ 1990年代後半〜2000年代前半：サービス指向アーキテクチャ¶

1900年代後半から2000年代前半頃、Michael BellやThomas Erlらがサービス指向アーキテクチャを提唱しました *21 。

サービス指向アーキテクチャでは、アプリケーションを『機能』の粒度で分割することで、モノリスアーキテクチャの課題を解決することを試みました。

ただ『機能』という粒度に明確な指針がありませんでした *22 。

そのため、概念としては提唱されていても一般化までには至りませんでした。

◼︎ 2003年：ドメイン駆動設計¶

2003年頃、Eric Evansはドメイン駆動設計を提唱しました *23 。ドメイン駆動設計はオブジェクト指向分析設計から派生した分析設計の方法の一種であり、オブジェクト指向分析設計のベタープラクティスを集めることで、機能ロジックのモデリングを強化しました。

◼︎ 2003年：プレゼンテーションドメイン分離¶

サービス指向アーキテクチャと同じ頃、Martin Fowlerはプレゼンテーションドメイン分離を提唱しました *24 。

プレゼンテーションドメイン分離では、ビジネスへの影響を抑えるため、バックエンド領域の機能ロジックから、ロジックの変更頻度の高いフロントエンドアプリケーションを切り離します。

◼︎ 2014年：マイクロサービスアーキテクチャ¶

2014年頃、Simon Brownは、モノリスアーキテクチャは時間経過とともに無秩序でつぎはぎだらけな『大きな泥団子』になり得ることを指摘しました *25 。

それと同じ頃、Martin FowlerとJames Lewisはマイクロサービスアーキテクチャを提唱しました *26 。

マイクロサービスアーキテクチャでは、サービス指向アーキテクチャにドメイン駆動設計の考え方を取り入れます。

ドメイン駆動設計には、集約や境界づけられたコンテキストといった高凝集と低結合の考え方があります。

これらをマイクロサービスの粒度として捉えることで、サービス指向アーキテクチャをより実践的な理論に昇華させました。

注釈

*12 Richards, M., & Ford, N. (2020). Fundamentals of software Architecture: An Engineering Approach. O’Reilly Media.

*13 Wikipedia contributors. (2024). Monolithic application. Wikipedia. https://en.wikipedia.org/wiki/Monolithic_application

*14 Wikipedia contributors. (2024a). Service-oriented architecture. Wikipedia. https://en.wikipedia.org/wiki/Service-oriented_architecture

*15 Newman, S. (2021). Building microservices. O’Reilly Media, Inc.

*16 Evans, E. (2004). Domain-driven design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional.

*17 Lewis, J. (n.d.). Microservices. http://martinfowler.com/. https://martinfowler.com/articles/microservices.html

*18 Fowler, M. (n.d.). bliki: Brown, S. (2014). Distributed big balls of mud. http://dzone.com/. https://dzone.com/articles/distributed-big-balls-mud

*19 Brown, S. (2014). Fowler, M. (n.d.). bliki: Monolith First. http://martinfowler.com/. https://martinfowler.com/bliki/ MonolithFirst.html

*20 Richards, M., & Ford, N. (2020). 『Fundamentals of software Architecture: An Engineering Approach』 O'Reilly Media.

*21 Wikipedia contributors. (2024). Monolithic application. Wikipedia. https://en.wikipedia.org/wiki/Monolithic_application

*22 Wikipedia contributors. (2024a). Service-oriented architecture. Wikipedia. https://en.wikipedia.org/wiki/Service-oriented_architecture

*23 Newman, S. (2021). 『Building microservices』 O'Reilly Media, Inc.

*24 Evans, E. (2004). 『Domain-driven design: Tackling Complexity in the Heart of Software』 Addison-Wesley Professional.

*25 Fowler, M. (n.d.). bliki: Presentation Domain Separation. martinfowler.com. https://martinfowler.com/bliki/PresentationDomainSeparation.html

*26 Lewis, J. (n.d.). Microservices. http://martinfowler.com/. https://martinfowler.com/articles/microservices.html

3 マイクロサービスアーキテクチャに関連のあるクラウドネイティブ技術¶

CNCFでは、オープンソースやクラウドプロバイダーのクラウドネイティブ技術をさまざまな分野に分類しています *27 。

各分野には、マイクロサービスアーキテクチャに関連のあるクラウドネイティブ技術が多くあります。

表3でそれらを一覧で示します *28 。

表ではCNCF Landscapeにある定義を参考して、各分野のマイクロサービスとの関連性を説明します。

1.1節では、クラウドプロバイダーの使用に言及しています。

ここではクラウドプロバイダーのマネージドサービスを使用することにより、ビジネスアジリティの向上、低レイヤーの運用コストの軽減などの利点があると主張しています。

補章では、2024年の執筆時点で特に人気の高いクラウドプロバイダーのAWSを主な例に挙げ、これのマネージドサービスを取り上げます。

表3. マイクロサービスアーキテクチャに関連のあるクラウドネイティブ技術例の一覧

分野	マイクロサービスとの関連性	代表的なオープンソース	代表的なマネージドサービス
API Gateway (APIゲートウェイ)	マイクロサービスのAPIのコールに必要な汎用的機能を集中管理する。	・Kong Gateway	・AWS (API Gateway)
Application Definition & Image Build (アプリケーション定義とイメージ構築)	コンテナイメージからマイクロサービスを構築し、またデプロイする。	・Docker Compose ・Helm ・OpenAPI ・Packer
Automation & Configuration (自動化と設定)	マイクロサービスのインフラストラクチャーのプロビジョニングを自動化する。	・Ansible ・Temporal ・Terraform	・AWS (CloudFormation)
Chaos Engineering (カオスエンジニアリング)	システムの全体や一部に障害を注入し、システムの回復力をテストする。	・ChaosMesh ・Istio	・AWS (Fault Injection Simulator)
Cloud Native Network (クラウドネイティブネットワーク)	マイクロサービスがほかと通信するためのネットワークを作成する。	・Cilium CNI	・AWS (VPC CNI)
Cloud Native Storage (クラウドネイティブストレージ)	ファイルストレージ、オブジェクトストレージ、ブロックストレージなどとして各種データを保管する。	・Ceph ・Longhorn	・AWS (EBS、S3)
Coordination & Service Discovery (調整とサービス検出)	各マイクロサービスがお互いに場所を特定できるようにする。	・CoreDNS ・Etcd	・AWS (ECS Service Connect)
Container Registry (コンテナレジストリー)	コンテナイメージの保管や提供などを集中管理する。	・Harbor	・AWS (ECR) ・Docker Hub
Container Runtime (コンテナランタイム)	コンテナ内のアプリケーションを実行し、またハードウェアリソース (例えばCPU、ストレージ、メモリなど) を提供する。	・Containerd
Continuous Integration & Delivery (継続的インテグレーションとデリバリー)	マイクロサービスの構築からデプロイまでに必要なタスクを自動化する。	・ArgoCD ・Dagger ・Flux ・Tekton	・GitHub Actions
Continuous Optimization (継続的最適化)	CNCFに定義の記載なし。	・Karpenter ・OpenCost	・AWS (Cost Explorer)
Database (データベース)	RDBやNo SQL DBとしてマイクロサービスがデータを保管し、また取得できるようにする。	・MySQL・Redis	・AWS (Aurora MySQL、ElastiCache)
Feature Flagging (機能フラグ)	CNCF Landscapeに定義の記載なし。	・OpenFeature	・AWS (AppConfig)
Key Management (キー管理)	暗号化キーの作成、保管、そしてローテションを集中管理する。	・Spire	・AWS (KMS)
Observability (オブザーバビリティー)	さまざまなテレメトリーデータの作成、収集、保管、分析、可視化を実施する。	・Fluentd／FluentBit ・Grafana (Grafana、Loki、Mimir、Tempo) ・Kiali ・OpenTelemetry (クライアントSDK、OpenTelemetry Collector) ・Prometheus	・AWS (CloudWatch Logs、CloudWatch Metrics、X-Ray)
Platform (プラットフォーム)	クラウドネイティブの各分野のツールを一括で提供する。	・KinD・Minikube ・Rancher	・AWS (EKS、Lambda)
Remote Procedure Call (リモートプロシージャコール)	マイクロサービスがほかのマイクロサービスにリクエストを送信できるようにする。	・gRPC
Scheduling & Orchestration (スケジューリングとオーケストレーション)	クラスター全体でコンテナを実行し、また管理する。	・Knative ・Kubernetes	・AWS (ECS)
Security & Compliance (セキュリティとコンプライアンス)	脆弱性を監視して脆弱性を検出する。また、マイクロサービスの認証認可を強化する。	・Cert Manager ・Falco ・Keycloak ・OAuth2 Proxy ・SOPS	・AWS (Certificate Manager、Cognito、Secrets Manager)
Service Mesh (サービスメッシュ)	各マイクロサービスのロジックを変更することなく、マイクロサービス間の通信に信頼性、オブザーバビリティー、セキュリティ機能などを一律的に追加する。	・Istio ・Linkerd	・AWS (VPC Lattice、ECS Service Connect)
Service Proxy (サービスプロキシ) *29	マイクロサービスからの送信されたリクエストを中継し、ほかのマイクロサービスにフォワーディングする。	・Envoy ・Nginx	・AWS (ALB)
Streaming & Messaging (ストリーミングとメッセージング)	パブリッシャーから送信されたメッセージを中継し、他のサブスクライバーにフォワーディングする。	・Apache Kafka ・CloudEvents ・RabbitMQ	・AWS (Kinesis、SQS)

注釈

*27 CNCFはクラウドネイティブ技術の属する分類をしばしば変更します。最新の分類はCNCF Landscape (https://landscape.cncf.io/) を参照してください。

*28 クラウドネイティブ技術には、人気があってもCNCF未登録または分野未分類なものがあります。今回、登録済や分類済の技術を、便宜上、競合技術と同じ分野に記載しています。

*29 Service Proxy分野のツールは設定次第でAPI Gateway分野のツールと同等に使用できます。

4 マイクロサービスアーキテクチャの構成領域¶

4.1 マイクロサービスアーキテクチャとは¶

まず、マイクロサービスアーキテクチャはどのような領域からなるのでしょうか？

図1と表3でモノリスアーキテクチャ、プレゼンテーションドメイン分離 (過渡的なアーキテクチャ) *30 、マイクロサービスアーキテクチャの例を示しそれぞれの領域を簡単に比較します。

モノリスアーキテクチャからマイクロサービスアーキテクチャに至るまでに、領域が細分化されていきます。

図2. マイクロサービスアーキテクチャに至るまでのアーキテクチャの変遷

4.2 関連アーキテクチャの構成領域の比較¶

サンプルアプリケーションはマイクロサービスアーキテクチャのため、ここでマイクロサービスアーキテクチャの構成領域を解説します。

モノリスアーキテクチャ、プレゼンテーションドメイン分離、マイクロサービスアーキテクチャを簡単に比較します。

いずれのアーキテクチャも、アプリケーションと各種ストレージ（ブロックストレージ、キーバリューストレージ、オブジェクトストレージ、ファイルストレージ）で構成されています。

データベースとしてのRDBはブロックストレージに属しています。モノリスアーキテクチャ、プレゼンテーションドメイン分離、マイクロサービスアーキテクチャの比較を次の表のとおりに整理しました。

表4. マイクロサービスアーキテクチャに至るまでのアーキテクチャ間の比較

	モノリスアーキテクチャ	プレゼンテーションドメイン分離	マイクロサービスアーキテクチャ
プロセスの単位	・アプリケーション全体・各種ストレージ	・フロントエンドアプリケーション・バックエンドアプリケーション・各種ストレージ	・フロントエンドアプリケーション・APIゲートウェイ（任意）・マイクロサービス・各種ストレージ
機能ロジックリリースの単位	アプリケーション全体	バックエンドアプリケーション	各マイクロサービス
各種ストレージの単位	アプリケーション全体に１つずつ	アプリケーション全体に１つずつ	各マイクロサービスに１つずつ、またはアプリケーション全体に１つずつ

4.3 モノリスアーキテクチャ¶

モノリスアーキテクチャでは、アプリケーションはフロントエンド領域とバックエンド領域で構成されています。

フロントエンド領域とバックエンド領域の領域は密結合になっており、両方は同じプロセスで稼働します。

そのため、モノリスアーキテクチャのアプリケーションのバックエンド領域の一部に機能ロジックを変更する場合、アプリケーション全体をリリースする必要があります。

4.4 プレゼンテーションドメイン分離¶

次にプレゼンテーションドメイン分離では、アプリケーションはフロントエンドアプリケーションとバックエンドアプリケーションで構成されています。

モノリスアーキテクチャと比較して、アプリケーションがフロントエンドアプリケーションとバックエンドアプリケーションに分割されており、両方は異なるプロセスで稼働します。

担当者は、これらを独立してリリースできます。ただし、プレゼンテーションドメイン分離のアプリケーションに機能ロジックを変更する場合、担当者はバックエンドアプリケーション全体をリリースする必要があります。

4.5 マイクロサービスアーキテクチャ¶

最後にマイクロサービスアーキテクチャでは、アプリケーションはフロントエンドアプリケーション、APIゲートウェイ（任意）、マイクロサービスで構成されています。

プレゼンテーションドメイン分離と比較して、　バックエンドがマイクロサービスに分割されており、バックエンドからAPIゲートウェイを切り離す場合があるかもしれません。

そして、これらはすべては異なるプロセスで稼働します。

マイクロサービスの粒度には、ドメイン駆動設計の高凝集と低結合な粒度（例：集約、境界づけられたコンテキスト）を取り入れることが適切です。

機能ロジックを変更する場合、マイクロサービス担当者はその機能ロジックをもつマイクロサービスだけをリリースします。

注釈

*30 Fowler, M. (n.d.). bliki: Presentation Domain Separation. http://martinfowler.com/. https://martinfowler.com/bliki/PresentationDomainSeparation.html

5 マイクロサービスアーキテクチャのデザインパターン¶

5.1 デザインパターンとクラウドネイティブ技術¶

マイクロサービスアーキテクチャでは技術的で組織的な特有の問題が起こります。

これを解決するために、マイクロサービスアーキテクチャの各領域でさまざまなデザインパターンが提唱されています 23~28 。

各領域のデザインパターンは、そのすべてや一部をクラウドネイティブ技術で代替できます。

図2でマイクロサービスアーキテクチャの領域とクラウドネイティブ技術の関連性を示します。

色が濃いほど関連性が強く、クラウドネイティブ技術で代替できることを表しています。

アプリケーションの領域では機能的なロジックは関連性が低い一方で、非機能的なものほど関連性が強いです。

そしてインフラストラクチャーは全般的に関連性が強いです。

図3. マイクロサービスアーキテクチャの領域とクラウドネイティブ技術の関連性

補章では、各領域でのさまざまなデザインパターンと具体的にいずれのクラウドネイティブ技術がデザインパターンに関連しているのかを概説します。

表3のオープンソースまたはマネージドサービス (主にAWS) を組み合わせ、マイクロサービスアーキテクチャの設計例を図で示します。

AWSの設計については、AWS Well-Architected Framework *29 を合わせて読んでいただくことをお奨めします。

なお、マイクロサービスアーキテクチャで安易にマネージドなクラウドネイティブ技術を使用するべきではないと私は考えています。

なぜなら1つ目の理由として、マネージドサービスによってはオープンソースと比べてユーザーの設定できるオプションが少ないことを挙げます。

機能または非機能によらず拡張性の求められる場合には、オプションの少なさが拡張性の足かせになります。

2つ目の理由として、マネージドサービスによってはアプリケーション領域とインフラストラクチャー領域の境界が曖昧なことを挙げます。

大きな開発組織になるほど、領域の境界の曖昧さによって開発組織で分業しにくくなっていきます。

これは結果的にビジネスのアジリティを低下させる可能性があります。

これらの理由からマイクロサービスアーキテクチャでは、マネージドサービスをオープンソースの代わりにどこまで使用すれば恩恵をより良く受けられるのかを見極める必要があります。

例えば、前述の2つの理由で、マイクロサービスのデプロイ方法 (表5を参照) はFaaSやPaaSといったサーバーレスではなく、コンテナ (もっと具体的に言うとKubernetes) がより適切であるという考えが私にはあります。

注釈

*31 A pattern language for microservices. (n.d.). http://microservices.io/. https://microservices.io/patterns/index.html

*32 Richardson, C. (2018). Microservices patterns: With examples in Java. Simon and Schuster.

*33 Newman, S. (2021). Building microservices. O’Reilly Media, Inc.

*34 Mezzalira, L. (2021). Building Micro-Frontends. O’Reilly Media, Inc.

*35 Siriwardena, P., & Dias, N. (2020). Microservices Security in action. Manning Publications.

*36 Ibryam, B., & Huss, R. (2023). Kubernetes patterns. O’Reilly Media, Inc.

*37 AWS Well-Architected Framework - AWS Well-Architected Framework. (n.d.). https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html

5.2 補章で取り上げるデザインパターングループ¶

補章では、さまざまな書籍 31~34 を参考にし、デザインパターンの分類を図式化しました。

前提として、対照的なデザインパターンをまとめたグループを『デザインパターングループ』と呼ぶことにします。

図3のように、マイクロサービスアーキテクチャを便宜上５つの問題領域に分け、その中にあるデザインパターングループとデザインパターンを取り上げます。

図4. 補章で取り上げるアーキテクチャの問題領域

flowchart LR

  アーキテクチャ領域([アーキテクチャ<br>領域]) --- 基点(( ))
  基点 --- APIゲートウェイ領域([APIゲートウェイ<br>領域])
  基点 --- マイクロサービス領域([マイクロサービス<br>領域])
  基点 --- ストレージ領域([ストレージ<br>領域])
  基点 --- 横断領域([横断<br>領域])
  基点 --- インフラストラクチャー領域([インフラストラクチャー<br>領域])

デザインパターングループは他にも多くあります。

表5で、取り上げられなかったデザインパターングループを含む全てのパターンを簡単に示します。

なお図2で示したように、非機能なロジックほどクラウドネイティブ技術と関連性が強く、クラウドネイティブ技術を使用して代替できます。

デザインパターングループを網羅的に学びたい読者はMicroservices.ioサイト 30 、Microservices patterns本 31 、Building Microservices本 32 、そしてBuilding Micro-Frontends本 33 を読んでいただくことをお薦めします。

表5. すべてのデザインパターンの一覧

問題領域	目的	デザインパターン名・：共存関係／：競合関係
フロントエンド	フロントエンドの分割	モノリスフロントエンド／マイクロフロントエンド
	レンダリングパターン	CSR／SSR／SSG／ISR
APIゲートウェイ	APIゲートウェイの分割	中央集約ゲートウェイ／BFF
マイクロサービス	マイクロサービス間の通信	・リクエスト−レスポンス・パブリッシュ/サブスクライブ
	マイクロサービスの分割	・ドメイン駆動設計に基づく境界・認証サービス・認可サービス・オーケストレーションサービス・外部API接続サービス・非同期処理に特化した機能サービス (例：メール／プッシュ通知の機能) ・リアルタイム処理に特化した機能サービス・永続データの機密度 (例：換金性の高い情報) ・永続データの所有組織の差異
	マイクロサービスの設計	・エンティティや値オブジェクトなどのドメイン駆動設計デザインパターン・レイヤードアーキテクチャやクリーンアーキテクチャなどのアプリケーションアーキテクチャ
	ドメインモデリング	ステートソーシング／イベントソーシング
	トランザクションの管理	オーケストレーションサーガ／コレオグラフィサーガ／２フェーズコミット
	認証	セッション／SSO／JWTとAPIゲートウェイの組み合わせ
	認可	中央集中管理／分散管理
ストレージ	永続データの分割管理	・DB per service／Shared DB ・Polyglot Persistence／Multi-model DB
	揮発性データの分割管理	中央集中管理／分散管理
	静的ファイルの分割管理	中央集中管理／分散管理
	分析用加工済データの分割管理	中央集中管理／分散管理
ネットワーク	L4/L7トラフィックの管理	・サービス検出・ロードバランシング
	証明書の認証方式	・非TLS (平文) ・サーバー認証・クライアント認証・相互TLS認証
テスト	ホワイトボックステスト	・ユニットテスト・サービステスト・コントラクトテスト・E2Eテスト
	ブラックボックステスト	・ロードテスト (負荷テスト) ・回帰テスト・フォールトインジェクションを含むカオスエンジニアリング
信頼性管理	各種インスタンスの回復	・ヘルスチェック・リトライ・タイムアウト・バルクヘッド・サーキットブレイカー・レートリミット
	各種インスタンスのスケーリング	・垂直スケーリング・水平スケーリング・インスタンスの希望数維持
デプロイメント	マイクロサービス実行環境	Serverless platforms／Multiple services instance per host／Service instance per VM／Service instance per container
	リリース	・インプレースデプロイメント・ローリングデプロイメント・カナリアリリース・ブルーグリーンデプロイメント
	CI/CD	CIOps／GitOps
	汎用的なロジックの配布	・Externalized configuration ・Microservice chassis ・サービステンプレート・サービスメッシュ
監視	テレメトリーの監視	中央集中管理／分散管理
	インシデントの対処	中央集中管理／分散管理
開発体制	開発組織の編成	Collective ownership／Strong ownership
	リポジトリの編成	モノレポ／ポリレポ

注釈

*38 A pattern language for microservices. (n.d.). http://microservices.io/. https://microservices.io/patterns/index.html

*39 Richardson, C. (2018). Microservices patterns: With examples in Java. Simon and Schuster.

*40 Newman, S. (2021). Building microservices. O’Reilly Media, Inc.

*41 Mezzalira, L. (2021). Building Micro-Frontends. O’Reilly Media, Inc.

5.3 凡例¶

図4で5章以降のデザインパターンの図の凡例を示します。

各図では丸ボックスをデザインパターングループ、四角ボックスをデザインパターンとして区別しています。

図5. デザインパターンの図の凡例

flowchart LR

  親グループ([親グループ]) --- 起点(( ))
  起点 ---- パターン1
  起点 --- 子グループ([子グループ])
  子グループ --- パターン2
  子グループ --- パターン3

6 APIゲートウェイ領域¶

APIゲートウェイ領域にはAPIゲートウェイを配置します。

マイクロサービスアーキテクチャでは、すべてのマイクロサービスのAPIをネットワークに公開する必要はありません。

APIゲートウェイを配置することにより、必要なマイクロサービスのAPIのみを公開して受信したリクエストを適切なマイクロサービスのAPIにルーティングできます。

図5で、APIゲートウェイ領域のデザインパターングループの種類を示します。

代表的なものにはAPIゲートウェイ分割方法があります。

図6. APIゲートウェイ領域のデザインパターングループの種類

flowchart LR

  APIゲートウェイ領域([APIゲートウェイ<br>領域]) ---- APIゲートウェイ分割方法([APIゲートウェイ<br>分割方法])

6.1 APIゲートウェイ分割方法¶

APIゲートウェイを適切な結合度と凝集度で分割することにより、開発を分業しやすくしAPIゲートウェイの拡張性や生産性を高められます。

図6で、APIゲートウェイ分割方法のデザインパターンの種類を示します。

代表的なものには中央集約ゲートウェイとBFFがあります。

図7. APIゲートウェイ分割方法のデザインパターンの種類

flowchart LR

  APIゲートウェイ分割方法([APIゲートウェイ<br>分割方法]) --- APIゲートウェイ分割方法の基点(( ))
  APIゲートウェイ分割方法の基点 --- 共有APIゲートウェイ[中央集約ゲートウェイ]
  APIゲートウェイ分割方法の基点 --- BFF

APIゲートウェイをクラウドネイティブ技術で代替できます。

表6でAPIゲートウェイ分割方法とクラウドネイティブ技術の関連性を整理します。

ここでは、技術用語のAPIゲートウェイとCNCFのAPI Gateway分野を区別しています。

表6. APIゲートウェイ分割方法とクラウドネイティブ技術の関連性

パターン名	中央集約ゲートウェイ	BFF
説明	各クライアントで共有するAPIゲートウェイを配置する。APIゲートウェイには、各クライアントからのすべてのリクエストを想定したエンドポイントを実装する。	クライアント別のAPIゲートウェイを配置する。APIゲートウェイには、特定のクライアントからのリクエストを想定したエンドポイントだけを実装する。
クラウドネイティブ技術との関連性	中央集約ゲートウェイとしてService Proxy、Service Mesh、API Gateway分野のツールを使用できる。	BFFとしてService Proxy、Service Mesh、API Gateway分野のツールを使用できる。
技術例	・Service Proxy (Nginx) ・Service Mesh (Istio)	・Service Proxy (Nginx) ・Service Mesh (Istio)

図7でBFFの配置例を示します。

BFFとしてService Proxy、Service Mesh、API Gateway分野のツールを使用できます。

例えば、NginxはAPIゲートウェイとして動作します *41 。

クライアント別 (PCブラウザSPA、スマホSPA、外部APIなど) にNginxを配置します。

各クライアントは対応するNginx (PCブラウザ用、スマホブラウザ用BFF、外部API用BFFなど) にリクエストを送信し、各Nginxは適切なマイクロサービスのAPIにこれをルーティングします。

APIゲートウェイとして使用できるツールはNginx以外にも非常に多くあります。

ただ、その中でもNginxは環境構築や設定の方法が簡単で扱いやすく、またこれらの情報をインターネットや書籍から見つけやすいため、私の好みのツールです。

なお、GraphQLサーバーをBFFとして使用する設計方法もあります。

この場合、フロントエンドや外部APIはGraphQLクライアントとして設計する必要があります。

図8. BFFの配置例

図8でAWS EKS上でのBFFの設計例を示します。

マイクロサービスアーキテクチャのAPIゲートウェイ領域には、図7と同様にクライアント別のNginxを配置します。

もしNginxでBFFとしての要件を満たせなくとも、Istioと組み合わせることにより足りない機能を補完できます。

なお、Istioの提供するIstio Ingress GatewayとIstio Egress Gatewayはメッシュゲートウェイと呼ばれ、APIゲートウェイと似た名前をもちます。

ただ、APIゲートウェイとは異なる役割を持ちます *42 。

図9. AWS EKS上でのBFFの設計例

注釈

*42 DeJonghe, D. (2022). NGINX Cookbook. O’Reilly Media, Inc.

*43 Gough, J., Bryant, D., & Auburn, M. (2021). Mastering API architecture. O’Reilly Media, Inc.

7 マイクロサービス領域¶

マイクロサービス領域には、適切に分割された複数のバックエンドアプリケーション (マイクロサービス) を配置します。

図9で、マイクロサービス領域のデザインパターングループの種類を示します。

代表的なものにはマイクロサービス間通信方法、マイクロサービス分割方法、マイクロサービス設計方法、ドメインモデリング方法、トランザクション管理方法、認証認可があります。

図10. マイクロサービス領域のデザインパターングループの種類

flowchart LR

  マイクロサービス領域([マイクロサービス<br>領域]) --- マイクロサービス領域の基点(( ))
  マイクロサービス領域の基点 --- マイクロサービス間通信方法([マイクロサービス間<br>通信方法])
  マイクロサービス領域の基点 --- マイクロサービス分割方法([マイクロサービス<br>分割方法])
  マイクロサービス領域の基点 --- マイクロサービス設計方法([マイクロサービス<br>設計方法])
  マイクロサービス領域の基点 --- ドメインモデリング方法([ドメインモデリング方法])
  マイクロサービス領域の基点 --- トランザクション管理方法([トランザクション<br>管理方法])
  マイクロサービス領域の基点 --- 認証認可([認証認可])

7.1 マイクロサービス間通信方法¶

マイクロサービス間を適切な方法で通信することにより、効率的で障害を解決しやすいマイクロサービスアーキテクチャを実現できます。

図10で、マイクロサービス間通信方法のデザインパターンの種類を示します。

代表的なものには、リクエスト−レスポンス、パブリッシュ/サブスクライブ、共有データ経由があります。

図11. マイクロサービス間通信方法のデザインパターンの種類

flowchart LR

  マイクロサービス間通信方法([マイクロサービス間<br>通信方法]) --- マイクロサービス間通信方法の基点(( ))
  マイクロサービス間通信方法の基点 --- リクエストレスポンス[リクエスト<br>レスポンス]
  リクエストレスポンス --- RESTful-API
  リクエストレスポンス --- RPC-API
  マイクロサービス間通信方法の基点 --- パブリッシュサブスクライブ[パブリッシュ<br>サブスクライブ]
  パブリッシュサブスクライブ --- プル型[プル<br>ベース]
  パブリッシュサブスクライブ --- プッシュ型[プッシュ<br>ベース]
  マイクロサービス間通信方法の基点 ---- 共有データ経由[共有データ経由]

リクエスト−レスポンスにはRESTful-APIとRPC-APIがあります。

パブリッシュ/サブスクライブにはプル型とプッシュ型があります *43 。

そして共有データ経由があります。

各マイクロサービスをどのようにモデリングしているか (例えば、ステートソーシングやイベントソーシング) に応じて、リクエスト−レスポンスとパブリッシュ/サブスクライブのいずれが適しているかが異なります。

これらのパターンのロジックはクラウドネイティブ技術で代替できます。

表7で、マイクロサービス間通信方法とクラウドネイティブ技術の関連性を整理します。

表7. マイクロサービス間通信方法とクラウドネイティブ技術の関連性

パターン名	リクエスト−レスポンス	パブリッシュ/サブスクライブ	共有データ経由
説明	送信元マイクロサービスは宛先と同期的に通信する。通信は双方向に流れる。	送信元マイクロサービスはメッセージ中継システム *44 を介して、宛先マイクロサービスと非同期的に通信する。通信は単方向に流れる。	送信元マイクロサービスは作成したデータをストレージに保管する。宛先マイクロサービスはストレージをポーリングして新しいデータが追加され次第、ストレージからこれを読み込む。通信は単方向に流れる。このパターンの例として、データレイクやデータウェアハウスを使用したシステムがある。
クラウドネイティブ技術との関連性	RESTの実装方法として、HTTP/1.1でテキストを送受信するパッケージを使用できる。一方で、RPCの実装方法にはRemote Procedure Call分野のツールを使用できる。	メッセージ中継システムとして、Streaming & Messaging分野のツールを使用できる。また、パブリッシュとサブスクライブの実装方法として、Streaming & Messaging分野のツールのクライアントSDKを使用できる。サブスクライブにはプル型とプッシュ型があり、ツールによってはこれらを選べる。	ストレージとして、Cloud Native StorageやDatabase分野のツールを使用できる。耐障害性の観点から、これらはオープンソースよりマネージドサービスの技術を使用することをお奨めする。
技術例	・REST (パッケージ) ・Remote Procedure Call (gRPC)	・Streaming & Messaging (CloudEvents、RabbitMQ)	・Cloud Native Storage (AWS S3) ・Database (AWS Aurora MySQL)

図11で、マイクロサービス間のリクエスト−レスポンスによる通信の様子を示します。

ここではKubernetes Podをマイクロサービスとして表します。

送信元マイクロサービスは宛先と同期的に双方向で通信します。

図12. マイクロサービス間のリクエスト−レスポンスによる通信の様子

図12で、AWS EKS上でのリクエスト−レスポンスの設計例を示します。

ここではKubernetes Podをマイクロサービスとして表しており、関連する他のKubernetesリソースを省略しています。

リクエスト−レスポンスのクライアントとサーバーとして、HTTP/1.1でテキスト (JSON、XML) を送受信するパッケージやRemote Procedure Call分野のツールを使用できます。

例えば、マイクロサービスアーキテクチャでgRPCを使用する場合、マイクロサービスのインフラストラクチャーレイヤーにgRPC関連の処理を配置することをお奨めします *45 。

マイクロサービスのgRPCクライアントは宛先マイクロサービスのgRPCサーバーと通信します。

マイクロサービスではなくフロントエンドとBFFに関する通信にも言及しておきます。

フロントエンドのRESTfulクライアントはBFFのNginxのRESTfulサーバーと通信します。

NgincはgRPCサーバーまたはRESTfulサーバーと通信し、もしgRPCサーバーと通信する場合は専用のモジュールが必要です *46 。

図13. AWS EKS上でのリクエスト−レスポンスの設計例

注釈

*44 Richardson, C. (2018). Microservices patterns: With examples in Java. Simon and Schuster.

*45 メッセージ中継システムの種類として、メッセージブローカー、メッセージキュー、およびイベントバスがあります。

*46 Vandeperre, M. (2023b, October 18). Implementing clean architecture solutions: A practical example | Red Hat Developer. Red Hat Developer. https://developers.redhat.com/articles/2023/08/08/implementing-clean-architecture-solutions-practical-example

*47 Module ngx_http_grpc_module. (n.d.). https://nginx.org/en/docs/http/ngx_http_grpc_module.html

7.2 マイクロサービス分割方法¶

マイクロサービスの分割はマイクロサービスアーキテクチャの設計の中で最重要な問題であり、技術的な難易度も非常に高いです。

分割のための境界を見つけるためには各マイクロサービスの凝集度、結合度、そして情報隠蔽度に着目するべきです *47 。

図13で、マイクロサービス分割方法のデザインパターンの種類を示します。

代表的なものには、ドメイン駆動設計に基づく境界、認証サービス、認可サービス、オーケストレーションサービス、外部API接続サービス、非同期処理に特化した機能サービス (例：メール／プッシュ通知機能など) 、リアルタイム処理に特化した機能サービス、永続データの機密度 (例：換金性の高い情報) 、永続データの所有組織があります。

また、ドメイン駆動設計に基づく境界には境界づけられたコンテキストと1つ以上の集約 *48 があります。

図14. マイクロサービス分割方法のデザインパターンの種類

flowchart LR
  マイクロサービス分割方法([マイクロサービス<br>分割方法]) --- マイクロサービス分割方法の基点(( ))
  マイクロサービス分割方法の基点 --- ドメイン駆動設計に基づく境界([ドメイン駆動設計に基づく<br>境界])
  ドメイン駆動設計に基づく境界 --- 境界づけられたコンテキスト[境界づけられた<br>コンテキスト]
  ドメイン駆動設計に基づく境界 --- 1つ以上のルートエンティティ群[1つ以上の集約]
  1つ以上のルートエンティティ群 --- 業務サービス
  境界づけられたコンテキスト --- 業務サービス
  マイクロサービス分割方法の基点 ----- 認証サービス[認証<br>サービス]
  マイクロサービス分割方法の基点 ----- 認可サービス[認可<br>サービス]
  マイクロサービス分割方法の基点 ----- オーケストレーションサービス[オーケストレーション<br>サービス]
  マイクロサービス分割方法の基点 ----- 外部API接続サービス[外部API<br>接続サービス]
  マイクロサービス分割方法の基点 ----- 非同期処理に特化した機能サービス[非同期処理に特化した<br>機能サービス]
  マイクロサービス分割方法の基点 ----- リアルタイム処理に特化した機能サービス[リアルタイム処理に特化した<br>機能サービス]
  マイクロサービス分割方法の基点 ----- 永続データの機密度[永続データ<br>機密度<br>]
  マイクロサービス分割方法の基点 ----- 永続データの所有組織の差異[永続データ<br>所有組織の差異]

図14で、ドメイン駆動設計に基づく境界のパターンの関係性を示します。

ドメイン駆動設計の考え方をマイクロサービスアーキテクチャに取り入れることにより、適切な凝集度と結合度を持つマイクロサービスに分割できます。

マイクロサービスの大きさは1つの集約より大きく、境界づけられたコンテキストより小さくするべきでしょう 40 42 。

これらの方法はクラウドネイティブ技術では代替できません。

ドメイン駆動設計はマイクロサービスアーキテクチャの文脈とは関係なく、非常に刺激的で興味深い分野です。

今回、ドメインの解決領域からいくつかの境界づけられたコンテキストや集約を切り離していく方法や、ドメイン駆動設計の戦略的設計から戦術的設計にかけた手順例などを補章で取り上げられませんでした。

そこで、ここでは関連書籍を少しだけ紹介します。

Learning Domain-Driven design本 42 は、ドメイン駆動設計の代表的な書籍であるDomain-Driven design本 43 やImplementing Domain-Driven design本 *51 をわかりやすく解説しており、さらにマイクロサービス分割方法へのドメイン駆動設計の適用についても言及しています。

補章で登場したドメイン駆動設計の用語やデザインパターンは、Domain-Driven Design reference本 *52 で整理されています。

図15. ドメイン駆動設計に基づくマイクロサービスの適切な大きさ

注釈

*48 Newman, S. (2021). Building microservices. O’Reilly Media, Inc.

*49 マイクロサービスを1つの集約よりも小さく分割するべきではありません。小さすぎるマイクロサービスから構成されるマイクロサービスアーキテクチャは分散した大きな泥団子と言われており、アンチパターンです。例えば、エンティティー単位で分割してしまうエンティティーサービスというアンチパターンがあります。The entity Service Antipattern - wide awake developers. (2017, December 5). https://www.michaelnygard.com/blog/2017/12/the-entity-service-antipattern/

*50 Khononov, V. (2021) Learning Domain-Driven design: Aligning Software Architecture and Business Strategy. O’Reilly Media.

*51 Evans, E. (2003) Domain-Driven design: Tackling Complexity in the Heart of Software. Addison-Wesley.

*52 Vernon, V. (2013) Implementing Domain-Driven design. Addison-Wesley.

*53 Evans, E. (2014) Domain-Driven Design reference: Definitions and Pattern Summaries. Dog Ear Publishing.

7.3 ドメインモデリング¶

マイクロサービスのドメインモデリングは分割に次いで重要な問題です。

図15で、マイクロサービスで採用しうるドメインモデリングのパターンの種類を示します。

代表的なものにはステートソーシングとイベントソーシングがあります。

ドメインモデリング方法の選定はマイクロサービス間通信方法に影響します。

図16. メインモデリングのデザインパターンの種類

flowchart LR

  ドメインモデリング方法([ドメインモデリング方法]) --- ドメインモデリング方法の基点(( ))

  ドメインモデリング方法の基点 --- ステートソーシング
  ドメインモデリング方法の基点 --- イベントソーシング

図16で、ドメインモデリングとマイクロサービス間通信方法の関係性を示します。

例えば、ステートソーシングでドメインモデリングしたマイクロサービス間では、リクエスト−レスポンスとパブリッシュ/サブスクライブのいずれかの通信方法を使用できます。

一方でイベントソーシングの場合、マイクロサービス間ではパブリッシュ/サブスクライブの通信方法が適切です 46 47 。

ステートソーシングとイベントソーシングはモデリング時の着眼点が異なるため、ドメインモデルの適切な分析手法やデータベーステーブルの構造なども異なります。

多くの読者にとって、より馴染みのあるドメインモデリングはおそらくステートソーシングでしょう。

図17. ドメインモデリングとマイクロサービス間通信方法の関係性

注釈

*54 Richardson, C. (2018). Microservices patterns: With examples in Java. Simon and Schuster.

*55 Newman, S. (2021). Building microservices. O’Reilly Media, Inc.

7.4 マイクロサービス設計方法¶

マイクロサービスを適切な結合度と凝集度で分割することにより、開発を分業しやすくして機能的なロジックの拡張性や生産性を高められます。

粒度が大き過ぎればモノリスアーキテクチャとなり、小さ過ぎれば分散した大きな泥団子になってしまいます *55 。

図17で、マイクロサービス設計方法のデザインパターングループの種類を示します。

代表的なものには、ドメイン駆動設計デザインパターン設計とアプリケーションアーキテクチャ設計があります。

図18. マイクロサービス設計方法のデザインパターンの種類

flowchart LR

  マイクロサービス設計方法([マイクロサービス<br>設計方法]) --- マイクロサービス設計方法の基点(( ))

  マイクロサービス設計方法の基点 --- ドメイン駆動設計デザインパターン([ドメイン駆動設計<br>デザインパターン])
  マイクロサービス設計方法の基点 --- アプリケーションアーキテクチャ設計([アプリケーション<br>アーキテクチャ設計])

まず、ドメイン駆動設計デザインパターン設計です。

ドメイン駆動設計のドメインモデリング手順では、ドメインエキスパートからビジネスルールや振る舞いをヒアリングします。

これらに基づいてユースケース図、ドメインオブジェクト図、ドメインモデル図などを作成して実装を落とし込んでいきます。

よりよく実装に落とし込むための手法がドメイン駆動設計デザインパターンです。

図18で、ドメイン駆動設計デザインパターンの種類を示します。

代表的なものにはエンティティーや値オブジェクトがあり、ほかに取り上げしきれないほどパターンがあります *56 。

ドメインロジックは機能的であり、クラウドネイティブ技術で代替できません。

図19. ドメイン駆動設計デザインパターンの種類

flowchart LR

  ドメイン駆動設計デザインパターン([ドメイン駆動設計<br>デザインパターン]) --- ドメイン駆動設計デザインパターンの基点(( ))
  ドメイン駆動設計デザインパターンの基点 --- エンティティ
  ドメイン駆動設計デザインパターンの基点 --- 値オブジェクト
  ドメイン駆動設計デザインパターンの基点 --- リポジトリ
  ドメイン駆動設計デザインパターンの基点 --- ...

次にアプリケーションアーキテクチャ設計です。

図19で、アプリケーションアーキテクチャ設計のデザインパターンを示します。

代表的なものにはレイヤードアーキテクチャ、ヘキサゴナルアーキテクチャ、オニオンアーキテクチャ、クリーンアーキテクチャがあります *57 。

これらはドメイン駆動設計デザインパターンを適切な層に実装するため、またドメインロジックを持つパターンを隔離するための方法です。

図20. アプリケーションアーキテクチャのデザインパターンの種類

flowchart LR

  アプリケーションアーキテクチャ設計([アプリケーション<br>アーキテクチャ設計]) --- アプリケーションアーキテクチャ設計の基点(( ))
  アプリケーションアーキテクチャ設計の基点 --- レイヤード
  アプリケーションアーキテクチャ設計の基点 --- ヘキサゴナル
  アプリケーションアーキテクチャ設計の基点 --- オニオン
  アプリケーションアーキテクチャ設計の基点 --- クリーン

表8で、アプリケーションアーキテクチャとクラウドネイティブ技術の関連性を整理します。

アプリケーションの中でも非機能的なロジックは、クラウドネイティブ技術で代替できます。

マイクロサービス間通信方法にリクエスト−レスポンスを使用している場合、アクセストークン署名検証ロジックはService Mesh分野のツールで代替できます (補章の認証認可を参照) 。

例えば、SSO時のアクセストークン署名検証のために、IstioによるサイドカーコンテナはリクエストをIDプロバイダーに送信します。

IstioなどのService Mesh分野のツールを使用しない場合、マイクロサービスがこれを担う必要があります。

一方で、マイクロサービス間通信方法にパブリッシュ/サブスクライブを使用している場合、ドメインロジックとメッセージ中継システムのクライアントSDKの仲介として、Streaming & Messaging分野のツールを使用できます。

例えば、CloudEventsとCloudEvents SDKはドメインロジックのイベントをメッセージ中継システムに送信します *59 。

表8. アプリケーションアーキテクチャとクラウドネイティブ技術の関連性

パターン名	レイヤード、ヘキサゴナル、オニオン、クリーン
説明	デザインパターンを適切な層に実装するため、またドメインロジックを持つパターンを隔離するためにアーキテクチャを使用する。ドメイン駆動設計ではいずれのアプリケーションアーキテクチャを使用するかは重要ではない。
クラウドネイティブ技術との関連性	非機能的なロジックの実装方法として、Service MeshやStreaming & Messaging分野のツールを使用できる。
技術例	・Service Mesh (Istio) ・Streaming & Messaging (CloudEvents、RabbitMQ)

注釈

*56 Brown, S. (2014, August 4). Distributed big balls of mud. http://dzone.com/. https://dzone.com/articles/distributed-big-balls-mud

*57 Evans, E. (2014). Domain-Driven Design reference: Definitions and Pattern Summaries. Dog Ear Publishing.

*58 Martin, R. C. (2017). Clean architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall.

*59 Salatino, M. (2022, January 29). Event-Driven applications with CloudEvents on Kubernetes – Salaboy (Open Source Knowledge). Salaboy. https://www.salaboy.com/2022/01/29/event-driven-applications-with-cloudevents-on-kubernetes/

7.5 トランザクション管理方法¶

マイクロサービスアーキテクチャでは、とくに永続データ管理方法にDB per serviceを使用している場合に問題があります。

各マイクロサービスの永続化の間に依存関係がある場合 (例えば、ECサイトで受注データの永続化が配送データや決済データに依存している) に各マイクロサービスの連続的な永続化を調整する必要があります。

この問題を解決するパターンとしてSagaや2フェーズコミットがあります。

永続データ管理方法の1つであるShared DBやDB per serviceの問題解決パターンの2フェーズコミットは、一般的に非推奨なパターンとされています。

図20で、トランザクション管理方法のデザインパターンの種類を示します。

Sagaにはオーケストレーションベースとコレオグラフィベースがあります。

図21. トランザクション管理方法のデザインパターンの種類

flowchart LR

  トランザクション管理方法([トランザクション<br>管理方法]) --- トランザクション管理方法の基点(( ))
  トランザクション管理方法の基点 --- DB-per-serviceの場合([DB per serviceの場合])
  DB-per-serviceの場合 --- Saga
  トランザクション管理方法の基点 ----- Shared-DBの場合(["Shared DBの場合<br>(非推奨)"])
  Saga --- オーケストレーションベース[オーケストレーション<br>ベース]
  Saga --- コレオグラフィフィベース[コレオグラフィフィ<br>ベース]
  DB-per-serviceの場合 ---- 2フェーズコミット["2フェーズコミット<br>(非推奨)"]

オーケストレーションベースまたはコレオグラフィベースのSagaは、一部のロジックをクラウドネイティブ技術で代替できます。

表9で、Sagaとクラウドネイティブ技術の関連性を整理します。

表9. トランザクション管理方法とクラウドネイティブ技術の関連性

パターン名	オーケストレーションベースSaga	コレオグラフィベースSaga
説明	Sagaのデザインの1つである。中央集権的なSagaオーケストレーターはメッセージ中継システムを介して、各マイクロサービスを順番にコールする。各マイクロサービスはローカルトランザクションを実行する。また、Sagaオーケストレーターはローカルトランザクションの進捗度を占有データベースに永続化する。	Sagaのデザインの1つである。特定のマイクロサービスが他のマイクロサービスを操作する。送信元マイクロサービスは、自身のローカルトランザクションを完了させた後に、メッセージ中継システムを介して宛先マイクロサービスをコールする。宛先のマイクロサービスは、ローカルトランザクションを実行する。
クラウドネイティブ技術との関連性	Sagaオーケストレーターとして、Automation & Configuration分野のツールを使用できる。このツールによっては、メッセージ中継システムがツール内部に組み込まれている。	メッセージ中継システムやこれのクライアントSDKとして、Streaming & Messaging分野のツールを使用できる。また、マイクロサービス間通信方法のパブリッシュ/サブスクライブの実装方法として、Streaming & Messaging分野のツールのクライアントSDKを使用できる。
技術例	・Automation & Configuration (Temporal)	・Streaming & Messaging (CloudEvents、RabbitMQ)

図21で、AWS EKS上でのオーケストレーションベースSagaの設計例を示します。

オーケストレーションベースSagaとして、Automation & Configuration分野のツールを使用できます。

オーケストレーションベースSagaのデザインパターンには、Sagaオーケストレーターがメッセージ中継システムを介して各マイクロサービスと通信するパターンと、これらの間でメッセージ中継システムなしに通信するパターンがあります *59 。

例えば、Temporalはメッセージ中継システムのあるオーケストレーションベースSagaとして動作します 53 54 。

Temporalクライアント (Sagaオーケストレーター) は、Temporalサーバー (Temporalの組み込みのメッセージ中継システム) にワークフローの開始を要求します。

Temporalサーバーはワークフローの進捗度 (Sagaログ) を占有データベースに永続化します。

Temporalワーカー (ローカルトランザクション実行マイクロサービス) は自身が実行するべきタスクをTemporalサーバーから取得し、タスクの実行後にその成否を送信します。

いずれかのローカルトランザクションが失敗した場合、Temporalは補償トランザクションのためのオーケストレーションも実施できます *62 。

Temporalはプログラミング言語でワークフローを定義できるため、複雑なビジネスロジックに対応できます。

また、Kubernetes上でコンテナとして動かせるため、アプリケーション領域とインフラストラクチャー領域の境界が明確になり、それぞれの領域を分業しやすいです。

これらの理由から、TemporalはオーケストレーションベースSagaの代替に適している技術であると私は考えています。

なお、より良いオーケストレーションベースSagaにはステータスチェッカーが必要になるでしょう。

ステータスチェッカーはトランザクションIDを使用してワークフローの進捗度を取得し、これをクライアントに返却します 56 57 。

図22. AWS EKS上でのオーケストレーションベースSagaの設計例

注釈

*60 Bellemare, A. (2020b). Building Event-Driven microservices. O’Reilly Media, Inc.

*61 Temporal. (2024, May 31). Saga Pattern Simplified: Building Sagas with Temporal [Video]. YouTube. https://www.youtube.com/watch?v=uHDQMfOMFD4

*62 Saga Pattern Made Easy: Trip planning with sagas but without the baggage. (n.d.). Temporal Technologies. https://temporal.io/blog/saga-pattern-made-easy

*63 Build a trip booking system with PHP | Learn Temporal. (2021, October 1). https://learn.temporal.io/tutorials/php/build_a_trip_booking_app/

*64 Richardson, C. (2018). Microservices patterns: With examples in Java. Simon and Schuster.

*65 Azure-Samples. (n.d.). saga-orchestration-serverless/docs/architecture/components.md at main · Azure-Samples/saga-orchestration-serverless. GitHub. https://github.com/Azure-Samples/saga-orchestration-serverless/blob/main/docs/architecture/components.md

7.6 認証¶

マイクロサービスアーキテクチャでは認証を適切に開始し、認証成功後にマイクロサービス間で認証アーティファクトを伝播する必要があります。

また、認証アークティファクト (例：セッションID、トークン) が有効かどうかを各マイクロサービスの実行時に検証しなければ、不正なリクエストを処理しかねません。

適切な認証認可や認証アーティファクトの伝播により、問題を単純に解決できます。

まずは認証です。

図22で、認証のデザインパターンの種類を示します。

代表的なものにはセッションベースとトークンベースがあります。

図23. 認証のデザインパターンの種類

flowchart LR

  認証([認証]) --- 認証の基点(( ))
  認証の基点 ---- セッションベース[セッション<br>ベース]
  認証の基点 --- トークンベース[トークン<br>ベース]
  トークンベース --- SSO
  トークンベース --- JWT-+-APIゲートウェイJWT[JWTとAPIゲートウェイの<br>組み合わせ]

セッションベースは、セッションを使用してマイクロサービス間で認証アーティファクトを伝播します。

トークンベースにはSSOやJWTとAPIゲートウェイの組み合わせがあり、トークンを使用してマイクロサービス間で認証アーティファクトを伝播します。

いずれの方法にもメリットデメリットがあり、要件に応じて選ばなければなりません *65 。

ここではSSOを概説します。

SSOでは、IDプロバイダーやこれへのリクエストはクラウドネイティブ技術で代替できます。

表10で、認証とクラウドネイティブ技術の関連性を整理します。

表10. 認証とクラウドネイティブ技術の関連性

パターン名	SSO
説明	SSOで認証する。認証サービスをIDプロバイダーとして使用し、これはアカウントデータ永続化やアクセストークン発行などを実施する。この認証サービスは資格情報を永続化するためのデータベースを持ち、有効期限が切れればアクセストークンを無効化する。
クラウドネイティブ技術との関連性	IDプロバイダーとしてSecurity & Compliance分野のツールを使用できる。また、IDプロバイダーへのトークン送信方法として、Service Mesh分野のツールを使用できる。
技術例	・Security & Compliance (Keycloak) ・Service Mesh (Istio)

図23で、AWS EKS上でのOIDC認可コードフローの設計例を示します。

IDプロバイダーとしてSecurity & Compliance分野のツールを使用できます。

例えば、KeycloakはIDプロバイダーとしてアカウントデータを永続化し、アカウントを証明するアクセストークンを発行します。

またKeycloakは検証エンドポイントを公開し、受信したリクエストのAuthorizationヘッダーにあるアクセストークンの署名を検証します *66 。

この時、任意の認証パッケージやIstioを使用してアクセストークン署名検証のリクエストをKeycloakに送信できます。

Istioの場合、Istioリソースを定義することにより無効なアカウントからのリクエストをサイドカーコンテナで阻止 (401や403レスポンスを返信) できます *67 。

このようにKeycloakとIstioを組み合わせることにより、マイクロサービスアーキテクチャでOIDC認可コードフローを実現できます。

図24. AWS EKS上でのOIDC認可コードフローの設計例

注釈

*66 He, X., & Yang, X. (2017). Authentication and authorization of end user in microservice architecture. Journal of Physics Conference Series, 910, 012060. https://doi.org/10.1088/1742-6596/910/1/012060

*67 Thorgersen, S., & Silva, P. I. (2023) KeyCloak - Identity and access management for modern applications: Harness the power of Keycloak, OpenID Connect, and OAuth 2.0 to secure applications. Packt Publishing Ltd.

*68 田畑. (n.d). コンテナ上のマイクロサービスの認証強化～IstioとKeyCloak～. Think IT (シンクイット) . https://thinkit.co.jp/article/18023

7.7 認可¶

伝播した認証アーティファクトを使用して各マイクロサービスは認可処理を実行する必要があります。

図24で、認可のデザインパターンの種類を示します。

代表的なものには中央集中と分散があります。

図25. 認可のデザインパターンの種類


  flowchart LR
  認可([認可]) --- 認可の基点(( ))
  認可の基点 --- 認可中央集中[中央集中]
  認可の基点 --- 認可分散[分散]

認可ロジックはドメインロジックに依存しています。

そのため、各マイクロサービスに認可ロジックを実装する分散パターンの方がより良いと私は考えています。

ただし、認可ロジックを中央集中的に実装できます。

この時、中央集中的な認可サービスはクラウドネイティブ技術で代替できます。

表11で、認可とクラウドネイティブ技術の関連性を整理します。

認可サービスとして、Security & Compliance分野のツールを使用できます。

例えば、Open Policy Agentはregoファイルのロジックで認可スコープを定義しており、各マイクロサービスはOpen Policy Agentから認可の真偽値を取得します *68 。

この時、値が偽の場合に各マイクロサービスは403ステータスを返信します。

表11. 認可とクラウドネイティブ技術の関連性

パターン名	中央集中	分散
説明	認可サービスを配置し、これがすべてのマイクロサービスの認可ロジックを担う。	各マイクロサービスが認可ロジックを担う。
クラウドネイティブ技術との関連性	認可サービスとしてSecurity & Compliance分野のツールを使用できる。	該当なし
技術例	・Security & Compliance (Open Policy Agent)	該当なし

注釈

*69 Introduction. (n.d.). Open Policy Agent. https://www.openpolicyagent.org/docs/latest/

8 ストレージ領域¶

ストレージ領域には、データの特徴に応じたストレージを配置します。

図25で、ストレージ領域のデザインパターンを整理します。

代表的なデザインパターングループには、永続データ方法、静的ファイル管理方法、揮発性データ管理方法、そして分析用加工済データ管理方法があります。

この時、必要に応じてストレージを分割し、また暗号化します。

図26. ストレージ領域のデザインパターングループの種類

flowchart LR

  ストレージ領域([ストレージ<br>領域]) --- ストレージ領域の基点(( ))
  ストレージ領域の基点 --- 永続データ管理方法([永続データ<br>管理方法])
  ストレージ領域の基点 --- 静的ファイル管理方法([静的ファイル<br>管理方法])
  ストレージ領域の基点 --- 揮発性データ管理方法([揮発性データ<br>管理方法])
  ストレージ領域の基点 --- 分析用加工済データ管理方法([分析用加工済データ<br>管理方法])

図26で、AWS EKS上でデータ管理の設計例を示します。

例えば、AWS Aurora MySQLは永続データを管理し、AWS KMSでデータを暗号化できます。

AWS S3は静的ファイルを管理し、暗号化にAWS S3マネージド暗号化キーなどを使用できます。

Kubernetes NodeにアタッチされたAWS EBSやKubernetes Volumeは揮発性データを管理し、AWS EBS上のデータの暗号化にAWS KMSを使用できます。

図27. AWS EKS上でのデータ管理の設計例

8.1 永続データ管理方法¶

図27で、マイクロサービスアーキテクチャにおける永続データ管理方法のデザインパターンの種類を示します。

代表的なものにはDB per serviceとShared DBがあります。

図28. 永続データ管理方法のデザインパターンの種類

flowchart LR
  永続データ管理方法([永続データ<br>管理方法]) --- 永続データ管理方法の基点(( ))
  永続データ管理方法の基点 --- DB-per-service[DB per service]
  永続データ管理方法の基点 --- Shared-DB["Shared DB<br>(非推奨)"]

DB per serviceでは、各マイクロサービスが占有するデータベースを配置します。

Shared DBでは、各マイクロサービス間で共有するデータベースを配置し、共有データベースのテーブルをマイクロサービス用に分割します。

Shared DBは一般的に非推奨なパターンとされているため、ここでは省略します。

表12で、永続データ管理方法とクラウドネイティブ技術の関連性を整理します。

表12. 永続データ管理方法とクラウドネイティブ技術の関連性

パターン名	DB per service	Shared DB
説明	マイクロサービスで占有するデータベースを配置する。各マイクロサービスが独立したトランザクションを実行できる。	非推奨なパターンなため省略
クラウドネイティブ技術との関連性	Database分野のツールを使用できる。耐障害性の観点から、データベースはオープンソースよりもマネージドサービスの技術を使用することをお奨めする。	同上
技術例	・Database (AWS Aurora MySQL)	同上

図28で、AWS EKS上でAWS EKS上でのDB per serviceの設計例を示します。

データベースとしてはDatabase分野のツールを使用できます。

例えば、マネージドなAWS Aurora MySQLはMySQL互換であるため、アプリケーションはMySQLのSQLの実装を変更する必要がありません。

また、AWS Aurora MySQLは高い耐障害性や性能を提供します *69 。

データベースの文脈にはスキーマという概念があり、MySQLではこれがデータベースに相当します。

つまり、データベーススキーマを分割することになります *70 。

例えば、AWS Aurora MySQLであれば、マイクロサービス単位でデータベーススキーマを定義します。

ほかの方法としてマイクロサービス単位でAWS Aurora MySQLクラスターを作成してもよいですが、クラウドの金銭的コスト面から私は好みではありません。

図29. AWS EKS上でのDB per serviceの設計例

注釈

*70 What is Amazon Aurora? - Amazon Aurora. (n.d.). https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html

*71 Newman, S. (2019) Monolith to microservices: Evolutionary Patterns to Transform Your Monolith. O’Reilly Media, Inc.

9 横断領域¶

横断領域には、他の領域に汎用的なロジックを横断的に提供するツールを配置します。

図29に、横断領域のデザインパターングループの種類を示します。

代表的なものにはExternalized configuration、CI/CDパイプライン、サービスメッシュ、そしてMicroservice chassisがあります。

補章では、これらのうちでExternalized configurationとサービスメッシュを概説します。

図30. 横断領域のデザインパターングループの種類

flowchart LR

  横断([横断<br>領域]) --- 横断の基点(( ))
  横断の基点 --- Externalized-configuration(["Externalized configuration"])
  横断の基点 ---- CI/CDパイプライン([CI/CDパイプライン])
  横断の基点 ---- サービスメッシュ([サービスメッシュ])
  横断の基点 --- Microservice-chassis(["Microservice chassis"])
  Externalized-configuration --- プル型
  Externalized-configuration --- プッシュ型
  Microservice-chassis --- 開発環境の設定
  Microservice-chassis --- API仕様
  Microservice-chassis --- CI/CDの設定
  Microservice-chassis --- IaCの設定
  Microservice-chassis --- アプリケーション計装パッケージ[アプリケーション計装<br>パッケージ]
  Microservice-chassis --- サービスメッシュ相当パッケージ[サービスメッシュ相当<br>パッケージ]
  Microservice-chassis --- ...[...]

9.1 Externalized configuration¶

マイクロサービスの実行環境には開発環境と本番環境を設け、開発環境で動作検証が済めば本番環境にデプロイします。

実行環境ごとに固有の設定をマイクロサービスに適用する必要があります。

設定をマイクロサービスから切り分け、各実行環境で設定を切り替えます。

これにより、マイクロサービスをさまざまな実行環境で簡単に稼働させられるようになります。

図30で、Externalized configurationのデザインパターンの種類を示します。

Externalized configurationにはプル型とプッシュ型の方法があります。

図31. Externalized configurationのデザインパターンの種類

flowchart LR

  Externalized-configuration(["Externalized configuration"]) --- Externalized-configurationの基点(( ))
  Externalized-configurationの基点 --- プル型
  Externalized-configurationの基点 --- プッシュ型

プル型とプッシュ型はクラウドネイティブ技術で代替できます。

表13で、Externalized configurationとクラウドネイティブ技術の関連性を整理します。

表13. Externalized configurationとクラウドネイティブ技術の関連性

パターン名	プル型	プッシュ型
説明	マイクロサービスが設定管理先から設定を取得し、自身でこれを組み込む。	マイクロサービスのインフラストラクチャーがマイクロサービスに設定を組み込む。
クラウドネイティブ技術との関連性	設定管理先や暗号化キーとして、Security & ComplianceとKey Management分野のツールを使用できる。	設定管理先や暗号化キーとしてKubernetesの標準機能、Security & Compliance、Key Management分野のツールを使用できる。
技術例	・Security & Compliance (SOPS) ・Key Management (AWS KMS)	・Kubernetes標準機能 (ConfigMap、Secret) ・Security & Compliance (AWS Secrets Manager) ・Key Management (AWS KMS)

図31で、AWS EKS上でのExternalized configurationの設計例を示します。

設定管理先と暗号化キーはKubernetes標準機能、Security & Compliance、Key Management分野のツールを使用できます。

例えば、Kubernetes ConfigMapやSecretはマイクロサービスに外部から環境変数やファイルなどの設定を動的に組み込みます *71 。

この時、SOPSを使用することによりHelmのマニフェスト展開前に、Secretの元データを暗号化して管理できます *72 。

AWS Secrets Managerはクラウドリソースなどに外部から設定を動的に組み込みます。

AWS Aurora MySQLを使用する場合、データベースに関する機密情報はAWS Secrets Managerで管理することをお奨めます。

Kubernetes ConfigMap、Secret、AWS Secrets Managerの暗号化キーは管理の簡単さ観点から、オープンソースよりもマネージドサービスの技術を使用することをお奨めます。

図32. AWS EKS上でのExternalized configurationの設計例

注釈

*72 Updating configuration via a ConfigMap. (2024, July 17). Kubernetes. https://kubernetes.io/docs/tutorials/configuration/updating-configuration-via-a-configmap/

*73 Getsops. (n.d.). GitHub - getsops/sops: Simple and flexible tool for managing secrets. GitHub. https://github.com/getsops/sops

9.2 サービスメッシュ¶

マイクロサービス間通信方法にリクエスト−レスポンスを使用する場合 *73 、各マイクロサービスに実装するべきロジックには重複があります。

例えばトラフィック管理、証明書管理、テレメトリー作成、認証、回復管理などです。

各マイクロサービスの開発チームが重複ロジックを実装することは、車輪の再発明と言えます。

サービスメッシュの仕組みでは重複ロジックをサイドカーコンテナやホストマシン上のエージェントとして切り分け、各マイクロサービスに横断的に提供します *74 。

図32で、サービスメッシュのデザインパターンの種類を示します。

代表的なものにはサイドカーとサイドカーレスがあります。

図33. サービスメッシュのデザインパターンの種類

flowchart LR

  サービスメッシュ(["サービスメッシュ"]) --- サービスメッシュの基点(( ))
  サービスメッシュの基点 --- サイドカーサービスメッシュ[サイドカー<br>サービスメッシュ]
  サービスメッシュの基点 --- サイドカーレスサービスメッシュ[サイドカーレス<br>サービスメッシュ]

サービスメッシュはクラウドネイティブ技術で代替できます。

表14で、サービスメッシュとクラウドネイティブ技術の関連性を整理します。

ここでは、技術用語のサービスメッシュとCNCFのService Mesh分野を区別しています。

表14. サービスメッシュの概説

パターン名	サイドカーサービスメッシュ	サイドカーレスサービスメッシュ
説明	各マイクロサービスの重複ロジックをサイドカーコンテナに切り分け、各マイクロサービスに横断的に提供する。また、サービスメッシュを公開するサービスメッシュゲートウェイを配置する。	各マイクロサービスの重複ロジックをホストマシン上のエージェント (コンテナあるいはカーネル機能) などに切り分け、マイクロサービスに横断的に提供する。
クラウドネイティブ技術との関連性	サービスメッシュゲートウェイとサイドカーコンテナの提供方法としてService Mesh分野のツールを使用できる。	エージェントの提供方法としてService MeshやCloud Native Network分野のツールを使用できる。
技術例	・Service Mesh (Istio)	・Service Mesh (Istio) ・Cloud Native Network (Cilium)

図33で、AWS EKS上でのサイドカーサービスメッシュの設計例を示します。

サービスメッシュとしてService Mesh分野のツールを使用できます。

例えば、コントロールプレーンとデータプレーンからなるIstioは、Envoyの設定を抽象化することによりサービスメッシュを実現します *75 。

IstioのサイドカーサービスメッシュではIstioはデータプレーンにサービスメッシュゲートウェイ (Istio Ingress GatewayとIstio Egress Gateway) を配置し、またマイクロサービス内にサイドカーコンテナ (istio-proxy) をインジェクションします。

サービスメッシュゲートウェイはサービスメッシュ内外を接続する役割を持ち、マイクロサービスを公開するためのAPIゲートウェイとはその役割が異なります *72 。

Istioによるサイドカーコンテナは、さまざまな汎用ロジックをアプリケーションコンテナに提供します。

サイドカーコンテナ内ではpilot-agentプロセスとenvoyプロセスが稼働しています。

envoyプロセスはコントロールプレーンとpilot-agentを介して双方向ストリーミングRPCを実施し、コントロールプレーンのAPIからEnvoyの設定を動的に取得します *76 。

Istioにより、マイクロサービスとしてのKubernetes Podは他のPodと直接通信できるようになります。

一方で、Istioを使用しない場合、Kubernetes PodはKubernetes Serviceを介して他のPodと通信します。

図34. AWS EKS上でのサイドカーサービスメッシュの設計例

注釈

*74 マイクロサービス間通信方法にパブリッシュ/サブスクライブを使用する場合、『イベントメッシュ』という仕組みが適切です。これは、イベント中継システムなどを各マイクロサービスに横断的に提供できます。これは、Knativeで代替できます (https://knative.dev/docs/eventing/event-mesh/) 。

*75 Gough, J., Bryant, D., & Auburn, M. (2021) Mastering API architecture. O’Reilly Media, Inc.

*76 Sidecar or ambient? (n.d.). Istio. https://istio.io/latest/docs/overview/dataplane-modes/

*77 Posta, C., & Maloku, R. (2022) Istio in action. Manning Publications.

10 インフラストラクチャー領域¶

インフラストラクチャー領域にはネットワーク、セキュリティ、オブザーバビリティーに関するツールを配置します。

図34で、インフラストラクチャー領域のデザインパターングループの種類を示します。

代表的なデザインパターングループにはL4/L7トラフィック管理方法、証明書管理方法、オブザーバビリティーがあります。

図35. インフラストラクチャー領域のデザインパターングループの種類

flowchart LR

  インフラストラクチャー領域([インフラストラクチャー<br>領域]) --- インフラストラクチャー領域の基点(( ))
  インフラストラクチャー領域の基点 --- L4-/-L7トラフィック管理方法([L4/L7トラフィック<br>管理方法])
  インフラストラクチャー領域の基点 --- 証明書管理方法([証明書<br>管理方法])
  インフラストラクチャー領域の基点 --- オブザーバビリティー([オブザーバビリティー])

10.1 L3管理方法¶

マイクロサービスのインスタンス間が通信するためには、各マイクロサービスのインスタンスに対するIPアドレスの割当と解放を管理する必要があります。

これはCloud Native Network分野の技術で代替できます。

図35で、AWS EKS上でL3管理の設計例を示します。

例えば、AWSであればAWS VPCがL3 (ネットワーク層) を提供します *77 。

また、マネージドなAWS VPC CNIアドオンはkubelet、ENI、AWS EKSコントロールプレーンと連携し、AWS VPC上にクラスターネットワークを作成します。

これはAWS EKSクラスター内のIPアドレスを制御し、マイクロサービスがAWS EKSのクラスターネットワークに参加できるようにします *78 。

図36. AWS EKS上でのL3管理の設計例

注釈

*78 ほかに例えば、L2を作成するCNIがあり、CNIによって提供する層はさまざまです。

いずれのプラットフォーム (補章であれば、AWS EKS) を選ぶかによって、適切なCNIが異なります。

*79 Amazon VPC CNI - EKS Best Practices Guides. (n.d.). https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/

10.2 L4/L7トラフィック管理方法¶

L4/L7のプロトコル (TCP、HTTP、HTTPSなど) を使用してマイクロサービスのインスタンス間が通信する時、トラフィック管理の仕組みが必要です。

図36で、デザインパターングループの種類を示します。

代表的なものにはサービス検出とロードバランシングがあります。

図37. L4/L7トラフィック管理方法のデザインパターングループの種類

flowchart LR

  L4-/-L7トラフィック管理方法([L4/L7トラフィック<br>管理方法]) --- L4-/-L7トラフィック管理方法の基点(( ))
  L4-/-L7トラフィック管理方法の基点 --- サービス検出([サービス検出])
  L4-/-L7トラフィック管理方法の基点 --- ロードバランシング([ロードバランシング])

まずはサービス検出です。

マイクロサービスアーキテクチャではマイクロサービスのインスタンスがスケーリングで増減するたびに、ネットワーク上の宛先を変化させます。

この時、宛先と継続的に通信できるような仕組みが必要です。

サービス検出により、リクエストの送信元マイクロサービスが宛先の場所IPアドレス、ポート番号、完全修飾ドメイン名などを動的に検出し、通信できるようになります。

図37で、サービス検出のデザインパターンを示します。

図38. 宛先検出と宛先登録のデザインパターンの種類

flowchart LR

  サービス検出([サービス検出]) --- サービス検出の基点(( ))
  サービス検出の基点 --- 宛先検出([宛先検出])
  宛先検出 --- サーバーサイド
  宛先検出 --- クライアントサイド
  サービス検出の基点 --- 宛先登録([宛先登録])
  宛先登録 --- セルフ
  宛先登録 --- サードパーティー

宛先検出にはサーバーサイドサービス検出とクライアントサイドサービス検出があります。

送信元または宛先マイクロサービス、ロードバランサー、サービスレジストリが組み合わさって宛先検出を実施します。

これらの仕組みはクラウドネイティブ技術で代替できます。

表15で、宛先検出とクラウドネイティブ技術の関連性を整理します。

静的ファイルストレージとして使用できる。

表15. 宛先検出とクラウドネイティブ技術の関連性

パターン名	サーバーサイド	クライアントサイド
説明	送信元マイクロサービスから問い合わせとロードバランシングの責務が切り離されている。送信元マイクロサービスはロードバランサーにリクエストを送信する。ロードバランサーは宛先マイクロサービスの場所をサービスレジストリに問い合わせ、またリクエストをロードバランシングする責務を担っている。	通信の送信元マイクロサービスは宛先マイクロサービスの場所をサービスレジストリに問い合わせ、さらにロードバランシングする責務を担う。
クラウドネイティブ技術との関連性	ロードバランサーとしてService Mesh、Coordination & Service Discovery分野のツールを使用できる。	送信元マイクロサービスのロードバランシング処理の実装方法として、Kubernetes標準機能を使用できる。
技術例	・Service Mesh (Istio)	・Kubernetes標準機能 (Kubernetes Service、kube-proxy) ・Coordination & Service Discovery (CoreDNS)

図38で、AWS EKS上でのサービスメッシュ内のL4/L7トラフィック管理の設計例を示します。

サービスメッシュ内ではL4/L7ロードバランサーとしてService Mesh分野のツールを使用できます。

例えば、Istioによるサイドカーコンテナはサービスメッシュ内のKubernetesリソースやIstioリソースの情報に基づいて、サーバーサイドサービス検出を実施します *79 。

IstioコントロールプレーンはAWS EKSコントロールプレーンからサービス検出に必要なリソースの情報を収集し、インメモリで保管します。

図39. AWS EKS上でのサービスメッシュ内のL4/L7トラフィック管

図39で、AWS EKS上でのサービスメッシュ外のL7トラフィック管理の設計例を示します。

サービスメッシュ外では、L7ロードバランサーとしてKubernetes標準機能とCoordination & Service Discovery分野のツールを使用できます。

例えば、CoreDNSはKubernetes Serviceとkube-proxyと連携し、サーバーサイドサービス検出を実施します 73 74 。

送信元Podは、宛先Podへのリクエスト前にCoreDNSから宛先Podのドメインを正引きします。

この時、AWS EKSを使用する場合、マネージドなAWS kube-proxyアドオンとAWS CoreDNSアドオンを使用できます。

図40. AWS EKS上でのサービスメッシュ外のL7トラフィック管理の設計例

図40で、AWS EKS上でのサービスメッシュ外のL4トラフィック管理の設計例を示します。

L4ロードバランサーとしてKubernetes標準機能を使用できます。

例えば、Kubernetes Serviceとkube-proxyはデフォルトでiptablesと連携し、クライアントサイドサービス検出を実施します *82 。

kube-proxyは新しいPodのIPアドレスをiptablesに追加し、またKubernetes Serviceはiptablesに基づいてリクエストをPodにロードバランシングします。

前述のとおり、AWSはマネージドなkube-proxyアドオンを提供します。

図41. AWS EKS上でのサービスメッシュ外のL4トラフィック管理の設計例

宛先登録にはセルフ登録とサードパーティー登録があります。

これらの仕組みはクラウドネイティブ技術で代替できます。

表16で、宛先登録パターンとクラウドネイティブ技術の関連性を整理します。

サービスレジストリとして、Coordination & Service Discovery分野のツールを使用できます。

例えば、Kubernetes上のさまざまなサービスレジストラーは収集した宛先情報をEtcdに保管します。

AWS EKSを使用する場合、Etcdはマネージドなコントロールプレーン上にあります *83 。

表16. 宛先登録とクラウドネイティブ技術の関連性

パターン名	セルフ登録	サードパーティー登録
説明	サービス検出時に起動した送信元マイクロサービスはサービスレジストリに自身の宛先情報を送信し、登録する。	サービス検出時にサービスレジストラーは起動した送信元マイクロサービスを収集し、サービスレジストリに宛先情報を登録する。多くのサービス検出ツールでサードパーティーパターンを使用している。
クラウドネイティブ技術との関連性	サービスレジストリとしてCoordination & Service Discovery分野のツールを使用できる。	サービスレジストリとしてCoordination & Service Discovery分野のツールを使用できる。
技術例	・Coordination & Service Discovery (Etcd)	・Coordination & Service Discovery (Etcd)

次に、ロードバランシングのデザインパターンです。

マイクロサービスのインスタンスに適切に負荷を分散させることにより、マイクロサービスアーキテクチャのシステム全体の可用性を高められます。

図41で、ロードバランシングのデザインパターンの種類を示します。

代表的なものには静的方式と動的方式があります。

図42. ロードバランシングのデザインパターンの種類

flowchart LR

  ロードバランシング([ロードバランシング]) --- ロードバランシングの基点(( ))
  ロードバランシングの基点 --- 静的方式
  ロードバランシングの基点 --- 動的方式

静的方式にはラウンドロビン、重み付きラウンドロビン、IPハッシュなどに基づくロードバランシングがあります。

これらは宛先の負荷を考慮しない方式です。

一方で動的方式には最小接続数、重み付き接続数、最小レスポンス時間などに基づくロードバランシングがあります。

これらは宛先の負荷をリアルタイムに考慮する方式です。

ロードバランシングの各方式はクラウドネイティブ技術で代替できます。

表16で、ロードバランシングとクラウドネイティブ技術の関連性を整理します。

例えば、Istioによるサイドカーコンテナはラウンドロビンや最小接続時間に基づいて、通信を宛先マイクロサービスにロードバランシングします *84 。

表17. ロードバランシングとクラウドネイティブ技術の関連性

パターン名	静的ロードバランシング	動的ロードバランシング
説明	宛先の負荷を考慮せずにロードバランシングする。	宛先の負荷をリアルタイムに考慮してロードバランシングする。
クラウドネイティブ技術との関連性	静的方式のロードバランサーとしてKubernetes標準機能とService Mesh分野のツールを使用できる。	動的方式のロードバランサーとしてService MeshとCoordination & Service Discovery分野のツールを使用できる。
技術例	・Kubernetes標準機能 (Kubernetes Service、kube-proxy) ・Service Mesh (Istio)	・Kubernetes標準機能 (Kubernetes Service、kube-proxy) ・Service Mesh (Istio)

注釈

*80 Mesh, A. (2020, August 12). Debugging Your Debugging Tools: What to do When Your Service Mesh Goes Down [Slide show]. SlideShare. https://www.slideshare.net/slideshow/debugging-your-debugging-tools-what-to-do-when-your-service-mesh-goes-down/237797183

*81 Belamaric, J., & Liu, C. (2019) Learning CoreDNS: Configuring DNS for Cloud Native Environments. O’Reilly Media, Inc.

*82 Virtual IPs and service proxies. (2024, October 7). Kubernetes. https://kubernetes.io/docs/reference/networking/virtual-ips/

*83 Service. (2024, June 25). Kubernetes. https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-iptables

*84 Control Plane - EKS Best Practices Guides. (n.d.). https://aws.github.io/aws-eks-best-practices/reliability/docs/controlplane/

*85 Traffic management. (n.d.). Istio. https://istio.io/latest/docs/concepts/traffic-management/

10.3 アプリケーションデータの暗号化¶

マイクロサービスアーキテクチャでは、システム内で非常に多くのパケット通信が起こります。

パケットのアプリケーションデータを暗号化しなければ、これを第三者に攻撃されかねません。

TLSプロトコルを使用してアプリケーションデータを暗号化することにより、攻撃から防御できます。

証明書を使用して通信を暗号化できます *85 。

図42で、証明書管理方法のデザインパターンの種類を示します。

代表的なものにはサイドカー、アプリケーション、クラウドリソースの証明書管理があります。

図43. 証明書管理方法のデザインパターンの種類

flowchart LR

  証書管理方法([証書<br>管理方法]) --- 証明書管理方法の基点(( ))
  証明書管理方法の基点 --- マイクロサービスの証明書管理[マイクロサービスの<br>証明書管理]
  マイクロサービスの証明書管理 --- サービスメッシュを使用する場合
  マイクロサービスの証明書管理 --- サービスメッシュを使用しない場合
  証明書管理方法の基点 ---- クラウドリソースの証明書管理[クラウドリソースの<br>証明書管理]

証明書管理はクラウドネイティブ技術で代替できます。

表18で、証明書管理とクラウドネイティブ技術の関連性を整理します。

ここでは、技術用語のサービスメッシュとCNCFのService Mesh分野を区別しています。

表18. 証明書管理とクラウドネイティブ技術の関連性

パターン名	マイクロサービスの証明書管理 (サービスメッシュを使用する場合)	マイクロサービスの証明書管理 (サービスメッシュを使用しない場合)	クラウドリソースの証明書管理
説明	サービスメッシュを使用する場合、マイクロサービスのサイドカーコンテナに証明書を組み込み、管理する。送信元と宛先のサイドカーコンテナ間の通信でサーバー認証を実施できる。この場合、アプリケーションコンテナで証明書を管理する必要がなくなる。	サービスメッシュを使用しない場合、マイクロサービスのアプリケーションコンテナに証明書を組み込み、管理する。送信元と宛先のアプリケーションコンテナ間の通信でサーバー認証を実施できる。	クラウドリソースに証明書を組み込み、管理する。クラウドリソースへの通信でサーバー認証を実施できる。
クラウドネイティブ技術との関連性	組み込む証明書としてService Mesh分野のツールを使用できる。	組み込む証明書としてSecurity & Compliance分野のツールを使用できる。	組み込む証明書としてSecurity & Compliance分野のツールを使用できる。
技術例	・Service Mesh (Istio)	・Security & Compliance (Cert Manager)	・Security & Compliance (AWS Certificate Manager)

図43で、AWS EKS上での証明書管理の設計例を示します。

マイクロサービスのサイドカーコンテナの証明書管理にはService Mesh分野のツールを使用できます。

例えば、Istioは署名済みの証明書をサイドカーコンテナに組み込み、定期的にこれを更新します *86 。

Istioコントロールプレーンは自己を署名し、ルート認証局としてサイドカーコンテナのクライアント／サーバー証明書を署名します。

さらにIstioコントロールプレーンはサイドカーコンテナに証明書を組み込み、証明書が失効すれば自動的に更新します。

この仕組みにより、サイドカーコンテナ間で相互TLS認証を継続的に実施できるようになります *87 。

一方でIstioを使用しない場合、Security & Compliance分野のツールを使用してアプリケーションコンテナに証明書を組み込み、これを管理する必要があります。

クラウドリソースの証明書管理にはSecurity & Compliance分野のツールを使用できます。

例えば、AWS Certificate Managerは中間認証局のAmazon CAからサーバー証明書を取得し、AWSリソースへの組み込みと定期更新を管理します。

図44. AWS EKS上での証明書管理の設計例

注釈

*86 Siriwardena, P., & Dias, N. (2020) Microservices Security in action. Manning Publications.

*87 Plug in CA certificates. (n.d.). Istio. https://istio.io/latest/docs/tasks/security/cert-management/plugin-ca-cert/

*88 Security. (n.d.). Istio. https://istio.io/latest/docs/concepts/security/

11 おわりに¶

補章としてマイクロサービスアーキテクチャのデザインパターンを取り上げ、どのようなクラウドネイティブ技術で代替できるのかを概説しました。

クラウドネイティブ技術とマイクロサービスアーキテクチャのつながりの理解を深めることはできたでしょうか？

既存のクラウドネイティブ技術の問題を解消した新しいクラウドネイティブ技術が次々と登場しています。

この時、その技術はマイクロサービスアーキテクチャのどのデザインパターンに結びつき、またすべてや一部のロジックを代替できるのだろうかという視点も重要です。

クラウドネイティブ技術の役割を複数の観点から知ると、システム全体の中でその技術が担う役割をより理解できるようになります。

そして、その知識をさまざまなシステムにパズルのように応用できるようになります。

たとえ類似の新技術が登場しても、振り回されることなく使用の是非を判断し、既存の知識に基づいてすぐに適用できるようになります。

補章が本書全体やクラウドネイティブ技術の理解度を高め、さまざまなシステムへの適用のきっかけになれば嬉しいです。

登場年	アーキテクチャスタイル	提唱者（アルファベット順）	概要
1999	モノリスアーキテクチャ	自然発生的	アプリケーションのすべてのロジックを単一のプロセスで稼働させ、また全体をリリースする。
1990年代後半〜 2000年代前半	サービス指向アーキテクチャ	Michael Bell、Thomas Erlなど	アプリケーションを『機能』の粒度で分割する。
2003	ドメイン駆動設計	Eric Evans	オブジェクト指向分析設計のベタープラクティスを集め、機能ロジックのモデリングを強化する。
2003	プレゼンテーションドメイン分離	Martin Fowler	フロントエンド領域をバックエンド領域の機能ロジックから切り離す。
2014	マイクロサービスアーキテクチャ	James Lewis、Martin Fowler	アプリケーションをドメイン駆動設計の『集約』や『境界づけられたコンテキスト』の粒度で分割する。