AlmaLinux 10移行前にサービス互換性を段階検証する｜9系構成差分の洗い出しと切り戻し設計

AlmaLinux 10移行が慎重を要する理由

AlmaLinux 10はRHEL 10をベースに構築されており、AlmaLinux 9との間には単なるカーネルバージョンの差以上の変更が含まれています。Pythonのデフォルトバージョンが3.12系に移行し、OpenSSLは3.2系が標準となりました。また、DNFの後継であるDNF5がデフォルトのパッケージマネージャーに採用されており、従来のDNF4向けに書かれたスクリプトや設定ファイルはそのまま動作しないケースがあります。

さらにSHA-1を用いた証明書や署名の多くが既定で拒否されるようになり、内部認証基盤やパッケージリポジトリが古い署名方式を使用している場合には、移行直後から接続障害が発生する可能性があります。多くの運用環境ではこうした変更を事前に把握しきれないまま本番切り替えを迎え、サービス停止を招いています。段階的な検証アプローチを設計しておくことが、安定移行の前提条件です。

9系と10系の主要な構成差分を洗い出す

移行前にまず実施すべき作業は、現在稼働中の9系サーバーの構成を記録し、10系との差分項目を一覧化することです。以下の観点から差分を確認してください。

• パッケージの廃止・名称変更：AlmaLinux 10ではいくつかのレガシーパッケージが削除されています。dnf list --availableで10系のリポジトリに同名パッケージが存在するか確認し、廃止されたものは代替パッケージへの移行計画を立てます。
• Pythonバージョン依存：アプリケーションが3.9系や3.11系を前提にしている場合、3.12系での動作確認が必要です。特にC拡張を含むパッケージはビルドしなおしが必要になるケースがあります。
• OpenSSL 3.2系への対応：一部の古いTLS 1.0/1.1通信やRC4暗号は完全に無効化されます。openssl ciphersコマンドで利用中の暗号スイートを事前に棚卸しておきます。
• systemdユニットの変更：一部のユニットファイルのデフォルト値が変更されています。systemctl catで9系と10系の設定を比較し、とくにタイムアウト設定やセキュリティサンドボックスオプションの差異を確認します。
• SELinuxポリシー：10系では新たなポリシーモジュールが導入されています。既存のカスタムポリシーがそのまま適用できるかどうか、audit2allowなどで事前にチェックします。

この洗い出し作業には、rpm -qa --qf '%{NAME} %{VERSION}\n'でパッケージ一覧をテキスト出力し、9系と10系のテスト環境とでdiffを取る手法が実用的です。インフラをコード管理している場合はAnsibleのファクト情報やTerraformのステートと照合することで、差分の見落としを減らせます。

ステージング環境で段階的に互換性を検証する

差分の洗い出しが完了したら、ステージング環境を用意して段階的な検証を進めます。一度に全機能を移行しようとするのではなく、機能レイヤーごとに分けてテストすることが重要です。

第1フェーズ：OSとミドルウェアの単体検証　AlmaLinux 10のクリーンインストール環境に対し、Webサーバー（Nginx/Apache）・データベース（MariaDB/PostgreSQL）・キャッシュ（Redis）などのミドルウェアを個別にインストールし、バージョン互換性と基本動作を確認します。設定ファイルを9系からそのままコピーして起動できるかどうかも合わせて確認します。設定書式が変わっていてサービスが起動しない場合は、ここで検出できます。

第2フェーズ：アプリケーションの結合検証　ミドルウェア単体の動作が確認できたら、その上でアプリケーション本体を展開します。Pythonアプリであれば仮想環境を10系で再構築し、依存パッケージをすべてインストールしなおして動作テストを実施します。RailsやNode.jsなど他の言語スタックも同様に、言語ランタイムのバージョン差に注意しながら環境を再構築します。

第3フェーズ：本番相当の負荷・通信検証　単体・結合が通過したら、本番に近いトラフィックを再現して通信経路全体を検証します。とくにTLS証明書まわり、内部サービス間のAPI通信、外部サービスとの連携（Webhook・OAuthなど）は、OpenSSLの変更の影響を受けやすい箇所です。curl -vやWiresharkによるパケットキャプチャで実際の通信内容を確認するのが確実です。

移行後の動作確認チェックポイント

本番移行後の初動確認で見落としやすいポイントを以下に挙げます。サービス再起動直後だけでなく、数時間運用してから改めて確認することも重要です。

• ログローテーションの動作：logrotateの設定がsystemdのタイマーユニットと競合していないかを確認します。10系ではsystemd-logindやjournaldの挙動が変わっているため、ログが二重に圧縮されるケースや、ローテーションがトリガーされないケースが報告されています。
• cronとsystemdタイマーの共存：9系から引き継いだcronジョブが正常に動作しているか確認します。一部のパスが変わっている場合（/usr/bin/pythonのシンボリックリンクなど）、cronスクリプトが実行時エラーになることがあります。
• ファイアウォールルールの継続性：firewalldのゾーン設定が正しく引き継がれているか、firewall-cmd --list-allで確認します。nftablesの直接ルールを使用していた場合は、10系での構文変更の有無を確認します。
• 監視エージェントの再稼働：PrometheusのNode ExporterやDatadogエージェントなど、サードパーティ製監視ツールを10系向けパッケージで再インストールしていることを確認します。9系向けバイナリがそのまま動作するとは限りません。

切り戻し設計：スナップショットとパッケージ固定の組み合わせ

移行後に重大な問題が発覚した場合に備え、切り戻し（ロールバック）の手段を事前に設計しておくことが不可欠です。切り戻しの現実的な手段として、仮想マシンスナップショットとパッケージバージョン固定の2層構成が有効です。

クラウド環境（AWSやGCP）では移行前にインスタンスのスナップショットまたはマシンイメージを取得し、切り戻し時にはそのイメージから新インスタンスを起動してDNSを切り替える手順を準備します。オンプレミスのKVM環境ではvirsh snapshot-create-asで移行前スナップショットを保存します。いずれの場合も、スナップショットを取得した時刻とその時点のサービス状態をドキュメントに記録しておきます。

パッケージバージョンの固定については、移行後に動作が確認できたパッケージ群のバージョンをDNF5のversionlockプラグインで固定します。

dnf install python3-dnf-plugin-versionlock
dnf versionlock add nginx mariadb-server redis

これにより、dnf update実行時に意図しないバージョンアップが発生してサービスが不安定になるリスクを低減できます。固定はあくまで暫定措置であり、セキュリティアップデートの適用計画と合わせて定期的に見直す運用フローを設計します。

また、データベースに関しては移行前後の両方でフルバックアップを取得し、切り戻し後もデータの整合性が保てる状態を維持します。MariaDBであればmariabackup、PostgreSQLであればpg_basebackupを用いた物理バックアップが復元時間の観点からも推奨されます。

2026年現行環境における注意点

2026年8月時点において、AlmaLinux 10はリリースから間もない段階にあり、サードパーティ製パッケージのEL10対応状況にはばらつきがあります。特にEPELリポジトリはEL10向けのパッケージ数がEL9と比較してまだ少なく、EPELに依存したツール群（一部の監視エージェント、言語ランタイム追加パッケージ等）は代替手段を検討する必要があります。

Dockerおよびコンテナ関連では、Podmanが引き続き標準として位置づけられています。Docker Engineを9系から引き続き利用している場合、EL10向けの公式パッケージが提供されているか確認が必要です。コンテナイメージ自体はAlmaLinux 10ベースのものが公式で提供されており、ホストOSの移行とコンテナイメージの移行は独立して計画できます。

CentOS 7系からの長期移行を経てAlmaLinux 9に定着した環境では、9系のサポート期限（2032年）まで十分な猶予があります。移行の優先度は、AlmaLinux 10でしか利用できない機能（新カーネルの特定サポートや最新ランタイム）が業務要件に直結するかどうかで判断するのが合理的です。現時点で10系への移行を急ぐ必要がない環境は、サードパーティ対応が成熟した段階で計画することも選択肢のひとつです。

一方で、新規構築するシステムについてはAlmaLinux 10を選択することで、将来的な9系EOL対応コストを前倒しで回避できます。新旧環境が混在する時期の運用負荷を考慮しながら、移行タイミングを組織ごとに設計することが現実的な対応といえます。