DMM.comの、一番深くておもしろいトコロ。
テクノロジー カルチャー

DMM GAMES プラットフォーム、Datadogはじめました！

テクノロジー DMM GAMES インフラ

DMM GAMES プラットフォーム、Datadogはじめました！

  • このエントリーをはてなブックマークに追加
  • シェア

はじめに

こんにちは。 DMM GAMESプラットフォーム開発本部PFシステム部インフラエンジニアの軸丸です。

DMM GAMESでは、AWS、GCPなどのパブリッククラウドの導入を進めており、その環境の監視・モニタリングツールとしてDatadogを採用しています。

今回は、Datadogを採用した理由や、それによってインフラ監視がどのように変わったかなどを紹介したいと思います。

  • なぜDatadogを採用したか？
  • インフラ監視運用の変化
  • 今後の展望

f:id:jikumaru-saori:20190313171221p:plain

なぜDatadogを採用したか？

パブリッククラウドを本格的に活用し始めたばかりの頃は、従来のオンプレミス環境と違い、監視対象のサーバ数が動的に変化する環境、各種マネージドサービスを含んだ構成、また、コンテナを活用したシステムに対して、どのような仕組みで統合的にインフラ監視・モニタリングを行うのがより良いのか、頭を悩ませていました。

そんななか、最終的にDatadogを選定した大きな理由が、以下の2つです。

SaaSであること

「監視システム」には、選択肢として大まかに以下の3種類があると思います。

  • パブリッククラウドが提供する監視システムを利用する。
  • 監視ソフトウェア(OSSなど)を使ったシステムを自前で構築する
  • SaaSを利用する

選定にあたり、SaaSの持つ以下の特徴にメリットを感じたため、これを利用するのが良いという結論に至りました。

  • AWS、GCP、オンプレミスどの環境にあるシステムも1つの監視システムに集約できる
  • ネットワーク、OS、ミドルウェア、アプリケーションレイヤの監視も集約できる
  • 監視基盤自体の運用・メンテナンスをする必要がない

豊富なIntegration

私たちが複数のSaaSを比較検討するなかで、Datadogを選定するに至った、一番の決め手は豊富なIntegrationでした。

f:id:jikumaru-saori:20190313171023j:plain

サーバにエージェントをインストールしてメトリクスを収集する従来型の監視はもちろん、主要なパブリッククラウド(AWS、GCP、Azure)についてはエージェントレスで各種マネージドサービスのメトリクスやイベントを取得することができます。

特にクラウド特有のオートスケールに対する監視が印象的で、スケールアウト時に増えたサーバを自動で監視対象に追加してくれるほか、スケールインを検知して削除されるサーバからのアラートを自動的にミュートしてくれた時には、感動を覚えました。

クラウド環境自体の監視以外にも、MySQLやNginxなどのミドルウェアとの連携も多く、さらにコンテナや、そのオーケストレーション環境についても選定当時、すでにサポートされていました。

今やりたいことに対応できるのはもとより、新しいシステム構築にチャレンジしていくにあたって、現状でもこれだけのIntegrationを提供しているDatadogなら、今後もさらに機能拡張され、この先私たちがやりたいことに対応できるだろうと感じました。

インフラ監視運用の変化

Datadogによってシステム環境の変化についていけるような監視を実現できました。 これによって、従来の監視システムの運用方法から変わった点を、いくつかご紹介します。

ダッシュボードのカスタマイズ

監視アラートを飛ばすだけではなく、モニタリングも課題でした。 デフォルトで用意されているダッシュボードも見やすくわかりやすいのですが、自前でカスタマイズもできます。

私たちのチームでは、全システムを一覧できるダッシュボードを作ってチームミーティングにて全員で眺めています。 これによって傾向などがつかみやすくなり、アラートが出る前に能動的な対処ができるようになりました。

f:id:jikumaru-saori:20190313170948j:plain

監視設定のCode化

私たちのチームでは、IaC推進の観点からDatadogの監視設定にTerraformを採用しています (TerraformにはDatadogのProviderが存在するため、監視設定のコード化が可能です)。

IaCのメリットは各所で語られているとおりですが、やはり私たちもコード化の恩恵を受けていると感じます。例えば以下のようなものです。

  • 汎用的なアラート設定をモジュール化しておくことで、ある程度簡単に使い回すことができる
  • 監視に関する設定(クエリや閾値、アラートの通知先など)のレビューがコードでできる
  • ユーザーの作成・削除といった変更履歴を管理できる

検知したイベントのSlack連携

Datadogでは、標準的なメトリクスだけではなく、各種インテグレーション先で発生したイベントを検知することができます。

f:id:jikumaru-saori:20190313170915j:plain

これを利用して、例えば以下のようなイベントのSlack通知を運用に組み込んでいます。

  • AWSの各種インスタンスのリタイアメントなど、対応が必要なメンテナンススケジュール発生通知
  • AWS CodeDeployによるデプロイの失敗/成功通知 など。

以前は、イベントをSlackに通知したい場合、Lambdaなどを使用する必要がありましたが、それらが不要になり簡単に通知することができるようになりました。

また直近では、Datadog経由でAnsibleの実行や Jenkinsのジョブの成否などもSlackに通知することを考えています。

今後の展望

現時点ではシステムの監視・モニタリングのみを行っていますが、ログ集約やAPMの導入を行うため準備を進めています。

  • システムのメトリクス
  • アプリケーションのパフォーマンス
  • システムログ

これらを集約してインフラ、アプリの担当範囲を問わず1つのシステムを上から下まで見ることができるようにし、障害対応だけでなく通常時の運用においてもより効率良く、速やかに問題の発見・解決ができるようになることに目標を置いています。

最後に

クラウド環境の監視については非常に新しい概念が多く、最初はとても戸惑いましたが、 Datadogを導入することでより新しいアーキテクチャの監視を行うことができるようになりました。 現在の設定をブラッシュアップしていく余地もまだありますが、今後さらにDatadogを活用し、インフラ監視のみならず インフラ・アプリをまたいで、より良いシステム運用を行っていきたいです。 別の機会に技術的に掘り下げた話や事例の紹介もできればと思っています。

現在、DMM GAMESでは、プラットフォーム開発本部にてインフラエンジニア、開発エンジニアを募集しています、興味のある方はぜひ下記ページをご覧下さい！ dmmgames.co.jp

ページトップへ