目的

CloudHubにて3階層（Experience APIs、Process APIs、System APIs）のAPIを構築する場合の各階層間のアクセス方法（Experience API → Process API、Process API → System API）について考察する。

前提条件

VPC

Firewall Rules

Type	Source	Port Range
http.private.port	Local VPC	8091
https.private.port	Local VPC	8092

DLB

Name: dlb01
Whitelisted CIDRs: 特定の送信元のみ許可する想定
Certificates: api.example.com

Input Path	Target App	Output Path	Protocol
/{app}/	{app}	/	http

Application

Experience API: exp-api-v1 / worker x2
Process API: proc-api-v1 / worker x2
System API: sys-api-v1 / worker x2

アクセス経路

3階層間のAPIアクセスの宛先として以下の4つが考えられるが、有力なのは「DLB内部Endpoint」と「Worker内部Endpoint」である。

DLB外部Endpoint

API ConsumerからExperience APIにアクセスするのと同様に、DLBの外部アドレスに対してアクセス要求する。
この場合、Workerからインターネット側へのアクセスとなり送信元はWorkerの公開IPアドレスとなるので、DLBのWhitelistにExperience API Workerの公開IPアドレスを登録する必要がある。
DLBでIPアドレス制限を行っている場合は、アプリが増える度にWhitelistへの登録が必要なので現実的ではない。（Static IP機能でIPアドレスを固定化できるが数に限りがある）
　
　Experience API Worker [exp-api-v1]
　　　　　↓　https://api.company.com/proc-api-v1/ （dlb01.lb.anypointdns.netのCNAME）
　DLB外部Endpoint
　　　　　↓
　Process API Worker [proc-api-v1]

DLB内部Endpoint

DLBの外部Endpointは<DLB名>.lb.anypointdns.netだが、internal-<DLB名>.lb.anypointdns.netでVPC側の内部Endpointのアドレスが返される。
このFQDNに対してアクセスする場合は、送信元はWorkerの内部IPアドレスとなりインターネット側に出ることはないのでWhitelistの登録は不要に思えるが、実際は必要なのでVPCに割当てたCIDRsをWhitelistを登録しておく必要がある。
DLBは通常はHTTPSのみ許可する設定で運用するので（Inbound HTTP Mode: Off）DLB内部Endpointにアクセスする際もHTTPSとなるが、外部アクセス用のSSLサーバ証明書のCNはカスタムドメインのFQDN api.domain.comとなっている筈なので、Workerからinternal-dlb01.lb.anypointdns.netでアクセスするとSSL接続エラーとなる。
回避方法としてinternal-dlb01.lb.anypointdns.netをCNにしたオレオレサーバ証明書を用意する方法も考えられるが、Process APIやSystem APIのRAMLをExchangeに登録して自動生成されるコネクタを使用する場合、このコネクタには独自のサーバ証明書を指定する設定が無く、この方法は利用できない。
カスタムドメインに内部アクセス用のinternal-dlb01.lb.anypointdns.netをapi-private.company.comとしてCNAME登録し、CNがapi-private.company.comのサーバ証明書をパブリック認証局で発行し、DLBに登録すればSSL接続エラーを回避する事は可能ではある。
　
　Experience API Worker [exp-api-v1]
　　　　　↓　https://internal-dlb01.lb.anypointdns.net/proc-api-v1/
　DLB内部Endpoint
　　　　　↓
　Process API Worker [proc-api-v1]

Worker外部Endpoint

Workerの公開IPアドレスを返すmule-worker-<アプリ名>.<リージョン>.cloudhub.ioに対してアクセスする場合、アクセス元のWorkerも公開IPアドレスからの発信となる為、VPCのFirewall Rulesでアクセス元のWorkerの公開IPアドレスを追加する必要がある。これは外部からのアクセスを禁止したいVPCの目的にそぐわない。
※<アプリ名>.<リージョン>.cloudhub.ioで返されるのは共用ロードバランサーのIPアドレス。
　
　Experience API Worker [exp-api-v1]
　　　　　↓　https://mule-worker-proc-api-v1.jp-e1.cloudhub.io/
　VPC Firewall
　　　　　↓
　Process API Worker [proc-api-v1]

Worker内部Endpoint

Workerの外部Endpointはmule-worker-<アプリ名>.<リージョン>.cloudhub.ioだが、mule-worker-internal-<アプリ名>.<リージョン>.cloudhub.ioでVPC側の内部Endpointのアドレスが返される。
このFQDNに対してアクセスする場合は、送信元はWorkerの内部IPアドレスとなり同アドレス空間のWorkerに直接アクセスする形となる。
通常はDLBをSSL終端としMuleアプリはHTTPで待受する構成なので3階層間の通信もHTTPとなり、DLB内部EndpointのようなSSLサーバ証明書の課題は発生しない。
　
　Experience API Worker [exp-api-v1]
　　　　　↓　http://mule-worker-internal-proc-api-v1.jp-e1.cloudhub.io/
　Process API Worker [proc-api-v1]