勉強会, 小ネタ, 雑談

3月から定期的に部内勉強会を開催しています。
今年開催した勉強会のお題目は以下(開催日時順)。

  • DOM →関連記事
  • ベアメタルサーバの構築自動化
  • NTTグループとソフトバンクグループ
  • JSON
  • KVM
  • PerconaDB
  • CloudStack
  • 大規模メールシステム
  • Kibana + ElasticSearch + Fluentd
  • LVSクラスタの構成と動作原理
  • QFabric
  • 囲碁のお勉強 →関連記事
  • ネットショッピングシステムの仕組み
  • DNS勘所
  • フローコレクタ
  • RADB、IRR
  • ブレードシステム
  • JANOG34振り返り →関連記事
  • Javascript、CSS
  • 大規模障害の振り返り
  • MySQL
  • 小学生にもわかるSDN →関連記事
  • CentOS7
  • ガンダムの歴史 その1
  • GlusterFS
  • いけてないIPv6とどう付き合うか →関連記事
  • DMMコンテンツダウンロードシステム
  • ディズニーについて
  • oVirt

この中の

  • GlusterFS
  • DMMコンテンツダウンロードシステム
  • QFabric

などは、あまり他では使われていない技術なので、ちゃんとこのブログで発信しなきゃいけないとは思うのですが、記事を書くのをさぼっててすみません。

ただ、著作権の関係で資料を公開できないものもあるんですよね。このへんですね。

  • ガンダムの歴史 その1
  • ディズニーについて

ガンダムの歴史では、宇宙世紀の始まりから1年戦争の終結までにあったことを、アニメ、漫画、小説、ゲーム等の膨大な資料から引用しつつお勉強。
ジャブロー上陸作戦はジオンの特攻だったんですねえ。
来年は1年戦争以降から勉強すると思われます。

ディズニーのお勉強もディープでした。
TDRのあちこちで売っているチョコクランチの味は同じじゃない、とか知ってました?
缶の裏を確認すると製造メーカーがわかるんですよ。
実食もおいしかった。
来年も実食付きの勉強会があると良いなあ。

 

今後も勉強会を続けていきたいと思っています。
一緒に楽しく勉強したい方は是非join↓してくださいませ!!

DMM.comラボ採用情報
http://labo.dmm.com/recruit/

それと出張勉強会の要望があれば気軽に言ってくださいね。

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

次回予告

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

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

この連載の過去記事

IPv6, ネットワーク, 勉強会, 雑談

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

 

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

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

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

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

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


(追記)

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

関連記事↓

パブリックサーバ

セキュリティ

みなさんは大丈夫なのかもしれませんが、2点ほど危ないなあと思ったので書き留めておきます。

9月24日、bashにCriticalな脆弱性が発見されCVE-2014-6271として注意喚起が行われた。これに対してパッチは公開されたようですが、完全に対応が出来ていなかったため、CVE-2014-7169として新たに注意喚起が行われている状況です。

そして、9月26日、CVE-2014-7169に対応したパッチが公開されセキュリティアドバイザリーがなされています。

こうやって近しい日付で2段階に注意喚起が行われているため昨日の段階で対応された方は次の日に同じ話題となっていても同じ脆弱性のことを言ってるんだなと安心しきってしまう恐れがあるように思います。4桁目を変えてはありますが番号も似ているし危ないなあと思った次第です。

対応するパッチに不備があると、注意喚起も新規に発行されるようになっているんだとは思いますがこのあたりをちゃんと認識しておく必要があるようですね。

■CVE-2014-6271
https://access.redhat.com/security/cve/CVE-2014-6271
redhatのerrata発行(セキュリティアドバイザリー)
https://rhn.redhat.com/errata/RHSA-2014-1293.html

■CVE-2014-7169
https://access.redhat.com/security/cve/CVE-2014-7169
redhatのerrata発行(セキュリティアドバイザリー)
https://rhn.redhat.com/errata/RHSA-2014-1306.html

また、もう一つの注意点として
# yum update bash
などで対応されると思いますが、例えばパブリックミラーにより同期が間に合わず修正版が上がっていないところも見受けられます。アップデートは必要がないと出ていても別のミラーには存在していることがありますので7169に対応しているバージョンなのかどうかをちゃんと確認することをおすすめします。

OS(x86_64) CVE-2014-6271 CVE-2014-7169
RHEL5 bash-3.2-33.el5.1 bash-3.2-33.el5_11.4
RHEL6 bash-4.1.2-15.el6_5.1 bash-4.1.2-15.el6_5.2
RHEL7 bash-4.2.45-5.el7_0.2 bash-4.2.45-5.el7_0.4

仮想化, 勉強会

囲碁の勉強会も相当無茶振りだったのですが、今回のお題もかなり無茶です。

とはいえそれなりに頑張るのがプロサラリーマンってもんです。

それなりな資料を作ってそれなりにごまかせたので資料を公開しておきます。

後半は著作権上問題がありそうな図とかもあるので非公開です。ごめんなさい。

PAGE TOP