Salesforce 認定 MuleSoft Platform アーキテクト 無料問題 10 / 10 ・ 分野9: アプリケーションネットワークの監視と分析
API Manager から API プロキシを CloudHub にデプロイして運用している。プロキシのデプロイが失敗したときと、ワーカーの CPU 使用率が高い状態が続いたときに通知を受けたい。Anypoint Platform のアラートの系統の説明に合うものはどれか。
- CPU 使用率は API インスタンスのアラートで扱い、デプロイの成否はランタイムのアラートとして別に設定する
- プロキシは API インスタンスに結び付くので、デプロイの成否も CPU 使用率も API インスタンスのアラートの条件として設定する
- デプロイの成否も CPU 使用率もランタイムのアラートで扱い、API インスタンスのアラートや契約のアラートとは別に設定する
- デプロイの成否は契約のアラートと同じく自動で通知され、CPU 使用率はランタイムのアラートとして別に設定する
正解と解説を見る
正解: C
正解の理由
アラートの概念のページは、Anypoint Platform のアラートを、インスタンスアラート・契約のアラート・ランタイムのアラートの3種類に分ける。インスタンスアラートは API インスタンスへの要求の振る舞いや性能の異常を、契約のアラートはクライアントアプリの契約に関わる操作を知らせる。「Runtime Alerts」は、ランタイムのアラートは API のアラートや契約のアラートとは別のもので、例として CPU 使用率・Secure Data Gateway の状態・デプロイの成功や失敗を挙げる。API プロキシであっても、デプロイの成否とワーカーの資源はアプリを動かすランタイムの側の出来事なので、ランタイムのアラートとして設定する。
違う選択肢
「プロキシは API インスタンスに結び付くので、デプロイの成否も CPU 使用率も API インスタンスのアラートの条件として設定する」… プロキシが API インスタンスに結び付いていても、インスタンスアラートが見るのは API への要求の振る舞いや性能である。デプロイの成否やワーカーの CPU 使用率はランタイムのアラートの例として挙がっていて、インスタンスの側で探しても設定できない。
「デプロイの成否は契約のアラートと同じく自動で通知され、CPU 使用率はランタイムのアラートとして別に設定する」… 自動で届くのは契約のアラートで、アクセスの申請の承認・保留・取り消しなど、契約の操作が起点になる。デプロイの成否は契約の操作ではなく、CPU 使用率と並んでランタイムのアラートの例に挙がっている。
「CPU 使用率は API インスタンスのアラートで扱い、デプロイの成否はランタイムのアラートとして別に設定する」… CPU 使用率は、デプロイの成否と並んでランタイムのアラートの例に挙がっている。API インスタンスのアラートの条件ではないので、2つに分けて設定する作りにはならない。
押さえどころ
3種類は、何が起点かで見分ける。API への要求の振る舞い（インスタンスアラート）、クライアントアプリの契約の操作（契約のアラート）、アプリを動かすランタイムの状態（ランタイムのアラート）である。同じ API プロキシでも、プロキシを載せたワーカーの状態はランタイムのアラート、契約の承認の連絡は契約のアラートと、起点で系統が分かれる。