はじめに

この記事は、IBM Cloud Classic Infrastructure (IaaS) 上で稼働していたRHEL7の仮想サーバーを、OSのEOL (End of Life) に伴いRHEL9へ手動で移行したプロジェクトの記録です。

PaaSやコンテナ環境が主流となる中、IaaS環境、特にOSのインプレースアップグレードが提供されないクラシック・インフラでのOSバージョンアップは、依然として多くの企業が直面する課題です。
この環境では「新しいサーバーをプロビジョニングし、データ、設定、アプリケーションをすべて手作業で移行する」というアプローチが必須となります。

本記事では、この「手動移行」の過程で直面した技術的課題と、それを乗り越えた戦略について共有します。

この記事が特に役立つ方

IBM Cloud Classic Infrastructureを利用しているインフラ担当者
IaaS環境でOSのEOL対応を計画しているエンジニア
手動でのサーバー移行における、実践的なトラブルシューティング事例に興味がある方

1. 戦略：安全な移行を実現する「2フェーズ・リリース」アプローチ

手動移行プロジェクトにおいて、最も重要なのは「安全な切り戻し経路」を確保することです。私たちは、ユーザーへの影響が大きい「サイトのトラフィック切替」と「DNS管理業者の変更」という2つのイベントを、意図的に分離する戦略を取りました。

フェーズ	目的	具体的なアクション	メリット
1. サイト切替 🚀	トラフィックを新サーバーに向ける	Cloudflare上でAレコードのIPアドレスを旧→新に変更	問題発生時にAレコードを戻すだけで、数分での切り戻しが可能
2. DNS移管 🏢	DNS管理業者を変更する	安定稼働確認後、NSレコードをCloudflare→別プロバイダに変更	影響範囲の大きいNSレコード変更を、安定した状態から実施できる

この段階的なアプローチにより、各変更の影響範囲を最小限に抑え、安全かつ確実な移行を実現しました。手動作業が多い環境だからこそ、このようなリスク分離の考え方がプロジェクトの成否を分けます。

2. 課題：移行後に発覚したパフォーマンス問題の特定と解決

サーバーを新しくしただけでは、移行は終わりません。移行後、基幹システム（AS/400）からJSONを取得するAPIで、特定の条件下でのみCloudflareエラー524（A timeout occurred）が発生しました。

🔍 原因分析

当初はファイアウォールを疑いましたが、「一部のデータのみNG」という情報からアプリケーションレイヤーの問題と判断。調査の結果、原因は基幹システムから返されるJSONデータ内の「末尾が全角スペースでパディングされた固定長文字列」にあることが判明しました。

title=基幹システムから返却されたJSONデータ例

"CompanyName": "サンプル株式会社　　　　　　",
"BranchName": "東京支店　　　　　　　　　　　",

RHEL9上のPHP 8.x環境で、これらの文字列に対して標準のtrim()関数を実行すると、マルチバイト文字の処理により著しいパフォーマンス劣化が発生し、スクリプトの実行時間がCloudflareのデフォルトタイムアウト（100秒）を超えていました。

解決策

パフォーマンスボトルネックとなっていたtrim()関数を、マルチバイト文字（UTF-8）に対応した正規表現による置換処理に変更しました。

title=PHPの処理を最適化

// 変更前
// $cleaned_string = trim($string_from_legacy_system);

// 変更後: PCREの/u修飾子を使い、UTF-8文字列として効率的に処理
$cleaned_string = preg_replace('/^[\s　]+|[\s　]+$/u', '', $string_from_legacy_system);

この最適化により、処理時間は1秒未満に短縮され、タイムアウトは完全に解消されました。これは、OSや言語のバージョンアップが、アプリケーションのパフォーマンスに予期せぬ影響を与えるという好例です。

まとめ

IBM Cloud Classic InfrastructureのようなIaaS環境におけるOSバージョンアップは、PaaSなどとは異なり、インフラのプロビジョニングからアプリケーションの動作確認、そして将来の運用設計まで、幅広い知識と計画性が求められます。

手作業が多い分、システムの内部構造を深く理解できるという側面もあります。この記事で共有した知見が、同様の環境でOSのEOL対応に挑むエンジニアの方々の一助となれば幸いです。