2021.09.10 合同勉強会

1. パブリッククラウドで
DR（災害復旧）に取り組んでみる話
ナイル株式会社 小宮良之

2. 自己紹介
小宮良之 （2017年入社）
ナイル株式会社 メディアテクノロジー事業本部 インフラ責任者
履歴：ガソリンスタンドのメカニックを6年、インフラエンジニアを20年
趣味：ラーメン食べ歩き（メインは横浜家系）
目標：年内にAWS認定SAPに合格！（いま模試で正答率約72%、あと少し！）

3. ナイルのシステム：ざつにいんふら紹介
● Webサービスは100%パブリッククラウド！！
● AWS、GCP(BigQueryのみ)
● 社内LANもオール無線！

4. ナイルのシステム：ちゃんと紹介（インフラ系）
AWSのサービス
EC2・ALB・AutoScaling・ECS
CloudFormation・CodePipeline・
CodeDeploy
S3・Aurora RDS・ElastiCache
SNS・SES・CloudSearch
CloudWatch・CloudWatch Event
CloudWatch Logs・Athena・RedShift
ほか、いろいろ
AWS外のサービス
Akamai Download Delivery
GitHub・CircleCI・DockerHub
GCP BigQuery
PagerDuty・Sentry・BlackDog
ほか、いろいろ

5. （AWS大阪リージョンが開設されたほか、色々な機能が整ってきた感があるので）
パブリッククラウドで
DR（災害復旧）に取り組んでみる話
今日のお題

6. DRとは？
DR ＝ Disaster Recovery（ディザスタリカバリ） ＝ 『災害復旧』
『地震や津波などの天災や、テロ、不正侵入などによりシステムが壊滅的な状況
になった際に復旧・修復すること、また、その災害に備えたシステムや体制』の
こと。
参考：DR/ディザスタリカバリ（IDCフロンティア）
https://www.idcf.jp/words/dr.html

7. なぜやるのか？
システムがダウンすると…
・機会損失、そして売上ダウン
・復旧がもたつくと、時間とともにサービスの
信頼性もダウン
・SEOで頑張ってるのに、サイトが落ちてたら
全て台無しに！

8. ちゃんと備えましょう！
実際のところ、今クラウド基盤が障害に陥ると、
・・・なのですが、そこで終わりではなく、
『クラウドならではの災害対策』を
平時のうちにしっかり進めておきましょう！
俺たちには何もできない
（ ＾ω＾）・・・

9. きっかけ
DRを考え始めたのは、2019年08月のAWS東京リージョン障害がきっかけ。
災害ではなく『冷却設備の故障』が原因と発表されたが、『事業継続性』の文脈
から、DR案を考えてみることにした。
※ちなみにこの時の障害では、ALBのマルチAZが機能せず
片側のALBのダウンにより50％の縮退が発生した程度で済んだ。
（完全なサービスダウンは免れたものの、時折500エラーを返す状態が1時間ほど続いた）。

10. もともとDRってこんな感じだった
稼働中のシステムを（規模を縮小したとしても）もう一つ作ることになるので、
クラウドの代わりにオンプレでやろうとしても…
● それなりに設備投資がかかる！
普段は使わないものなので、予算の獲得が大変…
● 設計と構築に時間も工数もかかる！
あと運用にも人手がいる。
● 遠方に作るので移動コストがかかる！
普段は都内のデータセンターを使い、DR環境には
西日本や北海道のデータセンターを借りる、など

11. で、どうする？
こういった背景を踏まえ
『短納期・イニシャルゼロでDRやるなら、やはりクラウドは外せない』
『会社として完全パブリッククラウド！という方針が掲げられている』
という前提で、このとき考えた障害・災害対策は…
● マルチクラウド（AWS+GCP、またはAWS+Azure）
● マルチリージョン（AWSで複数リージョン構成）
このうち、リソースの使いまわしがしやすいマルチリージョンで検討することに。

12. マルチリージョンのイメージ（2019年当時）
一番手っ取り早そうなのが、AWS東京＋海外リージョンの組み合わせ。
東京から近いところだとソウル、香港、シンガポールあたり。
（注：2019年時点では大阪リージョンはバックアップ専用だった）
この時点では『東京を軸にDRをやるならソウル』と方針を固めつつあった。

13. で、いまどんな感じ？
仕事の合間に案を考えているうちに2020年、コロナ禍に！
やることが増えたので、DRネタは一時中断。
そして今年に入り、今年3月にAWS大阪リージョンが
正規のリージョンに代わって運営開始＼( 'ω')／
国内リージョンだったら尚良し！

14. なぜ、今やるのか？１
もともとクラウドはDRとは相性が良い側面もあるので、
『なぜいまさらDR？』感のあるネタではありますが、
その理由は…
マルチAZは強力である一方、リージョンを跨ぐと
『かゆいところに手が"届かなかった"』。

15. なぜ、今やるのか？２
たとえばRDSだと…
『リージョン間でのレプリケーションが出来なかった』
そのため、DRのため、きちんとHAを機能させるには
● 『RDSをやめてEC2でDBを構築し、DR側にレプリカを置く』
● 『PacemakerやCorosyncでHA構成を組んでコントロールする』
など、クラウドなのにオンプレと同じ
アーキテクチャにするしかなかった
（因みにAzureはリージョン間でHAを組めたけど
AWSとGCPは未実装だった）

16. なぜ、今やるのか？３
2021年の3月に大阪リージョンリリースに並行
し、この半年間でDR向けの機能が急拡充。
とりわけRDS（Aurora含む）の
リージョン間同期が実装。
ここへきてようやく
DRの規模をマルチAZから
マルチリージョンへ拡張できる！

17. ということで、AＷＳの機能を活用した、
クラウドＤＲのプランを考えてみました

18. DRの構成イメージ１
● リージョン単位でのHA構成。正系は東京、副系は大阪
● ふだんのバックアップを東京と大阪にそれぞれ作成
● RDSやS3などデータ同期が必要なサービスはホットスタンバイ。
● それ以外はお金がかかるので普段はコールドスタンバイで。
東京は正系
（普段はこちら）
大阪は副系
（もしもの時に！）

19. DRの構成イメージ
実際に災害が起きてしまい、副系の出番がやってきたときは…
● RDS、S3の各レプリカをマスタ昇格
● ALB、EC2、ElastiCacheなどをCloudFormationで次々と起動
● Route53でルーティングを最適化してサービス再開
（実際にはテストとかもやっておきたい）

20. DRの構成イメージ１：リソースの同期
RDS/Aurora：クロスリージョンレプリカを使う
暗号化に対応するようになった！トランザクションログも送ってくれるようになった！
今年の7月から大阪→東京も同期され、双方向でレプリケート出来る様に！
（なのでフェイルバックも可能になった）
S3：バケットのレプリケーション機能を活用
地味にこれが重要だったりする。

21. DRの構成イメージ２：VPCなど基盤は先に作ってもOK
AWSの環境基盤となるVPCなどはCloudFormationでも構築できるが、維持コス
トの安いサービスは平時に予め作っておいてもＯＫ。
（その分復旧時間を多少は短縮できる）
・VPC、サブネット、NAT、セキュリティグループ、ほかいろいろ
・ビルド/デプロイ環境（Code4兄弟とかECR、ECSなどコンテナ系とか）

22. DRの構成イメージ3：コードインフラでスパっと切り替え
実際の復旧作業（復元作業）はもちろんCloudFormation（以下CFn）で。
● バックアップしたAMIの復元や、DR先のRDSリードレプリカ、S3などを
CFnで自動でマスターに昇格
● エッジの部分もCFnでインターネットのエッジ部分の切り替えを自動で実行
できるよう、ルーティングをしておく。
○ Route53
○ CloudFront
○ API Gateway
（可能なら予めエッジ最適化にする）
○ ほか、いろいろ

23. 計画し始めたばかりなので、課題と懸念もあります
● マルチAZと比べて、マルチリージョンの場合はレイテンシが気になる
（おもにRDSのトランザクションの部分）
● 予行演習をちゃんとやっておきたい。
○ 自動化を進めていても、正常に動作するかは別の話。ちゃんと動くことを確認する。
防災訓練と同じ。
● 他社サービスもダウンする可能性
○ GitHubやCircleCI、Slackなどのサービスも大規模災害によって共倒れする可能性も頭に入れ
てリカバリーのシナリオを作っていくこと。

24. まとめ
RDSやS3など個別のサービスでもクロスリージョンでのデータ同期の機能がどん
どん提供され、マルチリージョンでのDR環境が整ってきた！
ということで着々と整備と検証を進めて、課題を明らかにしていきます！
そして来年度の予算で費用をしっかりもらいに行きます！！（重要）

25. ご清聴ありがとうございましたm(__)m