イベント, インフォメーション, 勉強会

毎年夏に開催されている Lightweight Language イベントも今年で12回目を迎えます。

このイベントは毎年、LLなんとか、という名前で開催してるのですが、なんとか、の部分を毎回変えています。
公式開催概要には

LLを深掘りしたいという思いも込め、、、「LL Diver」を開催いたします。

と書いてありますが、「深掘り」というのは後付けです。
お台場で開催されるので、お台場→だいば→ダイバー→Diver、にした、というのが多分本当です。

ということで今週末はみなさんお台場に行きましょう!!

LL Diver 開催概要

  • 日時: 2013年8月23日(土) 10:30-17:30(昼の部) 18:30-21:00(夜の部)
  • 場所: 日本科学未来館(昼の部)、東京カルチャーカルチャー(夜の部)
  • URL: http://ll.jus.or.jp/2014/
  • 公式タグ: lldiver

DMM.comラボでは、来場者向け会場ネットワーク構築に協力させていただきました。

LL Diver 会場ネットワーク
http://ll.jus.or.jp/2014/network

会場ネットワーク構築は、CONBU(COnference Network BUilders)というチームが行なっています。
まだスタートしたばかりの団体なのですが、様々な大規模カンファレンスネットワークを作っていくはずなので、この団体の今後の活動にも要注目です。
イベント毎にスタッフの募集も行なわれるはずです。

CONBU(COnference Network BUilders)
http://conbu.net/

なお、今回のLLイベントでは、久しぶりにお酒が飲める夜の部も開催されますよ。
お酒が入らないと喋れないような発表があるはず。
こちらは会場が小さく、残席は残り僅かですので、お早めにチケットをお買い求めください。
あー、夜が楽しそうだから、昼ぐらいから参加すれば良いかな、と思う人もいるかもしれませんが、私が司会をするセッション(○○ as Code)↓は午前中の最初だったりするんですよね。できれば早起きして欲しいなあ。

LL Diver | ○○ as Code
http://ll.jus.or.jp/2014/program#code

インフラ全般, 小ネタ

はじめまして。3月に入社した年寄りの新人です。

小ネタとしてツールを作ってみましたので紹介します。

Webサーバの応答がちょっと遅いな?とか思ったときにどこで引っかかっているのか大まかにでもわかると切り分けの役に立つと思います。muninのプラグインとしてすでにhttpingプラグインがありますが、もっと細かな情報が知りたいこともありますよね?今回はcurlの-wオプションを使ってmuninのプラグインを作ってみました。curl の-wオプションは以下のように使います。

$ curl -s -o /dev/null -w “%{time_namelookup}\n” http://www.dmm.com

とすると名前解決にかかった時間を表示してくれます。詳しくはマニュアルを参照して頂くとして使える変数と大まかな意味を図示するとこんな感じです。

これClipboard01

コマンドで返される値を使ってmuninのプラグインを作りました。作成にあたっては先ほどのhttpingプラグインを参考にさせていただきました。大変感謝しております。このプラグインを使い色々なページのレスポンスを見てみるとどこに時間がかかっているかわかります。(チェックは5分に1回なので許してね)。こちらは比較的軽いページの結果です。

www.dmm.com

こちらは上に比較すると画像データが多く、表示に少々時間のかかるページです。

www.amazon.co.jp

いかがでしょう?プラグインのソースは以下のようなものです。

このプラグインはmunin-nodeから実行されます。

  • チェック対象のURLはhttp://www1.example.co.jp/, http://www2.example.co.jp/
  • muninのプラグインの置き場所は/usr/share/munin/plugins/以下
  • muninの設定ファイルは/etc/munin/以下

という条件では以下の設定で使えるようになります

  1. プラグインの置き場所の/usr/share/munin/plugins/に 上のプラグインをhttpresp_curl_ のような名前で置いて実行属性を与えておく
  2. /etc/munin/plugin-conf.d/httpresp_curl というファイルを作る。内容は以下の通り
  3. /etc/munin/plugins/ 以下にプラグインへのシンボリックリンクを作る。シンボリックリンクの名前はhttpresp_curlで[ ]の中に記述した名前にする。

以上です

CDN, DNS

昨日、geekなページのあきみち氏ご本人からアカマイの本をいただいたので、早速、読んでみました。

いただいた本↓
Geekなページ:『アカマイ 知られざるインターネットの巨人』を書きました

Akamaiのsurerouteサービスがispにどのような影響を与えるのか、
また、そのサービスはもろ刃の剣でありispに対する優位性が変化してきているというくだりが面白かったです。
あきみちさん献本ありがとうございました。

ところで、この本を読んでいて、ふと
パブリックDNSとCDNの相性問題を思いだしまして、突然ではありますが調べてみようと思い立ってしまいました^^;

一度、こう思ってしまうと寝る間を惜しんで調べてしまうところがツチノコ親分の性なんでしょうかね。

では調査結果を共有します。

googleの運用する8.8.8.8や8.8.4.4などのパブリックDNSは巷ではCDNとの相性は良くないと言われています。

確かに8.8.8.8はanycastのアドレスで台湾に設置されているサーバに振られます。

かつてはakamaiやその他のCDNを利用しているサイトのFQDNで名前解決を行うと台湾のサーバに振られるようになっていました。

結構前の話なので最近はどうなっているのかコマンドを叩いて調べてみます。

akamaiの場合

これを見ると8.8.8.8でもJPのエッジサーバに振り分けられています。
8.8.8.8は間違いなくRTTをみてもTRACEをみても国内のサーバではなさそうです。

limerightの場合

limerightは台湾にエッジがなく香港に設置されているのかもしれません。
いずれにしても台湾のDNSに対しては香港のエッジが返されています。
8.8.8.8を利用した環境においてlimerightを利用しているサイトを利用すると海外のサーバに飛ばされパフォーマンスが低下する可能性があります。

cdnetworksの場合

ここはまた違った結果が。。
KDDIが買収する前は韓国資本の会社
ここの会社はもしかすると、アジア地域のanycastのアドレスは標準で韓国のエッジに飛ばすようになっているのかもしれません。
いずれにしても8.8.8.8を利用しCDNをcdnetworksを利用したサイトを訪れる際は韓国へ飛ばされパフォーマンスが低下する恐れがありそうです。

この3社の結果をまとめると
Akamaiだけが台湾の8.8.8.8でも日本のエッジが返されるようになっている。

ここから見えることは
※あくまで想像です。^^;

8.8.8.8を利用してもakamaiであれば遅延が発生しない

googleとakamaiは仲良しでgoogleがakamaiに顧客のIPを渡している可能性がある。

渡していないのであればJPアドレスなのか否かの情報は渡している可能性がある。

というところでしょうかね。

結論

改善はしている。ただしAkamaiだけで。

パブリックDNSを利用するにはまだ早いかもしれません。
※過去の記事で8.8.8.8に話しをしているのですが浅はかだったかもしれません。^^;

利用するにしても日本国内のpublic dnsを利用するといったところでしょうか。

推測を含んでいる部分が多く、
いろんな誤解が含まれている可能性がありますのでご指摘いただけると助かります。

コマンド, 小ネタ

pingでsearchをかけるといろいろと出てくるpingライクなコマンド

みんなどんな役割を持っているんだろうか。

いわずと知れたpingのように各プロトコルで応答の確認を行うコマンドであり、

fping,httpingなど監視ツールと組み合わせて利用されることも多いんだと思いますが、

普段使いできそうなコマンドはあるのでしょうか。

さっそく、調べてみました。

fping:
複数のipにping
ioping:
簡易的なディスクレイテンシーモニタリング
omping:
マルチキャストとユニキャストで応答確認
hping:
icmp,udp,tcpなどいろんなパケットを生成し応答確認
arping:
イーサネットレベルの応答確認
2ping:
特定の2ホストでどちら側のホストに問題があるのか確認できる。
httping:
httpレスポンス詳細が確認できる。

結果、下記の三つのコマンドは覚えておいても損はないかなと思いました。

一つずつ確認していきます。

  1. httpingはウェブサーバで遅延しているときにどの部分で遅延が発生しているのかが確認できる。
  2. arpingはipバッティングがないかどうかの確認ができる
  3. iopingは実運用下の中でディスクのレイテンシーの悪化状況を確認できる。

1.httping

名前解決が完了するまでの時間
+サーバへ接続するまでの時間
+リクエストがサーバに受け付けられるまでの時間
+サーバが最初のデータをスタートするまでの時間
+データの転送が完了しコネクションがクローズされるまでの時間
=合計

がわかります。

これでどこの部分で遅延が発生しているのかが具体的にわかるようになります。

2.arping

このようにIPのconflictの確認が可能です。

このコマンドを運用に組み込んでIPバッティングを防いだりできます。


3.ioping

このように実稼働環境においてレイテンシーの変化を確認し増強のタイミングを見極めることができます。

ちなみに、pong2というOpenGLを利用した3Dゲームがあります。

3Dのピンポンゲームです。aptでサクっと入ります。画面はこんな感じ^^

pong2

iDC, インフラ全般, コラム

こんにちは。あきみちと申します。ゲストブロガーとしてツチノコブログで連載することになりました。連載の内容は、DMM.comの裏側で使われている技術などを解説するものですが、視点としては多少ネットワーク寄りになる予定です。

第一回は、DMM.comが運営されている環境の概観を紹介しつつ、今後掘り下げて行く予定にしている項目をいくつか示します。

DMM.comの規模

bps(bits per second)は、ネットワークを語るときに非常に良く利用される指標です。その名の通り、1秒間に何ビットが転送されるかを示しています。一般的なOSでは、8ビットを1バイトとして扱っているので、たとえば、800Mbpsでの通信であれば、100MBのファイルを1秒で転送できるぐらいだと言えます。

DMM.comが扱っているネットワークトラフィックは、ピーク時で100Gbpsを超えます。100Gbpsというのは、10GBのファイルを0.8秒間で送信するぐらいの規模ですが、それが毎秒送信されているのです。凄い量のパケットがDMM.comからインターネットに向けて毎秒配信されています。

このトラフィックは、「艦隊これくしょん」などのゲーム(2014年7月現在246タイトル)、コンテンツ配信、通信販売、オンラインレンタル、などを提供するためのものです。以下の図のように、DMM.comの会員数は増え続けていることもあり、インターネットに向けて配信しているトラフィックも年々上昇しています。2014年1月時点で、会員数は900万を超え、月間PVは16億にもなります。

100Gbpsものトラフィックをどのように捌くの?

現在、市場で購入可能な商用ネットワークインターフェースで最も広帯域なものは100Gbpsの通信が可能な100ギガイーサネットです。100ギガイーサネットは、数年前に標準化され、最近になってやっと商品が揃いつつありますが、それを使ったとしてもDMM.comの全てのトラフィックを捌くことはできません。さらに、一ヶ所で全てを配信するようなネットワーク設計にしてしまうと、何か問題が発生したときに全てがストップしてしまうので、複数の回線を使ってトラフィックが流れるようにしてあります。

AS間接続
図:AS間接続

DMM.comとインターネットを繋ぐ回線は、合計で180Gbpsの帯域があります。この値は年々増えていますが、まだまだ増えそうです。

この他、CDN(Content Delivery Network)事業者と呼ばれる、インターネットデータ配信代行を行う事業者に依頼してのデータ配信も行っています。

物理的にどこに置くの?

DMM.comが配信する100Gbpsを超えるトラフィックは、物理的に1ヶ所から配信されているわけではありません。

日本国内にある4ヶ所のデータセンターから配信されています。4つのうちの3つは東京にあり、残るひとつが九州にあります。それぞれ目的に応じてデータセンターが使い分けられています。

4つのデータセンター
図:4ヶ所のデータセンター

個人で小規模なWebサイトを運営する場合、ホスティング事業者などからサーバを借りますが、DMM.comの場合はデータセンター事業者から「場所」を借ります。このような場所借りは「コロケーション」と呼ばれています。コロケーションサービスによって提供されている場所に大量のサーバを持ち込み稼働させるという手法は、大規模なWebサービスを運用するうえで良く行われる手法です。

拠点間の通信ってどうやってるの?

DMM.comは、物理的に異なる4ヶ所のデータセンターで運用されていますが、それぞれのデータセンターを何らかの形で結ぶ必要があります。提供しているサービスが大きくなってくると、一ヶ所では運用し切れなくなり、一ヶ所で運用し切れなくなると拠点間の通信をどのように行うのかを考える必要がでてくるのです。

DMM.comは、東京都内にあるデータセンター間を結ぶために、「キャリア」と呼ばれる大規模通信事業者から光ファイバを借りています。こういった長距離光ファイバは、光が通っていない状態であることから「ダークファイバ」と呼ばれています。

拠点間を結ぶ方法としては、ダークファイバ、L2伝送、VPNなど、いくつかの方法がありますが、各事業者がおかれている状況に応じて必要なサービスが選択されたうえで運用されています。

「裏側」のトラフィック?

ネットワークトラフィックには「表側」と「裏側」があります。表側は、インターネットに対してサービスを提供する部分ですが、これが先ほど書いた100Gbps超のトラフィックです。

Webサービスの規模が大きくなってくると、1台のサーバだけで全てを完結するのが難しくなってきます。たとえば、DMM.comでは、データベース、ログイン認証、課金のための仕組み、データストレージなどが、それぞれ独立した別々のサーバで稼働しています。これらがDMM.com内部ネットワークでの「裏側」トラフィックを発生させます。

Webサービスの規模が大きくなって行くと、裏側のトラフィックをどのように制御するのかに関しても様々な工夫が必要になります。新しい機器が登場しがちなジャンルでもあるので、数年おきに運用トレンドが変わっていく部分でもあります。そういった「楽しさ」があるのも「裏側」の特徴かも知れません。

膨大な台数をどうやって管理するの?

DMM.comは、2014年8月現在、あわせて約4500台の物理サーバと仮想サーバをデータセンター内で運用しています。さらにそれに加えて外部のパブリッククラウドサーバでの運用も行なっています。

このような台数のサーバを全て手動でひとつひとつ制御するのは、もはや困難です。「複数のサーバを同時に制御するための仕組み」を考えることは、いままさに大きなトレンドであり、様々なものが提案されていますが、DMM.comでは構成管理ツールのansibleを一部で利用したり、Webサーバの操作やデプロイにcapistranoを利用しています。大量のWebサーバの管理は、capistrano等の自動化ツールがないと不可能です。

これらの他に、どのラックにどのような機器がマウントされているのかなどをRackTablesで管理しています(参考 racktablesを使っています)。

膨大なデータをどうやって記憶しておくの?

Webサービスが巨大になっていくにつれ、膨大な量のデータを扱う必要も出てきます。

個人的に運用している小規模なWebサイトであれば、1台のサーバにデータを記憶させておくことも可能でしょうが、規模が大きくなってくるとデータストレージ部分を独立したサーバ群として管理する必要がでてきます。

データストレージも時代とともにトレンドが変化している部分であると言えます。DMM.comでのデータストレージ方法も、そのうち解説する予定です。

続く

今後、こういった話などをひとつひとつ掘り下げて連載していきたいと考えています。お楽しみに!

PAGE TOP