1. はじめに
弊社では入社一年目のエンジニアは全三期のOJTを通して部署を渡り歩き、業務や会社について知見を深めていくという制度があります。
OJTについての詳細は、私の同期が入社一年目の経験を基に記事を書いていますので、是非こちらをご覧ください！
そのOJTの第三期で、新システムへの移行に伴い旧システムの運用が停止したため、対象システムが動作していた環境を廃棄するための作業を行いました。
この記事では、システムの廃止で苦労した点、意識した点、学びを共有したいと思います。
2. 意識していた部分
「システムを廃止する」と聞くと一見単純に見えますが、実際には関連システムとの依存関係を一つずつ切り離し、必要なデータを保全し、ユーザー影響を最小化しながら進める必要があるため、想像以上に手順が多く、判断ポイントも多い作業でした。
特に、今回触れた環境は構築年代が古く資料が少ないため調査に手間がかかり、ネットワーク的にも隔離されている特殊な環境であったため、特有の制約があり苦労しました。
2-1. 順番が重要
廃止作業は、いきなりサーバを止めて消すのではなく、段階的に影響範囲を狭めていくのが安全です。
- 入口（ユーザアクセス）を別系統へ逃がす
- 周辺システムとの連携を止める
- 必要データをバックアップする
- ネットワーク的に遮断する（FWを閉じるなど）
- サービスを停止する
- リソースを削除する
2-2. 遮断の段階
今回一番意識したのは「一発で消さない」ことです。
例えばネットワーク遮断やサーバ停止は、どちらも使えなくするという意味では同じですが、復旧可能性と確認のしやすさが違います。
ここでいう「疎通だけ止める」は、FW（ファイアウォール）を閉じて外部から到達できない状態にする、といった対応です。メリットは、サーバ上のプロセスやデータを触らずに入口だけ塞げるため、切り戻しが必要になってもFWを戻すだけで復旧できる点です。
- まず疎通だけ止める（FWを閉じるなどのネットワーク遮断）
- しばらく様子を見る
- 何も起きなければ削除に進む
という順で進めると、万が一のときの切り戻しコストが下がります。
2-3. 「様子見」を挟む
古いシステムは依存関係がドキュメントに残っていないことが多く、停止後に思いがけない影響が出る可能性があります。
そのため、停止と削除の間に時間を置き、アラートや問い合わせなどの遅れて出る症状を拾えるようにし、切り戻しの手間とリスクを最小化しながら進めて行きました。
3. 実際の対応
システム廃止は、次の手順で進めました。
| # | 作業 |
|---|---|
| 1 | 新システムへのリダイレクト設定 |
| 2,3 | 周辺システムとの連携停止 |
| 4 | バックアップ |
| 5 | FW遮断（疎通停止） |
| 6 | システム停止 |
| 7 | リソース削除 |
3-1. リダイレクト設定
まずはじめに、旧システムへのアクセスを、新システムへリダイレクトする対応を行っていました。
事前に経路となるリンクを差し替える対応を行って頂いたのですが、念の為旧システムに来るアクセスを新システムにリダイレクトするようにしました。
Ansibleを用いて該当サーバで稼働するhttpdに設定を反映し、URLに付随するクエリパラメータにより遷移先が異なるため、動作確認は 3 パターン実施しました。
| パターン | 遷移先 | 用途 |
|---|---|---|
| 1 | サービス終了ページ | サービス終了済みの案内 |
| 2 | 新システム | 新システムへのリダイレクト |
| その他 | 新システム | 例外処理 |
3-2. ファイル連携停止
関連システムとファイルの送受信でデータをやり取りしているバッチを停止しました。
この作業では他部署のシステムとの連携を解除するので、業務担当者との綿密な確認が必須でした。
手順としては、
- 先方でファイルの取り込みを停止
- 廃止するシステムでファイルの出力を停止
- 先方でファイルの出力を停止
- 廃止するシステムでファイルの取り込みを停止
の流れで行いました。
関連システムによってpull/pushの向きが違うなどの差がありましたが、基本的には取り込み処理停止→送信停止、の流れで行えば双方でのアラートを予防することができます。
3-3. 通信停止
上記とは別のシステムからのREST APIを使用した通信を切る対応を実施した。
こちらは部署内管理のものだったので構成の確認は比較的簡単にできたものの、開発経験がないPHPだったのと、ソースコードをコピペで作った関係で該当システムに無関係な記述が多量に含まれていて、必要な部分を抽出するのに手間取ってしまいました。
3-4. バックアップ
続いて関連情報のバックアップをしました。
バックアップ対象は色々考えられますが、今回は実際に動作していたソースコード(微妙にgitHub上のものと異なる)、他システムと授受していたファイル群、関連するログ、データベースのダンプ、実体をバックアップしました。
今回はサーバ上でバックアップ用ファイルを作成した後にAWS CLIを用いてバックアップを行いました。
なんとサーバ時刻の時刻がズレておりAWS CLI の認証が通らなかったため、作業前に sudo date -s で時刻合わせを行いました。普通であればNTPサーバの設定を行うところですが該当システムはもうすぐ廃棄するものであるため、dateコマンドで簡易的に時間をあわせるのみにしました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# ソースコード tar czvf ./source.tar.gz {path_to_source} source # ログ tar czvf ./logs.tar.gz -C {path_to_log} logs # MySQLダンプ mysqldump {connection_info} > dump.sql # MySQL実体 # 実際にはmariadb sudo tar czvf ./mysql.tar.gz -C {path_to_mysql} mysqldb # httpdログ tar czvf ./httpd_logs.tar.gz -C /var/log httpd |
|
1 2 3 4 5 6 7 |
# dryrun で転送対象を確認してから本転送 aws s3 cp ./{backup_dir}/ s3://{bucket_name}/{backup_dir} \\ --recursive --dryrun --profile {profile_name} aws s3 cp ./{backup_dir}/ s3://{bucket_name}/{backup_dir} \\ --recursive --profile {profile_name} |
3-5. FWを閉じる
続いてFWを閉じる対応をしました。
対象の環境に設定されているFWの設定を無効化することで、システムの停止をすることなく外部からの通信を遮断することができ、外部から見ると停止しているのと同じ状況を発生させることができます。
この対応を停止、削除の前に挟むことで切り戻しのコストを小さくしつつ、停止状況の再現ができました。
3-6. systemd unit停止
続いて本格的に停止を行っていきます。
停止対象は順番に、
- zabbix-agent: システム状態の監視を行っている 事前にzabbixサーバから該当システムの監視を停止しておく必要があります。
- keepalived: 主系/従系の切り替え用
- httpd: php動作用
- mariadb: phpのデータ保存に使用
です。
システム廃棄のための停止なので切り戻すことはありませんが、万が一のために順番を考えてsystemd unitを停止していきます。
停止したあと一日おいて問題が発生しないか様子見をします。
|
1 2 3 4 5 6 |
# 停止する順番を守る systemctl disable --now zabbix-agent.service systemctl disable --now keepalived.service systemctl disable --now httpd.service systemctl disable --now mariadb.service |
3-7. リソース削除
最後にシステムを稼働させていたリソースを削除し、環境を完全に廃棄しました。
4. まとめ・振り返り
今回のシステム廃止では、単に停止するだけでなく、依存関係の切り離し、データ保全、利用者影響の最小化まで含めて段取り良く進める必要があり、想像以上に調整と確認が多い作業でした。
特に、構築年代が古く資料が乏しいことに加え、ネットワーク的に隔離された特殊環境だったため、調査と作業手順の確立に時間がかかりました。
システム停止に伴うトラブルを最小化するために詳細に調査を重ねた結果、想定外の対応範囲が増加し続け、当初の目標スケジュールを大幅に超過してしまいました。
また、周辺システム連携停止では、双方でアラートや業務影響が出ないように業務担当者と手順とタイミングを丁寧に合わせる必要があり、関係者調整の重要性を強く実感しました。
今回のレガシーシステムの調査、外部システム担当者との調整などの経験を本配属後の業務に活かしていきます。
