目次 はじめに 背景と課題 避難訓練の全体像 GUIベースのツールを選定した理由 AIによるシナリオ ...

はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富( @yannKazu1 )です。 新規プロダクトを立ち上げるとき、インフラ構築って意外とやることが多いですよね。その中でも地味にめんどくさいのが DBユーザーの作成と権限付与 。手動でやると「あ、権限つけ忘れた」「このユーザー名スペルミスってない？」みたいなヒヤリハットが発生しがちです。 今回は、この作業をTerraformでIaC化した話を書いていきます。 背景：ボイラープレートでインフラ構築を爆速にしている 弊社では Te

本記事は、Datadog agent-skillsとpupをGithub Actionsで実行し、自 ...

はじめに 医療プラットフォーム本部 プラットフォーム開発室 SREグループの吉田です。医療機関向けSaaSである CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。 CLINICSではメインDBとしてMongoDBを使用しており、以下の3つの目標を掲げて、DBM（Database Monitoring）を導入しました。 なおCLINICSでは監視・オブザーバビリティ基盤としてDatadogをすでに活用(*1)していたため、Datadog DBM（Database Monitoring）を

はじめに SREの寺島です。 MNTSQでは、本番環境でのAWSの手動操作や顧客情報データへのアクセス等をCloudTrailログから検知し、操作者に目的や理由を確認するセキュリティ監査を運用しています（詳細は こちらの記事 を参照）。 これまではログからの異常検知は自動化されていたものの、その後の操作内容の確認や目的や理由を確認する運用が人力で行われており、運用上のToilとなっていました。 この課題を解決するため、今回、セキュリティ監査運用を自動化するSlack Botを開発しました。本記事では、その

はじめに こんにちは、WEAR開発部 バックエンドブロックのaao4seyです。普段は WEAR というプロダクトのバックエンド開発を担当しています。WEARバックエンドシステムでは2025年夏頃からパフォーマンス課題が顕在化し、SLOの悪化や運用負荷の増大といった問題に直面しました。本記事ではこれらの課題に対し、チームとしてどのように改善サイクルを構築し継続的に取り組んできたかをご紹介します。 目次 はじめに 目次 WEARバックエンドシステムが抱えていたパフォーマンス課題 DB負荷上昇の要因 SLOへ

はじめに   こんにちは！2026年2月に CA Tech Job インターン生として就業 ...

はじめに 東京科学大学情報理工学院情報工学系修士1年の千代丸怜央と申します。 2025年2月7日から ...

はじめに こんにちは。リテールハブ開発部の清水です。 先日 SRE Kaigi 2026 に参加してきまして、私の中でSRE熱がかなり高まっています。 私たちはDatadogをオブザーバビリティ基盤として使用しているのですが、私自身はDatadogをまともに触った経験がありませんでした。 Datadogの画面を開くと左のメニューだけでも大量の項目があって、何ができるのか把握すること自体に大きなハードルを感じていました。 そのような中で、Datadog Learning Centerというものを知りました。

こんにちは。ファインディのPlatform開発チームでSREを担当している 原 です。 ファインディでは、普段私たちが開発しているファインディのプロダクトの裏側や、開発メンバーが日々どのように働いているのかをお伝えするために、Findy Tech Talkという技術系のオフラインイベントを開催しています。 今回は、そのイベントの第二弾となる「Findyのサービスを支える、横断SREチームのマネジメントと技術の挑戦」を開催しまして、その当日のそれぞれの登壇内容について書いていこうと思います。 findy-i

はじめに こんにちは。商品基盤部の藤本です。 私たちのチームでは、Spring Bootで実装したJavaアプリケーションの起動時間の短縮に取り組んでいます。今回の記事では、Class Data Sharing（以下、CDS）を本番で稼働しているアプリケーションに実際に適用した内容を紹介します。 導入時には、Datadog Java Agentとの両立という課題にも直面しました。そのため、トレースとメトリクスの送信をOpenTelemetryとMicrometerに置き換える対応もあわせて実施しました。

こんにちは。ソリューションアーキテクトの松本 敢大です。三井物産デジタル・アセットマネジメント株式会社（以下、MDM）では、デジタル証券や資産運用のビジネスを展開しており、金融機関として高いセキュリティ要件を満たすことが求められています。本ブログは、MDM が Amazon Security Lake を活用して SIEM の限界を超え、セキュリティデータ基盤を構築した事例について、Chief Information Security Officer 鈴木様から寄稿していただいたものです。 背景 AWS：

本記事は 2026 年 2 月 3 日 に公開された「 AI agents in enterprises: Best practices with Amazon Bedrock AgentCore 」を翻訳したものです。 本番環境で使える AI エージェントを構築するには、開発ライフサイクル全体を通じた綿密な計画と実行が欠かせません。デモで印象的なプロトタイプと、本番環境で価値を提供するエージェントの差は、規律あるエンジニアリングプラクティス、堅牢なアーキテクチャ、そして継続的な改善によって生まれます。

CloudWatch メトリクス を活用することで、システムの状態を可視化し効果的な監視を実現できます。 CloudWatch メトリクスには保存期間の制限があり、また外部の監視ツールと連携したいケースも多く存在するため、 CloudWatch メトリクスを外部に転送して活用するニーズが高まっています。 本記事では、CloudWatch メトリクスの基本的な概念を押さえた上で、メトリクス転送が必要となるユースケースと、AWS が提供する 2 つの転送方法について、それぞれの特徴や使い分けのポイントを詳しく

こんにちは、DevPFチームの菅原です。 現在、弊社のアプリケーション基盤（ECS on Fargate）では、コンテナログの収集・転送に FireLens を採用し、 Datadog Logs へ集約しています。FireLensはタスク定義に数行記述するだけでログ基盤が整う非常に便利な機能です。一方で裏側では、 Fluent Bit がサイドカーとして動作し、複雑なパイプラインを処理しています。 「ログなんて標準出力に出せば、あとは勝手に届くもの」 そう思われがちですが、実際にはアプリケーションコンテナ