はじめに 既存構成 課題感 設計 CloudWatch Logs ではなく S3 に倒す クラスタ単位で S3 prefix を切る 実装 ECS タスクロールに付与する IAM ポリシー ECS クラスタの executeCommandConfiguration おわりに はじめに Amazon Linux 2 (以下 AL2) の EOL (2026 年 6 月 30 日) が近付いてくる昨今、皆様いかがお過ごしでしょうか。 弊社では SSH 踏み台として使う EC2 インスタンスを AL2 ベースで

はじめに こんにちは、株式会社スタメン、プラットフォーム部の 勝間田 です！ 5月14日・15日に名古屋の中日ホールで開催された「 クラウドネイティブ会議 」に参加してきました！ 私自身、今年からプラットフォーム部に配属となり、日々の業務でSREやプラットフォームエンジニアリングに携わることが増えました。今回は、各領域の知見を吸収し、現地での参加者との交流を通して、これからの業務に活かせるヒントを得られればと思い参加してきました。 この記事では、当日の会場の様子や、弊社のブース企画で行ったアンケートの結果

はじめに SREの寺島です。 MNTSQでは継続的なコスト最適化を進めており、SREチームでもこれまでいくつかの削減施策を実施してきました。本記事では、その中からNAT Gatewayのデータ処理料金の削減に向けた取り組みを紹介します。 結果として、NAT Gatewayのデータ処理料金を約70%削減することに成功しました。今回は、コスト増の原因特定から、具体的な対応、そして効果測定にいたるまでの一連の流れをお届けします。 はじめに まずは Cost Explorer でコストの把握をする NAT Gat

はじめに こんにちは、ファインディ株式会社でエンジニアをしている中嶋（ @nakayama__bird ）です。現在は、新規プロダクトであるFindy Contextの開発に携わっています。 ファインディでは、これまでSREチームが担っていた新規プロダクトのクラウド環境の構築から監視体制の整備までを、プロダクト開発チーム主体で行う体制に切り替えました。 本記事では、私自身がFindy Contextの環境立ち上げを担当した経験を、アプリケーションエンジニアの視点で振り返ります。 経験の浅いエンジニアにとっ

はじめに こんにちは。CyberAgent Dev PlatformでBucketeerのオーナーを ...

はじめに 「監視モニタリングのIaCとか机上の空論だろ。労力とリターンが見合わんわ」 …と思っていた時期が私にもありました（慣用句） 前回の記事 でも少し触れましたが、 AIエージェントの登場によってDatadog × Terraformのような監視モニタリングのIaCの実践が劇的に楽になり 、気づけば手動でポチポチとモニタリングの設定をする運用の方が限りなく非効率になってしまいました。 AIエージェントをどう利用するかという部分は、まだまだ過渡期であり皆さま試行錯誤中ではあると思いますが、 弊社SREチ

はじめに こんにちは、プラットフォーム部の 勝間田 です！ 今回は書籍紹介記事の第２弾です！ 昨年投稿した第一弾の記事は👇にあります。 tech.stmn.co.jp 今回はそれぞれ職種の異なる４人が各々GWで読んでよかった書籍について、紹介させていただきます！ この記事で何か学びになったり、書籍を読むきっかけになったら嬉しいです！ SREの知識地図—⁠—基礎知識から現場での実践まで 勝間田が紹介する本は、「SREの知識地図」という書籍です！ gihyo.jp 私自身、今年からSRE業務に携わることになっ

3行で要約すると CUJ（Critical User Journey）ベースのダッシュボードを作る前提として、各 CUJ に紐づく Critical API を客観的に特定する必要がありました Playwright の route API による fault injection を使い、E2E テストから Critical API を自動抽出する仕組みを作りました ある程度汎用的に使えそうなので npm にも置いています： critical-api-finder はじめに SREの寺島です。 特定の AP

はじめに Datadog Bits AI SREは、アラートを起点に関連情報を横断的に参照し、原因候補や調査の方向性を提示してくれる機能です。障害対応を支援してくれる一方で、使ってみると、有効化しただけで十分に活用できるわけではなさそうだと感じる場面もありました。 そこで今回は、Tag設計、Monitorメッセージ、Runbook、Feedback（Memory） の4観点から、Bits AIの回答品質がどう変わるかを検証しました。 結論として、Bits AIの有用性は機能そのものよりも、Tag設計やRu

はじめに Observabilityの文脈でAI活用への期待が高まっています。ログ・メトリクス・トレースが揃っていても、障害発生時に「どこから見ればよいか」「どの仮説を先に当たるべきか」で時間を使ってしまうことは、現場では珍しくありません。 今回、AIを活用したObservability高度化をテーマに、DatadogのAI機能（Bits AI SRE）を用いた障害解析検証を実施しました。本記事では、その検証結果をもとに、AIが実際にどこまで役立つのか、そして何が限界なのかを紹介します。 ! この記事は2

はじめに システムが成長し、扱うデータ量やトラフィックが増大してくると、非同期処理の安定性とスケーラビリティがサービス全体の課題となります。 弊社のサービスの根幹部分はRuby on Railsを採用しているため、長らく標準の非同期処理のキューとしてResque (Redis) を使用していました。しかし、サービス規模の拡大に伴い、 Redisベースの運用では「ワーカーのオートスケール最適化」が困難である という課題が浮き彫りになってきました。 本記事では、この非同期処理のバックエンドを Amazon S

本ブログは、KDDI 株式会社 パーソナル事業統括本部 システム開発本部 ライフデザインプラットフォーム部 アライアンスシステムグループ 中野 利彦 氏、久保田 剛史 氏と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。 マネージドサービスを組み合わせたサーバーレスアーキテクチャは開発・運用の効率化に大きく貢献する一方で、複数サービスにまたがる複合的なインシデントへの対応は依然とし

DBRE (DataBase Reliability Engineering)チームの taka-h です。 2025年10月のTiDB User Dayにおいて、 オートスケールについて取組み中(P. 81)であることをご紹介 しました。この記事では、その後のオートスケールの取り組み状況についてお伝えします。 結論としては、2025年11月時点で、DBREが管理するTiDB移行済みの全クラスタでTiDBの水平方向オートスケール導入が完了し、その後も安定稼働しています。 次の画像は、メルカリ内のとあるCl

はじめまして。SCSKのすぐろです。 プレビュー版として実装されていたAWS DevOps Agentが2026年3月にGA（一般提供）されましたね。 インシデント発生時に自動で原因調査を行ってくれるサービスですが、実際にどこまで調べてくれるのかが気になったので、Amazon EC2上のWebサーバーで障害を発生させ、DevOps Agentの調査精度と限界を検証してみました。 参照: AWS DevOps Agent is now generally available AWS DevOps Agent

本稿は、SBI ネオバンキングシステム株式会社による AWS EKS Auto Modeの活用について、主導されたSBI ネオバンキングシステム株式会社 新藤様より寄稿いただきました。 はじめに SBI ネオバンキングシステム株式会社（以下、弊社）は、地方銀行向けのインターネットバンキングサービスをマルチテナント型 SaaS として開発・運用しています。サービス基盤には Amazon Elastic Kubernetes Service（以下、Amazon EKS）を採用しており、従来は AWS Farg