iDC, コラム, ネットワーク, 運用管理

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

ペットから家畜へ

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が使われているのは、この部分です)。

次回予告

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

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

この連載の過去記事

hardware, linux, 小ネタ, 運用管理

艦これ」といえばDMMのゲームと言われるほどにまでなりましたが、「城コレ」が今度は控えているようです。約30万人の方が事前登録してくださったという嬉しい悲鳴がところどころで聞かれます。そしてツチノコ部隊も全体の安定稼働へ向けて色々と対応しています。ところで、こういうオンラインゲームは、可愛いキャラクターもさることながら、ブラウザの裏でインターネット越しに必死に動いている「黒子」のようなものたちがいます。いわゆる「ゲームサーバ」と呼ばれるものです。

ゲームサーバは、その基本構成としておおまかに「アプリ(フロント)サーバ」と「データベース(バックエンド)サーバ」に分かれます。今日はその中でも「データベースサーバ」についてのお話です。

DMMでは大抵のデータベースサーバにLinuxとMySQLを使っています。そのデータベースエンジンにInnoDBというのがありまして、設定項目としてメモリ上にバッファをするという設定を行うことができます。

例えば、メモリを128GB搭載したサーバでバッファ用に100GBのメモリを割り当てるとします。さて、実際のメモリの割当はどのようになるでしょうか。最近のXeonを搭載したサーバとして考えてみます。実はCPUの個数により、そのメモリの割り当てられ方が変わってきます。というのも、昔と違い今はメモリのコントローラがCPUに内蔵されているからなのです。

  • シングルCPU構成の場合

すべてのメモリがCPUと直接つながっているので、特に気にする事はありません。

  • マルチCPU構成の場合

CPU0とCPU1…とにそれぞれメモリがつながっています。例えば先ほど128GBとしたメモリが2CPU環境にあるとしましょう。そうするとCPUにごとに64GBのメモリがつながっている事になります。標準ではLinuxはプロセス毎にそのプロセスが動いているCPUにつながったメモリを利用しようとします。つまり、先ほどの100GB割り当てが、MySQLのプロセスが動いている片方のCPUに偏ってしまうのです。その結果、片方のメモリがMySQLに食いつぶされ、そこにもともといたデータがSWAPに吐き出されます。もう片方のCPUにつながっているメモリに空きがあっても、です。

少し詳しい話にしましょう。最近の共有型のマルチプロセッサシステムアーキテクチャは、NUMA(Non-Uniformed Memory Access)というものです。これは、CPUとメモリのまとまりを「ノード」と呼びます。先の例では、CPUと64GB分のメモリのまとまりが”ノード”です。

Linux OS上でプロセスが起動すると、そのプロセスはCPUに割り当てられます。CPUとメモリがまとまっているので、プロセス自体のデータは同じNUMAノードのメモリに置かれます。
先の例の2CPUの環境MySQLが起動したあとメインスレッドがCPU0に割り当てられたとして、そのCPUにぶら下がる64GBのメモリにMySQLのデータが置かれます。しかし、バッファデータのサイズだけで100GBあるので、NUMAノードの64GBをいずれ食いつぶします。そうなると、同じNUMAノード上にある他プロセスのデータがメモリから溢れます。他NUMAノードのメモリはデフォルトではOSが割り当てをしない状態になっているため、あふれたものはスワップへ送られます。もともと64GBのメモリ上にあるものなのでスワップアウトするデータ量も大きくなる傾向があります。なので実際のところスワップが埋まってしまう可能性が非常に高いです。

では、どうすればこの偏りやスワップアウトを抑えることができるのか。

NUMAをOSからコントロールするnumactlというコマンドがあります。
–interleaveオプションは割り当てるNUMAノードを指定します。上記の例では”all”となっているため、すべてのNUMAノードに割り当てを行うことを意味します。

こちらのコマンドで、NUMAに対するプロセスの状況が見られます。
とはいえ、見るのは大変なので、下記のページを参考に、Perlスクリプトを使ってみましょう。
http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
numa-maps-summary.pl というスクリプトです。って、実はこれ2010年の記事なんですよね。知りませんでした。

実際にスワップアウトしてスワップを喰い潰してしまったサーバがこちら

同じサーバで、numactlを設定したのがこちら

設定前はNUMAノード分の64GBに近く偏っていたものが、設定後は分散されているのがわかります。
上記のようにプロセスがどかっと大きなメモリを割り当てることでスワップアウトしてしまう現象を”Swap Insanity”といいます。
そして先のブログ記事にもありますが、mysqldのinitスクリプトを改造して、numactlを埋め込んでしまうという手を使うことで、回避ができます。

linux, コマンド, 小ネタ, 運用管理

ifconfigを含むnet-toolsが非推奨になって久しいようですが、

rhel7系からnet-toolsはおさらばとなります。
※手動で入れれば使えますが。

今思えば、ifconfig君

あなたと出会ってからこの十数年、あなたを打たなかった日はありません。

雨の日も風の日もいつも一緒だったね。

あなたがいつもいてくれたから私も輝けたんだといます。

これから私は新しいiproute2君と歩んでいくことになりますが、あなたのことは決して忘れることはないでしょう。

ifconfig君に幸あれ

P.S.
ついつい ifco[tab]ってやっちゃうのはご愛嬌です。

ということでnet-toolsとiproute2の対応表一覧です。自分の備忘録として残しておきます。

net-tools iproute2
ifconfig ip l (ip link)
ifconfig -a ip a show (ip addr show)
ifconfig eth0 up ip link set eth0 up
netstat ss
netstat -i ip -s link
netstat -l ss -l
netstat -r ip r (ip route)
route [add|del] ip route [add|del]
route -n ip route show
arp -n ip n (ip neighbor)

heartbeat+pacemakerなどで利用する仮想IPはipaddr2を利用しています。

そもそもifconfigではこのコマンドで設定されたIPは表示されません。rhel6系であってもip addr showで確認しなくてはいけません。

開発、オペレーションする側みんながこの違いを認識し共有することがミスを防ぐことになります。

glusterfs, イベント, インフォメーション, ネットワーク, 仮想化, 勉強会, 負荷分散装置, 運用管理

July Tech Festa 2014で発表させていただいたスライドを公開しました。

発表の機会をいただきありがとうございました。>JTF2014実行委員会様

 

JTF2014−presentation

なんとベストプレゼンテーション賞もいただきました。

ベストプレゼンテーション賞

機会があればもっと喋りますので気軽にお声がけくださいませ。

RackTables, イベント, インフォメーション, 運用管理

JANOG(JApan Network Operators Group)のメーリングリストにこんなメールが流れました。

世界のサービスプロバイダーの人が使ってるフリーのIPアドレス管理ツールって何ですか?
IPv4アドレス・マスク・アロケーションされた日にち、それをどこに割り当てたのか、リリースされた日

が管理運用出来るものが知りたいです。

日本ではどうですかー?

エクセル?

(いくつかメールが流れて)

何となく、この辺もExcel管理からの脱出で、皆さんの悩みどころでもありそうですねー。
JANOG 34のこの辺でやってくれるのかしらー?
情報共有ツールの情報共有
http://www.janog.gr.jp/meeting/janog34/program/itool.html

DMMさんはracktableを使ってるみたいだから、期待ですねー。
https://tsuchinoko.dmmlabs.com/?p=886

ええと、JANOGのメーリングリストは6000人以上が購読しているのですよ。がくぶるです。

ということで、racktablesでは、IPアドレスはどう見えるか、を書いてみますね。

まずはトップページでIPv4をクリックすると、(下の画像はクリックすると大きくなります)

racktables-ip-top-2
管理されているアドレスブロックと、その利用状況が一覧で見れます。

racktables-ip-list-2

アドレスブロックをクリックすると、個々のアドレスに紐付く機器がわかります。

racktables-ip-detail-2

さらに、そこから機器を選択すると、機器情報が見れたり、ドリルダウンでどんどん情報をひっぱってこれます。

なかなか便利でしょ?


せっかくなので、インフォメーション。

DMM.comラボはJANOG34のおやつスポンサーをさせていただいています。

JANOG 34 Meeting

7月はみんなで高松に行きましょう。

そして、今週末の、July Tech Festa 2014 にも来てくださいねー。

PAGE TOP