可視化から始めるDevOps〜 可視化が大切な理由 〜

2016/07/02 Innovation EGG 第8回

自己紹介

青池　利昭

　▷ 兵庫県尼崎市出身

　▷ cloudpack 大阪で MSP開発 やってます

　▷ お酒が大好きです！！

　▷ facebook: aoike.toshiaki

facebookでC3(Can Convenience Club) やってます！

アジェンダ

❏ 可視化とは？

❏ 可視化の取り組み

❏ アラートの可視化

❏ 可視化の先には

ー 可視化とは？ ー

可視化とは？（Wikipediaより）

可視化とは、人間が直接「見る」ことのできない現象・事象・関係性を「見る」ことのできるもの（画像・グラフ・図・

表など）にすることをいう。

視覚化・可視化情報化・視覚情報化ということもある。英語の "visualization", "visualize" に相当し、そのままビ

ジュアリゼーション・ビジュアライゼーションと称されることもある。

流れの可視化のように分野や領域に結びついて生まれた呼称も多い。

ー 可視化の取り組み ー

現状

❏ AWS上で数千のサーバーを運用

▷ 24365で運用してます！

❏ 昼夜と合わず上がってくるアラート

▷ アラートはコチラの都合などお構いなし

❏ サーバーの増加 ≒ アラートの増加

▷ サーバーが増えるとアラートも増化

課題

❏ サーバーの増加 ≒ アラートの増加 ≒ Ops の負担増加

▷ アラートが発生すると Ops は対応を行う

▷ サービスはどんどん増えていく為、Ops の負担も増

対策

❏ アラート通知の最適化

▷ 不要なアラートは（とりあえず通知）は発生させない

▷ 本当に必要な対策が必要なアラートに絞る

対策

現状を 見える化 し 改善ポイント がないか分析

ー アラートの可視化 ー

発生件数を時間単位で集計

発生件数を時間単位で集計

どの時間帯もアラートが上がってきている

一日の発生件数

一日の発生件数

突出しすぎ！

ちょっと多くない？

カテゴリ（傾向）を可視化

カテゴリ（傾向）を可視化

このアラートの傾向が多い

可視化して見えきた物

❏ 全時間帯でアラートが発生し、突出した件数

▷ サーバーが負荷に耐え切れていない？ 慢性的な リソース不足 ？

▷ アクティブユーザーの 増加 による リソース不足 ？

▷ アラートの 閾値 が厳しすぎる？

▷ キャンペーン等で スパイクアクセス が発生している？

❏ 発生系統のカテゴリが特定の物に振れている

▷ 外部要因（たとえばネットワーク障害など）が発生している

アラートの量や傾向が見えることで

原因を分析する材料

となる

傾向が見える事で

どういった対策が効果的なのか

検討しやすい

見えることにより

対策をしないといけない

という気持ちにつながる

対策の結果が目に見えると次への

モチベーション

に繋がる

アラート可視化のまとめ

❏ 現状の状況把握

→ アラートの多いサービスの特定

→ アラート傾向を明確化

▷ 改善施策の立案に必要な情報

❏ 改善実施後の状況把握

→ アラートの件数がどのように動いたかを確認

▷ 改善施策の妥当性の確認

ー 可視化の先には ー

たとえばこんな事が出来るのでは？

❏ ルーチンワークを自動的に処理する

▷ 手間ばかり取られる作業を自動化

❏ サーバーリソースの状態取得を自動化

▷ 問題発生時の初動のフォロー

❏ 状態により予め指定したアクションを実行

▷ 作業負担の軽減と作業精度の均一化

❏ アクションの学習と予測

▷ 最適なアクションの提案

自己紹介

高橋　慎一

可視化の先？

可視化の前

の話をします

可視化の前 is … ?

100%使う!!

100%使う!!

仕組み

仕組み

あるある

・設定忘れ・設定間違え・PDサービスダウン

...

あるある

・設定忘れ・設定間違え・PDサービスダウン

...

差分

100%使う!!

差分検知

100%使う!!

差分検知の先

100%使う!!

監視の監視

監視システムを監視

SaaS ≒ クラウドネイティブでは

❏ 可視化するためにはデータの”ゆれ”があってはいけない

❏ 「必ず動く」を前提に考えない

❏ 　監視サービスを監視する必要

❏ > 100%に可能な限り近づける

最後に

cloudpack wants you !!

開発・インフラ・デザイナーを募集しています

https://cloudpack.jp/recruit/

ご清聴ありがとうございました