tsalakh ain sus noam Huyah ol guf

勉強会のメモ。その他備忘録。参考にさせて頂いたサイトや資料はリンクさせて頂いていますが不都合があればご連絡ください。

【勉強会】freee×プレイド TechMeetup インフラ監視編

2017-01-19 【freee×プレイド】Tech Meetup インフラ監視編

これに行ってきた

plaidtech.connpass.com


freeeを支えるインフラ監視

freee @manabusakaiさん

speakerdeck.com

freeeで使っている監視サービスと、少人数運用のノウハウ

freeeで使っている監視サービス

  • サーバ監視
    • Mackerel:AWS+サーバ、DB
    • CloudWatch:AWS
    • Prometheus:サーバ
  • パフォーマンス監視
    • NewRelic:アプリ
    • MONyog:MySQL
  • ラッキング
    • Redash
    • Kibana

少人数(3/80人)運用

効率化しないと回らない!

情報はプルよりプッシュ

  • 必要な情報を一箇所に、Slack
  • botが日次でパフォーマンスサマリ報告
  • 止まってるサーバとか

フルマネージドサービスを活用

障害が起きることを前提にインフラ設計

サーバはAutoScalingで可用性担保 単一障害点を作らない リトライ・キューイングを前提としたコーディング

障害を避ける最も良い方法は、常に障害を起こすことである ーNETFLIX

本業にフォーカスする サービスをよくすることにフォーカス、それ以外にお金を使うのはあり Zabbix→Mackerel移行 Zabbix運用のコストがかからない、コストはペイした

様々なメトリックをトラッキングして見える化する 曖昧さを排除して、数値を元に改善サイクル


KARTEを支えるマルチプラットフォームインフラ監視

プレイド @ikemonnさん

speakerdeck.com

監視の目的

  • Startupはスピードが命
  • 多少の失敗を許容、ただしすぐ気付ける

インフラ構成

監視

課題

  • 別PFのインスタンス同士のメトリックを比較したい
  • 各PFに依存したメトリック送信のコードを書きたくない
  • 管理画面をたくさん開きたくない
    • →Datadogで一元管理

何を監視するのか

  • インフラの監視
    • CloudWatch、Stackdriver→Datadog→Slack、Pagerduty
  • アプリの監視
    • Runscope、STATSD、Bugsnag libray、logdna

どうやって監視するのか

  • Layerを分けてDashboardをドリルダウン設計
  • サービス死活
  • 重要なメトリック
  • 詳細メトリック
  • インスタンスごとのメトリック

アラート

Datadogで一元管理 Datadog、MCM、Runscope→閾値、異常値検知トリガー→Slack、Pagerduty Datadogは異常値検出が便利

はまり

コスト面 AWS起動遅い、AutoScaleで一括起動がしやすい GCP起動早い、AutoScaleで台数指定できない Datadogはホストあたり$18

メトリックの送信タイミングが想定と違う きちんと把握しておく


対談

@manabusakaiさん & @ikemonnさん

一つのサーバにメトリックを多すぎても見切れない サーバが落ちてもオートスケールで戻って来れば障害としない

閾値は職人芸

負荷が低すぎるのは、リソースの無駄という意味で障害という考え方 適切な負荷は? 日々の運用から傾向がわかってくると判断できる ソシャゲのような突発があるとつらい

ログの監視、Elasticsearch+kibanaからlogdnaに乗り換えた

モニタリングツールの辛いところ レンダリング速度、障害中に画面が遅いと辛い

Hack Everything 不満があったら自分で直す文化

監視はインフラ領域 モニタリングはアプリ領域

通知が多すぎてオオカミ少年になるのは? SlackはChannel分けてる、Critical/Incidents/Bug 深夜の通知は、ランダムで架電するスクリプト組んでたりする

失敗してせめる ヒューマンエラーをどう防ぐかは課題


grafana-zabbix 活用術

@kakakakakkuさん

speakerdeck.com

Monitoring&Alerting

  • Proactive Monitoring
    • ダッシュボードを見ながら予測
    • 「Zabbixスクリーン」→Grafanaにリプレイス
  • Reactive Monitoring
    • 閾値を超えたらアラートを飛ばす
    • 「Zabbixアラート」

Grafanaサーバにgrafana-zabbix入れればいい

Template timeShift


prometheus 監視で変わるもの

@sugitakさん

自前で建てる監視サーバのOSS ZABBIXの代わり

こみゅにてぃしさん、ドキュメント足りない

表はgrafana

古典的な監視は、見ないデータは取らない データは取れるだけ取る方針

監視ツールの使い方 Proactive/Reactive よく使うグラフだけ手が込んだ造りにする

グラフの描き方 必ずインサイトが得られるようにする 知りたい目的が、一目でわかるのがいいグラフ


プロセス生存確認サービス始めました

@narita-takeruさん

プロセスが動いてるかどうか、確認するサービス作った

cronから起動されるバッチ処理、とか メール送信系のバッチとか

サーバに直接入るなんてダメ

通常のバッチの前後に、通知入れる 終了通知がこなかったりしたらSlackに通知