[{"data":1,"prerenderedAt":307},["ShallowReactive",2],{"blog-ja-kubernetes-feature-flags-progressive-delivery-rollback":3,"blog-related-ja-kubernetes-feature-flags-progressive-delivery-rollback":256,"blog-ja-kubernetes-feature-flags-progressive-delivery-rollback-alt":244},{"id":4,"title":5,"author":6,"body":7,"date":238,"description":239,"extension":240,"image":241,"locale":242,"meta":243,"navigation":244,"path":245,"seo":246,"stem":247,"tags":248,"__hash__":255},"blog\u002Fblog\u002Fja\u002Fkubernetes-feature-flags-progressive-delivery-rollback.md","テストを増やすほど本番は壊れる。Kubernetes運用で『機能フラグ』が監視より効く理由","Kubo Team",{"type":8,"value":9,"toc":229},"minimark",[10,15,23,26,29,40,64,68,74,83,86,94,97,101,107,110,118,132,140,143,147,153,159,162,200,207,210,213,216],[11,12,14],"h2",{"id":13},"なぜテストを増やすという発想は本番障害を減らせないのか","なぜ「テストを増やす」という発想は本番障害を減らせないのか",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-feature-flags-progressive-delivery-rollback\u002Fsection01.webp",[16,24,25],{},"Kubernetes運用で本番障害が起きるたびに、多くのチームが取る対策は同じだ。「テストを増やす」「レビューを厳しくする」「ステージング環境を増やす」。しかし近年注目されているのは、テストの積み増しではなく機能フラグによる「壊れることを前提にした設計」だ。一見まっとうに見える従来の発想に、実は効果がないという指摘が開発現場から相次いでいる。",[16,27,28],{},"理由は単純だ。本番環境で起こりうる例外パターンは、事前にすべて洗い出せない。決済機能のような複雑な機能では、2回連続のボタン操作や無効なカード入力、モバイルブラウザ特有の挙動など、想定外の組み合わせが無数に存在する。QAがどれだけ徹底的にテストしても、実際のトラフィックパターンをラボ環境で再現するのは原理的に不可能に近い。",[16,30,31,32,39],{},"実際、DORA（DevOps Research and Assessment）の調査でも、デプロイ頻度と変更失敗率は必ずしもトレードオフの関係にないことが示されている。小さな変更単位で頻繁にデプロイするチームほど問題の特定と回復が容易になり、失敗率が下がる傾向があるという（",[33,34,38],"a",{"href":35,"rel":36},"https:\u002F\u002Fdora.dev\u002Fguides\u002Fdora-metrics\u002F",[37],"nofollow","DORA Metrics Guide","）。「テストで完璧に防ぐ」より「小さく壊して、すぐ気づいて、すぐ戻す」仕組みの方が合理的だということだ。",[16,41,42,43,47,48,51,52,57,58,63],{},"Kubernetesの標準的なデプロイフロー、Rolling Updateも、この思想の上に成り立っている。Kubernetes公式ドキュメントによれば、Rolling Updateは新しいPodを段階的に起動しながら古いPodを置き換えダウンタイムなしの更新を実現し、",[44,45,46],"code",{},"maxUnavailable","と",[44,49,50],{},"maxSurge","で置き換えのペースを制御できる（",[33,53,56],{"href":54,"rel":55},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fcontrollers\u002Fdeployment\u002F",[37],"Kubernetes公式ドキュメント","）。しかしこれだけでは「デプロイした瞬間に全ユーザーへ影響が及ぶ」課題は解決されない（監視基盤の自前構築は時間がかかるが、",[33,59,62],{"href":60,"rel":61},"https:\u002F\u002Fkubo.hexabase.io\u002F",[37],"Kubo","のような標準搭載環境という選択肢もある。詳しくは後半で触れる）。ここで登場するのが、機能フラグという発想だ。",[11,65,67],{"id":66},"壊れることを前提にする設計への転換-機能フラグという安全弁","「壊れることを前提にする」設計への転換 — 機能フラグという安全弁",[16,69,70],{},[19,71],{"alt":72,"src":73},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-feature-flags-progressive-delivery-rollback\u002Fsection02.webp",[16,75,76,77,82],{},"機能フラグ（Feature Flag）とは、コードのデプロイと機能の有効化を分離する仕組みだ。Martin Fowlerの解説によれば、機能フラグはもともと「リリースサイクルより開発に時間がかかる機能を、コードの統合を止めずに隠しておく」ために使われ始めた手法で、A\u002FBテストフラグやユーザー属性ごとに機能を出し分ける権限フラグなど、複数の用途に発展している（",[33,78,81],{"href":79,"rel":80},"https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FFeatureFlag.html",[37],"Martin Fowler \"FeatureFlag\"","）。",[16,84,85],{},"この発想をKubernetes運用に当てはめると何が変わるか。従来は「コードを本番サーバーに配置する」ことと「ユーザーがその機能を使える状態にする」ことが同時に起きていた。機能フラグを使えば、新しいコードは先に全Podへデプロイしておき、実際に機能を有効にするユーザーの割合だけを外部から制御できる。",[16,87,88,89,82],{},"具体的には、まず対象ユーザーの1%だけに新機能を見せ、エラー率や応答時間に異常がないか確認する。問題がなければ10%に拡大し、最終的に100%まで引き上げる。この段階的な拡大は、GoogleのSREチームが提唱する「カナリアリリース」の考え方とも共通している。SREワークブックでは、カナリア対象が全体の5%でエラー率20%を記録しても、全体のエラー率は1%に抑えられるため、サービス全体の信頼性目標（エラーバジェット）への影響を大幅に抑制できると説明されている（",[33,90,93],{"href":91,"rel":92},"https:\u002F\u002Fsre.google\u002Fworkbook\u002Fcanarying-releases\u002F",[37],"Google SRE Workbook: Canarying Releases",[16,95,96],{},"つまり機能フラグは、「テストで100%の安全を事前に証明する」のではなく「小さな影響範囲で実際に試し、問題があればすぐ引っ込める」という、壊れる前提の設計思想を実装レベルで支える仕組みだ。",[11,98,100],{"id":99},"監視と自動ロールバックがテストの代わりになる仕組み","監視と自動ロールバックが「テストの代わり」になる仕組み",[16,102,103],{},[19,104],{"alt":105,"src":106},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-feature-flags-progressive-delivery-rollback\u002Fsection03.webp",[16,108,109],{},"機能フラグによる段階的な公開はまだ半分の仕組みだ。もう半分は、公開後に「異常をどう検知し、どう戻すか」という監視と自動ロールバックの仕組みである。",[16,111,112,113,82],{},"代表的な自動化ツールが、Kubernetes上で動くFlaggerと、Argo Projectが提供するArgo Rolloutsだ。Flaggerは、Prometheusなど複数の監視バックエンドにクエリを投げてリリースを分析し、定義したメトリクス閾値を下回れば自動的に前のバージョンへロールバックする、CNCF傘下のプログレッシブデリバリー用Kubernetesオペレーターだ（",[33,114,117],{"href":115,"rel":116},"https:\u002F\u002Ffluxcd.io\u002Fflagger\u002F",[37],"Flagger 公式サイト",[16,119,120,121,126,127,82],{},"Argo Rolloutsも同様の思想を持つ。AnalysisTemplateという仕組みで、Prometheusから取得した成功率などの指標に成功・失敗条件を定義し、満たさなければロールアウトを自動中止できる（",[33,122,125],{"href":123,"rel":124},"https:\u002F\u002Fargo-rollouts.readthedocs.io\u002Fen\u002Fstable\u002Ffeatures\u002Fanalysis\u002F",[37],"Argo Rollouts公式ドキュメント: Analysis","）。判定の元になる監視ルールは、PromQL式で閾値を定義し一定時間継続した場合のみ発火させる、Prometheusのアラートルール機能で構築するのが一般的だ（",[33,128,131],{"href":129,"rel":130},"https:\u002F\u002Fprometheus.io\u002Fdocs\u002Fprometheus\u002Flatest\u002Fconfiguration\u002Falerting_rules\u002F",[37],"Prometheus公式ドキュメント: Alerting Rules",[16,133,134,135,82],{},"この判断基準が「エラーバジェット」という考え方だ。Google Cloudの解説によれば、エラーバジェットとはSLO（サービスレベル目標）に対して許容される失敗の余地であり、可用性目標99.9%なら0.1%がエラーバジェットとなる。余裕があれば新機能のリリースを進め、消費し尽くしていればリリースを止める、という客観的な意思決定の基準になる（",[33,136,139],{"href":137,"rel":138},"https:\u002F\u002Fcloud.google.com\u002Fblog\u002Fproducts\u002Fmanagement-tools\u002Fsre-error-budgets-and-maintenance-windows",[37],"Google Cloud Blog: SRE エラーバジェット",[16,141,142],{},"こうして見ると、「機能フラグ→段階的公開→メトリクス監視→自動ロールバック」という流れは、QAによる事前テストの代替として機能していることがわかる。少数のユーザーに影響を限定して検証し、異常があれば即座に戻す。これは「テストの量」ではなく「気づいて戻す速さ」の設計問題なのだ。",[11,144,146],{"id":145},"k3sマネージドkubernetes環境でどこから始めるべきか","K3s\u002FマネージドKubernetes環境でどこから始めるべきか",[16,148,149],{},[19,150],{"alt":151,"src":152},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-feature-flags-progressive-delivery-rollback\u002Fsection04.webp",[16,154,155,156,82],{},"ここまで読むと、「今すぐArgo RolloutsとFlaggerを導入しなければ」と焦る読者もいるかもしれない。しかし、これは早合点だ。成熟度に見合わない複雑な仕組みを性急に導入することは、かえって運用負荷を増やし、チームの疲弊を招く（",[33,157,38],{"href":35,"rel":158},[37],[16,160,161],{},"現実的な導入順序は次のようになる。",[163,164,165,182,188,194],"ul",{},[166,167,168,172,173,47,175,177,178,181],"li",{},[169,170,171],"strong",{},"第1段階",": Kubernetes標準のRolling Updateを正しく設定する。",[44,174,46],{},[44,176,50],{},"を意識するだけでも、ダウンタイムなしの更新とロールバックの土台ができる（",[33,179,56],{"href":54,"rel":180},[37],"）",[166,183,184,187],{},[169,185,186],{},"第2段階",": PrometheusとGrafanaによる監視基盤を整え、エラー率やレイテンシのアラートルールを定義する",[166,189,190,193],{},[169,191,192],{},"第3段階",": リリース頻度の高い機能から機能フラグを導入し、段階的な公開の運用に慣れる",[166,195,196,199],{},[169,197,198],{},"第4段階",": チームの規模とリリース頻度が増えてきたら、Argo RolloutsやFlaggerによる自動化されたプログレッシブデリバリーへ移行する",[16,201,202,203,206],{},"多くの中小規模チームにとって、実は第1・第2段階を確実に押さえるだけで本番障害への耐性は大きく向上する。K3sベースのマネージドKubernetesサービスである",[33,204,62],{"href":60,"rel":205},[37],"は、Rolling Updateがデフォルトで機能し、Prometheus+Grafanaの監視基盤も標準搭載されているため、第1・第2段階を自前で構築する手間なくスタートできる。GitOps対応も標準化済みで、第3・第4段階へ進む準備が整った時の追加構築も最小限で済む。",[11,208,209],{"id":209},"まとめ",[16,211,212],{},"本番障害を減らす鍵は、テストの量を増やすことではない。事前にすべての例外パターンを洗い出すのは原理的に不可能であり、デプロイ頻度と安定性は対立しない。",[16,214,215],{},"代わりに有効なのが「壊れることを前提にした設計」だ。機能フラグでコードのデプロイと機能の有効化を分離し、1%→10%→100%と段階的にユーザーへ公開しながら、Prometheusベースの監視とエラーバジェットの考え方で異常を検知し、必要なら自動ロールバックする。この仕組みが、事前テストの限界を補う「後からでも間に合う安全網」として機能する。",[16,217,218,219,222,223,228],{},"すべてのチームが最初から高度な仕組みを導入する必要はない。Rolling Updateと監視基盤という土台を固め、成熟度に合わせて段階的にレベルを上げていくのが現実的だ。",[33,220,62],{"href":60,"rel":221},[37],"のようにK3sベースで監視・GitOps対応が標準搭載されたマネージドKubernetes環境なら、その土台を最初から持った状態でスタートでき、必要になったタイミングで次の段階へも無理なく進める。まずは自分たちのチームが今どの段階にいるのか、Rolling Updateの設定とアラートルールの有無から確認してみてはどうだろうか。",[33,224,227],{"href":225,"rel":226},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[37],"お問い合わせ","から、Kuboの監視・GitOps標準搭載の詳細を相談することもできる。",{"title":230,"searchDepth":231,"depth":231,"links":232},"",2,[233,234,235,236,237],{"id":13,"depth":231,"text":14},{"id":66,"depth":231,"text":67},{"id":99,"depth":231,"text":100},{"id":145,"depth":231,"text":146},{"id":209,"depth":231,"text":209},"2026-07-24","QAテストを積み増しても本番障害は減らない。すべての例外パターンを事前に洗い出すのは原理的に不可能だからだ。Kubernetes運用で注目される『機能フラグ×監視×自動ロールバック』という壊れる前提の設計思想と、K3s環境で無理なく始めるための段階的ロードマップを解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-feature-flags-progressive-delivery-rollback\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-feature-flags-progressive-delivery-rollback",{"title":5,"description":239},"blog\u002Fja\u002Fkubernetes-feature-flags-progressive-delivery-rollback",[249,250,251,252,253,254],"k3s","kubernetes","feature-flags","progressive-delivery","devops","managed-kubernetes","ckPvq0-GlqjPUNkHXQ25x7XjI8zp1nQRrS8pV9NW7MQ",[257,265,273,282,290,298],{"path":258,"title":259,"description":260,"date":261,"tags":262},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[249,250,263,264,254],"kubevirt","networking",{"path":266,"title":267,"description":268,"date":269,"tags":270},"\u002Fblog\u002Fja\u002Fai-generated-kubernetes-manifest-resource-overprovisioning","Kubernetesリソース設計はAI任せにできない。「動く」YAMLがクラウド代を69%溶かす理由","AIが生成したKubernetesマニフェストはkubectl applyが通り「動く」。しかしKubernetesリソース設計を誤ると過剰プロビジョニングでクラウド代が膨らむ。AIの限界と本番品質のrequests\u002Flimits設計を解説する。","2026-08-04",[249,250,271,272,254],"resource-management","capacity-planning",{"path":274,"title":275,"description":276,"date":277,"tags":278},"\u002Fblog\u002Fja\u002Fkubernetes-microservices-chatty-calls-latency","1つの注文処理で、裏側は5回叩かれていた。Kubernetesマイクロサービスの「チャッティ呼び出し」とレイテンシの正体","1回の注文処理の裏側でサービスが5回も呼び出されていた。原因はKubernetesマイクロサービスが陥る「チャッティ呼び出し」というアーキテクチャの問題。分散システムのN+1問題と解決策を解説する。","2026-08-02",[250,249,279,280,281,254],"microservices","service-mesh","latency",{"path":283,"title":284,"description":285,"date":286,"tags":287},"\u002Fblog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design","推論が学習を逆転した。KubeCon Japanで語られた、AI時代のKubernetesクラスタ設計指針","AI計算需要は学習から推論へ逆転し、2030年には推論の計算能力が学習の1.5倍に達すると予測される。KubeCon Japanの議論とCNCF AI Conformance Programから、Kubernetes\u002FK3sクラスタが備えるべき設計指針を解説する。","2026-08-01",[250,249,288,289,254],"ai-inference","cncf",{"path":291,"title":292,"description":293,"date":294,"tags":295},"\u002Fblog\u002Fja\u002Fhybrid-k3s-edge-metrics-network-overhead","2000台のIoTデバイスがネットワーク回線を圧迫していた。ハイブリッドK3s運用でpush型メトリクスが牙を剥いた日","2000台規模のエッジデバイスを支えるK3sエッジ運用の現場で見えた、軽量Kubernetesを選ぶべき理由と、push型メトリクス収集が生むネットワークコストの実態を、具体的な数値とハイブリッドクラスタ設計の観点から詳しく解説する記事。エンジニア・運用担当者向け。","2026-07-31",[249,250,296,297,254],"edge-computing","hybrid-cluster",{"path":299,"title":300,"description":301,"date":302,"tags":303},"\u002Fblog\u002Fja\u002Fkubernetes-mlops-gpu-scheduling-talent-shortage","AIがコードを書ける時代に、なぜインフラエンジニアの給料は上がったのか。企業のAI導入ラッシュが生んだ「MLOps人材不足」の実態","生成AIの普及でコードは誰でも書ける時代になったが、企業のAI導入が進むほどKubernetes上でGPUやモデルサービングを安定運用できるMLOps人材の需要は逆に高まっている。その理由と解決策を解説する。","2026-07-30",[250,249,304,305,306,253],"mlops","ai-infrastructure","gpu-scheduling",1786354650564]