こんにちは。shuheiです。

これまでの業務で、データセンターの大規模なフロア移転を、プロジェクトマネージャーとして進めたことがあります。

きっかけは、データセンター側の要請によるフロア移転でした。最終期限まではおよそ2年の猶予がありましたが、新しいラックを並行利用できる期間や、ほかの案件との兼ね合いを考えると、期限ぎりぎりではなく、前倒しで移転を終える必要がありました。

当時は、長年オンプレミスで運用してきたサービスが数多く残っており、単純に機器を別のフロアへ運ぶだけでは済まない状況でした。私はプロジェクト全体の進め方やスケジュール、判断方針の策定を担い、技術的な検討は各担当のエンジニアと連携して進めました。

この記事では、クラウド移行とオンプレミス環境の整理を組み合わせながら、チームでどのようにフロア移転を進めたのかをご紹介します。

移転前に抱えていた課題

対象は、10年以上運用してきたブログやメディアなどのサービス群、会員向けの認証基盤、ファイル配信サービスなど、性質の異なる十数個のシステムでした。自社で提供するサービスと、外部企業向けに提供するサービスが混在していました。

サーバーの多くは物理筐体で、仮想化基盤の上で動いているものと、DBやファイルサーバーのように物理のまま稼働しているものが混在していました。中には10年以上使い続けているネットワーク機器もあり、単純に「同じ構成のまま場所を移す」だけでは済まない状態でした。

クラウド移行とオンプレ移転を組み合わせた方針

対象を洗い出したところで、次に取りかかったのは、クラウドに出すものとオンプレミスに残して移すものを分けることでした。すべての機器をそのまま運ぶのではなく、クラウドへ移せるサービスは先に移し、それによって空いたサーバーを移転先の受け皿として使う。そうすれば、既存の機器を使いながら段階的に移転できます。

この考え方を前提に、物理的な移転作業へ入る前に、移転全体の方針を固めました。大きく決めたのは次の点です。

論理移転と物理移転を使い分ける

移転のやり方には、大きく2つの考え方がありました。

  • 物理移転：移転元で稼働している機器を、そのまま新フロアへ運搬する
  • 論理移転：先に新フロア側へ受け皿となるサーバーを用意し、フロア間でデータを同期させてから切り替える

費用の問題があったので、論理移転の受け皿には、新しいサーバーを購入するのではなく、クラウド移行やサービス整理によって空いた既存サーバーを活用しました。

まず、空いたサーバーを新フロアへ運び、移転元との間でDBやファイルサーバーのデータを同期してから切り替えます。切り替えによって空いたサーバーを次の受け皿として新フロアへ移し、同じ手順を繰り返しました。

この方針をもとに、具体的な移転順序やサービスごとの切り替え方法を詰めていきました。

IPアドレス体系を整理する

IPアドレスの体系が長年の運用でつぎはぎになっていたため、この機会に整理し直すことにしました。

難易度が低いサービスから着手する

自社サービスを先に、外部企業向けに提供しているサービスを後に回す順番にしました。自社サービスで作業の勘所をつかんでから、外部の提供先が関わるサービスに着手することで、経験の浅い状態で先方を巻き込む事故を避ける狙いです。

あわせて、DBとアプリケーションだけで完結するシンプルな構成から着手し、ファイルサーバーが絡むもの、さらに物理機器の運用まで含む複雑な構成のものへと、段階的に難易度を上げていく順番にしました。

物理移転の対象を減らす

移転全体の方針を固めたあと、まず着手したのは、物理的な移転の対象を減らすことでした。

前述のとおり、今回は新しいサーバーを購入せず、既存のサーバーを新フロア側の受け皿として再利用する方針でした。そのためには、不要なシステムを廃止したり、クラウドへ移行したりすることで、先に既存サーバーを空ける必要があります。

そこで、機器を動かす前の準備期間に、次のような整理を進めました。

  • 稼働中のプロジェクトやサービスを棚卸しする
  • 継続するものと廃止するものに仕分ける
  • 廃止できる環境は早い段階で削除する
  • クラウドへ移行できるサービスは先に移行する
  • 静的コンテンツはオブジェクトストレージとCDNを組み合わせた構成へ移行する

廃止やクラウド移行によって空いたサーバーは、先に新フロアへ運び、データの同期先として利用しました。これにより、物理的に移転する機器を減らしながら、オンプレミスに残すサービスを段階的に移転するための環境も用意できました。

この過程では、レガシーなブログサービスのクラウド移行に伴うDBのバージョンアップや、ファイルサーバーのオブジェクトストレージ化、認証基盤に残る古い文字コードへの対応、NoSQLデータベースのマネージドサービスへの置き換えなど、システムごとに異なる技術的な課題もありました。

これらはフロア移転というより、個別のクラウド移行に関する内容になるため、詳細は別の機会にまとめたいと思います。

移転を進める中でわかったこと

実際に移転作業を進めていく中で見えてきた重要なポイントがありました。

IPアドレス変更の影響は後から表面化する

サーバーの引っ越し自体がうまくいっても、IPアドレスが変わることで、外部連携先のアクセス制限や、DNSキャッシュなどに起因する問題が後から表面化することがありました。

切り替え直後だけでなく、しばらく時間がたってから問い合わせが来るケースもあり、IPアドレスが変わる移転では、移転当日だけでなく数日後まで監視の目を残しておく必要があると感じました。

長期間変更していない設定は実動作を確認する

過去に設定した後、長期間手を入れていない項目(アクセス許可IPのリストなど)は、移転作業の際に見落としやすいポイントでした。しばらく変更していない設定ほど、なぜその設定が必要なのかを知っている人が社内に残っていないこともあります。

そのため、機械的に手順をなぞるのではなく、実際に想定どおり動作しているかを都度確認する工程を挟みました。

ファイルサーバーの同期方法はサービスごとに設計する

主系・従系の2台構成を組んでいるファイルサーバーが多かったのですが、同期にかかる時間やデータ量、確認すべき範囲はサービスごとにまちまちで、一律の手順では対応できませんでした。

特にデータ量の多いサービスでは、通常の同期ツールでは時間内に終わらず、専用の差分同期の仕組みを別途用意することになりました。

外部連携先との調整は早めに始める

外部との連携が多いサービスでは、こちら側の準備だけで移転日を決めることができません。接続先の確認、相手先の作業日程、社内外の承認などが必要になるため、詳細がすべて固まってから日程調整を始めると、移転日がどんどん後ろにずれてしまいます。

大まかな作業内容と影響範囲が見えた段階で候補時期を共有し、そこから手順や確認項目の精度を上げていくほうが進めやすいと感じました。

移転を機に見直した運用基盤

フロアを移すタイミングは、普段は手を付けにくい基盤部分を整理する良い機会だと考え、チームで話し合い、あわせて進めることにしました。実際に実施したのは次のような内容です。

  • サービスをまたいで共用していたロードバランサーを、サービスごとに分離する
  • サーバー管理用のネットワークと、サービス本番用のネットワークを分離し、VPN経由でのみ管理アクセスできるようにする
  • サービスごとにバラバラだったネットワーク構成(DNS、ロードバランサーなど)を標準化する
  • 証明書の管理・更新を一か所に集約する
  • サポートが切れた古いOSの上で動いていた社内管理用の環境を、クラウド上のVPN環境に作り直す

これらは移転そのものには必須ではありませんが、機器を止めて動かすタイミングにあわせて実施することで、通常の運用中に個別対応するより低い工数で片付けられました。

6ラックから3ラックへ集約

最終的に、移転前は6ラックに分散していた機器が、移転後は3ラックに収まりました。

クラウドへの切り出しと不要プロジェクトの削除で稼働台数そのものを減らしたことに加え、既存サーバーを整理し、現状の利用規模に合わせて集約できたことが大きく効いています。

クラウドへ切り出せるものは先に移し、オンプレミスに残すものは、空いたサーバーを新フロアへ運んで同期・切り替えを行う形で順番に移していきました。物理的な移動が必要だった範囲も、サービス全体をそのまま運ぶというより、オンプレミスに残す必要があったDBサーバーやファイルサーバーが中心でした。

対象の中でも特にデータ量が多いサービスでは、その同期にかなり気を使いましたが、作業中に軽微な問題が発生しつつも、サービス停止時間を抑えながら移すことができました。

中でも特に強調しておきたいのは、どのサービスにおいても、データのロストやデータの不整合を起こさずに完了できたことです。対象の多い移転作業を進める中で、最後までデータを失わずに移し切れたことは、今回の移転で最も重要な成果だったと考えています。

まとめ

今回のきっかけはデータセンター側の都合でしたが、結果としては「移転」という強制力を使って、長年手が回っていなかったクラウド移行とオンプレ環境の整理を一気に進める機会になりました。

レガシーなオンプレ環境を抱えている場合、クラウド移行や機器整理は、日常の運用と並行してやろうとするとどうしても後回しになりがちです。今回のように、外部からの期限が決まっているタイミングをうまく使うと、普段は着手しにくい整理にも踏み込みやすくなります。

当社には、このような大規模なインフラ移行や、長く運用されてきたオンプレミス環境の整理・クラウド移行を経験したメンバーが在籍しています。データセンターの契約更新や機器の老朽化をきっかけに、レガシーシステムの棚卸しやクラウド移行を検討されている場合は、Webシステム開発やインフラ構築・サーバー移行のページをご覧のうえ、お気軽にご相談ください。