クラウド時代のサーバー監視における、良いメトリックの4要素 - Part1

クラウド時代のモニタリング

Masahiro Hattori 氏：DatadogもAzureの連携機能とかにかなり力を入れてやっているんですが、その前に、とくに最近クラウドだけではなくて、コンテナという話が進んできて、アーキテクチャの大きな変化が進んでいる状況です。日々お客さまと接していて、みなさまに共有できるような話題ということで、モニタリング、運用・監視の大枠みたいな話をしたいと思います。

Datadogは日本に今年からオフィスができまして、私は今3年目になるんですけれども、一応日本の社員の1号という感じで、オフィスは丸の内のWeWorkです。

ほかにDropboxさんやZOOMさんのリモート会とか、ああいう会社さんと同じ丸の内に入っていたり、いろいろな会社さんが入っているようなところです。そこに今年からオフィスがありまして、昨年末までほとんどひとりだったんですけれども、今月からは2人増え、3人増えという感じで、今WeWorkの13人部屋を借りて、年末までに埋めるぞ、みたいな感じでやっているので、おかげさまでぐいぐい来ているという感じです。

実は大阪から単身赴任しております。平日は東京に住んでいるんですが、休日は大阪に家族と住んでいます。実は子どもの運動会が午前中ありまして、それに出てから来る予定だったんですが、要所要所で園長先生が熱く語るというアクシデントがありまして、予想以上に伸びて5分押してしまい、申し訳ないです。

一番最初の仕事としては、HPのストレージ事業部でSEをずっとやっていました。クラウドが出てきて、仕事がなくなるなと思ってクラウドの世界、最初はAWSに行きまして、そのあと妻の仕事の都合で1年間スイスで悠々自適に主夫をしていたんですけれども、その時にDatadogが日本のオフィスをつくるというところで1人目の社員を探しているということでいい巡り合わせでDatadogに入り、そこから3年という感じです。

Datadogの概要

Datadogは最近少し露出が多くなってきたんですけれども、仕事としてはSaaSでサーバー監視とAPMとログ管理ツールの3つを一括で提供しているようなベンダーになっています。

オープンソースでエージェントが見れますよとか、1日当たり1兆のデータポイントとトレースを処理していますとか、得意分野としてはもちろんAzure Monitorとか、クラウドベンダーさんは必ず監視プラットフォームを持っているんですけれども、そこのAPIからデータをとってきて、よりビジュアル化するとか、分析のプラットフォームみたいなかたちで使ってもらえるようなものを提供しています。

最近は、技術畑ではない人にもお話を伝えやすくするために、情シスの方や運用開発の方向けのシステムのためのBIツールを提供しています、みたいな言い方もしたりします。

システムのためのデータプラットフォームなので、もちろんサーバー監視みたいなアラートも出ますけれども、ビジュアル化や分析に強みがあると、トラブルシューティングがめちゃくちゃ早くなるんですよ、と言ったりするような感じです。

Datadogの話はあまり多めにはしないので、もう少しだけお話すると、実は開発リソース、運用ツールはすごく必要でして、とにかくお客さまが使うものはなんでもサポートしないといけません。リクエストが上がるという感じなので、うちのAzureのサポートもありますが、メジャーなミドルウェアやクラウドに限らず、VMware、OpenStack、OpenShiftやRed Hatなど、どんどんサポートしていかなければいけないので、けっこうマンパワーのいるビジネスなんだなとやり始めて感じています。

監視ツールはけっこうコミュニティベースにサポートを任せるというか、協調するようなケースも多いですが、Datadogは自社で開発して品質を担保しないとサポートしますとなかなか言わないというところがあるので、そこが強み感じです。

実はAzure MonitorがGAした時、うちのCPOのミットという人間が、エコシステムのメンバーの1人として、Azure MonitorのGAを大変喜ばしく思っていますと。

DatadogのAzureのお客さまにもより高品質なAzureのモニタリングが提供できますよという話も言っていたりするので、そんなAzure MonitorとかAzure Insightsなどもそうですが、競合するというよりはそういった仕組み・データソースを使って、より高度なものを提供する・拡張させるというようなベンダーの立ち位置で、実はほかのベンダーさんともうまくやらせてもらっています。

とくに今年、Azure MonitorのAPIが拡張したのと同時に、Datadogもそれをしっかり使えるようにサポートしまして、Azure Monitorで外向きにAPIでとれるメトリックは全部サポートするかたちになることで、Azureの60超のサービスに対応するようになりました。

今までDatadogのAzure連携は、サービスでは10個ぐらいだったんですが、ほぼ全部になりました。

おいしいところとしては、Datadogは基本的にVMにしか課金しないので、いろいろなサービスをご利用されていると思いますが、そこには関係なく単純に60超のサービスのなかでVMの数だけしか課金しません。

ですので、とくにパース寄りの使い方をされていたり、サービスを多用していてサーバレスだというケースだと、ただ同然で使えるケースは普通にあるのでおすすめです。

サーバー監視、モニタリングにおける課題

では、本題に入ります。

何をお話ししたいかというと、実は私がDatadogに入った理由そのものなんですけれども、当時はAWSで提案したり、最初は技術営業部隊に入って、そのあとはずっと営業だったんですが、少なくともベンダー側、お客さまに提案する側は、どう導入するか、アーキテクティングのところにすごく比重を置いていて、そのあとどう運用するかはお客さま任せのところが実際ありますし、どう提案していいかを彼らもわかっていないということがあります。

そのあたり、自分ではもにょもにょしていて、どういったことが提案できるのかな、というタイミングでDatadogのCTO、CEOの方と会って、少なくとも邪悪な会社ではないのと、ビジョンがちゃんとしっかりしていたということでやってみようとなりました。

オンプレミス、VMAの仮想化環境から、パブリッククラウドの環境に行くという、まず大きなアーキテクチャの変更や変化があったタイミングでもそうなんですが、さらにVMからコンテナにアーキテクチャをどんどん変えていくタイミングでの運用の課題というところ。すごく単純なことですが、そこに対してざっくりいうとサーバー監視、モニタリングでどんな課題があるのかを話していきたいと思います。

少しその話題をご紹介したあとに、余裕があればDatadogのデモをできればいいかなという感じです。

抽象化されるインフラ

最初にお話ししたように、インフラはどんどん抽象化されています。

物理から仮想化されて、パブリッククラウドになっていて、さらにコンテナ化しています。

弊社のユーザーさんでも、ユーザーの監視しているサーバー台数は何百万台という感じなんですが、実はその20パーセントはコンテナホストしているというデータがあります。

そういった社内のユーザーさんの匿名化したデータを、毎年Docker採用レポートというかたちで公開しています。

ご興味があれば資料を公開するので見ていただければと思います。例えばそのなかの1つに、「Datadogのユーザーの4分の1はもうDockerを採用していますよ」と。

これはすごいスピードで、毎年40パーセントずつぐらい増えていっています。

ただ、この状況で言いたいこととして、とにかく運用に関しても、スケーラビリティとともに複雑さが増すという、当たり前のことなんですが、その要素として物量とスピードというところが大きくあると思います。それぞれがコンテナ化することで、はっきりとデータとして変化していると。

まず、物量というのはサーバーホストです。コンテナをホストしているサーバー当たりの集積度なんですが、現在1台サーバー当たりのコンテナは平均すると8台です。

ですがレポートを取り始めた3年前は5台でした。それが年々1.いくつずつ増えていって、どんどん集積されています。

この背景には、オーケストレーターを使うとどんどん自動化されていって、より集積度を高めてリソースをうまく使えていくという背景もありますが、少なくともコンテナをどんどん採用しているユーザーさんの傾向としては、1サーバー当たりのコンテナ数をどんどん集積させています。

コンテナ数も導入から加速度的に増えていますし、サーバーとコンテナが上がってから落ちるまでのライフサイクルの平均値で見ると、Datadogのユーザーさん全体で見て、VMは23日、コンテナの平均としては2.5日で9倍早いです。

Kubernetesのオーケストレータに管理されているコンテナでは0.5日というのがあったりするので、コンテナ化してオーケストレータを使いこなしていくほど、よりライフサイクルを短くしていくことになります。

そうすることで、今までサーバー1台で見てきたものを、その上にコンテナが8台乗るというかたち、単純に数が8倍になるだけではないんでが、少なくとも例えばCPU、メモリやネットワーク、ディスクI/Oみたいな、監視対象のメトリックという点でいうと、その数が8倍に近く増えていきます。見ているもの自体も爆発的に複雑化しているので、そこに対して新しいやり方が必要です。

このあとの話をもっとひっくるめて言うと、少なくともコンテナでなくても、クラウドネイティブなアーキテクチャをやっていくのであれば、より複雑性が高まる前提で、運用回りも普通考えるとは思いますが、監視ツールに関しても考えるところにはなるかと思います。

フォーカスすべきところ

その新しいやり方、今からDevOpsと言うと難しい話題になりそうなんですが、割と単純な話です。

こういう開発と運用を一緒にやるということではないですよとか、よくあるCulture、Automation、Metrics、Sharingという話で、運用ツールとしては後半のMetricsとSharingにフォーカスしています。

もちろん前段のCultureやAutomationも大事です。

これはアメリカで掘っ立て小屋を建てる時の効率的な建て方らしいのですが、おっちゃんがこうやってがんばって縄で支柱を立てるみたいな感じなんですけれども、いっさい近代的ではないですし、なにも自動化されてはいませんが、200年以上前から続くつくり方らしいです。

こうした文化でこういう人たちは割と短時間でさくっとつくりたいものをつくってしまう。別にツールは便利であったことに越したことはないんですけれども、Cultureを補強するために使うものであって、仮想マシンなのかコンテナなのか、Kubernetesなのかほかのオーケストレータなのかみたいな話の前に、こういったことも考えたほうがいいでしょうという、あるあるな話です。

ですので、Cultureがうまく回れば自動化をして、Automationがうまく効いて効率がグッと上がるみたいな話はもちろんありますが、よくある話で、そこも最終的にはやはり人がボトルネックになります。そこは大前提としてあるので、お客さまにマイクロサービス化をご提案させていただくような段階では、たいていのお客さまはそこにはもう気付いていらっしゃって、SREの組織をつくって、組織の構造・人の配置から変えてやろうとしています。

そして可視化とか分析とか情報の共有というところでDatadogとか監視ツールを考え直したいという相談があるので、そういったケースは別に何も問題ないんですけれども、うちのCultureは大事ですよと。

人が必ずボトルネックになるので、実際にイベントでぜひ話を聞きたいと言ってご提案しに行くと、実はすでにZabbixで弊社のビジネスはでき上がっていて、今さらそこを変えようとすると、組織ごと、ビジネスごと変えないといけないので、やっぱり無理ですね、みたいな話は実際にあります。

良いメトリックの4要素

ですが最終的には監視ツールなので、Culture、AutomationとSharing、情報共有のところはオッケーとして、Metricsです。

指標なりインデックスをとっていくところについてなんですが、ここもいったん整理しましょう。

例えば監視ベンダーの人間なので、お客さま先に行って監視環境を刷新したいと。本当に稀なんですけれども、Excelシートで全監視項目をずらっと渡されて、これを入れ替えたいみたいな話もあるので、そんな場合には前提から考え直しましょう、みたいな話をしたりします。

まず、けっこう昔からサーバー監視をやっていらっしゃったりすると、必要なものだけを物理でサーバーを立てているといったこともあるので、必要なものだけを集めるという前提があったりするんですが、クラウド環境ですし、そういう前提でいくとデータを集めること自体、保存すること自体は非常に安価なので、やってしまいましょう、とれるだけとりましょう。

ただ、それがないと、とたんに損失が出る。ないととたんに高価なものになるので、とにかくデータは全部入れる前提でやりましょう。

さらに、変化の激しい時代のなかで、いいメトリックという指標としてDatadogが考えてきたものがあります。いいメトリックの4要素を挙げてみます。まず、組織内で正しく理解されていること。

この絵は何なのかというと、20年ぐらい前、火星探査機のNASAの大失敗の例とかが挙げられていました。何かというと、火星探査機が火星に着陸するというところに、NASAとベンダーが2つ並んで、一緒に火星の探査プロジェクトをやっていたんですが、火星探査のプロジェクトで軌道を計算する単位が、一方はメートル法になっていて、もう一方はヤード・ポンド法になっていました。実はそれにプロジェクトを開始してから9ヶ月間気付かずにそのまま進んでいて、それが破綻して初めてあれっとなるという。

実際に探査機が壊れてプロジェクトが失敗してしまった事例もあります。実はそういうことが普通に起こりうるので、どんなデータを見ているかをまず共通認識として正しく持てているかが大事じゃないか、という感じです。

もう1つ、十分な粒度です。

この例では、コンマ2桁のデータでなければ、全部22秒になってしまう、順位がつけられません。これを監視ツールでいうと1秒単位なのか1分単位なのか5分単位なのか、丸めが入っているとピークに気付けません。

Azure Monitorもほかのクラウドベンダーの監視も、基本的に最初は1分単位でデータを持っているんですが、たいていの監視ツールは途中から丸めが入るので、そうなってくると、最初にピークがあれば上2つぐらいの粒度で見られますが、途中からほとんどわからなくなってしまう可能性もあります。例えば監視ツールなり監視データなりを見る時に、データの保存期間ももちろん大事ですが、粒度も大事になります。

タグ付けされてフィルタされる

3つ目はタグ付けされてフィルタが可能という話です。

タグ付けというのは、時系列データとして監視データは保存され、SYSTEM.NET.BYTES_RCVDということなので、ネットワークの受信のメトリックですが、何ギガバイト受信した、みたいなものです。

メトリック名があって、値が4とか、その時刻が時系列データなんですけれども、その状況を示すためのタグみたいな感じでメタデータがずらっとついているというのが理想です。

なんでこれが重要になるかという話なんですが、実際にモニタリングで使ったとするとこんな感じになります。

「’application:iisのスループットの平均値についてversionごとに値はどう違う？」という、タグがあればDBにクエリするかのようなかたちで問い合わせることができます。

なければ、従来からの監視ツールですと、基本的にサーバー単位で登録するので、あるサーバーグループの値はどうかという聞き方しかできないんです。

とくにコンテナ化したり流動的なシステムになってくると、そういう考え方だと逆に監視対象がざっくりでしか見られなくなっていて破綻しやすいです。

ここがかなり重要なポイントです。例えば監視ツールをクラウドネイティブファウンデーションのLandscapeというのがあって、そのなかで監視ツールはオープンソースのPrometheusが卒業プロジェクトとして出ています。Prometheusだとこれはタグというかラベルという言い方で使われていますが、Prometheusがこういう仕組みでモニタリングの構造を持っているかというと、サーバー単位で見る時代ではありません。

モニタリングしたい人はこういうかたちでデータのプラットフォームからDBに問い合わせるようなかたちで、スコープをタグで切って見るという使い方でやらないと、ざくっとしたアラートになるので、オオカミ少年化しやすいとか、そもそももうコンテナはサーバーごとで動いてしまうものなので、サーバー単位で考えるアラートの仕組みは破綻していますので、そういったものになっていたりします。

下も「’application:sql-serverを稼働している当社のrole:accounting-appのの毎秒のリクエスト数についてregion:east-usとregion:west-usを比較すると？」というのは、タグであれば除外するなり対象を入れるなりで簡単にできるようになります。

これはVirtual MachineのVirtual Machine Scale Setsのパフォーマンスなんですが、対象としてはリージョンとリソースグループというタグで対象を切っているだけなんですけれども、例えばそこに新しいリージョンのサービスが追加されたりすると、タグでスコープが切られているので、自動的に3層のグラフになっているのでパコッと上に乗るだけというかたちで、なにもしなくて大丈夫です。

こういったグラフもエバンジェリストチームの許可がないと出せなかったりするので、わかりにくくても出したりするところがあるんですけれども。何が言いたいかというと、タグベースでスコープを切っておくと、そこに当てはまるものがあとから追加されたとしても、意図どおりのスコープであれば、そのあとなにもしなくても監視対象の増減は自由にできるので、管理性もすごくいいというのがこのクエリーベースのモニタリングです。

クエリーベースのアラート設定

もう1つ、アラートなんですけれども、とくにコンテナ環境で監視するという場合は、Prometheusは1つ、少なくともZabbixでコンテナを監視しようとしているお客さまには今まで会ったことがないんですが、そことは明らかに違うポイントになるのかなと思います。

そしてアラートの時はこんな感じで、「role:web-appが可動しているリソースグループでregion:west-usであるものについて、リクエスト数が異常に低下した場合にアラートする」とか、下は「application:sql-serverが可動しているrole:accounting-appのホストについて、region:east-usにあるグループ内でほかと違うものがあればアラート」という感じです。

フィルタするとか対象としたくないものを外すとかもラベルとかタグで簡単に設定できるというのがあるので、たぶん実際TwitterとかInstagramもあえてユーザーさんがグループとかあらかじめ設定しなくても、見たいものがパッと見られるという考え方でつくられていると思うので、そういう複雑なデータに対してはこういった仕組みが必須というのがあるでしょうということです。

長期的な保管について

最後は、長期的な保管についてです。

これは月火水木金土日みたいなデータで、長期的にデータを取っていれば、こういう月間とか週間のデータがとりやすいですよね。

世の中の監視ツールでは1ヶ月だけしかデータがないとか、もっと短くて2週間だけということも普通にあるのでそこは論外としても、そういったところをデータとして持っていれば今後機会学習とかを使って異常検知にも幅が広げやすいので、もちろん長期的に保管するのが重要になります。

ちなみに、クラウドプロバイダーの監視ツール、Azure MonitorやCloudWatchなど、Google Stackdriverみたいなところの長さで見てみると、基本的には1分の粒度である程度の期間まで持つ用になっていますが、Azure MonitorやGoogle Stackdriverは長めに持っているという感じです。