ニフティに入社して10年以上エンジニアをしておりますが、
これまでに複数のシステムを新しく作ったり、廃止したりしました。
システムを新しく作ったことがある方は多くいらっしゃると思いますが、
廃止に携わった・実際に廃止作業をした方というのはあまりいらっしゃらないかもしれないと考えて、この記事を書きました。
システム廃止作業に取りかかる前に
システム廃止を行う場合は、大きく2つに分かれると思います。- 利用がなくなったため廃止する
- 利用はあるが、価値が低下しているので廃止する（別の方法に変更する）
そのため今回は前者の「利用がなくなったため廃止する」場合を想定して書いていきます。
廃止想定システム
AWS環境で構築された、以下構成のシステムを廃止する想定で記事を書いていきます。赤枠で囲ってあるのが廃止対象システム、黒枠は廃止しないシステムです。
廃止の段取り
事前作業
記録の準備
はじめに、廃止作業を記録する準備をします。皆さん普段から作業を行う際はチケットなどにどのような作業を行ったか、作業のログなどを残していると思います。
システム廃止作業でもそれは同じです。
後述する事前調査時には対応不要だと考えていた部分などが、記録を取るうちに対応が必要な部分であると気づいたり、万が一復旧作業を行う際には、作業記録を頼りに復旧計画を練ったりします。
システム構成の調査
システム構成をできるだけ正確に把握しましょう。これにより副次的な障害発生を防ぐことができますし、廃止する担当者の心理的不安を軽減できます。
また、廃止による定量的な効果測定を行うためにも必要な段取りです。
今回は想定として具体例がありますが、通常であれば以下のような観点が必要になると思います。
- サーバにディスクやNFSがマウントされているか
- LBを利用しているか
- 他システムとの連携はないか
- インフラのコード管理（IaC化）
廃棄予定になってからのIaC化はなかなか大変ですが、初期構築時からIaC化されていれば、
システム構成を調査するにあたって役立つと思います。
今回の例では、廃止対象システムで利用しているEFSが、廃止しないシステムからも
利用されていることがわかりますので、廃止しないシステムに移管します。
以下が廃止作業後のイメージとなります。
※✕印が廃止対象
監視ありの状態のままシステム廃止を進めてしまうと、急に「システム落ちてます」といった連絡が来てしまうことになります。
アクセス状況調査
利用がなくなった前提ではありますが、廃止前にはアクセス確認を行いましょう。廃止の中心となるアプリケーションのログを確認するのはもちろん、アプリケーションの前段にあるApache, nginxといったWEBサーバのログ、LBのログなども必要に応じて確認します。
これによって、現状アクセスがあるか・ないか、アクセスがある場合は利用の頻度がどの程度かと言った点を確認します。
認証などが必要ないアプリケーションのログを確認する場合、自身がアクセスしたログを「どこからかまだアクセスがある」と誤認することがありますので注意が必要です。
ここまではログからアクセス状況を調査する方法に触れましたが、もしアクセス状況がCloudWatchのダッシュボードなどにわかりやすくまとめられていると、ログ調査を行うよりは楽にアクセス状況を確認することができます。
廃止するシステムが復旧可能か検討
システムの利用がないという前提ですが、復旧が可能かどうかの検討も行います。 例えば、以下のようなポイントを廃止前に検討する必要があります。- システムのソースコードが手元に存在するか
- OSSで提供されているツールなどは、同じバージョンのソースが手に入らない場合もあります
- システムのリリースを行うことができるか
- リリース手順などが残っているか
- 手順などがない場合、自身やチームのスキルで復旧が可能か
- DBは復旧可能か
- DBデータのバックアップがあるか
- ドメインの所有権は持ち続けているか
- ドメインが変更になるとリンク切れや、SEOへの影響が考えられます
システムを廃止する
各種バックアップの取得
システムの復旧ができるように、各種バックアップを取得していきます。バックアップを取得する対象の例を以下にあげます。
- アプリケーションの設定ファイル
- DBの設定ファイル、データバックアップ
- cronなどのスケジュール
そのような場合はOSレベルの設定ファイルをバックアップしておくと、より安心です。
システムの一時停止
システムの全リソース（サーバなど）を廃止する前に、一度システムの稼働を停止します。アプリケーションの稼働に利用しているコンテナやプロセス、サービスを停止状態にします。
これは、システムを停止したことにより、問題が発生しないということを確認するためです。
停止する期間は過去に利用されていた頻度を参考にするのがよいと思います。
例えば、毎日利用されていたシステムであれば数日～1週間程度の停止でいいでしょうし、
月に1度利用されるようなシステムですと、ひと月～ふた月程度の期間停止していれば利用者が困ることはないと考えられるでしょう。
システム稼働に必要な周辺リソースの切り離し
システム本体を廃止する前に、前述のシステム構成の調査で記載した様々な関連リソースの切り離しを行います。これにより、今回の構成例では
- ELB経由で停止したアプリケーション以外へのアクセスができなくなる
これにより、今回の想定からは外れるのですが
- 実はELB経由で利用されている別のアプリケーションが廃止対象のEC2に相乗りしている
以下の接続を切り離していくイメージです。
※DynamoDBおよびS3との接続は、前述のシステムの一時停止を行った際に切り離されている想定です
システムが稼働しているサーバなどの停止
各種リソースを切り離した後は、システムが稼働しているサーバなどを停止していきます。今回のシステム構成例ですと、EC2を停止するイメージです。
なぜこのような段階を踏むかというと、別システムが廃棄対象システムへアクセスしに来る、かつアクセス頻度が低い場合などは、事前調査における影響確認が難しいためです。
例えば、ひと月に一度別のシステムからファイルの取得が行われていた場合、ログイン・ログアウトのログをしっかりと確認すれば問題を防ぐことはできますが、なかなか発見が難しい場合もあります。
このような漏れがあった場合、システム廃止済みだと復旧不可能になる場合があります。
その回避のために一旦サーバなどを停止するような段階を踏みます。
より慎重を期すのであれば、この際に切り離した各種リソースへのアクセス状況を再度確認します。
こちらは、別システムからのアクセスが本当にないかを特定するために役立ちます。
システムの廃止
多くの方はクラウドサービスでシステムを運用されているかと思います。そういった場合はAPIやCLI、もしくはWEB画面でシステム稼働していたリソースを削除しましょう。
はじめてリソースを削除する際は緊張するかもしれませんが、ここまでの段取りを取っていれば、復旧する準備も十分にできているはずです。
安心してリソースを削除しましょう。
今回のシステム構成例で廃止を行った場合は、以下の状態になります。
廃止後の作業
効果測定
せっかくシステムを廃止したのですから、効果を測定して自分やチームの成果にしましょう。今回廃止したシステム例は、利用者がいない前提のシステムでしたので、どれだけコスト削減に寄与したのかを測定するのがいいと思います。
もし、利用者がいるシステムの場合は、コスト削減効果に加えて、利用者からの問い合わせやクレームがどの程度あったか・どのような内容だったかも測定するといいかもしれません。
最後に
いかがだったでしょうか？様々な事情はありますが、システムの廃止というのはいつか訪れると思います。
そんなときにこの記事が少しでも役に立つと嬉しいです。
ちなみに、本記事を書いている間も小規模な社内向けシステムの廃止作業中です。
現在は「システムが稼働しているサーバなどの停止」段階まで進んでいます。
We are hiring!
ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ Tech TalkやMeetUpも開催しております！
こちらもお気軽にご応募ください！
