データセンターからクラウドへの移行

これまでイートスマートでは、サービスの大部分をデータセンターを利用して提供してきました。 データセンターの利用を開始してから年月が経つことで、ネットワーク機器・サーバの故障や容量不足が目立つようになりました。 データセンターを利用しているなかで問題となったのは、主に以下の３つです。

• ネットワーク機器・サーバの老朽化によるトラブル
• 上記要因による保守作業の増加
• サーバのリソース不足

ハードウェアの老朽化により、故障が発生するリスクが高くなり、部品の交換にも支障をきたすようになりました。 また、サービスが成長するに伴いサーバのメモリ等の容量不足が目立つようになりました。 そこで昨年から、データセンターからクラウドへの移行を計画しました。

クラウドへの移行計画

移行を計画するにあたり、現状・移行のそれぞれのメリット・デメリット、それに伴うリスクを検討しました。 検討内容を踏まえ、データセンターから既に利用実績のあるさくらインターネットへ移行することになりました。 またこのタイミングで、既に一部のサービスの本番環境で稼働実績のあるDockerを全面的に利用することになりました。 これに伴い、アプリケーションのビルド・デプロイ・監視・ログ収集等の仕組みを作り直しました。

アプリケーションのビルド・デプロイ

アプリケーションのビルド・デプロイには、引き続きJenkinsを利用しました。 これまでは、VCSからチェックアウトしたソースをビルドし、rsyncでデプロイを行っていました。 Dockerを利用するにあたり、ビルド後にDockerイメージを作成し、Docker Registryへpushし、Dockerホストでpull/runを行うようにしました。

監視

監視には、こちらも引き続きZabbixを引き続き利用しました。 Dockerホストを含む各サーバへZabbix Agentを導入し、Zabbixから各種リソース・サービスの状態を取得しました。 Javaアプリを動かすDockerコンテナは、Zabbix Java Gatewayを利用してJMXの状態を取得しました。

ログ

ログはこれまでは各サーバに書き出し、バッチでファイルサーバへ集約していました。 これを、fluentdを利用してほぼリアルタイムでファイルサーバへ集約するようにしました。 これにより、今まで各サーバにsshでログインしていたログの確認が、ファイルサーバで行えるようになりました。

バッチの移植

バッチ処理はこれまで必要なミドルウェアや設定が行われてた専用のサーバで処理を行っていました。 バッチもwebアプリケーションと同様にDockerイメージ化することで、リソース管理が柔軟になりました。 このタイミングでバッチの洗い出しを行いました。移行当日に停止した場合の影響範囲の調査と、手動実行が必要か等を確認しておきます。

データベースのレプリケーション

これまでも一部サービスでは導入していたデータベースのレプリケーションを、全てのサービスで導入しました。

クラウドへの移行準備

移行にあたり、移行先の環境を出来る限り再現したものを用意して検証を行いました。 既存の仕組みをそのまま移行するわけでは無いため、現状の安定性とパフォーマンスを満たすことが出来るかを確認しました。 確認にあたり、主にApache BenchとJMeterを利用しました。 Apache Benchでは、Nginx/Apache/Tomcat等の高負荷状態を作り、安定性の検証を行いました。 JMeterでは、本番環境に近いシナリオを作り、安定性・パフォーマンスの検証を行いました。

検証と並行して、データセンター側の作業も進めました。 移行当日の作業を減らすため、事前にバックエンド系のサービスをクラウドへ移行しました。 また、移行にかかる時間を短縮するため、データの転送に時間がかかるデータベース・ファイルサーバも準備を行いました。 データベースは、事前にベースバックアップを転送し、レプリケーションを行うことが決まりました。 データセンター側をマスタ、クラウド側をスレーブとして移行当日まで運用し、当日にクラウド側をマスタに昇格させることでダウンタイムを短くするためです。 ファイルサーバは、事前にクラウドへ全ファイルの転送を行い、当日まで同期を行うようにしました。

最後に移行テストを実施し、作業内容に見直し等を行いました。

クラウドへの移行実施

移行は３つのフェーズで実施しました。

移行前日

• 開発中のアプリを凍結し、移行のためのマージ作業
• IPアドレスが変わるため、反映までの時間を短くするためDNSのTTLの変更
• zabbixによる監視の開始

移行当日

• サービス停止
• データベースなどのバックアップの停止
• バッチ処理の停止
• データベースの切り替え（マスタ昇格）
• DNSの切り替え
• サービスの動作確認
• サービス再開

移行後

• ログ等からサービスの切り替えの確認
• データセンターのデータのバックアップ
• データセンターの機材の撤収

データセンターを切り替えるための最後の作業を行いました。 準備の段階で大部分の作業を終えているため、前日・当日の作業自体は少なくて済みました。

動作確認が終わりサービスを再開すると、検証時には見つけられなかった問題がいくつか発生しました。 そのなかのひとつが、Dockerホストが不安定になり再起動が必要になってしまったことです。 Swarmモードの利用の停止、Dockerコンテナの再配置、メモリやサービスのチューニングで対処しました。

おわりに

データセンターを利用していて当時の問題は、移行を行うことで解消することが出来ました。 移行直後に一時的に不安定になりましたが、上記の対処を行うことで現在は安定しています。 リソースに余裕が出来たことで、これまで稼働させることが出来なかったものや、冗長構成を取ることが出来るようになりました。 いくつか失敗もしてしまいましたが、普段の業務では出来ない経験をすることが出来ました。