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

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

Direct Routing の仕組み

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

f:id:kujira16:20200505183321p:plain:w400

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

f:id:kujira16:20200505184433p:plain:w400

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

f:id:kujira16:20200505185308p:plain:w400

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

f:id:kujira16:20200505185453p:plain:w400

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

f:id:kujira16:20200505193115p:plain:w400

Direct Routing の利点と欠点

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

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

自作缶バッジを作ってイベントで配ってみた

ACM-ICPC OB/OG の会 という団体の認知を高めるためにグッズを作ってイベントで配ってみました。

どうして缶バッジ?

IT系のイベントでノベルティとしてよく配布されているのは

  • クリアファイル
  • ボールペン
  • 手帳
  • ステッカー
  • Tシャツ

あたりだと思います。

会社員になってから紙に記録したり紙の資料を持ち運んだりすることが激減してしまったので最初の3つは別にいらないかな、という感じになり、ステッカーやTシャツもよく考えると余るほど貰っているような気がしたので、コーナーケースを攻めるつもりで缶バッジを制作してみました。

業者選び

「缶バッジ」で検索すると少量から製造してくれる業者がたくさん見つかり、どういう観点で選べばいいのか最初はよく分からないのですが、今回は pixivFACTORY を使ってみました。理由はすでに pixiv のアカウントを持っていたからというだけです。

factory.pixiv.net

デザイン作成

Adobe Illustrator のような特殊なツールが必要にならないか心配していたのですが、缶バッジの場合はそんなことはなく、JPEGPNG をアップロードするだけで入稿できます。デザイン用のツールを持っていなかったので PowerPoint で作成したものを PNG にエクスポートして入稿しました。

注意点としては、丸形の缶バッジの場合、きっとあなたが想像しているよりも大きい余白が必要です。余白が足りなかったため、私は図の修正を2回くらいやり直しました。

注文

pixivFACTORY の場合は30個以上の製造で1個当たりの価格が最安となるので、今回は30個を注文してみました。

良かった点

簡単に作れた

注文したデザイン自体が単純ということもありましたが

  • 業者選び
  • デザイン作成
  • 注文

までの工程が2時間程度で終わったと言えば、どれだけ簡単に作れたか想像いただけると思います。

品質には満足

詳しくないので評価は難しいですが、実物の色味や余白の大きさなどはディスプレイ上でデザインしたときに想像したとおりのものが出来ていると思います。表面の加工などにも不満はありません。

次回はどうする?

次に缶バッジを作ることがあったら以下の点を再考してみるかもしれません。

より価格が低い業者を探す

30個注文したところ、1個あたりの価格が80円で送料が1,100円でした。

30個注文したときの1個あたりの価格は他のサービスと比べると20~30円高く、おそらく pixiv 社への仲介料と思われます。

より衝撃的なのは送料で、「n 円以上で送料無料」に慣れてしまった現代人からすると「ぐえー」という感じです。

その他付加サービスについて検討する

他の業者では追加の料金を支払うことで以下のようなサービスを追加できる場合があります。

  • フックピンから安全ピンに変更する
  • ピンではなくクリップに変更する
  • 個包装する

今回は参加者が大学生相当以上の年齢のイベントだったためあまり気にしていませんでしたが、別のイベントで参加者層が違う場合には検討する価値があります。

最後に

喜んでくれた人がいるようなのでぼくは満足です。