オウルです。
唐突ですが、皆さんはバックアップしっかりとっていますか？
個人のバックアップデータとしては主に次のような種類があると思います。
- 写真
- ドキュメント
これらのバックアップ先はパソコンではなく、クラウドサービスを利用されている方が多いのではないかと思います。もしかしたらクラウドサービスと知らず利用している方もいらっしゃるかもしれません。
-
- Googleドライブ
- Googleフォト
↑ は有名なクラウドサービスですよね。
では、なぜバックアップをとっているのでしょうか。
例えばスマホが壊れた場合、スマホを無くした場合にバックアップをとっていないと大事な写真がもう２度見れない、なんてことになるかもしれません。そんなことにならないようにクラウドサービスのバックアップを利用されていると思います。つまり、予期せぬ出来事に備えてバックアップをしているのです。
では前回紹介したクラウドサービスの仮想マシンのバックアップはどうでしょうか。Azureの仮想マシンのバックアップサービスを例に油断すると、ついつい見落としてしまうことを紹介したいと思います。因みに僕は油断してました。というか、妻のレオによく言われますが詰めが甘い・・・でしょうね、きっと。。。
サービス回復性側面について
主に２つの観点があります。
- 大幅なダウンタイムなしに、正常な状態で実行を継続するアプリケーションの能力（高可用性）
- 一時的なものではない大規模な障害から回復する能力（ディザスター リカバリー）
上記を踏まえてAzureのバックアップサービスをみてみましょう。
バックアップ対象はAzure VMのシングルサーバ（仮想マシンが１つ）として、以降お話します。
Ａzure Backup
Recovery Service コンテナーを利用してAzure IaaS VM（仮想マシン） のバックアップが可能です。このバックアップに使用するストレージ種類の既定はgeo冗長ストレージ (GRS)で構成されています。
geo冗長ストレージ（GRS）
プライマリ リージョン内に3 重レプリケート
セカンダリ リージョンに非同期で3 重レプリケート
※日本リージョンでは東・西のリージョンペアとなります。
※バックアップ対象のAzure VM があるリージョンがプライマリになります。
なぜバックアップをとるのか
基本的に予期せぬ出来事に備えてバックアップします。直前で説明したAzure Backの機能を見る限り、地理的に離れたリージョン（データセンター）にレプリケートしているためバックアップの役割は十分果たせていると思います。では、予期せぬ出来事の具体例を挙げてみたいと思います。
- リリースが上手くいかずロールバックする必要がある場合
- 何かしらの原因によりデータがクラッシュした場合
- リソース（Azure VM）利用の継続が不可能な災害（地震など）が発生した場合
- サービス提供側（パブリッククラウド）に問題が発生してリソース（Azure VM）利用の継続が不可能な場合
実は３、４の場合、バックアップをとっているにも関わらず問題が発生する可能性があります。
注意
前提として東日本リージョンをプライマリとして設定、東日本で災害等が発生したとします。
東日本で災害が発生してAzure VMの利用が不可能なため、西日本で環境を復元してAzure VMの利用を再開したいと思いますよね。なぜならバックアップはセカンダリ リージョンにもレプリケートしているからです。しかし、ここで問題が発生します。確かにセカンダリ リージョンの西日本にレプリケートはしていますが、読み取りができないのです。
セカンダリが読み取り可能となる条件
Azure データセンター側で復旧ができないと判断したタイミングで地理的フェールオーバーが発動しセカンダリ拠点が新しいプライマリ拠点として設定され、西日本リージョンにてバックアップデータからAzure VMを復元することが可能となります。
つまり、トリガーはユーザではなく、Azure データセンター側となるのです。
ディザスター リカバリー
でば、どのような対策方法があるのでしょうか。
Azure Site Recoveryの利用
地理的フェールオーバー発動のトリガーがユーザになります。
※Azure Site Recoveryの詳細については、また別の機会に紹介したいと思います。
いかがでしたか？バックアップに使用するストレージ種類の既定であるGeo冗長ストレージ (GRS)をみると一見十分な機能と思ってしまいますが、実はこのような事態になる可能性があるのです。つまりバックアップはとっているが、そのバックアップはどの程度の出来事に対して効果・対処できるのか、そのサービスをよく把握していないと、いざという時に困ったことになってしまいます。
また、ミッションクリティカルなダウンタイムが許容されないSaaSサービスの場合は、バックアップよりもシステム要件を満たす高可用性アーキテクチャ（クラスター、オーケストレーション、冗長化ストレージなどなど）が重要になってくると思います。バックアップだけではバックアップ⇒システムダウン直前までのトランザクションまでは保証できないですからね。
補足
geo 冗長ストレージ (RA-GRS)
RA-GRS は、2 つのリージョンにまたがる geo レプリケーションだけでなく、セカンダリ ロケーションにあるデータに対する読み取り専用アクセスを提供します。残念ながらAzure VMのバックアップストレージとしては利用できませんが、このような性能のストレージもあります。
▼ Azure定番システム設計・実装・運用ガイド
パブリッククラウドは色々なことができるため（マイクロサービス アーキテクチャ）、知識の整理が難しいというのが僕の悩みです。しかも公式リファレンスは、どうも翻訳が・・・。と思っていた時に、何気に見ていたAzure サポートブログで紹介されていました。著者が全員、現役のマイクロソフトのAzureテクニカルサポートのエンジニアです。
