[aws summit 2012] クラウドデザインパターン#6 cdp クラウド監視編
DESCRIPTION
クラウドデザインパターン#6 CDP クラウド監視編 登壇者名・社名 松尾 康博(アマゾン データ サービス ジャパン 株式会社)TRANSCRIPT
AWSクラウドデザインパターン -監視編-
自己紹介
名前
松尾 康博
所属
アマゾンデータサービスジャパン株式会社
ソリューションアーキテクト
@understeer
好きなAWSサービス
HPCインスタンス
好きなCDP
スケールアップパターン
AWSクラウドデザインパターンとは...
AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したもの。
例えば... (Web Storage Archive)
解決したい課題 サーバで大量に発生するログを一元管理したい
クラウドでの解決 容量無制限ウェブストレージを利用し、キャパシティを気にすることなく格納可能
実装 EC2上でローテートされたログをAPI等のツールを利用しS3に転送
利点 ディスクスペース管理が不要になり、堅牢性の高いストレージでログを管理
注意点 AutoScale時には、停止前に該当ログの退避の仕組みを実装する必要がある
構造
Webでノウハウを共有
WIKI http://aws.clouddesignpattern.org/index.php
FACEBOOK https://www.facebook.com/awscdp
書籍でノウハウを共有
http://www.amazon.co.jp/dp/4822211967/
Amazon Web Services クラウドデザインパターン 設計ガイド
CDPカテゴリ (2012.09.13現在)
基本 Snapshot
Stamp
Scale Up
Ondemand Disk
可用性を向上 Multi-Server
Multi-Datacenter
Floating IP
Deep Health Check
動的コンテンツを処理 Scale Out
Clone Server
NFS Sharing
NFS Replica
State Sharing
URL Rewriting
Rewrite Proxy
Cache Proxy
Scheduled Scale Out
静的コンテンツを処理 Web Storage Direct Hosting Private Distribution Cache Distribution Rename Distribution
データをアップロード Write Proxy Storage Index Direct Object Upload
リレーショナルデータベース DB Replication Read Replica In-memory DB Cache Sharding Write
バッチ処理 Queuing Chain Priority Queue Job Observer Scheduled Autoscaling
運用保守 Bootstrap
Cloud DI
Stack Deployment
Server Swapping
Monitoring Integration
Web Storage Archive
Weighted Transition
Hybrid Backup
ネットワーク On-Demand NAT
Backnet
Functional Firewall
Operational Firewall
Multi Load Balancer
WAF Proxy
Cloud Hub
Eコマースサイト 監視編
今回のシナリオ
今回のシナリオをご紹介する前に...
CDP画像・動画配信編(Movable Type)
雲の写真を載せるブログサイト開始
はじめは個人的に開始
動画や過去画像集も公開し始める
まさかの大人気
まさかの海外展開
今回のシナリオ
まさかの
本実装シナリオのゴール
大成長するECサイトを例に、
を実現するための監視方法を解説
アクセルを調整するようにサーバ数を調整
キャパシティの監視と
サイトを成長させるには
状況に応じた対応
サイトの重要度が上がると
http://www.flickr.com/photos/mutsmuts/4695658106/
可用性!可用性!
http://www.old-computers.com/news
深夜メンテナンス
負荷対策
障害対応。。。
ボッチ作業。。。
クラウドの可用性
故障することを前提に考える Design for Failure
可用性の2つの指標 MTBF: Mean Time Between Failure MTTR: Mean Time To Repair
可用性を高める2つのアプローチ
MTBFを長く:アプリケーション・アーキテクチャ MTTRを短く:クラウド+監視+API+自動化
ec.cloudesignpattern.org
初期のデザイン
EC2 インスタンス
本番 環境
Amazon Route 53
ec.clouddesignpattern.org
EIP
問題発生 (その1)
問題: お客様から「遅い」と言われないように、システム負荷を簡単に確認したい
アクション: ”CloudWatch Monitoring” Amazon CloudWatchを使用してインスタンスの
負荷状況を確認する。
閾値を超えたらアラート通知
CloudWatch Monitoring
EC2 インスタンス
本番 環境
Amazon Route 53
ec.clouddesignpattern.org
EIP
Amazon CloudWatch
OS内部の情報は
• Load Average
• Memory
• I/O wait
• Disk Usage
普段のコマンドで
sysstat(sar),vmstat,df
ps,top,iostat,free,netstat CPU負荷
I/O負荷
N/W負荷
CloudWatch Monitoring
メリット
標準機能としてCloudWatchを閲覧可能
閾値を設定してSNSで通知することも簡単に実現
注意点
CloudWatchのメトリクスは14日間保持
デフォルトではOS内部の状態( メモリ/ディスク使用率/ロードアベレージ/iowait/etc.)は監視対象外
問題発生 (その2)
問題: お客様から「遅い」と言われないように
システム内部の負荷を可視化したい
アクション: ”Hybrid Monitoring” 既存の監視ツールとCloudWatchを併用。
OSより上位の監視は監視ツールを使用。
閾値を超えたらアラート通知。
Hybrid Monitoring
EC2 インスタンス
本番 環境
Amazon Route 53
ec.clouddesignpattern.org
EIP
EC2 インスタンス
EIP
Amazon CloudWatch
利用ソフトウェア
Zabbix
Munin
Cacti
Nagios
RRDtool
MRTG
Ganglia
Hybrid Monitoring
メリット
CloudWatchのメトリクス以外の重要な性能情報を管理・収集・可視化
閾値を設定して通知することも簡単に実現
注意点
監視サーバ用に別途EC2インスタンスが必要
監視サーバ自体の可用性を考慮する必要あり
問題発生 (その3)
問題: サーバダウン!
問い合わせが入る前に対応したい!
アクション: ”Health Check” 監視ツールの死活監視機能と通知機能を使用
Health Check
EC2 インスタンス
本番 環境
Amazon Route 53
ec.clouddesignpattern.org
EIP
EC2 インスタンス
EIP
Ping等で定期的にチェック 正常応答が無い場合はアラートメール
問題発生 (その4)
問題: サーバは生きているがhttpd やmysqldのみダウン!
すぐに対応できるようにしたい!
アクション: ”Deep Health Check” 監視ツールの死活監視機能と通知機能を使用して
アプリケーションの動作をチェック
Deep Health Check
EC2 インスタンス
本番 環境
Amazon Route 53
ec.clouddesignpattern.org
EIP
EC2 インスタンス
EIP
HTTPでDBアクセスまで行うページを 定期的にチェック
正常応答が無い場合はアラートメール
Deep Health Check
メリット
チェック対象のコンポーネントを一度に監視可能
システムレイテンシのチェックとしても利用可能
注意点
チェック対象のコンポーネントを全て使うチェックページの用意が必要
システムに余分な負荷をかけないようにチェック間隔に気をつける
問題発生 (その5)
問題: サーバに障害発生! 速やかにサーバを自動復旧したい
アクション: “Server Swapping” 以前取得したマシンイメージから別サーバを起動 (壊れた)本番環境の最新データを持つディスクを移行して、復旧実施
Server Swapping
仮想 サーバ
サーバに障害発生
仮想ディスク
データ
仮想 サーバ
仮想ディスク
マシン イメージ
サーバ起動
EIP
EC2 インスタンス
EIP
監視サーバが障害を検知したら APIでサーバ入れ替え処理を自動実行
Server Swapping
メリット
APIを活用しクラスタソフトの様な機能を実現可能
様々なサーバに適用可能
注意点
APIの習得・実装が必要
障害発生の判断条件を慎重に行う必要あり
(敏感すぎるとSwapが発生しすぎてしまう)
問題発生 (その6)
問題: Webサーバが落ちても、システム全体で 稼働し続けるようにしたい。
DBサーバの運用管理も楽したい
アクション: “Multi-Server” Webサーバを冗長化し、単一障害点を削減
DBサーバを、RDSに変更
Multi-Server
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
MySQL DB インスタンス
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
Amazon CloudWatch
EC2 インスタンス
EIP
Multi Server
メリット
可用性が向上する構成
DB,ロードバランサーの運用負荷も低い
注意点
RDS・ELB(ロードバランサー)の性能監視はCloudWatchで行う
Webサーバ追加の度に監視ツール側にも設定が必要
問題発生 (その7)
問題: DBサーバをRDSにしたことで、 性能監視がCloudWatchと
監視サーバ画面に分かれて面倒
アクション: “Monitoring Integration” CloudWatchの監視メトリクスを監視サーバに取り込んで一元可視化
Monitoring Integration
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
MySQL DB インスタンス
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
Amazon CloudWatch
EC2 インスタンス
EIP
Monitoring Integration
メリット CloudWatchのメトリクスとその他のメトリクスを監視ツール上で一元管理可能
CloudWatchのメトリクスを任意の期間保存可能(CloudWatch上では14日間)
デメリット CloudWatch APIを使って、データ取り込み処理を実装する
CloudWatch API コール料金が若干発生
問題発生 (その8)
問題: Webサーバの台数を増やすと DBサーバの性能がネックに。。
アクション: “Scale Up” DBサーバの過負荷状態を検知すると、APIを使ってインスタンスサイズを自動で変更
Scale Up
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
MySQL DB インスタンス
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
Amazon CloudWatch
EC2 インスタンス
EIP
MySQL DB インスタンス
冗長 構成
監視サーバが障害を検知したら APIでサーバ入れ替え処理を自動実行
Scale Up
メリット
Web/APサーバのスケールアウトに追随してキャパシティ調整可能
Scale Downについても同様の仕組みで実現可能
注意点
RDSの場合 インスタンスサイズ変更で5分程度停止するのでタイミングを考慮したり、DB接続できない場合はSorryページを出すようにアプリケーションを作りこむなどの工夫が必要
問題発生 (その9)
問題: Webサーバの台数を増やすと ログが分散して確認しにくい
アクション: “Log Aggregation” 各サーバのログを集約して蓄積。
障害発生前後の状況・原因の特定等に利用
Log Aggregation
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
EIP
各サーバのログを、ログサーバに転送集約・蓄積 ログ内容の監視も行い、
パターンマッチしたらアラート通知
ログは最終的にS3に保存 長期保存ならGlacierに
Log Aggregation
メリット
多数のインスタンスに散らばったログを集約して管理
ローカルログは適宜rotateして改廃しディスク節約
注意点
ログ送信Agent、ログ収集サーバの導入運用が必要
集約したログを失わない工夫が必要(S3へ移動、等)
ログの内容監視する場合は、ログフォーマットについてアプリケーション開発者と事前に仕様を決めておく
利用ソフトウェア
syslog (syslog-ng, rsyslog)
Fluentd
Flume
Scribe
Zabbix
swatch
logmon
運用監視のまとめ
監視対象によって方法・内容が異なる オンプレミス EC2 サービス
(RDS,etc)
アプリ監視 要 要 要
性能監視 要 要 要
プロセス死活監視 要 要 不要
OS死活監視 要 要 不要
H/W死活監視 要 不要 不要
監視内容が少ないサービスは運用コストが低い
オンプレミスの運用監視
Application
Middleware
Data Center
Server/Storage
Appliance
SNMP/MIB
Agent経由等の 情報収集
アプリチェック
OS
Network
H/W監視
サーバ・ストレージ
ネットワーク
アプライアンス機器
電源・帯域
アプリ性能/死活監視
リソース監視
死活監視 (ログ,プロセス,OS)
SNMP Trap
• システム導入/拡張時の作業
• 保守切れによるH/Wの入れ替え。
• ファームウェアバージョンのチェックと維持
• 障害時の原因調査および復旧作業
EC2の運用監視
Application
Middleware
CloudWatch/ API/SDK
Agent経由等の 情報収集
アプリチェック
OS
Service Status監視
リソース監視
ログ監視
アプリ性能/死活監視
リソース監視
死活監視 (ログ,プロセス,OS)
Alarm
サービスの運用監視
Application アプリチェッ
ク アプリ性能/死活監視
Alarm
CloudWatch/ API/SDK
Service Status監視
リソース監視
ログ監視
まとめ
デザインパターンを活用し
システム規模・システム要件に合わせた監視システムの構築が可能に
APIで自動化することで性能維持・ダウンタイム短縮を実現可能に
システムが拡大しても、運用者の負担を削減する自働化の仕組みづくりが可能に
まとめ (改善・革新)
今までできていたことを、 より早く、簡単に、安く実現できる
今までできなかったことが 実現できる
改善
革新
CDPでAWSをもっと楽しく
ご清聴ありがとうございました。
FACEBhttps://www.facebook.com/awscdp