アソビューにおけるDatadogの使い方。エラー確認からログの分析・集計まで、幅広い領域のモニタリングを実現する

アソビューでSREを担当している鈴木です。本日は、アソビューでサーバの監視に利用しているDatadogをどのように利用しているかという部分についてご紹介していきたいと思います。

はじめに:監視システムに求めていること

アソビューでは、遊び予約サイトの運営をはじめ、チケットの電子化を支援するシステムなど、「生きるに遊びを」提供するための各種サービスを運営しています。多くのお客様が利用するサービスとなっているために、システムの異常をいち早く検出する必要があり、Datadogというサービスを利用して、その仕組みの一部を構築しています。

なお、弊社の提供しているサービスについては、下記のページをご参照ください。

www.asoview.co.jp

Datadogを活用して実施しているSRE業務について

Datadogを利用しているSRE業務としては色々あるのですが、いくつかピックアップしてご紹介したいと思います。

日々発生するエラーの通知と確認

運用していると、さまざまな理由でエラーが発生します。アソビューではAWSを利用しているので、AWS関連でエラーが出た場合も通知されますし、外部の利用サービスの障害やダウンなどでもエラーは発生します。こんな時にエラーを検知して知らせてくれる機能が必要です。そこにDatadogを利用しています。

エラーの通知方法について

エラーの通知は、PagerDutyによる通知とSlackの通知の2種類を用意しています。 超重大なエラーについては、PagerDutyにより通知し、電話で通知する運用になっています。それ以外のエラーについては、Slackに通知しておりまして、主に下記の三つのチャネルを使い分けています。

  • 緊急障害用チャネル : 緊急対応が必要と思われる事象が発生したときの通知用チャネル。ここは、主要なメンバーが参加して、何か発生した場合には、優先度をあげて対応するべきチャネル。

  • アプリケーションエラー通知チャネル:アプリケーションがエラーを出力したとか、例外が発生したとかそういう時に通知するチャネルです。ERRORログが出力されるたびに通知されます。緊急ではないもの発生したエラーについて原因を調べて対応をおこなっていくということを実施していきます。

  • 警告通知チャネル:些細な変化など、システムの障害の予兆となるべきものを通知しています。こちらも予兆を確認して、対応が必要なものについて対応を実施したりします。

基本的には、DatadogのMonitorの機能を利用してDatadogから通知を行なっています。

SREは、主に緊急障害用チャネルをウォッチして、発生した経緯を調査した後に、必要であればEmbedded SREと連携しながら、事象の解決にあたるということを実施しています。Embedded SREの取り組みについては、下記もご参照ください。

アソビューの Embedded SRE の取り組みについて - asoview! TECH BLOG

また、Datadogを用いてSLOの策定及びモニタリングも行っており、ここでもエラー率の変化やレイテンシの変化などを検知して、日々システムの安定運用ができるように監視しています。上の記事でも簡単に紹介していますのでよければご参照ください。

エラーの発生状況のサマリ

Datadogには、現在二つのタイプのエラートラッキング機能があり、こちらも便利です。 一つは、APMベースのエラートラッキング機能で、もう一つは、ログエラーベースのエラートラッキング機能です。 エラーがいつからどのくらい発生しているかだとか、無視可能なエラーを無視できる機能とか、エラーを自動的に分類して整理してくれてこれも便利な機能です。

詳細は、公式のページをご参照ください。

docs.datadoghq.com

ダッシュボードを利用して負荷の確認を行う

負荷のトレンド変化を見る際に、アソビューでは、さまざまな外部要因によりアクセスが変わってくるため、自動的に異常を検知するのが難しい場合もあります。 例えば、メールマガジンを発行した直後に、アクセスが増えたりとか、テレビの媒体で紹介された時にアクセス数が増えたりとか、特定のチケットの発売日に合わせてアクセス数が増えたりとか、さまざまな要因で、トレンドが変わってきます。そういう場合には、ダッシュボードで負荷の状況を確認することがあります。

ダッシュボードで表示している項目は、例えば下記のような項目です。

  • DBのCPU利用率
  • アクセス数(マイクロサービス単位/全体)
  • エラー数(マイクロサービス単位/全体)
  • レイテンシー(マイクロサービス単位/全体)
  • 利用可能なPodの数(マイクロサービス単位)

いくつか具体例をあげてダッシュボードの例を紹介したいと思います。

アクセス数の変化を見やすくする

下記は、nginxへのアクセス数下記で並べたものです。

  • 前日との比較
  • 1週間前との比較
  • 4週間前との比較

これらは、datadogのダッシュボードで利用可能なTimeshift関数を利用すると簡単にできます。便利ですね。これにより、アクセスが、増加傾向なのかどうかというのが分かりやすくなっています。ちなみにこのグラフで17時くらいに急増しているのは、メールマガジンを見た方からのアクセスが増えたことにより増加しているという感じになります。というのもダッシュボードで確認可能です。

各マイクロサービス毎の状況確認

下記のように、マイクロサービス単位で、エラーの発生状況やレイテンシーなどの基本情報を表示しています。これにより、各マイクロサービスが順調に稼働しているかということを判断することができるようにしています。

また、エラーが発生している場合には、こちらのメニューから該当エラーの詳細に飛べたりして、これも便利です。

また、下記のように、マイクロサービス毎の負荷状況を確認することができるダッシュボードを作成して必要であれば、スケールインやスケールアウトなど調整も行ったりしています。こちらのダッシュボードでは、Kubernetesの1podあたりの想定処理をベースにどれくらい余力があるかというのを表示するようなダッシュボードを作っています。いくつかのメトリックスをベースに計算しているのですが、柔軟に計算式を組めるのでそこも便利に利用しています。

ログの分析・集計

Datadogでは、ログの集計が標準的な機能でサポートされていて便利だと感じて使っています。例えば下記のような時に利用しています。簡単な例で言うと、nginxのログのStatus Codeの割合はどのような割合だろうということを調べようとすると下記のような設定で簡単に出力することができます。ログの分析をしたい時にDatadog内で完結するので、便利に利用しています。

設定例: 結果例:

まとめ

いかがでしたでしょうか?今回はアソビュー株式会社でDatadogをどのように使っているかの実例の一部をご紹介しました。そんなアソビューに少しでも興味がある方はぜひこちらもご覧ください!一緒に挑戦していく仲間たちを募集しています。すべての人に、遊びの世界をつなげる次の10年を一緒に創っていきましょう。

www.asoview.com