はじめに こんにちは、タイミーのプラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 この記事では、スキマバイトサービス「タイミー」のバックエンド（Rails API）に Datadog Test Impact Analysis（TIA） を導入し、PRごとのCIフィードバックを大幅に高速化した取り組みについて紹介します。 なお、バックエンドはRailsアプリケーションなので、テストフレームワークは RSpec を前提として話を進めます。 サービスが成長してプロダクトの機能が増えてくると、テストも当然増えていきますよね。開発者が増えればPRの数も増え、CIの待ち時間がボトルネックになってくるのも、割とあるあるな課題だと思います。同じような悩みを抱えているチームの参考になれば嬉しいです。 背景：膨れ上がるテストとの戦い タイミーのバックエンドはモジュラーモノ

はじめに 株式会社タイミーのプラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 突然ですが、皆さんの組織では「3ヶ月前のログを見たいんですが……」という依頼が来たとき、どう対応していますか？ タイミーではDatadogをログ基盤として利用しています。Datadogは日常的なログ検索やアラート、ダッシュボードなどに使える非常に強力なツールです。一方で、ログの保存にはそれなりのコストがかかります。そのため弊社でも、コストとのバランスを考えてログの種類ごとに14日〜長くても45日程度の保持期間を設定していました。 普段の運用ではこれで十分です。ただ問題となるのは、「保持期間を超えた過去のログを検索したい」という場面が来たとき。今回はこの課題に対してDatadogのFlex Logsを導入し、コストをほぼ変えずに長期ログ検索を実現しようとしている取り組みについて

メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、DevO

こんにちは、SRE Team の大野です。製造業データ活用クラウド CADDi Drawer の Product SRE として、サービスの信頼性の向上や、効率的な運用を目指す取り組みを行っています。 今回は Cloud Run ワークロードの OOM 対応に Datadog Continuous Profiler を導入した際の、ハマりどころや学びについてのお話をします。 TL;DR はじめに Cloud Run での Profiler 選定 導入時のハードル 公式 Wrapper が使えない Profiler 単体で動かすための環境変数 プロファイリング結果の分析 プロダクト理解から見えた掛け算の構造 複数の観点で判断する 改善提案のまとめ方 Claude Code を活用した横断的調査 おわりに TL;DR Cloud Run ワークロードの OOM 調査にて Datadog Con

はじめに 突然ですが、Dress Code 株式会社ではつい先日コードレビューの負荷軽減を目的として Greptile を導入しました。 Graphベースでコードのコンテキストを持ってくれているのでそれなりに精度が高く、学習させることで継続的に改善できる点が気に入っています。 ただ、一つだけ困った点があって、使用量を制限する仕組みがないんです。 Greptileの料金体系はざっくり以下のようになっています。 月に1ユーザーあたり 50レビューまでが基本料金に含まれる 超過分は 1レビューあたり$1の従量課金 つまり、誰かがガンガンPRを出してレビューを回すと、知らないうちにコストが膨らむ可能性があるわけです。 Greptile側にユーザーごとの上限設定やアラート機能があればいいんですが、現時点ではそういった機能は提供されていません。 「じゃあ自分たちで計測してアラート出せるようにするか」と

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on. →

こんにちは。オペレーション部のしいなです。 はじめに Datadog の操作をコマンドラインから行いたいと思ったことはないでしょうか。 公式 CLI ツール「Pup CLI」がプレビュー版として公開されました。 OAuth2 認証に対応しているため、キーの管理を必要とせず、安全に Datadog を操作できます。 macOS へのインストールから OAuth2 ログイン、各種コマンドの実行までを一通り試してみました。 Pup CLI とは Datadog API との簡単な対話を可能にする Go ベースのコマンドラインツールです。 大きな特徴として、OAuth2 認証をサポートしている点があります。 Datadog API をリクエストするには Datadog API キーや APP キーが必要でしたが、ブラウザベース認証によって安全に Datadog を操作することができます。（※従来の

こんにちは、DevPFチームの菅原です。 現在、弊社のアプリケーション基盤（ECS on Fargate）では、コンテナログの収集・転送にFireLensを採用し、Datadog Logsへ集約しています。FireLensはタスク定義に数行記述するだけでログ基盤が整う非常に便利な機能です。一方で裏側では、Fluent Bitがサイドカーとして動作し、複雑なパイプラインを処理しています。 「ログなんて標準出力に出せば、あとは勝手に届くもの」 そう思われがちですが、実際にはアプリケーションコンテナからDatadog Logsのexplorerに表示されるまでには、いくつもの難所が存在します。今回は、ログがDatadogに到達するまでのアーキテクチャを紐解きながら、ログが「どこで」「なぜ」欠損するのかを解説します。 ログ転送のアーキテクチャ概要 まずは現在の構成のおさらいです。 基盤: AWS

Datadog Continuous Profiler活用事例: Goのiteratorの導入でCPU時間半減、メモリ確保量1/100を達成 🎉 はじめに こんにちは！ABEMAの広告配信システムの開発チームでバックエンドエンジニアとしてバイトをしている内定者の戸田朋花です。 本記事では、Datadog Continuous Profiler を用いてボトルネックを特定し、Go1.23 から追加された iterator を活用してコードをリファクタリングした結果、CPU 時間を 57%短縮し、メモリ確保量を 99.4%削減した取り組みについてご紹介します！ 背景 ABEMA の広告配信システムは多数のマイクロサービスで構成されていますが、とあるコンポーネントにおいて、CPU使用率が定期的にスパイクしている課題がありました。 性能改善と今後の安定した機能追加を実現するため、原因の分析とリフ

はじめに システム要件を整理する際、次のような AWS の仕様を確認されたことはあるでしょうか。 パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。 これは「AWS のリソース間通信は、パブリック IP アドレスを使用した場合でもインターネットに出ない」ことを示しており、インターネット経由の通信を禁止したい要件にとってありがたい仕様といえます。 しかし、実際にその通信経路がどのように見えるのかを外部から確認することは簡単ではありません。 本記事では、Datadog の Network Path を利用し、E

Observabilityを理解するため、目先としてはDatadogを使いこなすため、統計学の基礎知識を振り返りつつ、Datadogの各機能に触れます。 Datadogの使い方を具体的に知りたい人には役立たないので、その仕様がなぜそうなっているのか、背景や違いを理解したい人向け。モニタリング機能は統計学の実装とも言える、という個人的見解が今回の動機です。 Observabilityとは システム内で「あの時どこで何が起きていたか」を知る能力。和訳では可観測性。 単なる監視だけでなく、分散トレーシング、プロファイリング(性能評価)、デバッグも含まれています。 個人的印象としては、分散トレーシングと一緒の文脈でObservabilityの重要性を言われることが多く、分散システムが流行り始めた頃と同時期に必要とされた非機能要件かと感じてます。 統計学の尺度とデータ Datadogで扱うデータを理