Active Assist / Recommender

解決する課題

クラウドは使い始めると、過剰なスペックや使われていないリソース、広すぎる権限が少しずつ積み上がります。Active Assist / Recommender は、各サービスの使用状況を分析し、改善点を「推奨（recommendation）」として提示することで、この見えにくい無駄を自動で洗い出します。

• VM などのスペックが過大/過小で、コストや性能に無駄がないか知りたい
• 使われていないリソース（アイドル VM、未接続の永続ディスクや IP）を見つけて止めたい
• 広すぎる IAM 権限を、実際の使用実績に基づいて絞りたい
• コミットメント（確約利用割引 / CUD）を、今の使用量からいくつ買えば得かを知りたい
• これらをサービス横断で一覧化し、節約見込みとあわせて棚卸ししたい

主要概念と用語

• Active Assist: Google Cloud の最適化提案ファミリー全体のブランド名。配下に複数の Recommender がぶら下がる
• Recommender（レコメンダー）: 特定の最適化観点ごとの推奨を生成するエンジン。例として VM のマシンタイプ適正化、アイドル VM 検出、アイドル永続ディスク/IP 検出、IAM ロールの適正化、**確約利用割引（CUD）**などがある
• 推奨（Recommendation）: 「このリソースをこう変えると良い」という具体的な提案。多くは推定されるコスト削減額などの効果（impact）を伴う
• 分析情報（Insight）: 推奨の根拠となる観測・分析結果。推奨が「対処」なら、インサイトは「気づき」にあたる
• 推奨の状態（State）: ACTIVE（未対応）、CLAIMED（対応中）、SUCCEEDED／FAILED（適用結果）、DISMISSED（却下）といったライフサイクルを持つ
• 推奨ハブ（Recommendations Hub）: コンソール上で各種推奨を横断的に確認できる集約ビュー
• 適正化（Rightsizing）: 過去の使用率に基づき、リソースの大きさを実需に合わせて見直すこと

仕様・制限・クォータ

• Recommender は提案を出すだけで、原則として変更を自動適用しない。適用するかどうかは利用者の判断（承認）に委ねられる
• 推奨は対象リソースの過去の使用状況を一定期間（多くは数週間程度）観測したうえで生成される。リソースを作りたてだと十分な推奨が出ないことがある
• 推奨はプロジェクト/ロケーション/Recommender 種別の単位で照会する。種別ごとに識別子（例: google.compute.instance.MachineTypeRecommender）が決まっている
• 適正化や CUD の削減額は推定値であり、実際の請求は使用状況の変動で変わりうる
• API のレート上限などのクォータが存在し、必要なら引き上げ申請が可能
• 推奨を見る/適用するには対象リソース側の権限に加え、Recommender 用の IAM ロールが必要

内部の仕組み

各 Google Cloud サービスのメトリクスや構成・利用ログを Recommender が定期的に分析し、ヒューリスティックや機械学習で「あるべき状態」とのギャップを推定します。たとえば VM のマシンタイプ適正化では、一定期間の CPU/メモリ使用率のピークや傾向を見て、過大なら一段小さいマシンタイプを、過小なら大きいタイプを提案します。

• 分析の結果はまずインサイトとして蓄積され、対処可能なものが推奨に変換される
• 推奨は状態機械（ACTIVE → CLAIMED → SUCCEEDED/FAILED など）で管理され、適用や却下に応じて状態が遷移する
• 推奨の生成は継続的に更新されるため、構成や使用量が変われば内容も更新・失効する

設計パターン / ベストプラクティス

• まず推奨ハブで全社/全プロジェクトの推奨を棚卸しし、削減見込みの大きいものから着手する
• VM はマシンタイプ適正化とアイドル VM/ディスク/IP 検出を組み合わせ、無駄なリソースを定期的に掃除する
• IAM はロール適正化（IAM Recommender）で、実際に使われていない権限を外して最小権限に近づける
• 安定したベースライン使用量には、CUD レコメンダーの提案を参考に確約利用割引を購入してコストを下げる
• 推奨は BigQuery エクスポートで蓄積し、傾向分析やレポート化、FinOps の定例レビューに乗せる
• 重要な本番リソースはいきなり適用せず、まず検証環境やメンテナンス枠で影響を確認する

運用・監視

• 推奨の確認・適用はコンソール（推奨ハブ）、gcloud recommender、または API から行う
• 推奨が出ない → 対象リソースの観測期間が不足していないか、Recommender 種別やロケーション指定が正しいかを確認
• 権限エラー（PERMISSION_DENIED）→ Recommender の閲覧/適用ロール（後述）と、変更先リソース側の操作権限の両方を確認
• 大規模な棚卸しは推奨を BigQuery にエクスポートし、プロジェクト横断で集計・可視化する
• 適用後は Cloud Monitoring で対象リソースの使用率や性能を観察し、過剰な縮小で性能問題が出ていないかを確認する

コスト

Active Assist / Recommender 自体の利用（推奨の閲覧・適用）は、一般に追加料金なしで使えるのが基本です。価値は「提案に従ってコストを下げる」ことにあり、削減効果はあくまで推定の節約額として提示されます。

セキュリティ

• IAM Recommender / ポリシー分析情報は、実際の権限使用実績から過剰な権限を可視化し、最小権限化を後押しする
• 推奨の閲覧・適用は IAM ロールで制御する。閲覧系（roles/recommender.viewer 系）と適用系を分け、必要な人だけに付与する
• 推奨の適用は実リソースの変更を伴うため、適用権限は限られた運用者に絞り、誰がいつ適用したかを Cloud Audit Logs で追跡する
• 自動適用を組む場合は、サービスアカウントの権限を最小化し、ガードレール（対象の限定、ドライラン、承認フロー）を必ず挟む

Well-Architected の観点

• コスト最適化（Cost）: 適正サイズ・アイドル資源の削減・確約利用割引の提案で、使っていない/使いすぎている支出を継続的に削る中核機能
• パフォーマンス効率（Performance）: 過小スペックの検出により、リソース不足による性能劣化を是正できる。適正化は「小さくする」だけでなく「適切な大きさに合わせる」こと
• 運用上の優秀性（Operational）: 推奨を BigQuery に集約し定例レビューに組み込むことで、最適化を一過性でなく継続的なプロセスにできる
• セキュリティ（Security）: IAM ロール適正化を通じて、運用しながら最小権限へ近づける改善ループを回せる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# プロジェクトの「マシンタイプ適正化」推奨を一覧（特定ゾーン）
gcloud recommender recommendations list \
  --project=PROJECT_ID \
  --location=asia-northeast1-a \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --format="table(name, primaryImpact.category, stateInfo.state)"

# 個別の推奨の中身（提案内容・推定効果）を確認
gcloud recommender recommendations describe RECOMMENDATION_ID \
  --project=PROJECT_ID \
  --location=asia-northeast1-a \
  --recommender=google.compute.instance.MachineTypeRecommender

# 推奨を「対応中（CLAIMED）」にマークしてから実リソースを変更する
gcloud recommender recommendations mark-claimed RECOMMENDATION_ID \
  --project=PROJECT_ID \
  --location=asia-northeast1-a \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --etag=ETAG \
  --state-metadata=reviewedBy=ops

# IAM ロール適正化の分析情報（未使用権限の気づき）を一覧
gcloud recommender insights list \
  --project=PROJECT_ID \
  --location=global \
  --insight-type=google.iam.policy.Insight \
  --format="table(name, category, stateInfo.state)"