寄稿記事

巻頭言：SRE × セキュリティを考える

書いた人：しょっさん（ @syossan27 ）

Googleが公開した「SREの考え方をサイバーセキュリティに適用する」記事を題材に、トイルの撲滅や症状ベースのアラートなど4つの主張をセキュリティの文脈で読み解きます。

クラウドのリソース不足に備えよ - GKE ComputeClass によるフォールバック運用

書いた人：saorio（ @sao_rio ）

2026 年上半期に Google Cloud で経験した、N2D をはじめとするマシンの在庫切れを出発点に、GKE ComputeClass で複数マシンタイプへのフォールバックと Spot 活用を組み込んだ運用を紹介する記事です。Node Pool 管理の削減と、コストを 1/4〜1/5 まで下げた結果もあわせて振り返ります。

非 root の nginx が 80 に bind できたのは capability のおかげではなかった

書いた人：harukin721（ @harukin721 ）

Dockerfile から Cloud Native Buildpacks への移行に合わせて nginx を非 root 化した際、ポート 80 に bind できていたのは CAP_NET_BIND_SERVICE ではなく、コンテナランタイムが設定する net.ipv4.ip_unprivileged_port_start のおかげでした。listen を省略したときに 8000 で待ち受けてしまう問題、80 に bind できた仕組み、8080 に移したことの意味を、ソースとドキュメントを読みながら整理した記事です。

AIを組み込んだアプリの信頼性をどう制御するか

書いた人：Kazunori Otani（ @katzchang ）

AIエージェントの失敗はダッシュボードに現れない。観測・評価・防止の3層で、LLMアプリの品質をSREの道具立てで制御するアプローチを整理した記事です。

国内外のSRE記事

AI handles incidents, engineers lose touch with their systems

元LinkedIn SREで、現在はRootlyに所属するSylvain Kalache氏の記事です。AIが日常的な障害を解決してくれるようになると、人間がシステムの挙動や故障を学ぶ機会は減っていきます。一方で、自動化では対処できない難しい障害は、引き続き人間が対応しなければなりません。 著者はこの問題を、Lisanne Bainbridge氏が1983年に論じた「自動化の皮肉」と結び付けています。システムの仕組みと人間の理解との間に生まれる隔たりを「comprehension debt」と捉えています。AIに調査手順を説明してもらうだけでは、自分で対応する経験の代わりにはなりません。自動化を進めるからこそ、障害シミュレーションなどで対応力を維持する取り組みも必要なのだと思います。

Kubelet watches inodes. Just not until it’s an emergency.

Onkar Raghunath Shelke氏による、Kubernetesノードのinode消費を調べた記事です。kubeletはinodeの空きも監視していますが、不足した際の対応はPodの退避であり、イメージGCはディスク容量を基準に動きます。そのため、小さなファイルを大量に含むイメージでは、容量に余裕があってもinodeを使い切る可能性があります。 記事では、containerdのスナップショットに残ったnode_modulesから、イメージの作り方がノードのinode消費につながる仕組みを追っています。ディスク使用率だけを見ていると気付きにくい問題を、イメージの軽量化とinodeの監視の両方から考えている点が興味深いです。

Netflix Stratum Media Processing: Automated Container Right-Sizing

NetflixのVioletta Pidvolotska氏とNaveen Mareddy氏による、メディア処理基盤Stratumのリソース割り当てを自動調整する取り組みです。使用実績を見て余っているリソースを減らす、というだけではなく、減らしたときに何が起きるかをリソースごとに分けて考えています。 CPUやネットワークは制限に達しても処理が遅くなる一方、メモリやディスクの枯渇は処理の失敗につながります。そのため、メモリとディスクには余裕を持たせ、1回の削減幅も最大15%に制限しています。適用前の検証と適用後の監視まで含めて設計されており、コストを下げるための自動化にも、本番の変更としての慎重さが必要だと分かる記事です。

Backups aren’t simple

Aleksandar Filipovski氏による、バックアップについての記事です。家族の写真を失いかけた経験を入口に、別の場所へコピーを置くだけだった話が、世代管理、重複排除、DBの整合性、オフサイト保管へと広がっていきます。一つ考慮すると、また別の考慮事項が出てくる。その積み重なりが分かりやすく書かれています。 ファイルをコピーできたとしても、稼働中のDBを復元できるとは限りません。こうした複雑さを既存のバックアップツールが引き受けてくれていることに、改めて気付かされます。そして最後には復元テストが必要になります。「バックアップを取っている」で安心せず、何か起きたときに、どこまで戻せるのかを確認しておきたくなる記事です。

OpenTelemetry Collectorでテレメトリーデータの欠損を防ぐためのいくつかの方法

taxin氏による、OpenTelemetry Collectorでテレメトリーデータが失われる箇所と、その対策を整理した記事です。Collectorの過負荷や再起動、送信先の障害に対して、バックプレッシャー、キューの永続化、リトライ、経路の冗長化などが紹介されています。 各対策が「防げる欠損」「最小構成」「防ぎきれない欠損」という構成で整理されています。永続キューを用意してもリトライ期限を超えれば破棄されますし、リトライを延ばしてもキュー溢れは解消しません。設定を有効にしただけで安心せず、どの障害に備えていて、どこから先は耐えられないのかを確認できます。

壊してもいいデータベースを数秒で–ZFSで作るDBブランチ基盤

モノタロウの舛田氏による、ZFSを使ったDBブランチ基盤の構築記事です。PRごとにアプリケーション環境を用意できても、DBは共有のまま。他の人の検証を壊さないか気になり、試したい変更を気軽に試せない、という問題を基盤側で解決しようとしています。 MySQL自体に手を入れるのではなく、その下のストレージ層でZFSのスナップショットとクローンを使い、独立したDBを数秒で用意するという発想が面白いです。本番に近いデータ量でSQLやマイグレーションを試せる環境があれば、変更前に確かめられることも増えます。 安全に試行錯誤できる環境を提供する取り組みとして参考になる記事です。

書き手が人でもAIでも正しくなる道、SREを埋め込んだDeveloper Platform

ログラスの見形親久氏による、SREの実践を開発者向けプラットフォームに組み込む取り組みの登壇資料です。AIによる設定変更が増える中で、監視やセキュリティの既定値は上書きできないようにし、開発者が書く設定そのものを減らしています。 基盤チームと開発チームの責務を分け、任せる権限をサービスの範囲に限定したうえで、スキーマ検証や署名確認によって不適切な変更を防いでいます。資料では言及されていませんが、Shift Downの観点からも興味深い取り組みです。一方で、プラットフォームに任せる範囲が広がるほど、その信頼性を高める責任も重くなります。この点も含め、SREをチーム全体で実践するための設計が具体的に示されています。