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

書籍でノウハウを共有

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

可用性を高める２つのアプローチ

MTBFを長く：アプリケーション・アーキテクチャ MTTRを短く：クラウド＋監視＋API＋自動化

ec.cloudesignpattern.org

初期のデザイン

EC2 インスタンス

本番 環境

Amazon Route 53

ec.clouddesignpattern.org

EIP

問題発生 (その１)

問題： お客様から「遅い」と言われないように、システム負荷を簡単に確認したい

アクション： ”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