サードウェア主催のDR×クラウドのイベントで登壇してきました

エンジニアの森(@mosuke5)です。
8月29日にサードウェアさん主催のセミナー「OSS+クラウドを活用し、重要業務システムをバックアップ ~『止められないシステム』『消えてはいけないデータ』をアクシデントから守る方法」に登壇してきましたので早速ご報告です。クラウドを利用したDRの考え方についてご紹介します。

セミナーについて

マジセミと呼ばれる、オープンソース活用研究所がプロデュースする勉強会で、今回「DR×クラウド」というテーマだったこともあり、クラウド環境でのDRの考え方についてスピーカーさせていただきました。講演の他、最後にディスカッションもあり、「参加者のために本当に『役に立つ』情報を提供する」というセミナーの趣旨を体現するような素晴らしいイベントでした。

OSS+SBクラウドを活用し、重要業務システムをバックアップ ~「止められないシステム」「消えてはいけないデータ」をアクシデントから守る方法

資料

当日のプレゼン資料はこちらです。本ブログでは、イベントで話すことのできなかった情報を追加してお届けします。

これだけはおさえよう

資料の中でも何度か書いていますが
「クラウド≠DR環境を作らなくていい」ではない点は再度お伝えします。

クラウドの特徴を活かした、DR環境を必要なときに作る方法をご紹介しましたが、すべてのケースにおいてあてはまるわけではありません。
クラウドを選択するということは、いままで実現することのできなかった使い方など、「選択の幅が広がる」ことが多いのがポイントです。

セミナーで語れなかった話

セミナーの中で話せなかった内容について3点追加します。

DR構築:スケールアップパターン

セミナーの中では、DR環境を必要になったときに構築する方法をお伝えしました。しかし、もうひとつクラウドの特徴を活かしたDR構築のパターンがあります。
それは、「DR環境を小さいスペックで作っておき、必要になったときにスケールアップする」というパターンです。
Alibaba Cloudでは必要に応じてサーバやストレージなどのリソースをスケールアップ、アウトすることが可能です。
DR環境が本当に必要になった際に、スケールアップ/アウトして利用することで、低価格でDR環境を運用することができます。

小さいスペックでもDR環境を作っておくことで、動作確認は常にできるようになります。突然にシステムを動かすと、うまく動作するかなど不安がありますよね。
小さいスペックでDR環境を作っておいて、定期的に動作確認できるようにすることで、こういったリスクを抑えることができます。

データベースのリージョン間同期について

DR環境を別リージョンに構築する際に、データベースのデータの同期が必要なことがあります。データベースのデータを同期するには一般的にいくつかの方法があります。

  1. データベースのレプリケーションを利用する
  2. DRBDを利用してブロックデバイス単位での同期をする
  3. アプリケーション側で2つのDBへの書き込みを制御する

1つ目のデータベースのレプリケーション機能は、一般的にデータベースで発生したトランザクション情報を同期します。データベースの種類によってレプリケーションの実装方法はことなりますが、MySQLの場合、更新系のトランザクションをバイナリーログとして保存し、バイナリーログを同期することでデータの同期を行います。データだけではなく、トランザクションログなども同期できるのが特徴です。

2つ目は、DRBDというソフトウェアを利用してデータベースを同期する方法です。DRBDというソフトウェアでは、データベースのトランザクションを同期するのではなく、データベースのデータ領域をブロックデバイス単位で同期するものです。

3つ目にアプリケーション側でデータを制御する方法があります。
こちらはリスクも大きい選択のため、選択されるケースは少ないですが紹介します。
例えば、あるデータの更新が行われた場合に、アプリケーション側で2つのデータベースに両方に更新を行うという方法です。
両方のデータが一致するようにコントロールしなければいけないのでリスクもありますが、アプリケーション側で簡易に対応できるため、状況によっては採用されることもあります。

アベイラビリティゾーン(AZ)にDRを任せる

本セミナーでは、DR環境を別リージョンに作るということを主軸に話しました。
クラウドのAZの機能を利用することで、より簡単にDRの対策をすることもできます。
AZとは、リージョン内にある、送電元とネットワークが互いに分離された物理的な領域(データセンタ)です。片方の、データセンタが停止してもシステムが継続的に動作するように設計可能です。
例えば、次の図のように、AZを分けてサーバやデータベースなどを配置することができます。

こうすることで、たとえ片方のAZが災害などでダウンしても、システムは稼働し続けることができます。
地理的にも離れているので、災害で両方のAZがダウンする可能性は低いとも言えます。
システムの要件によるが、AZを活用することでDR対策と考えることもできます。

ただし、すべてのリージョンでAZが複数あるとは限らない点は注意ポイントです。
展開したいリージョンにいくつのAZがあるかは構築前に確認しておきましょう。

さいごに

本セミナーですが、9/28にも開催予定です。
詳細は追ってSBクラウドのホームページで掲載しますので、ご興味のある方は是非参加してください。

この記事をシェアする