

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# クラウドネイティブ AWS サービスのバックアップと復旧
<a name="cloud-native-aws-services"></a>

バックアップとリカバリのアプローチは、ワークロードで使用される AWS サービスを対象とする必要があります。 は、データを管理し、操作するためのサービス固有の機能とオプション AWS を提供します。コンソール、、 SDKs AWS CLI、および API オペレーションを使用して、使用している AWS サービスのバックアップとリカバリを実装できます。このガイドでは、例として [Amazon RDS](rds.md) と [Amazon DynamoDB](dynamodb.md) について説明します。 AWS Backup は、DynamoDB と Amazon RDS の両方をサポートしているため、要件を満たす場合は使用する必要があります。

# Amazon RDS のバックアップと復旧
<a name="rds"></a>

Amazon RDS には、データベースバックアップを自動化する機能が含まれています。Amazon RDS は、データベースインスタンスのストレージボリュームのスナップショットを作成し、個々のデータベースのみではなく、DB インスタンス全体をバックアップします。Amazon RDS を使用すると、自動バックアップ用のバックアップウィンドウを設定したり、データベースインスタンスのスナップショットを作成したり、リージョンやアカウント間でスナップショットを共有したりコピーしたりできます。

Amazon RDS には、DB インスタンスのバックアップと復元に 2 つの異なるオプションがあります。
+ **自動バックアップ**は、DB インスタンスのポイントインタイムリカバリ (PITR) を提供します。自動バックアップは、新しい DB インスタンスを作成するとデフォルトでオンになっています。

  Amazon RDS は、DB インスタンスの作成時に定義したバックアップウィンドウ中に、データのバックアップを毎日実行します。自動バックアップの保存期間は最大 35 日まで設定できます。Amazon RDS はまた、DB インスタンスのトランザクションログを 5 分ごとに Amazon S3 にアップロードします。Amazon RDS は、毎日のバックアップとデータベーストランザクションログを使用して DB インスタンスを復元します。`LatestRestorableTime` (通常、最後の 5 分) までの保持期間中であれば、インスタンスを任意の秒にリストアできます。

  DB インスタンスの復元可能な最新の時刻を確認するには、`DescribeDBInstances` API 呼び出しを使用します。または、Amazon RDS コンソールの **[説明] **タブでデータベースを確認してください。

  PITR を開始すると、トランザクションログと最も適切な日次バックアップが組み合わされ、DB インスタンスが要求された時刻に復元されます。
+ **DB スナップショット**はユーザーが開始するバックアップであり、DB インスタンスを必要な頻度で既知の状態に復元するために使用できます。その後、いつでもその状態に復元できます。DB スナップショットを作成するには、Amazon RDS コンソールか `CreateDBSnapshot` API コールを使用します。これらのスナップショットは、コンソールまたは `DeleteDBSnapshot` API 呼び出しを使用して明示的に削除するまで保持されます。

これらのバックアップオプションはどちらも AWS Backup、他の機能も提供する の Amazon RDS でサポートされています。 AWS Backup を使用して Amazon RDS データベースの標準バックアッププランを設定し、特定のデータベースのバックアッププランが一意である場合は、ユーザー主導のインスタンスバックアップオプションを使用することを検討してください。

Amazon RDS は DB インスタンスが使用する基盤となるストレージへの直接アクセスを防ぎます。これにより、RDS DB インスタンス上のデータベースをローカルディスクに直接エクスポートすることもできなくなります。場合によっては、クライアントユーティリティを使用してネイティブのバックアップおよび復元機能を使用できます。たとえば、[Amazon RDS MySQL データベースで mysqldump のコマンド実行 ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html)を使用して、データベースをローカルクライアントマシンにエクスポートできます。Amazon RDS には、データベースのネイティブバックアップと復元を実行するための拡張オプションも用意されている場合があります。例えば、Amazon RDS は[SQL Server データベースの RDS データベースバックアップをエクスポートインポート](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.html)するストアドプロシージャを提供しています。

バックアップと復元の全体的なアプローチの一環として、データベースの復元プロセスとそれがデータベースクライアントに与える影響を徹底的にテストします。

## DNS CNAME レコードを使用して、データベース復旧中のクライアントへの影響を軽減します。
<a name="dns-cname"></a>

PITR または RDS DB インスタンススナップショットを使用してデータベースを復元すると、新しいエンドポイントを持つ新しい DB インスタンスが作成されます。この方法では、特定の DB スナップショットまたは特定の時点から複数の DB インスタンスを作成できます。RDS DB インスタンスを復元してライブの RDS DB インスタンスを置き換える場合は、特別な考慮事項があります。たとえば、中断や変更を最小限に抑えながら、既存のデータベースクライアントを新しいインスタンスにリダイレクトする方法を決定する必要があります。また、リストアされたデータの時間と、新しいインスタンスが書き込みを受け始める際のリカバリ時間を考慮することで、データベース内のデータの継続性と一貫性を確保する必要があります。

DB インスタンスのエンドポイントを指す別の DNS CNAME レコードを作成し、クライアントにこの DNS 名を使用させることができます。そうすれば、データベースクライアントを更新しなくても、復元された新しいエンドポイントを指すように CNAME を更新できます。

CNAME レコードの TTL (Time to Live) を適切な値に設定します。指定する TTL によって、別のリクエストが行われるまでレコードが DNS リゾルバーにキャッシュされる時間が決まります。DNS リゾルバやアプリケーションの中には、TTL を守らず、TTL よりも長い間レコードをキャッシュするものがあるかもしれないことに注意することが重要です。Amazon Route 53 の場合、より長い値 (たとえば、172800 秒、または 2 日間) を指定すると、DNS 再帰リゾルバがこのレコードの最新情報を取得するために Route 53 に行わなければならない呼び出しの回数を減らすことができます。これによりレイテンシーが軽減され、Route 53 サービスの請求額が削減されます。詳細については、[「Amazon Route 53 によりドメインのトラフィックをルーティングする方法」](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-dns-service.html#welcome-dns-service-how-route-53-routes-traffic)を参照してください。

アプリケーションやクライアントオペレーティングシステムは DNS 情報をキャッシュする場合もあるため、新しい DNS 解決リクエストを開始して更新された CNAME レコードを取得するには、フラッシュまたは再起動する必要があります。

データベースの復元を開始し、復元したインスタンスにトラフィックを移すときは、すべてのクライアントが以前のインスタンスではなく、復元されたインスタンスに書き込んでいることを確認します。データアーキテクチャによっては、データベースの復元、DNS の更新、復元したインスタンスへのトラフィックの移行、前のインスタンスにまだ書き込まれているデータの修正がサポートされている場合があります。そうでない場合は、DNS CNAME レコードを更新する前に既存のインスタンスを停止できます。そうすれば、新しく復元したインスタンスからすべてのアクセスが可能になります。これにより、個別に処理できる一部のデータベースクライアントで接続の問題が一時的に発生することがあります。クライアントへの影響を軽減するために、メンテナンスの時間帯にデータベースを復元できます。

指数バックオフを使用して再試行してデータベース接続障害をスムーズに処理するアプリケーションを作成します。これにより、復元中にデータベース接続が使用できなくなった場合でも、アプリケーションが予期せずクラッシュすることなく、アプリケーションを回復できます。

復元プロセスが完了したら、以前のインスタンスを停止状態に保つことができます。または、セキュリティグループのルールを使用して、不要になったことを確認するまで前のインスタンスへのトラフィックを制限できます。段階的に廃止するアプローチでは、まず実行中のデータベースへのアクセスをセキュリティグループによって制限します。インスタンスが不要になった場合は、最終的に停止できます。最後に、データベースインスタンスのスナップショットを作成して削除します。

# DynamoDB のバックアップと復旧
<a name="dynamodb"></a>

DynamoDB には、DynamoDB のテーブルデータをほぼ継続的にバックアップする PITR が用意されています。有効にすると、明示的にオフにするまで、DynamoDB は過去 35 日間のテーブルの増分バックアップを維持します。

DynamoDB コンソール、、または DynamoDB API を使用して AWS CLI、DynamoDB テーブルのオンデマンドバックアップを作成することもできます。詳細については、[「DynamoDB テーブルをバックアップする」](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Backup.Tutorial.html)を参照してください。を使用して定期的または将来のバックアップをスケジュールすることも AWS Backup、Lambda 関数を使用してバックアップアプローチをカスタマイズおよび自動化することもできます。DynamoDB のバックアップに Lambda 関数を使う方法については、ブログ記事 [「Amazon DynamoDB のオンデマンドバックアップをスケジュールするサーバーレスソリューション」](https://aws.amazon.com/blogs/database/a-serverless-solution-to-schedule-your-amazon-dynamodb-on-demand-backup/)を参照してください。スケジューリングスクリプトとクリーンアップジョブを作成しない場合は、 AWS Backup を使用してバックアッププランを作成できます。バックアッププランには、DynamoDB テーブルのスケジュールと保持ポリシーが含まれます。 は、保持スケジュールに基づいてバックアップ AWS Backup を作成し、以前のバックアップを削除します。 には、低コストの階層型ストレージ、クロスアカウントおよびクロスリージョンコピーなど、DynamoDB サービスでは利用できない高度な DynamoDB バックアップオプション AWS Backup も含まれています。詳細については、[「高度な DynamoDB バックアップ」](https://docs.aws.amazon.com/aws-backup/latest/devguide/advanced-ddb-backup.html)を参照してください。

リストアした DynamoDB テーブルに対して、手動で以下の設定を行う必要があります:
+ 自動スケーリングポリシー
+ IAM ポリシー
+ Amazon CloudWatch メトリクスおよびアラーム
+ タグ
+ ストリーム設定
+ TTL 設定

バックアップから新しいテーブルにリストアできるのは、テーブルデータ全体のみです。復元されたテーブルに書き込むことができるのは、テーブルがアクティブになった後のみです。

復元プロセスでは、新しく復元されたテーブル名を使用するようにクライアントにどのように指示するかを考慮する必要があります。設定ファイル、 AWS Systems Manager パラメータストア値、またはクライアントが使用するテーブル名を反映するように動的に更新できる別のリファレンスから DynamoDB テーブル名を取得するようにアプリケーションとクライアントを設定できます。

復元プロセスの一環として、切り替えプロセスを慎重に検討する必要があります。IAM 権限を使用して既存の DynamoDB テーブルへのアクセスを拒否し、新しいテーブルへのアクセスを許可することもできます。その後、新しいテーブルを使用するようにアプリケーションとクライアントの設定を更新できます。また、既存の DynamoDB テーブルと新しく復元した DynamoDB テーブルとの違いを調整する必要がある場合もあります。