「家畜」サーバ群を収容するDMMの内部ネットワーク

こんにちは。ゲストブロガーのあきみちです。今回は、大量のサーバ群がどのように管理されているのかに関する導入です。

ペットから家畜へ

10年前と比べると、サーバ管理のトレンドが大きく変わっています。どういった変化が発生しているのかに関して、昔は一台一台のサーバをペットのようにかわいがっていたが、最近は家畜のようにまとめて扱う、というアナロジーが2012年頃から言われるようになっています。

そのアナロジーの元となっているのは、恐らく、2012年4月に行われた「Architectures for open and scalable clouds」という発表です。

一般的な大規模Webサイトのほとんどが、大量のサーバを少人数のスタッフで管理しています。DMMでも、一人あたり数百台のサーバをみつつ、全体では数千台のサーバが運用されています。サーバ台数あたりのエンジニア数を見ると、一台一台のサーバを愛玩動物のように愛でるのではなく、家畜のようにまとめて運用する必要がでてくることがわかります。

L3視点で見るネットワーク構成

「家畜」のようにある程度まとめて管理が行われているサーバ群ですが、それらをどのように管理しているのかを説明する前に、まずはどのようなネットワーク構成になっているのかを紹介します。「○○というサービスだと××を使っていて。。。」といった説明をしようと思ったとき、何がどこにどのように配置されているのかを理解しないと意味不明になってしまうためです。

DMMのサーバ群は、基本的に東京にある3ヶ所のデータセンターで運営されています。

東京1と東京2の構成は、図1のように一般的なWeb3層構成になっています。グローバルIPv4アドレスがついたロードバランサの裏側に、アプリケーションサーバがプライベートIPv4アドレス空間で運用されています。アプリケーションサーバが運用されているプライベートIPv4アドレスのネットワークも必要に応じて別れています。

4-1
図1:東京1と東京2の構成概要

アプリケーションサーバのさらに裏には、データベース用のプライベートIPv4アドレス空間があります。データベース用のネットワーク上では、MySQLのマスターとスレーブ、memcached、Redis、あわせて1000台程度が運用されています(本稿執筆時点)。

memcachedとRadisは、MySQLよりも高速な動作が必要な部分で利用されていますが、memcachedがRead専用の揮発性キャッシュとして利用され、Redisが不揮発性のKVS(Key Value Store)として利用されています。Redisは、主にオンラインゲームのセッション情報を管理するために利用されます。

ロードバランサ

DMMネットワーク全体で利用されているロードバランサは約60台です。ロードバランサはL4だけではなく、L7ロードバランシングも行っており、URLによってアプリケーションサーバを切り替えています。

たとえば、「DVD/CDレンタル」のURLは「http://www.dmm.com/rental/」から開始するようになっていますが、そのURLの場合にはこのアプリケーションサーバが処理を行う、といった動作です。A10 Networksの機器が主に利用されています。

アプリケーションサーバ

アプリケーションサーバはサービス毎に役割がわかれています。DVDレンタルなど、大きく分けると10種類以上のサービスグループに分けて、2000台以上が運用されています。

なお、オンラインゲームは外部のDMMネットワーク内部ではなく、パブリッククラウドで運用される場合もあります。認証部分等のみがDMM内部で行われ、ゲームコンテンツ等は外部のパブリッククラウドなどで運用されるといった形態です。

データセンター間の接続

東京1、東京2、東京3の全体構成は、図2のようになっています。

4-2
図2:東京1、東京2、東京3の全体構成

東京2と東京3は、IPv4グローバルセグメント及びIPv4プライベートセグメントがダークファイバによって同じL2セグメントとして運用されています。東京3はグローバルIPv4アドレスによる外部接続を行っておらず、東京2経由でインターネットとの通信が行われます。

東京1と東京2が別々のアイランド(BGP island)としての運用されています。東京1と東京2は異なるAS番号で運用されており、それぞれBGPルータでインターネットに接続しています。そのうえで、東京1と東京2はBGPピアリングを行っています。

東京1と東京2のグローバルIPv4アドレス空間が個別ASで運用される一方、プライベートIPv4アドレスによるアプリケーションサーバ用セグメントとデータベース用セグメントは、ダークファイバで直接接続されており、それぞれ同じL2セグメントとして運用されています(JuniperのQFabricが使われているのは、この部分です)。

次回予告

今回は、主にオンラインゲームなどを念頭にネットワーク構成を紹介しました。

動画配信部分は、これとは多少異なる構成になっています。次回は動画トラフィックがどのように配信されているのかを紹介する予定です。

この連載の過去記事

イケてないIPv6とどう付き合うか

社内勉強会でIPv6について説明。

 

そもそもIPv6がイケてないなあ、ってところは以下なのよね。

  • インターネット・プロトコル・スイートがそもそもいけてない。IP層が交換可能になるように作られていない。
  • IPv6で解決したかった問題は他の手段で解決済み。空振りな感じ。
  • IPv4と互換性がないので、まったく別の新しいネットワークを作らなきゃいけない。
  • 新しいネットワークでは今までのやり方が使えないことがある。

IPv4からIPv6に移行させたい、というのであれば、IPの上に別のレイヤーをちゃんと定義して、IP層を交換可能な形に実装してやれば良い気がするんだよね。

そういうアイディアもスライド中にちょっと書いてみた。(19ページ目)

こういうのはIETFとかで議論されてたりしないのかしら?


(追記)

我々がIPv6をまったくやってない、ってことはなくて、パブリックミラーサーバはIPv6も喋ってます。まだそんなにトラフィックは出ていませんが、序々に増えてきてはいるようです。

関連記事↓

パブリックサーバ