本稿は、Japan Digital Design 株式会社 佐藤様による「三菱UFJフィナンシャル・グループの DX を牽引する Japan Digital Design、Aurora DSQL の採用で DB コストを約 87% 削減し、運用負荷ほぼゼロを実現」に関する寄稿記事となります。 こんにちは。Japan Digital Design 株式会社 Technology & Development Division で Technical Project Manager を務めている佐藤です。 Japan Digital Design 株式会社は「金融の新しいあたりまえを創造し人々の成長に貢献する」というミッションのもと、AI・CX・Tech の各領域を組み合わせて三菱UFJフィナンシャル・グループの DX を支援しています。私が所属する Technology & Development Division では、システムの開発・運用からプラットフォーム構築、アーキテクチャ設計までを担っています。 今回、ドキュメント検索システムを新規構築するにあたり、データベースとして  Amazon Aurora DSQL  を採用しました。パートナーを介さず自社開発チームのみで導入を完了し、結果として  Aurora Serverless 比で約 87% のコスト削減と DB 運用負荷ほぼゼロ を実現できています。本記事では、私たちが Aurora DSQL を選定した背景、開発時に直面した課題とその対処、そして導入後に得られた効果をご紹介します。これから DSQL の採用を検討される方の参考になれば幸いです。 対象システム Aurora DSQL は、Japan Digital Design 株式会社が運営するドキュメント検索システムの一部である文書管理データベースとして利用しています。 本システムは、夜間バッチ連携される PDF や Web サイトの情報を取り込み・加工し、ユーザーが取込履歴や取込データ一覧を CSV としてダウンロードできる機能を提供しています。 アーキテクチャ 本システムは 2 つのワークロードで構成されています。 夜間バッチ処理 : 翌朝の Web アプリケーションの開局時間までに全ての取り込み・加工処理を終わらせる必要があるため、AWS Step Functions にて約 1,800 の Amazon ECS タスク（EC2 上で稼働）を並列起動。上流から取り込んだデータを各タスクが処理して、取込結果を Aurora DSQL に書き込む Web アプリケーション : Amazon CloudFront + ALB + Amazon ECS で構成された Web アプリケーションから Aurora DSQL のデータを読み取り、取込データ一覧を CSV として提供 夜間バッチでは、 ピーク時に 1 晩あたり 10 万件超 のファイル／レコードを処理します。バッチはユーザーが利用しない夜間にのみ稼働し、日中の Web アプリケーションからの読み取りとは時間帯が分離されています。 データベース選定の背景 本システムは新規開発だったため、システムの特性に合わせてデータベースをゼロベースで検討できました。私たちがデータベースに求めた要件は以下の 3 点です。 1. 複数環境運用におけるコスト効率 本番・ステージング・開発など複数環境を運用するため、未使用環境にも固定費が発生するインスタンス課金型 DB ではコストが見合わないという課題がありました。 2. スパイクワークロードへの対応 夜間に約 1,800 の ECS タスクが並列書き込みを行うスパイクワークロードへの対応が必要でした。書き込みが夜間に集中する特性上、スケーラブルなアーキテクチャが望ましいと考えていました。 3. 将来のデータ拡大への備え 将来的にデータ量を 10 倍規模に拡大する計画があり、その都度性能調査・性能試験を行う工数は避けたいと考えていました。 Aurora DSQL を選択した理由 他の候補として Aurora Serverless、Aurora、DynamoDB を比較検討し、以下の理由から Aurora DSQL を選択しました。 サーバーレス・従量課金 夜間バッチ時のみコストが発生し、未使用環境の固定費を解消できます。Aurora Serverless では、コールドスタートを避けるために最小 ACU を 0.5 に設定すると環境ごとに固定費が発生しますが、DSQL では利用しない環境にほとんど料金がかかりません。 さらに、Aurora DSQL はアイドル状態が長期間続いても接続時の遅延が極めて小さく抑えられます。Aurora DSQL のクラスターライフサイクルでは、一定期間アイドル状態が続くとリソースを縮小（Idle 状態）し、さらに長期間接続がないとリソースをゼロにスケール（Inactive 状態）しますが、接続するだけで自動的に Active 状態に復帰します。一方、Aurora Serverless の自動一時停止機能（0 ACU へのスケーリング）では、再開時に通常約 15 秒、24 時間以上の一時停止後は 30 秒以上の待機が発生します。Web システムでこの遅延を許容できない場合、最小 ACU を 0.5 以上に維持する（＝固定費が発生する）か、定期的な ping 処理でウォームアップを維持する必要があります。DSQL ではこうした考慮が大幅に軽減され、週に 1 回程度しか動かないようなワークロードでも実用的な応答速度で利用できます。 メンテナンスゼロ パッチ適用やキャパシティ管理が不要で、DB 運用負荷を最小化できます。 SQL 互換性 — DynamoDB ではなく DSQL を選んだ理由 DynamoDB も検討しましたが、テーブル設計の特性と SQL 互換性を重視して Aurora DSQL を選択しました。 本システムは業務システムとしてある程度の複雑性を持ちます。DynamoDB でも構築は可能ですが、アクセスパターンに合わせたテーブル設計が求められる NoSQL のアプローチよりも、やりたいことを素直に SQL で表現できる RDB の方が健全なシステムを構築できると判断しました。開発チームの SQL への習熟度が高く、これまでの RDB の知見をそのまま活かせることも大きな要因でした。 そのうえで、RDB の選択肢の中でコスト面で最も優れていたのが Aurora DSQL でした。 スモールスタートから大規模まで、再設計なしに拡張できる 本システムは社内の利用者が使うためのシステムのため、最大ユーザー数は限定的です。Aurora DSQL は GA 当初、マルチリージョンの大規模スケーラビリティが注目されがちでしたが、私たちはむしろ「小さく始められ、必要に応じて再設計なしに大規模まで成長できる」点を評価しました。完全サーバーレスでゼロまでスケールダウンできるため、間欠的・小規模なワークロードでも無理なく利用でき、その後データ量やスループットが拡大しても、同じデータベースの特性・体験のまま使い続けられます。 Aurora DSQL に向いているワークロードかを見極める 採用にあたっては、本システムのワークロード特性が DSQL の設計思想に合致するかを、以下の 3 つの観点で事前に評価しました。DSQL の導入を検討されている方にも、そのまま使える判断基準だと思います。 判断基準 本システムでの評価 楽観的同時実行制御（OCC）で問題ないか 1 タスク = 1 ドキュメントで各タスクが独立した処理対象を扱い、同一レコードへの同時更新が発生しない。さらに書き込み（夜間バッチ）と読み取り（日中）が同時に発生しない OLAP（分析・集計クエリ）のユースケースがないか データの格納と CSV 出力が主用途で、分析・集計クエリは不要 スパイク型ワークロードか 夜間のみ集中した書き込み処理が発生し、日中の負荷は限定的 この 3 条件を満たすワークロードであれば、Aurora DSQL の特性を最大限に活かせると判断し、採用を決定しました。 開発スケジュール 2025 年 5 月末の Aurora DSQL GA（一般提供開始）を受けて検討を開始し、以下のスケジュールで開発を進めました。 時期 マイルストーン 2025 年 6 月 AWS Summit で Aurora DSQL の実動作を確認し、採用検討を開始 2025 年 8 月 事前検証開始（マイグレーションツールの動作確認等） 2025 年 10 月 設計・開発開始 2026 年 1 月 本番ローンチ GA から約 3 ヶ月で事前検証を経て開発に着手し、約 3 ヶ月の開発期間で本番ローンチを迎えることができました。 開発時の取り組みとハマりどころ 私たちはパートナーを介さず、すべて自社開発で Aurora DSQL を導入しました。AWS 公式ドキュメントを主な技術情報源とし、約 3〜4 ヶ月で習熟に至っています。 PostgreSQL 互換とはいえ DSQL 固有の制約はいくつかあり、開発中に検討した内容、および直面した課題と対処法を共有します。 ORM として SQLAlchemy、マイグレーションツールとして Alembic を採用 DSQL を利用する際の ORM とマイグレーションツールの選定前に、ORM とマイグレーションツールによる各 DB 操作で実施できるもの・できないものを一通り確認していきました。その上で、最終的に SQLAlchemy + Alembic を採用しました。 SQLAlchemy については、AWS が公開している aws-samples リポジトリに利用例が掲載されていることが決め手となりました。 https://github.com/aws-samples/aurora-dsql-samples/tree/main/python/sqlalchemy また、SQLAlchemy、Alembic のいずれも必要に応じて生 SQL の実行をサポートしている点も採用理由の一つでした。 大量データのフェッチとメモリ制限 十数万レコードを CSV 化する要件に対して、当初 LIMIT OFFSET 構文による分割取得を試みたところ、トランザクションあたりのワークメモリ上限 128 MiB の制約に抵触しました。LIMIT OFFSET の仕組み上、不要な OFFSET 分のデータもすべて取得してから最終的な結果を返すためです。 対処法: Primary Key として UUIDv7 や連番など一意で時系列なキーを採用しました。データ取得方法についても Keyset Pagination（WHERE 句で前回取得した ID 以降のデータを抽出）に切り替えることで解決可能です。 トランザクションサイズの制限 Aurora DSQL には、トランザクションブロックで変更できるテーブル行の最大数 3,000 件、書き込みトランザクションで変更されるデータの最大サイズ 10 MiB といった制限があります。 対処法: 設計段階からトランザクションサイズを意識し、処理を分割する方式を採用しました。後から気づくと手戻りが大きいため、設計初期にこの制約を織り込んでおくことをお勧めします。 列の変更対応 DSQL では DROP COLUMN、ALTER COLUMN、NOT NULL カラムの追加といった列定義の変更ができません。変更が必要な場合は、別テーブルを用意してデータを移行する対応が必要でした。 ローカル開発環境の整備 現時点では、Aurora DSQL の制約まで再現したローカルエミュレータは存在しません。PostgreSQL コンテナで代替すると、DSQL 固有の制約にローカルでは気づけないケースがありました。 対処法: 制約に抵触しやすい開発モジュールについては、ローカル環境から直接 DSQL に接続して開発する手法を取り入れました。 振り返って：AWS への早期相談は有効 私たちは自社開発のみで導入を完了しましたが、振り返ると、開発段階から AWS アカウントチームに相談していれば、DSQL 固有の制約やノウハウ（フェッチの取り方など）をより早く把握でき、改善要望も早期に提出できたと感じています。AWS 側でも DSQL の制約に関するナレッジを蓄積しており、開発段階から共有いただける体制があるとのことです。これから導入を検討される方には、開発の早い段階でのアカウントチームへの相談をお勧めします。 導入後の効果 コスト約 87% 削減 Aurora Serverless（コールドスタート回避のため最小 ACU を 0.5 に設定した場合）比で、約 87% のコスト削減を実現しました。多数の環境を運用するエンタープライズ案件では、利用しない環境にほとんど料金がかからない DSQL の料金体系により、環境数に比例したコスト増加を回避できています。稼働していなければ放置しても課金が発生しないため、開発環境の上げ下げを管理するバッチ処理やスクリプトも不要になりました。 運用工数ほぼゼロ キャパシティ管理・パッチ適用が不要となり、DB 運用工数がほぼゼロになりました。他のシステムでは、開発環境の上げ下げのバッチ作成、インスタンスの容量拡張、コールドスタート回避のための ping 処理など、細かな運用タスクがどうしても発生します。DSQL ではこれらがすべて不要です。DB 周りの運用管理にリソースがほぼ発生しなくなり、チームは開発や上流工程のタスクに集中できるようになりました。 小規模なシステム、たとえば週に 1 回程度しか動かないようなワークロードでも、コールドスタートなしで即座に応答できる点は、運用の手間を大きく削減してくれています。 データ 10 倍拡大も設定変更・性能チューニングなし データ量を約 10 倍（現在数十 GB 規模）に拡大した際も、DB 側の設定変更や性能チューニングは一切不要でした。DSQL 側には何も影響がなく、性能劣化も発生していません。今後もデータ格納量やバッチ利用時のスループットは拡大していく見込みですが、性能調査や性能試験に時間を取られることなく、DSQL の自動スケーリングで対応できる見通しです。 Multi-AZ 標準装備 デフォルトで Multi-AZ が担保されており、追加設定なしで AZ 障害耐性を確保できています。 総括すると、 コストと運用負荷の削減が Aurora DSQL 導入の最大のメリット でした。環境数がかなり多い本システムでは、利用しない環境にほとんど料金がかからない DSQL の料金体系がマッチしていました。データ量を約 10 倍に拡大した際も、DB 周りは追加の設定変更なく対応できています。 最後に データ格納量やバッチ利用時のスループットは今後も継続的に拡大していく見込みであり、Aurora DSQL の強みを引き続き有効活用していく方針です。また、三菱UFJフィナンシャル・グループ各社への AI 活用展開に向けて、Amazon Bedrock をはじめとする AWS の AI 関連サービスの拡充にも期待しています。 Aurora DSQL 自体に対しては、クエリログ（監査ログ）の実装や ALTER TABLE/COLUMN 対応による列定義変更の柔軟性向上を期待しています。 本記事が、Aurora DSQL の採用を検討されている方の一助になれば幸いです。 執筆者 佐藤 慎 Japan Digital Design 株式会社 Technology & Development Division テクニカルプロジェクトマネージャ Japan Digital Design 株式会社にて金融機関向けシステム・AI導入案件のプロジェクトマネージャを担当。 Amazon Aurora DSQLをはじめとするクラウドネイティブ技術を活用したプロダクトの本番導入に取り組んでいる。

はじめに こちらの記事 で実際にKubernetes環境にKubeBlocksを導入し、DBaaSの基盤を構築しました。 前回の記事 ではKubeBlocksを利用してDBaaS基盤上にMySQLを構築しました。 今回は、KubeBlocksを利用してNoSQLのインメモリデータベースであるRedisを構築していきます。 導入環境構成図 以下の図は、DBaaS基盤上にRedisを導入する環境の構成図です。 「KubeBlocksオペレーター」は こちらの記事 で構築しました。 本記事では、赤丸で囲まれた「DB(Redis)」の構築を対象とします。 Redisはすべてのデータをメモリ上で処理する「インメモリデータベース」の一種で、NoSQLに分類されます。 ディスク（SSD/HDD）にアクセスする一般的なデータベースと比較して圧倒的に高速なのが特徴で、主にWebサイトやアプリの高速化（キャッシュ）や、リアルタイム処理に利用されるDBになります。 導入環境構成図 Redisの構築方法 KubeBlocksを使用してRedisを構築する手順をご紹介します。 今回は最もシンプルな、1台のサーバーでRedisを稼働させるスタンドアロン構成で作成していきます。 前提条件 KubeBlocksが構築済みであること KubeBlocksによってデフォルトでインストールされるRedisアドオン（以下コマンド結果のredis 1.0.1）が有効になっていること 以下のkbcliコマンドで有効化されているアドオンを確認することができます。 kbcli addon list # 出力例 NAME VERSION PROVIDER STATUS AUTO-INSTALL qdrant 1.0.1 community Disabled false rabbitmq 1.0.1 community Disabled false apecloud-mysql 1.0.1 community Enabled true etcd 1.0.1 community Enabled true kafka 1.0.1 community Enabled true mongodb 1.0.1 community Enabled true mysql 1.0.1 community Enabled true postgresql 1.0.1 community Enabled true redis 1.0.1 community Enabled true Namespeaceの作成 まずはRedisをデプロイするNamespeaceを作成します。 kubectl create namespace redis # 出力例 namespace/redis created デフォルトユーザー認証用Secretの作成 Redisのデフォルトユーザー用のユーザー名・パスワードを設定したSecretを作成します。 kubectl create secret generic custom-redis-root-secret \ --from-literal=username='default' \ --from-literal=password='<任意の値>' \ -n redis # 出力例 secret/custom-redis-root-secret created ※Redis作成時に本手順で作成したSecretを指定することで、デフォルトユーザーのパスワードを任意の値で設定することができます。 Secretの指定がない場合は、KubeBlocksがデフォルトユーザー用のパスワードを自動発行します。 Redisの作成 MySQLクラスター構築時と同様に、KubeBlocksのカスタムリソースである「Cluster」のマニフェストを適用し、Redisを作成します。 cat <<EOF | kubectl apply -f - apiVersion: apps.kubeblocks.io/v1 kind: Cluster metadata: name: redis-cluster namespace: redis spec: terminationPolicy: Delete clusterDef: redis topology: standalone componentSpecs: - name: redis replicas: 1 systemAccounts: - name: default secretRef: name: custom-redis-root-secret namespace: redis serviceVersion: 8.0.3 disableExporter: false resources: limits: cpu: "0.5" memory: "0.5Gi" requests: cpu: "0.5" memory: "0.5Gi" volumeClaimTemplates: - name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi EOF # 出力例 cluster.apps.kubeblocks.io/mycluster created clusterDef: redis Redisアドオンが提供するRedisの構成テンプレートを、作成するDBクラスターのベースとして指定する設定です。 topology: standalone Redisを単一のRedisサーバーインスタンスで構成されるスタンドアロンクラスターとして起動する設定です。 terminationPolicy: Delete クラスターを削除した際、関連するデータも一緒に削除する設定です。 systemAccounts Redisのデフォルトユーザーの認証情報（ユーザー名・パスワード）に、事前に作成したSecretを割り当てる設定です。 volumeClaimTemplates DBのデータを保存するためのPVの設定です。 Redisの作成確認 Redis作成コマンド実行後、以下のコマンドでクラスター・Podのステータスを確認します。ステータスがRunningになっていれば正常に動作しています。 kubectl get cluster redis-cluster -n redis # 出力例 NAME CLUSTER-DEFINITION TERMINATION-POLICY STATUS AGE redis-cluster redis Delete Running 110s kubectl get pods -n redis # 出力例 NAME READY STATUS RESTARTS AGE redis-cluster-redis-0 4/4 Running 0 2m15s 動作確認 Redisへの接続テストを行います。 まず、作成したRedisのエンドポイント（Service名）を確認します。 kubectl get svc -l app.kubernetes.io/instance=redis-cluster -n redis # 出力例 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE redis-cluster-redis-redis ClusterIP 10.43.163.160 <none> 6379/TCP 3m kubectl runコマンドでRedisクライアント用のPodを作成し、コンテナ内でシェルを起動します。 kubectl run redis-client -n redis --rm -i --tty --image=redis:8.0.3 --restart=Never -- bash # 出力例 If you don't see a command prompt, try pressing enter. root@redis-client:/data# redis-clientコマンドを使用し、確認したRedisのエンドポイント、「 デフォルトユーザー認証用Secretの作成 」で作成したユーザ名・パスワードを指定して接続します。 root@redis-client:/data# redis-cli -h redis-cluster-redis-redis.redis.svc.cluster.local -p 6379 --user default --pass xxxxx # 出力例 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. redis-cluster-redis-redis.redis.svc.cluster.local:6379> Redisに正常に接続できているか、以下のPINGコマンドを使用して確認します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> PING # 出力例 PONG 「PONG」が出力されれば、正常に接続できています。 続いて、データの登録・取得が行えるかを確認します。 キー「test」に値「”Hello World” 」を登録します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> SET test "Hello World" # 出力例 OK 登録したデータが正しく取得できるかを確認します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> GET test # 出力例 "Hello World" 登録した「”Hello World” 」という文字列が出力されれば、Redisへのデータ登録と取得は正常に行えています。 これでRedisの構築と動作確認は完了になります。 おわりに 前々回構築したKubeBlocksを使用し、実際にRedisの構築から接続テストを行うまでの流れをご紹介しました。 前回のMySQL構築に引き続き、容易にRedisを構築できることを体感できたのではないでしょうか 。 今回は最もシンプルな「Redisサーバ1台のスタンドアロン構成」として構築しましたが、KubeBlocksなら本番環境向けの冗長構成も、マニフェストの設定を少し変更するだけで簡単に構築することができます。 KubeBlocksは様々なDBをサポートしているため、他のDBも同様の方法で手軽に導入することができます。 本記事が、Kubernetes上でDBを構築する際の選択肢として、KubeBlocksを検討するきっかけになれば幸いです。 参考文献 https://kubeblocks.io/docs/preview/kubeblocks-for-redis/03-topologies/01-standlone https://kubeblocks.io/docs/preview/kubeblocks-for-redis/06-custom-secret/01-custom-secret ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KubeBlocksでRedisを導入！Kubernetes上での高速キャッシュ/NoSQL構築を体験 first appeared on SIOS Tech Lab .

はじめに こちらの記事 で実際にKubernetes環境にKubeBlocksを導入し、DBaaSの基盤を構築しました。 今回は、作成したDBaaS基盤の上に実際にMySQLクラスターを構築していきます。 導入環境構成図 以下の図は、DBaaS基盤上にMySQLを導入する環境の構成図です。 前回の記事 では「KubeBlocksオペレーター」を構築しました。 本記事の対象範囲は、赤丸で囲まれた「DB(MySQL)」です。 今回は例として、プライマリ-レプリカ構成のMySQLをKubeBlocksオペレーターを利用して導入します。 この構成では、データの書き込み・読み込みを行う「プライマリ」と、読み込み専用の「レプリカ」を配置します。 万が一プライマリに障害が発生したとしても、レプリカが自動的にプライマリに昇格して処理を引き継ぐフェイルオーバー機能が働き、高可用性を確保できるのが特徴です。 導入環境構成図 MySQLクラスターの構築方法 KubeBlocksを使用してMySQLクラスターを構築する手順をご紹介します。 前提条件 KubeBlocksが構築済みであること KubeBlocksによってデフォルトでインストールされるMySQLアドオン（以下コマンド結果のmysql 1.0.1）が有効になっていること 以下のkbcliコマンドで有効化されているアドオンを確認することができます。 kbcli addon list # 出力例 NAME VERSION PROVIDER STATUS AUTO-INSTALL qdrant 1.0.1 community Disabled false rabbitmq 1.0.1 community Disabled false apecloud-mysql 1.0.1 community Enabled true etcd 1.0.1 community Enabled true kafka 1.0.1 community Enabled true mongodb 1.0.1 community Enabled true mysql 1.0.1 community Enabled true postgresql 1.0.1 community Enabled true redis 1.0.1 community Enabled true Namespeaceの作成 まずはMySQLクラスターをデプロイするNamespeaceを作成します。 kubectl create namespace demo # 出力例 namespace/demo created rootユーザー認証用Secretの作成 MySQLのrootユーザー用のユーザー名・パスワードを設定したSecretを作成します。 kubectl create secret generic custom-mysql-root-secret \ --from-literal=username='root' \ --from-literal=password='<任意の値>' \ -n demo # 出力例 secret/custom-mysql-root-secret created ※MySQLクラスター作成時に本手順で作成したSecretを指定することで、rootユーザーのパスワードを任意の値で設定することができます。 Secretの指定がない場合は、KubeBlocksがrootユーザー用のパスワードを自動発行します。 MySQLクラスターの作成 KubeBlocksのカスタムリソースである「Cluster」のマニフェストを適用し、レプリカ数2のプライマリ-レプリカ構成のMySQLクラスターを作成します。 cat <<EOF | kubectl apply -f - apiVersion: apps.kubeblocks.io/v1 kind: Cluster metadata: name: mysql-cluster namespace: demo spec: clusterDef: mysql topology: semisync terminationPolicy: Delete componentSpecs: - name: mysql serviceVersion: 8.0.35 disableExporter: false replicas: 2 systemAccounts: - name: root secretRef: name: custom-mysql-root-secret namespace: demo resources: limits: cpu: '0.5' memory: 1Gi requests: cpu: '0.5' memory: 1Gi volumeClaimTemplates: - name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi EOF # 出力例 cluster.apps.kubeblocks.io/mycluster created clusterDef: mysql MySQLアドオンが提供するMySQLの構成テンプレートを、作成するDBクラスターのベースとして指定する設定です。 topology: semisync MySQLクラスターをプライマリ-レプリカ構成の準同期レプリケーションモードで起動する設定です。 terminationPolicy: Delete クラスターを削除した際、関連するデータも一緒に削除する設定です。 replicas: 2 MySQLサーバーを2台（プライマリ1台、レプリカ1台）デプロイする設定です。 systemAccounts MySQLのrootユーザーの認証情報（ユーザー名・パスワード）に、事前に作成したSecretを割り当てる設定です。 volumeClaimTemplates DBのデータを保存するためのPVの設定です。 MySQLクラスターの作成確認 MySQLクラスター作成コマンド実行後、以下のコマンドでクラスター・Podのステータスを確認します。ステータスがRunningになっていれば正常に動作しています。 kubectl get cluster mycluster -n demo # 出力例 NAME CLUSTER-DEFINITION TERMINATION-POLICY STATUS AGE mycluster mysql Delete Running 7m30s kubectl get pod -n demo # 出力例 NAME READY STATUS RESTARTS AGE mycluster-mysql-0 4/4 Running 0 8m mycluster-mysql-1 4/4 Running 0 8m 動作確認 接続テスト MySQLクラスターへの接続テストを行います。 まず、作成したMySQLクラスターのエンドポイント（Service名）を確認します。 kubectl get svc -n demo # 出力例 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mycluster-mysql ClusterIP 10.43.32.224 <none> 3306/TCP 8m kubectl runコマンドでMySQLクライアント用のPodを作成し、コンテナ内でシェルを起動します。 kubectl run mysql-client -n demo --rm -i --tty --image=mysql:8.0 --restart=Never -- sh # 出力例 If you don't see a command prompt, try pressing enter. sh-5.1# mysqlコマンドを使用し、確認したMySQLクラスターのエンドポイントを指定してログインします。パスワードを求められたら設定したパスワードを入力します。 sh-5.1# mysql -h mysql-cluster-mysql.demo.svc.cluster.local -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 246 Server version: 8.0.35 MySQL Community Server - GPL Copyright (c) 2000, 2026, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> mysql>という出力が表示されればMySQLクラスターに接続できています。 フェイルオーバーテスト MySQLクラスターのフェイルオーバー機能を実際にテストしてみます。 まず起動したMySQLのPodのうち、どれが「プライマリ」で、どれが「レプリカ」なのかを確認します。 kbcli cluster describe mycluster -n demo | grep -E "ROLE|primary|secondary" # 出力例 COMPONENT SERVICE-VERSION INSTANCE ROLE STATUS AZ NODE CREATED-TIME mysql 8.0.35 mycluster-mysql-0 primary Running us-east-1a ip-10-1-0-23/10.1.0.23 Jun 25,2026 08:00 UTC+0000 mysql 8.0.35 mycluster-mysql-1 secondary Running us-east-1a ip-10-1-0-24/10.1.0.24 Jun 25,2026 08:01 UTC+0000 各PodのROLEの値を確認すると、mycluster-mysql-0がprimary、mycluster-mysql-1がsecondaryとなっています。 これは、mycluster-mysql-0が「プライマリ」、mycluster-mysql-1が「レプリカ」として構成されていることを表しています。 次にプライマリのPodを削除することで、プライマリに擬似的な障害を発生させます。 kubectl delete pod mycluster-mysql-0 # 出力例 pod "mycluster-mysql-0" deleted プライマリのPodを削除後、レプリカのPodが自動的にプライマリに昇格していることを確認します。 kbcli cluster describe mysql-cluster -n demo | grep -E "ROLE|primary|secondary" # 出力例 COMPONENT SERVICE-VERSION INSTANCE ROLE STATUS AZ NODE CREATED-TIME mysql 8.0.35 mycluster-mysql-0 secondary Running us-east-1a ip-10-1-0-23/10.1.0.23 Jun 25,2026 08:06 UTC+0000 mysql 8.0.35 mycluster-mysql-1 primary Running us-east-1a ip-10-1-0-24/10.1.0.24 Jun 25,2026 08:01 UTC+0000 先ほどレプリカであったmycluster-mysql-1が、プライマリに昇格していることがわかります。 これでMySQLクラスターの構築と動作確認は完了になります。 おわりに 今回は 前回 構築したKubeBlocksを使用し、実際にMySQLクラスターの構築から接続テスト・フェイルオーバのテストを行うまでの流れをご紹介しました。 KubeBlocksを活用すれば、シンプルなマニフェストを1つ適用するだけで、容易に冗長化されたMySQLクラスターを構築できることを体感できたのではないでしょうか。 KubeBlocksの大きな特徴は、様々なデータベースを同じ操作感で統一して管理できる点にあります。 そこで次回は、MySQLとはまた異なる特性を持つNoSQLのインメモリデータベースであるRedisの構築についてご紹介します。 参考文献 https://kubeblocks.io/docs/release-1_0_1/kubeblocks-for-mysql/02-quickstart https://kubeblocks.io/docs/release-1_0_1/kubeblocks-for-mysql/06-custom-secret/01-custom-secret ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KubeBlocksでMySQLを導入！Kubernetes上でのDB構築を体験 first appeared on SIOS Tech Lab .