とある3つの出来事から、アメリカにあるサービスを日本からインターネット経由で利用するというのも大変かもしれないと考え始めています。

● ● ●

一つ目は話題になっている前村さんの発言の一部です。

「ネットはBUSじゃない」

もちろんこれは単純に「じゃぶじゃぶ使うな」という意味で使ったわけでなく、インターネット特有の相互接続の仕組みなどを考えた上で使っていかないとリスクがあるというような話し合いの中で生まれた言葉でした。

プロジェクトXだったら間違いなくオープニングで活字に選ばれた言葉になったでしょう。「ファイバーはカッパーじゃない」というような言葉もあったように思います。もしオルタナ流行語大賞があったら今年は間違いなくこの言葉はノミネートしますね。

いずれにせよ、ネットワークは基板上の配線とは違うことを念頭に置いてクラウド化の可否を決めなければ、という話でした。

● ● ●

二つ目はとある方からとの雑談です。例えば日本に置いたサーバを使い、アメリカの支社にインターネット越しでアプリケーションをサービスしたいとしたら、回線の事情による障害を考慮しないといけない。どうやったらいいサービスができるだろうか。

これはややこしい問題です。日米間に限っても数多くのケーブルが通っていて、しかも学術ネットワークだったり最新のTbpsクラスの商用ネットワークだったりします。日米間ケーブルと言ってもユーラシアから流れてくるトラッフィックもあるでしょう。そういえばNコムさんもちょっと前にお買い得な買い物をしたようで。こういう動きがあると、米国に設置された巨大DCから日本はじめアジアに向かってばんばかトラフィックが流れる未来というのが本当のものに見えてきます。KDDI+googleその他という話題もありましたし。

もし障害について考えるのであれば、多少お金を積んだからといって回線の真ん中が切れづらいとかいうこともなく千切れるときは全部切れるでしょうし、終端機器に安いのと高いのがあるということもないでしょう。つまりおいしいところとかはじっこというものはなく、おそらくは高い金を払えば障害時に別経路への切り替えがそれだけ優先的に行われ、また最初からある程度分散されているというような感じになるんじゃないかと勝手に想像しています。

海底ケーブルの障害なんて全然ないかと思いきや台風やら地震やらで発生するときはしますし、起きてしまったらもう地球の反対側を回ってでもなんとかルーティングしてもらわないと困ってしまいます。海底ケーブルはリング型に敷いてあるので2箇所切れない限りは大丈夫という気もしますが、どうなんでしょう。何年か前の台湾大地震があったときは日本にも影響が来ました。ああ、このへんのことをオルタナのネットワーク部隊に聞きたい……。

電源だと電力会社に頼んで2系統もらったりということがありますが、ネットワークだと違う系統の海底ケーブルに分散してもらえるように2系統もらうことってできるんでしょうか。ハワイ周りと北周りとか。しかも日本で陸揚げしている場所まで別になるように選びたいとか。あとは某大陸へ分岐していくケーブルはなんとなく有事にサイバー攻撃されそうだから日米で完結している経路にしてくれとか。ああ、このへんのこともオルタナのネットワーク部隊に聞きたい……。

あとはプロバイダ間の接続です。国内大手ISP同士での接続はともかく、海外との接続となるとやはりプロバイダによる差が出てくるんじゃないかと思います。全然つながらないということはないにしろ、ホップ数が多くて遅延が大きいですとか、通信エラーがぽつぽつ出たとしても放置されるとか。これは、聞いてしまったら最後墓の底まで持っていかなくては……。

● ● ●

そしてようやく三つ目ですがこちらのニュースです。

Amazonクラウド、大規模データをHDD郵送で受け入れ − ＠IT via kwout

アメーバブログ  livedoor ブログ  はてなダイアリー  ココログ  Seesaa ブログ  So-net ブログ  エキサイトブログ  sa.yona.la  Twitter  Facebook  MySpace  Gmail  Tumblr  Blogger  Vox  Evernote  FriendFeed  Flickr 

ハッブル宇宙望遠鏡で撮影した100TB超のデータをGoogleスカイに載せるためにFedexががんばってHDDを運んでいるという話は有名です。普通のTCP/IPの仕様だと遅延の影響が大きいんですよね。

AWSで有名なRX7さんのサイトによると、アメリカ東海岸の拠点で200ms、ヨーロッパ拠点で300msほどの遅延が発生してしまうようです。200msというとウィンドウサイズを増やすにも限度ってものがありますし、エラー時の再送ロスのことなども考えるとどんな幹事でチューニングしたらいいんでしょうね。

そのあたりのことはおそらく回線遅延シュミレータを投入して動かしてみるとすっきりするように思います。残念ながら私の身近にはAPサーバもDBサーバもない環境になってしまいました。小俣さん、クラウドを想定してアメリカ（RTT200ms）との接続はこんな感じになりますよというデモなんてしたらEthdelayがヒットするかもしれませんよ！

ただでさえ長いエントリに更に余計なことを付け加えると、WebサーバとDBサーバからなるようなシステムでWebサーバとDBサーバ間のネットワークが貧弱だとDB応答を待っている間にWebサーバにリクエストが溜まってメモリ周りが心もとなくなるかもしれませんね。