製品

fastsoft

この製品のユニークな点は、サーバーサイドに設置するだけで、
複数拠点へのダウンロードを高速化できることです。従って拠点数
が増えてもコストは上がりませんし、拠点の保守が不要ですので
メンテナンスコストも最小化できます。
不特定多数を対象とした高速化及び海外拠点との通信の高速化を
お考えてあれば、まさに最適なソリューションと言えると思います。
FastSoftは全てのTCP通信を対象に高速化をしますが
CIFSの様にアプリケーションで応答確認をするプロトコルの高速化は得意ではあり
ません。FTP, FTPS, SSL, HTTP, HTTPSなどの高速化に適しています。

とあります。これは我々が導入するだけでお客様への通信が高速するというもので超画期的な製品でした。

昨年この評価をしたことがありますので結果を張り付けようと思います。

検証内容と結果

回線:1G
FTPサーバ
OS:CentOS 6.2 X86-64
CPU:24コア
搭載メモリー:16GB以上

同梱されていたバイパス機器は通さず
サーバをfastsoft配下に直接配置し
先方からftpクライアントでアクセスしダウンロード速度を計測しました。

台湾1
fastsoftなし:6Mbps
fastsoftあり:112Mbps
先方の回線速度:不明
クライアント情報:不明

台湾2
fastsoftなし:1.7Mbps
fastsoftあり:2.5Mbps
先方の回線速度:15Mbps
クライアント情報:不明

韓国1
fastsoftなし:7.3Mbps
fastsoftあり:11.68Mbps
先方の回線速度:基本128MB/s(1Gbps)、最大1.25GB/s(10Gbps)
クライアント情報:不明

そして、最後に東京とAWSのサンパウロリージョン間でテストしてみました。

地球の反対側にも関わらず、結果、4GBのcentosのisoが8秒で転送完了したのです。爆速です。

Akamaiのネットワークのバックボーンが大きいこと。我々のバックボーンの帯域も大きいことが起因して地球の反対側から500MB/sの速度をたたき出したものと思います。

これを使えば世界で一番安いidcにサーバを設置しても、エンドユーザに対して国内サーバからダウンロードしているのとなんらかわらない状況を作り出せる。どんなに遠くても。

これは我々にとっては革命でした。大きな衝撃とともになぜか心の中から何とも言えない喜びがわいてきたのを覚えています。

こんな画期的な装置を手に入れないわけにはいかないと購入に動いたところ、僅差でAkamaiさんに買収されてしまい。販売が急きょ中止となりました。

たしかにAkamaiさんにとっては死活問題となりうる機器。芽を摘んだというところは先見の明があります。さすがですね。

インフラ全般

dmmの歩んだidc遍歴をご覧ください。

最初はラックの空いたところを借りて運用していました。

20130809-163629.jpg

 

idcに空きがなくなると別のidcを借りることになります。まとまったラック数になるまではこれを繰り返します。

20130809-163712.jpg

 

これだけ分散すると運用が厳しくなるということでラックをまとめて一か所のidcに集めました。

20130809-163704.jpg

 

余裕があると思っていたのにすぐに埋まってしまいました。また借りなくてはいけません。ただボリュームが多くないので一括で大きく借りることはできないので1期、2期と同じようにラックを集めていきます。これが4期です。

20130809-163722.jpg

 

各idcが専用線でつながっていないとサーバの物理的な移動が発生する。またサーバの設置が偏ることになる。ということで各idcを専用線で繋ぎました。5期に突入です。ここからidcからvdcとなったといえるのではないでしょうか。

20130809-163730.jpg

 

そして、現在のvdcとクラウドの融合。

20130809-163738.jpg

 

我々のチームの役目としてパブリッククラウドであれ自社環境であれ事業で必要なものを必要なタイミングで確実に提供しビジネスの加速を鈍化させない事が重要と考えています。納期、利用する時間帯や課金方法など適材適所で最適解なインフラを最適なタイミング提供し、また、すべての環境へスムーズに移行できるような開発体制を取ることも重要視しています。

コストxパフォーマンスx納期x可用性x操作性x熟練度x信頼性xセキュリティx課金種別。すべてを考慮して最適解を見出すということ。

dmmが目指す最終形態はすべてのリソースプールの共通化ですが、

いまはまだシームレスに自社環境、クラウド、cdn間の行き来ができていないが現状です。

将来的にはボタン一つで簡単に移行できるようにすべきだと考えています。

glusterfs, linux

DMMで利用されているGlusterfs

ちょっとした工夫で耐障害性を向上させています。

通常は下記のようにサーバがfuseによってglusterのボリュームをマウントします。

※nfsでもcifsでもマウントできますがfuseが推奨されているようです。残念ながらWindows版のfuseクライアントは開発途中です。

この場合Glusterpeerで冗長性が取られていたとしてもサーバがマウントしているGlusterサーバが落ちるとサーバ側にも障害が発生してしまいます。しかも裏側が死んでいるのにもかかわらずフロント側のアプリケーションがサービスを受け続ける状態となってしまうのでやっかいな状態となる。

これを回避するために書き込みができるかどうかの監視を行い障害箇所を切り離すようするのですが、リアルタイムではないので問題は完全に解決しません。

fuse_mount

そこで我々がとったアプローチは下記の構成です。

サーバもglusterpeerに参加させ、そのpeer上でGlusterボリュームをマウントする。

こうする事でGlusterサーバのA,B,Cのどれが落ちても冗長性が保てるようになります。

Glusterpeer_mount

 

サーバはpeerに参加はするのですがbrickは一つも提供しません。

また、別のアプローチとしてglusterサーバ上にアプリケーションを乗っけてそのまま運用している場合もあります。

用途に合わせた使い分けを行うのが重要です。

みなさんはどのようにお使いですか?ぜひ教えてください。

co-location, hardware

サーバなど付属の電源ケーブルは2mや3mの長さが標準です。

これらのケーブルを使用するとラック内がスパゲッティ状態となり、さらに空調の妨げにもなります。

昔の写真をお見せしますね。これだ

lanケーブルのカーテン

 

お恥ずかしい限りです。LANケーブルのカーテンができています。

これらをすっきりさせるため

dmmではラック内の空調の流れを妨げないよう50cm、70cmの短いケーブルを特注しこれらのケーブルを使うことにしています。

SAMSUNG

機器の外観のチェックや調査などにも役に立ちますのでおすすめです。

もちろん、ネットワーク機器などの精密な機器と思われる機器や指定されている機器は付属のものを利用していますのでご安心を。

艦これ

おかげさまで大好評をいただいております艦隊これくしょん。

我々、エンジニアでもはまっていますよ。楽しいですよね。

最初はとっつきにくいのですが、進めるにつれてキャラクターに思い入れが出てきて、 かつての日本帝国軍のすごさを肌で感じるでしょう。

大和型戦艦が出るまではやめられない

みんな、お金を支払わず試行錯誤しながら楽しんでいます。

演習なんかは毎日のルーチン作業に組み込まれているようです。^^;

PAGE TOP