【ITニュース解説】Day 55: The Volume Hides nginx's Log Links, and Every Azure Subnet Gives Up Five Addresses

このニュース記事は、システム開発や運用において、私たちが意識せずに行っている設定や、利用するプラットフォームのデフォルトの挙動が、実は重要な影響を及ぼしていることを二つの具体的な事例を通して解説している。一つはKubernetes環境でのログ処理、もう一つはAzureクラウド環境でのネットワークIPアドレス管理に関するものだ。

まず、KubernetesにおけるnginxのログとSidecarコンテナの連携について説明する。Kubernetesでは、アプリケーションをコンテナとして動かし、それらをPodという単位で管理する。この記事では、ウェブサーバーのnginxコンテナと、そのログを読み取るSidecar（補助）コンテナの組み合わせが登場する。通常、nginxのようなアプリケーションコンテナが出力するログは、そのコンテナの標準出力（stdout）や標準エラー出力（stderr）に送られるように設定されていることが多い。これは、コンテナのログをKubernetesのログ収集システムが容易に集められるようにするためであり、公式のnginxコンテナイメージもデフォルトでそのように設定されている。具体的には、nginxのログファイルパス（例えば/var/log/nginx/access.log）が、コンテナの標準出力にシンボリックリンク（別の場所を指し示すショートカットのようなもの）されており、ログデータは直接標準出力に流れるため、コンテナのファイルシステム上には実際のログファイルは存在しない。

しかし、このデフォルトの挙動は、Sidecarコンテナがログファイルを読み取ろうとする場合に問題となる。Sidecarコンテナの役割が、メインのnginxコンテナが生成したログファイルをディスクから読み取り、別の場所に転送することだとすると、ディスク上にファイルがなければ、Sidecarはログを読み取ることができない。ここで登場するのが、Kubernetesの「ボリューム」という機能だ。記事ではemptyDirというタイプの一時的な共有ストレージボリュームが使われている。emptyDirボリュームはPodが作成されるときに同時に作られ、Podが終了すると同時に消滅する。

このemptyDirボリュームをnginxコンテナのログパスである/var/log/nginxにマウントすると、状況が変わる。ボリュームが特定のパスにマウントされると、そのパスに元々あったファイルやディレクトリは、ボリュームの内容によって「隠されて」しまい、アクセスできなくなる。nginxイメージのシンボリックリンクもこの「隠される」対象となるため、nginxはログを標準出力に送る代わりに、マウントされた共有ボリューム内の/var/log/nginxパスに通常のログファイルとして書き込むようになる。そして、この同じemptyDirボリュームをSidecarコンテナも/var/log/nginxにマウントすることで、Sidecarコンテナは共有ボリューム内に書き込まれたログファイルにアクセスし、その内容を読み取ることができるようになるのだ。記事のYAML設定例では、nginxコンテナとSidecarコンテナがshared-logsという名前のemptyDirボリュームを共有し、Sidecarコンテナがそのボリューム内のaccess.logとerror.logを繰り返し読み取るように設定されている。

この設定には注意点もある。ログが共有ボリュームに書き込まれるようになったため、nginxコンテナ自体のkubectl logsコマンドでログを見ても、もはや何も表示されない。ログはSidecarコンテナを介してのみ確認できる。また、Kubernetesで複数のコンテナがあるPodのログを見る場合、kubectl logs <pod名> -c <コンテナ名>のように、必ず-cオプションでコンテナ名を指定しなければならない。指定しないと、KubernetesはPod内の最初のコンテナ（この例ではnginx）のログを表示しようとするため、意図しない結果となる可能性がある。

このSidecarによるログ収集パターンは、Kubernetesの公式ドキュメントでも紹介されているが、その「コスト」についても触れられている。アプリケーションがログをファイルに書き込み、それをSidecarが読み取ってさらに標準出力に流す場合、ノードのストレージ容量が二重に消費される可能性がある。本来、ログを直接標準出力に書き出せるアプリケーションであれば、その方がストレージ効率は良い。しかし、中にはファイルにしかログを書き出せないアプリケーションも多いため、そのような場合にこのSidecarパターンが非常に役立つ。実際の運用では、記事の例のように全ログを再出力するのではなく、新しいログ行だけを効率的に追跡して転送する専用のログ収集ツールが使われることが多い。最近のKubernetesでは、コンテナの起動・停止順序をより細かく制御できる「ネイティブSidecar」機能も登場し、より高度なSidecarの利用が可能になっている。

次に、AzureクラウドにおけるIPアドレスの管理と予約について解説する。クラウド環境でネットワークを設計する際、IPアドレスの割り当て計画は非常に重要だ。Azureでは、仮想ネットワーク（VNet）を作成し、その中にサブネットと呼ばれる小さなネットワークをさらに分割して、仮想マシンなどのリソースを配置する。記事では、192.168.0.0/24というIPアドレス範囲を持つサブネットを例に挙げている。/24という表記は、このサブネットが192.168.0.0から192.168.0.255までの256個のIPアドレスを持っていることを意味する。

しかし、Azureでは、どんなサブネットサイズであっても、常に5つのIPアドレスが自動的に予約され、ユーザーが仮想マシンなどに割り当てて利用することはできない。これらの予約アドレスは以下の用途に使われる。

• .0：そのサブネット全体を表す「ネットワークアドレス」。
• .1：サブネット内のデバイスが外部と通信するための「デフォルトゲートウェイ」のアドレス。
• .2と.3：AzureのDNSサービスを利用するためのアドレス。
• 最後のアドレス（この例では.255）：サブネット内の全てのデバイスに一斉にデータを送るための「ブロードキャストアドレス」。

そのため、192.168.0.0/24のサブネットでは、256個のアドレスのうち5個が予約されるため、実際に利用可能なアドレスは251個となる。Azureで作成できる最小のサブネットサイズは/29（8個のアドレス）だが、ここでも5個が予約されるため、利用できるアドレスはたった3個となる。他の主要なクラウドプロバイダー（AWSなど）でも同様にIPアドレスの予約が行われるが、その目的はクラウドプロバイダーによって若干異なる場合がある。

さらに、Azureでは特定のサービスを利用する際に、専用のサブネットが必要となり、そのサブネットの名前や最小サイズが決められていることがある。例えば、VPNゲートウェイを利用するにはGatewaySubnetという名前で/27以上のサブネットが必要（一部を除く）で、Azure FirewallやAzure Bastionといったサービスには/26以上のサブネットが必要となる。/26は64個のアドレスを持つサブネットを意味する。もし将来的にこれらのサービスを導入する可能性があるVNetを設計する場合、最初からサブネットのサイズを十分に考慮して計画する必要がある。例えば、/24のサブネットから2つの/26サブネットを確保するだけで、元の/24のアドレスの半分が消費されてしまうため、小さすぎるサブネット設計は将来の拡張性を大きく損ねる可能性がある。

また、IPアドレスの範囲選択も重要だ。MicrosoftはRFC 1918で定義されたプライベートIPアドレス範囲（例: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16）の使用を強く推奨している。Azureは他にもRFC 6598で定義された100.64.0.0/10のような範囲もプライベートとして扱えるが、技術的に可能であっても、インターネット上で実際に使われているパブリックIPアドレス範囲をVNet内で使用することは避けるべきだ。なぜなら、VNet内でパブリックIPアドレス範囲を使ってしまうと、そのVNetからはインターネット上に存在する同じIPアドレスを持つ実際のホストにアクセスできなくなり、外部のサービスへの接続に問題が生じるからだ。

このニュース記事が私たちに伝えるメッセージは、システムを構築する際に、私たちがコードを書いたり設定ファイルを作成したりする「前」からすでに存在する、ベースとなる環境やプラットフォームのデフォルト設定、あるいは制約を深く理解することの重要性だ。nginxのログの挙動やAzureのIPアドレス予約のように、これらは明示的に文書化されている情報ではあるが、意識せずに進めてしまうと、予期せぬ挙動や将来的な問題につながる可能性がある。システムエンジニアを目指す初心者にとって、利用する技術やプラットフォームの「隠れた」または「当たり前とされている」挙動を常に探求し、その仕組みを理解しようとする姿勢が、堅牢で効率的なシステム構築の基礎となるだろう。