[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

正しく運用されているかを評価するのが監視である~ゼロからの運用監視設計(前編)。July Tech Festa 2016

2016年10月19日

運用監視の自動化は、複雑化するアプリケーションやサービスに対して効率的かつ確実な運用監視を実現する上で、またコスト削減の意味でも重要な要素になってきています。運用監視の自動化は、どのように考えて実現していけばいいのでしょうか。

7月24日に産業技術大学院大学で行われたイベント「July Tech Festa 2016」のセッション「運用自動化のための Re:ゼロから始める監視設計」は、そのための知見を得る上で大変参考になるものでした。この記事では、そのダイジェストを紹介します。

運用自動化のための Re:ゼロから始める監視設計

前佛雅人氏。

今日の私の話は、業界経験が豊富な方には当たり前すぎる内容かも知れませんが、自分だったら20年前にこれを知りたかったな、ということをまとめてみたつもりです。

fig

私はもともとデータセンターの運用をずっとやっていました。

最近ではテクニカルエバンジェリストなどをやっています。基本的には新しめの技術を検証したり情報発信したりしています。

今日話そうと思っていることはだいたいこんなことです。

fig

「自分はゼロから監視設計できます」と自信を持って言える人はいますか? 実はなかなかそういえる人はいないと思います。なぜかというと、ゼロから監視設計をするのは、知識があっても実際の運用経験がないとなかなかできないと思うからです。

なので、1つ目は監視設計するときにはこういうところに気を付けましょう、という話をします。

2つ目は、どうして私たちは失敗するのかという話です。どんなに対策をしても人は絶対に失敗をします。それを防ぐには手作業を減らす自動化しかないかなと思います。

3つ目は、自動化というとけっこう先走っている感じがありますが、そうではなくてこれまでの知識と経験を活かすための手段として自動化というものがあるのかなという考えを話そうと思っています。

正しく運用されているかを評価するのが監視

運用監視の設計と構築は、まずこういったシステムを動かしたいという目的があって始まります。

いわゆる「運用」といわれるものは、つねにシステムが正しく動き続けるためにあります。そして、そのシステムが正しく動いているかどうかを評価する仕組み、それが「監視」です。

監視ができないと、キャパシティプランニングだったり、障害発生時や通常ではない状態が発生したときのトラブルシューティングができません。

ですから、システムが正しく動いているかどうかを評価するものが監視である、ということを覚えておいてください。監視がないと運用が正しく回っているかどうかがわからないので、運用のために監視が不可欠なのです。

fig

これが、入社時に私が知りたかったことのひとつです。最初はこの運用と監視の関係や全体像がまったくわからなかったんですね。

当時は自社製の監視ツールで、WebサーバやTelnetのポートを関ししていました。しかし、ツールを使っているだけで、なぜなんのために監視しているのか分からなかったのです。

しかし、お客様のWebサーバなどのシステム運用をするという視点に立つと、こうした監視項目が必要なのは当然なのだろうということが後から分かってきました。

つまり、なにを監視すればいいのか分からないというときには、なにを運用するのか、という部分から考え始めると分かりやすくなるのではないかと思います。

逆に言えば、この運用監視ツールがいいぞ、という話から始まってしまうと、そのツールでできることだけに運用監視の幅が狭まってしまいます。本来あるべき運用監視に対して、このツールではこれしかできません、というのでは本末転倒です。

そういうことにならないように、気をつけなくてはなりません。

運用監視の歴史的変遷を振り返る

監視の歴史を少し振り返ってみます。

「監視第一世代」と呼んでいる時期には、Webサーバとデータベースサーバのつながりしかなかったので、これらの監視が中心だったんですね。

当時は1台のWebサーバに対して応答やネットワークトラフィックなどを監視していたので、NagiosやMRTGなどが使われていたと思います。

fig

第二世代では、いわゆるSNSの普及でいろんなサービスが登場し、それまでの監視では追いつかなくなってきました。

SNSなどでは、これまで想定しなかったトラフィックの集中や、想定しなかった不具合などが起きるようになります。例えば、よく分からないけど特定の時間にCPUの負荷が増えたりディスクI/Oが増えるといったことです。そこで時系列での監視情報の収集が始まりました。

fig

そしてクラウドなどに対応した第三世代になります。

fig

第一世代と第二世代の違いとして、グラフを通した監視の視覚化や、データ収集と通知の分離がはじまったのかなと思います。

そこで、監視ツールに対する考えも変わってきたんですね。Nagiosはあくまで設定値に対してアラートを出すのですが、Zabbixは時系列的にデータを収集する部分があります、そして収集したデータに対して評価する部分が分かれているんですね。

これで仮想化環境でも通用するようになってきたかなと思います。

サーバはペットから家畜へ

この10年の時代の変化を表すには、ペットから家畜へ、というキーワードが欠かせないと思います。

fig

ペットには名前を付けて大事にします。以前のシステムであれば、性能を高めるためによりよいサーバ、よりよいストレージを基本にしていました。

しかし最近ではスケールアウトで簡単に性能を高めることができるようになってきました。このことで監視にもかなり変化が起きてきたと思います。

このスライド(Architectures for open and scalable clouds)はとてもよくまとまっていますので、見てみるといいのではと思います。

≫後編に続く。後編では運用においてなぜ人は失敗するのか、そして自動化へのアプローチについて解説が進んでいきます。

あわせて読みたい

運用・監視 データセンター




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本