▼インフラ・サーバーの状態を可視化する「Datadog」とは…

新しい技術でチャレンジができる環境を求め、wizpraにジョイン

私はwizpraにジョインして、半年ほどになります。前職ではメインフレームなどを扱う大きめのコンシューマーさん向けのインフラ構築をしていたので、BtoBの自社サービスに携われるというのが大きな魅力でした。また、比較的新しい技術にチャレンジできることも大きかったですね。

大企業のインフラエンジニアはちょっと「枯れた」技術を中心に扱っている部分もあって、新しいものにはなかなか手を出しづらいんですよね。wizpraなら、今まで自分が培ってきた知識を活かしつつも、チャレンジングなことも出来るというのが入社の決め手になりました。

システム全体を可視化する「Datadog」を導入

「DevOps」という言葉は、今ではかなりメジャーになりましたね。Webサービスの開発において、機能開発・改良を担当する開発側（デベロッパー）と、サービスの安定性を担保するインフラの担当者（オペレーター）などが、互いに連携していこうという話です。弊社でもその取り組みを始めています。

そして、デベロッパーとオペレーターのコミュニケーションを円滑にすることをひとつの目的として、「Datadog」というインフラ監視ツールを導入しています。

インフラの監視で昔から使われているNagiosのようなアラートを上げるだけのサービスではなく、Zabbixのようにある期間の監視情報をグラフィカルに見られるツールです。

導入の背景としては、オペレーションの担当者とデベロッパーの双方が、同じグラフを見て会話をできる仕組みを作りたかったんです。

▼インフラの状態を「見える化」するDatadog

Datadogはインフラに限らず、サービス全体のパフォーマンスを可視化できるサービスです。アプリケーションをデプロイした回数やタイミングも記録できるんですよ。何か障害が発生した時に、どのデプロイと関連していたのかを判定するのに役立ちます。

Datadogさえあればモニタリングはすべて任せておける、という形で使えるのが素敵ですね。

システムの細やかな情報まで、グラフィカルに表示

またDatadogは、グラフを綺麗な形で表示してくれるところが良いですね。サーバー1台1台を、ミツバチ状に綺麗にならべて一覧化してくれるんですよ。

負荷がかかると表示が赤くなるので、どのサーバーに問題があるのか一目で分かります。AWSのインスタンスを何十台も動かしているような環境だと壮観ですよ！

▼「ミツバチ状に」サーバーの状況を可視化する

負荷がかかってしまっているインスタンスについては、詳細情報を確認して対応します。CPUやメモリの使用率はもちろん、内部でどういったサービスが動いているのか、さらにハードディスクのパーティションごとの空き容量まで確認できます。

ディスク全体としては空きはあるけど、特定のパーティションがゴミデータでいっぱいでソフトウェアがフリーズしてしまったというようなケースでも、視覚的に分かりやすくなっています。

初心者でも扱いやすいWebUIも提供。導入もスムーズ

導入自体も簡単で、デフォルトのサーバーのリソース監視・死活監視はエージェントをインストールするだけで実現できます。また、充実したWebUIなので、インフラ専門の人でなくてもカスタマイズを簡単に行えるのも良いですね。

最近のシステムであれば、JSON形式で設定を書き込むものも増えていると思います。ただ、インフラ専門の人や新卒の方の中にはJSONに馴染みのない人も多いんですよね。

初めてサーバー管理をやりますというときに、まずはJSONの書き方から勉強するというのは学習コストが高いじゃないですか。それがWebUIでポチポチ設定するだけで体験できるというのは素晴らしいですね。

Datadogは、1年間はデータを保存してくれます。監視目的であれば十分な期間だと思いますね。私自身、長い間インフラの運用をしてきていますが、1年以上前のデータを見ることは無いです。

もちろんトラブルが発生した時にピンポイントで「あの時どうだったっけ」と見ることはあると思いますが、それって単純にどういうグラフだったのかだけ分かれば十分なんですね。

グラフだけ別で残しておくだけでよくて、モニタリングのログ自体は無くても問題ないですし、必要とあればプランをアップグレードしてデータ保存期間を延ばすことも可能だったりします。

システム監視からユーザー行動が見えてくることも

弊社の提供するwizpra NPSは、顧客の声を把握・分析することでクライアントの経営課題を解決するサービスです。そのため、クライアントの方が顧客の声をリアルタイムで把握し、分析する機能があります。

この機能、僕らの考えだと、分析結果を表示するボタンを一度押したお客様は、しばらくは押さないだろうと思っていたんですよ。でも実際は、短時間に何度もそのボタンを押すお客様がいて、サーバーに予想以上の負荷がかかっていたことがありました。

なぜ何度も押されたのかと言うと、ボタンの二重押下防止処理が漏れていて、レスポンスが遅くて何度もクリックしていたり、集計期間を間違えたからもう一度新規で集計してしまったり、そういった事が原因でした。

このような作り手が意図していない、考慮漏れの行動についても、モニタリングしていたら分かることがありますね。それを元に「こういう使われ方をしているのであれば、こういう対策が打てるよね」というアイデアを出すことにつながる事もあります。

オペレーターとデベロッパーの共通認識にDatadogは最適

DevOpsは、開発者とオペレーターが一緒になって開発を進めていきましょうという話ですが、それにはお互いが共通の理解を持つことが重要です。

普段オペレーターの人が見ている情報をそのままデベロッパーに渡しても、「この情報のどこを見たらいいの？」と言われてしまったら意味がないですよね。

デベロッパーの観点に立ってみると、必要なのは簡単にグラフが見れて、関連する情報がダッシュボードに並べてあるという事なんです。デベロッパー側がオペレーター側と同じ情報を見ることができ、それがデベロッパー側にも分かりやすく可視化できていれば、オペレーターが説明する手間は必要なくなります。

Datadogはインフラとアプリケーションどちらの情報もまとめて、オペレーターとデペロッパー双方に分かりやすい形で確認できるため、オペレーターとデベロッパーのコミュニケーションには最適だと思っていますね。（了）