systemdソケットアクティベーション移行で実現するゼロダウンタイム起動設計

ソケットアクティベーションが解決する「起動タイムラグ」問題

Webサーバーやアプリケーションサーバーを再起動する際、クライアントからの接続がいったん拒否されてしまうのは、従来のサービス管理における根本的な制約です。サービスが停止してからListenソケットを閉じ、起動後に再度Bindするという一連の流れは、数百ミリ秒から数秒の「空白」を生みます。トラフィックの多い環境では、この空白が接続エラーとして利用者に届いてしまいます。

systemdのソケットアクティベーション（Socket Activation）は、この問題に対するアーキテクチャ的な解答です。仕組みの骨格はシンプルです。systemdが事前にソケットをBindしてListenを開始し、接続が来た時点でサービスプロセスを起動して、そのソケットのファイルディスクリプタをサービスに渡します。サービスが起動を完了するまでの間も、カーネルのTCPスタックがSYNパケットをキューに保持するため、クライアントは待機状態を維持したまま接続が成立します。

この考え方はsystemd初期から存在しましたが、2026年現在のRHEL 9系・Ubuntu 24.04 LTS・Debian 12以降の環境ではsystemdのバージョンが252以上に達しており、ソケットアクティベーションの安定性と機能の充実度が増しています。移行コストが下がっている現状は、実運用への組み込みを検討する好機といえます。

移行前に理解しておくべきユニット設計の基本

ソケットアクティベーションへの移行では、既存の.serviceユニットに加えて.socketユニットを作成します。この2つのユニットは名前の一致によって自動的に紐付けられます。たとえばmyapp.socketとmyapp.serviceは同名の前半部分（myapp）でsystemdが関連を自動認識します。

.socketユニットに最低限記述が必要なのは、TCPの場合はListenStream、UDPの場合はListenDatagramのいずれかです。UnixドメインソケットもListenStreamでパスを指定できます。[Socket]セクションにはAccept=noを明示することが推奨されます。これはデフォルト値ですが、接続ごとにサービスインスタンスを生成しない動作を意図として示すために記述しておくとよいでしょう。

一方、既存の.serviceユニット側で重要なのは、アプリケーション自身がソケットをBindしようとする設定を残したままにしないことです。ソケットアクティベーション環境ではsystemdが渡したファイルディスクリプタをSD_LISTEN_FDS環境変数経由で受け取って使用します。アプリケーションがlibsystemdのsd_listen_fds()関数またはそれと互換性のある仕組みに対応していれば、自前のBind処理は不要になります。Node.jsならlisten fd=3、Goなら独自実装やサードパーティライブラリでの対応が一般的です。

実際の移行手順：.socketユニットの作成とサービスの切り替え

ポート8080でListenするWebアプリケーションmyappを例に、ソケットアクティベーションへの移行手順を整理します。

まず/etc/systemd/system/myapp.socketを新規作成します。内容は次の構成が基本です。

[Unit]
Description=myapp socket

[Socket]
ListenStream=8080
Accept=no

[Install]
WantedBy=sockets.target

次に既存の/etc/systemd/system/myapp.serviceを確認・編集します。ExecStartの変更は原則不要ですが、アプリケーションが独自にBindしていた場合はその設定をアプリ側の設定ファイルや起動引数から取り除きます。また[Unit]セクションにRequires=myapp.socketとAfter=myapp.socketを追記しておくと依存関係が明示的になります。同名のソケットユニットが存在する場合はsystemdが自動で関連付けるため厳密には必須ではありませんが、設定の意図を読み取りやすくする効果があります。

設定が整ったらsystemctl daemon-reloadでユニットファイルを再読み込みします。次に従来のmyapp.serviceの自動起動を無効化し、代わりにmyapp.socketを有効化・起動します。

systemctl disable myapp.service
systemctl enable --now myapp.socket

この時点でポート8080はsystemdが保持しています。最初のリクエストが届いた瞬間にmyapp.serviceが自動起動し、起動完了後にファイルディスクリプタが引き渡されます。起動中もカーネルのTCPキューが接続を保持するため、クライアントから見ると接続が切れません。

移行後の動作検証とよくある落とし穴

移行後の検証では、まずss -tlnpコマンドでポートがsystemdのプロセスによって保持されているかを確認します。ポート8080に対してusers:(("systemd",pid=1,...))という表示が出ていれば、socketユニットが正しく機能している証拠です。

続いてsystemctl status myapp.socketとsystemctl status myapp.serviceの両方を確認します。myapp.socketがactive (listening)であり、まだリクエストがなければmyapp.serviceはinactiveのままです。最初のリクエストを送った後にmyapp.serviceがactive (running)へ遷移することを確認するのが定石です。

移行時に現場でよく遭遇する問題として、アプリケーションがSD_LISTEN_FDSを使わずに自前でBindしようとし続けるケースがあります。この場合、すでにsystemdが保持しているポートにBindしようとしてAddress already in useエラーで起動失敗します。アプリケーションの設定ファイルからポート指定を取り除くか、sd_listen_fds()相当の仕組みに対応するコード変更が必要です。

また、.socketユニットと.serviceユニットの名前が一致しない場合は自動的な紐付けが機能しません。リネームが必要な場合は[Socket]セクションにService=別名.serviceを明示することで対処できます。

切り戻し手順と運用上の注意点

ソケットアクティベーションを無効化して元の構成に戻す場合、手順は移行の逆順です。まずmyapp.socketを停止・無効化し、myapp.serviceを再度有効化します。

systemctl disable --now myapp.socket
systemctl enable --now myapp.service

切り戻しの際は、アプリケーション側の設定ファイルを元に戻すことを忘れないようにしてください。移行時にポート指定を削除していた場合、切り戻し後のサービスはListenするポートを認識できず、起動しても機能しない状態になります。変更した設定のバックアップを事前に保持しておくことが重要です。

運用上で見落としやすいのは、ソケットアクティベーションが有効な状態でsystemctl stop myapp.serviceを実行してもソケットはsystemdが引き続き保持している点です。次のリクエストが届いた瞬間にサービスが再起動します。サービスを完全に停止させたい場合はsystemctl stop myapp.socket myapp.serviceのように両ユニットを同時に停止する必要があります。メンテナンス時に意図せずサービスが起動されることを防ぐために、この挙動はあらかじめチーム内で共有しておくことをお勧めします。

2026年の現行環境における差分と実務への影響

2026年時点の主要ディストリビューションにおける環境差分を整理します。RHEL 9（systemd 252系）、Ubuntu 24.04 LTS（systemd 255系）、Debian 12（systemd 252系）がそれぞれ現行の長期サポート版として普及しており、いずれもソケットアクティベーションの全機能が安定して使えます。

systemd 255以降ではFileDescriptorName=ディレクティブによる名前付きファイルディスクリプタの受け渡しが強化されており、複数ソケットを扱うアプリケーションでの識別が容易になりました。Ubuntu 24.04 LTSを採用している環境ではこの機能を活用することで、より柔軟なマルチソケット構成が実現できます。

コンテナ環境との関係も変化しています。Podman 4.x以降ではsystemdソケットアクティベーションと連携するための--sdnotifyオプションが成熟しており、コンテナ内サービスをホスト側のsystemdソケットで制御する構成が実績を持ちつつあります。一方、Docker環境ではsystemdとの統合は依然として間接的であり、同じ設計思想を適用するには構成面での工夫が求められます。

Kubernetes上のサービスはソケットアクティベーションの直接的な恩恵を受けにくい面もあります。しかしVMベースのインフラや、systemdを中心に構成されたベアメタルサーバー、またはsystemd-nspawnコンテナを活用した環境では、依然としてソケットアクティベーションは有効な設計選択肢です。

ゼロダウンタイム起動の実現にはソケットアクティベーションだけでなく、アプリケーション自体のグレースフルシャットダウン対応（処理中のリクエストを完了してから終了する能力）も欠かせません。systemdのTimeoutStopSecやKillSignalの適切な設定と組み合わせることで、初めて真のゼロダウンタイム運用が成立します。移行の際はアプリケーション側の対応状況も合わせて確認することが、安定した運用への近道です。