クラウドデザインパターン#6 CDP クラウド監視編 登壇者名・社名　松尾 康博（アマゾン データ サービス ジャパン 株式会社）

1. AWSクラウドデザインパターン
-監視編-

2. 自己紹介
 名前
松尾 康博
 所属
アマゾンデータサービスジャパン株式会社
ソリューションアーキテクト
 ID
 matsuoy@amazon.co.jp
 @understeer
 好きなAWSサービス
HPCインスタンス
 好きなCDP
スケールアップパターン

3. AWSクラウドデザインパターンとは...
 AWSクラウドを使ったシステムアーキテクチャ設計を
行う際に発生する、典型的な問題とそれに対する解決
策・設計方法を、分かりやすく分類して、ノウハウとし
て利用できるように整理したもの。

4. 例えば... (Web Storage Archive)
 解決したい課題  構造
サーバで大量に発生するログを一元管
理したい
 クラウドでの解決
容量無制限ウェブストレージを利用し、
キャパシティを気にすることなく格納
可能
 実装
EC2上でローテートされたログをAPI等
のツールを利用しS3に転送
 利点
ディスクスペース管理が不要になり、
堅牢性の高いストレージでログを管理
 注意点
AutoScale時には、停止前に該当ログ
の退避の仕組みを実装する必要がある

5. Webでノウハウを共有
WIKI
http://aws.clouddesignpattern.org/index.php
FACEBOOK
https://www.facebook.com/awscdp

6. 書籍でノウハウを共有
Amazon Web Services クラウドデザインパターン 設計ガイド
http://www.amazon.co.jp/dp/4822211967/

7. CDPカテゴリ (2012.09.13現在)
 基本  静的コンテンツを処理  運用保守
Snapshot Web Storage Bootstrap
Stamp Direct Hosting Cloud DI
Private Distribution Stack Deployment
Scale Up
Cache Distribution
Ondemand Disk Server Swapping
Rename Distribution
Monitoring Integration
 可用性を向上 Web Storage Archive
 データをアップロード Weighted Transition
Multi-Server Write Proxy
Hybrid Backup
Multi-Datacenter Storage Index
Floating IP Direct Object Upload
Deep Health Check  ネットワーク
 リレーショナルデータベース On-Demand NAT
 動的コンテンツを処理 DB Replication Backnet
Read Replica Functional Firewall
Scale Out
In-memory DB Cache Operational Firewall
Clone Server Sharding Write Multi Load Balancer
NFS Sharing
WAF Proxy
NFS Replica  バッチ処理 Cloud Hub
State Sharing Queuing Chain
URL Rewriting Priority Queue
Rewrite Proxy Job Observer
Cache Proxy Scheduled Autoscaling
Scheduled Scale Out

8. 今回のシナリオ
Eコマースサイト
監視編

9. 今回のシナリオをご紹介する前に...
CDP画像・動画配信編(Movable Type)
雲の写真を載せるブログサイト開始
はじめは個人的に開始
動画や過去画像集も公開し始める
まさかの大人気
まさかの海外展開

10. 今回のシナリオ
まさかの

11. 本実装シナリオのゴール
大成長するECサイトを例に、
を実現するための監視方法を解説

12. サイトを成長させるには
キャパシティの監視と
状況に応じた対応
アクセルを調整するようにサーバ数を調整

13. サイトの重要度が上がると
可用性！可用性！
深夜メンテナンス
負荷対策
障害対応。。。
ボッチ作業。。。
http://www.old-computers.com/news
http://www.flickr.com/photos/mutsmuts/4695658106/

14. クラウドの可用性
 故障することを前提に考える
Design for Failure
 可用性の2つの指標
MTBF: Mean Time Between Failure
MTTR: Mean Time To Repair
 可用性を高める２つのアプローチ
MTBFを長く：アプリケーション・アーキテクチャ
MTTRを短く：クラウド＋監視＋API＋自動化

15. ec.cloudesignpattern.org

16. 初期のデザイン
Amazon
ec.clouddesignpattern.org
Route 53
EIP
本番
環境
EC2
インスタンス

17. 問題発生 (その１)
問題：
お客様から「遅い」と言われないように、
システム負荷を簡単に確認したい
アクション：
”CloudWatch Monitoring”
Amazon CloudWatchを使用してインスタンスの
負荷状況を確認する。
閾値を超えたらアラート通知

18. CloudWatch Monitoring
Amazon
ec.clouddesignpattern.org
Route 53
Amazon CloudWatch
OS内部の情報は
EIP
• Load Average
• Memory
• I/O wait
• Disk Usage
普段のコマンドで
本番
環境
sysstat(sar),vmstat,df
ps,top,iostat,free,netstat
EC2
CPU負荷 インスタンス
I/O負荷
N/W負荷

19. CloudWatch Monitoring
メリット
標準機能としてCloudWatchを閲覧可能
閾値を設定してSNSで通知することも簡単に実現
注意点
CloudWatchのメトリクスは14日間保持
デフォルトではOS内部の状態( メモリ/ディスク使用率
/ロードアベレージ/iowait/etc.)は監視対象外

20. 問題発生 (その2)
問題：
お客様から「遅い」と言われないように
システム内部の負荷を可視化したい
アクション：
”Hybrid Monitoring”
既存の監視ツールとCloudWatchを併用。
OSより上位の監視は監視ツールを使用。
閾値を超えたらアラート通知。

21. Hybrid Monitoring
Amazon
ec.clouddesignpattern.org
Route 53
Amazon CloudWatch
EIP EIP
本番
環境
EC2 EC2
インスタンス インスタンス

22. 利用ソフトウェア
Zabbix
Munin
Cacti
Nagios
RRDtool
MRTG
Ganglia

23. Hybrid Monitoring
メリット
CloudWatchのメトリクス以外の重要な性能情報を管
理・収集・可視化
閾値を設定して通知することも簡単に実現
注意点
監視サーバ用に別途EC2インスタンスが必要
監視サーバ自体の可用性を考慮する必要あり

24. 問題発生 (その3)
問題：
サーバダウン！
問い合わせが入る前に対応したい！
アクション：
”Health Check”
監視ツールの死活監視機能と通知機能を使用

25. Health Check
Amazon
ec.clouddesignpattern.org
Route 53
EIP EIP
本番
環境
EC2 EC2
インスタンス インスタンス
Ping等で定期的にチェック
正常応答が無い場合はアラートメール

26. 問題発生 (その4)
問題：
サーバは生きているがhttpd やmysqldのみ
ダウン！
すぐに対応できるようにしたい！
アクション：
”Deep Health Check”
監視ツールの死活監視機能と通知機能を使用して
アプリケーションの動作をチェック

27. Deep Health Check
Amazon
ec.clouddesignpattern.org
Route 53
EIP EIP
本番
環境
EC2 EC2
インスタンス インスタンス
HTTPでDBアクセスまで行うページを
定期的にチェック
正常応答が無い場合はアラートメール

28. Deep Health Check
メリット
チェック対象のコンポーネントを一度に監視可能
システムレイテンシのチェックとしても利用可能
注意点
チェック対象のコンポーネントを全て使うチェック
ページの用意が必要
システムに余分な負荷をかけないようにチェック間隔
に気をつける

29. 問題発生 (その5)
問題：
サーバに障害発生！
速やかにサーバを自動復旧したい
アクション：
“Server Swapping”
以前取得したマシンイメージから別サーバを起動
(壊れた)本番環境の最新データを持つディスクを
移行して、復旧実施

30. Server Swapping
サーバに障害発生 EIP
EIP
仮想 仮想
サーバ起動
サーバ サーバ
データ
EC2 マシン
インスタンス
イメージ
仮想ディスク 仮想ディスク
監視サーバが障害を検知したら
APIでサーバ入れ替え処理を自動実行

31. Server Swapping
メリット
APIを活用しクラスタソフトの様な機能を実現可能
様々なサーバに適用可能
注意点
APIの習得・実装が必要
障害発生の判断条件を慎重に行う必要あり
（敏感すぎるとSwapが発生しすぎてしまう）

32. 問題発生 (その6)
問題：
Webサーバが落ちても、システム全体で
稼働し続けるようにしたい。
DBサーバの運用管理も楽したい
アクション：
“Multi-Server”
Webサーバを冗長化し、単一障害点を削減
DBサーバを、RDSに変更

33. Multi-Server
Amazon
Route 53 ec.clouddesignpattern.org
Amazon CloudWatch
ロードバランサ
EIP
オリジ 冗長
ナル 構成
EC2 EC2
インスタンス インスタンス
EC2
インスタンス
MySQL DB
インスタンス

34. Multi Server
メリット
可用性が向上する構成
DB,ロードバランサーの運用負荷も低い
注意点
RDS・ELB(ロードバランサー)の性能監視は
CloudWatchで行う
Webサーバ追加の度に監視ツール側にも設定が必要

35. 問題発生 (その7)
問題：
DBサーバをRDSにしたことで、
性能監視がCloudWatchと
監視サーバ画面に分かれて面倒
アクション：
“Monitoring Integration”
CloudWatchの監視メトリクスを監視サーバに取
り込んで一元可視化

36. Monitoring Integration
Amazon
Route 53 ec.clouddesignpattern.org
Amazon CloudWatch
ロードバランサ
EIP
オリジ 冗長
ナル 構成
EC2 EC2
インスタンス インスタンス
EC2
インスタンス
MySQL DB
インスタンス

37. Monitoring Integration
メリット
CloudWatchのメトリクスとその他のメトリクスを監視
ツール上で一元管理可能
CloudWatchのメトリクスを任意の期間保存可能
（CloudWatch上では14日間)
デメリット
CloudWatch APIを使って、データ取り込み処理を
実装する
CloudWatch API コール料金が若干発生

38. 問題発生 (その8)
問題：
Webサーバの台数を増やすと
DBサーバの性能がネックに。。
アクション：
“Scale Up”
DBサーバの過負荷状態を検知すると、API
を使ってインスタンスサイズを自動で変更

39. Scale Up
Amazon
Route 53 ec.clouddesignpattern.org
Amazon CloudWatch
ロードバランサ
EIP
オリジ 冗長 冗長
ナル 構成 構成
EC2 EC2
インスタンス インスタンス
EC2
インスタンス
MySQL DB
MySQL DB
インスタンス
インスタンス
監視サーバが障害を検知したら
APIでサーバ入れ替え処理を自動実行

40. Scale Up
メリット
Web/APサーバのスケールアウトに追随してキャパシ
ティ調整可能
Scale Downについても同様の仕組みで実現可能
注意点
RDSの場合 インスタンスサイズ変更で5分程度停止す
るのでタイミングを考慮したり、DB接続できない場合
はSorryページを出すようにアプリケーションを作りこ
むなどの工夫が必要

41. 問題発生 (その9)
問題：
Webサーバの台数を増やすと
ログが分散して確認しにくい
アクション：
“Log Aggregation”
各サーバのログを集約して蓄積。
障害発生前後の状況・原因の特定等に利用

42. Log Aggregation
Amazon
Route 53 ec.clouddesignpattern.org
各サーバのログを、ログサーバに転送集約・蓄積
ログ内容の監視も行い、
パターンマッチしたらアラート通知
ロードバランサ
EIP
オリジ 冗長
ナル 構成
EC2 EC2
インスタンス インスタンス
ログは最終的にS3に保存
長期保存ならGlacierに

43. Log Aggregation
メリット
多数のインスタンスに散らばったログを集約して管理
ローカルログは適宜rotateして改廃しディスク節約
注意点
ログ送信Agent、ログ収集サーバの導入運用が必要
集約したログを失わない工夫が必要(S3へ移動、等）
ログの内容監視する場合は、ログフォーマットについ
てアプリケーション開発者と事前に仕様を決めておく

44. 利用ソフトウェア
syslog (syslog-ng, rsyslog)
Fluentd
Flume
Scribe
Zabbix
swatch
logmon

45. 運用監視のまとめ
監視対象によって方法・内容が異なる
オンプレミス EC2 サービス
(RDS,etc)
アプリ監視 要 要 要
性能監視 要 要 要
プロセス死活監視 要 要 不要
OS死活監視 要 要 不要
H/W死活監視 要 不要 不要
監視内容が少ないサービスは運用コストが低い

46. オンプレミスの運用監視
 アプリ性能/死活監視
 リソース監視
 死活監視 Application
(ログ,プロセス,OS)
アプリチェッ
ク
Middleware
OS
Agent経由等の • システム導入/拡張時
情報収集 の作業
• 保守切れによるH/W
SNMP/MIB の入れ替え。
Server/Storage • ファームウェアバー
SNMP Trap ジョンのチェックと維持
Network • 障害時の原因調査お
 H/W監視 よび復旧作業
 サーバ・ストレージ Appliance
 ネットワーク
 アプライアンス機器 Data Center
 電源・帯域

47. EC2の運用監視
 アプリ性能/死活監視
 リソース監視 アプリチェッ Application
ク
 死活監視
(ログ,プロセス,OS)
Middleware
Agent経由等の
情報収集
OS
CloudWatch/
API/SDK
 Service Status監視
Alarm
 リソース監視
 ログ監視

48. サービスの運用監視
アプリチェッ
 アプリ性能/死活監視 ク Application
CloudWatch/
API/SDK
 Service Status監視 Alarm
 リソース監視
 ログ監視

49. まとめ
デザインパターンを活用し
システム規模・システム要件に合わせた監視シ
ステムの構築が可能に
APIで自動化することで性能維持・ダウンタイ
ム短縮を実現可能に
システムが拡大しても、運用者の負担を削減す
る自働化の仕組みづくりが可能に

50. まとめ (改善・革新)
今までできていたことを、
改善
より早く、簡単に、安く実現できる
今までできなかったことが
革新
実現できる

51. CDPでAWSをもっと楽しく

52. ご清聴ありがとうございました。
FACEBhttps://www.facebook.com/awscdp