はじめに

日商エレクトロニクスのAzure担当エンジニア 渡邊です。

年度末が近づき、より一層忙しくなっているところに酷い寒暖差や花粉症の追撃が来る時期になってきました。皆様、体調など崩されないようにしっかり対策してください。

さて、今回は2月プレビューとなったAzure Storageのフェールオーバー機能の紹介を行います。この機能により災害が起きた際の対策がより具体的にできるようになると思います。

※ここで紹介している内容は2019年2月時点のものです。Azureは常に変化しますので常に最新の情報を参照してください。

1.Azure Storage

Azure StorageはAzure上で利用可能なStorageサービスです。Azure仮想マシンにアタッチ可能なBLOBストレージ、過去記事で紹介しているAzure File Syncで使用するAzure Filesなどの様々な用途で使われています。

1.1 Azure Storageで利用可能な冗長構成

通常、このAzure Storage内に保存されたデータはデータセンター内で3重で保存されます(ローカル冗長ストレージ:LRS)。これにより物理的な障害である、ラック障害やノード障害が発生した場合でも、可用性を高く保つことが可能となっています。しかし、データセンター規模の障害が発生した場合にはLRSではAzure Storageを使用するユーザーのサービス継続ができず、データが損失する可能性もあります。そのため、Azure Storageではデータセンター規模の障害が発生した場合でもデータ損失を防ぐために地理的冗長ストレージ(GRS)、ユーザーのサービスを継続させるために読み取りアクセス地理冗長ストレージ(RA-GRS)という冗長構成が用意されています。

GRSはデータセンター内で3重化され保存されているデータを別のペアとなるリージョンでも3重化して保存するため、計6重化されて保持します。リージョン間のデータコピーは非同期で実行されます。

GRSでコピーされたデータは通常読み取り書き込みなどの利用ができません。プライマリのリージョンが利用できなくなった際にMicrosoftの判断により、ペアであるセカンダリのリージョンへMicrosoftの判断によりフェールオーバーされます。しかし、Microsoftの方針として第一にプライマリリージョンの復旧を考えます。そして、検討の後にセカンダリリージョンへのフェールオーバーの実行が検討されるため、いつフェールオーバーが実行されるのかがわからず、災害時の復旧計画が立てにくくなっています。このことから、Microsoftではセカンダリリージョンでコピーされたデータの読み取りが可能なRA-GRSを提供しています。これにより、セカンダリリージョンでデータの読み取りは可能であるため、サービスの機能を制限して継続させることが可能です。しかし、これもフェールオーバーされない限り書き込みができないため、いつサービスの機能を復旧させることができるのか、という目途を立てるのが難しいです。

1.2 ユーザー判断によるフェールオーバー

今回プレビューとなったのが、このMicrosoftの判断によるフェールオーバーをユーザーの判断により行えるという機能です。これにより、ユーザー側でフェールオーバーの判断を行い実行することで、サービスを復旧させることが可能かという目途をつけることが可能となると考えられます。

1.2.1 フェールオーバーのプロセス

フェールオーバー機能を行うためにはAzure Storageの冗長性としてGRS、RA-GRSを使用することが前提となります。

例として、図のようにAzureユーザーがAzure Storageを使用するサービスを提供しているというシナリオでプロセスを見ていきます。

※例として[東日本リージョン]、[西日本リージョン]としていますが、現在[米国西部2リージョン]、[米国中西部リージョン]でのみプレビューが提供されています。

通常はプライマリリージョンである東日本リージョンのAzure Storageを使用してサービスを提供します。Azure StorageはGRSを利用してペアリージョンの西日本リージョンへ非同期コピーをとっています。

障害により東日本リージョンが使用不能となった場合、AzureユーザーとサービスはAzure Storageに保存や読み書きができなくなります。そのため、サービスは停止します。

※RA-GRSであればこの場合でも読み取りのみで可能なサービスは継続できます。

この状態になった場合、以前であればMicrosoftの判断を待つことになりましたが、ユーザーの判断によりフェールオーバーが実行できるため、フェールオーバーを開始します。通常１時間程度かかるようです。フェールオーバーを行うとAzure StorageのDNSエントリが更新され、セカンダリリージョンのAzure Storageがプライマリストレージに変更されます。これにより、読み書きが可能となり、サービスの提供が可能です。

1.2.2 注意点

フェールオーバー前に注意すべき点として、セカンダリリージョンの最後に同期された時刻を確認しておく必要があります。GRS、RA-GRSは共に非同期によるコピーのため、セカンダリリージョンに同期される前にプライマリリージョンで書き込まれたデータは障害が起きた場合、失われてしまいます。そのため、最後に同期された時刻を必ず確認し、その時刻以降に更新された内容がないか確認を行う必要があります。

また、フェールオーバー後の動作として新しいプライマリリージョン(例の[西日本リージョン])でのAzure Storageの冗長構成はLRSとなります。ペアリージョンが復旧し、再度GRSに設定することで、非同期コピーが行われます。最終同期時刻を確認し、全てのデータが同期されたことを確認後、再度フェールオーバーを行うことでフェールバックを行うことができます。フェールバックを行うと、プライマリリージョン(例の[東日本リージョン])でAzure StorageはLRSで構成されるため、元のセカンダリリージョン(例の[西日本リージョン])のデータは全て失われます。

強制的にフェールオーバーを行う場合には、必ずペアリージョンにあるAzure Storageの最終同期時刻を確認してから実行するようにする必要があります。

2.まとめ

今回プレビューとなった、ユーザーの判断によるフェールオーバーにより、災害時の不確定要素を減らすことができると考えられます。今後、Web Appのようにクラウドでサービスを展開し、データの保存先としてAzure Storageを使用するという運用が増えていくことも考えられます。その際に、どの程度のサービスレベルを提供できるかに影響を与えてくるため、サービス停止に関係するアップデートは都度確認が必要となります。現段階ではプレビューが始まったところであるため、今後仕様が変更になる可能性があります。日本でGAされた際には必ず仕様の確認を忘れないでください。

この記事を書いた人

渡邊真悟
渡邊真悟
オンプレエンジニアとして活動するはずが、弊社Azure立ち上げを担い、気が付いたらクラウドエンジニアとなっていました。
新しいことに取り組むのが苦手だった自分を変え、常に最新の情報を取り入れられるように日々奮闘しています。
Azure Virtual DesktopやAzure Filesなど、IaaS/PaaS領域の機能検証や、Microsoft 365などのSaaS範囲まで組み合わせた情報をお伝えしていきます。
こんな検証ができないか、等ありましたら是非ご連絡ください！