2024年7月23日 【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~ Apigee GKE Google Cloud 検索する Popular tags 事例紹介 GEN-STEP 生成AI(Generative AI) Vertex AI Search Looker Studio BigQuery AlloyDB Google Workspace Cloud SQL Category Google Cloud Author Google Cloud研究開発チーム SHARE 目次 Apigee ハイブリッドの概要 Apigeeハイブリッドを実行するクラスタについて まとめ Content 近年、APIエコノミーの進展に伴い、企業におけるAPI管理の重要性が高まっています。 オンプレミス環境とクラウド環境の両方でAPIを運用するケースも増加しており、従来のAPI管理ツールでは対応が難しい課題も生まれてきています。 そんな課題を解決すべく、ApigeeハイブリッドがGoogle Cloudで提供されており、今回は実際に環境構築を行った経験を元に、Apigeeハイブリッドについてご紹介をしていきます。 Apigee ハイブリッドの概要 Apigeeハイブリッドとは、Google Cloudが提供するハイブリッド型API管理プラットフォームです。 従来のAPI管理ツールでは、オンプレミス環境とクラウド環境で別々のツールを使用する必要があり、管理が複雑になるという課題がありました。 Apigeeハイブリッドであれば、単一の管理コンソールからすべてのAPIを管理することができ、運用効率を大幅に向上させることができます。 特徴 Apigeeハイブリッドには、主に以下のような特徴があります。 一元的なAPI管理 オンプレミス環境とクラウド環境のAPIを統一管理でき、運用コスト削減や運用の効率化が実現可能 高度なAPIセキュリティ OAuth 2.0やSAMLなどの認証・認可機能が利用可能 データの暗号化やアクセス制御などのセキュリティ機能が利用可能 API分析 応答時間やレイテンシを始めとする、様々な分析が可能 構成 Apigeeハイブリッドは、以下図のような形で、管理プレーンとランタイムプレーンで構成されます。 管理プレーン Google Cloud上にホストされ、Googleが管理する、UIやManagement API、分析などのサービスです。 ランタイムプレーン サポートされているKubernetesプラットフォーム上で動作する独自のKubernetesクラスタで、顧客管理のサービスです。 ランタイムプレーンのKubernetesプラットフォームは、Google CloudやAWS、Azure、オンプレミスのVMware環境などがサポートされています。 詳細は公式ドキュメントをご参照ください。 料金 Google Cloudで提供されているApigeeの料金体系としては、執筆時点で以下3つの料金モデルがありますが、Apigeeハイブリッドを利用する場合は「サブスクリプション」モデルを選択する必要があります。 ※Apigeeハイブリッドをお試しで利用したい場合は、60日間無料利用可能な「評価」モデルも選択可能です。 評価モデル 従量課金モデル サブスクリプションモデル サブスクリプションモデルの中でも3種類の利用資格(Standard、Enterprise、Enterprise Plus)があり、APIプロキシを呼び出す回数やAPIをデプロイする環境数に応じて、必要な資格を選択することが可能です。 詳細は公式ドキュメントをご参照ください。 サブスクリプションモデルの料金については、Google Cloud営業担当、または、弊社をはじめとするセールスパートナーへお問い合わせください。 Apigeeハイブリッドを実行するクラスタについて 前述の「構成」にて、管理プレーンは、サポートされているKubernetesプラットフォーム上で動作することをご紹介いたしました。 既にご利用頂いている(他のワークロードが実行されている)Kubernetesクラスタ上にApigeeハイブリッドをインストールすることも、新しい専用クラスタを作成しインストールすることも可能です。 セキュリティやパフォーマンス、運用管理などを鑑みると、他のワークロードとの分離をすることが望ましいため、専用クラスタを準備頂くことをお勧めします。 オンプレミス環境を想定し、今回はGKE on VMware上にApigeeハイブリッドを構築する方法を簡単にご紹介いたします。 前提 Apigeeハイブリッドのクラスタ最小構成(GKE on VMwareに限らず)については、公式ドキュメントをご覧ください。 構築を行うVMwareや管理ワークステーションについては、こちらの記事をご覧ください。 管理クラスターは上記の記事内のものを指定しています。 ユーザークラスターの作成 ①クラスターを構成する定義ファイルを作成 管理ワークステーションで以下のファイルを作成する。 ユーザークラスタのIPブロックファイルの作成 (本記事ではapigee-user-cluster-ipblock.yaml) yamlファイルのサンプルを表示する▼ blocks: - netmask: "NETMASK" ##ホストのサブネットマスク gateway: "DEFAULT_GATEWAY_IP" ##ホストのデフォルトゲートウェイのアドレス ips: ##個別のIPアドレスまたはIPアドレスのCIDRブロック - ip: "USER_NODE_IP_1" hostname: "USER_NODE_HOSTNAME_1" - ip: "USER_NODE_IP_2" hostname: "USER_NODE_HOSTNAME_2" - ip: "USER_NODE_IP_3" hostname: "USERR_NODE_HOSTNAME_3" - ip: "USER_NODE_IP_4" hostname: "USER_NODE_HOSTNAME_4" - ip: "USER_NODE_IP_5" hostname: "USER_NODE_HOSTNAME_5" - ip: "USER_NODE_IP_6" hostname: "USER_NODE_HOSTNAME_6" - ip: "USER_NODE_IP_7" hostname: "USER_NODE_HOSTNAME_7" yamlファイルの記載内容の詳細についてはこちらをご覧ください。 ユーザー クラスタ構成ファイルの作成 (本記事ではapigee-cluster.yaml) yamlファイルのサンプルを表示する▼ apiVersion: v1 kind: UserCluster name: "USER_CLUSTER_NAME" ##ユーザークラスタ名 gkeOnPremVersion: "1.28.0-gke.651" ##ユーザー クラスタの GKE on VMware のバージョン enableControlplaneV2: true ##Controlplane V2が有効になっているユーザー クラスタを作成する場合はtrue network: hostConfig: dnsServers: - "DNS_SERVER_IP" ##VM の DNS サーバーのアドレス ntpServers: - "NTP_SERVER_IP" ##VM が使用する時刻サーバーのアドレス ipMode: type: "static" ##"dhcp"か"static"を指定 ipBlockFilePath: "apigee-user-cluster-ipblock.yaml" ##クラスタの IP ブロック ファイルのへのパス serviceCIDR: "SERVICE_CIDR" ##クラスタ内の Service に使用される IP アドレスの範囲(CIDR 形式) podCIDR: "POD_CIDR" ##クラスタ内の Pod に使用される IP アドレスの範囲(CIDR 形式) controlPlaneIPBlock: netmask: "NETMASK" ##コントロールプレーンノードを持つネットワークのネットマスク gateway: "DEFAULT_GATEWAY_IP" ##コントロールプレーンノードのデフォルトゲートウェイの IP アドレス ips: - ip: "USER_CONTROL_PLANE_NODE_IP" hostname: "USER_CONTROLPLANE_HOSTNAME" loadBalancer: vips: controlPlaneVIP: "USER_CONTROL_PLANE_VIP" ##ユーザー クラスタのKubernetes APIサーバー用にロードバランサ上に構成することを選択した IP アドレス ingressVIP: "USER_INGRESS_VIP" ##上り(内向き)プロキシのロードバランサを構成するために選択した IP アドレス kind: "MetalLB" ##"ManualLB"、"F5BigIP"、"Seesaw"、"MetalLB" のいずれかを指定 metalLB: addressPools: - name: "ADDRESS_POOL_NAME" ##アドレスプールに付ける名前 addresses: ##アドレスの範囲 - "USER_INGRESS_VIP/32" - "SERVICE_VIP_1/32" - "SERVICE_VIP_2/32" enableDataplaneV2: true ##Dataplane V2 を有効にする場合はtrue nodePools: - name: "apigee-data" ##ノードプールに付ける名前 cpus: 4 ##プール内の各ノードの vCPU 数 memoryMB: 16384 ##プール内の各ノードのメモリ容量(MiB) replicas: 3 ##プール内のノード数 enableLoadBalancer: true ##プール内のノードで MetalLB スピーカーを実行できるようにする場合はtrue - name: "apigee-runtime" ##ノードプールに付ける名前 cpus: 4 ##プール内の各ノードの vCPU 数 memoryMB: 16384 ##プール内の各ノードのメモリ容量(MiB) replicas: 3 ##プール内のノード数 enableLoadBalancer: true ##プール内のノードで MetalLB スピーカーを実行できるようにする場合はtrue antiAffinityGroups: enabled: false ##DRS ルールの作成を有効にする(true) or しない(false) gkeConnect: projectID: "PROJECT_ID" ##GoogleCloudプロジェクトのID registerServiceAccountKeyPath: "CONNECT_REGISTER_SA_KEY" ##接続登録サービス アカウントの JSON 鍵ファイルのパス stackdriver: projectID: "PROJECT_ID" ##GoogleCloudプロジェクトのID clusterLocation: "REGION" ##ログを保存する Google Cloud リージョン enableVPC: false ##クラスタのネットワークが VPC によって管理されている(true) or されていない(false) serviceAccountKeyPath: "LOG_MON_SA_KEY" ##ロギングモニタリングサービスアカウントのJSON鍵ファイルのパス disableVsphereResourceMetrics: false ##trueに設定するとvSphereからの指標の収集が無効 autoRepair: enabled: true ##ノードの自動修復を有効にする場合はtrue ※Apigeeハイブリッドでは、apigee-dataとapigee-runtimeのノードプールを構成する必要がございます。 yamlファイルの記載内容の詳細についてはこちらをご覧ください。 ②構成ファイルの検証とクラスター作成 作成したapigee-cluster.yamlを基に、以下のコマンドを実行してユーザークラスタを作成します。 gkectl check-config --kubeconfig kubeconfig --config apigee-cluster.yaml 失敗していると「Exit with error」のエラーメッセージが返ってきます。 作成したapigee-cluster.yamlを基に、以下のコマンドを実行してユーザークラスタを作成します。 gkectl create cluster --kubeconfig kubeconfig --config apigee-cluster.yaml ③Cassandra用の永続SSDを構成 (本番環境の場合) Apigeeハイブリッドを本番環境で利用する場合、CassandraのストレージはSSDのStorageClassである必要があります。 デフォルトのStorageClassは次のコマンドで確認できるため、変更する場合は、公式ドキュメントをご参照ください。 kubectl get storageclass 以上までが、GKE on VMwareにおけるクラスターを構成するための手順になります。 まとめ 本記事では、Apigeeハイブリッドの概要や構成、料金をはじめ、ハイブリッドを実行するKubernetesクラスタについてご説明いたしました。 次の記事では、Apigeeハイブリッドのインストールや管理ツールとなる、helmを用いた構築の流れやAPIのデプロイについてご紹介いたします。 関連コンテンツ 【Google Cloud】第2回:Apigee ハイブリッドでAPIをデプロイしてみた~Helmでインストール・デプロイ編~ by Google Cloud研究開発チームon 2024年7月23日 頂きましたご意見につきましては、今後のより良い商品開発・サービス改善に活かしていきたいと考えております。 よくわかった 実際につかってみたい よくわからなかった APIの運用管理で困っている Author Google Cloud研究開発チーム 株式会社システムサポート(STS)のGoogle Cloud研究開発チームです。 実際に技術検証した事例を中心に記事発信していきます。 Apigee GKE Google Cloud 2024年7月23日 【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~ Category Google Cloud 前の記事を読む 第1回 Google Cloud LTイベントを開催しました! 次の記事を読む 【Google Cloud】第2回:Apigee ハイブリッドでAPIをデプロイしてみた~Helmでインストール・デプロイ編~ Recommendation オススメ記事 2023年9月5日 Google Cloud 【Google Cloud】Looker Studio × Looker Studio Pro × Looker を徹底比較!機能・選び方を解説 2023年8月24日 Google Cloud 【Google Cloud】Migrate for Anthos and GKEでVMを移行してみた(1:概要編) 2022年10月10日 Google Cloud 【Google Cloud】AlloyDB と Cloud SQL を徹底比較してみた!!(第1回:AlloyDB の概要、性能検証編) BigQuery ML ワークショップ開催のお知らせ 生成AI導入支援パッケージ Discovery AI導入支援パッケージ Google Cloud ホワイトペーパー 新着記事 2026年5月11日 Google Cloud BigQueryの役割はどう変わるのか-Google Cloud Next’26で感じた「AIエージェント時代のデータ基盤」 2026年5月11日 イベント・セミナー 【2026/5/28開催】EC運営を効率化! 生成AIでコンテンツ制作業務を加速させる改善術 2026年5月11日 モバイル Jetpack ComposeとCredential ManagerでPasskeyログインを実装してみた HOME Google Cloud 【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~