2024年7月23日 【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~ Apigee GKE Google Cloud 検索する Popular tags 生成AI(Generative AI) 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 ホワイトペーパー 新着記事 2024年10月9日 イベント・セミナー 【参加無料】typeエンジニア転職フェア 出展のお知らせ(2024/10/12) 2024年10月4日 イベント・セミナー 【11/20開催】データ分析&活用ウェビナー(事例紹介付き) 2024年9月30日 Google Cloud 【Google Cloud】サーバレスでマネージドなサービス「Cloud Run」でアプリケーションを走らせよう! HOME Google Cloud 【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~ ご意見・ご相談・料金のお見積もりなど、お気軽にお問い合わせください。 お問い合わせはこちら HOME Categories お知らせ イベント・セミナー Google Cloud Google Workspace モバイル インフラ 技術開発 ブログ 4koma Tags 生成AI(Generative AI) Looker Studio BigQuery AlloyDB Google Workspace 事例紹介 Cloud SQL STSエンジニアリングマガジン 「サイタル」 当サイトではクッキー(Cookie)、Googleアナリティクスを利用します。 「同意する」をクリックいただくことで、サイト上での最高のエクスペリエンスをご提供いたします。 ※詳細は以下をご覧ください。 外部送信ポリシー プライバシーポリシー同意する同意しない