ネットアシスト開発チームの yu-kinjo です。昨今はセキュリティ面での脆弱性対応などにより、以前よりもより迅速なWebアプリケーション・システムの改修が求められるようになっています。今回は、さくらのクラウドでより停止時間を短く済ませる改修デプロイ方法について考えてみたいと思います。
Webサーバー1台構成
まずは、Webサーバーが1台の構成から考えます。これはDBなども含めすべてを1台にまとめている場合と、Webサーバー1台 + DBサーバー1台としている場合の両方を含みます。
Web側が1台の場合、些細な修正や更新であれば無停止でリリースする事も出来ますが、大きめの変更内容が有る場合はやはりダウンタイムが生じます。ただ、このダウンタイムを短くする事は出来ます。
日常的なバージョン追従
サポート期限の有効なOSを利用する、サポート期限の有効な言語バージョンを利用する、サポート期限の有効なWebアプリケーションフレームワークやライブラリを利用し、有効期限が近付いた場合はあらかじめバージョンアップを行います。
当然の事ではありますが、これらが行われていない環境では、脆弱性対応時に「OSのパッケージ更新コマンドの実行」や「利用しているソフトウェアの末尾バージョンのアップデート」だけでは済まない事になり、もしもの際のダウンタイムが長くなります。
デプロイ処理の改善
今採用しているデプロイ方法よりもより改善されたデプロイ方法への移行を進める事で、デプロイ自体の時間を短縮する事が可能です。
- サーバー上のファイルを直接編集している、SFTPでアップロードしているなどの場合は、ソースコードのGit管理への移行を行う。
- その際、Gitリポジトリ上に機密情報をアップするような作業ミスに特に注意する事。
- Git管理になっている場合は、デプロイ時に実行する一連のコマンドの、デプロイスクリプト化を行う。
- git pull でソースをダウンロードするだけでなく、ファイルのパーミッション調整、Webサーバーユーザー（apache, www-data 等）に切り替えてのパッケージインストールコマンド（composer, npm等）や保守用コマンドの実行などをスクリプト化する。
- 既にデプロイスクリプト化が行われている場合、より高度なCI/CDの検討など。
アーカイブの取得
大きめの改修を行う際にはさくらのクラウドの「アーカイブ」機能でディスクのバックアップを取得する事が出来ます。改修のリリースに何らかの理由で失敗した場合、切り戻しが必要になった場合に、アーカイブが有ると切り戻しの手段が増えます。
※ 安全にアーカイブを取得するにはサーバーの停止が推奨されます。メインの切り戻し手段は、Git等のソースコード管理システムからのコード切り戻し、DBバックアップの取得～流し込みなどで対応するように検討し、アーカイブはそれらが上手くいかない際の非常時の代替手段とします。
※ Web側で静的ファイルを保持しDB側でDBを持つような構成においては、アーカイブ取得タイミングが異なると、システムの作りによっては不整合が発生します。その点もご注意ください。
一時サーバーの作成と切り替え（ルータ+スイッチ）
基本的に1台運用にするとしても、大きな改修リリースの際には改修先となる別のサーバーを作成し、入れ替えるような対応が可能です。サーバーの複製にも「アーカイブ」機能が利用できます。
サーバーを入れ替える際にはグローバルIPアドレスを入れ替える方法が最もシンプルです。「ルータ＋スイッチ」を利用している環境であれば複数のグローバルIPアドレスが割り当てられていますので、改修をデプロイしWeb側切り替えOKとなったタイミングで本番公開用のグローバルIPアドレスを入れ替えます。
その際、IPアドレスの入れ替えはコントロールパネル上で行うのではなく、OS側でのネットワーク設定調整が必要になりますので、必要な手順はあらかじめまとめておくとスムーズです。
※複製したサーバーをそのまま起動すると、複製元と同じIPアドレス設定で起動します。複製したサーバーを起動する際は、一旦ネットワークにはつながない状態で起動し、コンソールから設定を調整するなどを検討してください。
※ WebとDB含め1台構成の場合は、切り替え先サーバーにDBデータを移す手順も必要である事に注意してください。厳密さが求められるシステムではバックアップ取得後に書き込まれたデータが生じないよう、メンテナンス中画面を表示する時間を設定しましょう。また、静的ファイルをアップロード可能なサーバーについても rsync コマンド等によるファイル同期が必要になります。
一時サーバーの作成と切り替え（DNS）
サーバーの接続先が直接インターネット（共有セグメント）となっている場合は、DNSで向き先のIPアドレスを変更し、移行先のIPアドレスにトラフィックが流れるようにする対応となります。
その為、DNSのキャッシュにより挙動が変わり一気に向き先が切り替わる訳ではなく、切り替え元と切り替え先の両方にトラフィックが流れる期間が生じる事に注意しましょう。あらかじめ該当ドメインDNSレコードのTTLを短くしておくことで、両方にトラフィックが流れる期間を短縮できます。
※ルータ+スイッチの方で述べたDBデータの移行・ファイル同期に関する注意事項も同様にご確認ください。
また、特にメールを送信するサーバーの場合はグローバルIPが変わる事による影響が大きいです。メール送信が重要なシステムでは始めからルータ+スイッチを使った構成にしておき、サーバーとグローバルIPの対応を任意に差し替えられる状態にしておく方が無難です。
ロードバランサーによるWeb複数台構成
ルータ+スイッチ でグローバルIPを取得している環境に ロードバランサ を導入し、Webサーバーが複数台構成となっている場合、改修内容によっては1台ずつロードバランサから切り離しデプロイ、ロードバランサへの組み込みを行う事で、システム全体としてはダウンタイムを無しで改修をリリースする事が可能になります。
また、1台ずつ切り離しを行う場合、そのサーバーを一時停止する事が可能になりますので、「アーカイブ」機能によるバックアップ取得がより信頼性の高い内容になります。
1台ずつデプロイする事が可能かの判断
例えば、機能面での変更点が無く、各種インタフェース（DB通信、DBスキーマ、各種API通信、ファイルの置き場所など）に変更がなく、新旧バージョンのWebサーバーの混在が許される場合は1台ずつデプロイが可能と考えられます。
上記の変更がない状態でのライブラリ脆弱性対応、フレームワーク脆弱性対応、言語基盤のバージョンアップなどは1台ずつデプロイする事が可能でしょう。
※ユーザーのWebログインセッションが、サーバー上のセッションファイルによる管理の場合、ロードバランサからの切り離しの過程でユーザーのログアウトが発生する可能性が有ります。このログアウトを許容範囲とするかどうかも検討した方がよいでしょう。これを解決したい場合、セッションをDBサーバー管理とする、セッション管理用のRedisサーバーをさらに別で立てておく等の構成を検討する必要が有ります。
ソーリーサーバ機能でメンテナンスページを表示
1台ずつのリリースが出来ない場合はシステムをメンテナンス状態とし、リリース作業を進める必要が有ります。
その際、ロードバランサの振り分け対象がすべて停止している際に代わりの内容を応答する「ソーリーサーバ」が設定可能です。ロードバランサ配下のサーバーに対する監視方法が HTTP/HTTPS/TCP（ping 以外）で、本番のWebサーバー上のWebサーバーサービス（Apache, Nginx等）をすべて停止しておくことで、このソーリーサーバが有効になります。システム側でメンテナンス中表示などの機能を用意していない場合には、代替のメンテナンス中画面として活用する事が可能です。
※ソーリーサーバにも本番サーバーと同様にVIPのループバック設定が必要になる事に注意しましょう。
ソーリーサーバーは本番サーバーとは別のサーバーが必要となります。そのため、基本的には本番サーバー自体でメンテナンス中表示機能を持っていた方が扱いやすいかと思いますが、そのような機能を用意していない場合や、今すぐにWebサーバーをWebから切り離したいような緊急性の高い脆弱性が出た場合などは、こちらの方が有効なケースも考えられます。
まとめ
Webサーバーが1台の場合、ロードバランサによりWebサーバーが複数ある場合でそれぞれなるべくダウンタイムの短い改修デプロイを行う方法を検討しました。生成AI技術の発展により脆弱性が見つかる速度、その脆弱性が悪用されるスパンは早くなる傾向にあります。あらかじめメンテナンスが生じる前提でこういった検討を進めておくとより柔軟な運用が可能になるかと思います。
さくらのクラウドで柔軟性の高い構成を検討される場合は、ぜひネットアシストへご相談いただければと思います。
この記事を書いた人
