はじめに
こんにちは、価格.com基盤システム部のTです。
今回は、私たちのチームが行なったサーバーリプレイス作業の振り返りを共有いたします。
経緯
ホストサーバーのストレージ機器の保守期限のため、対象ホストサーバーに載っているすべてのサーバーのリプレイス対応が必要となりました。
当リプレイス作業はすべて自分で行なうわけではなく、サーバー構築などを実施してくれるインフラ担当チームに協力いただきました。
チームとしては規模の大きいリプレイス対応となったことと、私自身はじめてのリプレイス作業のため、対応についての良かった点と悪かった点についてお伝えできればと思います。
対象サーバー
- DBサーバー
- APサーバー
- （WEBサーバー）
対象環境
- 開発環境
- 検証環境
- 本番環境
リプレイス対応について
リプレイス対応で取り組んだおおまかな内容について記載いたします。
事前作業内容
関係者でキックオフ
OSやストレージ容量などの協議、決定。
ここで当初リプレイス対象であったWEBサーバーについては今回のリプレイス要因であるストレージホストサーバーの移行のみで対応することとなったため、リプレイス対象からは除外しました。
WEBサーバーもリプレイスする予定ではありましたが、全体工数と影響を考えて、可能な限りリプレイス対象を減らす方針としました。
全体スケジュールの作成
何かあったときのことを考えて、ストレージの保守期限の半月前をゴールとして逆算し作成。
作成にあたり、数年前にも小さな規模でしたが、別の方がサーバーリプレイスを実施していたため当時の作業手順書やスケジュールを確認しました。
この過去作業手順書のおかげで、自分なりに全体のスケジュールのイメージがつき、それぞれの環境、サーバーごとの修正案件や必要な作業を洗い出しまで行なえました。
サーバー構築・受け入れ確認
事前に協議した仕様に基づいてサーバーを構築するよう依頼し、サーバーの構築はインフラチームに実施していただきました。
構築が完了した後、構築されたサーバーが要件を満たしているかどうかを徹底的に確認。
確認内容としては、OSのインストール、ネットワークの設定、セキュリティの構成などが含まれていました。
受け入れの確認手順は開発部門全体に共有されていた手順があったので非常に助かりました。
リプレイスに関わる修正
リプレイスのついでに課題となっていたフォルダ構成やサーバー名を修正しました。 影響のあるアプリケーションの修正およびテストを実施、この作業は通常の開発業務の内容とほぼ同じでした。
動作確認
一部のアプリケーションはリプレイス対応の影響で修正しましたが、修正の有無にかかわらずすべてのアプリケーションの動作確認を実施しました。
環境が複数あるため、必要十分な動作確認について非常に悩みましたが、この確認内容についても、過去手順が非常に参考になりました。
自分なりに動作確認手順を作成し、上長に相談、指摘修正といったプロセスで進めました。
移行当日
先述した移行のための作業を済ませ迎えた移行当日、事前に当日用スケジュールを作成し、インフラチームと連絡を取りながら実施しました。
移行当日ではシステム停止時間を意識すると思いますが、担当システムの仕組みとして、WEBサーバーが稼働していればシステムを停止する必要がありませんでした。
また当日のリプレイス対象はAPとDBで、WEBサーバーのホスト移行は別日にしたため、システムを停止することなく実施できました。
リプレイスのような運用作業を考慮した構成を考案してくれた方に感謝です。
当日の作業内容はおおまかに次のとおりです。
- 日次で作成されるファイルなどの移行
- サーバー上のアプリケーションの無効化
- DBバックアップ・転送・復元
- CNAME切り替え
- システム動作確認
- サーバー上のアプリケーションの有効化
「DBバックアップ・転送・復元」、「CNAME切り替え」はインフラチームに担当していただき、特に問題なく無事終了しました。
移行振り返り
良かった点
過去に実施したリプレイス作業履歴が残っていたこと
私の功績ではありませんが、過去のリプレイス作業履歴のおかげで、スケジュール全体のイメージが簡単につくことができました。
ただ、残っている資料は数年前のものなので、社内ルールの変更などですべてを鵜呑みにすることは危険だったため、あくまで参考までに留めました。
次回以降のため、今回実施した内容は細かく残しておこうと強く実感しました。
リプレイス作業当日の細かいタイムスケジュール作成
自チームだけの作業ではないことが分かっていたので、コミュニケーションを円滑にするため、事前にタイムスケジュールを作成し、共有しました。
作成のため各作業の洗い出し、自チームの担当作業かインフラチームの作業か各作業の時間がどれだけかかるか徹底的に確認しました。
スケジュールを作成したことにより、当日の実施イメージなどもつかめたため、良い取り組みでした。
不明点があったらすぐ確認
リプレイス前後でホストサーバーの構成が大きく変更となったため、チーム内で管理していたドキュメントを修正しました。
サーバー構成以外にも、DB容量やRAIDなど修正点があったためそれぞれ確認。
不明点があったらすぐ確認する意識で進め、ドキュメント反映内容もチーム内でしっかりレビューし、確認漏れもなく修正ができました。
その他にも上長への確認も適宜実施し、指摘による手戻りを極力無くしました。
全体スケジュールの適当なバッファ
初のリプレイス作業で工数見積もりも多少のずれがあると見込んでいたため、見積もりの1.2倍ほどでスケジュールを作成していました。
多少スケジュールに余裕があることは心の余裕にもつながるため、組み込んでよかったと実感しています。
リプレイス作業後の動作確認
リプレイス作業は移行したら完了ではありません。
移行後に数々のアプリケーションが日次、週次、月次などの間隔で動くため、それぞれの動作結果を確認していきます。
この動作確認についても、細かい確認手順（ログの場所など）を作成し、自分以外の誰が実施しても問題なく完了できる内容に仕上げました。
課題解消へ向けた取り組み
リプレイス作業とは違うついでの要素ですが、以前から課題として認識していたフォルダ構成の一貫性の無さについてこのタイミングで修正しました。 他にも移行タイミングで実施できる課題解消の対応はありましたが、全体スケジュールを考えて、無理なく組み込める修正を実施できたことはよかったと思います。
悪かった点
他メンバーから見えない環境でインフラチームとやり取りしていた
インフラチームと自分の間で色々と連絡を取り合っていましたが、自チーム内メンバーからは見ることのできないチャットでのやり取りでした。
もちろん、内容についてはチーム内にも共有を怠らないようにしていましたが、共有のやりづらさを感じていました。
チャット内のメンバーに自分以外のメンバーも含めるとかえって混乱を招くかと思い、あえてこの形式のやり取りをしていましたが、
結果的には全員含めた方が共有が円滑に行うことができたため、誤った方法だったと反省しました。
サーバー廃棄作業漏れ
新サーバーが稼働してからしばらくして、インフラ担当の方から連絡をいただき気がつきました。
もともとの全体スケジュールとしても完全に抜けてしまっていたため、完全に考慮漏れでした。
使用していないサーバーのため、結果的には廃棄していないことでシステムへの影響は基本的にはありませんでしたが、
不要なサーバーを稼働させておくのは無駄でしかないので、今回の手順には加えておき、次回は忘れないようにしました。
インフラ担当への回答が遅延してしまった
インフラ担当へは適宜質問を双方向で行っていました。
途中込み合ったタイミングがあり、未回答の質問について見落としがあり、遅延となってしまいました。
質問についても、タスク化する等日々使用しているタスク管理ツールに落とし込むことによって、見落とすことがなくなるので、
そのようなツールを活用するべきでした。
感想
キックオフからリプレイス作業完了まで約半年ほど当作業を進めてきましたが、サーバー周りの知識やリプレイス作業の進め方について非常に勉強になりました。
結果としてはリプレイスを起因とする障害は発生せず、無事作業を完了できました。
不明点の解消や相談する環境が整っていたことが、この結果につながっている大きな要因だと思います。
また、今回のサーバーリプレイスと同時に、課題となっていたフォルダ構成の見直しもできたため、単純な運用作業だけでなく、より良い環境に課題を解消していく対応を含めていたことが高いモチベーションを保って実施できたと考えています。
だた、悪かった点にも記載したとおりドキュメント不足について痛感するところもあったので、次回以降のリプレイス作業をより簡単に行なえるよう整えていこうと思います。
カカクコムでは、ともにサービスをつくる仲間を募集しています！
カカクコムのエンジニアリングにご興味のある方は、ぜひこちらをご覧ください！
