Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Stackdriver を利用した実戦的なサーバ監視・運用方法

138 views

Published on

MSP 企業が語る「 Stackdriver 」を利用した実戦的なサーバ監視・運用方法

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Stackdriver を利用した実戦的なサーバ監視・運用方法

  1. 1. MSP 企業が語る 「 Stackdriver 」を 利用した実戦的な サーバ監視・運用方法 原岡 昌寛 代表取締役, 株式会社ビヨンド 2018/9/20 Copyright © 2007-2018 Beyond Co., Ltd. All Rights Reserved.confidential
  2. 2. 原岡昌寛 株式会社ビヨンド 代表取締役 Google Certified Professional Cloud Architect Oracle DBAから LINUXベースのインフラエンジニアへ Speaker
  3. 3. Agenda 1. 会社紹介 2. Stackdriver について 3. 他の監視ツールとの違い 4. Stackdriver と運用監視
  4. 4. 1 会社紹介
  5. 5. ビヨンドについて 会社紹介 ■ 会社名 株式会社ビヨンド ■ 設立年月日 2007年4月4日 ■ 事業内容 ・サーバー事業 ・システム開発事業 ・Webサービス事業
  6. 6. 主な事業内容 主な事業内容(サーバ事業) ■ サーバー構築/24時間365日 のサーバー監視と運用(MSP)
  7. 7. 主な事業内容 主な事業内容(システム開発事業) ■高負荷・高可用性・低レイテンシなど、 ご要望に応じた API開発
  8. 8. 主な事業内容 主な事業内容 主な事業内容(Webサービス事業)
  9. 9. 2 Stackdriver について
  10. 10. Stackdriver とは Google Cloud Platform(GCP)の運用監視ツール アプリケーションのモニタリングサービス マルチクラウド環境の監視 エラー検知・分析、デバッグ
  11. 11. Stackdriver の特長 GCP 環境でのネイティブ統合 GCP 、AWS の監視を統合して行える 各種クラウドサービスとの連携 (Slack、PagerDuty) モニタリングを数分で簡単に開始できる アプリケーション開発の効率化 スマートなデフォルト設定
  12. 12. Stackdriver が提供する機能 機能 概要 Stackdriver Monitoring メトリクス監視、指標・イベント収集、ダッシュボード、グラ フ、アラート Stackdriver Logging ログデータ・イベントの検索・分析・モニタリング・通知、公 開API Stackdriver Error Reporting クラッシュをカウントして、分析と集計を実施、エラー管理イ ンターフェース、エラー詳細 Stackdriver Trace 分散トレース システム、レイテンシ データ収集、パフォーマ ンス分析 Stackdriver Debugger リアルタイム アプリケーション デバッグ、本番環境のコード 分析
  13. 13. Stackdriver のアカウント管理
  14. 14. Stackdriver の使いどころ GCP 環境 ・Google プロダクトのネイティブ統合 BigQuery、Cloud Pub/Sub、etc AWS とのマルチクラウド環境 ・可用性向上のためのバランシング ・適材適所によるパフォーマンス向上 BigQuery、Cloud Bigtable ・コスト削減
  15. 15. インフラエンジニアから見たいいところ ・GCP / AWSの両方が監視可能 ・WEB/Applicationの外形監視のレイテンシ が世界各国から見える ・BigQuery と連携(BQ利用状況を視覚化) ・Kubernetes ネイティブである (Kubernetesのノード、ポッド、デプロイメントのメトリクスを収集する) ・advanced logs filter(高度なログフィルター)
  16. 16. 3 他の監視ツールとの違い
  17. 17. ビヨンドで主に利用している監視ツール Stackdriver CloudWatch Mackerel Zabbix Nagios
  18. 18. Cloudwatchとの違い ■ CloudWatch ・対象:AWS ・メトリクス:死活、ログ ・通知方法: Amazon SNS ・データ保持期間:2週間 ■ Stackdriver ・対象:GCP / AWS ・メトリクス:死活、プロセス、Web、ログ、トレース、デバッグ ・通知方法:メール、Webhook、Slack、PagerDuty等 ・データ保持期間:6週間
  19. 19. mackerel との違い ■ Mackerel ・対象:AWS/クラウド/オンプレミス ・メトリクス:死活、プロセス、Web、ログ ・料金:1ホスト1800円~ Trial 14日間 ・通知:メール、Webhook、Slack、PagerDuty、TypeTalk、ChatWork ・データ保持期間:460日 ■ Stackdriver ・対象:GCP / AWS ・メトリクス:死活、プロセス、Web、ログ、トレース、デバッグ ・料金:無料プラン/有料プラン ・通知方法:メール、Webhook、Slack、PagerDuty等 ・データ保持期間:6週間
  20. 20. Zabbixとの違い ■ ZABBIX ・対象:クラウド/オンプレミス ・サーバ:必要 ・通知方法:メール(カスタムで多種の連携も可能) ・料金:サーバ費用 ・データ保持期間:特に制限なし(指定した分だけDBに蓄積) ■ Stackdriver ・対象:GCP / AWS ・サーバ:不要 ・料金:無料プラン/有料プラン ・通知方法:メール、Webhook、Slack、PagerDuty等 ・データ保持期間:6週間
  21. 21. image Webサイト監視サービス アプミル ● GCP 環境で構築 ● Webの外形監視のみのシンプル設定 ● エンジニア以外の利用を想定 ● URL設定だけで通信、コンテンツ、 セキュリティのチェックが行える https://appmill.work
  22. 22. GCP でのアプミルシステム構成 Cloud Storage Compute Engine Cloud Load Balancing Cloud SQL Cloud Datastore Cloud Pub/Sub Cloud Functions Logging Error Reporting Monitoring
  23. 23. 4 Stackdriver と運用監視
  24. 24. Stackdriver でのアプミル監視設定 監視項目 間隔 閾値 CPU使用率 1分 平均90%以上 CPU LoadAverage 平均5以上 Memory使用率 平均90%以上 Swap使用率 平均20%以上 ディスク使用率 平均80%以上 DB接続数 1分当たりの平均100以上 OSログ 常時 syslog ミドルウェアログ Nginx アプリケーションログ プログラムエラーログ
  25. 25. 運用監視のポイント 1. 対応速度 2. コミュニケーション 3. 対応スキル 4. 情報共有
  26. 26. 1.対応速度 アラートにどれだけ素早く対応できるか ・サーバへの素早いアクセス ・関係者への連絡 ・サービスの動作確認 ・切り分け ・一次対応
  27. 27. アラート内容のカスタマイズ ・素早い対応はアラート内容の工夫から ・メール文言のカスタマイズで障害箇所への 素早いアプローチ Alerting / Policies / Create / 3Documentation マークダウン方式
  28. 28. アラートノイズを減らす ・重要でないアラートが増える ⇒オペレーション担当者の疲弊 ⇒重要なアラートに気付かない ・まめなメンテナンス 閾値の変更 Alerting / Policies / Edit 時間の調整
  29. 29. サードパーティ連携 主要なオープンソースをサポート エージェントをインストールし ミドルウェア設定とエージェント再起動 Apache Nginx MySQL Memcached Redis Elasticsearch
  30. 30. 2.コミュニケーション ・関係者との素早いレスポンス(チャット) ・日々のやり取りで安心感を持ってもらう ・電話を恐れない ・顔の見える環境で信頼関係を作る
  31. 31. チャット連携 アラート対応にはチャットの通知が有効 Slack 連携でログを残す 過去データの検索 対応速度のアップ Pagerduty との連携も
  32. 32. アプリケーションログ ログエージェントのインストール install-logging-agent.sh アプリケーションログからエラー検知 するためには開発者の協力が必要 緊急度の高いエラー、対応の流れなどを 事前に決めておく
  33. 33. 3.対応スキル ・サービスの動作確認 サービスを知ること、コンテンツを見る ・切り分け ネットワーク?OS?ミドルウェア? ログ、グラフを読み取る ・一次対応 正しい根本原因解決より、素早い暫定対応 ・二次対応 再発に備え根本原因を解決する
  34. 34. 監視フローの作成
  35. 35. 4.情報共有 ・24時間365日は一人では見れない ・対応のばらつきをなくす ⇒ マニュアル化、訓練 ・アラートをためておく ⇒ 過去の事例の共有、検索 ・正確なデータを保つ ⇒ データのメンテナンス
  36. 36. アラートのレベル分け Aランク サービスが止まっている可能性が高いため最優先で対応 Bランク このまま放置しておくとサービスが止まる可能性が高いため優先的に対応 Cランク すぐにサービスに影響が出る可能性はないが対処が必要
  37. 37. アラート発生頻度を集計する 監視項目別 ランク 件数 割合 Ping監視 A 9 1% 37% ポート監視 A 152 18% URL監視 A 145 18% ロードアベレージ監視 B 6 1% 53% CPU監視 B 310 38% メモリ監視 B 4 1% プロセス監視 B 114 14% SWAP監視 C 35 4% 10% ディスク使用量監視 C 51 6% 合計 826 (2018/某月の実績)
  38. 38. 上位アラートの発生頻度 アラート別統計 A B C 総計 306 434 86 上位10件合計 82 204 0 割合(%) 26.7% 47.0% 0% (2018/某月の実績)
  39. 39. 上位アラートの解決 ・発生数の多いアラート10件は 全体の7割以上になることも ・月ごとに統計を取り上位アラートから 優先順位を上げて根本解決していく
  40. 40. Copyright © 2007-2018 Beyond Co., Ltd. All Rights Reserved.confidential まとめ ● Stackdriver は運用管理者にとって非常に有用 ● 環境によって使い分けを ● アラート対応の工夫によってより良い運用を!

×