Terraformを利用したEFSのフェイルオーバー/フェイルバックについて

はじめに

EFSでフェイルバックが実装されてから約1年経ちましたが、
Terraformでの切り替え手順を示している事例が見当たらなかったので記事にしました。

• Amazon EFS でのレプリケーションフェイルバックの導入と IOPS の増加

切り替え時間なども含めて全体の流れを確認しているので、EFSのレプリケーションを検討している方の参考になればと思います。

本記事の内容は以下リポジトリで気軽に試せるので、よければご利用ください。

• multi-region-efs

EFS フェイルオーバー/フェイルバックの流れ

まず全体の流れについて説明します。
前提として以下のような構成のシステムを想定します。

• Region A がプライマリー、Region B がセカンダリー
• EFSのレプリケーション設定を作成済み
• 各リージョンのEC2でEFSをマウント済みで利用できる状態

➀フェイルオーバー

フェイルオーバーは非常に簡単で、既存のレプリケーション設定を削除するだけで完了します。
ここでは何らかの障害で Region A のEC2、またはEFSが利用不可になったと想定します。

(1).レプリケーション設定削除

Region A → Region B のレプリケーション設定を削除します。

(2).EFSが利用できることを確認

レプリケーション設定の削除が完了した段階で Region B のEFSが書き込み可能となるので、
EC2から利用可能なことを確認します。

➁フェイルバック

フェイルオーバーと同様でレプリケーション設定の作成/削除の繰り返しとなります。

(1).レプリケーション設定作成

Region A のリソースが復旧したら、Region B → Region A のレプリケーション設定を作成します。

(2).レプリケーション状態確認

次にレプリケーションの状態をメトリクスなどから確認します。
レプリケーションの同期履歴は以下で確認できます。

• 最終同期 (EFSの詳細タブから確認)
  

• TimeSinceLastSync (Cloud Watch Metricsにて確認)
  

なおこれは「レプリケーションの最終同期タイミング」を表しており、実際にレプリケーションが発生しているかではありません。
厳密にEFSが利用されていないか確認したい場合は、実際にEFSを参照する、
またはメトリクスにてDataReadIOBytes、DataWriteIOBytesを参照するのが確実です。

• EFS の CloudWatch Amazon メトリクス

(3).レプリケーション設定削除

レプリケーションの状況を見て、データの読み込み/書き込みなど更新が発生していないことを確認できたら、
Region B → Region A のレプリケーション設定を削除します。

(4).EFSが利用できることを確認

レプリケーション設定の削除が完了した段階で Region A のEFSが書き込み可能となるので、
EC2から利用可能なことを確認します。

(5).レプリケーション設定作成

最後にRegion A → Region B のレプリケーション設定を作成します。

Terraformでのやり方

Terraformの場合もやることは同様であり、
aws_efs_replication_configurationがレプリケーション設定に該当するリソースなので、こちらを作成/削除します。

• aws_efs_replication_configuration

今回は例として、冒頭でも紹介した以下リポジトリを利用します。

• multi-region-efs

➀フェイルオーバー

(1).レプリケーション設定削除

該当の箇所をコメントアウトしてterraform applyし、
Region A → Region B のレプリケーション設定を削除します。
筆者の環境では削除完了まで8分程度かかりました。

examples/main.tf

# module "efs_replication" {
#   source = "../modules/efs_replication"
# 
#   source_file_system_id = module.efs.efs.id
#   replication_file_system_id = module.efs_secondary.efs.id
#   replication_region = local.secondary_region
# }

(2).EFSが利用できることを確認

こちらと同様

➁フェイルバック

(1).レプリケーション設定作成

該当の箇所をアンコメントしてterraform applyし、
Region B → Region A のレプリケーション設定を作成します。
筆者の環境では作成完了まで15分程度かかりました。

examples/main.tf

module "efs_replication_secondary" {
  source = "../modules/efs_replication"

  providers       = { aws = aws.replica }
  source_file_system_id = module.efs_secondary.efs.id
  replication_file_system_id = module.efs.efs.id
  replication_region = local.primary_region
}

(2).レプリケーション状態確認

こちらと同様

(3).レプリケーション設定削除

該当の箇所をコメントアウトしてterraform applyし、
Region B → Region A のレプリケーション設定を削除します。
筆者の環境では削除完了まで8分程度かかりました。

examples/main.tf

# module "efs_replication_secondary" {
#   source = "../modules/efs_replication"
# 
#   providers       = { aws = aws.replica }
#   source_file_system_id = module.efs_secondary.efs.id
#   replication_file_system_id = module.efs.efs.id
#   replication_region = local.primary_region
# }

(4).EFSが利用できることを確認

こちらと同様

(5).レプリケーション設定作成

該当の箇所をアンコメントしてterraform applyし、
Region A → Region B のレプリケーション設定を作成します。
筆者の環境では作成完了まで15分程度かかりました。

examples/main.tf

module "efs_replication" {
  source = "../modules/efs_replication"

  source_file_system_id = module.efs.efs.id
  replication_file_system_id = module.efs_secondary.efs.id
  replication_region = local.secondary_region
}

まとめと所感

• 切替そのものはめちゃシンプルで手間が少ないのはうれしいポイント
• とはいえ切替完了までにちょっと時間がかかるので、余裕をもった計画が必要
• RTO 15分以下、SLA 99.5%みたいな超タイトな要件だと、正直厳しめかも…
• レプリケーションの進捗をダイレクトに見られるメトリクスがないのは、ちょっとモヤッとする

総じて便利で手軽ではありますが、即時性や管理面で細かい不満は残る感じでしょうか。
実運用で導入するなら手順の検証やダウンタイム計画、メトリクス監視などの工夫はしっかりやっておいた方が安心だと思います。