View
0
Download
0
Category
Preview:
Citation preview
AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ
大谷 晋平(Shinpei OHTANI, ohtani@amazon.co.jp)
エマージングソリューション部 部長/ソリューションアーキテクト
Wifiは全セッション会場 展示会場にて、ご利用いただけます。
SSID: awssummit #awssummit
自己紹介
• 大谷 晋平(おおたに しんぺい)
• アマゾンデータサービスジャパン
– エマージングソリューション部 部長
• エマージングソリューション部とは？
– 技術駆動でイノベーションを起こす企業様を担当
• 執筆活動など
注意事項
• 本セッションはAWSサービスの基本的な機能などの説明はしません。
• アドバンスドな内容を想定したプレゼンテーションです。
アジェンダ
• おさらい
• マルチアベイラビリティゾーンアーキテクチャ
• マルチリージョンアーキテクチャとそのユースケース
• マルチリージョンの注意点
• まとめ
マルチアベイラビリティゾーン アーキテクチャ
リージョン
リージョン 米国西 オレゴン
EU西 東京
シンガポール
米国西 カリフォルニア
南米
米国東
米国政府
シドニー
=AWSのサービスを利用できる データセンター群の拠点
アベイラビリティゾーン
アベイラビリティゾーン 米国西 オレゴン
EU西 東京
シンガポール
米国西 カリフォルニア
南米
米国東
米国政府
シドニー
=AWSの論理的な データセンターの単位
• AWS固有のコンセプト
• リージョン内で同期が可能なゾーンを2つまたは3つ選択する
– 数ミリ秒程度の遅延
– 顧客インパクト最小でフェイルオーバ可能
アベイラビリティゾーンA アベイラビリティゾーンB
マルチアベイラビリティゾーンモデル(マルチAZ)
マルチAZは、AWSのコアのコンセプトの一つ
RDS
アベイラビリティゾーンA アベイラビリティゾーンB
EC2 A
EC2 B
EC2 C
Elastic
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を利用する
– Route53のレイテンシベースルーティング
ポイント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:ディザスタリカバリ
• ニーズ:DR用のバックアップサイトを立て、災害時に瞬時にリカバリしたい
ユースケース2:ディザスタリカバリ
• ソリューション:AMIやデータのリージョン間コピー→災害時に起動
AMIコピー EBSスナップ ショットコピー
S3間でのデータコピー
ユースケース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)
http://www.slideshare.net/adrianco/cassandra-performance-on-aws より抜粋
ポイント4:マルチリージョンでのデータ一貫性の維持は難しい
• マルチリージョン構成にする場合
– CAP定理や合意プロトコルの理解
– 分散ファイルシステムや分散データベースを用途に応じて使う
– データ同期形式が非同期であることを意識する
– 耐障害性に対して、あらゆるレベルでのリスクを検討しておく
– ZooKeeperなどのコーディネーションを利用する
マルチリージョンでの注意点
マルチリージョンアーキテクチャのポイント
• その１：必要になるまで分散させない
– 必要になるまでマルチリージョンは出来るだけ避ける
– マルチAZをまずは考える
– マルチリージョンの目的をはっきりさせる
• ユーザビリティ？非常に高い可用性？バックアップやDR?
• その２：物理制約を考慮する(光の速度は越えられない)
– 分散、分割、非同期コミュニケーション
– 同期型のコミュニケーションはパフォーマンス劣化がユースケースにあうか
マルチリージョンアーキテクチャの注意点
• 複合障害の伝播をどう抑えるか
– サーキットブレイカーパターン
• フォールバックの提供
• 障害をノーマルケースとして扱う工夫
• 自動化
– 素早いロールアウト・ロールバックが必須
– インフラストラクチャの自動化は必須
– Chef、Puppet、CloudFormation
リージョンB リージョンA
マルチリージョンでの注意点
テストをどうやってやるか？
マルチリージョンでの注意点 答え：GameDay
（本番環境での継続的なテスト）
広がるGameDayカルチャー
• 本番環境でアクティブ/アクティブ構成のテスト
– 実際の負荷同様でなければ、稼働するかどうかわからない
– 本番環境でテストしなければ、稼働するかどうかわからない
• Amazon.com: GameDay
• Netflix: Chaos Monkey(オープンソース)
• Obama for America
52
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
http://www.slideshare.net/jesserobbins/ameday-creating-resiliency-through-destruction
ポイント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より
ボーアバグ: 再現可能なソフトウェアバグで、本番環境ではレアであるべき
ハイゼンバグ: 通常ではありえない複数のリクエストや個々に独立した長いオペレーションのパターンの中で発生するバグで、調査しようとすると再現できなかったりするもの
HOST
LEVEL
METRICS
AGGREGATE
LEVEL
METRICS
LOG
ANALYSIS
EXTERNAL
SITE
PERFORMANCE
まとめ
マルチAZの妥当性
構成 可用性 コスト 難易度
シングルAZ 普通 安い 容易
マルチAZ 高い 比較的安い 容易
マルチリージョン 非常に高くすることが可能
高い 非常に難しい
AWS マルチアベイラビリティゾーンモデル再考
• AWS固有のコンセプト
• 現実に今出来る手法
• 同期式レプリケーションを前提にDCからサービスまで緻密に設計
– S3、RDS、DynamoDBなど
– データの一貫性を最優先に考えた設計
• 複数のゾーン間で負荷を分散
• アプリケーション側の開発容易性の確保
– 分散システム特有の高難度な点をAWSが隠蔽
– アプリケーション開発者がアプリケーションにフォーカスできるように
68
まとめ
• ポイント1:出来るだけマルチAZを活用しよう
• ポイント2:データの近さを意識してアーキテクティング
• ポイント3:DRはAWSの機能をフル活用しよう
• ポイント4:マルチリージョンでのデータ一貫性の維持は難しい
• ポイント5:障害は避けられない、受け入れて日常へ
• 複雑さを排除し、シンプルな構成で運用を
Thank You
AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ
大谷 晋平(Shinpei OHTANI, ohtani@amazon.co.jp)
エマージングソリューション部 部長/ソリューションアーキテクト
Recommended