キープアライブ

Keep-Alive

IT運用・現場

Keepaliveは、接続を維持・再利用したり、相手との接続が生きているか確認したりする仕組みの呼び名です。HTTPの接続再利用と、TCPの確認用プローブでは意味が異なります。

🐾 猫で例えると？

ハンモックで寝転がりながら、名前を呼ばれて何ですかと言わんばかりにだるそうに首だけ向けて反応するアメショ — 呼びかけに対して最低限の反応だけを返し、接続を維持するアメショ

基本的には孤独を愛するアメショですが、ハンモックでくつろいでいる時に飼い主から名前を呼ばれると、「何ですか？」と言わんばかりにだるそうに首だけを向けて一応反応してくれます。これはまさに、無駄なエネルギー（リソース）を消費することなく「まだ起きてるよ（接続は生きてるよ）」という最低限のシグナルだけを返して通信経路を維持する、TCP Keepaliveで接続を確かめる様子に似ています。HTTP Keepaliveは、通信に使う接続を再利用するという別の意味です。

💻 IT現場における「Keepalive」とは？

IT現場で「Keepalive」と言う場合、大きく分けて「HTTP Keep-Alive」と「TCP Keepalive」の2つの文脈があり、それぞれ目的が異なります。

HTTPの持続的接続は、複数のリクエストで接続を使い回し、接続確立の負担を減らします。HTTP/1.1では原則として持続的接続が既定です。「定期的に信号を送ること」がHTTP Keep-Aliveの定義ではありません。HTTP/2では接続を共有し、複数のストリームを扱います。

TCP Keepaliveは、有効にした接続で、一定時間通信がないときにプローブを送って接続の状態を確認する仕組みです。TCPで応答できてもアプリが正常に処理できるとは限らないため、業務機能のヘルスチェックとは分けて考えます。

⚠️ Keepaliveの仕組みと注意点

接続を維持するのは便利ですが、繋ぎっぱなしにするということは、それだけサーバーのメモリなどのリソースを占有し続けることを意味します。そのため、いつまでも返事がない接続は適切に切断（タイムアウト）する設定が不可欠です。

NginxでのHTTP Keep-Alive設定例

以下はNginxの設定例です。値は説明用で、適切な設定は接続数やクライアント、前段のロードバランサーによって変わります。

# Nginxの設定ファイル（nginx.conf）での例
http {
    # クライアントとのKeepalive接続を維持する時間（秒）
    # 長すぎるとサーバーのリソースが枯渇し、短すぎると再接続の負荷が上がる
    keepalive_timeout 65;

    # 1つのKeepalive接続（パイプ）で連続して処理できる最大リクエスト数
    keepalive_requests 100;
    
    server {
        listen 80;
        server_name example.com;
        # ...
    }
}

keepalive_timeoutは次の要求を待つアイドル時間を設定します。短くすれば接続を早く解放できますが、再接続が増える可能性もあります。現在の接続数と応答時間を測り、設定前後を比較します。

🛠️ Keepaliveを賢く使うためのポイント

現場でネットワーク障害や謎のタイムアウトに悩まされないための重要な設計ポイントです。

前後の機器で意味をそろえる：ロードバランサーとバックエンドのアイドルタイムアウトが食い違うと、切れた接続の再利用などでエラーになる場合があります。大小関係を一律に決めず、製品が推奨する設定を確認します。
接続数の上限を確認する：接続はファイルディスクリプタやメモリを消費します。上限を上げるだけでなく、不要な接続の寿命、プロセス側の上限、必要な容量を合わせて調整します。
TCP設定の適用範囲を確かめる：開始までの待ち時間、プローブ間隔、失敗回数はOSやソケットの設定で異なります。システム全体の値を変更する前に、アプリ単位で設定できるか確認します。

だるそうに反応するアメショにしつこく何度も呼びかけすぎると、許容値を超えて本当にアクセス拒否（無視）モードになってしまいます。システムも猫も、お互いの負荷にならない適度な間隔とタイムアウト設定で生存確認を行うのが、長く良好な関係（通信）を保つ秘訣ですね。