Google Cloud Japan の RyuSA です。
先日 AlloyDB Omni というプロダクトがリリースされました 🎉
AlloyDB Omni は ハイパフォーマンスなワークロード向けの PostgreSQL 互換のマネージドサービスである AlloyDB を Linux 環境(ローカル、VM、基本的にどこでも)上で動かすことができるプロダクトです。
本記事ではチュートリアルに則りながら AlloyDB Omni を動かしつつ、 Kubernetes 上に移行してReadReplica 機能やソフトウェアの外部データベースとして使ってみたりなど検証してみます。
まずはチュートリアル通りに検証する
Install AlloyDB Omni を参考にしながら環境を構築して動作検証してみます。ドキュメントには次のリソースが最小構成として記載されています。
- 2 CPUs (x86/AMD64)
- Raspberry Pi では動きません
- 16 GB of RAM
- Debian or Ubuntu or RHEL 8+
実際にこれらを満たすリソースを作成し、 AlloyDB Omni を起動してみましょう。
Google Cloud 上に検証環境を構築する
AlloyDB Omni が要求するスペックを Google Compute Engine のマシンタイプで実現するには n2-highmem-2 が最小となるため、このマシンタイプでインスタンスを作成します。 AWS であれば r6i.large が、 Azure であれば Standard_E2bds_v5 が同じような構成になるかと思います。
$ export GCP_PROJECT=<GCP_PROJECT>
$ export ZONE=asia-northeast1-b
$ export MACHINE_TYPE=n2-highmem-2
$ export NETWORK_NAME=default
# 検証用のProjectを作成(スキップ可)
$ gcloud projects create $GCP_PROJECT
# GCEインスタンスを作成(defaultネットワーク上に作成)
$ gcloud compute instances create alloyomni \
--project=$GCP_PROJECT \
--zone=$ZONE \
--machine-type=$MACHINE_TYPE \
--boot-disk-size=50GB
NAME: alloyomni
ZONE: asia-northeast1-b
MACHINE_TYPE: n2-highmem-2
PREEMPTIBLE:
INTERNAL_IP: FOO
EXTERNAL_IP: BAR
STATUS: RUNNING
また AlloyDB Omni はコンテナとして提供されており、後述の起動シェルで Docker を使っているため依存関係として Docker をインストールしておきます。
(local)$ gcloud compute ssh --project=$GCP_PROJECT --zone=$ZONE --tunnel-through-iap alloyomni
(alloyomni)$ curl -fsSL https://get.docker.com -o get-docker.sh
(alloyomni)$ sh get-docker.sh
(alloyomni)$ sudo docker run hello-world
Hello from Docker!
...
これで事前準備は完了です。AlloyDB Omni の起動に必要なシェルスクリプトなどをダウンロードして AlloyDB Omni を起動していきます。
AlloyDB Omni を起動する
Install AlloyDB Omni に従ってスクリプトをダウンロードして起動してみます。
# インストーラーをダウンロード
$ gsutil cp -r gs://alloydb-omni-install/$(gsutil cat gs://alloydb-omni-install/latest) .
$ cd $(gsutil cat gs://alloydb-omni-install/latest)
# Unitファイルやコンフィグをインストール
$ tar -xzf alloydb_omni_installer.tar.gz && cd installer
$ sudo bash install_alloydb.sh
2023-04-06 04:04:32.855 UTC: [install_alloydb.sh:59] Starting installation of AlloyDB Omni...
2023-04-06 04:04:32.856 UTC: [install_alloydb.sh:61] Checking hardware requirements for AlloyDB Omni...
2023-04-06 04:04:32.871 UTC: [install_alloydb.sh:64] Checking software requirements for AlloyDB Omni...
2023-04-06 04:04:33.014 UTC: [install_alloydb.sh:67] Configuring installation files...
2023-04-06 04:04:33.025 UTC: [install_alloydb.sh:70] Setting up postgres user...
2023-04-06 04:04:33.059 UTC: [install_alloydb.sh:73] Configuring systemd services...
Created symlink /etc/systemd/system/multi-user.target.wants/alloydb-setup-env.service → /etc/systemd/system/alloydb-setup-env.service.
Created symlink /etc/systemd/system/multi-user.target.wants/alloydb-dataplane.service → /etc/systemd/system/alloydb-dataplane.service.
2023-04-06 04:04:35.248 UTC: [install_alloydb.sh:76] Copying configuration files...
2023-04-06 04:04:35.255 UTC: [install_alloydb.sh:79] Creating internal directories...
2023-04-06 04:04:35.258 UTC: [install_alloydb.sh:82] Finished installing AlloyDB Omni
# AlloyDB Omni のデータ保存領域をデフォルト値から変更する
# デフォルトでは /path/to/alloydb/omni/data/ というディレクトリにデータが格納されます
$ export DATA_DIR="/path/to/your/favorite/directry"
$ sudo sed -i "s|^\(DATADIR_PATH=\).*|\1\"${DATA_DIR}\" |" /var/alloydb/config/dataplane.conf
# AlloyDB Omni を起動する
$ sudo systemctl restart alloydb-dataplane
$ sudo systemctl status alloydb-dataplane
● alloydb-dataplane.service - AlloyDB Data plane
Loaded: loaded (/etc/systemd/system/alloydb-dataplane.service; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2023-04-06 04:08:01 UTC; 12s ago
Process: 5684 ExecStart=/bin/bash /opt/alloydb/scripts/start_alloydb.sh (code=exited, status=0/SUCCESS)
Main PID: 5684 (code=exited, status=0/SUCCESS)
CPU: 999ms
...
Apr 06 04:08:01 alloyomni bash[6148]: 2023-04-06 04:08:01.277 UTC: [start_alloydb.sh:153] Successfully started AlloyDB Omni
Apr 06 04:08:01 alloyomni systemd[1]: Finished AlloyDB Data plane.
# コンテナを確認する
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
aa5f70a84d6f gcr.io/alloydb-omni/memory-agent:latest "/cgmon --logtostder…" 47 seconds ago Up 46 seconds memory-agent
670df5e7ee80 gcr.io/alloydb-omni/pg-service:latest "/bin/bash /smurf-sc…" 55 seconds ago Up 49 seconds pg-service
# AlloyDBに接続してみる
$ sudo docker exec -it pg-service psql -U postgres -h localhost -c "SELECT VERSION();"
version
-----------------------------------------------------------------------------------------
PostgreSQL 14.4 on x86_64-pc-linux-gnu, compiled by Debian clang version 12.0.1, 64-bit
(1 row)
構成を確認する
作成されたコンテナを確認すると、pg-service コンテナが AlloyDB 本体のコンテナとして、memory-agent コンテナが(おそらく)サイドカーのような形で起動しています。pg-service コンテナの起動コマンドを復元するとこのようなコマンドで起動しているようです。
docker run \
-it \
-d \
-v "/var/alloydb":"/var/alloydb" \
-v "${DATA_DIR}":"/mnt/disks/pgsql":rshared \
-v /dev/shm:/dev/shm \
--name pg-service \
-u 2345 \
--privileged \
--cap-add=SYS_NICE \
--ulimit nice=-20:-20 \
--network host \
--log-driver=journald \
"${PG_IMAGE}:${OMNI_VERSION}" /bin/bash /smurf-scripts/alloydb_init.sh
- Kernel の NICE 値を最大にできるようになっている
- ホスト OS から見てもコンテナプロセスの優先度が最大になる
-
network=hostとなっているためホストOSの0.0.0.0でポートをリッスン- サーバー外部から接続し放題なため、ファイアーウォールなどが設定されていない環境では注意しましょう
- 共有メモリ空間
/dev/shmをマウント
試しにこれらの設定を外しても pg-service コンテナを起動はできるので、おそらくこれらは AlloyDB Omni のパフォーマンスを最大限活用するための設定かと思います。 🤔
AlloyDB Omni(の一部) on Kubernetes
特権権限が必要な設定などを無視して、pg-service コンテナを Kubernetes 上で動かしてみようという話です。Kubernetes 上に AlloyDB Omni をデプロイできれば簡単に利用できる環境としても使いやすくなるはずです。
チュートリアルでは systemd の Unit ファイルから起動スクリプトまですべて提供されていましたが、Kubernetes 向けの設定は存在しません。AlloyDB Omni を Kubernetes 上で動かすには、 AlloyDB Omni がどのように動いているのかを確認する必要があります。
AlloyDB Omniの起動構成を整える
AlloyDB Omni の Unit ファイルとコンテナイメージの起動スクリプトをそれぞれ読み、起動プロセスに合わせて設定ファイルなどを構築すると次の ConfigMap のマニフェスト configmap.yaml で表現できます。
apiVersion: v1
kind: ConfigMap
metadata:
name: omni-pri-config
data:
dataplane.conf: |
INSTANCE_TYPE=PRIMARY
---
apiVersion: v1
kind: ConfigMap
metadata:
name: omni-config
data:
pg_hba.conf: |
local all alloydbadmin reject
local all all md5
host all all 127.0.0.1/32 trust
host all all ::1/128 trust
local replication all md5
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
postgresql.conf: |
archive_command='/bin/true'
archive_mode=off
archive_timeout=300
bgwriter_delay=50
bgwriter_lru_maxpages=200
checkpoint_completion_target=0.9
datestyle='iso, mdy'
default_text_search_config='pg_catalog.english'
dynamic_shared_memory_type=posix
hot_standby=on
hot_standby_feedback=on
# disable huge pages
huge_pages=off
lc_messages='en_US.UTF8'
lc_monetary='en_US.UTF8'
lc_numeric='en_US.UTF8'
lc_time='en_US.UTF8'
listen_addresses = '*'
log_autovacuum_min_duration=0
log_directory='log'
log_filename='postgres'
log_line_prefix='%m [%p]: [%l-1] db=%d,user=%u '
log_rotation_age=0
log_rotation_size=0
log_temp_files=0
log_timezone='UTC'
logging_collector='on'
max_connections=1000
max_locks_per_transaction=64
max_prepared_transactions=0
max_replication_slots=50
max_wal_senders=50
max_wal_size=1504MB
max_worker_processes=64
shared_buffers_active_ratio=0.6
shared_preload_libraries='google_columnar_engine,google_job_scheduler,google_db_advisor,google_storage,pg_stat_statements'
synchronous_commit=on
timezone='UTC'
wal_init_zero=off
wal_level=replica
---
apiVersion: v1
kind: ConfigMap
metadata:
name: omni-internal
data:
dynamic_postgresql.conf: |
shared_buffers=6553MB
max_parallel_workers=8
max_parallel_workers_per_gather=2
effective_cache_size=13421772kB
work_mem=4MB
ほとんどはチュートリアル時に /var/alloydb 配下に作成される設定ファイルをコピーしただけですが、 postgresql.conf の huge_pages をオフに設定しておきます。これは Kubernetes で Hugepages を使うには事前準備が必要なため今回はスキップするためです。またこの後に AlloyDB Omni を vCPU=2 / Mem=8Gi のリソースで起動させるため、事前に PostgreSQL 向けのリソース設定を dynamic_postgresql.conf に設定しておきます。この値は /opt/alloydb/scripts/alloydb_uti.sh で定義されている関数 alloydb::write_dynamic_postgres_params を参照して算出できます。
あとはこの設定ファイルを Pod にマウントするようにマニフェストを作成して Kubernetes にデプロイすれば Kubernetes 上で AlloyDB Omni を起動できます。
AlloyDB Omni をデプロイする
(Optional) GKE Autopilot クラスターを準備する
もしお手元に ConfigMap / Statefulset / Service を自由にデプロイできる Kubernetes クラスターがない場合、 AlloyDB Omni をデプロイするための GKE クラスターを作成しておきます。
$ gcloud container --project $GCP_PROJECT \
clusters create-auto alloydb-playground \
--region "asia-northeast1"
Creating cluster alloydb-playground in asia-northeast1... Cluster is being health-checked (master is healthy)...done.
Created
# GKE のクレデンシャルをセット
$ gcloud container clusters get-credentials alloydb-playground --region asia-northeast1 --project $GCP_PROJECT
Kubernetes 上に pg-service コンテナを起動するために、 Docker コマンドのオプションを Kubernetes の言葉に翻訳した StatefulSet のマニフェスト alloydb.yaml を作成しましょう。
apiVersion: v1
kind: Service
metadata:
name: alloyomni
labels:
app: alloyomni
spec:
ports:
- port: 5432
name: postgres
clusterIP: None
selector:
app: alloyomni
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: alloyomni
spec:
selector:
matchLabels:
app: alloyomni
serviceName: "alloyomni"
replicas: 1
template:
metadata:
labels:
app: alloyomni
spec:
securityContext:
runAsUser: 2345
runAsGroup: 2345
fsGroup: 2325
initContainers:
- name: init
image: busybox
command:
- "sh"
- "-c"
args:
- "chown -R 2345:2345 /mnt/disks/pgsql && chmod -R 0700 /mnt/disks/pgsql"
securityContext:
runAsUser: 0
runAsNonRoot: false
volumeMounts:
- name: omni-data
mountPath: /mnt/disks/pgsql
containers:
- name: pg-service
image: gcr.io/alloydb-omni/pg-service:latest
command:
- /bin/bash
args:
- /smurf-scripts/alloydb_init.sh
ports:
- containerPort: 5432
name: postgres
resources:
requests:
cpu: 2500m
memory: 16Gi
limits:
cpu: 2500m
memory: 16Gi
volumeMounts:
- name: omni-data
mountPath: /mnt/disks/pgsql
- name: omni-config
mountPath: /var/alloydb/config/pg_hba.conf
subPath: pg_hba.conf
- name: omni-config
mountPath: /var/alloydb/config/postgresql.conf
subPath: postgresql.conf
- name: omni-dataplane
mountPath: /var/alloydb/config/dataplane.conf
subPath: dataplane.conf
- name: omni-internal
mountPath: /var/alloydb/internal/
volumes:
- name: omni-data
persistentVolumeClaim:
claimName: omni-data
- name: omni-config
configMap:
name: omni-config
- name: omni-dataplane
configMap:
name: omni-pri-config
- name: omni-internal
configMap:
name: omni-internal
volumeClaimTemplates:
- metadata:
name: omni-data
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 50Gi
作成した StatefulSet のマニフェストと先ほど作成した ConfigMap のマニフェストをデプロイすることで AlloyDB Omni を起動できます。
$ kubectl apply -f configmap.yaml -f alloydb.yaml
configmap/omni-pri-config created
configmap/omni-config created
configmap/omni-internal created
service/alloyomni created
statefulset.apps/alloyomni created
$ kubectl get sts,po
NAME READY AGE
statefulset.apps/alloyomni 1/1 16m
NAME READY STATUS RESTARTS AGE
pod/alloyomni-0 1/1 Running 0 16m
# AlloyDB Omni に接続
$ kubectl exec -it alloyomni-0 -- psql -h localhost -U postgres -c "SELECT version();"
version
-----------------------------------------------------------------------------------------
PostgreSQL 14.4 on x86_64-pc-linux-gnu, compiled by Debian clang version 12.0.1, 64-bit
(1 row)
これで無事 Kubernetes 上に AlloyDB Omni をデプロイできました 👏 開発向けの利用用途が広がりますね。
AlloyDB Omni でたわむれる
AlloyDB Omni は通常のインストールでは systemd ベースで起動でき、またいくつかマニフェストを定義することで Kubernetes 上でも起動できました。
ここから先は蛇足な内容です。 AlloyDB Omni には ReadReplica の機能や PostgreSQL との互換性があるとのことなの、これらの機能を使っていろいろ試してみます。
リードレプリカ とたわむれる
リードレプリカ インスタンスはデータのオリジナルとなるプライマリー インスタンスと同期して、 SELECT 文などの Read 系のクエリーを専門に処理できるインスタンスです。
AlloyDB Omni はこの Primary-ReadReplica 構成を取れます。公式ドキュメントに則って、Kubernetes 上で AlloyDB Omni のリードレプリカインスタンスを作成してみます。
まずは ConfigMap omni-config を修正します。 ConfigMap の pg_hba.conf に認証を許可する IP アドレスレンジを追加する必要があります。今回は簡略化のため、 Pod の IP アドレスレンジからの alloydbreplica ユーザーへのレプリケーションを許可する設定を入れて起動することにします。またこの後検証で利用する Matrermost 用の認証設定も追記します。ここでは Pod の IP アドレスレンジを 10.33.0.0/17 と仮定し、 ConfigMap omni-config を次のように修正します。
apiVersion: v1
kind: ConfigMap
metadata:
name: omni-config
data:
pg_hba.conf: |
local all alloydbadmin reject
...
+ host all alloydbreplica 10.33.0.0/17 trust
+ host replication alloydbreplica 10.33.0.0/17 trust
+ host mattermost postgres 10.33.0.0/17 trust
次にコンテナ起動時にコンテナ自身がリードレプリカであることとプライマリー インスタンスの所在を伝えるための CofnigMap のマニフェスト configmap-ro.yaml を作成します。PRIMARY_IP_ADDRESS の値に AlloyDB Omni の Service のドメインを設定します。
apiVersion: v1
kind: ConfigMap
metadata:
name: omni-ro-config
data:
dataplane.conf: |
INSTANCE_TYPE=READ_REPLICA
# Service name of the primary AlloyDB
PRIMARY_IP_ADDRESS=alloyomni
REPLICA_SLOT_NAME="alloydb_omni_replica"
またリードレプリカのための StatefulSet のマニフェスト alloydb-ro.yaml も作成します。プライマリーと異なる点は、 ConfigMap omni-pri-config をマウントする代わりにリードレプリカ向けの ConfigMap omni-ro-config をマウントすることです。
apiVersion: v1
kind: Service
metadata:
name: alloyomni-ro
labels:
app: alloyomni-ro
spec:
ports:
- port: 5432
name: postgres
clusterIP: None
selector:
app: alloyomni-ro
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: alloyomni-ro
spec:
selector:
matchLabels:
app: alloyomni-ro
serviceName: "alloyomni-ro"
replicas: 1
template:
metadata:
labels:
app: alloyomni-ro
spec:
securityContext:
runAsUser: 2345
runAsGroup: 2345
fsGroup: 2325
initContainers:
- name: init
image: busybox
command:
- "sh"
- "-c"
args:
- "chown -R 2345:2345 /mnt/disks/pgsql && chmod -R 0700 /mnt/disks/pgsql"
securityContext:
runAsUser: 0
runAsNonRoot: false
volumeMounts:
- name: omni-data
mountPath: /mnt/disks/pgsql
containers:
- name: pg-service
image: gcr.io/alloydb-omni/pg-service:latest
command:
- /bin/bash
args:
- /smurf-scripts/alloydb_init.sh
ports:
- containerPort: 5432
name: postgres
resources:
requests:
cpu: 2500m
memory: 16Gi
limits:
cpu: 2500m
memory: 16Gi
volumeMounts:
- name: omni-data
mountPath: /mnt/disks/pgsql
- name: omni-config
mountPath: /var/alloydb/config/pg_hba.conf
subPath: pg_hba.conf
- name: omni-config
mountPath: /var/alloydb/config/postgresql.conf
subPath: postgresql.conf
- name: omni-dataplane
mountPath: /var/alloydb/config/dataplane.conf
subPath: dataplane.conf
- name: omni-internal
mountPath: /var/alloydb/internal/
volumes:
- name: omni-data
persistentVolumeClaim:
claimName: omni-data
- name: omni-config
configMap:
name: omni-config
- name: omni-dataplane
configMap:
# リードレプリカ向けのConfigMap
name: omni-ro-config
- name: omni-internal
configMap:
name: omni-internal
volumeClaimTemplates:
- metadata:
name: omni-data
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 50Gi
$ kubectl apply -f configmap.yaml
configmap/omni-pri-config unchanged
configmap/omni-config configured
configmap/omni-internal unchanged
$ kubectl rollout restart statefulset alloyomni
statefulset.apps/alloyomni restarted
$ kubectl apply -f configmap-ro.yaml -f alloydb-ro.yaml
configmap/omni-ro-config created
service/alloyomni-ro created
これでPodが起動すればリードレプリカが動いているはずです。
試しにプライマリ インスタンスにデータを投入してリードレプリカ インスタンスからデータをクエリできることを確認しましょう。まずプライマリ インスタンスにログインして book テーブルを作成し、適当にデータを投入します。
$ kubectl exec -it alloyomni-0 -- psql -h localhost -U postgres
postgres=# create database mattermost;
CREATE DATABASE
# postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
--------------+--------------+----------+---------+---------+-------------------------------
alloydbadmin | alloydbadmin | UTF8 | C.UTF-8 | C.UTF-8 |
postgres | alloydbadmin | UTF8 | C.UTF-8 | C.UTF-8 |
mattermost | postgres | UTF8 | C.UTF-8 | C.UTF-8 |
template0 | alloydbadmin | UTF8 | C.UTF-8 | C.UTF-8 | =c/alloydbadmin +
| | | | | alloydbadmin=CTc/alloydbadmin
template1 | alloydbadmin | UTF8 | C.UTF-8 | C.UTF-8 | =c/alloydbadmin +
| | | | | alloydbadmin=CTc/alloydbadmin
postgres=# \c mattermost
You are now connected to database "mattermost" as user "postgres".
sample=# create table mybook (id integer, name varchar(10));
CREATE TABLE
sample=# insert into mybook VALUES (1, 'hoge'), (2, 'huga');
INSERT 0 2
sample=# select * from mybook;
id | name
----+------
1 | hoge
2 | huga
(2 rows)
プライマリ インスタンスにデータの投入ができたらリードレプリカ インスタンスからデータを取得できることを確認します。
$ kubectl exec -it alloyomni-ro-0 -- psql -h localhost -U postgres
# postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
--------------+--------------+----------+---------+---------+-------------------------------
alloydbadmin | alloydbadmin | UTF8 | C.UTF-8 | C.UTF-8 |
postgres | alloydbadmin | UTF8 | C.UTF-8 | C.UTF-8 |
mattermost | postgres | UTF8 | C.UTF-8 | C.UTF-8 |
template0 | alloydbadmin | UTF8 | C.UTF-8 | C.UTF-8 | =c/alloydbadmin +
| | | | | alloydbadmin=CTc/alloydbadmin
template1 | alloydbadmin | UTF8 | C.UTF-8 | C.UTF-8 | =c/alloydbadmin +
| | | | | alloydbadmin=CTc/alloydbadmin
(5 rows)
postgres=# \c mattermost
You are now connected to database "mattermost" as user "postgres".
sample=# select * from mybook;
id | name
----+------
1 | hoge
2 | huga
(2 rows)
このように dataplane.conf に定義されている環境変数を変更するだけで AlloyDB Omni の挙動を変更し、 Primary-ReadReplica 構成を取ることができるようになりました。今回は Kubernetes で実践しましたが、 Docker で起動する従来のパターンでも同じような構成を取れます。Create a read-only replica | AlloyDB for PostgreSQL | Google Cloud
Mattermostとたわむれる
Mattermost は Slack ライクな SNS ソフトウェアで、バックエンドに PostgreSQL を利用します。AlloyDB Omni は PostgreSQL 互換、であれば AlloyDB Omni を Mattermost のバックエンドとしても使えるはずです。サクッと動作検証してみましょう。
次の Mattermost 用のマニフェストを Kubernetes にデプロイします。
apiVersion: v1
kind: Pod
metadata:
name: mattermost
spec:
containers:
- image: mattermost/mattermost-enterprise-edition:7.1
name: mattermost
ports:
- containerPort: 8065
name: app
env:
- name: MM_SQLSETTINGS_DRIVERNAME
value: postgres
- name: MM_SQLSETTINGS_DATASOURCE
value: postgres://postgres:@alloyomni:5432/mattermost?sslmode=disable&connect_timeout=10
$ kubectl apply -f mattermost.yaml
pod/mattermost created
$ kubectl port-forward pod/mattermost 8065:8065
Forwarding from 127.0.0.1:8065 -> 8065
...
Mattermost は 8065番/TCPポート で待ち受けているのでポートフォワードして動作チェックします。
Mattermost with AlloyDB Omni も動作しました 👏 AlloyDB は PostgreSQL 互換を謳うだけあり、既存の PostgreSQL を利用するソフトウェアもバックエンドとして AlloyDB Omni を利用できました。
クリーンアップ
作成したリソースを削除していきます
# GKE クラスター削除
$ gcloud container clusters delete alloydb-playground --region asia-northeast1
# GCE インスタンス削除
$ gcloud compute instances delete alloyomni \
--project=$GCP_PROJECT \
--zone=$ZONE
さいごに
AlloyDB Omni の基本的な動作を確かめつつ、たわむれながら AlloyDB Omni の機能の確認をしました。
AlloyDB はハイパフォーマンスが要求されるエンタープライズワークロードで力を発揮します。しかし「アプリケーションがオンプレミス環境にあるからデータベースもオンプレミス環境で動作させたい」「開発に使いたいけどインスタンス建てにくい」など、Google Cloud マネージドな AlloyDB を利用できない場合は AlloyDB Omni を利用するのがひとつの手段かもしれません 👏
Discussion