もうやめたい！
運用監視システムの運用監視

投稿日: 2020/08/21

はじめに

この記事を読もうと訪れてくださった皆さんはきっと運用監視に対して何らかの課題を抱えているか、もしくは現状よりももっとより良い運用監視について興味を持っていることでしょう。

筆者も運用監視には少なからず…いやかなり多くの課題を抱えており、この業界で仕事をして20年以上経ちますが、全く何も課題や問題のない運用監視システムというものに出会ったこともなく、まして自分でそのようなシステムを構築できたこともありません。
しかし、それでも様々なプロジェクトに関わり運用監視の仕組みを作り上げてきたなかで、常に感じてきた一番大きなことは「この運用監視システムでトラブルが起こりませんように」でした。

そのため、何もアラートが飛ばないと逆に心配になり、無駄に正常性を通知するようにしたりと、いったい何のために運用監視をしているのかわからなくなるありさまでした。

また、ときには運用監視システムを運用監視する仕組みを作ったりもして、その仕組みを監視するのをどうしようか？と迷走しだすこともありました。

では、この連鎖的な運用監視システムの運用監視をやめるためにはどんな方法が考えられるでしょうか？一つの解としては、自分で運用監視システムを運用するのではなく、監視SaaSを利用するという解決方法があります。
監視SaaSとは、運用監視のための各種機能をサービスとして提供するもので、有名なものですとNew Relic, Sysdig, Datadog, Mackerelなどがあり、いずれも月額千円から数千円程度で利用を始めることができ、またトライアルで試用でき気軽に試せるため、検証やPoCで試しに使ってみるといったことが容易にできます。

とは言え、「では今の運用監視システムを停止して、監視SaaSを早速利用しよう」と簡単に切り替えられないと思いますので、この記事では既存の運用監視システムからどのように監視SaaSにマイグレーションするか？について、監視SaaSであるDatadogを例に挙げて説明致します。

なお、運用監視に関する書籍はたくさんありますが、筆者はオライリー社から出版されている「入門　監視」（著: Mike Julian 氏、訳: 松浦隼人氏）をお勧め致します。
この書籍は運用監視に対する有意義なことが書かれておりますので、ぜひ一度目を通してみてください。

運用監視システムのマイグレーション手法について

昔のシステムであれば、システムの更改のタイミングで運用監視システムを一新することが一般的だったわけですが、クラウド時代と呼ばれる昨今では大規模なシステム更改のタイミングというのはあまりなく、どちらかというと既存のシステムを少しずつクラウドに移行する形のマイグレーションが多いでしょう。

よって、本記事では「既存のシステム」＝「オンプレ環境」とし「新規のシステム」＝「クラウド環境」という前提で進めます。というのも、既存のシステムがオンプレ環境でかつ運用監視システムだけ新しくするというケースでは「既存の運用監視システムのハードウェアやソフトウェアがEOSやEOLを迎えるために、運用監視システムを新しくしなければならない」という状況であるため、そのような場合はドラスティックに移行しなければならないケースが多いと思いますので、本記事ではクラウドリフトをする場合を前提とします。
では、そのような中で運用監視システムをマイグレーションするにはどのような手法があるのでしょうか？以下に代表的なマイグレーション手法を紹介致します。

新旧両立方式のイメージ

この方式は、既存の運用監視システムと新しい運用監視システム(Datadog)のどちらも利用しながらマイグレーションする方法になります。

この方式のメリットは既存の運用監視システムには手を加えずに、新規の運用監視システムとしてDatadogを用意し、既存のシステムを順次クラウドに移行するときにDatadogで監視し、既存のシステムが全てクラウドに移行し終えたのちに既存の運用監視システムがリタイアを迎えることで、環境の変化によるシステムに対する影響を少なくするという点です。
一方でこの方式のデメリットは、既存の運用監視システムと新規の運用監視システムのどちらからもイベントが発報されるため、運用管理者にとっては若干煩わしい運用になります。

オーバーラップ方式

この方式は、既存の運用監視システムが収集している監視データやアラートをDatadogに投げ、運用管理者はDatadogを参照する形で運用する方式になります。

この方式のメリットは、前述の新旧両立方式とは違い、日常業務において既存の運用監視システムを参照しなくて済むという点が挙げられます。既存の運用監視システムが外部に対して自身の保有する収集データを出す機能があれば理想的ですが、もしそのような機能がない場合でもアラートを発報する先をDatadogにするだけでもこの方式を実現できます。
一方でこの方式のデメリットは、既存の運用監視システムとDatadogという多段構成になるため、新旧両立方式に比べるとイベントの検知に若干のタイムラグが発生してしまいます。

Agent同居方式

この方式は、既存の運用監視システムには手を加えず、既存のシステムの各ホストに対してDatadog Agentをインストールし、監視データをDatadogに投げて管理する方式になります。「Agent同居方式」という名称なのは、既存のシステムの各ホストにインストールされている監視データ収集用Agentを置き換えるのではなく、追加でDatadog Agentをインストールする形であるためです。

この方式のメリットは、既存システムの各ホストの監視データ収集用Agentを置き換えるわけではなく、あくまでもDatadog Agentを追加するだけであり、マイグレーションの移行時期においてDatadogでの運用監視を確認しながら移行できるという点です。仮にDatadogでの監視が思うようにいかなくても、既存の運用監視システムを参照することで、移行期間においても今まで通りの運用監視が行えます。
一方でこの方式のデメリットとしては、既存システムのホストがDatadog Agentをインストールできない古いOSだったり物理装置（例えばネットワーク機器など）である場合はこの方式でカバーできません。

オーバーラップ＋Agent同居方式

この方式は、オーバーラップ方式とAgent同居方式を組み合わせた方式になります。

この方式は、オーバーラップ方式とAgent同居方式のどちらのメリットも受けられる反面、どちらの方式のデメリットも受けてしまいますが、マイグレーションの移行期間中は手堅い運用監視を行なえます。
また、この方式においては一見するとイベント発生時に二重管理および二重発報が懸念されますが、実際にマイグレーションする際にはホスト単位で既存の運用監視システムの発報を止めたりしながら進めることにより、細かな調整を行いながら移行することが可能です。

おわりに

運用監視システムのマイグレーションについていくつかの方式を挙げましたが、実際にどの方式を採用するかは、それぞれのシステムに応じて判断する必要があると思います。しかし、筆者がこれまで運用監視システムをマイグレーションしてきた経験で述べますと、マイグレーションを考えるうえで一番リスクを回避できるのがオーバーラップ＋Agent同居方式になります

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。