Contents
Apigee Edge の概要と主要コンポーネント
Apigee Edge は Google が提供するフルマネージドの API 管理プラットフォームです。本節では、Organization・Environment・API Proxy の役割と相互関係を簡潔に整理し、全体像を掴むための基礎知識を提供します。
Organization と Environment の関係
Organization はテナント単位でリソースや権限を一元管理し、Environment はステージ(test / prod など)ごとの実行領域として機能します。
テナント構造 (H4)
- Organization:
my-orgのように名前で識別され、KVM、ユーザー・ロール、Virtual Host などを共有します。 - Environment:
test,dev,prodといったステージごとに分離され、各環境は独自の設定セット(ポリシー、キャッシュ、証明書)を保持できます。
ステージングと本番の分離 (H4)
- 安全性: 開発・検証用の設定が本番環境に影響しないよう、Environment 毎に独立した Virtual Host と KVM を割り当てます。
- 運用効率: 環境ごとにデプロイ対象を切替えるだけで、同一 API Proxy のリビジョン管理が容易になります。
デプロイ前の事前準備
Apigee Edge に安全かつスムーズにデプロイするためには、Google Cloud アカウント取得から IAM ロール付与までの手順を正しく実施する必要があります。本節では、具体的な作業フローとポイントをご紹介します。
Google Cloud アカウント作成手順
以下のステップでプロジェクトと Apigee Edge の利用準備を整えます。
- Google Cloud コンソール にログインし、「新規プロジェクト」を作成。
- プロジェクト名・請求情報を入力し、利用規約に同意してプロジェクトを有効化。
- 「Marketplace」から Apigee Edge を検索し、対象プロジェクトに追加。
必要な権限・ロール設定
デプロイ作業には最低でも Organization Admin と API Proxy Developer の 2 つのロールが必要です。
ロール付与手順 (H4)
| 手順 | 操作内容 |
|---|---|
| 1 | Cloud Console → IAM & 管理 → 「+追加」ボタンをクリック |
| 2 | 対象ユーザー(またはサービスアカウント)に roles/apigee.admin と roles/apigee.developer を選択 |
| 3 | 「保存」してロール付与完了。 |
権限確認方法 (H4)
Apigee UI の Organization Settings ページで、現在のロール一覧と権限範囲が表示されるため、デプロイ前に必ず確認してください。
API プロキシの作成と構成
API Proxy は Apigee Edge の核となる機能です。本節では UI と CLI 両方の作成手順を示し、主要設定ファイル(proxy.xml, targets.xml)のポイントも解説します。
UI でプロキシを作成するフロー
UI はウィザード形式で直感的に操作できるため、初心者にもおすすめです。
- Develop → API Proxies に移動し「+ Proxy」ボタンをクリック。
- テンプレート(例: Reverse Proxy)を選択し、プロキシ名・ベースパス・ターゲット URL を入力。
- 「Create」後に自動生成された proxy.xml と targets.xml を確認し、「Deploy」ボタンでテスト環境へデプロイします。
主要設定ファイルの概要 (H4)
proxy.xml: エンドポイント、フロー(PreFlow/PostFlow)、ポリシー定義を保持。targets.xml: バックエンドサーバーへの接続情報(URL、タイムアウト)を記述。
CLI でプロキシを作成・デプロイする手順
スクリプト化や CI/CD パイプラインに組み込む場合は apigeetool/apigeectl が便利です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# プロキシ作成(apigeetool) npx apigeetool createProxy \ -u $APIGEE_USER -p $APIGEE_PASS \ -o my-org -e test \ -n hello-proxy -b /hello \ -t https://jsonplaceholder.typicode.com # デプロイ(apigeetool) npx apigeetool deployProxy \ -u $APIGEE_USER -p $APIGEE_PASS \ -o my-org -e test \ -n hello-proxy -v 1 |
CLI のベストプラクティス (H4)
- 環境変数で認証情報を管理し、コードに平文を書かない。
- バージョン番号は CI ビルド番号や Git タグと連動させてリビジョン管理を自動化する。
apigeectlでも同様のコマンドが利用可能で、YAML 定義ファイルを直接操作できる点が特徴です。
環境別デプロイ手順と設定項目
テスト環境から本番リリースまでの流れを具体例とともに示し、Target Endpoint・Virtual Host・KVM など重要な設定ポイントを整理します。
テスト環境へのデプロイと検証フロー
テスト Environment(test)へは バージョン指定でデプロイし、ポリシーや KVM の挙動を確認します。
|
1 2 3 4 5 6 |
apigeetool deployProxy \ -u $APIGEE_USER -p $APIGEE_PASS \ -o my-org -e test \ -n hello-proxy -v 1 \ --revision 2 |
- Target Endpoint:
targets.xmlにhttps://api.dev.example.comを設定。 - Virtual Host:
defaultホストにtest.mycompany.comを割り当て、TLS はテスト証明書を使用。 - KVM: テスト用キーは
kvm-testに格納し、ポリシーで参照させます。
検証手順 (H4)
- Apigee UI の Trace タブでリクエスト/レスポンスを可視化。
- ログにエラーが無いことを確認し、期待通りのヘッダー変換やレート制限が適用されているかチェック。
本番環境へのリリース手順
本番 Environment(prod)へは 上書きデプロイ と段階的トラフィックシフトを組み合わせます。
|
1 2 3 4 5 6 |
apigeetool deployProxy \ -u $APIGEE_USER -p $APIGEE_PASS \ -o my-org -e prod \ -n hello-proxy -v 2 \ --override |
- Target Endpoint:
https://api.prod.example.comに切替。 - Virtual Host:
prod.mycompany.comを使用し、正式証明書を適用。 - ポリシー強化: レート制限・OAuth 2.0 認証を追加し、セキュリティ要件を満たす。
本番デプロイ後の監視 (H4)
Apigee Edge の Analytics ダッシュボードでエラーレートとレイテンシをリアルタイムに確認。閾値超過時は Cloud Monitoring アラートへ自動転送する設定が推奨されます。
CI/CD 連携による自動デプロイ
手作業のミスを排除し、迅速なリリースサイクルを実現するために GitHub Actions と Cloud Build の例を提示します。両ツールともシークレット管理とブランチ戦略に合わせて柔軟に設定できます。
GitHub Actions 実装例
develop ブランチへのプッシュでテスト環境へ自動デプロイ、main マージで本番へリリースします。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
name: Apigee Deploy on: push: branches: - develop pull_request: branches: - main jobs: deploy-test: runs-on: ubuntu-latest if: github.ref == 'refs/heads/develop' steps: - uses: actions/checkout@v3 - name: Set up Node.js uses: actions/setup-node@v3 with: node-version: 20 - name: Install apigeetool run: npm install -g apigeetool - name: Deploy to test env: APIGEE_USER: ${{ secrets.APIGEE_USER }} APIGEE_PASS: ${{ secrets.APIGEE_PASS }} ORG: ${{ secrets.ORG }} run: | apigeetool deployProxy \ -u $APIGEE_USER -p $APIGEE_PASS \ -o $ORG -e test \ -n hello-proxy -v ${{ github.run_number }} deploy-prod: runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' needs: deploy-test steps: - uses: actions/checkout@v3 - name: Install apigeetool run: npm install -g apigeetool - name: Deploy to prod env: APIGEE_USER: ${{ secrets.APIGEE_USER }} APIGEE_PASS: ${{ secrets.APIGEE_PASS }} ORG: ${{ secrets.ORG }} run: | apigeetool deployProxy \ -u $APIGEE_USER -p $APIGEE_PASS \ -o $ORG -e prod \ -n hello-proxy -v ${{ github.run_number }} \ --override |
ワークフローのポイント (H4)
- シークレットは GitHub の Settings → Secrets に格納し、平文が流出しないようにする。
github.run_numberをバージョンとして利用すれば、CI ビルドごとにリビジョンが自動インクリメントされます。
Cloud Build 実装例
GCP の IAM と統合したパイプラインで、コードプッシュからテスト環境デプロイまでを完全自動化します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
steps: - name: 'gcr.io/cloud-builders/npm' args: ['install', '-g', 'apigeectl'] - name: 'gcr.io/cloud-builders/gcloud' entrypoint: 'bash' args: - '-c' - | apigeectl login \ --username=$$APIGEE_USER \ --password=$$APIGEE_PASS apigeectl deploy proxy \ --org=$$ORG \ --env=test \ --name=hello-proxy \ --revision=$BUILD_ID options: substitutionOption: 'ALLOW_LOOSE' substitutions: _APIGEE_USER: ${_APIGEE_USER} _APIGEE_PASS: ${_APIGEE_PASS} _ORG: ${_ORG} |
Cloud Build の利点 (H4)
- サービスアカウントだけで認証が完結し、外部シークレットストアは不要。
- ビルドステップに
apigeectlを組み込むことで、同一 YAML でビルド・テスト・デプロイを統合できる。
トラブルシューティングとベストプラクティス
実運用で遭遇しやすいエラーと対処法、さらに長期的に安定した API 運用を支えるベストプラクティスをまとめます。
よくあるエラーコードと対策
| エラー | 主な原因 | 推奨対策 |
|---|---|---|
| 401 Unauthorized | 認証情報の誤り、ロール不足 | IAM ロールを再確認し、シークレットを最新に更新 |
| 409 Conflict | 同一リビジョンが既にデプロイ済み | --override で上書き、または新バージョン番号へ変更 |
| 500 Internal Server Error | ポリシー構文エラーやバックエンド不達 | Trace ログで失敗ステップを特定し、XML/YAML スキーマ検証ツールで修正 |
エラーログの活用方法 (H4)
apigeetool getTrace -u $U -p $P -o my-org -e test -n hello-proxy -v 1 を実行すると、リクエストフロー全体が可視化されます。失敗したポリシーやヘッダー変換箇所を即座に特定できるため、問題解決までの時間が大幅に短縮します。
ロールバック手順と運用上のベストプラクティス
デプロイ失敗時は 前バージョンへのロールバック が最速の復旧手段です。Apigee はリビジョン管理を自動で行うため、対象リビジョンを再デプロイするだけで元に戻せます。
ロールバック実行例 (H4)
|
1 2 3 4 5 6 |
apigeetool deployProxy \ -u $APIGEE_USER -p $APIGEE_PASS \ -o my-org -e prod \ -n hello-proxy -v 1 \ --override # 安定版 v1 にロールバック |
運用ベストプラクティス (H4)
- バージョニング:
v1, v2, v3の整数で管理し、Git タグと紐付ける。 - ステージング環境の導入:
stagingEnvironment を設置し、本番リリース前に実稼働と同等の負荷テストを実施。 - 継続的モニタリング: Apigee Analytics のダッシュボードでエラーレート・レイテンシをリアルタイム監視し、閾値超過時は Cloud Monitoring へ自動アラートを送信。
- ドキュメント化: デプロイ手順、ロールバック手順、障害対応フローを Confluence 等にまとめ、チーム全体で共有。
まとめ
本稿では Apigee Edge の基本構造から実践的なデプロイ手順、CI/CD 連携、そしてトラブルシューティングまで網羅的に解説しました。Organization と Environment の正しい設計、適切な IAM ロール付与、CLI/ UI の使い分け、そして自動化パイプラインの導入が、安定かつ高速な API デリバリーを実現する鍵です。ぜひ本ガイドを参考に、貴社の API 管理基盤構築・運用に活かしてください。