JAWS-UG沖縄 Cloud on the BEACH 2015発表資料

1. Sensu
2015.4.25
cloudpack
JAWS-UG 沖縄
Cloud on the BEACH 2015
テクニカルトラック

2. 自己紹介
☁岸上 健太郎
☁アイレット株式会社 cloudpack事業部所属
– cloudpack二年生
– セクションリーダー
☁AWS認定ソリューションアーキテクト
アソシエイトレベル
☁好きなAWSのサービス

3. アジェンダ
☁cloudpackを支える監視ツールの紹介
☁Sensu 導入のきっかけ
☁Sensu Server成長期
☁Sensuの恩恵
☁tips

4. cloudpackで利用している監視ツール

5. 監視対象のEC2
600
2014/6 2015/4
＞60
※AWSのマネージドサービスも監視してるので、それらを含めるともっとあります

6. Check Dashboard - Uchiwa

7. Metrics Dashboard - Grafana

8. Notification

9. Sensu監視環境の全体像
Sensu Serverのバージョンは0.12
Sensu Clientは0.12 – 0.17まで混在
監視対象クライアントは全てstandaloneモードで動作している
各クライアントが自身のcheck結果をSensuのエンドポイントであるRabbitmqへ通知

10. アジェンダ
☁cloudpackを支える監視ツールの紹介
☁Sensu 導入のきっかけ
☁Sensu Server成長期
☁Sensuの恩恵
☁tips

11. Sensu導入のきっかけ
支えられるの！？
☁Blue-Green Deployment

12. 監視設定どうする問題
☁デプロイの度に最初から監視設定しなおす
ことになるのでは・・
– Nagiosのパッシブチェックつかってみる？
– AMIに組み込んで起動時のcloud-initで色々..?
誰かが言った
Nagiosでの管理も限界近いし、
今の仕組みを流用することに
悩むならSensuを使ってみよう

13. 新監視システム要件
☁ 監視クライアント自身がチェック結果をサーバへ通知するパッシブ
チェック
– SensuならStandaloneモードがあるよ
☁ 監視設定・管理が自動化なり単純化ができること
– SensuならChef LWRPがあるよ
☁ Sensu ServerへのClient登録名をrecipe(attribute)に書きたくない
– ssh_configのHost文字列+Instance IDを結合してノード名を登録
☁ 複数のAWSアカウントで稼働するEC2/RDS等を監視,メトリクを収
集・一元管理ができること
– sensu community pluginがあり,Graphite用のHandlerもある。さらに
Rubyistな同僚とPJを担当することになので何とかなりそう

14. 導入ツールの壁
☁Chefの学習コスト..全員が書けるようにな
る前にリリースを迎えてしまう
– そうだJenkinsおじさんにおまかせしよう

15. やってみた
☁Sensuの監視設定はChef soloを利用
– Jenkinsジョブでデプロイ時に起動されたインスタ
ンスをAWS Tagより判別し、Jenkinsサーバから並
列でknife solo cookを実行する

16. 進むSensu化
☁ 主な監視設定
– EC2内のOSやミドルウェアはCommunication plugionsを利用
☁ Cloudwatchメトリクスの値
☁ AWSコンポーネントのCloudwatch MetricsはIAM Roleを付与したインス
タンスで収集すると安全
– Check: https://github.com/y13i/sensu-plugin-check-cloudwatch
– Metrics: https://github.com/y13i/sensu-plugin-metrics-cloudwatch

17. アジェンダ
☁cloudpackを支える監視ツールの紹介
☁Sensu 導入のきっかけ
☁Sensu Server成長期
☁Sensuの恩恵
☁tips

18. Sensu Server成長期(~100台)
☁Sensu Serverはc3.large*1でスタート
– 監視クライアント100台あたりから通知が遅
れる事が時々発生
– c3.large*2に変更

19. Sensu Server成長期(~300台)
☁またSensu ServerのLoad Average上昇
– c3.xlarge*2に変更
☁大規模用監視設定に一部Chef Zero導入
– クライアントツールをknife-soloからknife-
zeroに変更
– 100ノード以上でもChefのSearch機能で容易
に監視設定・変更することも可能に

20. Sensu Server成長期(~600台)
☁またまたSensu ServerのLoad Average上昇
– c3.2xlarge*2に変更
☁Sensu Serverのダウン
– Sensu Serverの1台が停止(Status Check 0/2)
− 残った1台にに負荷が集中する
− Checkと通知遅延が発生
− 一時的にインスタンスタイプを変更して遅延を
解消

21. アジェンダ
☁cloudpackを支える監視ツールの紹介
☁Sensu 導入のきっかけ
☁Sensu Server成長期
☁Sensuの恩恵
☁tips

22. Sensuの恩恵
☁定義/管理方法の統一
– ChefのSensu LWRPのお陰で監視設定構文を統一化
できた
– BerkShelfと組み合わせて共通/環境固有毎の管理がで
きるようになった

23. Sensuの恩恵
☁ Grafana
– Sensu Graphite Handlerで収集したメトリクスを配置できる
– サービス全体のリソース状況を容易に閲覧
– Cloudwatchよりも長い期間の情報を保持しているので過去のリソース状況から、
運用しているサービスのリソース予測をしやすくなった

24. アジェンダ
☁cloudpackを支える監視ツールの紹介
☁Sensu 導入のきっかけ
☁Sensu Server成長期
☁Sensuの恩恵
☁tips

25. Sensu Serverの冗長化手段
☁ Sensu Server/Sensu API
– ノードは分割せず1EC2に同居が良い
– /etc/sensu配下に同じ定義を入れるだけ
– Standaloneモードであれば600クライアントの監視はc3.2xlarge*2~が目
安
☁ Redis
– クライアントのStashを記録する
– cache.m1.smallで十分
– インスタンス障害リブートが発生するとStashが解除されるので注意
☁ RabbitMQ
– Queue Mirroringで冗長化している
– MQの負荷は低いのでm1.smallで十分
– エンドポイントの監視はRoute53 failoverを利用

26. Sensu Clinet & Grafana tips
☁Sensu Clientのtips
– sensu-clientのcheckはfork型なので負荷が高い
– m3.medium等のvCPU1つのインスタンスはcheck実行時
にsteal%が大きく上昇する
☁定義変更後再起動が必要
– sensu-client, sensu-serverで利用するcheck定義やハンド
ラを更新した場合はプロセスの再起動が必要
☁Grafanaの辛い所
– 現在利用しているバージョン(v1系)はユーザー認証がな
い、お客様と共有したくてもできない、2015/4にリリー
スされたv2から認証機能があるみたいなので検証したい

27. Sensuを使ってみたい方へ
☁ 実際に運用しているなかの人に聞く
– cloudpackの中の人
☁ Sensu
– http://sensuapp.org/
☁ Sensu Plugins
– New Community Plugin(最近Gemで入手できるようになった)
– http://sensu-plugins.github.io/
– Community Plugin
− https://github.com/sensu/sensu-community-plugins
– cloudpackメンバー謹製Plugin
− https://github.com/y13i/sensu-plugin-metrics-cloudwatch
− https://github.com/y13i/sensu-plugin-check-cloudwatch
☁ Grafana
– http://grafana.org/
☁ Jenkins
– https://jenkins-ci.org/
☁ Chef, Berkshelf, knife-zero
– https://www.chef.io/chef/
– http://berkshelf.com/
– https://github.com/higanworks/knife-zero