AWSを用いた耐障害性の高いアプリケーションの設計

AWSを用いた耐障害性の高い
アプリケーションの設計
2011年5月17日
玉川憲 (@KenTamagawa ), エバンジェリスト
荒木靖宏 (@ar1), ソリューションアーキテクト

AWSアーキテクチャセンターのご紹介

aws.amazon.com/jp/architecture/

Webinarのご案内

ホワイトペーパー
「耐障害性の高い
アプリケーションの構築」
日本語版、本日公開！！

ベストプラクティスの共有

Copyright © 2011 Amazon Web Services

Overview

耐障害性に関係するAWSの機能

AWSアーキテクチャのガイダンス

ヒントとTIPS

Q&A


耐障害性に関係する
AWSの機能


AWSにおける耐障害性を高める構成要素

本質的に耐故障性、耐障害性の高いAWSのサービス:
• Amazon Simple Storage Service (S3)
• Amazon Simple Queue Service (SQS)
• Amazon SimpleDB
• Amazon Relational Database Service (RDS)

EC2では耐故障性、耐障害性を高めるツールや機能を提供
 Availability Zone、Elastic IP Address、EBS等
 予算 vs 耐障害性のトレードオフの間で柔軟に選択


Amazon S3の場合

バケット
S3 データ置くと、
東京リージョン
東京リージョン内で、物理的に3
あらゆるか所以上にコ
データをピーされる
保存
データセン
ター

自動複製

高い耐久性で
データ失わない:
99.999999999%

Amazon EC2 アーキテクチャ

Amazon Region
Machine Availability Zone
Image (AMI) Ephemeral
Storage
EC2 Instance

Elastic
CloudWatch Block
Storage

Security Group

Auto Amazon S3
Scaling Elastic IP
EBS EBS
Address Snapshot Snapshot

Load Balancing

EC2の機能
AMI (Amazon Machine Image)
 サーバーのコピーをとりテンプレート化することで、再利用可能
 障害から迅速に回復するための第一歩

ストレージの形式
 インスタンスストレージ
 寿命はインスタンスと同じ
 年間故障率(AFR)は通常のハードディスクと同程度（5％前後）

 EBSボリューム
 寿命はインスタンスとは独立
 データを冗長化 →AFR は 0.1% から 0.5%
 EBSスナップショットでバックアップできる
 EC2インスタンスが故障した際には、
新しいEC2インスタンスに、EBSと取り付ければ良い


EC2の機能

Elastic IP Address
 リージョン内で任意のEC2インスタンスにマッピングできる
 故障したインスタンスから取り外して、代替インスタンスへ付け替え可能

Auto Scaling
 2種類の使い方:
• CloudWatchの測定結果に基づくインスタンス数の追加と終了
• インスタンス数を固定した使い方：故障/状態の悪くなったインスタン
スを交換
Reserved Instances
 キャパシティの保証


EC2の機能

CloudWatch Alarms


EC2の機能
Elastic Load Balancing
 入ってくるトラフィックを、複数インスタンス、複数ゾーンに
分散して転送
 正常動作しているインスタンスにのみ転送


Amazon EC2: Regions と Availability Zones

米国東 (Northern Virginia) 東京リージョン

Availability Availability
Zone A Zone B
Zone A Zone B
Zone C Zone D

Amazon EC2 Regions:
US East (Northern Virginia) / US West (Northern California) /
EU (Ireland) / Asia Pacific (Singapore) / Asia Pacific (Tokyo)


Availability Zoneの特徴とポイント

特徴
 物理的に異なるロケーション
 AZ間は低レイテンシのネットワークで接続
 独立した電源、空調、ネットワーク、セキュリティ

アーキテクチャ設計のポイント
 ELBは複数AZのインスタンスを使用できる
 アプリケーションスタック毎に、複数AZで分離しておく


典型的な複数AZの利用法
Availability Zone A Availability Zone B
データベースサーバ/ データベースサーバ/
RDS DBインスタンス RDS DBインスタンス

App サーバー App サーバー

Web サーバー Web サーバー

リクエストとヘルスチェック

Elastic Load Balancer

入ってくるリクエスト

リージョンの特徴と利用ポイント
特徴
 リージョンは、機能的に分離されている(しかしそれぞれ同じ設計)
 各リージョンが、2つ以上のAZで構成
 リージョン間は、パブリックなインターネットで接続
使用リージョンの選択
 利用できるサービス、機能があること
 利用者に近いリージョンを選ぶ
 法律や慣行に合致すること
 DR戦略にあわせて

アーキテクチャ設計のポイント
 利用ポイント耐障害性の高いアプリケーションを作成するには、
リージョン内の複数のAvailability Zoneを用いる

AWS アーキテクチャ
ガイダンス


Design For Failure – 基本原則

単一障害点（single points of failure）の排除

全てが故障すると仮定して、保守的に設計する

Goal: 物理ハードウェアが故障して、消失したり交換されて
もアプリケーションは機能する

障害からの復旧を計画する

ビジネスニーズと高可用性実現コストのトレードオフ


Design For Failure – AWSの場合

Elastic IPを固定したアクセス手段として使う
複数のアベイラビリティゾーン(AZ)を使う
データを複数AZに複製する
 例：Amazon RDSのMulti-AZモードの使用
常時監視する（Amazon CloudWatch）
永続するファイルシステムはEBSを使う
EBSスナップショットをとって、S3にバックアップ


Amazon EC2上での耐障害性アーキテクチャ

YourWebsite.com

EC2 Instance A EC2 Instance B

Replication
MASTER MASTER
SLAVE

EBS Data EBS Log EBS Data
Volume Volume Volume


アベイラビリティゾーンの利活用

YourWebsite.com

EC2 Instance A EC2 Instance B

Replication
MASTER MASTER
SLAVE

Logs
EBS Data EBS Data
Volume Amazon Volume
Simple DB

Copyright ©
2011 Amazon

疎結合なシステムの構築
Web Services

独立したコンポーネントの使用

ブラックボックスとして全て設計

負荷分散とスケールを意識したクラスタ

適切な縮退をも意識

Amazon SQS をバッファ使う
密結合 Controller Controller Controller
A B C

Q Q Q
キューをつかった Controller Controller Controller
疎結合 A B C

Elasticityの実現

コンポーネントの正常稼働やロケーションの固定を前提としない

再起動や再配置で回復できる設計の採用

自力でブートする
 名前や役割を自己解決する

動的な設定を有効にする

ブート時の設定内容保持にSimpleDBを使う

オートスケールの使用

ELBをそれぞれの段階で使用


ヒントとTips


抽象化を行う

サーバー
 レシピからサーバーを構築する
(PuppetやChefを利用)

システム
 全体のシステムをテンプレートから構築す
る (CloudFormation)


自己管理するEC2インスタンスの構築

TagあるいはUserDataを読み込んでインスタンス起動
Startupコードに、コンフィグデータをチェックさせる
上記の動的な情報を基にして、インスタンスの役割をセットする
パッケージをインストール/アップデートする
サービスを開始する
アプリケーションのコードをインストール/アップデートする
必要なEBSボリュームをCreate/attachする
Elastic IPアドレスを付加する
追加のTagをセット
最後にヘルスチェックを実施して、オンラインにする


故障は役に立つ？？？

あらゆるソフトウェアシステムが、長期間使うと品質が
低下する
 メモリリーク、ファイルのフラグメント、ハードウェアの品質
低下
従来のIT環境では、ハードウェアを定期的に保守するが
→更新は大変、金銭的にも厳しい
Amazon EC2を用いれば、任意のタイミングで入れ替
え可能
むしろ、定期的なリフレッシュと考えられる


Copyright © 2011
Amazon Web

Chaos Monkeyを用いる Services

Netflixブログを参照

Simple monkey:
 AWSのアカウント内のインスタンスを落とす(kill)

Complex monkey:
 特定のタグを持ったインスタンスを落とす
 他の障害を追加 (例: セキュリティグループでの接続性)

Human monkey:
 AWS Management Consoleからインスタンスを落とす

http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html

AWSプレミアムサポート
アーキテクチャ設計に関するガイダンス、ベストプラク
ティスも日本語でご案内できます
aws.amazon.com/jp/premiumsupport/
ブロンズシルバーゴールドプラチナ

初回応答時間１２時間４時間１時間１５分

サポート連絡先１人２人３人無制限

24/365対応なしなしありあり

TEL可能不可不可可能可能

専任スタッフなしなしなしあり

特別サポートなしなしなしあり
AWS利用総額の
AWS利用総額の
$0~$10K: 10%
AWS利用総額の 10%
料金 $49
5%
$10K~$80K: 7%
$80K~: 5%
（最低$15K）
（最低$400）

Q&A


ご参加ありがとう
ございました


AWSを用いた耐障害性の高いアプリケーションの設計

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to AWSを用いた耐障害性の高いアプリケーションの設計

Similar to AWSを用いた耐障害性の高いアプリケーションの設計 (20)

More from SORACOM, INC

More from SORACOM, INC (20)

Recently uploaded

Recently uploaded (16)

AWSを用いた耐障害性の高いアプリケーションの設計