変更要約: Professional Cloud Developer 第4章を新規作成（ドメイン3「デプロイ向け構成」: Cloud Run へのデプロイ＝ソースデプロイ/リビジョン/トラフィック分割/Eventarc・Pub/Sub トリガー/Apigee、GKE へのデプロイ＝Deployment/Service・liveness/readiness プローブ・Horizontal Pod Autoscaler・Cloud Run との使い分け）。
4.1Cloud Run へのデプロイ
ソースコードからの Cloud Run デプロイ、リビジョンとトラフィック分割によるロールアウト、トリガー（Eventarc・Pub/Sub）による起動とイベント受信の構成、そして Apigee による API のバージョン管理・公開・保護を理解します。
コンテナをサーバーレスで動かす Cloud Run は、開発者のデプロイ先として中心的です。ソースから簡単にデプロイし、安全にロールアウトします。
4.1.1デプロイとロールアウト
Cloud Run は ソースコードから直接デプロイ できます（内部で自動的にコンテナ化）。デプロイのたびに リビジョン が作られ、トラフィック分割 で新リビジョンへ段階的に割合を移す カナリア や、問題時の即時 ロールバック が可能です。同時実行数や CPU/メモリ、最小/最大インスタンス数を構成して性能とコストを調整します。「段階公開/ロールバック＝リビジョン＋トラフィック分割」と結びます。
4.1.2トリガーと API 公開
Cloud Run サービスは、Eventarc や Pub/Sub の トリガー で起動でき、イベント駆動の処理を構成します（イベント受信側として Eventarc/Pub/Sub を設定）。公開する API は、Apigee で バージョン管理・公開・認証・レート制限・保護を行います。「イベントで起動＝Eventarc/Pub/Sub トリガー」「API のバージョン管理/保護＝Apigee」と結びます。
「要件 → 手段」が頻出。例：「ソースから簡単にデプロイ」＝Cloud Run のソースデプロイ、「新版を段階公開/即戻す」＝リビジョン＋トラフィック分割、「イベントで Cloud Run を起動」＝Eventarc/Pub/Sub トリガー、「API をバージョン管理し保護」＝Apigee。
混同に注意：
①リビジョン（バージョン）とトラフィック分割（割合制御）は組で使う。
②同時実行数や最小インスタンスは性能/コスト/コールドスタートに影響。
③Apigee はAPI 管理で、デプロイ基盤そのものではない。
4.1.3この節のまとめ
- Cloud Run はソースから直接デプロイ、リビジョン＋トラフィック分割でカナリア/ロールバック
- Eventarc/Pub/Sub トリガーでイベント駆動に起動
- API のバージョン管理・公開・保護は Apigee
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Cloud Run で新リビジョンへ段階的にトラフィックを移し、問題時に戻したい。使うのはどれですか？
Q2. Cloud Run サービスをイベントで起動したい。使うのはどれですか？
Q3. 公開 API のバージョン管理・認証・レート制限・保護を一元化したい。使うのはどれですか？
Q4. Cloud Run でコンテナをソースから手早くデプロイしたい。正しい説明はどれですか？
Q5. Cloud Run の同時実行数や最小インスタンス数が主に影響するものはどれですか？
Q6. リビジョンとトラフィック分割の関係として正しいものはどれですか？