## コントロールプレーンとランタイムプレーン

図の左側のコントロールプレーンは、APIとかMuleアプリケーションの設計とかデプロイ・管理に使う機能が含まれる。
内容はExchange・デザインセンター・マネジメントセンターの3つ。

右側のランタイムプレーンは、APIとかMuleアプリケーションがデプロイされてきて、ユーザーが利用できるようにするための機能。内容はMuleランタイムサーバーとサポートサービス。

このコントロールプレーンとランタイムプレーンは、それぞれmule提供を使うか自分で用意するか選べるので、下記の3パターンの方法が選べる。
* 両方mule提供
* 両方自分で用意する
* ランタイムプレーンだけ自分で用意する
（コントロールプレーンだけ自分で用意することはないらしい）

**コントロールプレーン**の環境には以下の4つがある。
1. USクラウド（これがデフォルト！）
1. EUクラウド
1. Mulesoft Government Cloud（政府機関向け）
1. 顧客が独自のデータセンター内でホストする（PCEを使って制御）
※PCE…Anypoint Platform Private Cloud Edition

この4つそれぞれによって使える機能の制限に違いがある。（③④ではフローデザイナーとかランタイムファブリックが使えないとか）
　参考：https://docs.mulesoft.com/hosting-home/

**ランタイムプレーン**のオプションには以下の4つがある。
1. クラウドハブ2.0（フルマネージド型でコンテナ化されたiPaas。世界中の12リージョンにデプロイできる）
3. クラウドハブ1.0（Muleのクラウドベースの環境。コントロールプレーンは同じ環境（＝US/EU/政府のどれか）に存在するものしか管理できないのでそろえる必要がある）
5. ランタイムファブリック（顧客が管理するデータセンターやサードパーティークラウド環境でAPIを実行できるようにしてあげるためのコンテナサービス。物理サーバーやawsにインストールして使用可能。負荷分散やフェイルオーバーができるのが強み。コントロールプレーンはUSかEUのみ管理できるので、政府とPCEは使えない）
6. スタンドアロンランタイム（物理サーバーやawsなどでAPIを実行できる。4種のどのコントロールプレーンも使用できる）

ランタイムファブリックの種類によって使えない機能もある。
クラウドハブ以外ではMQ、オブジェクトストア、データグラフが使えないらしい。なので代わりにMuleクラスタリングなるものが使えるらしい。

コントロールプレーンとランタイムプレーンの可能な組み合わせ。横で見るのがわかりやすい。クラウドハブとランタイムファブリックはPCEとは組み合わせられない。

## Runtime Manager

## IdP=アイデンティティプロバイダとは
IdPというのは、クラウドサービスとかにアクセスするユーザーの認証情報を保存したり管理してくれるサービスのこと。
シングルサインオンのために使われる認証の標準規格になっているSAML認証の一部分として使われる。
上の図のように、ユーザーとSPの間にIdPが挟まって認証のやり取りをしてくれて、ユーザー認証情報をSPと連携することでSAML認証が完了する。
SP＝サービスプロバイダというのは、Office365とかみたいなクラウドサービスのこと。

muleでは、この便利なIdPという機能を最大25個設定することができる。
例えばユーザーがMuleのAPIに対してGETリクエストを送りたいとき、IdPへのリダイレクトが行われ、IdPで認証ができたらAPIからGETが許可されるみたいな感じになる。
サービスプロバイダは直接認証情報（パスワードとか）を保持しないので、攻撃されても安心。

## OAuth2.0とOpenID Connect
OpenID ConnectはOAuth2.0の拡張版である。
OAuth2.0は認可を行うプロトコル。認証は行わない。

例えば、ツイッターからGoogleに保存してあるプライベートな写真を参照したい場合、ツイッターはクライアント、Googleが認可サーバーという関係にあたる。
認可サーバーは許可すると認可コードを発行してクライアントにリダイレクトする。（認可コードが漏れないようにリダイレクトは事前に設定されたURLのみに行える）
クライアントはこの認可コードを認可サーバーに渡すことでアクセストークンを要求できる。このアクセストークンを使って保護されたリソース（Googleに置いた写真）にアクセスできるようになる。アクセストークンにはユーザーのクレデンシャル（ユーザー/パスワード）とかユーザー権限が含まれている。

つまり、アクセストークンを発行する係が認可サーバーである。クライアントが認可コードを使ってアクセストークンをもらう一連のやり取りを標準化したのが**OAuth2.0**である。
※実際には認可コードを発行する時には認可サーバーからユーザーに「こいつ（twitterとか）に権限与えちゃうけどいい？」という確認が入る。

一方、OpenID Connectorの場合はアクセストークンみたいなノリでIDトークンというものを発行する。
IDトークンを発行する係をOpenIDプロバイダーという。
IDトークンを発行する際には、ユーザーからOKを許可をもらうだけではなく本人確認の提示（主にユーザー/パスワード）による認証も行うのがポイント。

ただし、OpenID ConnectorはOAuth2.0の拡張版なので、OpenIDプロバイダーだけでなく認可サーバーも兼ねることができる。そしてIDトークンとアクセストークンを両方要求することができる。

IDトークンを使えば、そのIDトークンを引きまわして色々な場所でユーザー認証をスキップできる。


HTTPコネクタにOAuth2.0の認証機能があり、これを使ってトークン取得を行うことができる。
## 監査ログ
Anypoint platformの組織内でユーザーが行った変更はすべて監査ログサービスによってログに記録されるらしい。すごい。
オブジェクトの操作内容とタイムスタンプ、操作したユーザーがわかる。
ログはデフォルトで6年間で消えるので、それ以上保管したいならダウンロードが必要。
見れるログは自分の所属しているビジネスグループのものだけ。システム管理者または監査ログ閲覧者ロールなら監査ログUIとクエリAPI両方にアクセスできるらしい。

監査ログUIは、Access Management>Bussiness Groupsにある。

## API Gateway
API Gatewayは、クライアントから受け取ったリクエストをそれぞれのマイクロサービスにルーティングしてくれる。
クライアントから直でマイクロサービスにつながないことで、複数のAPIを使う場合に何度も疎通が必要になったりするのを防ぐことができる。

例えば、awsのAPIGatewayでは、大きく分けてAPIの管理と作成が行える。
管理っていう意味では、インフラの管理とか運用、バージョン管理とか認証とかAPIレスポンスのモニタリングとかそういうAPIを支える機能がある。
作成っていう意味では、Lambdaで定義した関数を使ってAPIを作成できる。
つまり、Lambdaで作ったAPIをバージョン管理したり便利に運用したいときに便利ってこと。

そんな便利なAPIGatewayがMuleにも存在します！
3つのランタイムオプションがあるので好きなのを選んでください。

**Anypoint Flex Gateway**(実行されている場所に関係なくAPIを管理して保護することができる。DevOpsやCI/CDのワークフローとシームレスにいい感じに統合できるし、性能もいいので高負荷でも大丈夫)
**Anypoint Mule Gateway**(埋め込みAPIGatewayが含まれているので、コードを記述する必要がない)
**Anypoint Service Mesh**(MuleSoft以外のアプリケーションをAnypointPlatformのエコシステムに組み込むことでマイクロサービスネットワークを拡張する。)

## セキュア設定プロパティ
アプリケーションの設定プロパティにはパスワード等の情報もあるため、ファイルにべた書きすることは避けたい。
そのため、セキュア設定プロパティを使うことで暗号化することができる。

> 用語
> Name:グローバルセキュア設定プロパティの一意になる名前
> Key:復号に使う値
> file：キーが復号するファイルの場所
> Encode:キーが復号するファイルの文字コード。デフォルトはUTF-8
> File Level Encryption:ファイル全体を暗号化する場合はtrueにする。デフォルトはfalse
>
1. セキュア設定プロパティファイルを作ろう
まずはプロパティを定義するYAMLファイルかSpring形式の.propartiesファイルを作成しよう。
配置場所はsrc/main/resourcesか、絶対パスを使用して作成も可能。
2. 1で作ったファイル内でセキュア設定プロパティを定義しよう
暗号化された値を値を![~~~]という書式で囲むことで、セキュア設定プロパティを定義することができる。
このファイルに記載した値は、Muleアプリケーション内のどこからでもアクセスできる。暗号化されていてもされていなくてもOK。ただし暗号化されている場合は文字列として読めるように""で![]を囲う必要がある。

暗号化にはセキュアプロパティツール（ヘルプでjar配布中）を使うことができる。

サンプル
encrypted:
value1: "![nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=]"
value2: "![nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=]"

testPropertyA: "testValueA"
testPropertyB: "testValueB"

3. プロパティファイルをプロジェクトに設定する
ExchangeにあるMuleセキュア設定プロパティ拡張モジュールを使うことでプロジェクトにファイルを設定することができる。設定の方法は、スタンドアロンXMLなるもので設定するか、Anypoint Studio内で設定するかのどっちでもOK。
Studioの方だけ詳しく見てみると、Anypoint StudioでMuleオブジェクトを開いて、MuleパレットからSearch in Exchangeで[Mule Secure Configuration Property Extension (Mule セキュア設定プロパティ拡張)]を検索してAddすることで拡張モジュールを追加することができる。
そうしたら、Global Elemetnsでセキュア設定プロパティの設定を作成して、1で作ったファイルの場所とかKeyとか暗号化の方式とかを記入する。

## 隠しアプリケーションプロパティ（secureProperties）
上のセキュア設定プロパティとは全く別の概念として、安全な隠しアプリケーションプロパティというものが存在する。
例えばDBのパスワードなど、AnypointPlatformユーザーが値を見えてしまうとまずい値を隠すことができる。
この機能を使うと、Runtime Manager上ではプロパティ名だけは見えるが、値は誰も見れないし取得もできないが、実行時にはちゃんと解決される。
内部的にはどうなっているかというと、値は暗号化されていて、CloudHubプロパティデータベースに保存されている。（データベースはユーザ組織ごとに暗号化される）

作成手順
1. mule-artifact.jsonファイルのsecureProperties項目に、隠したいプロパティの項目名を記入する。（ここで定義した名前は定義した場所にかかわらずすべてのプロパティに影響する）
2. ローカルでテストをするため、src/main/resourcesフォルダにYAMLファイルを作って、隠したいプロパティとその値を記載する。
3. Muleアプリケーションをデプロイして、設定ページのプロパティタブを見ると2で記入したプロパティが確認できる
4. 3の画面でapply changesボタンを押してアプリケーションを再起動か再デプロイすると、隠しプロパティ化が完了して画面上で値が見れなくなる（上書きはできる）。この後でmule-artifact.jsonからsecureProperties項目を消しても一度隠したプロパティが公開されることはない。

## Object Store V2
Object StoreV2では、いろんなバッチプロセスやMuleコンポーネントとかアプリケーションを横断してデータとステータスを保存することができる。これを使うことで、他のMuleアプリケーションがセットした値を他のMuleアプリケーションから参照したりができる。
CloudHubアプリケーション内からか、もしくはObjectStore REST APIから使用可能。（オンプレのMuleアプリケーションはCloudHub使えないのでREST APIのみ使用できる）
オブジェクトストアに格納するデータはキーとバリューのペア。
**特徴**
・データは永久ではなく、TTLと呼ばれる一定期間で消える
・データの件数や合計サイズには制限がない！
・データ一件あたりの最大サイズは10MB
・ワーカーと同じリージョンに作られる
・オブジェクトストアコネクタを使うことでデータ書きこみができる（V1/V2どっちも対応）

一定期間で消えるTTLは、ローリングTTLと静的TTLという2種類がある。
**ローリングTTL**は最小30日間でデータが消えるが、最後の7日間の間にデータにアクセスがあればまた+30日間延長されるシステム。つまりアクセスし続ければ永久に消えない。
アクセスといってもなんでもいい訳ではなく、Retrive/Retrive all/Retrive All Keys/Store(保存)でのみ延長され、Contains/Clear/Removeでは延長されない。
**静的TTL**は、entryTtlという設定に自分で削除される期間を指定する。最小は1秒で、最大は30日。100日とか指定したところでエラーにはならないが普通に30日でデータは消える。データを更新するとTTLは指定した期間に改めてリセットされる。

## JMS
非同期通信をJavaEEに取り込むための仕組み。
送る側（Sender）と受け取る側（Receiver）が1:1の関係であるpoint-to-point（PTP）メッセージドメインというパターンと、受け取り側が複数いるPublish/Subscribeメッセージドメインの2種類がある。
PTPではメッセージを格納するのはキューだが、Pub/Subではトピックである。
オールオアナッシングトランザクションで使用可能らしい。

### JMSコネクタ

## Mavenプラグイン
* Mule Mavenプラグイン
このプラグインをpomに追記してやると、コマンドでプロジェクトのjarファイルを作ったり、デプロイしたり、アンデプロイしたりする。

* MUnit Mavenプラグイン
このプラグインをpomに追記してやると、コマンドでMUnitテストを実行できるようになる。テスト自動化とかがしたいなら、これを使えばコマンドとしてテスト実行を組み込めるようになる。

## トランザクション
Muleのトランザクションには、単一リソース（ローカル）と、拡張アーキテクチャ（XA）の2種類がある。

単一リソースでは、JMSなのかVMキューなのかJDBCなのかわからないがどれか一つだけをトランザクション対象とすることができる。不便な分パフォーマンスはXAより高い。

拡張アーキテクチャ（XA）はJMS、VM、JDBCを組み合わせて一連の操作に対してトランザクショングループとすることができる。トランザクションの中でさらにトランザクションを作る（＝ネストする）こともできて、ネストされたトランザクションでロールバックされても親トランザクションはロールバックされるという訳ではない。

どちらにしてもトランザクションの対象になるのはJMS・VMキュー・JDBCのどれかだということ。MQとかObjectStoreは対象外ということだ。（IBMMQはOKそうな気配もあるが、AnypointMQは対象外ということかな？）

## ログの設定
MuleSoftには、アプリケーションログとランタイムログの二つのログがある。

**アプリケーションログ**には、アプリケーションで発生したエラーに関する内容とか、ビルドした内容が含まれる。自分でロガーを設定して吐いたログもアプリケーションログに記述される。

アプリケーションログが見たい場合は、以下の2つのどちらかで見ることができる。
1. AnypointStudioのコンソールウインドウ（Studioで開発してる場合のみ）
2. OSコンソール（コマンドラインからMuleを使ってアプリケーションを実行した場合）
上の内容は、ちゃんとファイルとしても保存されてデフォルトではMULE_HOME/logs/<アプリ名>.logに保存される。
アプリケーションごとに独自のlog4j2.xmlというファイルが生成されるので、その中で保存場所はカスタマイズできる。（global一個で編集はできないので注意）

**ランタイムログ**には、アプリケーションとライフサイクルに関する情報が含まれる。つまり、アプリケーションが開始したとかデプロイした、停止した、アンデプロイされたみたいな情報が含まれる。
ランタイムログの設定は/conf/log4j2.xmlでカスタマイズすることができる。（オンプレでMuleを実行している場合のみ）ログレベルとかも変更できる。
ランタイムログは変なところにあるので基本は見ないが、StudioのHelp> [About Anypoint Studio (Anypoint Studio について)] > [Installation Details (インストールの詳細)] > [Configuration (設定)] をクリックし、[View Error Log (エラーログを表示)]にある。

同期ログと非同期ログという設定も設定ファイルで決められる。同期ログの場合はログを書いている間処理が中断してしまう。非同期ログの場合は中断しない（こっちがデフォルト）。ただしシステムクラッシュが起きた時に最新のログまで記録されない場合があるので、アプリケーションログを監査履歴として使いたい場合は必ず同期ログにする必要がある。

## API機能監視（モニタリング）
API機能監視では、APIの品質に問題がないか&信頼できるかをチェックすることができる。
開発環境か本番環境かにかかわらず、APIの機能がちゃんと動作するかと性能が問題ないか、つまりライフサイクルすべてに問題がないかをテストできるので、ホワイトボックステスト・ブラックボックステスト・監視に利用できる。
監視対象のAPIは、誰でもアクセスできる公開APIでも非公開API（CloudHubのAnypoint Visual Private Cloudにデプロイされて、非公開ネットワークのユーザだけアクセスできる）でもどっちでもOK。MuleでもMuleじゃないAPIでも大丈夫。

監視は、いわばテストを繰り返すスケジュールを組むということ。監視のことをスイートとも呼ぶ。
実行の方式は、下の２つのどちらか。
1. ブラックボックス自動テストCLIを使って、テストを自分で記述してスケジューリングしておく
2. Anypoint MonitoringのFunctinal Monitoringというところで監視を作成する。自分で記述したテストプロジェクトをアップロードすることもできる。

# 模擬試験
A…VPNが違うからダメ？
B…オブジェクトストアが使えるのはCloudHubだけなので×
C…ビジネスグループが違うからダメ？
D…〇

↓CloudHubにデプロイされているアプリのアラート条件一覧
https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager
* CPU使用率
* 指定したテキストが含まれる
* イベント件数
* メモリ使用率
これと、デプロイに失敗とかワーカーが応答しないとかのアラートも追加のパラメータは不要。
よって答えはB。

A…〇
B…全部まとめて検索できるはずなのでAPIごとに調査する必要はない
C…監査ログは6年持つので×
D…監査ログクエリAPIがあればわかることなので×

A…同じワーカーにデプロイされて上書きとかされたとしたらさすがに使用することはできない
B…〇
どうやらデプロイ済みのMuleアプリケーションを編集して再デプロイすると、デプロイ済みだった方の古いワーカーとは別の新しいワーカーにデプロイを始めるらしい。そんでデプロイにもある程度時間がかかるから、その間はすぐに新しいワーカーにリクエストがルーティングされるわけではなくて古いワーカーにルーティングされて、デプロイが完了されたら新しいワーカーにルーティングされるようになる。
CD…普通に考えてデプロイ中エラー返すような不便なつくりはしない
# 用語集
**オーケストレーション**
システムなどの構築・運用を自動化すること
**HAクラスター（High Availability）**
高可用性のこと。サーバーに障害とかが起きても業務を継続敵に稼働できる能力が高いこと。そのために、サーバーを複数台使用して冗長化したりしているシステムのことを指す。
**ノード**
サーバーが複数台集まって構成されるクラスターに対して、そのうちのひとつひとつのことをノードと呼ぶ。
**OAS定義**
OpenAPISpecification、つまりRESTAPIの仕様を記述するフォーマットのこと。YAMLかjsonで記述する。ほぼRAMLでは。
**アーティファクトリポジトリ**
自動デプロイに使うために、継続的インテグレーションが生成したビルドアーティファクトなるものを保管しておく場所のこと。ビルドアーティファクトというのは、配布パッケージとかログとかwarファイルその他もろもろ、ビルドプロセスが作成したファイルのこと。

**不明点**
Muleクラスタリングでできることとは？
SSOとIDトークンは別？
共通データモデルとは？
オブジェクトストアコネクタとREST APIで何が違うのか？
RuntimeManagerエージェントと自動デプロイ
サーバー証明書
インスタンスIDがないとAPIを使えないとは？？