AWS クラウドデザインパターン - 監視編 -
自己紹介 名前 松尾康博 所属 アマゾンデータサービスジャパン株式会社ソリューションアーキテクト ID matsuoy@amazon.co.jp @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
書籍でノウハウを共有 Amazon Web Services クラウドデザインパターン設計ガイド http://www.amazon.co.jp/dp/4822211967/
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
初期のデザイン Amazon Route 53 ec.clouddesignpattern.org EIP 本番環境 EC2 インスタンス
問題発生 ( その 1) 問題 : お客様から 遅い と言われないように システム負荷を簡単に確認したい アクション : CloudWatch Monitoring Amazon CloudWatch を使用してインスタンスの 負荷状況を確認する 閾値を超えたらアラート通知
CloudWatch Monitoring Amazon Route 53 ec.clouddesignpattern.org Amazon CloudWatch EIP 本番 環境 CPU負荷 I/O負荷 N/W負荷 EC2 インスタンス OS内部の情報は Load Average Memory I/O wait Disk Usage 普段のコマンドで sysstat(sar),vmstat,df ps,top,iostat,free,netstat
CloudWatch Monitoring メリット 標準機能として CloudWatch を閲覧可能 閾値を設定して SNS で通知することも簡単に実現 注意点 CloudWatch のメトリクスは 14 日間保持 デフォルトでは OS 内部の状態 ( メモリ / ディスク使用率 / ロードアベレージ /iowait/etc.) は監視対象外
問題発生 ( その 2) 問題 : お客様から 遅い と言われないように システム内部の負荷を可視化したい アクション : Hybrid Monitoring 既存の監視ツールと CloudWatch を併用 OS より上位の監視は監視ツールを使用 閾値を超えたらアラート通知
Hybrid Monitoring Amazon CloudWatch Amazon Route 53 ec.clouddesignpattern.org EIP EIP 本番環境 EC2 インスタンス EC2 インスタンス
利用ソフトウェア Zabbix Munin Cacti Nagios RRDtool MRTG Ganglia
Hybrid Monitoring メリット CloudWatch のメトリクス以外の重要な性能情報を管理 収集 可視化 閾値を設定して通知することも簡単に実現 注意点 監視サーバ用に別途 EC2 インスタンスが必要 監視サーバ自体の可用性を考慮する必要あり
問題発生 ( その 3) 問題 : サーバダウン! 問い合わせが入る前に対応したい! アクション : Health Check 監視ツールの死活監視機能と通知機能を使用
Health Check Amazon Route 53 EIP ec.clouddesignpattern.org EIP 本番 環境 EC2 インスタンス EC2 インスタンス Ping等で定期的にチェック 正常応答が無い場合はアラートメール
問題発生 ( その 4) 問題 : サーバは生きているが httpd や mysqld のみダウン! すぐに対応できるようにしたい! アクション : Deep Health Check 監視ツールの死活監視機能と通知機能を使用して アプリケーションの動作をチェック
Deep Health Check Amazon Route 53 EIP ec.clouddesignpattern.org EIP 本番 環境 EC2 インスタンス EC2 インスタンス HTTPでDBアクセスまで行うページを 定期的にチェック 正常応答が無い場合はアラートメール
Deep Health Check メリット チェック対象のコンポーネントを一度に監視可能 システムレイテンシのチェックとしても利用可能 注意点 チェック対象のコンポーネントを全て使うチェックページの用意が必要 システムに余分な負荷をかけないようにチェック間隔に気をつける
問題発生 ( その 5) 問題 : サーバに障害発生! 速やかにサーバを自動復旧したい アクション : Server Swapping 以前取得したマシンイメージから別サーバを起動 ( 壊れた ) 本番環境の最新データを持つディスクを移行して 復旧実施
Server Swapping サーバに障害発生 EIP 仮想 サーバ EC2 インスタンス 監視サーバが障害を検知したら APIでサーバ入れ替え処理を自動実行 EIP 仮想 サーバ サーバ起動 データ 仮想ディスク 仮想ディスク マシン イメージ
Server Swapping メリット API を活用しクラスタソフトの様な機能を実現可能 様々なサーバに適用可能 注意点 APIの習得 実装が必要 障害発生の判断条件を慎重に行う必要あり ( 敏感すぎると Swap が発生しすぎてしまう )
問題発生 ( その 6) 問題 : Web サーバが落ちても システム全体で稼働し続けるようにしたい DB サーバの運用管理も楽したい アクション : Multi-Server Web サーバを冗長化し 単一障害点を削減 DB サーバを RDS に変更
Multi-Server Amazon Route 53 ec.clouddesignpattern.org Amazon CloudWatch EIP ロードバランサ オリジナル EC2 インスタンス 冗長構成 EC2 インスタンス EC2 インスタンス MySQL DB インスタンス
Multi Server メリット 可用性が向上する構成 DB, ロードバランサーの運用負荷も低い 注意点 RDS ELB( ロードバランサー ) の性能監視は CloudWatch で行う Web サーバ追加の度に監視ツール側にも設定が必要
問題発生 ( その 7) 問題 : DB サーバを RDS にしたことで 性能監視が CloudWatch と 監視サーバ画面に分かれて面倒 アクション : Monitoring Integration CloudWatch の監視メトリクスを監視サーバに取り込んで一元可視化
Monitoring Integration Amazon Route 53 ec.clouddesignpattern.org Amazon CloudWatch EIP ロードバランサ オリジナル EC2 インスタンス 冗長構成 EC2 インスタンス EC2 インスタンス MySQL DB インスタンス
Monitoring Integration メリット CloudWatch のメトリクスとその他のメトリクスを監視ツール上で一元管理可能 CloudWatch のメトリクスを任意の期間保存可能 (CloudWatch 上では 14 日間 ) デメリット CloudWatch API を使って データ取り込み処理を実装する CloudWatch API コール料金が若干発生
問題発生 ( その 8) 問題 : Web サーバの台数を増やすと DB サーバの性能がネックに アクション : Scale Up DB サーバの過負荷状態を検知すると API を使ってインスタンスサイズを自動で変更
Scale Up Amazon Route 53 ec.clouddesignpattern.org Amazon CloudWatch EIP ロードバランサ オリジ ナル 冗長 構成 EC2 インスタンス 冗長 構成 EC2 インスタンス EC2 インスタンス MySQL DB インスタンス 監視サーバが障害を検知したら APIでサーバ入れ替え処理を自動実行 MySQL DB インスタンス
Scale Up メリット Web/AP サーバのスケールアウトに追随してキャパシティ調整可能 Scale Down についても同様の仕組みで実現可能 注意点 RDS の場合インスタンスサイズ変更で 5 分程度停止するのでタイミングを考慮したり DB 接続できない場合は Sorry ページを出すようにアプリケーションを作りこむなどの工夫が必要
問題発生 ( その 9) 問題 : Web サーバの台数を増やすとログが分散して確認しにくい アクション : Log Aggregation 各サーバのログを集約して蓄積 障害発生前後の状況 原因の特定等に利用
Log Aggregation Amazon Route 53 ec.clouddesignpattern.org 各サーバのログを ログサーバに転送集約 蓄積 ログ内容の監視も行い パターンマッチしたらアラート通知 EIP ログは最終的にS3に保存 長期保存ならGlacierに ロードバランサ オリジ ナル 冗長 構成 EC2 インスタンス EC2 インスタンス
Log Aggregation メリット 多数のインスタンスに散らばったログを集約して管理 ローカルログは適宜 rotate して改廃しディスク節約 注意点 ログ送信 Agent ログ収集サーバの導入運用が必要 集約したログを失わない工夫が必要 (S3 へ移動 等 ) ログの内容監視する場合は ログフォーマットについてアプリケーション開発者と事前に仕様を決めておく
利用ソフトウェア syslog (syslog-ng, rsyslog) Fluentd Flume Scribe Zabbix swatch logmon
運用監視のまとめ 監視対象によって方法 内容が異なる オンプレミス EC2 サービス (RDS,etc) アプリ監視要要要 性能監視要要要 プロセス死活監視要要不要 OS 死活監視要要不要 H/W 死活監視要不要不要 監視内容が少ないサービスは運用コストが低い
オンプレミスの運用監視 アプリ性能 / 死活監視 リソース監視 死活監視 ( ログ, プロセス,OS) アプリチェック Application Middleware H/W 監視 SNMP Trap サーバ ストレージ ネットワーク アプライアンス機器 電源 帯域 Agent 経由等の情報収集 SNMP/MIB OS Server/Storage Network Appliance Data Center システム導入 / 拡張時の作業 保守切れによる H/W の入れ替え ファームウェアバージョンのチェックと維持 障害時の原因調査および復旧作業
EC2 の運用監視 アプリ性能 / 死活監視 リソース監視 死活監視 ( ログ, プロセス,OS) アプリチェック Application Middleware Agent 経由等の情報収集 OS CloudWatch/ API/SDK Service Status 監視 リソース監視 ログ監視 Alarm
サービスの運用監視 アプリ性能 / 死活監視 アプリチェック Application CloudWatch/ API/SDK Service Status 監視 リソース監視 ログ監視 Alarm
まとめ デザインパターンを活用し システム規模 システム要件に合わせた監視システムの構築が可能に API で自動化することで性能維持 ダウンタイム短縮を実現可能に システムが拡大しても 運用者の負担を削減する自働化の仕組みづくりが可能に
まとめ ( 改善 革新 ) 改善 今までできていたことを より早く 簡単に 安く実現できる 革新 今までできなかったことが実現できる
CDP で AWS をもっと楽しく
ご清聴ありがとうございました FACEBhttps://www.facebook.com/awscdp