AWS Summit 2015 - Day2 - AWS System Operation Deep Dive
システム運用で考えるポイント
- クラウドだからといって考える事の基本は同じ
- Monitoring
- 死活監視
- キャパシティ監視
- Logging
- 誰が、いつ、どのような変更をしたのか
- Configuration
- 構成管理
- Chef / Puppetとかの個別の構成ではなく、システム全体の構成の話
Monitoring
CloudWatch
- AWSのリソース監視
- 死活・性能・ログ監視
- メンテナンスイベント
- 他にも、課金状況の監視など
何がオンプレと違うか？
CLIから情報を引っこ抜いてきて情報を持ってくることができる
CloudWatchと監視ツールの線引と連携
責任共有モデルの範囲か否か、で分けたりするのがひとつの手
- カスタムメトリクスを使えば、CloudWatchだけで監視することもできる
定期メンテナンスの時にアラートを出したくない、とか
オンプレミスの環境と組み合わせながら、やっていったりするのが効率が良い
Mackerel / DatadogなどでSaaSで監視してしまうのも手
Sensuを使ったモニタリング例
- RappidMQを使ってスケール
- SSLを使った通信でセキュアに
CloudWatch Log
- エージェントがLogをendpointに送る
- 1回あたりのpushは32KB まで
- それを超えるとログがトランケートされる
- そのメッセージしか残らない
- ログのカット等をアプリ側で実装する必要がある
- 対応しているローテーション
- rename and re-create
- copy and truncate
- ceate common-patterned file
- poort毎に異なるファイルに書き込まれるようなパターンのログは追えない
- ログの転送設定
- file_fingerprint_lines
- デフォルトでは1
- 1行目は必ず同じになる！という場合には上手く動かないので、この辺を変える必要がある
- file_fingerprint_lines
Logging
CloudTrail
利用ケース
- 検知
- 何かあったらすぐ知りたい
- 検索
- かつて何があったか調査したい
- 可視化
- トレンド
- 検知
CloudWatch Logs Metrics Filterの利用
- CloudTrailのログをCloudWatch Logsにどんどん投げ込む
- CloudFormationのテンプレートが公開されている
CloudTrail API Activity Lookup
- 直近7日間のログが閲覧できる
- ただし、CloudTrailのサポートするサービスをすべて見れる、というわけではない。注意
CloudSearch, Lambdaとの連携
- S3にup されたCloudTrailのログをLambdaが検知してCloudSearchに流す
ElasticSearch, Kibana, Lambdaの連携
- S3に入ったのをLabmdaが検知し、それをElasticsearchに流し込んでKibanaで表示
splunkでもとかでも可視化可能
短期、中期、長期の目的に依って使い分ける
Configuration
AWS Config
- 構成変更を記録して、変更の記録
- ヒストリとして残す
- 今の状態をスナップショットとしてのこす
- 構成変更を記録して、変更の記録
リレーションシップ
Logstorage
