Cloud Steps

1. はじめに システム開発をする中で、Docker でコンテナイメージのビルドされている方は多いのではないでしょうか。 コンテナイメージは、可搬性に優れており、どの環境（開発環境、検証環境、本番環境）でもアプリケーションを動作させることができるメリットがあり、開発者には大きな安心感を与えます。 しかしながら、イメージタグの理解が乏しいと、同じイメージを利用しているはずなのに、開発環境と本番環境で異なるイメージが利用されることがありえます。 この記事では、イメージタグの誤解から生じる問題と対策について記述します。 2. イメージタグに対する誤解 イメージタグは、ミュータブル（変更不可能）ではなく、ミュータブル（変更可能）です。 以下は検証結果です。 2.1. Dockerfile 作成 FROM alpine CMD ["echo", "This is Version 1.0 of the image!"] 2.2. ビルドする ~/Desktop/docker-test$ docker build -t test-image:1.0 . [+] Building 0.1s (5/5) FINISHED docker:default => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 98B 0.0s => [internal] load metadata for docker.io/library/alpine:latest 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [1/1] FROM docker.io/library/alpine:latest 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:d7cbeb7e099abb6ef223dbef9a5b39f11ba31c4ab8433 0.0s => => naming to docker.io/library/test-image:1.0 2.3. イメージを確認する タグとイメージID を確認する。

1. はじめに Kubernetes において、Pod のデプロイ戦略として、ローリングアップデート　が用意されています。 ローリングアップデートは、よく知られたデプロイ戦略です。 ただし、ローリングアップデートの実施前に確認しておかないと、想定していない障害や不具合が発生することがあります。 この記事では、ローリングアップデート実施前の確認事項をまとめています。 2. ローリングアップデートとは ローリングアップデートとは、システム全体停止を行わず、順次 Pod (コンテナ) を新しいバージョンの Pod へと段階的に入れ替えていくデプロイ手法です。 2.1. メリット ダウンタイムが生じない 常に一定数の Pod が存在しているため、サービス停止せず更新を行うことができます。 リスク分散 一度に全ての Pod を入れ替えないため、新しいバージョンに問題があった場合でも、影響範囲が少なくてすみます。 2.2. 注意点 ローリングアップデートの注意点として、古い Pod と 新しい Pod が一時的に存在する時間が生まれてしまうことです。 この時、ユーザーによって、アクセスする Pod が異なる場合があります。 こういった挙動で不具合が生じる可能性があるシステムで利用する場合は、注意が必要です。 3. 最初に確認したい全体観点 レプリカ数の確認 maxUnavailable / maxSurge Readiness / Liveness Probe 4. レプリカ数の確認 ローリングアップデートを行う事前確認として、レプリカの数を kubectl get deployment コマンド で確認を行うのが良いです。 レプリカ数が 1 の場合 maxUnavailable を 0 と設定したとしても Pod の切替時に処理落ちが発生する可能性があるため、レプリカ数 は、2 以上あることが望ましいで 5. maxUnavailable / maxSurge の設定 Kubernetes では、設定変更することで ローリングアップデート時の挙動を変更することが可能です。

1. はじめに Kubernetes の運用・保守していると Pod が正常に立ち上がらない問題に遭遇します。 立ち上がらない理由は、多くあると思いますが、初動確認手順は、おおよそ似通っているため、調査手順をまとめてみました。 不具合が起こった時、焦ってしまいますが、ある程度手順を決めておくと冷静に対処できると思います。 1.1. 検証環境について 本記事の動作確認には、ローカル環境で手軽に Kubernetes クラスターを構築できる kind (Kubernetes IN Docker) を使用しています。 2. 全体の調査フロー 異常な Pod を特定する kubectl get pod -A で稼働していない Pod の特定を行う。 Pending, CrashLoopBackOff, ImagePullBackOff など describe でイベントを確認する kubectl describe pod -n logsでコンテナの中を確認 kubectl logs -n 依存リソースも確認 3. 異常な Pod を特定する kubectl get pod -A で全名前空間の Pod を一覧する。 異常なステータスの Pod を特定する。ここでは、error-image-pod の ImagePullBackOff の状態であることがわかります。 kubectl get pod -A NAMESPACE NAME READY STATUS RESTARTS AGE default error-image-pod 0/1 ImagePullBackOff 0 20s kube-system coredns-7d764666f9-54bl2 1/1 Running 0 3m40s kube-system coredns-7d764666f9-kn66c 1/1 Running 0 3m40s kube-system etcd-kind-control-plane 1/1 Running 0 3m46s kube-system kindnet-q75q4 1/1 Running 0 3m40s kube-system kube-apiserver-kind-control-plane 1/1 Running 0 3m46s kube-system kube-controller-manager-kind-control-plane 1/1 Running 0 3m45s kube-system kube-proxy-tw269 1/1 Running 0 3m40s kube-system kube-scheduler-kind-control-plane 1/1 Running 0 3m46s 4. describe でイベントを確認する kubectl describe pod で pod のイベント詳細を確認する。

1. はじめに 本番環境のみのシステムで CLI (kubectl 等) のバージョンアップを行う必要がありました。 本番環境は、顧客が利用しているため、動作確認しない状態でバージョンアップすることはトラブルにつながると考えました。 そのため、EC2 から AMI を作成し、そこから検証用インスタンスを作成し、バージョンアップから動作確認ができるようにしました。 2. 想定している状況 サーバー（EC2）が本番環境のみでCLI等バージョンアップの検証を行いたい場合 ※ CLI のみなど軽微な検証を想定 3. 今回の作業の流れ 作業内容は以下の流れを想定しています。 EC2 から AMI の作成 ↓ AMI からEC2 インスタンス作成 ↓ バージョンアップの実施 ↓ 動作確認 ↓ 本番環境へ適用 4. EC2からAMIを作成 AWSマネジメントコンソール＞EC2＞対象のEC2を選択＞アクション＞イメージとテンプレート＞イメージを作成 を押下する。 任意のイメージ名を入力＞イメージを作成する。 5. AMIから検証EC2を作成 AWSマネジメントコンソール＞EC2＞AMI＞対象のAMIを選択＞AMIからインスタンスを起動を押下する。 AMI から作成するインスタンス名を入力する。 AMI から作成するインスタンスの配置するVPC やセキュリティグループ等を入力＞インスタンス起動を押下する。 6. バージョンアップの検証 新しく作成した EC2 インスタンス上でバージョンアップの検証を行う。 ※ ここは読者の皆様の環境に合わせて実施 8. 本番環境へ適用 6. バージョンアップの検証 で行った内容を本番環境で実施し、動作確認後問題なければ、作業完了です。 9. まとめ AMI を利用すると、EC2 の複製を簡単に作成することができるので、本番環境の EC2 から AMI を作成し、検証用インスタンスをらくらく作成可能です。 本番適用する前に検証を行いたいときはこの AMI を利用するとよいと検証作業がはかどります。

1. はじめに Linuxを学習する際、毎回EC2を手動で作成して環境を用意していました。 ただ、この作業は学習のたびに行う必要があり、少し手間だと感じていました。 そこで今回、AWS CDKを使ってLinux学習用のEC2環境をコードで構築できるようにしました。 これにより、 学習環境をすぐに作成できる 同じ環境を再現できる IaCの練習にもなる といったメリットを得ることができました。 この記事では、AWS CDKを使ってLinux学習環境を構築した方法を紹介します。 2. 背景 Linuxの学習では、実際にサーバーを触りながらコマンドを試すことが重要です。 しかし、学習用の環境を毎回手動で構築する場合、 EC2の作成 セキュリティグループの設定 VPC の作成 Session Manager の作成 などの作業が必要になります。 このような作業は毎回同じ手順であり、**自動化できる作業（Toil）**だと感じました。 そこで、AWS CDKを使って学習環境をIaC化することにしました。 3. 作ったもの Linux学習用のEC2環境を、AWS CDKで簡単に構築できるプロジェクトを作成しました。 GitHubはこちらです。 https://github.com/kohei-iwamoto-wa/linux_learning 主な特徴は以下です。 AWS CDKによるインフラ構築 Linux学習用EC2の自動作成 CDK destroyで環境削除可能 EventBridge Scheduler で CloudFormation スタックを定時で削除（リソース削除忘れ防止のため） 4. 構成 今回の構成はシンプルです。 AWS CDK VPC ↓ EC2 (Amazon Linux) ↓ Linux学習 CDKでEC2インスタンスを作成し、SSHで接続してLinuxコマンドの学習を行います。 5. CDKを使うメリット 今回CDKを使ったことで、次のメリットがありました。 5.1. 環境構築の自動化 手動でEC2を作成する必要がなくなり、 コマンド一つで学習環境を構築できるようになりました。 5.2. 再現性のある環境 IaCとして管理することで、 いつでも同じ構成の環境を再現できます。 5.3. IaCの練習になる CDKを使うことで、インフラをコードとして管理する 実践的な練習にもなりました。

1. はじめに Amazon Aurora の復旧機能を調査する機会があり、ポイントインタイムリカバリ（PITR） に関して勘違いしていたポイントをまとめました。 2. 継続的バックアップとポイントインタイムリカバリ（PITR） 2.1. 継続的バックアップとは？ 継続的バックアップとは、DBインスタンスへの書き込みと並行して、トランザクションログをリアルタイムでストレージ（Amazon S3）に保存し続ける仕組みのことです。 2.2. ポイントインタイムリカバリとは？ ポイントインタイムリカバリ（PITR）とは、継続的なバックアップデータを利用し、過去35日前から現在より5分前までの任意の時点を指定してデータを復元できる機能のことです。 3. 勘違いしていたポイント PITR について勘違いしていたポイントは、「現在のクラスターが過去の状態にロールバックされる」とイメージしていましたが、実際には異なります。 3.1. 既存クラスターで復旧されない PITRを実行すると、指定した時点のデータの新しいDBクラスター」が作成されます。 元のクラスター: そのまま残ります（調査や比較に使用可能）。 新しいクラスター: 指定した時刻の状態で新規作成されます。 ※ 新しいクラスターが作成されるためエンドポイントが変更されます。 3.2. なぜ「新しいクラスター」なのか？ これには以下のメリットがあります。 安全性の確保: 復元操作に失敗しても、現在の本番環境（既存クラスター）に影響を与えません。 3.3. 注意すべき点 PITRは、RPO（Recovery Point Objective）の達成には非常に有効なバックアップ方法ですが、PITR はクラスターを別途新規で作成した上で復元するため、復元にはある程度の時間がかかることが想定されます。復旧にかかる時間は事前にテストしておき、RPO,RTOが達成できることを確認すべきです。 REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する 4. PITR を有効化する設定 PITR を有効化するためには、BackupRetentionPeriod(バックアップ保持期間) を１以上で設定する必要があります。 こちらを設定すると自動バックアップ（スナップショット）が有効になるのと同時に継続的バックアップも有効になります。 4.1. RDS設定用CloudFormationのサンプル TestDB: Type: "AWS::RDS::DBInstance" Properties: DBInstanceIdentifier: test-db Engine: postgres EngineVersion: 17.6 DBInstanceClass: db.t3.micro AllocatedStorage: 30 StorageType: gp2 DBName: eksworkdb MasterUsername: user MasterUserPassword: password DBSubnetGroupName: !Ref EksWorkDBSubnetGroup PubliclyAccessible: false MultiAZ: false PreferredBackupWindow: 18:00-18:30 PreferredMaintenanceWindow: sat:19:00-sat:19:30 AutoMinorVersionUpgrade: false DBParameterGroupName: !Ref EksWorkDBParameterGroup VPCSecurityGroups: - !Ref RdsSecurityGroup CopyTagsToSnapshot: true # この設定が必要（１以上に設定することで有効化する） BackupRetentionPeriod: 7 DeletionProtection: false 5. PITRの実施 5.1. データ登録 eksworkdb=> \dt List of relations Schema | Name | Type | Owner --------+-------+-------+------------ public | users | table | eksdbadmin (1 row) eksworkdb=> select * from users; user_id | username | email | status | created_at ---------+----------+--------------------+--------+---------------------------- 1 | tanaka | tanaka@example.com | active | 2026-01-07 14:16:21.683738 2 | suzuki | suzuki@example.com | active | 2026-01-07 14:16:21.683738 3 | sato | sato@example.com | active | 2026-01-07 14:16:21.683738 5.2. データ削除 eksworkdb=> TRUNCATE TABLE users RESTART IDENTITY; TRUNCATE TABLE eksworkdb=> select * from users; user_id | username | email | status | created_at ---------+----------+-------+--------+------------ (0 rows) 5.3 復元 AWSマネジメントコンソール＞RDS＞アクション＞特定時点への復元を押下する。

1. 何が起きたか Amazon Aurora PostgreSQL-Compatible Edition を利用しているシステムがあり、PostgreSQLのバージョンが13系でした。 Aurora PostgreSQL のリリースカレンダーを確認すると Auroraの標準サポート終了日が迫っていることに気がついたため、バージョンアップ計画とバージョンアップ手順の作成していました。 DBメンテナンスの事前作業手順にECSタスクのタスク停止し、アプリケーションからデータベースへのアクセスを防ごうとしていたのですが、タスクをAWSマネジメントコンソールからタスク停止を行ったところ数分後にタスクが立ち上がっていました。 もしこれが本番環境だった場合、アプリケーションからDBの操作が発生し事故に発展する可能性があります。 正しいECSタスクの止め方とユーザーからのアクセスを止める方法について述べていきます。 2.2. 復活した理由 結論：ECSサービスが「あるべき姿（Desired Count）」を維持しようとしたためです。 ECSサービスには、*「常に実行しておきたいタスクの数」*を指定する desiredCount（希望するタスク数）という設定があります。 ECSサービスは、以下のタスクを監視しています。 理想（Desired）： ユーザーが設定した「実行したいタスク数」 現実（Running）： 実際に動いているタスクの数 今回、私が手動でタスクを停止したことで、ECSサービスは「現実が理想を下回った」と判断しました。その結果、サービスは自動的に新しいタスクを起動し、差分を埋めようとしたのです。 ※ ECSにとって、手動停止もシステム障害も「タスクが減った」という事実に変わりはありません。desiredCount が 0 でない限り、タスク内のコンテナが復活します。 3. 正しい対処方法 ECS 上で稼働させているアプリケーションからDB にアクセスさせたくないケースがあるのであれば、タスクを停止するという方法はおすすめできません。 前述したとおり、ECS サービスで設定したdesiredCountの設定値通りのコンテナをECS サービスが稼働させ続けようとするからです。 以下、ECS へ接続を防ぐ方法の一例です。 3.1. タスクを停止する場合 ECS タスク内のコンテナを停止させたい場合は、ECS サービスの desiredCount を 0 に設定を変更させます。 この設定により ECS サービスのがECS タスク内のコンテナ数を 0 に自動的に保つようになります。 3.2. ALB (Application Load Balancer) の場合 セキュリティグループのインバウンドルールを一時的に削除（または許可されていないものに変更）する方法です。 これにより、ECSタスクが動いていたとしても、外部からのリクエストがDBに到達する前にALBで遮断されます。 ※注意: ユーザーにはタイムアウトやエラー画面が表示されるため、あらかじめメンテナンス画面（Sorryページ）への切り替え設定もセットで検討するのが理想的です。 4. 学び 4.1. タスク停止ではなくサービスの設定変更 ECS などのクラウドネイティブなリソースは、停止ではなく、サービスの設定変更で対応するのが理想的です。

1. はじめに CloudFormation（以下、CFnと呼ぶ）は、AWSのリソースの構築、管理、更新する上で非常に便利な IaC です。 一方で、CFn でリソースの更新を行う際、意図せずの更新、削除が行われるケースがあります。 本番環境で CFn を運用する中で意図しない更新や削除は行いたくないものです。 CFn 運用時の削除防止について記述していきます。 2. 削除防止機構の種類と説明 2.1. スタックポリシー（Stack Policy） スタックポリシーは、意図しない更新からリソースを保護することに役立ちます。 スタックを作成するとすべてのリソースが更新を許可されていますが、スタックポリシーを設定することでスタック内のすべてのリソースが更新できないようになります。 デフォルトではすべてのリソースが更新不可になりますがスタックポリシーの設定で更新不可対象のリソースを選択することができます。 ※ スタックポリシーは、更新のみ対応しており、削除は対応しいません。 2.2. 削除ポリシー（Deletion Policy） 削除ポリシーは、スタックの削除が行われた際のリソースの扱いを指定することが可能です。 2.2.1. 保持 削除ポリシーで「保持」を設定した場合でもAWSリソースの削除は行われません。 2.2.2. スナップショット スタック削除された場合、AWS リソースが削除される前にスナップショットを取得します。 ※ この機能は、スナップショット機能がサポートされているAWSリソースに限ります。 例）EC2、RDS、EFS等 2.2.3. 削除 削除ポリシーで「削除」を設定した場合、AWSリソースは削除されます。 ※ 削除ポリシーはデフォルトでは、「削除」が設定されています。 2.3. 終了保護 終了保護は、スタック自体の削除防止を目的とした機能です。 削除保護を有効にするとAWSマネジメントコンソール等からスタックの削除できなくなります。 また、対象のスタックがネステッドスタックの場合、親スタックに終了保護が適用されていれば、子スタックに対しても終了保護が適用されます。 ただし、注意すべき点があります。終了保護はスタック自体の削除は保護されますが、リソースの更新に伴う削除からはリソースを守ることができません。 例）CFn で S3バケット のリソースを作成されていて、CFn テンプレートからS3バケットの記述を削除後、スッタックの更新をした場合はS3バケットは削除されます。 3. 削除防止で注意すべき点 2. 削除防止機構の種類と説明 でAWS が提供している３つの削除保護機構について説明してきました。 これらはAWSリソース、スタックの意図しない削除や更新から環境を守るために非常に強力な機能です。 しかしながら、これらの機能単体ではスタックやリソースを守り切ることはできません。 スタックポリシーでは、スタック内のリソースの意図しない更新を防ぐことはできますが、スタック内リソースの削除は防ぐことはできません。そのため、スタックポリシーだけではなく、削除ポリシーを有効にすることで意図しない削除からAWSリソースの保護を行うことが必要です。また、スタック自体の削除をフェールセーフの観点から防ぐためにも設定しておく必要があるでしょう。 このように、スタックポリシー、削除ポリシー、スタックポリシーを単体で適用するだけはスタック、リソースを守るには不十分で３つの削除保護機構を組み合わせることでより安全に CFn の運用が可能になります。 ご自身の現場に合う設定の組み合わせを考えてみるのがいいと思います。 4. ポリシーのテンプレート例 4.1 スタックポリシー AWSドキュメントのスタックポリシー例です。

1. はじめに 今回は、S3の同一リージョンレプリケーションについて学んでみました。 S3には、クロスリージョンレプリケーション（CRR）, 同一リージョンレプリケーション（SRR）の二種類のレプリケーション方式があります。 ２つのレプリケーションは名前の通り、CRRはリージョン間でS3のオブジェクトのコピーを行い、SRRは同一リージョン内でS3オブジェクトのコピーを行うことをいいます。 今回この記事を書こうとしたきっかけは、いまいちユースケースが思いつかなかったためです。 なのでドキュメントを読んでユースケースを書いていこうと思います。 2. 構成図 図の左：同一リージョンレプリケーション（SRR）、図の右：クロスリージョンレプリケーション 3. 同一リージョンレプリケーションとは（SRR）？ 同一リージョンレプリケーション（SRR）とは、同じAWSリージョン内のS3バケット間でオブジェクトを自動的にコピーする機能です。 4.　同一リージョンレプリケーション（SRR）のユースケース 同一リージョンレプリケーションはどのようなユースケースで利用されるのでしょうか？ 4.1. ログの集約 １つ目のユースケースは、複数のバケットや複数のアカウントにログを保管している場合、ログを簡単にコピーすることができます。 そうすることによって、ログの管理をシンプルにすることができます。 4.2. 本番稼働アカウントとテストアカウント間のライブレプリケーション ２つ目のユースケースは、アプリケーションの開発・検証中に本番環境のS3バケットのデータで検証を行いたいケースがあります。 同一リージョンレプリケーションを利用することによって、本番環境アカウントのS3バケットのデータを開発アカウントのS3バケットにコピーすることで、 開発・検証中に本番相当のデータを利用できるようになります。 4.3. データ主権に準拠する必要がある場合 S3のバックアップを遠隔地保管したいケースがあります。この場合、国外のリージョンへの保管を検討することがあるともいます。 しかし、法律やコンプライアンスの規制によりデータを国外のリージョンに保管できないケースがあります。 この場合、同一リージョンの別アカウントにS3のデータをコピーするケースがあります。 5. SRRの便利機能 5.1. S3 Replication Time Control S3 Replication Time Control (S3 RTC) という機能があります。この機能を利用すると99.9%のオブジェクトが15分以内にコピーすることができます。 この機能は、ビジネス要件で１５分以内にコピーを完了させる必要がある場合、利用されることがあります。 6. レプリケーションでコピーされる設定・コピーされない設定 6.1. レプリケーションでコピーされるもの レプリケーション設定でコピーされる項目を一部列挙します。 レプリケーション設定の追加後に作成されたオブジェクト 暗号化されていないオブジェクト ユーザー提供のキー (SSE-C) を使用して暗号化されたオブジェクト、Amazon S3 マネージドキー (SSE-S3) の下で保管時に暗号化されたオブジェクト、および AWS Key Management Service (SSE-KMS) に保存されている KMS キーで暗号化されたオブジェクト レプリケート元オブジェクトからレプリカへのオブジェクトメタデータ 作成日、更新日付等 オブジェクトタグ、存在する場合。 S3 オブジェクトロックの保持情報 6.1. レプリケーションでコピーされないもの レプリケーション設定前のオブジェクトはレプリケーション先にコピーされません。 もしコピーした場合は、別途レプリケーションを実行する必要があります。

1. はじめに AWSでAuorora, S3, EFSのバックアップ方法について検討していると、AWS Bacupというサービスがあることがわかりました。 RDSなどのサービスにはAWS Backupを利用せずに個別でバックアップ機能が備えられていますが、 AWS Backupを利用するメリット等、調べていました。 2. AWS Backupとは AWS Backupとは、AWSのさまざまなサービスにわたるバックアップを一元的に管理し、自動化するためのバックアップサービスです。AWS Backupを利用することで、複数のサービス（Amazon Aurora, Amazon S3, Amazon EFS, Amazon EC2, Amazon RDSなど）のバックアップを一元的に定義・実行できます。 ※この記事では、Amazon Aurora のバックアップについて取り扱います。 3. 構成要素 AWS Backupは、主に以下の3つの要素で構成されています。これらが連携することで、バックアップの**「どこに」「何を」「いつ・どのように」**実行するかを定義し、管理します。 3.1. バックアップボールト (Backup Vault) これは、作成されたバックアップデータが安全に保存される保管場所です。 保存場所: バックアップボールトは、バックアップされたリソースのデータが保管される場所です。 暗号化: バックアップデータは、KMSキーを使用して暗号化され、安全性が確保されます。 アクセス制御: IAMポリシーを使用して、誰が、いつ、どのようにボールト内のデータにアクセスできるかを厳密に制御できます。 ロック機能: ボールト内のバックアップを一定期間変更・削除できないようにロックする機能（Vault Lock）があり、コンプライアンス要件への対応に役立ちます。 3.2. バックアッププラン (Backup Plan) これは、**「いつ、どのように」**バックアップを作成するかを定義する要素です。 スケジュール設定: バックアップを作成する頻度（日次、週次、月次など）と時刻を定義します。 頻度とウィンドウ: バックアップジョブを実行する時間帯（バックアップウィンドウ）や、許容される完了時間を設定できます。 ライフサイクル設定: バックアップの保持期間を定義します。また、コールドストレージへの階層化（例：30日後に低コストのストレージに移行）のポリシーを設定し、コスト効率を高めることができます。 コピー設定: 異なるAWSリージョンや、別のAWSアカウントのバックアップボールトへ、自動的にバックアップをコピーする設定（クロスリージョン/クロスアカウントコピー）を含めることができます。 3.3. バックアップセレクション (Backup Selection) これは、**「どのAWSリソース」**をバックアッププランの対象とするかを定義するものです。 対象リソースの特定: 特定のAWSリソースタイプ（Aurora DBクラスタ、S3バケット、EFSファイルシステムなど）の中から、実際にバックアップを取得するインスタンスやボリューム、ファイルシステムを指定します。 4. メリット 4.1 一元管理 AWS Backupを利用することで、バックアップの一元管理を行うことが可能です。 Amazon Aurora のクラスターを複数管理しているアカウントがあるとします。 これらのクラスターごとでバックアップ設定を行うことは、手間がかかります。