UberのIPv6対応

2017/5/1-1

Uberの技術ブログ「Uber Engineering」で、IPv6対応状況を公表しました。 Uberの内部ネットワークは急激に成長しており、このままでは2017年後半頃に10.0.0.0/8のプライベートIPv4アドレスが足りなくなってしまうこともあり、内部ネットワークで積極的にIPv6を活用することを目指していることが述べられています。

Uber Engineering Updates: Adopting the Next-Gen Internet Protocol: Deploying IPv6 for Uber Engineering

2017年4月の時点で、Uberの内部ネットワークでは10.0.0.0/8の50%以上を既に使ってしまっています。買収した会社で利用されているIPv4アドレスが、既に運用されている機器に設定されているIPv4アドレスと重複するといった問題もありました。

そういった問題を解決するため、Uberでは内部ネットワークをIPv6対応を開始しました。Uber Engineeringでは、「IPv6 deployment will be mission critical for our expansion. (訳) IPv6デプロイメントは、我々の事業拡大にとって必要不可欠である」とあります。

10.0.0.0/8が足りなくなるという問題意識は、米国ComcastがIPv6に積極的に取り組んでいた問題意識と同じです。CATV網を運用するために利用されるDOCSIS 3.0がIPv6を利用した仕様になったのも、10.0.0.0/8の空間が小さすぎるのが大きな要因でした。(参考:CATVによるIPv6サービスとDOCSIS3.0)

IPv6対応における3つの要素

Uber Engineeringの記事は、UberがIPv6対応するうえで以下の3つの主要分野が存在することに気がついたとあります。

ネットワークアーキテクチャ
ソフトウェアサポート
ベンダーサポート

ネットワークアーキテクチャ

Uberのネットワークアーキテクチャは、ハードウェア、オートメーション、ネットワークデザイン、の3つのセクションによって構成されています。

Uber Technology Day: Explore IPv6 Deployment at Uberより

ハードウェアとしてはサーバへの100G/50G/25Gイーサネット接続されていること、オートメーションとしては自社開発のツールでの運用が紹介されています。

ネットワークデザインとして、RFC 7938:Use of BGP for Routing in Large-Scale Data CentersにあるIGPとしてBGPを利用するという手法が使われています。内部ネットワーク用にBGPを使うという手法は、数年前から話題ですが、最近では普通に使われるようになってきたのがよくわかります。(参考:IGPとしてのeBGP＠Interop 2013)

Uberでは、複数のサーバラックをサーバpodとして集約し、複数のサーバpodをクラスタとして扱っています。

Adopting the Next-Gen Internet Protocol: Deploying IPv6 for Uber Engineeringより

Uberでは、サーバラックやクラスタを単位としてIPv6アドレスブロックの割り当てを行っています。サーバラックには/64のセグメントを、クラスタには/64よりも小さいプレフィックス長のIPv6アドレス空間が割り当てられます。これらの内部ネットワーク用に使われるIPv6アドレスは、RIR(Regional Internet Registry)からの割り振りを受けた/32のGlobal Unique IPv6 Address(GUA)が利用されます。

Uberのネットワーク用で利用されるルーティングプロトコルは、IPv4とIPv6の両方で使いやすいBGPやIS-ISが使われています。

ソフトウェアサポート

ネットワークだけではなく、ソフトウェアの更新も必要です。 Uber Engineeringでは、次の点が必要だったと書かれています。

プレフィックス長(ネットマスク)が/24を前提にしたものは、IPv6に合ってない
a.b.c.dといった感じで「.」でIPアドレスを分割しているコードはIPv6に対応できない。IPv6は「:」で区切られる。
a.b.c.d:80のように「:」でIPアドレスとポート番号が区切られた前提で書かれているコードに、[2001:db8::1]:8080というIPv6の記述が渡されると失敗する。逆に、単純に「:」で区切った出力をするコードは、2001:db8::1:8080といった誤った出力をしてしまう。(Uber Engineeringでは[2002:a:b:c::ff]:8080という例で書かれていますが、ここでは例示用IPv6アドレスを使いました)
IPv4アドレス用に書かれたregexは、IPv6アドレスを渡すと失敗する
データベースで、IPv4アドレスを保持するために専用に作られたvarchar(16)は、IPv6アドレスを保持できない

Uberのインフラストラクチャは、リージョン間での通信にhaproxyを使っています。 haproxyのYAMLによる設定ファイルであるhaproxy.cfgなどにIPv4アドレスが含まれることがあります。そういった設定ファイルにIPv6アドレスも登録する必要があったようです。

IPv4アドレスをハードコーディングするのではなく、コードに記述するのをホスト名とすることでDNSを使うようにしたとあります。現在、Uberは開発者に対してgetaddrinfoなどIPv6対応されたツールを使う方法を教育しています。

ベンダーサポート

非常に多くのベンダーがIPv6をサポートしているものの、まだ実運用でIPv6が利用されている環境も少ないこともあり、IPv6に関連するバグが多数報告しているとあります。

Uberでの2017以降のIPv6対応など

現在、Uberの全体に対して適用するためにIPv6はラボでのテスト中です。

大規模なIPv6対応を行うことで、フロントエンドのIPv6対応、重複するIPv4アドレスに対するスケーラブルな対応を実現することなどの効果があると推測しているようです。

Uber Engineering記事の最後で、世の中の開発者に対してIPv4とIPv6の両方に対応するコードを書くことや、IPv6を自社ネットワークでデプロイすることを呼びかけています。

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！