艦これ

E-1を攻略すべくネットのwiki情報を駆使しています。
最終ボスの潜水艦にダメージを与えてゲージを無くせば潜水艦娘が出現するらしいので、
潜水艦娘目指してがんばっています。

潜水艦攻撃用開発について

旗艦 駆逐艦 雷(レベル18)
20/60/10/110

3回連続回して

瑞雲 対空+2、対潜+1、爆装+4、命中+1、索敵+6
瑞雲 対空+2、対潜+1、爆装+4、命中+1、索敵+6
九四式爆雷投射機 対潜+4

瑞雲は航空戦艦か水上機母艦
九四式爆雷投射機は軽巡洋艦で搭載します。

現在の編成は
戦艦、水上機母艦、航空戦艦、軽巡洋艦、軽巡洋艦、軽巡洋艦、

この編成で潜水艦娘を目指してE-1チャレンジ中。

少しづつゲージが減っていっています。
あと10回はチャレンジしないと。

超解釈

 

サイジングでよく出てくる言葉
iops 「input output per second」

ディスクが1秒間に処理できるI/O要求数。(プラッターをシークし移動する平均時間+ディスクを書き込み位置へ回転させるための平均時間+ディスクに書き込む時間)

ここでミソとなるのがプラッターなどの移動時間がすべての処理で含まれているということ。

180iopsならその180すべての処理にプラッターの移動時間が含まれている。

ということはシーケンシャル、ランダム、read、writeやキャッシュのことを考慮しなくとも、
単純に最低でもこのくらいの処理はできるという数字と見て取れる。

この数字さえわかればサイジングは簡単

DBなら秒間どのくらいのトランザクションを処理したいのかを確認する。

500トランザクション/秒がほしいと回答がくれば、

HDDのiopsは180前後と言われているので、HDDを4玉使ったraid5を構築すれば仕様は満たされる。

そして、この例だと180*3で540iopsが期待でき500のトランザクションが同時に実行されても最大で1秒以内の応答時間で完結する。ほんとに同時実行なら最大で1秒待たされるトランザクションがいるはず。

ここで新しく応答時間という言葉が出てきました。

応答時間1秒以内というのが、これまたポイントになります。

iopsだけの設計だと確かに仕様は満たします。

だけど、

当然、応答時間が考慮されていないので開発者側としては、「いやいや1秒もかかってるんだけどディスクが遅いんじゃないの?」という話になる。しかも早いもの遅いものが混在して一定の速度がでない状況。

そこで応答時間を使ったサイジングの登場ということになります。

こちらもどのくらいの時間を想定しているのか確認する必要があります。

もし、応答時間が0.1秒以内でということなら

iopsが500で0.1秒以内の応答時間という要件に対してiopsを設計するという形になります。

となると、iops5000をクリアできる設計とすれば余裕を持ったサイジングになると思います
※ライトやリードキャッシュなどを使うことになるので余裕があると考えられそうです。

なので、このケースではssdを利用することになるのかなと。

とりあえず、これだけ押さえておけば大丈夫なんじゃないかと思いますが、
みなさんいかがでしょうかね?ご意見お願いします。

今後は各社のクラウド環境やローカルディスク、シェアードディスク、infiniband、ethernet、fc、iscsi、hdd、ssd、iodriveなどいろんな環境が出てきます。そのどの環境においても適切なサイジングでプロビジョニングしていく必要があるかと思います。

そうであっても、上記の二つを考慮してベンチマークを取ることである程度の対応は可能と考えます

そもそもディスク周りを考慮するのはDBかファイルサーバ系だけで、その他は何も考えずに投入できると思っています。

そういえば、

ssdやiodriveはiops数千~数百万ですが、

これらNANDフラッシュと呼ばれる機器はなぜiopsがずば抜けているのか。

プラッターが移動する時間がないからです。
HDDのiopsの1秒間、プラッターが移動で使っている時間は0.8秒と思えばわかりやすいかも。

それがほとんどないわけですから早い

ただ、HDDもシーケンシャルリードやらリードライトキャッシュやらで速度改善は行われています。

 

最後に超解釈というカテゴリを作りました。

自分がいろん文献を読み漁り、いままでの経験から、
ここだけは押さえときましょうという部分を超簡単に解釈してみるカテゴリです。

「これは抑えとかなだめだろ?」というものや、
間違ってるものがあれば指摘いただけると助かります。

みなさんの解釈を掛け合わせてコネコネして、もっと面白い情報にしたいと思います。

まだまだもっと知りたいスーパーインフラエンジニアを目指す方は
ここを入口にもっと奥まで入り込んで、いろんな発見してみてください。そして教えてくださいね。

インフラ全般

 

私の見解としてはDNSラウンドロビンは「あり

ですのでdmmでは一部でDNSラウンドロビンを使っています。

なぜ、使っているのか

最近のブラウザはfailoverの機能を持っているからです。

3つのホストでラウンドロビンの設定をしておけば、OSブラウザはその3つのホストを保持します。

そしてエラーが返ってきた瞬間に即座に次のホストを試します。

ブラウザでfailoverが可能だということはDNS系での負荷分散は下記の二つで実現できるということになります。

  • GSLB
  • ブラウザ※ブラウザのバージョンによる

上記のどれもがホストのダウンを検知すると切り替える能力をもっていますが、

GSLBはブラウザやDNSサーバのキャッシュにより切り替わりに多少時間がかかります。
※ちなみにGSLBの設定でAレコードをいくつも返すようにすることは可能です。

dmmでは画像関連のサーバでラウンドロビンの設定となっています。

www.dmm.comはGSLBの設定でAレコードを一つだけ返すような設定としています。
※将来的にはDNSラウンドロビンへ移行したいと思っています。。

大規模サイトをdigってみると

facebook.comとrakuten.co.jpはAレコードが1つ

apple,ebay,msn,yahoo,twitter,tumblr,googleやamazonなどはAレコードが複数でした。

ラウンドロビンが多数派ですね。

もちろん、ラウンドロビン以外の分散方式が幾重にも連なっているはずですが。

ちなみに、ブラウザのキャッシュを確認する方法ですが、

コマンドプロンプトで「ipconfig /displaydns」となります

ぶらぶらと出てくるものがキャッシュです。

キャッシュクリアは「ipconfig /flushdns」です。

追記

rfc3848の規定でDNSラウンドロビンが使えなくなるのでは?という指摘がありました。
このあたり知りませんでした。ご指摘ありがとうございます。

これについて

DNSラウンドロビンをどのように使うのかで意味が変わると解釈できそうです

サーバで障害が発生したとしてもブラウザの切り替えによって切り替えさせたいという目的においては、

DNSラウンドロビンは「あり」

DNSラウンドロビンにて均等に負荷分散したいという目的であれば、

rfc3848を考慮し多少工夫する必要がでてくるのではないかと思います。

ちなみにdmmで利用しているまったくrfc3484rfc3848を意識していないDNSラウンドロビンですが、
いまのところ均等に分散されているようです。

私の環境(Windows7)においてはランダムで選択できているようです。

調べてみたところ

Microsoftの情報ではWindowsVistaとWindows2008では標準でランダムで選択していない。
ランダムで選択させたい場合はレジストリを修正してくださいという記事がありましたので、
意外と影響のあるOSがvistaだけだったりして、均等に分散されているのかもしれませんね。

ところでDNSラウンドロビンで均等に分散させるためのアイデアですが、

うちだとアプライアンスを使ってCNAMEで分散させるとかですかね。

Akamai社のGTMも面白いと思いますし、

Amazon社のroute53(WRR)も今後進化を遂げるとすれば選択肢としてはありかもしれません。

インフラ全般

 

ウェブサーバとmemcacheサーバの通信においてトラフィックが最大で120Mbpsの帯域を想定しているとする。

この状況において

アプリケーション全体でパフォーマンスを最大化するミッションがあったすると、

インフラエンジニアはどう対応すればいいのでしょうか?

みなさんならどう考えますか?

いままでは、gigabit ethernetで十分帯域は足りるのでgigabit ethernetのスイッチとnicで接続とし、帯域が足りなくなればLAGで対応するという形でした。

ただ、アプリケーション全体でのパフォーマンスの最大化を考える場合においては

スイッチ側ネットワークのlatencyも考慮する必要があります。下にあるリンクの画像を見てもわかるとおり

http://www.networkworld.com/graphics/2008/0714-latency.gif

L2で10G接続が一番パフォーマンスが良いことがわかります。

もちろん、予算などとのバランスを考える必要がありますが、より広帯域で低latencyのスイッチやNICを選択する事となります。inifinibandなども検討することになるかと思います。

クラウドの共有ストレージを考える場合も同じです。

kvmならvirtioなどのドライバを利用し、
かつ、より広帯域なスイッチやinifinibandを検討という形になるかと思います。

ここでわかってくる事は

アプリケーションといってもインフラエンジニア側で他人事とすべきではないことです。

どんなことであっても、チーム内でいろんな可能性について考えてみると良いのではないかと思います。

ちなみに、dmmではまだまだgigabit ethernetが主流です。

 

 

運用管理

みなさん、監視してますか?※長嶋さん風

監視ネタを一つ

監視は大きく2種類に分けられます。※セキュリティやログなどの監視除く

1.サービス監視
※サービス監視はhttpやdbやその他アプリケーションレベルでの監視

2.リソース監視
※サーバのcpuやメモリなどの機器のリソース状況の監視

dmmではこれらを明確に区別して別経路で監視しています。

サービス監視はお客様と同様の経路で監視することとしています。

リソース監視は管理用のネットワークからでもSerial over LANでもIPMI over LANでもどこからでも良いとしています。

なぜそうなるのか

お客様が通る道以外で監視を行ってしまうと、お客様が通過する経路で障害が発生してもアラートを上げることができないからです。

かつてはどこからでも監視さえすればいいという形で監視していましたが、

過去に何度かアラートがあがっていないのに接続できないという事象が発生していたので、

その過去の経験をもとに区別して考えるようになりました。

カイゼン事例の一つです。

 

 

 

PAGE TOP