長らくインフラ基盤として利用されてきたCentOS 7のサポート終了（EOL）は、多くのシステムにとってアーキテクチャを見直す良い契機となりました。

本記事では、あるECサービスの基盤において、単なるOSの入れ替えにとどまらず、クラウドのマネージドサービスやCDN/WAFの統合、そしてツールによる運用保守の自動化を同時に実施したプロジェクトについて解説します。なお、本プロジェクトはインフラ構成の調査・計画から実際の移行作業、移行後のサポートに至るまで、筆者一人で遂行しました。 限られたリソースの中でいかに安全かつ効率的にシステムを移行し、その後の運用を楽にするかという視点から、システム設計と運用の工夫を整理・考察します。

1. 課題（Situation / Task）

移行前のインフラ環境では、以下のような運用上・コスト上の課題が顕在化していました。

OSのサポート終了によるセキュリティリスク 稼働中のサーバー群がCentOS 7ベースであり、新たな脆弱性に対する公式のパッチ提供が終了することによるセキュリティリスクの増大が懸念されていました。

レガシーな構成による高い運用負荷と維持費 システム内で自前運用しているデータベースやプロキシサーバの管理に多くの工数を割かれていました。また、数十に及ぶドメインのSSL証明書更新にかかる多額の費用や、サーバー常駐型セキュリティソフトのライセンス費用など、インフラ維持費が高止まりしている状態でした。

外部保守の形骸化 外部ベンダーと月額の保守契約を結んでいましたが、実質的な稼働実績が少なく、月次で実施されるはずのセキュリティアップデートもOSのサポート終了を理由に見送られるなど、費用対効果が低い状態が常態化していました。結果として、アラート対応などの実務は開発側で行うことになり、二重の非効率が生じていました。

2. 解決策（Action）

これらの課題を解決するため、「低コスト・高セキュリティ・低運用負荷」を目標に、アーキテクチャの刷新と運用の自動化を実施しました。

アーキテクチャのモダナイズ サーバーOSをAlmaLinux 8へ移行し、長期的なサポート（2029年まで）を確保しました。

• リプレース手法の調査検討: 移行に際しては、当初AlmaLinuxが提供する移行ツールキット「ELevate」を利用する手軽なインプレースアップグレードを検討しました。しかし、テスト環境を複製して検証を行った結果、本ECサービスには10年以上前から蓄積されたファイルや複雑な依存関係が存在しており、ツールを用いた正常なバージョンアップは困難であることが判明しました。

• クリーンインストールによる最適化: 代替策として、新規マシンにAlmaLinux 8および必要なミドルウェアをクリーンインストールし、プログラムとデータを移植して動作確認を行った上でDNSを切り替えるという、従来通りのリプレース手法を採用しました。結果として、この地道なプロセスを通じて古いインフラの遺産や不要なデータを洗い出すことができ、必要なものだけを新環境へ移植できたため、結果的に移行後の運用負荷の軽減に繋がりました。

インフラ構成の見直し 複数の仮想マシンで構成されていた環境を整理し、構成を見直しました。

• CDN / WAFレイヤーでの統合管理: 個別に購入・管理していたSSL証明書と常駐型のセキュリティソフトを廃止し、Cloudflareへトラフィックの入り口を統合しました。これにより、多数のドメインのSSL管理が自動化され、大幅なコスト削減となったほか、WAF機能によってアプリケーションに対するセキュリティ保護をエッジネットワーク側で担保できる構成へと変更しました。

• 複雑な処理のマネージドサービスへのオフロードと再構成: 運用負荷の大きな自前のデータベースとプロキシサーバを廃止しました。データベースはクラウドプロバイダーのマネージドRDBへ移行し、高可用性とバックアップ管理の自動化を実現しました。また、プロキシサーバも同じくクラウドプロバイダーのロードバランサへ移行し、前項のCloudflareからのアクセスだけを許可する形にすることで運用負荷が大きく軽減されました。また、静的コンテンツやアップロード画像などのファイル群はオブジェクトストレージへ分散させることで、費用と配信速度の最適化を図っています。

監視とパッチ適用の自動化（保守の内製化） 外部保守に依存していた体制を見直し、ツールを活用した自動化・内製化へ切り替えました。

• 監視の高度化: Mackerel等のSaaS型監視ツールを導入し、リアルタイムでのリソース監視とアラート通知の仕組みを構築しました。
• セキュリティ更新の自動化: OSの標準機能である dnf-automatic を活用し、脆弱性パッチを毎日自動で検知・適用する仕組みを構築しました。万が一適用に失敗した場合には、前述の監視ツールによって異常を検知できるフェイルセーフ機構を持たせています。

3. 補足：ダウンタイムを極小化するマルチドメインの移行プロセス

本プロジェクトの実行において、特に重要な要件となったのが「稼働中のECサイトのダウンタイムを極力短くすること」でした。

この課題の解決策として、Cloudflareの「カスタムホスト名（Cloudflare for SaaS）」機能が大きく貢献しました。これは、前提条件をクリアできればマルチドメイン型SaaSのドメイン管理を劇的に効率化できる仕組みです。

今回のサービス基盤では、システム側で管理するドメインだけでなく、利用者自身がドメインおよびネームサーバー（NS）を管理・運用しているケースも存在しました。そのため、本番切り替えの前にCloudflareのネームサーバーへ切り替えていただく必要があり、利用者への事前告知や個別サポートには相応の時間と工数を要しました。

しかし、この「事前のネームサーバー切り替え」を徹底したことで、本番切り替えの当日は、管理下にあるすべてのドメインのトラフィックをワンアクションで新サーバーへ振り向けることが可能になりました。結果として、過去に実施した同規模のサーバー移行プロジェクトと比較しても、ダウンタイムを劇的に削減し、移行作業中やその後の運営側へのお問い合わせ（クレーム対応）工数も抑えることができました。

4. 結論（Result）

今回のプロジェクトでは、OSのサポート終了を単なる「サーバーの入れ替え作業」としてではなく、「アーキテクチャ全体のモダナイズ」と「技術的負債の解消」の機会と捉えたことで、以下のような複合的な成果を得ることができました。

技術的負債の解消と大幅なコスト削減 クリーンインストールによる地道なリプレース手法を選択したことで、長年蓄積された不要な設定やデータを整理し、システムのスリム化に成功しました。また、SSL証明書や常駐セキュリティソフトの機能をCloudflareのCDN/WAFへ集約し、プロキシサーバやデータベースをマネージド化するなどインフラ構成を最適化したことで、システム全体のランニングコストを大幅に削減しています。

保守体制の内製化とセキュリティ水準の向上 dnf-automatic による日々の自動パッチ適用と、SaaS型監視ツール（Mackerelなど）を組み合わせたことで、実態と乖離しがちだった外部保守に頼ることなく、よりリアルタイムで強固なセキュリティ体制を内製化できました。これにより、外部への保守委託コストも削減されています。

ダウンタイムを極小化した安全な移行 多数のドメインを抱えるシステムでありながら、Cloudflareのカスタムホスト名機能を活用し、事前にネームサーバーを切り替える運用プロセスを徹底しました。これにより、本番環境へのトラフィックの切り替えをワンアクションで完了させ、ECサイトの売り上げに直結するダウンタイムを劇的に短縮できました。

本プロジェクトは、調査計画から移行作業の実施、切り替え後のサポートに至るまで一人体制で完遂しました。それが可能だったのは、単なる物理的なリプレースにとどまらず、「どの機能をクラウドのマネージドサービスやエッジネットワークに委譲できるか」「どの運用業務をツールで自動化できるか」をゼロベースで再検討し、徹底して自らの運用負荷を下げるアーキテクチャを選択したためではないかと考えています。

長期間稼働しているレガシーシステムの移行において、この「運用負荷を手放す」という視点は、将来のシステム運用の持続可能性を確保する上で重要になるかもしれません。