Amazon Web Services ブログ

新規 – Amazon Data Lifecycle Manager とカスタムスクリプトを使用して、アプリケーション整合性があるスナップショットを作成する

Amazon Data Lifecycle Manager は、AWS Systems Manager ドキュメントに埋め込まれたスナップショット前のスクリプトとスナップショット後のスクリプトの使用をサポートするようになりました。これらのスクリプトを使用して、Data Lifecycle Manager によって作成された Amazon Elastic Block Store (Amazon EBS) スナップショットにアプリケーション整合性があることを確認できます。スクリプトは、I/O 操作の一時停止と再開、バッファリングされたデータの EBS ボリュームへのフラッシュなどを行えます。このリリースの一環として、セルフマネージドリレーショナルデータベースと Windows Volume Shadow Copy Service (VSS) でこの機能の使用方法を示す詳細なブログ記事も公開します。

Data Lifecycle Manager (DLM) のまとめ
簡単にまとめると、Data Lifecycle Manager は、Amazon EBS ボリュームスナップショットの作成、保持、削除を自動化するのに役立ちます。EC2 インスタンスを AWS Systems Manager にオンボーディングする、DLM 用の IAM ロールをセットアップする、SSM ドキュメントにタグを付けるなどの前提条件となるステップを完了したら、ライフサイクルポリシーを作成し、該当する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを (タグで) 示し、保持モデルを設定して、残りは DLM に任せるだけです。ポリシーでは、スナップショットをいつ実行するか、何をバックアップするか、どれだけの期間スナップショットを保持するかを指定します。DLM の詳細な説明については、2018 年のブログ記事「新規 – Amazon EBS スナップショットのライフサイクル管理」をご覧ください。

アプリケーション整合性があるスナップショット
EBS スナップショットは Crash-consistent です。つまり、スナップショットが作成された時点の関連付けられた EBS ボリュームの状態を表しています。アクティブなリレーショナルデータベースの状態をキャプチャするためにスナップショットを使用しないアプリケーションを含め、多くの種類のアプリケーションにはこれで十分です。アプリケーション整合性があるスナップショットを作成するには、保留中のトランザクション (処理が完了するのを待っている、またはトランザクションが失敗するのいずれか) を考慮し、それ以降の書き込み操作を一時的に停止し、スナップショットを作成して、通常の操作を再開する必要があります。

そして、それが今日のリリースが行われる場所です。DLM は、アプリケーション整合性があるバックアップの準備をするようインスタンスに指示できるようになりました。スナップショット前のスクリプトは、保留中のトランザクションを管理したり、メモリ内のデータを永続ストレージにフラッシュしたり、ファイルシステムをフリーズさせたり、アプリケーションやデータベースを停止させたりすることができます。その後、スナップショット後のスクリプトによって、アプリケーションやデータベースを元の状態に戻したり、永続ストレージからメモリ内キャッシュをリロードしたり、ファイルシステムを解凍したりすることができます。

カスタムスクリプトの基本レベルのサポートに加えて、この機能を使用して VSS Backup スナップショットの作成を自動化することもできます。

前および後のスクリプト
新しいスクリプトはインスタンスの DLM ポリシーに適用されます。スナップショット前のスクリプトとスナップショット後のスクリプトを含む SSM ドキュメントを参照するポリシーを作成し、それが単一のインスタンスに適用されると仮定します。ポリシーをスケジュールに従って実行すると、次のようになります。

  1. スナップショット後のスクリプトは SSM ドキュメントから起動されます。
  2. スクリプト内の各コマンドが実行され、スクリプトレベルのステータス (成功または失敗) がキャプチャされます。ポリシーで有効になっている場合、DLM は失敗したスクリプトを再試行します。
  3. マルチボリューム EBS スナップショットは、インスタンスにアタッチされた EBS ボリュームに対して開始され、ポリシーによってさらに制御されます。
  4. スナップショット後のスクリプトは SSM ドキュメントから起動されます。
  5. スクリプト内の各コマンドが実行され、スクリプトレベルのステータス (成功または失敗) がキャプチャされます。

ポリシーには、いずれかのスクリプトがタイムアウトまたは失敗したときに実行されるアクション (再試行、続行、またはスキップ) を制御できるオプションが含まれています。ステータスはログに記録され、Amazon CloudWatch メトリクスが公開され、Amazon EventBridge イベントが発行されます。また、ステータスは各スナップショットに自動的に割り当てられるタグにエンコードされます。

スナップショット前のスクリプトとスナップショット後のスクリプトは、コマンドドキュメントで許可されている任意のアクション (シェルスクリプトの実行、PowerShell スクリプトの実行など) を実行できます。アクションは、ポリシーで指定されたタイムアウト (10 秒から 120 秒の許容範囲) 内に完了する必要があります。

開始方法
堅牢なスクリプトペアを構築するには、アプリケーションまたはデータベースを詳細に理解する必要があります。すべてがうまくいったときに「ハッピーパス」を処理することに加えて、スクリプトはいくつかの障害シナリオに備えて計画を立てる必要があります。例えば、スナップショット前のスクリプトは、スナップショット後のスクリプトが期待どおりに動作しない場合に備えて、フェイルセーフとして機能するバックグラウンドタスクをフォークする必要があります。各スクリプトは、こちらで詳しく説明するように、シェルレベルのステータスコードを返す必要があります。

スクリプトを作成してテストし、SSM ドキュメントとしてパッケージ化したら、EC2 コンソールの Data Lifecycle Manager ページを開き、EBS スナップショットポリシーを選択して、[次のステップ] をクリックします。

本稼働のモードでタグ付けされたすべてのインスタンスをターゲットにし、デフォルトの IAM ロールを使用し (別のロールを使用する場合は、SSM へのアクセスを有効にする必要があります)、残りの値はそのままにして、次に進みます。

次のページで、[前および後のスクリプト] まで下にスクロールして、セクションを展開します。[前および後のスクリプトを有効にする] をクリックし、[カスタム SSM ドキュメント] を選択して、メニューから [自分の SSM ドキュメント] を選択します。また、タイムアウトと再試行のオプションも設定し、スクリプトの 1 つが失敗した場合は Crash-consistent バックアップをデフォルトに設定しています。[ポリシーをレビュー] をクリックし、最後の確認をして、次のページの [ポリシーを作成] をクリックします。

自分のポリシーが作成され、すぐに有効になります。少なくとも 1 回実行したら、CloudWatch メトリクスを調べて、開始、完了、失敗の有無を確認できます。

その他の参考資料
先ほどお約束した詳細なブログ投稿の最初の記事は次のとおりです。

今年後半に向けてさらに多くの作業を進めており、公開されたら上記のリストを更新します。

また、ドキュメントを読んで詳細を確認することもできます。

DLM ビデオ
この機会に、有用なビデオをいくつかご紹介します。

新しい機能がすでに利用でき、今日からすぐに使用を開始できます。

– Jeff;

原文はこちらです。