WEBアプリケーションサーバのリプレイス作業で気をつけるべきポイント

WEBアプリケーションサーバのリプレイス作業は、考えることが多くて神経を使う作業です。新しいサーバで動作確認して問題なさそうに見えても、稼働すると問題が発生して、リプレイス前のサーバに緊急で戻し作業をすることはよくあります。自分がこれまで経験、もしくは見聞きしたサーバリプレイス作業の失敗事例をまとめてみました。

なお、僕はインフラを中心にエンジニアの経験を積んできたので、ここに書いてあるものはインフラエンジニアがサーバのリプレイス作業をするときに注意する点をまとめています。アプリ層ではまた異なった点で気をつけないといけないことがあるとは思いますが、今回は記載していません。

リプレイス作業チェックリスト

ミドルウェア

ホスト名, IPアドレスが直書きの設定ファイル

• ミドルウェアの設定で稼働しているサーバのホスト名・IPアドレスを記載しているものがたまにあります。この設定ファイルをそのままリプレイス先のサーバに持っていくと、ホスト名・IPアドレスが変わっている場合は意図しない挙動をしてしまうので、修正をしましょう。

ミドルウェアが特定バージョンのライブラリに依存

• 古いOSで動いているミドルウェアは、特定のライブラリのバージョンを前提として動いているものがあります。いろんな理由でリプレイス後のサーバでもリプレイス前のサーバと同じバージョンのミドルウェアを使いたい場合、古いバージョンのライブラリでないと動かないことがあります。エラーになって動かないで済むのであればまだ気付きやすいですが、一部機能だけ使えなくなっているときは気付きにくいので、注意が必要です。

設定ファイルの書き方が変わる

• ミドルウェアのバージョンによっては、設定ファイルの書き方が変わることがよくあります。起動しようとするとエラーになって落ちるのであれば気付きやすいのですが、挙動のみ変わる場合は意図しない動作のまま動き続ける可能性があります。設定ファイルの記述方法に変更がないか確認をよくしましょう。

ネットワーク

ホワイトリストのIPアドレス設定更新

• サーバから外部のAPIサーバと通信しているとき、そのAPIサーバがIPアドレスの制限をしていることがよくあります。サーバリプレイス後のIPアドレスが変わる場合、APIサーバからアクセスを拒否されることがあるので、新しいIPを事前に外部APIサーバの管理者に連絡する必要があります。

内部ネットワークのプロキシサーバ設定

• サーバが外部ネットワークと通信するとき、その通信は内部ネットワークにあるプロキシサーバを経由していることがあります。これを把握しないままリプレイスすると、接続元のIPが異なるなどの理由でプロキシサーバが接続を拒否することがあるので注意が必要です。curlコマンドなどで外部と通信出来ることを確認するだけではなく、アプリケーションのソースコードにプロキシサーバを利用する設定がないかも確認しておきましょう。

ルーティングテーブルの設定

• 別のネットワークセグメントにサーバをリプレイスしたときには、そのルーティングテーブルの設定が移行前とは異なっていることがあります。ルーティングテーブルの差異が問題を起こすこともあります。例えば、目的のサーバと通信できている場合でも、InternetGatewayを経由する場合とNATを経由する場合ではトラフィックあたりのコストが大きく異なっていることがあるので気をつける必要があります。

IPアドレス制限

• リプレイス予定のサーバに社内からアクセスして、動作に問題なかったのでDNSを新しいサーバに切り替えたら、バランサは社内のIPしかアクセスを許可していなかったという失敗もたまにあります。スマホなど別のネットワークからアクセスして動作を確認すると安心です。

レイテンシー

• リプレイス後のサーバがDBやKVSなど他のバックエンドサーバと通信する場合は、リプレイス前のサーバと比べて通信のレイテンシーが遅くなっていないか確認しておくとよいです。以前、サーバをリプレイスした後に、深夜のバッチが終わらなくなったのでリプレイス前のサーバに戻してほしいという出来事がありました。その深夜のバッチはデータベースと数百万回やり取りをしており、リプレイス前は1msより小さなレイテンシーだったが、リプレイス後は数msのレイテンシーに増えたのでバッチが終わらなくなったのだそうです。バッチを改修した方がいいのではという話ももちろんあるんですが、結局その時は元に戻すことになりました。

ネットワークセグメント

• 意外とあるミスとして、リプレイス後のサーバを本来配置する予定だったネットワークセグメントと異なる場所に配置してしまって、通信が正しく実施出来ないということがあります。例、本番のサーバをSTGのネットワークセグメントに構築していた。特定の通信のみ出来ない場合は気づきにくいので、正しいセグメントに配置しているかどうか確認を忘れずに。

リソース

cpu/memory/disk

• リプレイス前後では、cpu数やメモリサイズなどのサーバスペックは同じになるように揃えると思います。ただ、意外と見落としがちなのがディスクのサイズで、リプレイス前のサーバが特別にディスクサイズを増やしていた場合は、リプレイス後のサーバが稼働するようになった深夜にディスクフルのアラートで起こされることもあります。

重要データの消失

• リプレイス前のサーバに実はクレデンシャルなどの重要なデータやアクセスログが残っていて、バックアップを取らないまま消去してデータを失ってしまったという失敗がたまにあります。リプレイス前のサーバを消去する時は、そのサーバにしかない大切なデータはないかよく確認してから消しましょう。特に、ウェブサーバのアクセスログなどきちんと残しておかないと、警察などから捜査関係で問い合わせが来たり、不正アクセスの確認をしたいときにデータがなくて困ることになります。

ログ

ログローテート設定

• リプレイス後のサーバのログローテートが設定されていない、設定内容が間違っていたなど原因で、ディスクフルとなってしまうことがあります。リプレイス後のサーバが問題なくログローテートされているかどうか、リプレイス後に確認してみましょう。

error/criticalログ

• リプレイス前にはなかったerror/criticalレベルのログをリプレイス後のサーバで出していることがあります。気付かないでそのまま運用してしまうことも多いので、error/criticalレベルのログは通知されるように設定しておきましょう。

ログ転送

• ログ転送に使っているagentのバージョンが変わると、設定ファイルの書き方が変わりログを正しく転送出来きていなかったなんてことが、ログを調査したいときに初めてわかったりすることがあるので、リプレイス後のサーバは意図した通りにログを転送しているか確認しましょう。

=================================================================

以上、サーバのリプレイス時に気をつけるポイントをまとめました。考えてみれば当たり前のことばかりなのですが、リプレイス時に意外と見落としていることがあるのではないかと思います。他にも出てきたら更新したいと思います。誰かの役にたてれば嬉しいです。