タグ: #reliability
GPU・LLM・MLOps・Kubernetes、そしてマインドセット · 25 件
#reliability タグの記事は25件で、最新の記事は2026-08-15に公開されました。
よく一緒に付くタグ: #sre 8 #2026-04 5 #observability 5 #database 3 #distributed-systems 3
過去90日間によく読まれた記事:
本番の感覚 — 障害を経験した人が違って見ているもの
同じ設計文書を読んでも、障害を経験した人は別のものを読みます。これが未明に壊れたらどんなログが残るか、戻すのに何分かかるか、戻したあとすでに入ったデータはどうなるか。この記事は、本番がなぜコードではなく状態なのか、100パーセントがなぜ正しい信頼性目標ではないのか、可観測性とロールバックと段階的リリースがなぜ道具の導入ではなく既定値の問題なのか、そして大きな障害を自分で経験せずにその感覚を得る三つの方法を扱います。デプロイ前に埋めておく
2026-08-15 · 13 分で読めます #career#skills#sre#production#reliability657,607本のリンクを辿った結果とURLの寿命 — リンクはなぜ404ではなく接続失敗で死ぬのか
2009年から2014年の間に作られた短縮リンク65万本あまりを2026年にすべて辿った調査が公開されました。結果より重要なのは失敗の内訳です。死んだリンクの大半は404ではなく接続そのものが成立しない状態であり、これは内容が移動したのではなくインフラが消えたという意味です。調査手法の限界まで押さえたうえで、外部URLをデータとして保管するシステムで何を変えるべきかを整理します。
2026-08-14 · 13 分で読めます #web#data-engineering#archival#reliability#url-designAIエージェントを本番で運用するということ — 冪等性、予算、そして自信満々の誤答
エージェントをプロトタイプから本番へ移すとき、遅れて見つかる運用面があります。リトライされたツール呼び出しの冪等性、予算とステップ上限、非決定的な制御フローの可観測性、ツール単位の権限境界、そしてエージェントが自信満々に間違えたときのエスカレーション経路です。最近GeekNewsのAsk GNに投稿された分析は、ベンチマークのトレース6,780件から重複ツール実行8,042件を見つけ、そのうち159件は状態を変えるツールが実際に重複リソ
2026-07-31 · 29 分で読めます #ai#agents#observability#reliability#mcpレートリミットのアルゴリズム選び — 固定ウィンドウ、スライディング、トークンバケットの実際の違い
毎分100回で止めたはずなのに200回が通るのはバグではなく、固定ウィンドウアルゴリズムの定義された動作です。固定ウィンドウ、スライディングログ、スライディングウィンドウカウンター、トークンバケットの四つについて、メモリと精度のトレードオフを表で比較し、境界の問題を数字で確認します。分散環境でRedisの原子的操作がなぜ必要なのか、ノードごとのローカルリミットが生む誤差はどれくらいか、IPをキーにすると何が壊れるのかを整理しました。42
2026-07-26 · 21 分で読めます #web#rate-limiting#api-design#redis#reliabilityAIエージェントはプロダクションでどう失敗するのか — 14の失敗モード、そしてリトライが安全ではない理由 ♪ 聞けます
エージェントをプロダクションに載せると、3つの場所が痛みます。第一に、失敗はモデルではなくシステム設計から生まれます — UCバークレーのMAST研究は実行トレース1642件を分類して14の失敗モードを抽出し、そのうち44.2%がシステム設計の問題でした。第二に、最も多い2つの失敗モード(ステップ反復15.7%、終了条件の未認識12.4%)が、そのままトークンの請求書になります。第三に、まさにその2つがリトライ/冪等性の問題を生みます
2026-07-17 · 39 分で読めます #ai#agents#observability#reliability#mcpTemporal Worker Versioning GA — リプレイモデルが生んだデプロイ問題、2世代を捨てて出てきた3つ目の答え
Temporalのような耐久実行エンジンはイベント履歴をリプレイして障害に耐えますが、まさにそのリプレイのせいで「実行中のワークフローがあるまま新しいコードをデプロイする」ことが、このモデルで最も厄介な問題になります。Temporalは2026年3月30日にWorker VersioningのGAを発表し、OSSサーバーではv1.31.0(4月29日)で明記されました — 2023年6月の初プレビューから2年9か月、その間に2世代のバー
2026-07-17 · 22 分で読めます #distributed-systems#durable-execution#temporal#workflow-engine#reliability決済の冪等性：二重課金を防ぐ
ネットワークはいつか必ず切れ、切れたらクライアントは再試行します。ところが決済では、再試行が二重課金になりえます。冪等キー、重複排除ウィンドウ、ユニーク制約、再試行とタイムアウトの問題、at-least-once配信にdedupを足す設計、決済のステートマシン、そしてStripe流の冪等性実装まで — お金をきっかり一度だけ請求する方法を整理します。
2026-07-02 · 27 分で読めます #payments#idempotency#reliabilityExactly-onceは幻想か：決済・メッセージングの正確性
配信保証の三段階（at-most-once、at-least-once、exactly-once）が実際に意味すること、なぜexactly-once「配信」は原理的に不可能なのにexactly-once「処理」は冪等性・重複排除・トランザクションアウトボックスで達成可能なのか、二人の将軍問題が教えること、そしてKafkaのexactly-onceが本当に保証するものまで。決済とメッセージングの正確性を冷静に整理します。
2026-06-28 · 26 分で読めます #distributed-systems#messaging#reliabilityレートリミットのアルゴリズム徹底解説：固定ウィンドウ・スライディングウィンドウ・トークンバケット・リーキーバケット
固定ウィンドウ、スライディングウィンドウのログとカウンター、トークンバケット、リーキーバケットまで、代表的なレートリミットのアルゴリズムを一つずつ対比します。バーストをどう扱うか、Redisで分散環境にどう実装するか、そして429とRetry-After、クライアントのバックオフの作法まで整理します。
2026-06-25 · 20 分で読めます #systems#api#reliability冪等性とリトライ：信頼できるAPIの作り方
ネットワークはいつか必ず失敗し、失敗すればリトライしなければなりません。厄介なのは「すでに処理されたのに応答だけ届かなかった」場合です。冪等性とは何か、安全なHTTPメソッドとそうでないメソッド、POSTのための冪等キー、「ちょうど一度」という神話、そして指数バックオフとジッターでサンダリングハードを避ける方法を整理します。
2026-06-21 · 24 分で読めます #api#reliability#distributed-systemsDBマイグレーション戦略入門 — スキーマ、データ、そして無停止
データベースマイグレーションの種類とリスク、バージョン管理型マイグレーション、無停止デプロイの原則を体系的に整理します。トランザクショナルDDL、バックアップとドライラン、環境昇格、チームプロセス、障害予防チェックリストまで実践的な観点で扱います。
2026-06-16 · 25 分で読めます #database#migration#schema#devops#reliabilityマイグレーション事故事例とチェックリスト — 他人の失敗から学ぶ
マイグレーションは最も多く、最も痛い障害の源です。ロック嵐、レプリケーション遅延、データ損失、ロールバック不能といった典型的な事故タイプを押さえ、3件の仮想ポストモーテムで症状から原因と教訓を導き、予防パターンと総合チェックリストで整理します。
2026-06-16 · 23 分で読めます #database#migration#postmortem#incident#reliabilityExpand-Contract パターン — 無停止スキーマ変更の定石
稼働中のデータベースのスキーマを無停止で変更する標準手法である Expand-Contract パターンを整理します。カラム追加、リネーム、削除、制約追加といったシナリオごとの SQL と、ダブルライト、段階的バックフィル、アプリケーションコードとの連携、ロールバック戦略まで段階を追って解説します。
2026-06-16 · 23 分で読めます #database#migration#zero-downtime#expand-contract#reliabilityロード/パフォーマンステストツール 2026 — k6・Locust・Vegeta・Gatling・Artillery・JMeter 徹底比較(JMeter の先の風景)
パフォーマンステストは2026年もなお難しい。しかしツールは確実に良くなった。JS で書く k6、Python で書く Locust、ワンライナーで終わる Vegeta、エンタープライズの Gatling、YAML で速い Artillery、マイクロベンチの wrk/wrk2 と autocannon、そして今も生きている JMeter。gRPC・WebSocket・ブラウザモードまで届く k6 の拡張、ghz や fortio とい
2026-05-14 · 27 分で読めます #load-testing#performance-testing#k6#locust#vegetaうまく失敗するコード — エラーハンドリングとレジリエンス設計を深掘りする (2026) ♪ 聞けます
エラーハンドリングは機能を作り終えた後に付け足す装飾ではなく、設計そのものだ。失敗の種類を分類し、例外とエラー値のどちらを使うか決め、境界で検証してコアを信頼し、すべてのリモート呼び出しにtimeoutをかけ、retryにjitterを入れ、idempotencyで安全に再試行し、circuit breakerで障害を隔離し、優雅に性能を落とす — コードレベルでうまく失敗するソフトウェアを設計する方法。
2026-05-14 · 41 分で読めます #error-handling#resilience#retry#circuit-breaker#timeoutDurable Execution エンジン 2026 — Temporal・Restate・Inngest・Trigger.dev・DBOS 深掘り比較:cron とリトライ地獄から抜け出す道
長時間実行される workflow をもう cron と queue と if-else で書くな。2026 年の答えは Durable Execution である。Temporal・Restate・Inngest・Trigger.dev・DBOS、加えて AWS Step Functions・Cadence・Azure Durable Functions まで — deterministic replay・checkpointing・
2026-05-14 · 33 分で読めます #durable-execution#temporal#restate#inngest#trigger-devagent 評価システム 2026 — Inspect AI・Promptfoo・Phoenix・LangSmith・OpenAI Evals 徹底比較（モデルではなく agent を測る）
LLM 評価はモデルを測る。agent 評価はモデル + harness + tool が作業を最後まで完遂するかを測る。これは別の問題だ。2026 年現在の agent 評価フレームワークの地図を描く — UK AISI の Inspect AI（事実上の gold standard 化）、Promptfoo（OSS CLI）、Arize Phoenix（OSS observability + eval）、LangSmith（Lang
2026-05-14 · 29 分で読めます #agent-evaluation#inspect-ai#promptfoo#phoenix#langsmith有名ポストモーテム解剖 — Cloudflare・Fastly・AWS・Knight Capital・GitLab の失敗から学ぶ
Cloudflare 2022 BGP、Fastly 2021 のインターネット半分ダウン、AWS S3 2017 のタイプミス、Knight Capital 8 分で $440M、GitLab の DB wipe など — 有名な失敗から抽出したパターンと教訓。
2026-04-15 · 16 分で読めます #postmortem#sre#outage#reliability#cultureChaos Engineering 完全解剖 — Netflix Simian Army、LitmusChaos/Chaos Mesh、AWS FIS、Game Day
2010年、なぜ Netflix は本番サーバーをランダムに殺し始めたのか。Chaos Monkey の哲学と 4 原則、Simian Army 全体構成、LitmusChaos/Chaos Mesh/AWS FIS の比較、Game Day の設計、Blameless Postmortem までを解説。
2026-04-15 · 13 分で読めます #chaos-engineering#sre#reliability#netflix#kubernetesAWS Well-Architected Framework 完全ガイド 2025: 6つの柱、実戦適用、コスト/セキュリティ/パフォーマンス
AWS Well-Architected Framework のすべて。6つの柱 (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability)、実戦チェックリスト、Well-Architected Tool の使い方、一般的なアンチパターン、移行時の適用ポイントを解説。
2026-04-15 · 19 分で読めます #aws#well-architected#cloud-architecture#security#reliability