きゃまなかのブログ

新卒6年目の WEB エンジニアです。 直近3年間は大規模システムの運用を担当していました。 今期から開発チームに移動になって、Java を勉強しています。 好きな言語が Ruby なので、Ruby 系の記事が多いです。

【Apache】graceful 再起動でホットデプロイを行う

概要

自分のお仕事は運用メインなので、リリース作業を行う機会が多いです。

正直、数年間同じ仕事をしているので、リリース作業は慣れましたし飽きました(苦笑)

そこで、少しでも今のリリース作業が簡略化できる方法が無いか調べてみました。

そこで見つけたのがホットデプロイです。

現在のリリース手順とは、ロードバランサから数台ずつサーバーをサービスアウトしてリリースして戻す(サービスイン)と言うものです。

リリース時にサーバーの再起動(詳しくは Apache の再起動)を行うため、ユーザー影響がないようにサービスアウトしています。

ホットデプロイを導入すると、アプリケーションの修正を行っても、サーバーの再起動を行わずに本番環境に反映させることが出来ます。

と言うことは、ロードバランサから数台ずつサービスアウトせずに、一気に全台リリース出来るようになりますよね??

実現すれば、かなり作業が簡略化されます。

自分が運用しているシステムは LAMP 環境が多いので、LAMP 環境でホットデプロイが出来るか調べてみました。

はじめに

LAMP 環境とは?

Web サービスを開発する際の環境の組み合わせで、それぞれの頭文字も取ったものです。

OS  Linux
Webサーバ  Apache
DB  MySQL
プログラミング言語  PHP ( Perl, Python )

参考:LAMP (ソフトウェアバンドル) - Wikipedia

多くの企業で導入実績があり、沢山のモジュールやプラグインが配布されているため、拡張性に優れている気がします。

全てオープンソースソフトウェア(無償)なので個人でも簡単に環境構築できます。

ホットデプロイとは?

アプリケーションに変更を加えた際に、サーバーのサービスアウトと再起動を行わずに運用環境に反映させる仕組みのことです。

詳しくは定義されていないので、サービスアウトと再起動なしで、アプリケーションの更新ができれば、なんでもホットデプロイと呼ばれる気がします。

参考:ホットデプロイとは - IT用語辞典 Weblio辞書

ホットデプロイ導入

最初は Ruby on Rails で良く使われている Unicorn みたいに Apache も出来るんじゃないかと思っていました。

誰かしら便利なモジュールを作っていると思ってました。けど無かったです。

調べてみたら、Apache でサービス停止をせずにプロセスを新しく立ち上げ直す方法があったのでそれを使おうと思います。

graceful で再起動

サービスの停止をせずに、アプリケーションの変更を取り入れて、プロセスを新しく立ち上げ直してくれます。

親プロセスは、子プロセスに現在のリクエスト処理が完了したら終了するように命令します。

親プロセスは設定ファイルを再読み込みして、ログファイルを開き直します。

restart と違って親プロセスは終了しないので PID はそのままです。

子プロセスが徐々に無くなるにつれて、新しい設定を反映した子プロセスが立ち上がりリクエストに応答します。

graceful では再起動する前に、設定ファイルの構文チェックをしてくれます。

誤りがあった場合は、エラーメッセージを出力し、サーバーの再起動は行いません。

コマンド
$ sudo apachectl -k graceful

又は

$ sudo /etc/init.d/httpd graceful
Gracefully restarting httpd:

参考:Stopping and Restarting Apache HTTP Server - Apache HTTP Server Version 2.4

注意点

SSL 証明書の更新や、モジュールの追加を行った場合は、graceful では反映されないケースがある様なので注意してください。

owen11.hateblo.jp

まとめ

Apache を利用しているサーバーでは graceful を利用することでホットデプロイ出来ることが分かりました。

今までアプリケーションを修正した際には、何でもかんでも(念のため) restart していましたが、 今後は graceful や reload など使い分けたいと思います。

SSL 証明書の更新や、モジュールの追加を伴うリリースは頻度が少ないので、基本は graceful を使おうと思います。

まだ実運用はしていませんが、これで通常のリリース手順を簡略化できたと思います。

ただし、全台一気に行うリリース作業は時間が短縮されましたが、事故リスクは高まりました。

development 環境で開発して、いきなり production 環境へのリリースではなく、staging 環境に一旦リリースして確認することが大事だと思います。