サービスインフラをAWSに移行した2014年から10年以上にわたりDatadogを利用

ビジネスSNS「Wantedly」を運営するウォンテッドリー株式会社は、2014年以来10年以上にわたりDatadogの利用を続けている。2012年に「Wantedly」をスタートした当初、サービスインフラは非エンジニアでも使える手軽さとコスト抑制の観点から、コンテナベースのPaaSを採用した。その後、ユーザー数の増加などでパフォーマンスに限界が見えてきたことから2014年にアマゾン ウェブ サービス（AWS）に移行し、同時にDatadogの利用を開始。インフラチーム リーダーの田中篤志氏は「サービスインフラをAWSに移行する際、PaaSのメリットを維持するためにコンテナを引き継ぎDockerで構築しました。監視ツールは当時唯一Dockerに対応していたDatadogを採用し、インフラ監視で利用したのが始まりです」と振り返る。

その後、サービスの拡大を見据えて2016年にKubernetesによるマイクロサービスの運用を開始。ここでも当時、Kubernetesに唯一対応していたDatadogを再び採用した。2018年にはすべてのサービスがKubernetes上での稼働に移行したが、依存関係の多いサービスが増えた結果、デバッグが難しくなっていた。そこで、リクエストが各サービスをどのように通過したかを記録・追跡する分散トレーシングを目的にDatadog APMを試験導入し、徐々にAPMがカバーする領域を広げていった。

2020年にはサービス障害の平均復旧時間（MMTR）の短縮を目的にDatadog Logsを活用したSLO（サービスレベル目標）基盤の検証を開始。2022年にはKubernetesの管理環境を自前の基盤からAmazon EKSに移行して運用コストの軽減を図った。同時にマイクロサービス単位で異なっていた監視ツールの見直しに着手し、2024年にAPMの機能をDatadog APMに統合するとともに、2018年から導入を進めていたSLOにおいて、モニタリング基盤をDatadog SLOに移行し、Datadog LogsとDatadog SLOによる監視を開始した。

このようにDatadogを長年使い続けている理由について田中氏は「フェーズごとに最適なツールを模索した結果」と強調する。

「その都度、必要な機能を検討した結果がDatadogだったということで、Infra、APM、Logs、SLOはすべてにおいて当社のニーズにマッチしていました。特に、当社には技術選定において他社がやっていない新しいことにチャレンジする気風があり、その点においてもDatadogの思想と一致しています」（田中氏）

ウォンテッドリーでは現在、インフラチームを中心にプロダクト開発チームを加えた約50名がDatadogを利用し、150個近くのマイクロサービスを監視している。運用のメインはアラートへの対応が中心だ。インフラチームの川井颯人氏は次のように説明する。

「インフラチームは毎朝アラートをチェックし、対応が必要なものはDatadogで確認しています。エラー率の急上昇、レスポンスの低下など、ユーザーに直接影響を及ぼすものはインシデント管理ツールを介して"#war_room"と呼ぶSlackの緊急対応チャンネルに通知され、24時間365日の体制で対応しています。アプリケーションのメトリクスについてもアラートチャンネルに通知し、各チームで対応しています。バックエンドエンジニアはエラー調査でDatadog APMを活用していますが、最近は採用管理サービスの開発チームがフロントエンド周りの障害調査でDatadog RUMを利用してユーザーが直面しているバグなどの問題やパフォーマンスを把握し、ユーザー体験の向上を図っています」

Datadogでは、オートディスカバリー機能を活用するとAmazon EKSにサービスをデプロイした時点でDatadog Agentがコンテナで実行中のサービスを識別し、メトリクスを収集する。問題があればアラートが届くため、エンジニアはそれに応じて調査するだけだ。

「現在、社内のルールとしてマイクロサービスは社内共通ライブラリを導入し、EKSクラスタへのデプロイを義務付けています。それに従うことで自動的にログやメトリクスが取得できるため、エンジニアはDatadogを意識する必要はありません」（田中氏）

Datadogはサービス開発でも活用されている。1つのリクエストが複数のサービスにまたがるマイクロサービスは全体の処理の流れを把握することが困難である。Datadog APMを活用することで、トレース情報を追いながらデバッグができるため、開発者はシステムへの理解が深まるという。「結果として開発生産性が向上し、リリースまでの時間を短縮することができました」と田中氏は効果を語る。

また、ユーザー数課金でないことも同社のオブザーバビリティ思想に合致している。開発者全員がオブザーバビリティの価値を理解する体制づくりを目指す同社において、ユーザーを限定することなくほぼすべての機能を従量課金で利用できるDatadogは相性がよかった。

さらに、アプリケーションライブラリーがカスタマイズしやすい設計になっている点も同社の思想とマッチする。インフラチームにはさまざまなツールをカスタマイズして利用する文化が根付いており、SLOの基盤を構築する際もDatadog Logsを活用してカスタムメトリクスを生成するなど、多数の実績を残してきた。川井氏は「自分たちがやりたいことを自由にできることがDatadogのメリットであり、長年使い続けている大きなモチベーションになっています」と話す。

Datadogの技術情報は主にドキュメントを参照し、必要に応じて自社で情報を収集している。国内のDatadogのユーザー会（JDDUG）にも2020年から参加し、ユーザー同士で情報交換をしたり、ミートアップで情報発信しながらノウハウを蓄積している。

今後については、フロントエンドやモバイルなどエンドユーザーに近い領域でDatadog RUMを適用し、ユーザー体験の向上やサービスの信頼性向上を図っていく考えだ。アラートを受信した際の対応施策やアクションに関してはAI機能の活用も視野に入れている。川井氏は「現在、DatadogのAIエンジンであるWatchdogから自動的にアラートが通知されるものの、プロダクト担当ではないインフラチームでは原因分析まで追い切れません。一次調査をAIに任せることができれば対応負荷が軽減されるので、AIアシスタントのBits AIを含めたDatadogのAI機能に注目しています」と語る。

一方、課題もある。プロダクト開発チーム内ではAPMを中心にDatadogを利用しているユーザーと、使っていないユーザーで2極化している現状があるため、わかりやすいダッシュボードの提供などを通して利用者への普及活動を推進していく計画だ。そのためにもDatadogには継続的な機能強化と並行して、普及活動の支援にも期待を寄せている。

「インフラからアプリケーションまで、Datadogへの機能集約が理想的な姿なので、今後の機能拡大に期待しています。併せて全社における活用推進にもご協力いただければ幸いです」（田中氏）

「自分たちがやりたいことを自由にできることがDatadogのメリットであり、長年使い続けている大きなモチベーションになっています」

川井 颯人 氏
ウォンテッドリー株式会社
エンジニア