はじめに

こんにちは、MSPセクションの齋藤です。

 

「Datadog Summit Tokyo 2024」に参加してきましたので、体験したワークショップに関しての概要、感想含めて紹介していきます。

イベント情報

イベント名 Datadog Summit
開催日時
2024年10月16日(水)
イベント開催時間 10:00〜17:00
イベント会場
赤坂インターシティコンファレンス AICCホール&カンファレンスホールA
東京都港区赤坂1-8-1 赤坂インターシティAIR 4F
公式サイト https://www.datadoghq.com/ja/summit/tokyo24/

アジェンダ

09:00 – 10:00 受付
10:00 – 12:00 Datadogセッション + お客様セッション
12:00 – 13:30 昼食 + プロダクトデモ + AWS GameDay
13:30 – 16:00 ワークショップ + お客様パネルセッション
16:00 – 17:00 懇親会

 

ワークショップ概要

今回体験したワークショップは以下です。

 

「APMと分散トレーシングによる高品質ソフトウェアの提供」

 

このワークショップでは、実際にDatadogさんの方でご用意いただいたアプリケーション環境を使い、
Datadog APMを活用しオブザバビリティーを向上させ、アプリケーション内の問題を特定する方法を学びました!

 

ワークショップ上で使う機能について細かく説明があった上で適切にナビゲートしてくれてますので、
丁寧に読み進めればとてもわかりやすい内容かと思います。
(普段全く使わないボタンの操作ばかりだったので、若干オロオロしましたが..)

 

APMってなに?

今回体験したワークショップについて触れる前に、APMってなんなのか簡単に説明します。
APMは、アプリケーションのパフォーマンスを監視し、システムの問題やボトルネックを特定して解決するためのツールになります。
APMをシステムへ導入することにより、「オブザーバビリティ(Observability)」の向上に繋がります。

オブザーバビリティってなに?

「オブザーバビリティ(Observability)」とは、システムやアプリケーションの内部状態を外部から観測可能にすることです。

「オブザーバビリティ(Observability)」を向上させることにより、開発者や運用チームはパフォーマンスの問題を早期に発見し、効率的に対策することができるため、アプリケーションの信頼性とパフォーマンスを向上させることが可能です。

 

オブザーバビリティには以下の三つの柱があります。

  • 1. メトリクス (Metrics)

メトリクスは、システムやアプリケーションのパフォーマンスやリソース使用状況を定量的に測定したものです。

通常、数値として収集され、時間ごとに記録されます。メトリクスはパフォーマンスのトレンドを把握したり、異常を検知するために使われます。

例: CPU使用率、メモリ使用量、ディスクI/O、リクエストの処理時間、エラーレート

  • 2. ログ (Logs)

ログは、システムやアプリケーション内で発生したイベントの詳細な記録です。

通常、タイムスタンプ付きで保存され、システムの状態やアクションを記録します。

ログはエラーや障害が発生した際に問題の根本原因を特定するのに不可欠です。

例: エラーログ、アクセスログ、デバッグログ、ユーザーアクションの履歴

  • 3. トレース (Traces)

トレースは、リクエストがシステム全体をどのように通過するかを追跡し、特にマイクロサービスや分散システムで重要です。

分散トレーシングは、1つのリクエストが複数のサービスやコンポーネントを通過する際に発生する遅延や障害の箇所を特定するのに役立ちます。

ワークショップの進め方

Datadogのワークショップは「Datadog Learning Center」という学習用プラットフォーム上で行います。
こちらは、事前にアカウントの登録が必要です。

 

今回のDatadog Summitの中で行われたワークショップでは、基本的に黙々とDatadog Learning Center上の学習コンテンツを進めていくのですが、
わからないことがあったら、何人か待機しているDatadogの社員の方にすぐ質問できるような環境でした。

 

以下、学習コンテンツの画面

 

ターミナル

画面右側の「Instructions」にワークショップの説明や、進め方など、左側にアプリケーション修正用のターミナルやIDEの画面が用意されています。
Datadogのアカウントもワークショップ用に用意されてます。アカウント情報はターミナル画面から確認できます。
IDE

 

Datadogさんの方で用意いただいたサンプルアプリ(web画面)

 

 

Datadog Agentの導入

本ワークショップでは、Docker Composeを使ってアプリケーションが構成されており、
Datadog Agentも事前にセットアップされています。

 

このセクションでは、Datadog Agentがどのようにセットアップされているかを
docker-compose.ymlファイルの記述を見て確認していきます。

 

docker-compose.ymlファイル一部抜粋
datadog:
image: gcr.io/datadoghq/agent:7.53.0
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- /proc/:/host/proc/:ro
- /sys/fs/cgroup/:/host/sys/fs/cgroup:ro
environment:
- DD_API_KEY
- DD_LOGS_ENABLED=true
- DD_PROCESS_AGENT_ENABLED=true
- DD_DOCKER_LABELS_AS_TAGS={"my.custom.label.team":"team"}
- DD_TAGS='env:apm-workshop'
- DD_APM_NON_LOCAL_TRAFFIC=true
- DD_HOSTNAME=apm-workshop-host
- DD_REMOTE_CONFIGURATION_ENABLED=true
ports:
- "8126:8126/tcp"
- "8125:8125/udp"

 

上記のyamlでは、Datadog Agentコンテナに必要な環境変数や、ボリューム、
トレースライブラリからのトラフィックを許可するポートなどの設定が記載されています。

 

設定内容を一部説明
DD_LOGS_ENABLED=true
ログ有効化
DD_PROCESS_AGENT_ENABLED=true
プロセスエージェント有効化
DD_TAGS=’env:apm-workshop’ Datadogのenvタグを設定 → 閲覧するデータをフィルタリングできるようにするため
ports:
トレースライブラリからのトラフィックを許可するポート
 
 上記はすでに設定済みなので、Datadog上でデータが閲覧可能の状態です。
ホスト情報

 

ログ情報

 

トレース情報

 

アプリケーションの動作を監視するための仕組み(APM)を設定する

store-frontendサービス(Railsで作られたアプリ)を監視するためには、まず必要なRubyの「トレースライブラリ」をインストールする必要があります。

 

設定ファイルを追加してサービス名を指定、また、トレースやログを集めるためにdocker-compose.ymlファイルを更新する必要があります。

 

※この設定は使用しているプログラミング言語により異なりますので、詳しくは以下参照ください。

 

ワークショップ環境では、このAPMの設定もすでにされていました。

 

設定ファイル一部抜粋
Datadog.configure do |c|
  c.tracer enabled: true

  # This will activate auto-instrumentation for Rails
  c.use :rails,
    service_name: 'store-frontend',
    cache_service: 'store-frontend-cache',
    database_service: 'store-frontend-sqlite'

  c.use :active_record,
    service_name: 'store-frontend',
    orm_service_name: 'store-frontend'

  # Make sure requests are also instrumented
  c.use :http,
    service_name: 'store-frontend'
  end

Datadog APMを活用したアプリのデバック

当セクションから、本格的にDatadog APMの活用に関するレクチャーを受けていきます。

 

①サービスマップで全体を把握

 

フロントエンドの store-frontend が2つのサービス discounts-service と advertisements-service を呼び出していることがわかる
サービスの一覧画面(List)から、リクエスト数、レイテンシー、エラー数など、データを深堀ることが可能

サービスの一覧画面(List)

 

各メトリクスを確認

 

②サービスの一覧画面から、一つだけERROR RATEが表示されているサービス(store-frontend)があることを確認

 

③対象のサービスを選択して、エラーが発生している箇所を深堀り
リソース一覧画面を表示

 

→「Spree::OrdersController#edit」のリソース画面を確認

 

トレース情報から、500エラーが起きていることを確認

 

トレース情報を選択し、さらに深堀りしていく。
Errosタブからエラー情報(undefined method `[]’ for nil:NilClass)を確認

 

→Template部分に問題があると言うことがわかった!!

 

 あとはdocker-compose上のコンテンツを修正して、再デプロイを実施し、問題が解決していることを確認したら当セクションは完了です!

 

こんな感じで、当アプリケーション上に存在する複数のボトルネックとなっている箇所を、APMを使って特定し、コンテンツを修正すると言う流れを繰り返し実施しました!

 

これに近い内容のワークショップは「Datadog Learning Center」から受けられるようですので、気になる方はチャレンジしてみてください。

 

最後に

弊社は、PagerDutyやAMS、オブザーバビリティツールなどを用いた次世代監視基盤と24/365の体制での運用保守サービス、およびSaaSの調達から運用高度化の支援まで幅広いサービスを提供しています。ぜひ一度ご相談ください。
お問い合わせはこちらから