Apache の標準モジュールを（だいたい）全部調べてみた

Docker イメージ httpd:2.4.38 の httpd.conf には以下のように利用できるモジュールが列挙されています。

LoadModule mpm_event_module modules/mod_mpm_event.so
#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_worker_module modules/mod_mpm_worker.so
LoadModule authn_file_module modules/mod_authn_file.so
#LoadModule authn_dbm_module modules/mod_authn_dbm.so
#LoadModule authn_anon_module modules/mod_authn_anon.so
#LoadModule authn_dbd_module modules/mod_authn_dbd.so
#LoadModule authn_socache_module modules/mod_authn_socache.so
LoadModule authn_core_module modules/mod_authn_core.so
...

それぞれのモジュールの目的を簡単に調べました。

Linux の Network Namespace で Direct Routing (DSR, Direct Server Return) の動きを確認する

以前から気になっていた Direct Routing (a.k.a. DSR, Direct Server Return) 方式のロードバランサーの挙動を確認しました。以下の書籍で Network Namespace で実験する方法を習得したので、仮想マシンを複数用意することなく手軽に実験できました。

Linuxで動かしながら学ぶTCP/IPネットワーク入門

Direct Routing の仕組み

以下のようなネットワークがあるとします。lb = ロードバランサー、ap = アプリケーションサーバーです。3台のホストはすべて同じネットワークセグメントに所属しています。アプリケーションサーバーが1台しかないのにロードバランサーを使う必要があるのかという疑問が浮かぶかもしれませんが、これは Direct Routing の仕組みを知る上では台数はあまり関係がないためです。

lb と ap には、そのサーバー固有のリアル IP アドレス（ここでは 192.168.0.2 と 192.168.0.3）のほかに、ロードバランシングされる IP アドレスとしてクライアントから利用されることを意図したバーチャル IP アドレス（VIP、ここでは 192.168.0.10）を付与します。何も対策しない状態では同じネットワークセグメントに同じ IP アドレスを持つホストが複数存在する状態となり問題が起きるので、ap 側の VIP には後述する特殊な細工を行っています。

クライアントから VIP を指定してサービスにアクセスする例を見てみます。ap 側の VIP には特殊な細工を行っているため、VIP へのアクセスは lb に向けられます。

ここで lb によってトラフィックの振り分けが行われます。ap にトラフィックが向けられるときは Ethernet フレームの宛先 MAC アドレスが ap のものに書き換えられ、IP パケットの中身はそのまま転送されます。

クライアントへのレスポンスの戻り方が Direct Routing の最も特徴的な点です。lb から ap へは IP パケットの中身がそのまま転送されたので、ap が受け取ったリクエストの送信元 IP アドレスはクライアントの IP アドレスとなっています。よって、リクエストを受け取ったアプリケーションは「送信元の IP アドレスにレスポンスを返す」という通常の動作をするだけで、lb を迂回して直接クライアントにレスポンスを返すことができます。

Direct Routing の利点と欠点

レスポンスを返すときに lb を迂回して直接クライアントに返すことができるという点が最も大きな利点です。Web のトラフィックはサーバーの視点ではリクエストよりもレスポンスのほうが大きくなることが普通なので、lb のボトルネックが緩和されることが期待できます。

副次的な効果として ap から見た送信元 IP アドレスがクライアントの IP アドレスになる点もあります。NAT モードなどと呼ばれている方法では ap から見た送信元 IP アドレスが lb のものになってしまうため、クライアントの IP アドレスを利用する諸々の処理（たとえばアクセスログの保存や IP アドレスを使ったアクセスブロック）に制限があります。

欠点としてはロードバランサーとアプリケーションサーバーが同じネットワークセグメントに所属していない場合には利用できません。

「Linuxで動かしながら学ぶTCP/IPネットワーク入門」を読みました

読みました。

Linuxで動かしながら学ぶTCP/IPネットワーク入門

ネットワークの勉強をしようと思ったきっかけ

最近はデータベース周り担当のインフラエンジニア業をしているのですが、Docker や Kubernetes の台頭によりネットワーク周りの知識の不足が目立つようになってきたためです。具体的に以下のような点で危機感を感じることが増えてきました。

• Docker を使っているときの ip addr show の読み方が分からない。veth や bridge って何？
• Kubernetes のネットワーク周りの話についていけない。いつの間にみんな NAT や iptables に詳しくなっていたの？？

特に、以下のページが理解できなかったことはネットワークの勉強をちゃんとやろうと思ったきっかけとなりました。

kubernetes.io

speakerdeck.com

この本に手を出してみた理由

Kindle の試し読みで以下の点が気に入ったからです。

• Linux の Network Namespace を使って説明している
  実験用のネットワークを VM で構築する方法と比べて軽量という理由で Network Namespace が採用されたようですが、Docker のネットワークがよく分かっていなかった私にとっては Network Namespace での説明のほうが都合がよかったです。
• 本当によく使われる基礎的なコマンドを利用している
  ip, ping, tcpdump といった実際よく使われる基礎的なコマンドで説明されているので、学習以外で使うことはないであろうよく分からないネットワークシミュレータの使い方の学習のために時間を割く必要がありません。

最後まで読んでみた感想

• 知りたかった内容は一通り学べた
  L2, L3 と NAT まわりについて学びたかったのですが、それぞれ3章、4章、7章で学べたので満足しています。5章、6章、8章は L4, L7, ソケットプログラミング について扱っている章でしたが、これについてはだいたい知っている内容でした。
• Network Namespace を使った説明は有用
  大学ではネットワークの講義で原理を勉強しただけでルーターのコンフィグを書いて実験してみるようなことはなかったので、あまり学習した内容が身についていなかった自覚がありました。Linux の Network Namespace ではホスト間を接続したりルーターを設置したりすることがコマンドだけで実現できるので学習用途にも便利だと思いました。
• ネットワークまわりのトラブルシューティングの習得にも役に立つかも
  本書では何かを実装した後に必ず tcpdump での確認を行う流れを取っています。ARP のリクエストを tcpdump で確認してみるといったこともやっているので、下のレイヤーをブラックボックス扱いすることはありません。私はネットワーク周りのトラブルがあった時にはとりあえず設定を戻してみたりと、ネットワークをブラックボックス扱いしたトラブルシューティングをしていたのですが、今後はちゃんと tcpdump で状態を確認しながらトラブルシューティングをしていきたいと思います。

おわりに

「ネットワーク周りのことを詳しく知らなくても Kubernetes は使える」という意見について、どうも私にはそうとは思えず、今後は避けては通れないのではないかと焦りを感じていたところだったので、ちょうどよいタイミングで本書が発売されて助かりました。

本書の著者のブログにはたびたびお世話になっているので紹介記事を書いてみました。

blog.amedama.jp