2024年7月23日

【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~


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のデプロイについてご紹介いたします。

2024年7月23日 【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~

Category Google Cloud

ご意見・ご相談・料金のお見積もりなど、
お気軽にお問い合わせください。

お問い合わせはこちら