Fedora Linux 本番サーバへの段階採用｜短サイクル EOL 管理とスナップショット切り戻し設計

Fedora を本番に持ち込む前に知っておくべきサイクルの特性

Fedora は Red Hat が支援するコミュニティディストリビューションで、最新の Linux カーネル・systemd・glibc・コンパイラツールチェーンをいち早く取り込む「アップストリームの試験場」としての役割を担っています。リリースサイクルは概ね 6 か月ごとで、各バージョンのサポート期間は次の次のリリースが出るまで、すなわち約 13 か月が目安です。Ubuntu LTS の 5 年、RHEL の 10 年と比べると、賞味期限は桁違いに短く設定されています。

この短さが問題になるのは、EOL（End of Life）を迎えたバージョンにはセキュリティパッチが供給されなくなる点です。本番サーバでそのまま運用を続けると、既知の CVE を放置した状態で稼働させることになります。しかし裏を返せば、カーネルや SELinux ポリシー・cgroup v2 対応・io_uring サポートといった最新機能を追いかけられるため、コンテナランタイムや eBPF を活用した可観測性ツールとの親和性は高い傾向にあります。

本番採用を検討する場合は、このトレードオフを運用チームが正しく認識した上で、「更新し続けることを前提とした設計」を組み込むことが出発点になります。

段階採用の進め方：ロール分類とカナリア昇格

すべてのサーバを一斉に Fedora へ切り替えるのではなく、ロールごとにリスク許容度を評価してから段階的に展開する方法が現実的です。以下は一般的な考え方の整理です。

• ステージング・CI ランナー：EOL による影響が限定的で、最新カーネルの動作確認をいち早く行いたいロール。Fedora を真っ先に導入して知見を蓄積する場として適しています。
• 内部ツール・非公開 API サーバ：外部トラフィックへの影響が少なく、問題発生時に切り戻しやすいロール。ステージングで安定性が確認できたバージョンをカナリアとして投入します。
• 公開 API・データベースホスト：EOL 管理の自動化と切り戻し手順が整備された後に移行を検討します。SLA が厳しいロールは最後に持ってきます。

カナリア昇格のタイミングは「次バージョンのリリース後 1 か月以内に本番ステージングへ投入し、3 か月以内に全ロールへ展開する」というサイクルを想定しておくと、13 か月の猶予期間内に余裕を持って完了できます。自動化パイプライン（Ansible・Terraform など）でプロビジョニングを管理している場合は、Fedora バージョンをパラメータ化しておくと昇格作業がシンプルになります。

EOL 管理の自動化：タイマー・通知・強制アップグレード

EOL を見逃すリスクを下げるために、以下の 3 層の仕組みを組み合わせるのが一般的なアプローチです。

1. EOL 日付の監視

dnf system-upgrade コマンドは Fedora の公式アップグレードパスを提供しています。EOL 管理の起点として、/etc/os-release に含まれる VERSION_ID と Fedora の公式 EOL カレンダー（Fedora EoL dates として公開されています）を突き合わせるスクリプトを systemd タイマーで週次実行し、残り猶予が 60 日を切ったら監視チャネルへアラートを送る構成がよく使われます。

2. アップグレード手順の標準化

本番環境での dnf system-upgrade は「スナップショット取得 → アップグレードのダウンロード → 再起動 → アップグレード適用 → 動作確認 → スナップショット削除」というシーケンスを Ansible プレイブックとして定義しておくことで、手順のばらつきを防ぎます。ダウンタイムを許容できないロールでは、Blue-Green デプロイメントパターンと組み合わせて旧バージョンのインスタンスを並走させながら切り替える方法が有効です。

3. 強制アップグレードポリシー

EOL まで 14 日を切った段階でメンテナンスウィンドウを強制予約するルールを運用手順書に明記しておきます。「後でやる」が重なって EOL を越えてしまうケースはよくあるつまずきです。ポリシーを Jira や PagerDuty のルールとして機械的に起票する仕組みにすると、担当者の判断に依存しなくなります。

スナップショット切り戻し設計：Btrfs と LVM の選択基準

Fedora 33 以降、デスクトップインストールのデフォルトファイルシステムは Btrfs に変更されています。サーバ用途でも Btrfs を採用する場合、サブボリューム構成とスナップショットを組み合わせた切り戻し設計が標準的になっています。

Btrfs スナップショットによる切り戻し

Btrfs のスナップショットはコピーオンライト（CoW）で作成されるため、差分だけディスクを消費します。btrfs subvolume snapshot でシステムルート（@ サブボリューム）のスナップショットを取得し、GRUB のエントリを切り替えることで、アップグレード後に問題が発生した際に旧環境へ起動し直せます。snapper または Timeshift を使うと、スナップショットのライフサイクル管理（世代数上限・自動削除）を設定ファイルで統一できます。

注意点として、Btrfs の RAID 5/6 実装は 2026 年現在も「実験的」扱いが続いています。冗長構成が必要なデータボリュームには LVM または mdraid を併用するか、ストレージ層での冗長性（クラウドブロックストレージ・ZFS）を別途確保してください。

LVM スナップショットとの使い分け

従来の LVM 環境や仮想化ホスト上で ext4 を使い続けているケースでは、lvcreate --snapshot によるスナップショットが選択肢になります。LVM スナップショットはスナップショット取得後の書き込み量に比例してスナップショット LV が肥大化するため、アップグレード前後の短期保持（24 時間以内に動作確認して削除）を前提とした用途に向いています。長期保持には向かないため、スナップショット容量の上限設計には注意が必要です。

クラウド環境（AWS・GCP・Azure）では、ブロックストレージのスナップショット機能をアップグレード前後で取得するのが最も確実な切り戻し手段です。インスタンスの OS 層のスナップショットと切り離してデータボリュームのスナップショットを管理することで、切り戻し時のデータ整合性を保ちやすくなります。

2026 年現在の環境差分と採用判断のポイント

Fedora 41（2024 年秋リリース）および Fedora 42（2025 年春リリース）では、以下の変更が本番採用の判断に影響します。

• DNF 5 への移行：Fedora 41 から DNF 5 がデフォルトになりました。DNF 4 と比べてプラグイン API が変更されており、カスタムプラグインを使っている環境では互換性確認が必要です。dnf system-upgrade のサブコマンド体系も一部変化しているため、既存の自動化スクリプトをそのまま流用する前に動作確認を行ってください。
• cgroup v2 完全移行：cgroup v1 の後退的サポートは Fedora では早い段階で打ち切られています。コンテナランタイムや旧来の systemd サービスユニットが cgroup v2 を前提とした設定になっているかを確認します。Docker Engine は 20.10 以降、Podman は標準で cgroup v2 に対応しているため、現行バージョンを使っていれば問題になるケースは少なくなっています。
• SELinux ポリシーの更新頻度：Fedora はアップストリームの SELinux ポリシー更新を積極的に取り込むため、メジャーアップグレード後にカスタムポリシーモジュール（.pp ファイル）が動作しなくなるケースが報告されています。アップグレード後の SELinux 拒否ログ（ausearch -m avc）の確認を手順に組み込んでおくことを推奨します。
• Fedora CoreOS との棲み分け：コンテナワークロード専用のホスト OS を探している場合、Fedora CoreOS（FCOS）は rpm-ostree による不変 OS モデルとオートマチックアップグレードを提供しており、本稿で扱った EOL 管理の手間を大幅に削減できます。汎用サーバ用途には Fedora Server、コンテナ専用には FCOS という棲み分けを運用チームで合意しておくと、ディストリ管理の複雑さを抑えられます。

Fedora を本番に採用することは「常に動き続ける更新サイクルに乗り続ける」という意思決定です。ツールチェーンの鮮度を保ちたいワークロードには大きなメリットがありますが、更新自動化とスナップショット設計を先に整備しないまま導入すると、EOL 追跡の負荷が運用チームのボトルネックになります。段階採用の枠組みと切り戻し手順を先に固めてから展開することが、安定した本番運用につながります。