マイクロサービス

今更だがマイクロサービス（ Microservices ）についてまとめる。
自分の仮説込みなので参考にしていただいてよいが鵜呑みにしないでね。

• 1.モノリスの限界
• 2.マイクロサービスとは
• 3.マイクロサービスの分割
• 4.マイクロサービスのデメリットへの対応（マイクロサービスエコシステム）
• （マイクロサービスの構成）

1.モノリスの限界

総じて言うとアジリティが低い。

• 小さな変更でもモノリス全体のビルド・リリース
  • リリース・デプロイの調整、コミュニケーション問題
• リソースを必要とする部分だけでなく、アプリケーション全体のスケールアウトが必要
• 小さなリリース、大胆な意思決定が難しい
• オーナーシップ問題があり、自律的なプロダクト開発ができない、イノベーション阻害

システム開発のアジリティを向上するためのアプローチの 1 つに マイクロサービスアーキテクチャ がある。

2.マイクロサービスアーキテクチャとは

それぞれ独自のプロセス内で動作する小さなサービス（マイクロサービス）の集合体としてシステムを構成し、マイクロサービス間では軽量のプロトコルを使用して通信を行うアーキテクチャー手法 を指す。また、 1 つのマイクローサービスはアプリケーションおよびそれと対のなる DB で構成される実行単位を指す。
ThoughtWorks 社の James Lewis が 2012 年 3 月に発表したMicro services - Java, the Unix Wayが初出で、James Lewis/Martin Fowler が 2014 年に公開した Microservices（日本語）でバズったとされる。
どのような手法にも言えることだが、 マイクロサービスアーキテクチャも全てのシステムに適している訳ではなく、メリット・デメリットがあり、トレードオフの関係になっている。
マイクロサービスの適用を検討するシステムの特徴は以下が挙げられる。

• システム規模が大きい
  • （例）初期構築に数百人月を要する
• アジリティを求める
  • （例）初期構築以降も継続的に機能追加・改善を行う、改修頻度は低いものの今後他システムとの連携が想定される、意思決定からシステム反映までの速さを重視する
• 様々なドメイン・サブドメインを含むシステム
  • （例）社内の複数組織が関係するシステム

MSA は導入コストが高い。上記を満たすようなシステムでないのであれば導入はおすすめしない。恩恵を受けられないからだ。
大きすぎるモノリスであるがために、運用コストが高い、開発生産性が低い、意思決定と実行が遅いといった問題が発生することが見込める・現に発生しているのであれば導入検討をおすすめする。

2.1.メリット

• 開発チームがサービスごとに分かれ、それぞれ得意な最適な技術（言語など）を選択できる
• システム全体に影響を与えず、各マイクロサービスごとに変更・リリースできる
  • 小さなチームへの 責任と権限の委譲 、頻繁なトライアンドエラー、高速且つ高精度な意思決定
  • データスキーマ、メッセージスキーマ、シグネチャ、ライブラリやフレームワークのバージョン、共有コンポーネントの依存が起こらず、マイクロサービス単位で頻繁な更新をかけることが可能
• リリースサイクルの短縮
  • ビルドやテストの期間が短くなり開発効率が上がる
  • 2014年の時点で年間5000万回のデプロイ(Amazon)
• コンピュータリソースを効率的に利用
  • サービスごとに性能をスケールできる（水平スケーリング・スケールアウト）
• 再利用性
  • 1 つのマイクロサービスの機能を複数のマイクロサービスが利用できる
• 障害の分離
  • 1つの機能がダウンしてもほかの機能に影響しない、呼び出し先のサービスがダウンしても呼び出し元のサービスはダウンしない
  • モノリシックなシステムだと何か障害が起きたときに、どこがおかしいのかルート構造をたどるのに時間がかかるが、原因の突き止めが比較的容易

つまり、用途・目的ごとに小さくサービスを作っておくことで、 変化に強くて柔軟性の高い アプリケーション開発、 ビジネス変化への迅速な追従 が可能となる。

2.2.デメリット

• マイクロサービスへの分割が難しい
  • ドメインの境界やどれくらいの大きさがいいか？など
• 個々のサービスはシンプルになるが、システム全体は複雑化
  • サービス間通信が複雑化し、サービス同士を繋げるのが難しい（service discovery の問題）
• サービス間でデータの一貫性を保つのが難しくなる
  • 各サービスが独自のデータベースを持つので
• 個々のサービス開発は楽になるが、全体の運用は極度に難化
  • 成熟した DevOps カルチャが必要
  • バージョン管理
• 全般的に冗長なシステムになりオーバーヘッドが多い
• 全体を見渡しにくく障害の影響を予想しにくい
• 全体のテストやデバッグがしにくい
• テクノロジーの標準を定めにくい
• サービスをまたぐトランザクションや整合性を保つしくみが必要
• アジャイル開発、DevOps、インフラ運用の自動化などが前提で新しいITスキルが必要

マイクロサービスの適用においては、メリットを享受しつつ上記のデメリットを最小化することによってその効用を得ることがポイントとなる。

2.3.マイクロサービス導入で注意すること

• 「独立した」サービスという意味を詳細に決めておく
  • 「独立した」というのは、それが「単一でデプロイ、実行可能である」という性質を満たす必要がある
• 変化を許容するような計画・プロセスであるべき
  • 例えば Agile
• ボックス間で起こっていることについて心配し、ボックス内で起こっていることには寛大になる
• コンウェイの法則 ： システムのアーキテクチャは、コミュニケーションと企業の組織構造によって決まる
  • 逆コンウェイの法則 ： 組織構造は、システムのアーキテクチャによって決まる
    • 組織の サイロ化 をまねき、個別最適、組織間に壁ができる
• The Reactive Manifesto（日本語）
• 全てのサービス間連携はサービスインターフェイスを通じて行われるべきである
  • Amazonではこれを破ると解雇される

2.4.マイクロサービスで起こる問題

デメリットとやや重複するが、ではそのデメリットがどのような形で体現するのか。

• Observability（可観測性）への対応
  • Twitter 社のエンジニア発の概念
  • 分散システムをうまく運用するためにシステムの繋がり部分の挙動に注目して可視化・監視する必要がある
  • 取得すべき値や集約・ストレージの設計などがスコープ
• サービス境界の問題 -> Service Mesh
  • サービス境界で何が起こっているのか？
    • RPS、status、リトライ、タイムアウト、サーキットブレーカ、バルクヘッド、補正トランザクション
  • 分散トレーシング
    • あるリクエストを処理したサービスはどれで、その処理結果がどうだったのか
• サービス単体の可用性の確保
  • SPOFがないか -> 冗長化
  • 障害耐性/回復性は十分か -> 障害を想定した前提にした設計 -> Design for Failure
    • 品質特性
• 効率的にシステム障害を解決したり、キャパシティプランニング
• 新規参入開発者が全体像を早期に把握
  • 組織の急速な成長
• オーナーシップ問題
  • 責任の分離
    • プロダクト開発社は基本的に自分たちのプロダクト・サービシに責任を持てる
  • SRE
    • しかしシステム全体は協調して動作させる必要があるので組織横断的なチームは必要
  • 横断的なチームがアプリケーションの細部を把握しなくてもシステム全体の動作を理解できる必要がある（中央で管理する必要性）

3.マイクロサービスの分割

まず最初に重要なことは、 小さなシステムにマイクロサービスアーキテクチャを適用することは避ける ことだ。マイクロサービスのデメリットを上回るメリットを享受できない。モノリスから始め、サービスが軌道に乗る見込みがたった段階でマイクロサービスへの移行を検討するとよい。
その上で分割する際の観点は以下の通り。

• 3.1.ドメイン観点
• 3.2.アーキテクチャ観点
• 3.3.チーム観点

3.1.ドメイン観点

まずドメインを分割する際はシステム特性で バイモーダル に考える必要がある。

• SoR ( System of Record )
• SoE ( System of Engagement )
• SoI ( System of Insight ) という考え方もあるがここでは割愛。

つまり、SoR と SoE でドメイン分割する際のアプローチが異なる。

そもそも SoR にマイクロサービスを適用するのか？という議論があるが、SoR はその名の通り記録のシステムであり、データを保有することが役割である。 そのデータは SoE と適切に連携され、 SoI へのデータソースとなる。 つまり、 API エコノミーを形成するため、データ連携に対してアジリティ（柔軟性）が求められるのだ。 そのアジリティ獲得の方法の 1 つとして、マイクロサービスは一考の価値があるのではないか。

結論から書くと、SoR は DOA ( Data Oriented Approach ) 、 SoE は POA ( Process Oriented Approach ) 、そしてそれぞれ OOA (Object Oriented Approach ) の併用が適しているのではないか。

バイモーダル	設計アプローチ
SoR	DOA -> OOA
SoE	POA -> OOA

マイクロサービスへの移行や新規構築では「十分に小さく、ちょうどいい大きさ」にする訳なのだが、以下に 4 原則を定める。

1. すべてが分散されており、
2. ビジネスドメインを起点に
   • SoR の場合：データモデリングされており、
   • SoE の場合：UX デザインされており、
3. 各サービスが独立してデプロイでき、
   • OOA、後述の「アーキテクチャ観点」の分割
4. サービス間でデータを共有していない
   • OOA、後述の「アーキテクチャ観点」の分割

上記の 4 原則、さらにバイモーダルの考えに沿って、以下の観点で分割方法を記載する。

• 3.1.1.SoRの分割（データモデリング）
• 3.1.2.SoEの分割（UXデザイン）
• 3.1.3.OOAの手法（ドメイン駆動設計）

（以降、未整理）

3.1.1.SoRの分割（データモデリング）

ERD を作成する。

3.1.2.SoEの分割（UXデザイン）

イベントストーミング を利用して、ドメインモデルを作成する。

3.1.3.OOAの手法（ドメイン駆動設計）

• 1 つのマイクロサービスで、 1 つのビジネスファンクションが完結すること
  • サービスの境界をビジネスの境界に合わせる
  • 変更する理由が同じものは集める、変更する理由が違うものは分ける
  • サービス間は疎結合

マイクロサービスの境界をうまく決める設計手法に ドメイン駆動設計 （ DDD : Domain Driven Design ）がある。

「不完全な状況の中で、抽象的な設計原則を、現実のソフトウェアに適用するための助言」。
「ドメインモデルをソフトウェア開発の中心にすえ、コードやコミュニケーションを常にドメインモデルと一体化させながら、ドメインモデルを反復的に深化させることでより価値の高いアプリケーションを生み出していこうとする考え方」。
オブジェクト指向コミュニティの間で長年培われてきたドメインモデリングのノウハウやベストプラクティスを集大成した、1つの設計思想／哲学でアジャイルなプロセスを前提としている。

• DDD難民に捧げる Domain-Driven Designのエッセンス
• 持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
• ドメイン駆動設計＋クリーンアーキテクチャ解説【DDD編】
  • これの次の記事読むべき

以下は用語。

• ドメイン（ Domain ）
  • アプリケーションが対象とする業務領域
  • 「知識、影響力、活動の一領域」
  • ユーザーがプログラムを適用する対象エリアは、ソフトウェアのドメイン
• 境界付けられたコンテキスト（Bounded Context）
  • 特定のモデルが定義され適用される境界（通常、サブシステム、または特定のチームの作業）の説明
  • 会社全体で？プロダクト全体？もっと狭めてチームぐらいかな、という形に「この言語をこの意味で使う範囲はここまで」という風に決めましょうという概念
• ユビキタス言語（ Ubiquitous Language ）
  • ドメインモデルを中心に構造化された言語
  • チームのすべてのアクティビティをソフトウェアと結びつけるために、境界付けられたコンテキスト内のすべてのチームメンバーが使用する
  • 「チームで使う共通言語」ぐらいの和訳でとらえておくのがわかりやすい
• ドメインモデル（ Domain Model ）
  • ユビキタス言語で定義された、ドメインに必要なデータとそれに対するメソッドのセット
  • 以下の 3 つから構成される
    1. エンティティ（ Entities ）
       • 同一性・連続性があるもの
       • 例）ユーザの年齢や身長などの属性は変化するが、ユーザ自身であることは変わらない
       • データストアの構成には依存しない
    2. 値オブジェクト（ Value Objects ）
       • 同一性を持たないもの
    3. ドメインサービス（ Domain Services ）
       • 状態をもたない（statelessな）機能や処理
    4. リポジトリ（ Repository ）

ここで住所について考察しましょう。メッセージアプリにおけるユーザにとって、住所は同一性はなく値オブジェクトとして扱うことができます。しかしユーザが配送先をWEB上で決め、それを元に集荷、配送を送るようなアプリケーションを考えてみましょう。この時送り先としての住所は管理され、同一性を持ちます。Aさんが送り先を指定し、その後変更した場合送り先としての住所には同一性があります。このようなケースではエンティティとして管理する必要があります。

3.1.4.ドメイン観点での分割手順

一口にMSA分割手順といっても様々な状況がある。 状況に応じて以下の手順でビジネスドメインへ分割する。

• 既存システムの場合
  • 新規に構築する部分からマイクロサービス化
  • その他はストラングラーパターン
• 新規システムの場合
  • SoRの場合：DOA -> OOA
  • SoEの場合：POA -> OOA

これまでの「アーキテクチャ観点での分割」「ビジネスドメイン観点での分割」を加味して、マイクロサービス分割手順を示す。

• http://ascii.jp/elem/000/001/659/1659834/

1. マイクロサービスの設計は、ビジネスドメインをラフスケッチし、ドメインモデルを描くことからスタートする。
2. ビジネスドメインとは、ドローン配送サービスの例では、「在庫管理」「オーダー管理」といった単位になる。「その領域内で同一の言語を話す単位（Bounded Context）。
   • 例えば、顧客管理において“顧客”が意味するものが同一である必要がある。
   • “顧客”の意味が違う領域にサービスがまたがる場合は、Bounded Contextを分離する（別のマイクロサービスにする）ように」

• オブジェクト志向
• エクストリームプログラミング

3.2.アーキテクチャ観点

マイクロサービスもまたレイヤーでその役割を分けて考えることができる。
ドメイン観点で分割されたドメインモデルに対して以下のコンポーネントを加味したアーキテクチャを設計する。

• プレゼンテーション層(UI/API)
  • ネイティブアプリ・SPAなどのビュー、 API エコノミーを形成するための API Gateway
• アプリケーションビジネスロジック層（ BFF : Backend for Frontend ）
  • 複数のマイクロサービスへアクセスし、プレゼンテーション層向けのビジネスロジックを実行する層
  • 複数のドメインロジックを横断して利用し、サービスのロジックを実現する層
• ドメインビジエンスロジック層（API）
  • データソース層を API でラッピングし、ドメインロジックを保有・実行する層
• データソース層
  • RDBMS や NoSQL
  • ドメイン分割されたマイクロサービスが個々に独立したデータベースを持つ

「アプリケーションビジネスロジック層」「ドメインビジネスロジック層＋データソース層」が 1 つのマイクロサービスとなる。

ちなみに以下のようなアーキテクチャが巷に転がっているが、これらは DDD （後述）文脈でアプリケーションを作る際のソフトウェアアーキテクチャを指しており、マイクロサービスアーキテクチャでいうと 1 つのマイクロサービスを実装する際に参考にするとよい。

1. レイヤードアーキテクチャ
2. ヘキサゴナルアーキテクチャ
3. オニオンアーキテクチャ
4. クリーンアーキテクチャ

3.3.チーム 観点

基本的にはドメイン観点、アーキテクチャ観点で分割されたマイクロサービスに対して開発者をアサインしていくのだが、チームについては以下の観点を加味する。

• 1 マイクロサービスで 10 人未満の 1 チーム
  • Two-pizza teams(Amazon)
  • UI担当、ミドルウェア担当、DBA のような職能でチーム分割せず、クロスファンクショナルなチームを構成
  • 2週間で書き直せるサービス（できない場合はサービスを分割する）
• サービスがチーム構造と一致していること（ コンウェイの法則 ↔︎ 逆コンウェイの法則 ）
  • 購買管理チーム、在庫管理チーム、会計チーム、など

4.マイクロサービスのデメリットへの対応（マイクロサービスエコシステム）

ここでは、マイクロサービスのメリットを享受しつつ、 デメリットを最小化 するためのノウハウについて記載する。
以下のようにレイヤを分けて考える。

• レイヤ４：マイクロサービス
• レイヤ３：アプリケーションプラットフォーム
• レイヤ２：通信
• レイヤ１：ハードウェア

レイヤ３以下を抽象化できる構造にすることによって初めてマイクロサービスを開発・運用することができる。

Service Mesh

分散アーキテクチャの運用を楽に。

• Envoy ( Envoy proxy )
  • プロキシソフトウェア
  • Data Plane
• Istio
  • Envoy を統合管理するソフトウェア
  • Control Plane

構成

アプリケーションの代わりにネットワーク層の仕事をする。
メトリクス取得/送信、リトライ等の実行、分散トレーシング用のログの送信、service discovery、load balancing なども行う。
以下の2つのコンポーネントで構成される。

• Data Plane
  • proxy として上記タスクを実行
• Control Plane
  • 各 proxy の管理を行う

https://speakerdeck.com/taiki45/observability-service-mesh-and-microservices?slide=38

課題への対応

対応したい障害	対処法	対処法の実装
サービス間の一時的な障害	リトライ	サービス呼び出し失敗時に再試行
障害が発生しているサービスにリクエストを繰り返しリソースを消費	サーキットブレーカー	障害が発生しているサービスへのリクエストに対して早期にエラーレスポンスを返却してリソースの無駄な消費を防止
障害がサービス機能全体に影響することを防止	バルクヘッド	アプリケーションの構成要素をプールに分離し、1つ失敗しても他が引き続き機能できるようにする
複数サービスにまたがるデータ更新において結果整合性を保証	補正トランザクション	各サービスのデータ更新において、更新前の状態へ復元するための情報を残しておく。ロールバックにおいてその情報を使用

通信方式

同期と非同期

• 同期

  • リクエスト・レスポンス方式

• 非同期

  • パブリッシュ・サブスクライブ方式（ PubSub ）
  • イベントベース
  • ビジネスロジックが中央に集中されず、代わりに様々なコラボレータに均等に割り振られる

• オーケストレーションとコレオグラフィ

  • Web APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式
    • 呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになる
  • イベントをサブスクライブしていて、新規会員登録イベントが発生したら、それを受け取り、それぞれ処理を行うコレオグラフィ方式

• RX (Ractive Extensions)

• 冪等性

プラクティス

• DRY (Don’t Repeat Yourself)
  • 1 つのマイクロサービス内では DRY を破らないけれど、すべてのサービスにわたる DRY の違反には寛大に対処する
  • ロギングライブラリなどはサービス横断で共通化してもかまわない
  • クライアントライブラリは API 開発者が提供しない（クライアントとサーバを密結合にしない）
• バージョニング
  • セマンティックバージョニング
    • MAJOR.MINOR.PATCH
      • MAJOR：後方互換性のない変更
      • MINOR：後方互換性のある追加機能
      • PATCH：既存機能のバグFIX
  • 異なるエンドポイントの共存
    • v1,v2,v3,,,
• Backend for Frontend（ BFF ）
• トランザクション
  • 結果整合性
    • ACID ではなく BASE な考え方
      • ACID
        • A：Atomicity、アトミック性
        • C：Consistency、一貫性・整合性
        • I：Isolation、独立性、トランザクション中に行われる操作は他のトランザクションに影響を与えない事を保証
        • D：Drability、トランザクション処理結果は永続的
      • BASE
        • BA：Basically Available、高可用性
        • S：Soft-State、あるノードの状態は自律的ではなく外部からの情報により変化する、復元可能
        • E：Eventually Consistent、 結果整合性
  • 操作全体の中止
    • サーキットブレーカー
  • 分散トランザクション
  • データポンプ
• デプロイ
  • ビルドパイプライン
    • コンパイルと高速テスト -> 低速テスト -> UAT(User Acceptance Testing) -> 性能テスト -> 本番環境
  • イミュータブルサーバ
  • カナリアリリース
  • ブルーグリーンデプロイメント
• テスト
  • 単体テスト
  • サービステスト
  • エンドツーエンドテスト
• 監視
  • 相関ID
• セキュリティ
  • シングルサインオンゲートウェイ

Istio が有する機能

• ネットワーク制御
• デプロイメント方法（カナリア、 Blue-Green など）
• リトライ／タイムアウト
• 負荷分散
• サーキットブレーカー
  • サービス呼び出しに対する応答に異常を発見すると、それ以降の呼び出しを遮断する仕組み
• バルクヘッド
  • アプリケーションの要素をプールに分離し、1 つの要素が失敗しても、他の要素が引き続き機能できるようにする
• 流量制御
  • トラフィックオーバーしたら Sorry 流し？
• 障害検知
• 監視
• ログ出力

参考

• Azure クラウド設計パターン
• https://www.slideshare.net/oracle4engineer/developers-summit-2018-kubernetes
• A pattern language for microservices ,Chris Richardson
• Service Discovery in a Microservices Architecture, Chris Richardson of Eventuate, Inc.
• Spring特別勉強会レポート(後編),エンタープライズギークス (Enterprise Geeks)
• マイクロサービス アーキテクチャ スタイル
• Light and shadow of microservices

処理方式

• 同期・非同期
  • 同期
  • 非同期
    • ポーリング方式：初回実行依頼をしてから、定期的に実行が終わったか確認しにいく
    • コールバック方式：初回実行を依頼してから、通知が来るまで待つ
• 逐次・並列・並行
  • 逐次：シーケンシャル処理。前から順番に実施。
  • 並列：複数タスクを同時に処理する。
  • 並行：逐次・並列より抽象度が高い。「どんな順番で実行してもよいタスク」に分解して実行。逐次も並列も含む。
• オンライン・バッチ
  • オンライン
  • バッチ：1つのバッチ処理はジョブという。順序制御、リラン制御が大事。
    • オフラインバッチ
    • オンラインバッチ
    • ディレードオンラインバッチ：キューとか挟んでやる。
• メッセージング

デザインパターン

可用性 ※参考

• エンドポイントヘルスチェックモニタリング（Endpoint Health Check Monitoring）
  • 勝手に名前つけた
  • 公開している API や Web サイトのサービスが正常に動作しているかモニタリングする
  • /health のような API を公開し、そのサービスが正常かどうかチェックし 200 を返す仕組みを作り、外から叩いて監視する
• キューベースの負荷平準化
  • 大量のリクエストを捌く必要があり、且つ、リアルタイムで処理結果を返却する必要が無い場合はタスクをキューに詰めて後から処理をする
• スロットリング
  • システムリソースへの負荷が予め設定していた値に到達した場合、設定値を超える処理を受け付けなくする
  • システムが落ちることを防ぐが、ユーザから見て利用制限がかかる

データ管理 ※参考

• キャッシュ
• CQRS（Command and Query Responsibility Segregation：コマンド・クエリ責務分離）
  • 更新（ Command ）と参照（ Query ）のアクセスとデータストアを分離する
  • いわゆるリードレプリカを作成する
• イベントソーシングパターン
  • ちょっとわからん
  • キューで PubSub するのと違いは？
• インデックステーブルパターン
  • DB でセカンダリインデックスがサポートされていない場合に利用
  • 主キーへのアクセスではなく、条件検索の場合インデックスが効かない
  • 頻繁に使う条件の場合は、この条件で指定する値をキーとしたインデックステーブルを作成する
• ビューバターン
  • うーん
• シャーディング
  • データ ストアを水平方向のパーティションまたはシャードのセットに分割
  • 主にデータ量への対応
• CDN
• バレットキーパターン
  • AP サーバを経由してデータのダウンロード・アップロードを行うのではなく、直接ストレージに行う
  • トークンを払い出して行う

設計と実装 ※参考

• アンバサダーパターン
  • アプリケーションと外部サービス間のプロキシとして機能する外部プロセスに配置（サイドカー、Data Plane）
  • リトライ、サーキットブレイク、計測と監視、ログ記録、ルーティング、セキュリティ（TLSなど）、接続・認証
• 破損対応レイヤ
  • サブシステム間にアダプターレイヤーを実装する
  • 最新アプリケーションに組み込まない古いインフラストラクチャ、プロトコル、データ モデル、API、またはその他の機能をサポート
• BFF
• CQRS
  • 重複
• コンピューティング リソース統合パターン
  • あんまり
• 外部構成ストア（External Configuration Store）
  • アプリケーション実行時のパラメータを外部構成ストアに保存
  • アプリケーションには外部構成ストアへのアクセス権限だけ付与しておく
• ゲートウェイ集約パターン / gateway aggregation
  • ほぼ BFF
  • 複数ドメインバックエンドへの処理を集約する役割に言及している点でf BFF と若干異なる
• ゲートウェイ オフロード パターン / gateway offloading（ API Gateway ）
  • 一部の機能は複数のサービスでよく使用される（認証など）
  • 認証、承認、ログ、監視、スロットリング、SSL 終端
• ゲートウェイ ルーティング パターン / gateway routing （ API Gateway ）
  • 単一のエンドポイントを使用して複数のサービスに要求をルーティング
  • クライアントが複数のサービスを使用する必要がある場合、サービスごとに個別のエンドポイントを設定し、クライアントが各エンドポイントを管理するのは難しい
• リーダー選定パターン
  • ピンとこん
• パイプとフィルターのパターン
  • ジョブネット的なやーつ
• サイドカー
  • アプリケーションのコンポーネントを別のプロセスまたはコンテナーにデプロイして、分離性とカプセル化を実現
  • 監視、ログ記録、構成、ネットワーク サービスなどの関連する機能
• CDN
  • 重複
• ストラングラー・パターン
  • 機能の特定の部分を新しいアプリケーションやサービスに徐々に置き換えることで、レガシ システムを段階的に移行

メッセージング ※参考

• 競合コンシューマー パターン
  • 「イベントソーシングパターン」と何がちゃうねん
• パイプとフィルターのパターン
  • 重複
• 優先順位キュー（ Priority Queue ）パターン
  • 読んで字のごとく
  • 並び替えできる（割り込みできる）キューを使うか、優先順位ごとにキューを分けるか
• パブリッシャーとサブスクライバーのパターン（ PubSub ）
  • 「イベントソーシングパターン」「競合コンシューマー パターン」と分けて理解する（後々
• キュー ベースの負荷平準化パターン
  • 重複
• Scheduler エージェント スーパーバイザー（Scheduler Agent Supervisor パターン）
  • Scheduler ：実行されるタスクを構成する手順を準備し、その操作を調整
  • Agent ：リモート サービスの呼び出し、またはタスク内の手順によって参照されるリモート リソースへのアクセスをカプセル化するロジックが含まれ
  • Supervisor ： Scheduler によって実行されているタスク内の手順の状態を監視

管理と監視 ※参考

• アンバサダーパターン
  • 重複
• 破損対応レイヤ
  • 重複
• 外部構成ストア（External Configuration Store）
  • 重複
• ゲートウェイ集約パターン / gateway aggregation
  • 重複
• ゲートウェイ オフロード パターン / gateway offloading（ API Gateway ）
  • 重複
• ゲートウェイ ルーティング パターン / gateway routing （ API Gateway ）
  • 重複
• エンドポイントヘルスチェックモニタリング（Endpoint Health Check Monitoring）
  • 重複
• サイドカー
  • 重複
• ストラングラー・パターン
  • 重複

パフォーマンスと拡張性 ※参考

全部重複、、、

回復性 ※参考

• バルクヘッド
  • アプリケーションの要素をプールに分離し、1 つの要素が失敗しても、他の要素が引き続き機能できるようにする
  • コンシューマーの負荷と可用性の要件に基づいて、サービス インスタンスを別々のグループに分割
  • DB とか HTTP コネクションプールとかかな
• サーキットブレーカー
  • リモート サービスまたはリソースとの接続時に、復旧に要する時間が一定しないエラーを処理
  • リモートサービスの反応が無いときに切る子
• 補正トランザクション
  • 最終的に整合性がある操作を定義する一連のステップの中で、1 つ以上のステップが失敗した場合に、実行された作業を元に戻す
• エンドポイントヘルスチェックモニタリング（Endpoint Health Check Monitoring）
  • 重複
• リーダー選定パターン
  • 重複
• キュー ベースの負荷平準化パターン
  • 重複
• リトライ
  • キャンセルする、再試行する、時間をおいて再試行する
• Scheduler エージェント スーパーバイザー（Scheduler Agent Supervisor パターン）
  • 重複

セキュリティ

• フェデレーション ID
  • 外部の ID プロバイダーに認証を委任する
  • 認証とトークン発行
• ゲートキーパー
  • 専用のホスト インスタンスを使用して、アプリケーションとサービスを保護
  • クライアントと、アプリケーションまたはサービスとの間でブローカーとして機能し、要求を検証して不適切な部分を除去
• バレットキーパターン
  • 重複

AWS

• http://aws.clouddesignpattern.org/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8