DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

SSHパフォーマンス最適化完全ガイド：ZLib圧縮の活用

SSHのZlib圧縮がいつ効果的で、いつ逆効果になるかを学び、低速リンクやテキスト主体の転送で安全に有効化する方法を解説します。

SSHパフォーマンス最適化完全ガイド：ZLib圧縮の活用

Secure Shell（SSH）は信頼性が高いですが、低速なWANリンク、VPN、または頻繁な端末セッションではパフォーマンスが低下することがあります。データがテキスト主体でネットワークがボトルネックになっている場合、Zlib圧縮は効果的ですが、リンクがすでに高速である場合やファイルがすでに圧縮されている場合にはCPUを浪費する可能性があります。

このガイドでは、SSH圧縮が適している状況、クライアントとサーバーでの有効化方法、および実際にワークロードが改善されるかどうかをテストする方法を説明します。

SSHパフォーマンスと圧縮の理解

SSHのパフォーマンスは、ネットワーク遅延、利用可能な帯域幅、転送されるデータの性質など、さまざまな要因に影響されます。たとえば、大きなテキストファイルやログアーカイブの転送、低速接続での詳細なコマンドラインアプリケーションの操作は、もたつきを感じることがあります。ここで圧縮が役立ちます。

ZLib圧縮は、圧縮率と速度のバランスが良い、広く使用されているデータ圧縮ライブラリです。SSHと統合されると、ZLibはデータを暗号化してネットワークに送信する前に圧縮し、受信時に解凍します。これにより、送信されるデータの総量が削減され、転送の高速化と応答性の向上が期待できます。

ZLibがSSHと連携する仕組み

SSH圧縮が有効になると、クライアントとサーバーはZLibの使用をネゴシエートします。確立されると、データペイロード（例：シェル出力、scp/sftp中のファイル内容）は送信者によって圧縮され、受信者によって解凍されます。ヘッダーや暗号化キーなどの実際のSSHプロトコルオーバーヘッドは、通常圧縮されません。SSHクライアントとサーバーのCompressionオプションは、通常ZLib圧縮を指します。

SSH圧縮を使用すべき場合（および使用すべきでない場合）

圧縮を有効にすることは万能な解決策ではありません。その利点は、特定のユースケースとネットワーク状況に大きく依存します。いつ適用すべきかを理解することが、真の最適化の鍵です。

SSH圧縮に理想的なシナリオ

  • 低帯域幅接続: ネットワーク接続の帯域幅が限られている場合（例：DSL、衛星インターネット、混雑したWi-Fi）、送信データ量を削減することで実効スループットが大幅に向上します。送信データが少なくなることで節約される時間が、圧縮/解凍に費やされるCPUサイクルを上回ります。
  • 高遅延接続: 十分な帯域幅があっても、高遅延はインタラクティブなSSHセッションの応答性を低下させます。圧縮は、データが送信される際に可能な限りコンパクトにすることで、大きな出力の「最初のバイトまでの時間」を短縮し、大きな違いを生み出します。
  • 反復性の高いデータの転送: テキストファイル、ログファイル、設定ファイル、ソースコード、その他の構造化または半構造化データは、多くの場合、高い冗長性を含んでいます。ZLibはそのようなデータの圧縮に非常に効果的で、大幅なサイズ削減につながります。
  • 冗長な出力を伴うインタラクティブ端末セッション: 大量のテキスト出力を生成するコマンド（例：大規模リポジトリでのdmesg、journalctl、git log）を頻繁に実行する場合、圧縮によりこれらの出力が端末ではるかに速く表示されるようになります。

SSH圧縮を避けるか注意すべき場合

  • 高帯域幅、低遅延のLAN接続: 高速なローカルエリアネットワークでは、データの圧縮と解凍のオーバーヘッドが、データ転送の削減によって節約される時間を上回る可能性があります。このような場合、ネットワークリンクがボトルネックになる可能性は低く、CPU使用率が制限要因になります。
  • すでに圧縮されたデータの転送: すでに圧縮されているファイル（例：JPEG画像、MP3オーディオ、ZIPアーカイブ、GZipファイル、MP4ビデオ）を圧縮しようとしても、ほとんど効果がありません。ZLibはさらなる冗長性をほとんどまたはまったく見つけられず、サイズ削減はごくわずかで、不必要なCPUオーバーヘッドが追加されるだけです。
  • CPU負荷が高いシステム（クライアントまたはサーバー）: クライアントマシンまたはSSHサーバーのCPU負荷がすでに高い場合、圧縮を有効にするとパフォーマンスの問題が悪化する可能性があります。CPU使用率を監視して、圧縮が過度なストレスを追加していないことを確認してください。

SSHでZLib圧縮を有効にする

SSH圧縮は、クライアント側、サーバー側、または永続的な設定のための設定ファイルを通じて有効にできます。

クライアント側の設定

通常、ローカルマシン（SSHクライアント）から圧縮を制御します。

1. -Cコマンドラインオプションの使用

単一のSSHコマンドで圧縮を有効にする最も簡単な方法は、-Cフラグを使用することです。

ssh -C user@hostname
scp -C local_file user@hostname:/remote/path
sftp -C user@hostname

このオプションは、そのコマンドによって開始された特定のセッションに対して圧縮を強制します。テストや、圧縮が有益であることがわかっている単発の転送に便利です。

2. ~/.ssh/configファイルの使用

特定のホストまたはすべてのホストに対して永続的に圧縮を有効にするには、SSHクライアント設定ファイル（通常Unix系システムでは~/.ssh/configにあります）を編集します。ファイルが存在しない場合は作成できます。

# デフォルトですべてのホストで圧縮を有効にする
Host *
    Compression yes

# 特定のホストでのみ圧縮を有効にする
Host my_remote_server
    HostName 192.168.1.100
    User remote_user
    Compression yes
    Port 2222

# 特定のホストで圧縮を無効にする（グローバル設定を上書き）
Host fast_lan_server
    HostName 10.0.0.5
    Compression no

ディレクティブの説明:

  • Host *: より具体的なHostブロックで上書きされない限り、以下の設定をすべてのSSH接続に適用します。
  • Host my_remote_server: ssh my_remote_serverを使用して接続する場合にのみ設定を適用します。
  • Compression yes|no: 指定されたホストまたはグローバルに圧縮を明示的に有効または無効にします。

サーバー側の設定（オプションですが、制御のために推奨）

通常、圧縮をネゴシエートするにはクライアント側の有効化で十分ですが（サーバーがサポートしている場合）、SSHサーバー（sshd）にも圧縮に関連する設定オプションがあります。これらは通常/etc/ssh/sshd_configにあります。

1. Compressionディレクティブ

デフォルトでは、sshdは通常、クライアントから要求された場合に圧縮を許可します。ただし、明示的に設定することもできます。

# /etc/ssh/sshd_config
Compression yes

サーバーでCompression yesを設定すると、サーバーはクライアントからの圧縮要求を受け入れ、処理できるようになります。noに設定すると、クライアントが要求しても圧縮が無効になります。

2. Compressionディレクティブとdelayed

特に多数の同時接続がある場合のサーバーパフォーマンスを最適化するために、OpenSSHはCompression delayedオプションを導入しました。この設定は、ユーザーが正常に認証されるまで圧縮の開始を遅らせます。これにより、潜在的に悪意のあるボットクライアントからの認証試行（通常は小さく反復性がない）を圧縮するために不必要なCPUサイクルが費やされるのを防ぎます。

# /etc/ssh/sshd_config
Compression delayed

/etc/ssh/sshd_configを変更した後、ファイルを検証し、sshdをリロードまたは再起動します。

sudo sshd -t
sudo systemctl reload sshd

一部のディストリビューション、特にDebianベースのシステムでは、サービス名がsshdではなくsshになっている場合があります。

実用的な例とユースケース

圧縮が実際のメリットにどのように変換されるかを見てみましょう。

例1: scpを使用した大規模ログファイルの転送

比較的遅い接続を介して、リモートサーバーから数ギガバイトのログファイルをダウンロードする必要があるとします。ログファイル（application.log）には、反復性の高いテキストデータが含まれています。

圧縮なし:

time scp user@remote_host:/var/log/application.log .

圧縮あり:

time scp -C user@remote_host:/var/log/application.log .

-Cを追加することで、scpコマンドは圧縮を使用します。特にログファイルがよく圧縮される場合、転送時間が大幅に短縮される可能性があります。

例2: SSH経由でのrsyncパフォーマンスの向上

rsyncは-zでファイルデータ自体を圧縮することも、ssh -Cを介してSSH圧縮を使用することもできます。通常は、どちらか一方を選択してテストし、両方を重ねないようにする必要があります。

rsync -avz /local/path/to/sync user@remote_host:/remote/destination/

rsync -av -e "ssh -C" /local/path/to/sync user@remote_host:/remote/destination/
  • -a: アーカイブモード（パーミッション、タイムスタンプなどを保持）
  • -v: 詳細出力
  • -z: rsync独自の圧縮。低速リンクでのファイル転送にはこれで十分なことがよくあります。
  • -e "ssh -C": リモートシェルとしてssh -Cを指定します。

例3: インタラクティブシェルの応答性向上

大きなファイルシステムでls -lR /のようなコマンドを実行したり、詳細な診断出力を取得したりする場合、圧縮により出力が表示され始めてから終了するまでの遅延を減らすことができます。

ssh -C user@hostname "ls -lR /"

これにより、ネットワーク接続が不良な場合でも、圧縮されていないセッションと比較して、インタラクティブな操作がはるかに高速に感じられるようになります。

圧縮の影響の測定

真のメリットを理解するには、圧縮前後のパフォーマンスを測定する必要があります。timeのようなツール（例に示したように）は、総実行時間を測定できます。ネットワークスループットにはiperf3を使用できます（ただし、これはSSHオーバーヘッドではなく、生のネットワーク速度を測定します）。最も直接的な方法は、実際のファイル転送時間を比較し、インタラクティブセッションの応答性を観察することです。

また、ssh -vを使用して詳細なデバッグ出力を表示することもできます。これにより、圧縮の使用状況が示される場合がありますが、直接的なパフォーマンス測定の方がより指標的です。

ベストプラクティスと高度なヒント

  • 環境でテストする: 特定のネットワーク条件とデータタイプで常に圧縮をテストしてください。あるシナリオでうまく機能しても、別のシナリオでは逆効果になる可能性があります。
  • CPU使用率を監視する: 圧縮を有効にした状態での大量転送や長時間のインタラクティブセッション中は、クライアントとサーバーの両方でCPU負荷を確認してください。CPU使用率が過度に急上昇する場合、圧縮は逆効果である可能性があります。
  • 他の最適化と組み合わせる: 圧縮はSSH最適化の1つの側面にすぎません。以下と組み合わせることを検討してください。
    • 接続多重化: 既存のSSH接続を再利用する（~/.ssh/configのControlMaster、ControlPath）ことで、繰り返されるハンドシェイクのオーバーヘッドを回避します。
    • 暗号の選択: セキュリティ要件が許せば、より高速な暗号（例：[email protected]、[email protected]）を選択します。一部の暗号は他の暗号よりもCPU負荷が低いためです。
    • キープアライブ設定: ServerAliveIntervalとClientAliveIntervalを使用して、非アクティブによる接続の切断を防ぎます。
  • 設定を具体的にする: ~/.ssh/configでグローバルにCompression yesを有効にする代わりに、Hostブロックを使用して、効果が確認されているホストにのみ適用します。

まとめ

低速リンク、大量のテキスト出力を伴う端末セッション、ログやソースツリーなどのプレーンテキストの転送には、SSH Zlib圧縮を使用してください。高速LAN、CPU負荷の高いホスト、すでに圧縮されたファイルではオフにしてください。最も安全な次のステップは、同じコマンドを-Cありとなしでテストし、CPU使用率を監視し、測定結果が明らかに優れているホストに対してのみCompression yesを有効にすることです。