はじめに
この記事は、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データ内の「末尾が全角スペースでパディングされた固定長文字列」にあることが判明しました。
"CompanyName": "サンプル株式会社 ",
"BranchName": "東京支店 ",
RHEL9上のPHP 8.x環境で、これらの文字列に対して標準のtrim()関数を実行すると、マルチバイト文字の処理により著しいパフォーマンス劣化が発生し、スクリプトの実行時間がCloudflareのデフォルトタイムアウト（100秒）を超えていました。
解決策
パフォーマンスボトルネックとなっていたtrim()関数を、マルチバイト文字（UTF-8）に対応した正規表現による置換処理に変更しました。
// 変更前
// $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対応に挑むエンジニアの方々の一助となれば幸いです。