技術の深掘り・日常など幅広く紹介してます
複数の Google Cloud プロジェクトに跨るリソース間の通信が発生する場面では、VPC ネットワークを通じて安全に接続できる仕組みが必要です。Google Cloud では、主に Cloud VPN によるプライベート接続で VPC 間にトンネリングを構築する方法、VPC Peering で VPC 間を直接接続する方法、比較的規模の大きいサービスでは Shared VPC を利用してネットワークを共有する方法等があります。中でも Cloud VPN を使用した接続は、プロジェクト間を柔軟かつセキュアに接続したい、異なるネットワーク構成を維持したまま通信させたいといった場合に有効です。Cloud VPN は、トラフィックの暗号化や論理的なネットワーク分離を重視するケース、推移的ルーティングが必要となる場面で多く採用されています。今回のブログでは、Cloud VPN を利用して異なるプロジェクトの VPC をセキュアに接続する方法について紹介したいと思います。
Kubernetes でリクエストを Pod に負荷分散する際にクライアントの送信元 IP アドレスを保持したいケースがあります。LoadBalancer や NodePort を使用する Service の場合、負荷分散の過程で送信元 IP アドレスが NAT（SNAT：Source NAT）されるため、Pod に到達するパケットからはクライアントの IP アドレスを知ることができません。Service の External Traffic Policy を Local に設定すると、外部からのトラフィックは受信したノード上の Pod にのみ転送されるため SNAT は回避できますが、単一ノードにトラフィックが集中するためクラスタワイドな負荷分散ができません。また、Ingress Controller を利用すると HTTP X-Forwarded-For ヘッダに送信元情報を付加することができますが、L7 LB が前提となるため、L4 LB のような低レベルロードバランサでは有効に機能しません。ベアメタル Kubernetes でネットワークロードバランサをプロビジョニングするための代表的な OSS に MetalLB があります。MetalLB には L2 モードと BGP モードの 2 種類の負荷分散方式が用意されています。多くの場合は前者が利用されますが、後者の BGP モードでは、より柔軟なネットワーク構成や負荷分散の制御が可能になり、送信元 IP アドレスを保持したままリクエストを分散することができます。今回のブログでは、MetalLB の BGP モードを利用して SNAT を回避しつつ、クラスタワイドな負荷分散を実現する構成について紹介したいと思います。
L2 モデルによるネットワーク設計は拡張性や高可用性の観点から、DC の弱点とされてきました。 これは L2 で使用されるプロトコルが多数のデバイス間でトラフィックを大量に送信するため、冗長化構成を取りながらもフレーミングストームを回避するための策を講じる必要があったためです。 また、従来のネットワークトポロジは、スケールインモデルであることから、ネットワーク帯域を拡張する際は、より大きくて高価な機器に交換します。 さらに、大きな機器ほど多くの機器と接続するため、故障した際の影響範囲が大きくなることが懸念されます。 そのため、DC ネットワークは拡張に伴いますます複雑化し、運用面やコスト面においてスケーラビリティは限界を迎えようとしていました。近年では、これらの問題を受け、多くの DC で IP-Clos と呼ばれる、Clos ネットワークの原則を適用した IP-fabric が採用されています。 Clos ネットワークは、L3 ベースのアーキテクチャを用いることで、ブロードキャスト等の BUM トラフィックによる帯域圧迫を排除し、安定性と拡張性を向上させます。 また、BGP と BFD はベンダに依存せず、L3 で経路を制御するため、トラブルが発生した際も、従来の IP のトラブルシューティングが適用可能になります。今回のブログでは、実際に日本で IP-Clos が採用されているヤフーにて Clos ネットワークの構築を経験してきたので、これを機に聞いた話や知見を含め、IP-Clos について調査・紹介しようと思います。