AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ
大谷 晋平(Shinpei OHTANI, [email protected]) エマージングソリューション部 部長/ソリューションアーキテクト
Wifiは全セッション会場
展示会場にて、ご利用いただけます。
自己紹介
• 大谷 晋平(おおたに しんぺい)
• アマゾンデータサービスジャパン
– エマージングソリューション部 部長
• エマージングソリューション部とは？
– 技術駆動でイノベーションを起こす企業様を担当
• 執筆活動など
注意事項
• 本セッションはAWSサービスの基本的な機能などの説明はしません。
• アドバンスドな内容を想定したプレゼンテーションです。
アジェンダ
• おさらい
• マルチアベイラビリティゾーンアーキテクチャ
• マルチリージョンアーキテクチャとそのユースケース
• マルチリージョンの注意点
• まとめ
マルチアベイラビリティゾーン
アーキテクチャ
リージョン
リージョン
米国西 オレゴン EU西 東京 シンガポール 米国西 カリフォルニア 南米 米国東 米国政府 シドニー =AWSのサービスを利用できる データセンター群の拠点アベイラビリティゾーン
アベイラビリティゾーン 米国西 オレゴン EU西 東京 シンガポール 米国西 カリフォルニア 南米 米国東 米国政府 シドニー =AWSの論理的な データセンターの単位• AWS固有
のコンセプト
• リージョン内で同期が可能なゾーンを2つまたは3つ選択する
– 数ミリ秒程度の遅延 – 顧客インパクト最小でフェイルオーバ可能 アベイラビリティゾーンA アベイラビリティゾーンBマルチアベイラビリティゾーンモデル(マルチAZ)
マルチAZは、AWSのコアのコンセプトの一つ
RDS
アベイラビリティゾーンA アベイラビリティゾーンB EC2 A EC2 B EC2 CElastic
Load Balancing
DynamoDB
S3
※あくまで一例ですポイント1:出来るだけマルチAZを活用しよう
構成
可用性
コスト
難易度
シングルAZ
普通
安い
容易
マルチAZ
高い
比較的安い
容易
マルチリージョン 非常に高くす
ることが可能
高い
非常に難しい
マルチリージョンアーキテクチャと
そのユースケース
マルチリージョンアーキテクチャ
• マルチリージョンアーキテクチャとは？
– 複数リージョンを使って分散システムを構築するアプローチ
• どうしてこのようなマルチリージョンが難しいのか？
– AWSのビルディングブロックではカバーしない範囲をカバー
– 分散システム本来の難しさ
– フォールトトレラントの維持、部分障害・障害検出のむずかしさ
マルチリージョンのユースケース
• ユーザエクスペリエンスの向上
• ディザスタリカバリ
マルチリージョンのユースケース
• ユーザエクスペリエンスの向上
• ディザスタリカバリ
ユースケース1：ユーザエクスペリエンスの向上
• ニーズ：地理的に離れたユーザからのアクセス ELB EC2 RDS S3ユースケース1：ユーザエクスペリエンスの向上
• ソリューション：静的データをオフロードし、データの配信をより近くから CloudFront S3 Route53 ELB EC2 RDSユースケース1：ユーザエクスペリエンスの向上
• ニーズ：動的コンテンツも高速にアクセスしたい CloudFront S3 Route53 ELB EC2 RDSユースケース1：ユーザエクスペリエンスの向上
• ソリューション：データを分割して、データのローカリティを確保する データは分割 マスターデータはコピーする Tsunami Skeed Aspera CloudOptユースケース1：ユーザエクスペリエンスの向上
ユースケース1：ユーザエクスペリエンスの向上
• ソリューション:GSLBを利用するポイント2:データの近さを意識してアーキテクティング
• データの配信先を意識して静的データのオフロード • 動的コンテンツのローカリティにはリージョン間でデータ分割が必要 • データのリージョン間での受け渡し – 耐障害性の高いバウンダリをもうけ、非同期通信する (S3+SQS) – SNS＋SQSでメッセージを一斉通知(マルチリージョンPub/Sub) n n Amazon SNS Amazon SQS トピック キュー バウン ダリ リージョン A リージョン B AとBではバウンダリを通して データのやりとりをするマルチリージョンのユースケース
• ユーザエクスペリエンスの向上
• ディザスタリカバリ
ユースケース2:ディザスタリカバリ
• 実現するための考慮事項
– BCPプラン– RTO(Recovery Time Objective: 目標復旧時間) – RPO (Recovery Point Objective: 目標復旧時点)
• コスト vs RTO/RPOのトレードオフ
ユースケース2:ディザスタリカバリ
ユースケース2:ディザスタリカバリ
• ソリューション:AMIやデータのリージョン間コピー→災害時に起動
AMIコピー EBSスナップ
ショットコピー
ユースケース2:ディザスタリカバリ
• ソリューション:Route53を活用し、ディザスタリカバリを当たり前に 重みづけにより 正副切り替え Route53なら、 • 重みづけ • EC2のフェイルオーバ • ELBのフェイルオーバポイント3:DRはAWSの機能をフル活用する
• AMI/EBSスナップショットのコピー機能 • Route53の重みづけにより、正副を切り替え • Route53のELB/EC2フェイルオーバ機能 リージョンB リージョンA リージョンB リージョンA 100% 0% リージョンB リージョンA S3 Webサイトマルチリージョンのユースケース
• ユーザエクスペリエンスの向上
• ディザスタリカバリ
ユースケース3:非常に高い可用性の維持
• ニーズ : 非常に高い可用性の維持・データ一貫性の維持
各リージョンで高い可用性
ユースケース3:非常に高い可用性の維持
• 非常に高い可用性の維持・データ一貫性の維持 各リージョンで高い可用性 データはリージョンを超えてコピーデータベース、ファイルシステムの
データ一貫性の維持
マルチリージョンで高可用性のためにおさえたい3つの基礎
• CAP定理
• 合意プロトコル
• 耐障害性の維持
マルチリージョンで高可用性のためにおさえたい3つの基礎
• CAP定理
• 合意プロトコル
• 耐障害性の維持
ブリューワのCAP定理
ネット
ワーク分
断耐性
P
可用性
A
一貫性
C
http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdfブリューワのCAP定理
P(ネット ワーク分 断耐性) A(可用性) C(一貫性)一貫性・可用性・ネットワーク分断耐性
の3つのうち、分散システムでは
同時に3つ獲得できない
ブリューワのCAP定理
ネット
ワーク分
断耐性
P
可用性
A
一貫性
C
ブリューワのCAP定理、マルチリージョンでの場合
ネット
ワーク分
断耐性
P
可用性
A
一貫性
C
マルチリージョンで高可用性のためにおさえたい3つの基礎
• CAP定理
• 合意プロトコル
合意プロトコル
• 分散システム内で合意が必要な例
– リーダー/マスター選定、分散ロック – 複数サーバの中から1サーバだけが書き込むことを保証する – 広域災害によるパーティション分割時のDNS • http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-problems.html• Paxos：分散システムの合意プロトコル
• ZooKeeper(ZAB)：オープンソースのコーディネーションサービス
マルチリージョンで高可用性のためにおさえたい3つの基礎
• CAP定理
• 合意プロトコル
耐障害性の維持
• マルチリージョンのような地理的に大きく離れたDC間の場合
• データセンター間での
非同期レプリケーション
• 障害時の復旧のむずかしさ
1トランザクションあたり 70-80msecユースケース3:非常に高い可用性の維持
• マルチリージョンでの分散ファイルシステム(GlusterFS等) • 非同期レプリケーションが中心 レプリカ マスター スレーブ スレーブ Geo-Replication (非同期)ユースケース3:非常に高い可用性の維持
• マルチリージョンで分散データベースを利用• クオラム+Geo-Replication
Geo-Replication (Fail fast & silent, Isolation failure)
ポイント4:マルチリージョンでのデータ一貫性の維持は難しい
• マルチリージョン構成にする場合
– CAP定理や合意プロトコルの理解
– 分散ファイルシステムや分散データベースを用途に応じて使う
– データ同期形式が非同期であることを意識する
– 耐障害性に対して、あらゆるレベルでのリスクを検討しておく
– ZooKeeperなどのコーディネーションを利用する
マルチリージョンアーキテクチャのポイント
• その１：必要になるまで分散させない – 必要になるまでマルチリージョンは出来るだけ避ける – マルチAZをまずは考える – マルチリージョンの目的をはっきりさせる • ユーザビリティ？非常に高い可用性？バックアップやDR? • その２：物理制約を考慮する(光の速度は越えられない) – 分散、分割、非同期コミュニケーション – 同期型のコミュニケーションはパフォーマンス劣化がユースケースにあうかマルチリージョンアーキテクチャの注意点
• 複合障害の伝播をどう抑えるか – サーキットブレイカーパターン • フォールバックの提供 • 障害をノーマルケースとして扱う工夫 • 自動化 – 素早いロールアウト・ロールバックが必須 – インフラストラクチャの自動化は必須 – Chef、Puppet、CloudFormation リージョンB リージョンAマルチリージョンでの注意点
マルチリージョンでの注意点
答え：
GameDay
広がるGameDayカルチャー
• 本番環境でアクティブ/アクティブ構成のテスト
– 実際の負荷同様でなければ、稼働するかどうかわからない – 本番環境でテストしなければ、稼働するかどうかわからない
• Amazon.com: GameDay
• Netflix: Chaos Monkey(オープンソース)
• Obama for America
GameDayは何故できたのか？
More than anything else, I’ve learned that the key to building resilience systems is accepting that failure happens. There’s just no getting around it. That applies to the software discipline, as well as to the system management and architectural disciplines. …
The best you can hope for is to build a reliable software platform on top of components that are completely unreliable.
(最も確実なのは、信頼できないコンポーネントの上でも稼働する、信頼できるソフト ウェアプラットフォームを構築することだ)
Jesse Robins, former architect of GameDay in Amazon
http://queue.acm.org/detail.cfm?id=2371297
ポイント5:障害は避けられない、受け入れて日常へ
• 障害を特別視せずに迅速なリカバリを中心に考える – Resilience Engineering • GameDayのコア – Observe/Orient/Decide/Act – プロダクト+人での継続的な訓練 – 運用主体のカルチャー • 技術要素 – インフラストラクチャの自動化 – システム、ソフトウェア、オペレーションの全てを本番環境でテストする – 障害を受け入れて素早くリカバリーResilience(レジリエンス)とは
システムが変化や、障害、混乱を
受け入れる能力の事
http://www.slideshare.net/jesserobbins/ameday-creating-resiliency-through-destructionリカバリーオリエンテッドコンピューティングパターン(ROC)
• ソフトウェア、ハードウェアは非定期にかつ頻繁に壊れる前提 • アプリケーションでの障害の検出に注力
App ボーアバグ Urgent Alert ハイゼンバグ Reboot Failure Restart Re-image Failure Replace Failure
re:Invent CPN208:Failures at Scale & How to Ride Through Themより
