# MCPA Exam Readiness ワークショップ
[TOC]

[](https://hackmd.io/OkSUHDLGQA6APZNv4srOkA)

###### tags: `MuleSoftTraining`

- [MuleSoft Exam Readiness Kit - 認定資格試験への準備キット -](https://salesforce.quip.com/JBhRAIbXU9VO)
- 試験の予約方法や、当日の流れなど、試験準備に関して必要な情報はこちらにて！
- [MCPA データシート](https://training.mulesoft.com/oltpublish/cmsres/downloads/APAAppNet_datasheet_japanese.pdf) で出題範囲を確認
- [MCPA 模擬試験](https://training.mulesoft.com/course/development-fundamentals-mule4/quiz-diy-japanese) で実際の試験時間・問題数・難易度に近い問題を解いてみる
- 少し古い試験範囲から、模擬試験に出題されている場合もあります

# 1. アプリケーションネットワークの基礎 : Explaining application network basics
## Delivery Gapを解決するためのMuleSoftの提案
* 従来のスタイルには限界
* 過重労働
* アウトソーシングによるDependencyの複雑性
* Agile, DevOpsの試みが不十分
* **組み立てブロックの再利用**

## モダンAPI
* 役割
* 特徴
## API主導の接続性
* ３つの層に割り当てるインテグレーションアーキテクチャーのスタイル

* アセットの条件
* 発見可能
* セルフサービス
* 組織全体からコンシューム可能（消費・活用・呼出）
## Outcome~based Delivery(OBD)
## 用語
* API
* API実装
* APIクライアント
* APIコンシューマー
* API Invocation
## High-levelで見たAnypoint Platformコンポーネント
* Anypoint Design Center
* Flow Designer, API Designer
* Anypoint Management Center
* Access / Runtime / API Manager, Analytics, Monitoring, Visualizer
* Anypoint Exchange
* Mule RuntimeとRuntimeサービス
* Mule Runtime, Anypoint MQ, Object Store, VPC, Cloudhub, Anypoint DataGraph, RTF, Connectorsなど
### Anypoint Platformの自動化
- Anypoint CLI
- Mule Maven プラグイン

### Anypoint Platformにおける監査ログ
- 対象
- 変更に関連する全て（変更内容、ユーザー、オブジェクト、ユーザーが行った操作）
- 保持期間：6年

# 2. Establishing organizational and platform foundations
## C4E(Center for Enablement)
* 目的
### Overview
### C4EのKPI
* Exchangeに公開されているアセットの数
* 特定の機関のExchangeアセットのインテグレーションの数
* Anypoint Platformで管理されているAPIの数
* APIクライアントの数
* 再利用されているアセットの数・トレンド
* 特定の機関のAPI呼び出しの回数
* Anypoint PlatformにデプロイされたAPI実装の数
* 自動テストによりカバーされたコードの行数・割合
* 再利用可能なテンプレートの数
* 改善につながった自動化スクリプトの数
* 全体のアップタイムなどの合計
* エラーレスポンス
* Time To Market(本番までデプロイに必要な時間)

## 組織の状況を考慮したHosting Optionの選定
* Control Plane / Runtime Plane
* コントロールプレーンとランタイムプレーンを個別にホストできるように設計
* Anypoint Design Center
- Flow Designer
- API Designer
* Anypoint Management Center
- Runtime Manager
- API Manager
- Access Management
- Analytics
* Control Planeのロケーション
* US Cloud
* EU Cloud
* Gov Cloud
* 顧客がホストするコントロールプレーン
* Anypoint Platform Private Cloud Edition (Anypoint Platform PCE)
* 物理サーバ、仮想サーバ、またはサードパーティクラウド環境 (Amazon Web Services など) でコントロールプレーンをホスト
* **RTF, Cloudhub, Analytics, DataGraphなどが使えない**ことに注意
* Runtime Plane
* Cloudhub
* RTF(Runtime Fabric)
* Standalone
RTFとStandaloneはAnypoint MQやObjectStoreをサポートしないものの、代わりにMule Clusteringをサポート
RTF：Replica間Object共有可能
Standalone：複数のMule Runtime Engineで相互のObjectを共有可能
* **DLB, VPCもRuntime Planeの一部**

* Hosting Option

* MuleSoft が管理するコントロールプレーンとランタイムプレーンで Anypoint Platform を使用
* SLBを利用する場合

* DLBを利用する場合（自分達のVPCを立ち上げる場合）

* 各自のインフラストラクチャ内でランタイムプレーンをホストおよび管理し、MuleSoft が管理するコントロールプレーンと接続
* Non RTF

* RTF
* VM, BM, AWS, Azureなどでデプロイ可能
* MuleSoftが提供はするが、管理はお客さんの責務

* コントロールプレーンとランタイムプレーンの両方を各自のインフラストラクチャ内でローカルにホスト

* Q&A
* RTFはCloudhubを使うのか？
* No, only uses Control plane.
* Standalone == PCE?
* No. It's same with hybrid option which installs mule standalone version.
* Hosting Optionにより、利用できるPlatformのコンポーネントが異なる
* 全部利用できる場合
* API Designer, Access Management, Runtime Manager, API Manager, Exchange, Persistent VM Queue
* 判断のポイント
* API呼び出しとメッセージに関するMetadataや全てのデータアイテムをOnPremiseで管理したい場合 →　Private Cloud Edition
* Time to marketを短縮したい場合　→ MuleSoft Hosted Platform(Cloudhub)
* OnPremise DCにアクセスする際の遅延を防ぎたい　→ 地理的に近い方が有利なため、RTF, PCEが有利
* JVMやRuntimeを細かく管理したい　→ Hybrid(MuleSoft Hosted Control + Customer Hosted Runtime), PCEがCloudhubより有利
* Scailabilityが求められる場合　→ Cloudhubを含むCloudベースのオプションが有利

* Anypoint Platformのデータレジデンシー(保管場所)
* Mule Runtime / Application : 顧客の環境もしくはデプロイしたAWSリージョン
* ObjectStore：Cloudhubならデプロイ先と同じリージョンで、顧客が管理するデプロイならRuntimeのIn memory(Transient)やDisk(Persitent)。
* VM Queue : RuntimeのIn memory(Transient)やDisk(Persitent)
* Anypoint MQ：Cloudhubのみをサポートしているので、デプロイ先と同じリージョン
* メッセージ（データ）、メタデータ
* Runtime -> Management Center
* MuleSoft Hosted Control + Runtime Plane：MuleSoft Hosted Control
* MuleSoft Hosted Control + Customer Hosted Runtime (Hybrid)
* メッセージ：顧客環境で保存・管理
* メタデータ：MuleSoft Hosted Control
* Customer Hosted Control + Runtime : 全て顧客環境で保存・管理
* メタデータの例：CPU/Memory使用率、メッセージやエラーの数、API名とバージョン、APIクライアントに対する地理的データ、HTTPメソッド、違反したAPIポリシー名など（StudentManual 10.4.1）
* ログ：
* 価格
* Hosting Optionを問わず価格ポリシーは全て同一
* Gold < Platinum < Titanum準にサポートの範囲や対応速度について差別化
* 理由できるProductも少しずつ違う。
* Doc : https://www.mulesoft.com/anypoint-pricing
## Identity management vs Client management
* 言葉の定義
* Identity management : Anypoint Platform(Web UI / API)のユーザー管理 with SSO
* Client management : API実装を呼び出すためのクライアント認証管理
* 両方ともIdP(ID Provider)で管理
* Identity management : ユーザーの資格情報を保存・検証
* 最大25個まで外部IdPの連携が可能
* 外部IdPにより発行されたSAML 2.0 BearerトークンでPlatform APIを呼び出せる
* 外部IdPを構成する前に設定された資格情報は、構成してからも変わらずに有効
* Business Group, Dev Phase (Environment)にマッピングして、異なるIdPを設定することが可能
* Groupや環境ごとにTokenが違うのは一般的な事例でもよく見つかる。
* e.g. for Team A (Dev/STG/Prod)
* LDAPはPCE(Private Cloud Edition)のみ利用可能
* https://docs.mulesoft.com/jp/access-management/conf-ldap-private-cloud-task

* Client management : OAuth 2.0アクセストークンの発行・保存・検証
* OAuth 2.0を利用するためには、外部IdPの設定が必須
* デフォルトとして内部のIdPが用意されている。
* トークンは使われておらず、client_id/client_secretで認証
* 後から外部IdPが構成されても、変わらずに有効（構成されてからは、外部IdPにより非OAuth式のクライアント管理もできるようになる）

## Connected Apps
* 外部アプリケーションとの統合を可能に
* Sample
* 組織の管理者：許可されているアプリの一覧を管理（有効化・無効化などを含む）
* Connected Appsを開発する組織の管理者：組織内で新規アプリを登録
* エンドユーザー：

# 3. Designing APIs and API interactions
## 機能要件(FR) / 非機能要件(NFR)
### 機能要件
ビジネス目標を考えた上で、必要なAPIをAPI主導の接続性に基づいた３段階のレイヤーに割り当てる。
- システムAPI（SAPI）
- 更新頻度が一番少ない
- 1つのバックエンドシステムの前に、複数のSAPIを構成することもある。
- プロセスAPI（PAPI）
- 必要なデータの集合体を作成。
- エクスペリエンスAPI（EAPI）
- 複数のPAPIを呼び出す。

### 非機能要件

## 粒度の細かいAPI・API実装（vs 粒度の粗い）
- デプロイ性（Deployability）
- 他のすべてのAPIやAPI実装から独立
- 細かい進化や機能の展開が可能
- 管理（Management）
- 細かく管理はできるが、コストが上がる。
- 拡張性（Scalability）
- ニーズに合わせた細かい調整
- リソース（Resource）
- より多くのリソースを消費
- 複雑さ（Complexity）
- Application Networkの中、アセット間のやりとりが多くなる
- 各APIそのものの複雑さは低減
- 遅延（Latency）
- 全体的に遅延が発生　→ Cachingを検討する必要あり
- 障害モード（Failure mode）
- Application Networkのかで連鎖的な失敗が発生し得るので、普段から準備する必要あり
- チーム組織（Team organization）
- より柔軟な形
- Application Architecture → Business Architecture
- アジャイルとイノベーション（Agility and innovation）
- 迅速にニーズに対応可能 with 短いサイクル・テストスコープ
### APIの再利用性
- 将来の新しいニーズを予想する。
- 特定のサービスに依存を持たないようにする。（e.g. Aggregator用で今は作っていても、Aggregator以外のニーズが入った時も使えるようにする。）

## Domain Driven (Data modeling) : StudentManual p.165
- Enterprise Data Model
すべてのAPIが一つのデータモデルを共有する
部署が違うのに管理しているプロダクトがかぶる場合になる。→ 拡張の際に困難（Overheadの発生）　→ 一般的に通用しない。

- Bounded Context Data Model
下のレイヤーでは、用語が同じであっても組織によっては意味が違ったりするので
一つのモデルですべてのドメインをまとめることは望ましくない。
（bookingという用語について、ホール管理部署とホテルの部署が持っている意味が違う。
）

各用語に対するモデルを組織別に1:1で作ることがよく、区分の境界線をコンテキストという
→下のレイヤーのドメインごとに別途モデルを作ることが望ましい。

- データモデルの特定
- 成功しているEnterprise Data modelがなく、Bounded Contextをどう策定するかについて疑問がある場合小さなBounded Contextがおすすめ
- Bounded Contextデータモデルも RAMLグラ求メントとしてExchangeに公開、同じContext内のすべてのAPIで再利用する。

- Bounded Contextデータモデル間のマッピング →　破損対策レイヤー(Anti-corruption layer)の必要性
- 一種のGatewayやDMZのようなもの。依存性を縮小。New - Legacyの関係において、Legacyに何かしらの変更や破損があった場合でも、Newに関する影響を最小限に収める。
- https://docs.microsoft.com/ja-jp/azure/architecture/patterns/anti-corruption-layer
ドメインが混ざったら、機能を拡張することが難しくなる。
破損対策レイヤーを間に挟むことで、ドメインが混雑することを回避可能

### 関連記事
https://dzone.com/articles/enterprise-data-model-vs-bounded-context-data-mode
***If there is no successful Enterprise Data Model, it is most pragmatic to use Bounded Context Data Models. If there is a prosperous Enterprise Data Model, then all Process APIs and System APIs should reuse that Enterprise Data Model as much as feasibly possible.***

***The API data model of Experience APIs, on the other hand, is decided by the needs of the top-level API clients (such as user-visible apps) and thus is quite incredible to be obeyed by an Enterprise Data Model***

***Aggregator or Customer Self-Service Mobile App/interface is unlikely to agree with an Enterprise Data Model.***

### 複数Bounded Context間の力関係について
* パートナーシップ(Partnership)：対等な力関係
* 顧客サプライヤー(Customer/Supplier
* クライアント：機能を要求
* 呼び出される側：要求を調整
* コンフォーミスト(Conformist)
* クライアント：絶対的に協力

## APIバージョニング
* Semantic Versioning
* メジャー(major) : APIクライアントから必要なAPIの変更・互換性が保てない大きな変更
* マイナー(minor) : APIクライアントが新しく導入された変更・機能を利用する場合を除き、APIクライアント側に変更が必要ない、互換性のある変更
* 新しい機能を使うためには、クライアント側にも変更が必要となる
* パッチ(patch) : ドキュメントの変更など完全に互換性のある小さな修正

## 非同期処理(Polling vs Callback)

* Polling
* 定期的にシグナルをモニタリングする。変更を検知したら作業を始める。単一処理に有利。
* Callback
* 並列処理には有利だが、各プロセッサーを処理する際に他のプロセッサーをブロックすることから遅延が発生する。ただモニタリングに必要なリソースがいらなくなる。

## 冪等性のあるHTTPのメソッド
下記のメソッドはReadOnlyであるため、データに変更を加える恐れがない。（重複処理を起こさずに再送できる）
Cachingしたレスポンスを返せる。
* 安全なメソッド
* GET
* HEAD
* OPTIONS
* 冪等性を求めているメソッド
* GET
* HEAD
* OPTIONS
* PUT
* DELETE

### Cachingに関わるHTTP Header
* Cache-Control
* Last-Modified
* ETag
* If-Match, If-None-Match, If-Modified-Since
* Age

CachingのためにはStorage管理や必要に応じてRequest/ResponseのHeaderを操作する必要がある。

Cacheable TraitというRAML Fragmentとして公開および再利用可能
Cachingポリシー（TTLなど）はBiz側と要相談

## HTTP Optimistic concurrency
目的：リソースの同時更新が警告なしに行われることを防ぐ
同時修正できないように保護する。Header情報(e.g. If-Match, Resource Version ID)を利用した比較

**ただ明確なビジネス的価値とニーズがある場合のみ実装する**

## RAMLを利用した再利用可能なアセットの作成や公開

# 4. Following API-led connectivity
## ビジネスプロセスを考慮したAPI実装

## API-led connectivityにおいてのレイヤー
* 各レイヤーAPIの変更に対する動機(Motivation)
### やめるべきな今のArchitecture😖

### API主導の接続性に基づいたArchitecture😀

## リクエストや組織の特性を考慮したバックエンドシステムのデータモデリング
### システムAPIによるバックエンドシステムからの抽象化
#### 一般的なガイドライン
* 単一責任の原則に従う
* 大きなバックエンドシステムの場合、複数のシステムAPIが構成されることがある。
* Case1：Enterpriseデータモデルが利用されている場合
* Enterpriseデータモデルに従い、API実装はEnterpriseデータモデルとバックエンドシステムのデータモデル間での変換を行う
* Case2：Enterpriseデータモデルが利用されていない場合
* 各システムAPIをBoundedContextに割り当てて、対応するモデルを利用
* API実装はBounded Contextモデルとバックエンドシステムデータモデル間での変換を行う
* Bounded Contextのデータモデルとバックエンドシステムのデータモデルはあくまで別のもの→変換がその分重要な作業になる
* Case3: Enterpriseデータモデルが使われていない場合、かつ、Bounded Contextデータのクリーンなモデルを定義することに苦労すると考えられる場合
* システムAPIのAPIデータモデルは、バックエンドシステムのデータ型をミラーしたデータ型を利用する（バックエンドのモデリングを従う）

## Contract-first vs Contract-last

# 5. Governing APIs on Anypoint Platform
| Basic Endpoint | Proxy Endpoint |
|---|---|
|  |  |

## APIの特性や制約を考慮した保護政策(APIポリシー)
* Provided(Default) : すぐに利用可能な
* カテゴリー
* セキュリティー
* Basic Authentication - LDAP
* LDAPのCredentialを利用

* Basic Authentication - Simple
* Username, Passwordでの認証
* IP Blocklist
* IP Whitelist
* JSON Threat Protection
* 文字数などを制限
* XML Threat Protection
* 文字数などを制限
* JWT
* 使う理由
* Sessionサーバーが特に必要ない
* Microserviceで有利
* 懸念
* Token自体に情報を含めている
* Tokenが長くなったら、Network的に負荷の余地がある
* Statelessなので、任意削除ができない
* Doc
* https://blogs.mulesoft.com/dev-guides/how-to-tutorials/json-web-token-validation/
* https://jwt.io/#debugger

* OAuth 2.0 Access Token Enforcement Using Mule OAuth Provider Policy

* OpenAM Access Token Enforcement
* OpenAMとは？
* https://github.com/OpenIdentityPlatform/OpenAM
* PingFederate Access Token Enforcement
* PingPederateとは？
* QoS(Quality of Service)
* HTTP Caching
* API実装からHTTPレスポンスを保存
* Rate Limiting
* Rate Limiting, SLA-Based
* Spike Control

* コンプライアンス
* Client ID Enforcement
* CORS
* トランスフォーメーション
* Header Injection
* Header Removal
* トラブルシューティング
* Message Logging
* Custom
Defaultポリシーでは対応できない場合使用する。
例えば、APIを使うための認証が失敗した場合、単なるエラーログやステータスコードを返すわけではなく、Customizedされた詳細の情報などをPayloadに追加で加えたいとき使う。　← Defaultでは対応できるポリシーがない。
https://docs.mulesoft.com/gateway/1.1/policies-custom-getting-started
https://docs.mulesoft.com/jp/api-manager/2.x/policies-custom-landing-page
https://docs.mulesoft.com/api-manager/2.x/custom-response-policy-example#use_case

mvn -Parchetype-repository archetype:generate \
-DarchetypeGroupId=org.mule.tools \
-DarchetypeArtifactId=api-gateway-custom-policy-archetype \
-DarchetypeVersion=1.2.0 \
-DgroupId=aec3bb73-7577-44b7-981a-c50e1f5b17dd \
-DartifactId=custom-response-policy-demo \
-Dversion=1.0.0 \
-Dpackage=mule-policy

[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating project from Archetype: api-gateway-custom-policy-archetype:1.2.0
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: groupId, Value: aec3bb73-7577-44b7-981a-c50e1f5b17dd
[INFO] Parameter: artifactId, Value: custom-response-policy-demo
[INFO] Parameter: version, Value: 1.0.0
[INFO] Parameter: package, Value: mule-policy
[INFO] Parameter: packageInPathFormat, Value: mule-policy
[INFO] Parameter: policyDescription, Value: demo policy for checking the behavior
[INFO] Parameter: package, Value: mule-policy
[INFO] Parameter: policyName, Value: custom-response-policy-demo
[INFO] Parameter: groupId, Value: aec3bb73-7577-44b7-981a-c50e1f5b17dd
[INFO] Parameter: encryptionSupported, Value: false
[INFO] Parameter: minMuleVersion, Value: 4.1.1
[INFO] Parameter: artifactId, Value: custom-response-policy-demo
[INFO] Parameter: exchangeRepositoryUrl, Value: https://maven.anypoint.mulesoft.com/api/v1/organizations
[INFO] Parameter: version, Value: 1.0.0
[INFO] Project created from Archetype in dir: /Users/woohyeok.kim/Desktop/work/server-config/custompolicies/custom-response-policy-demo
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:14 min
[INFO] Finished at: 2022-08-31T15:07:52+09:00
[INFO] ------------------------------------------------------------------------

* Automated：すべてのAPIに対して、自動的に適用させるポリシー

## ポリシーのセッティング
* ポリシー自体はRuntimeに含まるものではなく、API実装がAPIManagerからダウンロードをしてくる。

* Without Proxy

* With Proxy

* RTF with k8s
Anypoint Service Meshを利用する。

## RAML仕様のアップデートが求められる変更
- Client ID Enforcement
Policiesの方で、Snippetを確認することが可能
- 全てのAPIクライアントと実装間のコントラクトの変更は、RAML仕様にもきちんと反映されているべき

## レイヤーに対するポリシーの設定

## OAuth 2.0 の文脈における Anypoint Platform、外部 ID プロバイダ(IdP)、ビジネスグループ、および APIクライアントの関係
- Anypoint Platform上でのClient managementは、外部OAuth2.0プロバイダと同期して保存・管理はされない。

## Anypoint VPC(DLB)の使用を必要とする要件
* DLBとAPI実装の間の双方向認証
* カスタムドメインに関するHTTPS接続
* 外部からのリクエストを、API実装に紐づくためのMapping Rule

## カスタムAPIポリシーが必要なシナリオ
* 既存のポリシーでは対応できない場合
* 例えば、特手のDBからアカウント情報を取得し、それをAPI実装を呼び出す際のBasic AuthのInputとして使いたい場合。

## APIプロキシー
* 1 proxy → 1 API
* ポリシーを適用する際に、Latencyが発生するので、SLAを考慮して設定すべき。

## API Gateway
* Gateway Policies
* Doc : https://docs.mulesoft.com/gateway/mule-gateway-capabilities-mule4#:~:text=Mule%20Runtime%20includes%20an%20embedded,having%20to%20write%20any%20code
## API Gatekeeper
* APIデプロイの際、ポリシーが反映される間にAPI望ましくないアクセスが入ることを防ぐ
* その時は503レスポンスを一時的に返す。
* Docs
* https://docs.mulesoft.com/gateway/1.1/mule-gateway-gatekeeper

## Service Mesh

## Anypoint Security / Edgeポリシー (for RTF)
（先端にあるからEdgeだと呼ぶだけ）
### ポリシーの適用フロー

### Tokenization

# 6. Controlling access to APIs
## Client IDとSecretのAPIへの渡し方
- Requestを送る際に、Headerを使う。

## API Clientへのアクセス許可
- ExchangeからRequest Access
- 承認フローにつきましては、自動化することが可能。
- 自動承認の際には、下記のようなメールが管理者に届く。

# 7. Delivering APIs
## API実装に対するDevOps実現
### DevOps

### CI/CD・テスト自動化
Mule Maven Pluginを使い、テスト、Packaging、Deployなどが自動化可能

## 単位テスト(Unit Test) vs 統合テスト(Integration Test)
## MUnit
*
## Autodiscoveryの作動原理
* Runtime -> API Manager
* ポリシーのダウンロード・管理やAnalyticsデーターの生成
* Autodiscoveryにより、API実装がAPI Managerからトラッキングされる。
* APIインスタンスIDは、API ManagerのSettingsから取得
* 前提
* API実装がAnypoint Platform Credentialにより制御
* API実装にAutodiscoveryエレメントを設定

* https://docs.mulesoft.com/gateway/1.1/mule-gateway-autodiscovery-overview
## API実装の再デプロイが必要な場合
TBU

## Error Tolerance

## CQRS

# 8. Deploying Mule applications to Cloudhub
## Cloudhubでのデプロイ
## Cloudhubでのネットワーク要素
* Cloudhub アーキテクチャ
* AWS EC2ベース
* アプリケーションごと最大Workerの数：８
* Shared worker cloud
* 失敗したら自動的に再起動
* ちゃんと生きているWorkerのみLBの対象となる。
* ObjectStoreが利用可能

* Auto Scaling可能
* Route53に基づき、CloudhubのDNSを管理

* Doc : https://docs.mulesoft.com/runtime-manager/cloudhub-networking-guide
## 適切なWorkerサイズの選定
## ObjectStore
* 1 MuleApp : 1 ObjectStore instance
* Appの横断は不可
* Transaction / Queryサポートはない　← ObjectStoreはDBではない。
* 内容はRuntime Managerで公開される。
* ObjectStore REST APIにてアクセス可能
* TTLは最大３０日
* キーのエントリの数は無限、値の容量は１０MBまで。
* AWSリージョン内のAZにデプロイされ、HAを達成
* 送受信中および保管中の際には暗号化。
* Persistent
* 特別な設定なしで使える。(_defaultUserObjectStore)
* Transient
* InMemoryなので、再起動とかしたら終わり。

### その他のキーワード
* Runtime Manager
* Doc : https://docs.mulesoft.com/jp/runtime-manager/
* Runtime Manager Agent
* Cache
* Cacheのスコープ
* It's useful when
* frequently called
* repeatable
* Cache vs ObjectStore

* Anypoint VPC
* Organization / Business Groupに対して作成可能
* Shared workerを利用せずにデプロイ可能
* Shared worker cloudと同じくAWS VPCに構成されているが、ロジカル的に分離されている。
* ただ、AWS VPCに対するアクセスは提供していない。
* 既存のAWS VPCをAnypoint VPCに転用することも不可
* Private Address(CIDR Block)の範囲 / Regionは、一度作成されると変更が不可能
* Shared workerもVPCのworkerもPublic / Private Addressが割り当てされる。Cloudhub DNSがそれらの名前解決を行う。(MuleSoftのControl Plane側で管理)
* Anypoint VPCの管理者は、VPC Firewallのみを管理
* 顧客のDNSサーバーを使うのも可能。もちろんAnypoint VPCからアクセス可能なところにある必要がある。
* Mapping between VPC and Environment : Many to Many
* IPsec TunnelやAWS Direct Connectを使って、顧客のOn Premiseと繋げられる。
* IPSec VPN

* VPC Peeringを使うことで、顧客のAWS VPCに繋げることも可能。

* AWS VPCと繋げるなら、同じリージョンにあるべき。
* Public Internetを使わずに全てのTrafficはAWSの中で完結
* Anypoint VPC同士でのPeeringは不可能
* GCP, AzureとのVPC Peeringは可能
* GCP : https://blogs.mulesoft.com/api-integration/security/setting-up-vpn-with-google-cloud/
* Azure : https://help.mulesoft.com/s/article/How-to-establish-a-VPN-connection-between-Azure-and-Cloudhub
* この場合、 AnypointのRegionとなるべく地理的に近いところのRegionを選ぶべき。
* Transit Gatewayを使い、顧客のAWS VPCそしてOn Premise環境に繋げることもできる。
* 組織のクラウドリソースとOn Premiseのデータセンターを1つのネットワークに効果的に統合
* VPC Connection Doc : https://docs.mulesoft.com/jp/runtime-manager/vpc-connectivity-methods-concept

# 9. Architecting performant and resilient APIs
## API性能の改善
* Horizontal vs Vertical Scaling
## SLB(Shared) vs DLB(Dedicated)
* Workerに関するあれこれ 

* SLB
* AWS ELB(Elastic Load Balancing)ベース
* DNSエントリーは、「CNAME」
* 80(http)/443(https) -> 8081(http)/8082(https) -> MuleApps' workers (Round Robin)
* 証明書はMuleSoftで管理
* DLB
* Anypoint VPCにデプロイされたMuleアプリケーションが対象
* IPの割り当て 
* VPCの非公開範囲でPrivate Addressが2つ以上
* Public Addressも。（Aレコード）
* 任意の自社ドメインをCNAMEとして登録可能
* e.g. https://ranking.hellomule.com/daily/

* 公開用APIに加え、VPC内の非公開API用のDLBを作成することも可能
* すなわち、複数のDLBが生成可能
* 証明書は顧客が管理（CNAMEをカバーする）
* APIクライアントは、LB上の証明書だけを確認して、LB~MuleAppのところの証明書は特に気にしない。
* （非推奨アプローチ）LBを経由せずにMule Workerに直接アクセスする場合は、LB ~MuleAppの証明書を確認する。（Self-signed CRTの場合、クライアントはそれを受け入れられる設定が必要になる可能性がある。）

## サンプルアーキテクチャ

## Single points of failiure (失敗しうるところ)
* HW / VM
* Runtime, JVM, OS
* Network (Switch, Router etc.)
* API Policy, Proxy, LB, Cloudhub worker/replica
* Impl itself

## API実装呼び出しのためのクライアント設計(Fault-Tolerant)

* Timeout
* Retry
* Circuit Breaker
* API呼び出しを監視
* 一定回数失敗したら、失敗させて後にCircuitを開ける。
* 即時失敗させることで、API実装が回復する時間を稼ぐ
* 開きの状態でConnectionが貯まることを防ぐ
* 一定時間後に、徐々に呼び出しを再開する。（partial s-inのような状態）
* 状態の確認が必要なので、Circuit Breakerはネットワーク全体で共有されるアプリケーションのリソースであることが要求される。
* Circuit BreakerがWebAPIそのものであるケース
* Custom Policyとして実現
* https://github.com/mulesoft-catalyst/circuit-breaker-policy-mule-4
* APIを呼び出す際のFallback
* Fallback用のServerを用意する。（代わりのサーバー）
* s-out側のサーバーを利用することも。
* Opportunistic parallel web
* 失敗の可能性を高いと想定した上で、2つのAPI実装に同時にリクエスト送信。
* Cached fallback
* Static Result

## CQRS
* 読み取りと書き込みの独立した最適化
* 場合によって、更新タイミングによって若干古いデータが返されることがある。
* Command用・Query用

## DevOpsの理解

# 10.Monitoring and analyzing application networks
## 監視・アラートのためのデータ生成や転送

## Anypoint Platformで収集されるメトリックス(Metrics)
* Doc : TBU
##
##
### その他のキーワード
* Functional Monitoring
Pollingにて定期的にAPI実装のLivenessやReadinessをチェック
* Anypoint Visualizer

* Anypoint Analytics
* APIの呼び出しを分析する。
* Metric
* リクエストの数
* レスポンス時間の平均
* リクエスト・レスポンスのペイロードサイズ
* Client ID、地理情報などのClientのProperties
* HTTPメソッドなど呼び出しそのもののProperties

* Alert
* From Runtime Manager：特定の環境に対してセット![Uploading file..._5ijwza01z]()

* CPU Usage, Memory Usage, Deploy Fail, Thresholdなど
* From API Manager：特定のAPIに対してセット

* Request count：いくら以上だったら。。
* Response code：特定のレスポンスだったら。。
* Policy violation
* Response time：いくら以上かかったら。。
* From Anypoint Monitoring：API、アプリケーション、サーバーに対してセット
* Application 
* Server 
* API 
* Anypoint Monitoringからセットできるアラートの数が限られているため（契約による）、Runtime ManagerやAPI Managerのアラートを積極的に活用することがおすすめ。

* Custom alert
* Advanced alert
* Auto Scaling