備えあれば憂いなし。DR 対策としてのクロスリージョンバックアップを自動化
kazu です。お久しぶりです。
このところ、実務をお任せいただくことも
多くなりブログ執筆活動が滞りがちとなっておりますが、
今回はそんな実務からお送りします。
DR とは
まず、タイトルにある「DR」について。
「Disaster Recovery（ディザスタリカバリ）」の略で
平たく訳せば災害復旧という意味です。
すなわち災害発生時にどのように復旧するか、
またそれに備えてとるべき対策全般を指します。
今回は具体例として遠隔地への
データバックアップについて AWS にからめて書いてみます。
クロスリージョンバックアップ
AWS 上のサービスでこれを考えると、
例えば、通常東京リージョンで
使っているリソースのバックアップを
大阪リージョンにおいておく、
ということになるかと思います。
これをクロスリージョンバックアップと呼んだりします。
以下、最悪の例えですが、
東京リージョンのデータセンターが
何らかの理由で全滅となったとき、
大阪リージョンにて保管したバックアップを
利用して素早くリソースを立ち上げる
ことが可能になる、という寸法です。
自動化するには？
今回は「クロスリージョンバックアップを自動で」
という要件を想定しています。
実現する方法を EC2、RDS、S3 で調べてみました。
EC2 の場合
EC2 の自動クロスリージョンバックアップについては
以前このブログでも取り上げた
DLM（Data Lificycle Manager）を使います。
バックアップ（スナップショット作成）時に
他リージョンへのコピーを作成するという設定に
することで実現可能です。
EC2 のナビゲーションメニュー「ライフサイクルマネージャー」で
この画面で EBS スナップショットポリシーを選択、
「次のステップへ」をクリック。
ターゲットリソースは対象の EC2 を選択して「追加」。
「追加」するとこんな表示に。
「説明」に適宜入力してあとはデフォルトで。
この辺もデフォルトで「次へ」をクリック。
ここでスケジュール、保持タイプなどを決定します。
ここ重要！
「クロスリージョンコピーを有効にする」にチェックを入れます。
そうするとどのリージョンにコピーするか
暗号化等々の表示が現れますので適宜
選択、入力します（今回は大阪リージョンにコピー）。
一番下の「ポリシーを確認」をクリック。
内容を確認して作成すれば（画面省略）。
ライフサイクルポリシーの作成が完了、
決められたスケジュールで自動的に
クロスリージョンコピーが作成されます。
RDS の場合
データベースエンジンによって機能差がありますので
具体例を 2 つ挙げて解説します。
RDS には自動バックアップの際に別リージョンへの
コピーを作成する機能があります。
ただし、現時点で対応しているエンジンは、
RDS Oracle、RDS for PostgreSQL、RDS for SQL Server
のみとなっており、今回使用を想定している RDS for MySQL では
残念ながら未対応。Aurora も未対応ですね。
※ 類似として Aurora にはクロスリージョンリードレプリカを
作成する機能があります。
RDS for PostgreSQL
まずはクロスリージョン自動バックアップに
対応しているこちらから。
対象とするデータベースを選択して「変更」をクリック。
変更画面の「追加設定」の下の方、
「別の AWS リージョンでレプリケーションを有効化」に
チェックを入れ、
バックアップ送信先のリージョン、
保持期間を選択。最下部の「続行」をクリック。
変更内容を確認し、
「DB インスタンスを変更」を
クリックすれば有効となります。
RDS for Mysql
クロスリージョン自動バックアップ未対応の場合、
AWS Backup を使ってこれを実現します。
大まかには、
バックアッププランを作成し、
これにリソースを割り当てる、
という流れになります。
以下で詳しく説明していきます。
AWS Backup 画面から「バックアッププランを作成」をクリック。
バックアップルール名を入力、バックアップ頻度を選択。
バックアップボールトは、
「バックアップを整理するためのコンテナ」との
公式説明がありますが、ここではデフォルトを
利用することにして省略します……
「コピー先にコピー」のところで、
リージョンを選択、下部の「プランを作成」をクリック。
次の画面でこのプランに割り当てるリソースを決定します。
「リソース割り当て名」を適宜入力し、IAM ロールを選択、
「リソースタイプ」は「RDS」を選択、
「データベース名」で当該データベースにチェック
（「すべてのデータベース」を選ぶこともできます）。
下部のリソースを割り当てるで設定完了です。
この画面で確認することができます。
S3
S3 ではレプリケーション機能により実現できます。
今回は検証環境に残っていた Cloudtrail のログを
レプリケーションしてみます。
まず、レプリケート先の S3 バケットを作成。
事前準備として大阪リージョンに
レプリケーションの受け皿となるバケットを
作成します。
レプリケーションを有効にするためには
バージョニングを有効にする必要があります。
諸々の設定を確認し、「バケットを作成」します。
2 つのバケットができました。
コピー元となるバケットを開き「管理」タブから
「レプリケーションルールを作成」をクリック。
ルール名を入力。
ソースバケット（コピー元）の諸々確認、
必要であれば修正。
送信先バケットは、
先ほど作成した大阪リージョンのバケットを選択。
既存のオブジェクトをレプリケートするかを確認。
通常、レプリケーションルールを設定する前の
オブジェクトについてはレプリケート対象外です。
ここで「はい、既存のオブジェクトをレプリケートします」を
選択するとコピー元、コピー先を完全に
同期することができます。
最後に「送信」をクリックで設定完了です。
コピー元バケットに変更が加えられると
15 分以内にコピー先バケットへレプリケートされます。
なお、日次、6 時間ごとなど決まったタイミングで
バックアップを行いたい場合は AWS Backup を利用することになります。
やりかたは先述の RDS の項で
バックアッププランに割り当てるリソースを
S3 とすれば OK です。
備えあれば憂いなし
IT システムの構築には、いざという時のための
備えも重要な要素となります。
実生活に例えると「保険」と言えるもので
実は軽視されがちな点ですが、
安定運用のためには、
こういうところにもしっかりと
コストを費やすことが重要ですね。
最短でAWSを習得したい方におすすめ！
オンラインスクール「とらくら」
当ブログを運営しているオンラインスクール「とらくら」では、AWSを実務で活用するために必要なAWSの主要サービスの知識を、理論だけでなく、環境構築をハンズオン形式で実践しながら学べるカリキュラムをご用意しております。
参考書だけではイメージがしにくい内容でも、「座学＋実践」で効率良くインプットが可能です！
まずはお気軽に無料説明会にご参加ください。
投稿者プロフィール
-
＜インフラエンジニア＞
■ 以前、運用・保守系業務に携わるもしばらく別畑の仕事に。約8年ぶりに復活。クラウドに関しては初心者。AWS エンジニア目指して奮闘中！
■ 趣味はスキー（インストラクター経験あり）、クルマ（特にスバル車）、ロードバイク、登山とブログ。
最新の投稿
AWS2024年10月3日最初の落とし穴。AWS WAF ですったもんだした話- AWS2022年12月5日備えあれば憂いなし。DR 対策としてのクロスリージョンバックアップを自動化
- AWS2022年10月24日コスト意識を大切に！ハンズオン後の後始末
AWS2022年9月29日AWS 初心者が RDS（データベース）を構築してみました！ Part.2 構築編
