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