小さな町を「データセンターの聖地」に変える Facebook 85
ストーリー by reo
現地雇用をあんまり産みませんから 部門より
現地雇用をあんまり産みませんから 部門より
ある Anonymous Coward 曰く、
本家 /.「Facebook May Make Tiny Town a Data Center Mecca」より。
オレゴン州プラインビルに Facebook のデータセンターがオープンしてから一週間後、この小さな町に、さらに 2 つの企業がサーバーファームを建築するかもしれない、という話が持ち上がった。Facebook はプラインビルについて「外気冷却のための理想的な環境」と述べたそうだが、このニュースはプラインビルがデータセンターハブとして急浮上することを示している (かつてこのように小さな町がデータセンターファームの拠点となった例として、ワシントンのクインシーがある) 。
日本でも、北海道・石狩市にさくらインターネットがデータセンターを作るという例があるが、それ以外では地方の小都市にデータセンターを作るという話はあまり耳にしない。日本でこのような例が少ない原因は何なのだろうか ?
日本での実例 (スコア:2, 参考になる)
日本の地方の小都市にあるデータセンターの例。
＃関連ストーリーに表示されていなかったので…
IIJ、島根県松江市に外気冷却式コンテナ型データセンターの構築を開始
http://itpro.nikkeibp.co.jp/article/NEWS/20100826/351486/ [nikkeibp.co.jp]
帯広に床面積2,000坪のデータセンターを今年、開業
http://srad.jp/it/comments.pl?sid=432666&cid=1483519 [srad.jp]
わけがわからないよ (スコア:1)
どうして僕たちSEは怒田舎にある工業団地のデータセンターにいかなきゃならないんだい？
ここが地方じゃないならば群馬は東京だよ？
まったく君達タレコミ人の意図はわからんでありますよ
Re:わけがわからないよ (スコア:1)
田舎もなかなかいいもんだよ、と言うのは措いといて。
では、なぜ米国の技術者は田舎に行くんででしょうか。
Re:わけがわからないよ (スコア:3, すばらしい洞察)
片道80マイルの距離を通勤している友人を知っています。
どれくらい離れたところまで通勤圏なのか彼らに聞いたことありませんが、結構離れていても転職の障害にならないみたいで。
Re:わけがわからないよ (スコア:2)
うちの妹がアメリカ駐在中に、月に1度くらいは、平気でセントルイスからシカゴまで車を飛ばして買い物に行っていたって話してた。
元々、広くて田舎ばっかりの国だから、少々田舎でもみんな平気、てなかんじ。
Re:わけがわからないよ (スコア:2)
>日本：鉄道
東京の周りだけじゃね？
Re:わけがわからないよ (スコア:2, すばらしい洞察)
まさにそれが問題なんだよ。
「都会に行くには電車でなくちゃいけない」
「でも、田舎では自動車でないと移動できない」
というのが日本だとして、
「都会だろうが田舎だろうが、自動車でいけちゃう/自動車でないといけない」
のがアメリカ。
.
で、前から思っているのだが、それは単にアメリカ全土が田舎だからという事ではないのか?!
fjの教祖様
Re:わけがわからないよ (スコア:1)
都市間移動は、国内だとやはり列車でありますよ
バスは冬場は当てにならないし、飛行機は間隔が広すぎる……
Re:わけがわからないよ (スコア:1)
別に三重じゃなくても、近鉄（日本一の鉄道）があるってだけなら、
奈良も京都も大阪も滋賀もそうですよ。
もっとも、滋賀にあるのは近鉄は近鉄でも、
近（江）鉄（道）ですけど。
＃それは近鉄じゃなくてガチャコン
Re:わけがわからないよ (スコア:1)
群馬は東京ですよ [sanyo.com](ぇ
Re:わけがわからないよ (スコア:1, 興味深い)
というのはさておき、
過去に、東京三洋電機株式会社があったので、それを合併した名残ということでしょうかね。
Re:わけがわからないよ (スコア:1)
やぁ、奇遇だな。実は神奈川も東京なんだ [ibm.com]
fjの教祖様
Re:わけがわからないよ (スコア:1)
「日本では〜あまり聞かない〜」に対して、わけがわからないと言っているからでありますよ
#じつはここはデータセンターじゃなくてサーバ倉庫かもしれない
#動かないコンピュータだらけだ！！！
#我輩が動く様にしたら都市に納品されるんだね！
プラグインビル (スコア:1, おもしろおかしい)
後からモジュールを増設できるデータセンターに最適な構造のビルなのかと勘違いしました。
Re:プラグインビル (スコア:1)
もしかして：中銀カプセルタワービル
日本はなぁ～ (スコア:1)
大都市もちょっと怖いな。
Re:日本はなぁ～ (スコア:1)
>災害対策なら行うべきは広範囲への分散でしょう。
でしょうね。
最初は災害対策用DCってことで待機用のを集積。
ついで平行稼働やデータバックアップの遠隔地化をやりつつ
複数DCでの平行／災害対策というのがよいみたい。
サーバ設計で「一点障害でダウンはやだ」とかいっている割に
DCの一点障害やネットワークの一点障害(２系統とっていても、
同じケーブルだったり配管隣接だったり)があまり考慮されてい
なかったと思うね。
あと、どんどん平行稼働が進んでいく→複数の(いくつかの環境)
での稼働を前提としたシステム設計も進む→新しく安いDCが
できたらそこで使える→コストダウンというメリットも見込める
わけなんだよね。
仮想化とかって、最終的にはクラウド→分散拠点でのクラウドから
拠点という概念がないモノを目指している側面もあるんだよね。
Re:日本はなぁ～ (スコア:1)
空母作って沖合に浮かべておけばいいんじゃね？
これのことですね。
http://srad.jp/it/article.pl?sid=08/01/10/1253252 [srad.jp]
空母ではないですが。
Re:日本はなぁ～ (スコア:1, おもしろおかしい)
障害対応に呼び出されてヘリで駆けつけるSE。格好良い。
Re:日本はなぁ～ (スコア:1, おもしろおかしい)
「もしもし、SEです。はい、ただいま復旧しました」
「おー待ちくたびれたぞ」
「これから帰社しますのでヘリを…」
「あー帰りはゆっくり泳いできていいよ、おつかれさん」（ブツッツー…ツー…）
移動時間の問題じゃないでしょうか (スコア:1)
10年ほど前にサーバHWを売っていた頃の話ですが、
障害復旧寺にメーカーエンジニアが最速で駆けつけられる立地を考えると、
都内やそれなりの規模の都市に限られるという話を聞きました。
実際に、都内の修理では、現地で部品が足りなかった場合は、
バイク便で走ってきましたし。
# それでも直らなかったのは、懐かしい思ひ出。
答えはある。それを見つける能力が無いだけだ。
Re:移動時間の問題じゃないでしょうか (スコア:2, おもしろおかしい)
なんだかありがたそう
ショウガイフッキュウ寺院 (スコア:2, おもしろおかしい)
＊ でーたー は はいになりました ＊
Re:移動時間の問題じゃないでしょうか (スコア:1, おもしろおかしい)
Re:移動時間の問題じゃないでしょうか (スコア:2, 興味深い)
>障害復旧寺にメーカーエンジニアが最速で駆けつけられる立地を考えると、
まぁ、そういうお寺に直結しなければいけないシステム構成って
どうなの？ってなこともあるでしょう。
Linux/AIX/HP-UX/Solaris/Windowsといった宗派があるので、
お寺も色々でも設備を準備したり、駆けつける坊主も宗派なんか
にあわせていっぱい用意しなきゃならない。
それで飯を喰っている方々も多数いるわけなんだけど、そういう
コストを前提にしているからバカ高くなるわけな。
>都内やそれなりの規模の都市に限られるという話を聞きました。
そもそも、そこでそれを直さないといけないという体制／構成が、
問題なんだけどね。
Re:移動時間の問題じゃないでしょうか (スコア:1)
「データは輪廻転生せず、涅槃に至りました。もう復旧しません」と言われてチーーン…。
なので宗派問題もほとんど起こりません。
「まー、結局、死んでしまえば、阿弥陀如来がどうにかするからな」
「そうそう。あいつ辺土に『悟塾』っての開いて、塾長になったしな」
「『わしが悟塾塾長! 阿弥陀・如来であるっ』って叫んでるよな」
「死んだあとだから死なないっていうんで、物凄いスパルタ教育してるよな」
「そりゃ、どんな奴でも悟らせて見せるっって豪語したわけだし。一方で死なないのも本当だしな。遠慮なんぞする必要はないってもんだ」
「ビットでも悟れそうだな～～～」
fjの教祖様
Re:移動時間の問題じゃないでしょうか (スコア:1)
>「データは輪廻転生せず、涅槃に至りました。もう復旧しません」と言われてチーーン…。
いや、お陀仏になった方の宗派がいかないとどうも死亡診断もろくに出ないというのが、アレだったりする。
>遠慮なんぞする必要はないってもんだ
つまり涅槃で悟りをひらく修行としては、デスマに参加というのが結構有効だということでしょうね。
つまらない煩悩、たとえば、納期に間に合わせたいとか、たまには家に帰りたいとか、これ以上仕様変更は受けたくないとか、WBSの赤いラインを短くしたいとか、手順やプログラムをエレガントにしたいとか、バグが出ない様にしたいとか、コストダウンしたいとか、サビ残はしたくないとか、そうですね、１０８くらいあるそうなんですが、そういったものを捨て去って、ただ一心に写経というかプログラムとか手順書とかを書くわけですね。
それでデスマに参加されている方々は涅槃が近いのでしょう。
Re:移動時間の問題じゃないでしょうか (スコア:1)
>それらを見えない化するのがクラウドだったりするわけで
クラウドの目的のひとつがそれなんだけど、
なんかクラウドを構成する機器類を一カ所にまとめちゃって
いたりして、DCとかネットワークの一点障害から抜けきれて
いないクラウドが結構あるんだよね。
クラウドの定義として、「拠点依存しない」「拠点障害耐性」
みたいなのが見失われている面があるんだ。
Re:移動時間の問題じゃないでしょうか (スコア:1)
>障害復旧寺にメーカーエンジニアが最速で駆けつけられる立地を考えると、
「諸行無常」と唱えて諦めるんですね。
#諦観と悟りは違うらしいのでID
それはともかく
僻地（は言いすぎか）にも各社エンジニアが共用できる、各種パーツ等保管センターみたいなものがあればいいんですけどね。
……
ヤマダ電器とかそういう名前で建ってるのがソレかな。
Re:移動時間の問題じゃないでしょうか (スコア:1)
やはり昔ですが、外資系H/Wの部材調達で制限があったのを思い出しました。
こちらは全国各都道府県に１個所はセンター設置（間借りですけど）してたんで、復旧時間の比較により国内ベンダを選択した経緯がありました。
今の時勢だと、データセンターとはいえH/W調達や交換部材の供給がネックになる事は、恐らくないでしょうね。
反対に都内とか高いから費用対効果が少なく感じる企業も多いと思うんだけど。
フレッツ網のトポロジーのせい (スコア:0)
> 日本でこのような例が少ない原因は何なのだろうか ?
東京・大手町か大阪・堂島の近くにないとそれだけで不利だから。
北海道の端末から北海道のデータセンターにあるサーバにアクセスする場合、わざわざ地域IP網かNGN網を通って大手町まで行って、そこで外に出てISP網を経由して折り返してくるなんてアホらしいことになる。
ネイティブ方式IPv6サービスではNGN網内折り返しがサポートされるそうなので、ネイティブ方式契約者同士のIPv6 P2P接続はレスポンスタイムが大幅に改善されるんじゃないかな。データセンターには関係なさそうだけど。
Re:フレッツ網のトポロジーのせい (スコア:1)
……とかよく僕も言いますし、よく他の人から聞くことでもありますけど、折り返しても最悪で数〜数十 ms だったりしますよね。フレーム単位の精度が要求されるリアルタイムゲームのサーバでもなければ気にならないレベルじゃあないですか ? そしてそんなアプリケーションが世の中においてさして支配的でもないと思うのです。
Hiroki (REO) Kashiwazaki
Re:フレッツ網のトポロジーのせい (スコア:3, 参考になる)
＞折り返しても最悪で数〜数十 ms だったりしますよね。
WindowsServer2003系だとその数十msでこの問題 [microsoft.com]に引っかかることがある。
広域イーサネットのバックアップ回線にフレッツ光ネクストを使ったら食らいました。
水を飲むと屁(CH4)をこきます
Re:フレッツ網のトポロジーのせい (スコア:2, 参考になる)
とんでもない。
応答時間そのものはその程度でも、それだけ中継局があると、RTTが「どれぐらいばらつくか」と言う問題が別途発生します。
TCP/IPで、流量制御をするときに、RTTを元にWindow Sizeを変更して流量制御をしたりなんかしている世界では、数msec～十数msecもバラつかれたら、LAN⇒WANの部分でパケットロストが起こりますよ。一気に通信速度が落っこちて、運びきれたデータが時間内に運べなくなります。
# 「だから、WANの回線はRTTがバラつかないものを選べと言うておるにっっ」
# と何度お客様に釘をさす羽目に陥ったことか…
fjの教祖様
Re:フレッツ網のトポロジーのせい (スコア:1)
アメリカの回線状況って、そんなに日本より良いのかな～？
この話は小さな町にプラインビルという使える箱があったから成り立ってるんだが、某ミュージシャンが「地方で立派なホールがあっても使えない」なんて話をラジオで言ってたから、他の業種でも日本は使えない箱ばかりの箱物行政やってたんじゃないかな。
the.ACount
Re:フレッツ網のトポロジーのせい (スコア:2, 参考になる)
RTTが安定して『長い』上に、通信速度が遅い回線というのがアメリカの特徴だ。例えばRTTが100msec - 120msecの範囲でバラついたりする。
RTTが不安定で『4倍ぐらいのふらつきがありえる』が、トップスピードが早い回線というのが、日本の特徴。RTTが4msecから20msecの範囲でバラついたりする。
判ると思うけど、RTTの最小・最大値の差は日本の方が小さい。単純に考えるなら、変動誤差の絶対量は日本の方が小さいのだ。しかもRTTの平均値自体だって日本の方が小さい。でも。
アメリカの場合、TCPは回線を目一杯まで使いまわしてくれる。RTTの変動は20%程度なのが、うまく行く理由だ。
日本の場合、TCPは回線に目一杯振り回されて、ろくなパフォーマンスにならない。RTTが5倍もバラつくからだ。
カタログスペック的にはアメリカの方が劣悪に見える。bps値は遅いし、RTTだって長い。でも、ばらつきからくる制御のし難さ、という観点で見た途端に、実はアメリカ型の方が制御し易い事になる。回線を利用し易いのは「カタログスペック上の数値の悪い、アメリカ型」だったりするのだ。
というか。多分TCPの実装は大抵アメリカでやってるから、そっちに合い易い制御構造ばかり採用するってのもポイントだと思うよ。日本の企業がもっと「フリーハンドで使える予算」を末端の開発者や研究者に渡し、結果をもっと世界中で自由に利用できるよう、余計な縛りを外してくれれば、RTTの絶対値が小さい方が有利な制御機構をなんぼでも実装できると思う。
fjの教祖様
Re:フレッツ網のトポロジーのせい (スコア:1)
どちらかというと専用線のコスト高じゃないですか。
光どころかDSLが通っていないところだと、初期投資が土地代より高くなりますので…
あとはメンテナンス（出張費等）とか含めると地方は結構お金がかかりますよ。
＃データセンターじゃないですが、地方の事業所でそんなことがありました。
Re:フレッツ網のトポロジーのせい (スコア:1)
>初期投資が土地代より高くなりますので…
土地代を初期投資以下に抑えられるという文脈も成立するかもね。
>あとはメンテナンス（出張費等）とか含めると地方は結構お金がかかりますよ。
わざわざ出向かないと出来ないメンテナンスが多発するのであれば、
それは構成を見直した方がよいと思う。
構成の中には、「予備機を何台か抱えておいて、自動プロビジョニングなんか
で待機させておいて、不稼働が一定数を越えるであろう時期を定めて定期的に
いく」といったのも含めてね。
インフラ系の専任SEを地元で確保しておいて、あとは遠隔操作だろうな。
東京にあれば計画停電を気にしなくて済む (スコア:0)
やっぱり人でしょう。
人口の集中したところのほうが人を集めやすいという発想。
たくさんあるけど、話題にならないだけ (スコア:0)
T/O
田舎は不便だから (スコア:0)
Re:田舎は不便だから (スコア:1)
都心では明日では無く当日に「即日配達」されますよね。
極上な土地では「アスクル」の社名自体が希薄ですよ・・・
Re:技術者の確保は (スコア:1, おもしろおかしい)
ネット通販で解決、というか
都心は立地に反して自宅警備員多いし
Re:ぜひ誘致を (スコア:2, 興味深い)
ちなみに避難区域と言われても普通の電子機器が動作するには
なんの問題もない程度の場所ですよ．
原子炉建屋のすぐとなりに設置とか言わなければ．
農業や子供の生活で問題とされる量なんて，
ほんのわずか計測される程度ですし
データセンタなんて建物の中にサーバを設置するんですから
本当になーんの問題もないんです
# 放射「脳」化している人には分からないかも知れませんが…
敷地に余裕を持って配置できますし，
本当にメリットはあると思うんだけど．
Re:ぜひ誘致を (スコア:1)
放射能に強いサーバやネットワーク機器の開発がネックだと思うよ。
Re:ぜひ誘致を (スコア:1)
放射線はたかだか計算機を誤動作させるだけですが。
放射能はヘタをすると、死んだ計算機を復活させ、巨大化させ、放射能をまき散らしながら東京目がけて一直線…なんて状態に陥りかねないので、そうならないための対策が必要なのです。
fjの教祖様
Re:ぜひ誘致を (スコア:1)
>東京目がけて一直線…なんて状態に陥りかねないので、そうならないための対策が必要なのです。
東京近辺にデータセンターを集中させておくと、そのモンスターの移動による被害を減殺することが出来る訳ですね。
Re:東京脳の真実 (スコア:1)
＞中国四国って何かあったっけ？
正しくはこう。
岡山：大都会
東京・大阪・名古屋：都会
・
・
それ以外 : 田舎
Re:東京脳の真実 (スコア:1)
あぁ、それ、違います。
大岡山：大都会
岡山：都会
です。間違えないように。
多くの人が間違えていますが、岡山市は真の県庁所在地から原住民並びに石原慎太郎の目を欺くためのフェイクですから。真の県庁所在地はもちろん、「大岡山」の方にあるんです。
fjの教祖様
Re:東京脳の真実 (スコア:1)