Datadog コース

コースでも触れましたが、Datadogの機能自体が多く、画面上もUIが少し分かりづらいため苦手意識を持つ感覚もなんとなく理解できました。ただ、そういった点を考慮して、Datadogを使いこなす上で必要な不可欠な要素（メトリクス・ログ・トレース・APM・ダッシュボード・モニター）について、それぞれどういった目的のリソースなのか細かく丁寧な説明があるので、非常に学習しやすい構成だったと思います。

また、AWSインテグレーションとDatadogエージェントが収集するデータの違いを理解した上で、実際にAWSインテグレーションを連携してメトリクスを収集したり、Datadogにおける課金形態やその仕組み、コスト増大を防ぐためのポイントも解説されていて非常に為になりました！
あと、よく耳にするSLA・SLO・SLI、エラーバジェット・バーンレートについてもしっかりと解説があって、改めてキャッチアップできてよかったと思います。

個人的にはバックエンドについても幅広くインプットできたのは嬉しいポイントでしたね！
gRPCについてはprotoファイルのリポジトリ管理方法や、プライベートリポジトリ配下のGoモジュールの参照方法など、特にログとトレースを組み込むGoバックエンド実装についてはDatadogと連携する本質であり、アプリケーションログはどういった内容を出力すべきなのか見直すきっかけになりましたし、このコースの醍醐味だと実感しました！

受講前は自分も「APM＝トレース」と認識していた状態だったので、このコースをやりきってDatadogやオブザーバビリティに対する捉え方が大きく変わったと思いますし、正直このコースを受講したら、Datadogの導入から運用まで誰でも容易にできるようになるのでは！と感じております！
改めてこの教材を作って下さり、ありがとうございました

特に印象に残ったのは以下の課題です。

13 SLOによりサービス品質を数値化する

SLOの設定とその達成度のモニタリングは非常に重要だと感じました。
Datadogを活用することで、SLOの達成状況をリアルタイムで把握でき、問題が発生した際には迅速に対応できる点が魅力的です。
また、SLOをチーム全体で共有することで、サービス品質向上への意識も高まると思います。

課題の中で特に印象に残ったのは、CUIからSLI/SLOを逆算して定義するというアプローチです。
ユーザー体験を起点に「何をもって成功するか」を明確にしてからSLIを決め、目標値としてSLOを設定するという流れは、実務で「とりあえず99.9%」と決めがちな場面で非常に参考になります。
また、SLOは高ければ高いほど良いわけではなく、エラーバジェットによって開発の自由度を確保するという考え方も、信頼性とリリース速度のバランスを取る上で重要な視点だと再認識しました。

SREは非機能要件だけでなく、プロダクトの意思決定にも密接に関連していると感じました。

15 【鬼モード】Slack MetricsにDatadogを導入する

現場でPython、Ruby、Elixirでtraceを実装した経験がありますが、Goでのtrace実装は社内システムが多く、実務では取り組む機会がありませんでした。
今回の課題を通じてGoでのtrace導入を学べたことは大きな収穫です。

実際に取り組んでみて、実務で経験したElixirのtraceとGoのtraceの大まかな概念は同じであることを実感しました。
Tracerの起動、HTTPミドルウェアでのspan生成、contextを通じたトレースIDの伝搬など、言語は異なっても基本的なアーキテクチャは共通しています。

実務ではbackendエンジニアがわかるように実装サンプルのPRなどで差分を明示して共有していましたが、Datadog自体のエコシステム知識も必要なので、共有するのが結構大変でした。
個人的にこの経験があったので、本カリキュラムの落とし込みの粒度が非常に良いと感じました。
実務の導入ガイドとして捉えてもそのまま活用できるレベルだと思います。

このコースは、Datadogの機能を網羅的に学べるだけでなく、「なぜその機能が必要なのか」「実務でどう活かすのか」という観点が随所に盛り込まれており、非常に実践的な内容でした。
またBackendPraticaとしての体験も良かったと思います。

その他

課題のサイズ感が長すぎず短すぎずでテンポよく進められました。
課題を始める前にざっくりどれくらい進めようか考えるのですが見通しも立てやすかったです。
コース作成にあたり、これだけの分量と質を両立させるのは相当な労力が必要だったと思います。
非常に質の高い課題を作成していただきありがとうございました。

APM、ダッシュボード、モニターといった主要な概念を一通り学べたことで、Datadogで「どこで何を見るべきか」のイメージが明確になりました。

ログとトレースを紐付けることで、Log ExplorerからTraceを確認できる点はとても感動しました。
FireLensがDatadogにログを送信する仕組みについて解説している課題もあり、学んだ内容を応用できる課題構成になっています。
Datadogの分散トレーシングの形式は、Web標準のW3C Trace Contextをデフォルト採用しているわけではなく、Datadog独自の形式を優先している点に気付くきっかけもいただけました。

また、DatadogのリソースをTerraform管理することで、他のプロダクト・環境への転用や実務への導入に活かしやすい点も嬉しいポイントです。
本コースをきっかけに今回扱わなかった他の機能についても調べるようになり、非常に完成度・満足度が高いコースだと感じました。

また個人的にはGoをベースに普段から開発しているため、contextやmiddlewareを使ったトレースの管理はすごく参考になりました。スパンに触れられているのも、マイクロサービスが前提になっているのも実践的でありがたかったです！
これでddtraceだけではなくOpenTelemetry等の他のAPIを使って構築するイメージもかなり鮮明になりました。

さらに、これは他のコースにも言えることですが、Terraform管理するところまでしっかり明記されているのが嬉しかったです。これからモニターや、おそらくSLOもDatadogで構築していきTerraform化するところまでやる仕事があるので、あらかじめ頭の中に実用的な知識があることで大きな地雷を踏むことなく進められそうです。

Datadogを使いこなすにはバックエンドとインフラ両方がそれなりのレベルで求められる気がしていて、CP始めたての頃だと突破できなかったと思います。ここまでのコースを1つずつ丁寧に理解しながら進めることで突破できたと思っています。

また、現在はログをDatadogにはほぼすべて取り込んでいる状態のため、今後は削減の余地が大きいと感じています。現職では、エンジニアは約70名在籍しており、システム規模もそれなりに大きいため、ログ削減を進めるにあたっては合意形成が簡単ではありません。そのため、初期設計の段階からログ削減を意識することが重要だと感じました。

コンテナのログについても、CloudWatch LogsのみにするかDatadogに送るかといった細かな設計が可能なため、今後調整していきたいと考えています。