share facebook facebook twitter menu hatena pocket slack

2011.08.25 THU

(献本御礼)日経コンピュータ2011年8月4日号

鈴木 宏康

WRITTEN BY 鈴木 宏康

日経BP社様から「日経コンピュータ2011年8月4日号」を
献本いただきました。

他にも興味深い記事があるのですが、
やはりAWS関係の特集である

「クラウドのトラブル(Amazonの事例にみる三つの予防策)」

に注目してしまいました。

この記事は、まだ記憶に新しいAWSの2011年4月21にUS東岸リージョンで
発生した、大規模なトラブルの詳細な説明が中心となっています。

最大4日間程度、部分的なサービスが停止していたのですが、その障害内容を非常に詳しく紹介しています。
そして、紹介する上でAWSの内部的な仕組みも多数説明されているのでAWSの内部的な仕組み(特にEBSまわり)を
知る上でも、非常に参考になる記事です。

障害ばかりではなく、その対策に関しても下記3点を軸に言及されています。

  • ストレージ障害
  • 仮想マシン障害
  • DC設備障害

良い機会ですので、この3点に関して、僕の考え(AWS限定)も入れた形で
まとめておこうと思います。

○ストレージ障害

EBSの障害に関しては三つの対策かあると思います。

  • 定期的にスナップショット
  • 定期的にファイルバックアップ
  • ソフトウェアRAID(ミラーリング)

ファイルバックアップ先はS3やAWS外も考えることができます。

○仮想マシン障害

EC2インスタンスの障害は冗長構成にしてELBで分散させる方式になるでしょう。
冗長構成はAZをまたがる形にしておけば、下記のDC設備障害にもある程度対応できるはずです。
また、ELBが利用できなくても、EIPは他のインスタンスへの割り当て直しができるので、障害を検知したら、
スタンバイ状態のEC2インスタンスにEIPを割り当て直す方法も可能だと思います。

○DC設備障害

DC=AZとした場合は、上記のような方法や、並列で動かせるシステムなら、
別のAZで複数起動することで対応できると思います。
また、AZ間は非常にシームレスになるように設計されているので、上記の構築も簡単です。

DC=Regionとした場合は、Region間は完全に隔離されているので、
自分たちで仕組みを作成する必要があるでしょう。

実際問題、上記の中でもAWSの仕組みを利用して簡単にできるものは、下記のようになると思います。

  • 定期的にスナップショット
  • 定期的に(S3へ)ファイルバックアップ
  • 複数AZで冗長構成を組みELBで分散

こちらの記事はなかの人(suz-lab)監修のもと掲載しています。
元記事は、こちら

鈴木 宏康

鈴木 宏康

愛知県生まれ。東京工業大学大学院修士課程修了。在学時より、ベンチャー企業でインターネットに関する業務に携わり、現在はクラウド(主にAmazon Web Services)上での開発・運用を軸とした事業の、業務の中心として活躍。

cloudpack

cloudpackは、Amazon EC2やAmazon S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。
AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。