2026年3月19日、Aqua Security が提供するOSSセキュリティスキャナ Trivy のエコシステムが、3週間以内に2度目のサプライチェーン攻撃を受けました。攻撃者は aquasecurity/setup-trivy および aquasecurity/trivy-action の2つのGitHub Actionsに悪意あるコードを注入し、これらを利用するCI/CDパイプラインからクレデンシャルを大規模に窃取するペイロードを配布しました。 本記事では、GitHub Events APIおよびGitHub上に残存するcommitデータから取得したエビデンスをもとに、何が起こっているかを記録します。その上で、取りうる対応指針を示します。 免責 本記事の目的は事態の把握と対応の促進であり、違法行為への加担・助長を意図するものではありません。ペイロードの動作は手法の理解に必要な範囲で要

2026年1月20日のOpenTelemetryコレクター v1.50.0/v0.144.0のリリースノートにこのようなことが書かれていました。 exporter/otlp_grpc: Rename otlp exporter to otlp_grpc exporter and add deprecated alias otlp. (#14403) exporter/otlp_http: Rename otlphttp exporter to otlp_http exporter and add deprecated alias otlphttp. (#14396) OpenTelemetryコレクターからOTLP/gRPCでテレメトリーを送信するにはOTLP/gRPC Exporterを利用し、このとき、これまでは設定ファイルのexporter欄にotlpというキーで設定を記述していまし

こんにちは。株式会社スマートバンク SRE部の capytan です。スマートバンク 新春エンジニア駅伝 2026 の十四区目の走者として頑張って走ります。十三区目は nissyi さんの Agent Client Protocol 入門 -エディタとAIエージェント連携の仕組みを体験する- でした。 本記事は、ゆるSRE勉強会 #14 で発表したLTの内容をもとに加筆・修正したものです。 CI/CDパイプラインの高速化は、多くのチームが一度は取り組む課題ではないでしょうか。Pull Requestをマージしてから本番に反映されるまでの時間は、開発者体験に直結します。障害対応時に「修正はできたけど、デプロイに30分かかる……」という状況は、なかなかつらいものがあります。 本記事では、私たちがDockerビルドのキャッシュ戦略を見直すことで、デプロイ時間を50〜65%削減した取り組みについて

Nikkei Advent Calendar 2025 の 14 日目はセキュリティチームからお届けします。セキュリティエンジニアの藤田です。普段はプロダクトセキュリティチームのリーダーとして組織横断的なクラウドセキュリティの向上や DevSecOps（開発・セキュリティ・運用の連携）などに取り組んでいます。最近は経営学に興味を持ち、技術とセキュリティと経営をセットで結びつけることにチャレンジしています。 本稿では、経営層からしばしば問われる「うちはランサムウェア対策できているのか」「攻撃は受けないのか」「システムは止まらないのか」に、AWS 環境において現実に起きている脅威と、今日から実装できる対策で答えることを目指します。アプリ開発者や運用者の視点と、セキュリティレビューの視点の両方から実践事項を検討します。本稿が、皆さまのクラウド環境におけるランサムウェア対策とセキュリティ文化醸成の

レガシーシステムやバイナリ化されたアプリケーションなど、「コードにさわれない」ブラックボックスな環境に、OBI（OpenTelemetry eBPF Instrumentation）を使ってゼロコードでオブザーバビリティをもたらす方法を紹介します。Mackerel APMにトレースデータを統合し、言語を問わず、フロントエンドからデータベースまでシームレスに処理を追跡する手順と、その利点を解説します。 こんにちは、Mackerel CREチームの武藤（ id:kmuto ）です。 CREチームは、お客さまのMackerelの導入・活用を支援する立場として、現在は特にAPM（アプリケーションパフォーマンスモニタリング）のご説明をさせていただく機会が多くあります。 そして、サービスを可視化するAPM自体には関心があるものの、「コードに手を入れるのは難しい」「古いバージョンでOpenTelemet

こんにちは、SREの與島（よしま）です。 Topotalでは、SRE as a ServiceというSREを軸にした技術支援サービスを提供しており、これまで何度かSLOの導入支援を行ってきました。 AWSで稼働しているサービスでSLOを導入するときには、ALBメトリクスでSLIを計測するというのがよくあるパターンです。低コストでSLIを計測できる一方で、SLIがユーザー体験と結びつかずサービスの改善につながらないケースがありました。これは、ALBメトリクスがパス単位で区別できず、重要なパスとそうでないパスが同じ指標に混ざるためです。 この課題に対して、ALBログをもとにPath/Host/Method単位でCloudWatchカスタムメトリクスを投稿するLambda関数を開発し、SLI計測の実装コストと有用性の両立を試みました。 この記事では、この取り組みの背景とアプローチを紹介します。な

やりました！私は運営と会場スポンサーとパネルディスカッションをやりました。会場周りは何もわからずでしたが同僚の皆さんに助けてもらいながらなんとかなりました(いなかったらどうなっていんだと考えるとゾッとします。本当にありがとうございました☺️) connpass.com スポンサーセッション 本日の資料です、IVRyのSREだいたい1周年記念https://t.co/ruv7JqXTIp#srelounge— abe (@abnoumaru) 2025年11月19日 スポンサーセッションを同僚にやってもらいました。1年通してSREが何ができて何ができていないのかを綺麗に整理した内容を話してもらいました。目の前の火は確実に消している一方でただし、見えている火の数が増えてきていっぱいありすぎてできていないのでは？みたいな感覚が生まれたりするのですがこうやって振り返ってもらえるとやってたのかもしれ

本記事では、オブザーバビリティプラットフォームであるMackerel、特にそのAPM部分について、大規模データに対応するためにどのような工夫を行っているかを紹介します。 オブザーバビリティプラットフォームは多くのデータを処理します。 たとえば、株式会社AbemaTVではサンプリングがない場合毎秒165万スパン作成されることを先日のObservability Conference Tokyo 2025で発表しています。 また、Googleの時系列データベースであるMonarchでは毎秒数テラバイト、PinterestのGokuでは毎日4.5兆のデータポイントを取り込んでいると報告しています。 このように、オブザーバビリティ関連のデータは大規模になるものです。 私たちMackerelはSaaS型のオブザーバビリティプラットフォームを提供しており、多数の企業からオブザーバビリティ関連のデータを受

はじめに 皆様こんにちは、あかいけです。 突然ですが、 CloudFront のどの箇所の通信にどんな料金がかかるか、把握しておりますでしょうか？ インターネット ↔︎ CloudFront 間の通信では確実に料金がかかりそうな気がしますが、 CloudFront からオリジンへの通信やデータ転送量にはどれぐらいお金がかかるのでしょうか…？ また CloudFront Functions と Lambda@Edge の料金には違いがあるのでしょうか…？ といった感じで私はめちゃくちゃふんわりとした理解だったので、 公式ドキュメント + 実際の請求書をもとに、CloudFrontの料金を図にしてみました。 皆様もこれを機に CloudFront 料金マスターになってください。 請求書の項目について まず請求書上の CloudFront に関連した項目は、以下のドキュメントに記載されています。

Forkewell Library #103登壇資料

はじめに こんにちは、SREチームの森原(@daichi_morihara)です。 今回はDatadogのログのコスト削減に関して最近行った取り組みを共有していきたいと思います。AWSやGCPなどのクラウドに関してはコスト削減・最適化に積極的に取り組んでいる一方で、Datadogに関してはあまりできていない、、というケースは多いのではないでしょうか？ (Datadogを使用している場合に限りますが。) 弊社でもDatadogのコスト最適化はあまり行えておらず、提供するサービスのスケールに伴ってDatadogのログコストが着々と増加してきたため、コスト削減に取り組むに至りました。 Datadogログコストの構造 Datadogのログコストは主に2つの要素によって構成されます。 ログの取り込み（Log Ingestion)：Datadogに送信されたログの収集・処理・パースするのに発生するコス

こんにちは。SREチームの吉澤です。 SREはインフラの専門性を持つため、SREチームのミッションに「インフラコスト削減」も含まれている会社は多いと思います。アンドパッドでも、主にSREチームがインフラコスト削減に取り組んできました。しかし、この取り組みだけでは削減できないコストが見えてきました。 そこでアンドパッドでは、2024年6月から、SREとソフトウェア開発者を集めた専門チームによるインフラコストマネジメントプロジェクトを開始しました。私は、SREチームとの兼務でこのプロジェクトに参加しています。プロジェクト開始から約1年が経過し、すでに大きな成果が出ています。 今回の記事では、このプロジェクトの背景や進め方、そして約1年の経験から学んだことをご紹介します。私と同じように、コスト削減に取り組む方の参考になれば幸いです。 背景 マルチプロダクト開発とコスト把握の難しさ コスト削減に関

はじめに 基盤本部で今後のhacomonoのアーキテクチャ設計をしている @bootjp と申します。 最近はマイクロサービス化に向けての社内共通のイベントバスの設計や基盤周りの設計/実装を行っています。 以前にはこのような記事を書き、分散システムや分散データベース、分散ストレージなどが大好きです。 「Goで作って理解するRaftベースRedis互換KVS」という同人誌も書いています。 もし興味のある方はお手にとってみてください。 さて、今回は分散システムやマイクロサービスで頻繁に用いられるQueueについて焦点を当てた記事を書きます。 とくにマネージドサービスを用いない環境では、RedisでQueueを実装してる方は多いのではないでしょうか？ しかし、ナイーブなQueueの実装には罠があり、データロストの危険性があります。 実例とともにデータをロストしないためには何が必要なのかをこの記事

2025-07-30 追記 macOS 15.6 で ja_JP が直っているのを確認しました。助かる！！！ （ko_KR も同じ原因で同じ現象なんだけど、そっちはそのままなんだ……。別途報告しよう……） $ cal 3月 2025 日 月 火 水 木 金 土 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 5 月なのに 3 月と言われる。 $ date #午後 date で #午後 という文字列が返ってくる。 状況は cal -y するとある程度理解できて、 $ cal -y | grep "[0-9]月" PM %Y年 %B%e日 %A %X %Z 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 と、本来「1月」「2月」となるべきところに「PM」「%Y年

はじめに こんにちは！トモニテで開発を行っている吉田です。 今回は Serverless Framework で作成した Lambda 関数を lambroll に移行しようとしたことについて書きます！ 移行検討の背景 昨年、Serverless Framework の v4 がリリースされました。 v4 からはライセンス形態が変更されて、収益の閾値を満たす、あるいは超える組織では有料でサブスクリプションを購入する必要があります。また v3 は 2024 年までのサポートで、クリティカルなセキュリティ問題やバグにしか対応しません。 他にもランタイムのアップデートにも対応していないため、今は大丈夫でもいずれ AWS Lambda のランタイムサポートが切れるため、v3 から v4 へのバージョンアップが必要になります。 www.serverless.com そこで Serverless Fr

はじめに きっかけ —技術者として、人間として 同窓会イベントでの再会、そして僕にやれること 生成AIによる可能性とスケールの実現 プロジェクト立ち上げと、本質的な挑戦、開発の現状 開発の現状 クラウドファンディング、残り1日の戦い 最後に はじめに この記事では、僕が個人的に関与しているプロジェクトについて語らせてください。 僕は普段は渋谷にある会社のCOOをしていたり、犯罪を予測するというテクノロジーを持つスタートアップのCTOをしたりしています。 Xでも何度かつぶやいているので知っている人もいるかも知れませんが、あらためて紹介するとともに「なんでやるのか」という自分自身の想いとともに言葉にしてみます。 【拡散希望】開発に関与しているプロジェクトのクラファンが始まりました。AWS時代の同僚が自身の経験をもとに立ち上げたもの。苦しむ人が多くいることを知り自分の知見が役に立つならと手伝って

Qiita Conference 2025 https://qiita.com/official-campaigns/conference/2025#day3 Appendix - https://konifar-zatsu.hatenadiary.jp/entry/2023/11/01/193210 -

こんにちは！バクラク事業部 Platform Engineering部 SREグループの id:sadayoshi_tadaです。 みなさんは監視ツールとして何を使われていますか？バクラクでは、監視にDatadogを使用しています。この記事ではDatadogのメトリクス収集の課題とそれに対する改善について書きます。 Datadogに収集するメトリクスにおける課題 CloudWatch Metric Streamsとは CloudWatch Metric Streamsで収集するメトリクスのフィルタリング Kinesis Data Firehoseを経由したDatadogへのメトリクス転送実装 CloudWatch Metric Streamsへの切替時の考慮点 切り替え後の変化と課題 まとめ 最後に Datadogに収集するメトリクスにおける課題 バクラクではサービスの実行基盤としてAWS

JAWS DAYS 2025 B-1 にて発表した際の資料です。SREの基礎的な話とAWSの各種サービスでSREのプラクティスを便利にする機能を紹介しています。 https://jawsdays2025.jaws-ug.jp/sessions/B-1

オープンソースで開発されているJavaScriptランタイム「Bun」のバージョン1.1.43に、Amazon S3のクライアント機能が搭載されることが発表されています（記事公開時点ですでに1.1.43はリリース済み）。 これによりBunで実行されるアプリケーションからAmazon S3に対してデータのアップロードやダウンロードを行う機能が簡単に実装できるようになります。 In the next version of Bun Bun gets first-class support for S3. Upload, download, stream, and presign with 0 dependencies pic.twitter.com/PR6OqdARoP — Bun (@bunjavascript) December 29, 2024 Bunの開発者であるJarred Sumne