• Like
[AWS Summit 2012] クラウドデザインパターン#6 CDP クラウド監視編
Upcoming SlideShare
Loading in...5
×

[AWS Summit 2012] クラウドデザインパターン#6 CDP クラウド監視編

  • 4,158 views
Uploaded on

クラウドデザインパターン#6 …

クラウドデザインパターン#6
CDP クラウド監視編

登壇者名・社名 松尾 康博(アマゾン データ サービス ジャパン 株式会社)

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,158
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
101
Comments
0
Likes
20

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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でノウハウを共有WIKIhttp://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/newshttp://www.flickr.com/photos/mutsmuts/4695658106/
  • 14. クラウドの可用性 故障することを前提に考える Design for Failure 可用性の2つの指標 MTBF: Mean Time Between Failure MTTR: Mean Time To Repair 可用性を高める2つのアプローチ MTBFを長く:アプリケーション・アーキテクチャ MTTRを短く:クラウド+監視+API+自動化
  • 15. ec.cloudesignpattern.org
  • 16. 初期のデザイン Amazon ec.clouddesignpattern.org Route 53 EIP 本番 環境 EC2 インスタンス
  • 17. 問題発生 (その1)問題: お客様から「遅い」と言われないように、 システム負荷を簡単に確認したいアクション: ”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 EC2CPU負荷 インスタンス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.orgAmazon 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.orgAmazon 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.orgAmazon 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