はじめに
こんにちは、ヤフーでネットワーク設計に携わって早10年の松谷と申します。 今回はヤフーネットワーク10年と題し、ヤフーの重要配信インフラの一部であるネットワークについて、過去の課題と共にご紹介していきたいと思います。
2000年
この頃のヤフーでは検索やオークションといったサービスのウェブサーバーへ、大量のアクセスが集中し高負荷になる事が多々ありました。当時、ほとんどのサービスが皆さんご存じのDNS Round Robin(以下DNSRR)で運用していました。DNSRRは非常にシンプルで優れた機能ですが、サーバー障害時にはAレコードを手動で抜く作業が必要です。またDNSの512byte問題でAレコードを束ねるのが限界になっていました。
そこで登場するがLoad Balancer(以下LB)です。LB自体は皆さんご存じだと思いますが、ヤフーではDirect Server Return(以下DSR)といった他ではあまり使われてない方法で使用していました。DSRでは一般的に以下のようなパケットフローで動作します。
1. クライアントはLBのVirtual IP(以下VIP)へリクエストを送る 2. LBは設定されているリアルサーバーへリスエストをフォワードする 3. リアルサーバーは直接クライアントへレスポンスを送る |
またDSRでは以下のようなメリットがあります。
- クライアントIPを書き変えない - ウェブトラフィックは圧倒的にサーバー→クライアント間のトラフィックが多いためLBへ負荷をかけない |
1台のLBで数百台のリアルサーバーを設定できるため、費用対効果が非常に高く、安定した運用が可能となりました。
2001年
2001年はサービスの性質に合わせた、よりセキュアな構成を検討する事になりました。Stateful FirewallやSSLアクセラレータの導入検討です。しかしながら、当時のトラフィックを受けきれる機器が少なく検証に非常に時間がかかりました。
2002年
この年までは各サービスの立ち上げと同時にネットワークを構築している事が多かっため、構成が標準化されていなく拡張が難しい構成が多く、運用負荷が上がってきた年でした。そこで構成を標準化した、さまざまな構成を柔軟に構築できるネットワーク設計を行う事になりました。以下のようにvlanを多用し、一つのコアスイッチ配下にさまざまなネットワークを構築するモデルにシフトしていきました。
2003年
サービスの拡大とともにトラフィック増加は進み、1つのデータセンタでuplinkを1Gから10G化する事となりました。また、uplinkトラフィックの増加とともに、複数あったデータセンタ間のトラフィックも増え続け、10Gのデータセンタ間バックボーンの構築を行う必要が出てきました。ここで各データセンタ間の経路交換を行う上で下記の事が少し問題になってきました。
- 各データセンタ単位で上位プロバイダーよりIPアドレスを割り当ててもらっていた - 上位プロバイダーへスタティックなデフォルトルートを向けていた - 各データセンタのIGPとしてOSPFを使用していた |
つまるところ、各データセンタ間でデフォルトルートをフィルタし経路交換する必要がありました。方法としていろいろあるかと思いますが、下記の方法で構築してみました。
- バックボーンをEIGRPで構成 - 各データセンタ間のOSPFからEIGRPへ経路を再配布 - EIGRPより必要なデータセンタのOSPFへ再配布 |
上記構成で課題は克服しましたが、本構成の難点はアドレスが増えるたびにルールを更新しないといけないため、運用が少々大変でした。こうなってくると解決方法としてはBGPへの移行が必要となり、2004年はBGP化の話となります。
2004年
さて、BGP移行のメリットは何でしょうか?
- 上記のようにISPに依存しない経路制御が可能 - マルチホームによる耐障害性の向上 - ピアリングによるレイテンシ向上 |
良い事ずくめのため、やる事自体は問題なかったのですが大きな問題がひとつありました。IPアドレスのリナンバです。レジストリからAS番号とIPアドレスを取得し、それに切り替えるには、当然、サーバーのIPアドレスのリナンバが発生します。大量のサーバーのリナンバは大量の手間だけが発生するというデメリットが多いため、並行運用する事としました。しかしながら2006年にはほとんどのサーバーがBGPで広報しているアドレスへ移行できていました。
2005年~2007年
この頃から本格的にDisaster Recoveryを意識したネットワークを構築し始めました。
データセンタのライフラインは何でしょうか?一つは電気、もう一つはネットワークだと考えます。どちらか一方が機能しなくなった時点で、データセンタとしての機能は停止するでしょう。データセンタは異キャリア、異ルート、異なる電力会社で複数配置した方が、より可用性が上がる事になります。
またISPとトラフィックを交換する場所についても複数準備する必要があります。ただ、当時Internet Exchange(以下IX)は東京に集中していましたし、接続するISPもほとんどが東京に存在していました。今後、日本全体のトラフィックはさらに増大し必ず大阪でトラフィック交換が活発になると予想し、大阪での拠点構築を始めました。
現在では東京と大阪を中心としてトラフィック交換を行い、その2拠点にぶら下がるような形でデータセンタを配置しています。
ネットワークを分けただけでは、サービスとしては救えない部分も出てきますので、同時にGlobal Server Load Balancing(以下GSLB)を行う事によって、データセンタレベルの障害が発生しても、サービスを継続できる構成となりました。
2008年
データセンタを広域に分散して行く過程で、社内システムなど異なったポリシーを持つネットワークをデータセンタ間で接続する案件が増えてきました。都度データセンタ間の回線を増強したりルーターを買っていては、費用がかかって仕方がないので、バックボーン機材を有効に使い解決する事としました。具体的にはLogigal Routerを使用してルーターを仮想化し、仮想化したルーター上でVPLSを動かすことにより、データセンタ間をLayer2で接続する事にしました。
2009年~2010年
techblogでも何回か掲出しているIPv6について、この辺りより本格的に取り組んでいく事としました。World IPv6 Dayに参加したのもtechblog読者ならすでにご存じだと思いますが、ネットワークのIPv6化を順次進めています。
2011年~
さてここまで10年ですが、11年目となるこの年より、何を行っているのかも少し紹介したいと思います。
laas
時代はクラウド真っ只中ですが、ヤフーでも社内向けに、仮想サーバーやストレージはもちろんのこと、ネットワークリソースについてもブラウザー上からAPIを通してコントロールできる仕組みを独自に開発し提供しています。この仕組みによりエンジニアは好きな時に仮想サーバーをインストールし、ディスク容量、アクセスリストのコントロールやVIP、GSLB、DNSの作成といった事をオンデマンドで利用する事が出来ます。
データセンターをスケールアウト
ヤフーのサーバーは大昔から電源を一つしか搭載していませんし、ネットワークポートも1つしか利用していません。もちろんコストが安くなるのもありますが、サーバーが1台、2台故障したところで稼働できる用にシステムを組んでいるからです。 現在、この考えをデータセンタにも適用する実験が進めらています。つまり、データセンタをある程度の最小単位にし、接続する設備はネットワーク回線も電力も1回路のみ準備します。無駄な設備排除しているので、コストが下がる他、電力効率も良くなります。瞬時電圧低下に備え、サーバーメーカと協力してバッテリーを搭載したサーバーの実験も行っています。 以下のように、スイッチにサーバーを接続していた構成から、スイッチにデータセンタを接続する構成と変化する予定です。
まとめ
駆け足になってしまいましたが、以上が10年+αの説明となります。個々の技術については、また説明させていただく機会があるかもしれません。今後も課題に対し、新しい技術で解決していく姿勢を取り続け、安定したネットワーク運用を心掛けて行きたいと思います。
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました