月間約1,000万PVのサイトをサーバー移設した話

先日サーバー移設が無事に完了し、全ロールのサーバーで正常稼働が確認できたので、気持ちが熱いうちに記事にしておこうと思います。

概要

• 5年前から週末・平日の夜に開発・運営しているとあるレビューサイトをサーバー移設した話です。
• 規模感としては月間1000万PV、ユーザー数30万人、移設前のサーバー台数は6台です。
• 技術的な課題に対する解決方法、導入した技術などは別にしようと思います。
• 今回は移設理由、移設手順、全体スケジュール、移設直後の感想のお話です。

なぜサーバー移設したのか

• 結論を言えば、2015年9月頃にサーバー会社から年末までの移設命令が来たからです。その会社が某社と業務提携をし、データセンターが統合されるのでなんとかかんとか。
• 元よりオンプレミスな環境には不満を持っており、クラウドサーバーへの移設は検討をしていたので、重い腰をあげる良い機会になりました。

移設前のサーバー構成

• 全台オンプレミス環境
• Web x 3
• DB x 2 (Master/Slave)
• Image x 1

移設後のサーバー構成

• 全台クラウドサーバー
• Web x 3
• Batch x 1
• DB x 2 (Master/Slave)
• Image x 1
• Mail x 1

まず初めに何をしたのか

現状の構成と移設後の構成を手書きで書いた

既存の構成、仕様を洗い出しました。各サーバーで動いているミドルウェア、利用状態をA4のホワイトボードに何度も書き直しました。

移設予定日を最初から決めた

スケジュールを逆算で作る際に必要なので、最初から決めました。直前をゴールとせず一回失敗しても余裕がある日を移設予定日としました。

やること・やらないことルールを決めた

ルールはシンプルにしました。何か問題が発生した際やディレクターからの割り込み業務が入った際の断る理由として役立ちます。

• やること

  • やらないとユーザー、サイトに悪影響を及ぼす業務。これはやるしかありません。
  • それ以外はしない。基本的に移設業務のみとする。

• やらないこと

• 開発メンバーは把握していないスクリプト、ミドルウェアは移設しない。導入しない。

  • リファクタリング
  • メジャーバージョンアップ
  • サイトの改善系差し込みの業務
  • 自分の技量に合わない新技術の導入、挑戦

スケジュールを簡単に立てた

スケジュールを立てる際には下記のルールとしました

• 本業に支障がでるスケジュールは立てない
• 健康を害するようなスケジュールは立てない
• 最終期限に余裕を持たせること

その上でスケジュール第一版として週単位での作業目安のスケジュールを立てました。ここで日単位でスケジュールを立てなかったのは、プロジェクトの開始初期は技術的な課題が発生しやすく多少のスケジュール変更もしやすくしました。

サーバー構築方針

• 既存のサーバーは動作しているミドルウェア、技術的に把握していな箇所が多く、整理も兼ねて正しいサーバー構築手順書を作成するために今回は手動構築としました。
• 手順書は全て
  • コンフルエンスにまとめました。
• プロビジョニングツール化はサーバー移設後に完成した手順書を元に書き起こす予定です。

プロジェクト中盤でやったこと

• スケジュールの進捗を確認し、他開発者への助けが必要かどうかの判断をしました。これはギリギリになってリソースを割いても間に合わせない可能性があるので、早めの判断が必要です。
• 今回の場合ですが、一部想定外の作業が発生し明らかにスケジュールに間に合わないと判断したので助けを求め、作業を分担することで解決しました。

プロジェクト後半でやったこと

• 後半になると残件の残り僅かとなるので、issueに細かい粒度で全てを列挙し日別で作業を割り当てました。その結果、予想以上に残件が多いことに気づき、作業分担と予定立てが出来た点が良かったです。

メンテ直前でやったこと

• 担当者と口頭でリハーサルを行いました。実際にコマンドは叩かずに、メンテナンス手順書を読み上げながら確認しました。その結果、作業の漏れや実行順序の入れ替えによる効率化など改善が出来ました。
• メンテナンス手順書においては、実行予定のコマンドがコピペで使えるように工夫しました。

移設して良かったこと

• 移設準備作業を通じて既存構成の懸念点、セキュリティ的課題など多数の問題を発見することが出来た。
• 念願のクラウド環境を手に入れることができ、サーバー調達が容易になった。
• これら移設作業を通じることで幅広いインフラ知識を身に付けることが出来た。
• クラウド環境ならではのテクニックを得ることが出来ました。DBサーバーの移設時にダンプ＆圧縮＆解凍処理に長時間がかかり、メンテナンス時間が長引く恐れがあったのですが、その時だけ高額のプランを利用することにより、一時的にネットワーク帯域、CPUコア数、メモリースペックを最大限にあげることで、処理の短縮化が出来ました。
• 分割移設が出来たことが良かったです。事前に画像サーバー、メールサーバーを段階的に移設することで最終移設日の作業範囲を減らすことが出来ました。

感想

まずは無事に移設できて良かったです。作業の過程で見つかった課題はこれから徐々に潰していく予定です。また移設の過程で自分では解決できない問題がいくつも発生し、開発・インフラエンジニアの友人の助言によって問題解決が出来ました。友人達にはとても感謝しています。今回唯一残念だったことは、最終メンテナンス日が友人の壮行会と重なってしまい参加できなかった事でした・・・・。

総じて楽しく移設できたので、引き続きサイト改善に努めたいと思います。