はじめに

こんにちは！

お久しぶりです！
今回のテーマは「DRシステム」です！

最近寒くなりましたが、風邪に気をつけましょう！

DRシステムってなに？

Disaster Recovery

つまり、「災害復旧」ということです。

ここの災害というのは、天災や物理的な災害によってシステムが不能になった時復旧するためのシステムや体制となります。

DRシステムが必要な理由？

こんなシステムがなんで必要か？というと

• 私たちは24時間サービスがちゃんと動いてるのか確認するのはが不可能です。
• また、クラウドサービスも100%稼働を保証していません。
  

  AWSの場合、99.9% ~ 99.999%の可用性を提供しています。
  

引用元：https://docs.aws.amazon.com/ja_jp/whitepapers/latest/real-time-communication-on-aws/high-availability-and-scalability-on-aws.html

なので、私たちはDRシステムを構築することで、サービスをもっと安全に運用する必要があります。

では、もうちょっと具体的な概念をみましょうか？

RTO

• Recovery Time Object
• 目標復旧時間
• 修復を完了してシステムをオンラインに戻すまでの合計時間。
  

  RPO

• Recovery Point Object
• 目標復旧時点
• データを復旧できる時点。
  

  RTO / RPO - 短くほどコストが上がる

  

引用元：https://aws.amazon.com/jp/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/

例えば、毎時バックアップされるシステムがあります。
そして、11時にバックアップしました。その後、11時45分に災害が発生しました。
最後に、12時に復旧できました。

という流れを、上記の絵に導入すると

RPO - 11時、RTO - 12時となります。
その間、45分のデータの損失と15分の復旧時間がかかったといことになります。

RPOとRTOは短ければ短くほどコストがあがります。

引用元：https://aws.amazon.com/jp/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/

では、簡単なDRシステム戦略を三つ紹介します。

DRシステム戦略 - Backup and Restore

• RTO、RPOが時間単位の時使える戦略
• コストが低い、戦略が簡単
• データをバックアップして、復旧に使う
• 災害が発生したら、時間をかけて復旧する
  • 簡単にいうと、一般的なバックアップとなります。時間がかかっても復旧ができたらOKという戦略です。

  DRシステム戦略 - Active / Passive

• RTO、RPOの分単位の時使える戦略
• コストが高い、戦略が複雑
• resourceのActiveを保有する
  

  

引用元：https://cloud.google.com/compute/docs/disks/design-considerations-for-resilient-workloads-with-regional-persistent-disks#adding_a_regional_persistent_disk

• Activeを保有していますが、Passive状態のサーバーやDBを保有しています。
  ActiveのデータをPassiveの状態と同期させ、災害があった時PassiveをActiveに変える戦略です。
  その間、元のActiveサーバーを起動させたり、Passiveサーバーの調整などが可能ですね。

DRシステム戦略 - Active / Active

• RTO、RPOがreal-timeの時使える戦略
• コストがもっと高い、戦略がもっと複雑となりますが、一番標準
• クラウドサービスのお陰で、高可用性が簡単になった
  

  

引用元：https://aws.amazon.com/jp/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/

• 複数のサーバーを設定し、ユーザーとLBを配置します。ここで、二つのLBを設定します。
  もちろん、LBが壊れないようモニタリングが必要です。規模によって、その数はいつでも変わります。

最後に。。。

DRシステムに関して軽く説明してみましたが、いかがでしょうか？

まだ、「readonly replica」とか「sharding」等
もっと色んな方法があります！

自分のプロジェクトがちゃんとDRシステムが構築されているのか確認するのもいいと思います！

では、また次の記事で会いましょう！