はじめに

廃校となった小学校の跡地を見て涙が出た。ピンネの山から吹き降ろす強烈な風が雪を低湿地に運び、えぐれた地面から吹き上げる。振り返ると北電砂川発電所と、東洋高圧の古い工場が見えた。

この街の特徴は何だったのだろう。

夕張や富良野のような観光地でもなければ、夕張や浦臼のようにメロンが有名な町でもない。わずかな稲作地はブランドや規模からして、隣の奈井江や深川に負けている。高速道路は通っているが、街を通り抜けるだけで市内にインターチェンジはない。

水と風と人が通り過ぎるまち、surachipt この街で新しい産業を興すことはできないのだろうか。

 

キーワード

雪冷データセンター、省電力データセンター、低環境負荷データセンター

 

リンク

勝手に Surachipt Data Stream を創ろう

砂川市役所公式 ウェブサイト　 Sunagawa City Hokkaido Official Web site
美唄市役所公式ウェブサイト    Bibai City Hokkaido Official Web site
奈井江町公式ウェブサイト    Naie Town Official Web site
空知工業団地公式ウェブサイト    Sorachi Industrial Park Official Web site
美唄自然エネルギー研究会 Bibai Nature Energie Research Association Eneken facebook

※ このサイトは「『勝手』に Surachipt Data Stream を創ろう」です。上記自治体、団体とは何の関係もありません。
※ できるだけ良質な情報を提供することを目指します。表現や内容に不正確な場合はご指摘いただけると幸いです。

高倉健と「幸せの黄色いハンカチ」、「ドライブインいしかり」で変わったこと

道民にとって高倉健は特別な俳優です。




東映の任侠映画に出演してきた高倉健にとっては、東映から独立して初めてやった「イイ人役」の映画が「幸せの黄色いハンカチ」だと思います。

後半、欣也と朱美に自分の過去を語り終えた勇さんが

「やっぱりオレ夕張行くわ」

と決心を固めるシーンを取ったのが、あの「ドライブインいしかり」の駐車場でした。目の前は三井東圧化学（現、北海道三井化学）の正門前。目の前は国道１２号線。多くの車が豊沼の交番前の坂を上り下りしています。

当時、豊沼の中学生だった私たちは昼休みに「おい、今タカクラケンがあそこの"ドライブイン石狩"でロケやってるぞ」程度にしか思っていなかったし、後でテレビ放映された時も「おぉ、映っているな」ぐらいしかかんがえませんでしたが、東圧正門前から坂を上って砂川市内へと流れるクルマを目の前に、一人の前科持ちのヤクザ暮らしの男が真正直に生きてみようと決心する瞬間のシーンだった訳です。

その後、高倉健は、暴力やバイオレンス、アクション映画にも出ましたが、基本的に「イイ人役」へと変わっていきます。

彼の変化の始まりは「幸せの黄色いハンカチ」であり、あの「オレ夕張へ行くわ」の台詞だったのかもしれません。そう考えると、あのわずか数十秒のシーンは、「映画俳優：高倉健」の一つの転換点だったのかな、と思います。

多くの感動を与えたあの映画と高倉健が水の様に流れて立ち寄り、そして去っていく。そんな物語が空知の小さな町で撮影されたのです。

今はあのロケ地「ドライブイン石狩」は産業、経済構造の変化によりコンビニエンスストアに代わりました。私たちも変わらなければならないのです。

機器の故障と稼働率、MTBF,MTTR,TBW（PTW）とは

ＭＴＢＦ

　MTBF(Mean Time Between Failure) は「平均故障間隔」の略です。「どれくらい故障しやすいか、壊れにくいか」を表す言葉です。機器の信頼性を表す指標です。

　例えば「平均MTBF10,000時間のハードディスク」と言えば、「平均」一万時間で故障するハードディスクである。あるいは一万時間は動作するはずである、という事です。

　仮にＭＴＢＦ一万時間と仮定した場合、１万台のＨＤＤがあると１時間に１台は壊れるという事になります。交換は結構忙しい作業ですね。

　中にはアタリの悪いディスクもあって５００時間もたたずに壊れるディスクがあれば、２万時間動作していても壊れなかったディスクもあります。５００時間と言えばわずかひと月弱ですから、ほぼ「初期不良」として扱われるでしょう。製造番号が近いものは全て「怪しい」ので交換すべきです。

　MTBF、一万時間と言えば、大体１年半くらいでしょうか。最近のハードディスクはMTBFは３～５万時間程度の様です。

　MTBFを超えて運用できていれば、ラッキーです。大抵はMTBFを超える辺りでHDDの換装やシステムの更新が必要になります。中には２０年全く壊れずに動き続けたという「猛者」を見たこともあります。

米グーグル社が自社で壊れたディスクの統計を取ってみたところ、ディスクのブランドやモデルと言った要素に関係なく「壊れるものは壊れる」し、壊れないでＭＴＢＦを超えて運用できているディスクにもブランドや型番は関係なかったという調査結果を発表しています。つまり壊れるか壊れないかは運次第ということでしょうか。

　故障しやすい機器としては、他に電源やマザーボードに搭載されたコンデンサなどがあります。コンデンサも、稼働時間に比例して壊れやすいパーツです。ほとんどの場合、どのコンデンサが壊れたかを簡単に目視で確認できないし、半田で交換という訳にも行かないので、マザーボードや電源ユニット丸ごと交換という事になります。

　という事で、普通のＰＣの寿命は５年が目安です。サーバーベンダーの中には７年保障を謳っているメーカーもありますが、これはあくまでもパーツの保持であり、故障することを前提で保障しているだけです。

　金融システムなどに使われる専用のＨＤＤを作るメーカーの工場で仕事をしたことがあります。ここのＨＤＤは「絶対壊れない事が前提で作られています、他所のメーカーは壊れる事を前提で設計されています」と品質担当者が胸を張って答えたことが印象的でした。例え壊れても「なぜ壊れたのか」まで徹底的に究明しているそうです。工場の中では数万台のＨＤＤが品質検査を受けていました。

　こういった精度の高い品質のいいパーツを使っている場合のＭＴＢＦは高いレベルになります。


ＭＴＴＲ

　ＭＴＴＲ(Mean Time To Repair/Recover) は「平均修理時間」という意味です。現実には「システムが動いていない時間」でＳＬＡ（サービスレベルの同意）の中で使われます。 ＭＴＴＲ４時間以内、という事は、４時間以内にサービスを再開できるという事になります。

　またＭＴＴＲは「修理のしやすさ」を表します。実際の「安物」ＰＣサーバーの場合、修理のためにいくつものネジを取り外したり、ケーブルの取り回しが複雑だったりします。

　よくＩＴ系の広告で「サーバーがたった３万９千円」などというのもありますが、私の様にハードウェアに詳しくないエンジニアでも、中を覗けば、いかにコストダウンした「安物のパーツ」が使われているか良くわかります。

　例えばパネルの取り付けがネジ止めで雑だったり、電源交換しようにも、何本ものケーブルを間違えなく差し替えたりする必要がありそうだ、というのはすぐ見抜けます。中程度以上のサーバーの場合、レバー一本ひねるだけでパーツ交換ができたり、空冷ファンが工夫されていたり、ハードウェアが故障した場合の状況がわかるようなＬＥＤが外部に付いていたりします。

　この様な安物の機材の場合、たいていは１年保障で追加でも３年保障までしか受け付けません。しかも３万９千円でも年間保守料金が４万円かかったりするわけです。


　この時間は実際にサービスが止まっていることになりますので、運用担当者はＭＴＴＲをどう短縮するかが腕の見せ所となります。

　結局は壊れたパーツを取り寄せて、交換して、動かすことができれば問題ありません。しかしそれではサービスが停止します。そこで大手の顧客やクラウド事業者では、予備の機材を常に確保しておきます。ＭＴＢＦの問題もあり、あるサービスを予備機に移し替えてサービスを止めないでＭＴＴＲを短縮します。壊れた機材は後でゆっくり修理して予備ストックするか廃棄するかです。

　一か所に数千台から数万台のサーバがあるデータセンターでは、一日に２、３台のＰＣサーバーが壊れることは特別なことではありません。何しろ分母が大きいのです。

　熟練した運用担当者は、機器が「壊れる予兆」という事に鼻が効いている必要があります。

　廃棄するサーバーには、多くのレアメタルや銅線、取扱い危険な金属類が含まれています。これらの電子部品の廃棄、再利用に必要な産業も、ＤＣ立地には必要かもしれません。


ＴＢＷ（ＰＢＷ）

　まだ余り注目されていませんが、ＴＢＷ(Tera Byte Write) とは、最近はやりのＳＳＤ（半導体フラッシュメモリディスク）の故障単位の指標として使われます。ＰＴＷ(Peta Byte Write) とも言います。

　フラッシュメモリは「書き換え回数」が寿命です。

　これは、半導体として、「書き換え」が負荷の重い作業で、半導体の寿命に大きな影響があるためです。

　デジカメや携帯電話、ノートＰＣでよく使われる半導体メモリです。例えば私のデジカメは４Ｇｂのメモリがあります。しかしこの４Ｇバイトを全て書き換えるのは年に一、二度です。ノートパソコンで使うＳＳＤにしても、一日に書き変える量は多くても数Ｇバイトです。

　一般的なＳＳＤ寿命のＴＢＷは７００―ＴＢＷから１―ＰＴＷ程度ですが、ノートＰＣやデジカメ程度の書き換えであれば、ほぼ無限です。しかし２４時間無停止のサーバーで使う場合、使い方によっては数週間から数か月で１ＰＴＷを超えてしまいます。

　ほとんどのＳＳＤディスクの場合１―ＰＴＷ善後が書き換え寿命の様です。これは一日１Ｔｂのデータの書き込みがあれば(１Ｔｂ×３６５日×３年)３年で確実に壊れる、という事です。

　という事もあり、ＳＳＤの記憶装置はメーカーの保障期間は最大３年、もしくは機種により１ＰＴＷ善後とするケースが多いようです。何しろまだ評価の定まっていないＳＳＤの寿命問題です。良い悪いも含めて、バックアップを正しく取って運用することが無難です。

　一般的に「書き換え量」が単位なので容量の大きなＳＳＤほどＴＰＷの値は大きくなります。１２８Ｇｂの場合５００ＴＰＷ、５１２ＧＢのＳＳＤの場合、１．３ＰＴＷとかです。

　読み出しの多いデータをＳＳＤに配置して、書き込み、書き換えが多いデータをＨＤＤに配置するのはエンジニアの腕の見せ所です。

　一番困るのは、ＳＳＤを二重化しても、予備のシステムが同じ量のデータを書き換えてしまうという事です。しかも寿命は、データ量で決まってしまう。つまりバックアップシステムも、ほぼ同じタイミングで壊れる可能性が高いということです。

　救いがあるとすると、ＳＳＤが壊れるには現在のＴＢＷを計算して、「そろそろ寿命だ」と予測できることです。ＨＤＤの場合、「突然死」ということがあるので、こちらの方が怖いかもしれません。

　ＨＤＤの場合は３年で壊れる場合もあれば、運が良ければ１０年動作する場合もあります。しかしＳＳＤは「利用頻度」によって必ず壊れるため、常に利用頻度をモニタする必要があります

　ＨＤＤの場合、故障はＭＴＢＦという時間単位で示され、ＳＳＤはデータ量です。

　まだＳＳＤは若い技術なので、情報の蓄積がありません。実際のＰＴＷがどれくらいなのか、まだ事例が少ないということです。

-複雑なシステム程壊れやすい-

さて、ここに９０％(0.9)の稼働率の製品と９０％の稼働率の製品とが組み合わさったとしましょう。
実際の稼働率は

0.9 × 0.9 = 0.81

となります。同じく 0.9（９０％）の稼働率の製品が３つ組み合わさると 0.7 (70%)程度まで稼働率が落ちます。複雑なシステムはそれだけ、壊れやすいということになります。またシステムを二重化するなど、複雑性を増やすと、それだけ故障の原因がわかりにくくＭＴＢＦにも影響します。

99.9% の稼働率というのは１０００時間に１時間の停止時間ということですから、約４０日に１時間停止するということです。これでは使い物にならないと言われそうですね。９９．９９％程度であれば、大体１年は無停止ということになります。

石狩川流域をシリコンバレー化する勝手なプロジェクト

データのバックアップ

　データのバックアップと言えば、２０年ほど前はＤＡＴテープ。２０００年頃からＬＴＯ（リニアテープオープン）と呼ばれる規格のテープがこの十数年主流です。

　テープバックアップの悪夢は、テープの中をスキャンしないと中に戻すべきデータがあるかどうかわからないという所です。１本のテープをスキャンするには数時間から丸一日かかる場合があります。その中に目的のデータがあればよし、なければ次のテープをスキャンする、という悪夢のような作業を繰り返して、やっと目的のテープのデータを見つけてリストアします。

　ですから、通常はバックアップソフトウェアと組み合わせ、どのテープにどのデータが入っているかを管理し、必要なテープがどのテープなのかをできるだけ短時間で探し出す仕組みになっています。

　そこで、バックアップのためのデータベースが障害を起こすと、これは困りものです。

　もっとも、テープにラベルが貼ってあっても、ソフトウェアはそのラベルを読むわけではないので、「×月×日」と書かれたテープがソフトウェアのデータベースのリストにあるかどうか、一つ一つ調べるという、これまた悪夢のような作業があります。

　テープバックアップ装置は、通常１本差しのものと、マガジンタイプのものがあります。実はこのマガジンタイプのものは、システム運用者にとって見たくない悪夢です。

　テープの厚さは×ｎｍという薄いビニールです。これが秒速数百回転のリムに巻き取られます。当然熱も出ます。高熱による巻き込み事故というのもあります。また、テープは接触媒体なので、読み取りヘッダを定期的にクリーニングしなければなりません。

　さらに、マガジンタイプの装置であれば、テープをマガジンから取り出して、装置にセットするためのロボットが付いています。

　いちど、とある国立の研究機関で見たことがあるのですが、４畳半ほどの広さの「部屋」にテープが何千本と並んでいる「装置」を見たことがあります。部屋丸ごとバックアップ装置なのですね。

　テープチェンジャは稼働部品が多い。壊れやすいのです。

　また、マガジン装置自体はどのラベルのテープが交換されたか、という情報を保持するため、いったんマガジンを交換すると、内部のロボットが

　「ギーガポン、ギーガポン」

　と内部のテープをスキャンします。この時間もオペレータにとっては悪夢です。蓋を開けて閉めただけでこの動作ですから、一日何度もコーヒータイムができてしまいます。

　一度だけ経験したことがありますが、２０本のテープをスキャンして、その中のわずか４本のテープからデータをリストアするまで３日かかったことがあります。

　ということでシステム全体の障害というのは運用管理者にとって、最大の見たことにしたくないものなのです。

　最近は、Ｄ２Ｄと呼ばれるディスク・ツー・ディスクのバックアップが主流です。これならば、いちいちテープをスキャンしたりしないため、リストアするためのデータに瞬時にアクセスできます。

　また、テープメディアは１本１万五千円ほどしますが、最近のＨＤＤの場合、倍の容量でもその半額で済みます。しかも、テープメディアの信頼性が置けるバックアップは精々数回だけ。２０回も使えばエラーが出始めます。

　しかし、まだテープ装置にはメリットがあります。

　それはオフライン保管できるということです。

　Ｄ２Ｄシステムの場合、オンラインでオペレーションのミスで瞬時にバックアップ内容が消去されますが、テープはオフラインで「耐火金庫に保管」という手段が取れるため、世代バックアップや何年もの間データを保管しておきたい場合などに有効です。ただ、サーバールームと同じ場所の耐火金庫であれば、火事で全部ダメになることもあるので、銀行の貸金庫や、「保管屋さん」と呼ばれる大金庫を持つ業者に預けるケースもよくあります。

　日時のバックアップはディスクへ、月次のバックアップはテープで、という運用をしている運用担当者もいます。

　不思議なもので、バックアップを丹念に管理しているお客様は、まず機材自体の故障という事故が起こりにくいようです。バックアップを粗雑にしている所では、よく機材が壊れて「御臨終」に立ち会うものです。

　それでも古いテープメディアは新しい装置で読み込みができない場合もあります。ちょうど、今の時代のフロッピーディスクの様なものです。ここにデータがあるよ、とＦＤを出されても、読むための装置がない。これでは困りますね。

「北海道石狩平野をシリコンバレーに」

Linux は無料？

　Linux は「オープンソースで無料」とメディアでは言われます。

　「タダ」という言葉に私たちは非常に弱い。

　しかし「タダより高いものはない」ともあるように、決してコストゼロではありません。

　「オープンソース」とはソースコード（ソフトウェアの詳細な設計書）が公開されているソフトウェアです。しかし、守るべき著作権があります。オープンソースの著作権には様々な種類があります。は、ソースコードを再利用した場合は、変更したソースコードも併せて公開しなければならないというルールがあるもの、あるいは著作権保持者を明記しなければならない、などのルールです。

　このルールがあるため、オープンソースにはウィルスを仕込んで配布するなどの事は事実上困難です。

--
　Linux はオープンソースですが、無料で使えるものと、「商用Linux」と呼ばれる有料のものとがあります。

　ソフトウェアには必ず「バグ」と呼ばれる不具合が付きものです。

　無料で利用できるものは、全て「自己責任」で利用できます。しかし、バグの対応も自己責任です。先日も SSL と呼ばれる暗号通信の機能にバグが見つかり、大騒動になりました。

　ソフトウェアの機能は単一のプログラムで完結していません。共通の機能を「ライブラリ」という形式で提供します。例えばあるプログラムに暗号化通信が必要であれば、そのプログラムはライブラリを利用すれば良いわけです。他の全てのプログラムはこの暗号通信用のライブラリを使えば、別なソフトウェアとして機能できます。

　これを「ソフトウェアの依存性」と言います。

　よくある話として、あるアプリケーションソフトウェアを動かそうとすると、この「依存性」の問題で動かないケースがあります。そこでライブラリを新しくすると、今度は別なプログラムが動作しないということがあります。これは日常茶飯事です。

　無料の Linux の利用者はこの問題を自分で解決しなければならないのです。

　一方、商用 Linux はこうした依存性の問題や不具合の対応を解決した状態で出荷され、それなりの費用を支払えば、見つかったバグにも、電話対応もしてくれるわけです。

--
　格安のレンタルサーバーなどを運用するホスティング事業者は、コストを下げるために無料の Linux を使います。しかし、自社運用なので、それなりの技術者が必要です。大抵の場合、彼らは Linux のシステムに精通していて、海外のメーリングリストなどのコミュニティにバグの報告や改善方法を投稿し、時には自ら解決できる程の技術力があります。

私の様な一般的な「何でも屋」の技術レベルではこの様な高度なことはできません。ですから、お客様に提案する場合は必ず商用 Linux でサポートを受けられる体制を提案します。ただし、自己責任でテストするような場合は、無料の Linux を使います。

--
なぜ Windows にはオープンソースのアプリケーションがないのでしょうか。それは Linux を始めとする多くの UNIX 系のシステムには「コンパイラ」という機能があるからです。コンパイラはソースコードに書かれた詳細な設計図をプログラムに翻訳するソフトウェアです。

コンパイラがあって、ソースコードがあれば、ソースコードを自由に変更してコンパイル（翻訳）して修正することができます。（技術があればの話ですが）

しかし Windows にコンパイラは付属しません。なぜならマイクロソフトは昔からコンパイラのようなＰＣ向けの開発ツールを販売していたからです。ですから Windows 用の開発ツールは有料です。しかも、マイクロソフト以外の企業もコンパイラを販売しています。

したがって Windows 向けのソフトウェアはソースコードを添付して配布するという事ができません。ソフトウェアを開発したい人々は、マイクロソフトからコンパイラなどの開発キットを購入して、プログラムを書いて、コンパイルからセットアッププログラムにまで仕上げて配布します。

ここに悪意がある開発者がいると、セットアッププログラムにコンピュータウィルスを仕込む事が出来ます。何しろソースコードは配布されていないのです。

だから「信頼できないプログラムは実行してはならない」といるルールが出来上がります。

最近、Windows 用の中国製の文字変換プログラムや、韓国製のビデオソフトにこのような「悪意」を感じさせる機能が組み込まれていることが判明して、大きな話題になりました。

一般的には、ソースコードが公開されているオープンソースにはこのような機能を組み込むことは困難でしょう。

北海道石狩川流域をシリコンバレーに変える勝手なプロジェクト

田中社長ありがとう

「石狩データセンター」裏話


風景がシリコンバレーに似ていること

本当、そう思います。

有難う田中社長。

シリコンバレーのあの茶けた山並みと、空知の緑あふれた山並みを見比べて、「シリコンバレーと似ている」という発言は大変力強さを感じました。


中部空知は、２番目の選択肢で、それでも十分です。ベスト１である必要はありません。ありませんが、第二のＢＣＰ地区として「シリコンバレー」を思い出させる風景であることは、とてもいいですね。

ちなみに、北海道にはゴキブリがほとんどいないことは有名ですが、獣害は多いので気を付けてください。一番いたずら者なのは「イタチ」の類です。金網を食い壊し、平気で建屋内に侵入します。ウチの鶏小屋もよくやられました。

もし、アドバイスができることがあるとするなら、

「データセンター犬」でも飼ってみたらいかがでしょうか。広大な敷地を一日２度散歩させる。室内作業がおおいオペレータさんのいい運動にもなるし、犬がアッチコッチで「主張」することで、イタチのような小動物は中々近づきたくなくなるでしょう。犬もアホではないので、「異常」な匂いには異様に反応してくれます。また、データセンターの通路の周回にも付き合ってもらいましょう。犬は短毛種がいいと思います。間違ってもレトリバーのような抜け毛が多い犬種は止めた方がいい。秋田犬とか、シェパード類が良いと思います。

ところで「日経コンピュータ 2013 10/31号 - 無防備すぎるサーバーの社内運用」の記事の中で各ＩＳＰのデータセンター所在地の一覧がありました。まず９０％以上の「データセンター」が首都圏に存在していることがよくわかります。当然、東アジアでも最大のＩＴ拠点の「一つ」（今はシンガポールかなぁ）である首都圏直下型災害が発生すれば、当然トラフィックとその影響はＡＰＡＣ地区全体に影響します。

BCP対策として、データセンターの地域分散は重要ですが、通信の分散も考えた方がよいでしょう。

動植物に関しては「多様性」を模索するのに、通信システムの「多様性」はどこに行ったのでしょう。

石狩川流域をシリコンバレーに勝手に Surachipt Datastream

“ローグクラウド”実装が急増 管理部門の新しい頭痛の種

“ローグクラウド”実装が急増 管理部門の新しい頭痛の種


Rogue というのは、"一匹狼",はぐれ者"から転じて、"ローグクラウド" というのは「組織が管理できないクラウドサービスを利用する」という風に考えてよいのでしょうか。

上の記事では DropBox や SkyDrive などの例を挙げています。他にも「組織外とのプロジェクトをスムーズに行うため」に情報部門が関与できないところでクラウドサービスを利用している例がたくさんあるということです。ｌ例えば、ＳＮＳの機能を利用して、「何気なく社外」で「社外の関係者」などのステークスホルダーを集めてプロジェクトの管理を行ったりするケースは増えていると思います。極端な例を言えば、橋下大阪府知事が Twitter を使って発言するのも Rouge Cloud の一種かもしれません。本来、議会制民主主義が前提であれば「議会での発言」がオフィシャルなものとなるはずなのですね。

しかし、閉鎖した中での業務遂行というのは閉鎖社会であり、革新性を生み出すことは出来ません。社会の中にこのような「はぐれ者」が存在し、「はぐれ者」が他の社会と接触することで、情報や文化、経済に変化が訪れるわけです。

「面倒を見きれない奴」が何かをやらかすと脅威にもなり、時には革新的なアイディアを作り出すのですが、ほとんどの場合は組織にとって「脅威」と感じる人が多いのではないのかなと思います。

現代の情報技術では、ネットワークに繋がったパソコンのみならず、スマートフォンやタブレットでも無線キーボードを繋いでしまえば、ほとんど重要な仕事をこなすことができます。これはシステム管理者の制御の範囲外です。

ほとんどの利用者は善良であり、決して「悪意ある」利用者ばかりではないのでしょうが、お上（システム管理側）からすると「厄介な掟破り」として映ってしまうわけです。掟破りである以上、善良なユーザであっても何らかの形で抜け穴となり、脆弱性の入り口となる場合もあるわけです。

結局、セキュリティ論議というのは、「パスワードは複雑に」とか「これやっちゃいけない」と言った運用ポリシーによる「根性論」が中心です。根性をシステムとして組み込むことが困難だという事です。「武」（システム）によるマツリゴトではなく併せて「文」による善政（柔軟な運用ポリシー）も組織のトップには求められるのです。

石狩川流域をクラウド化、勝手に北海道に石狩川流域にデータセンターを誘致するプロジェクト

ハリケーンSandyで見えた都市の脆弱性

人の不幸を笑うわけではありません。

NYC はじめ近くのニュージャージー州など、大混乱が続いているようです。

大型ハリケーン「Sandy」の影響で「Gizmodo」や「Buzzfeed」が停止に

何度か東京駅から新宿駅まで歩いたことがあるのですが、意外と近いものなのですね。しかしこの間を歩こうという都市市民はほとんどいない。

都市は精密なスイス製の腕時計のように全てがバランスが取れて精密に動くように結果的に出来上がっており、この精密機械のどこかに水が入り込んだだけでその機能は失われてしまいます。

変電所の故障により停電が発生し
Massive explosion at NY power plant


多くのデータセンターの電力が失われています。
Massive Flooding Damages Several NYC Data Centers

これは、NYCでのことではなく、首都圏でも同じシナリオが描けるわけですね。

ハリケーンで公共交通が破壊されたNY：ギャラリー



私が住んでいる街からは西東京市はすぐそこなのですが、電車で行くとなると非常に面倒な乗換えが沢山必要で１時間以上かかります。おそらく自転車でも同じ程度なのでしょうが、この距離感覚は、首都圏では「遠い」という感覚です。

都心部がNYCのように水没すると、まず、首都圏郊外へのデータセンターの「復旧」のための出勤は不可能になります。

東京一極集中という日本の「今のあり方」を真剣に考えてみたいものです。

ＳＬＡ(Service Level Agreement)とは

情報用語やデータセンターのサービス用語でＳＬＡ(Service Level Agreement)という言葉があります。

簡単に言うと「これだけの機能と性能(Service Level)を規定して、できない場合はたとえばその分値段を安くするなどの措置をとりますよ」という「合意(Agreement)」のことです。重要なのは「合意」であり「保障」ではない点です。

実際、さくらインターネット石狩データセンターでは、サービス開始時にありがちな初期不良でいくつかの有料サービスのうち無料試用期間を延ばすなどの良心的な処置を取っています。

「ADSL 12M ベストエフォート」などというサービスであれば「繋がれば良い」程度のサービスを保証しているわけです。一方３６５日１００Ｍｂｐｓ９９％保障というサービスレベルであれば、少なくとも「拠点」とデータセンター間との通信容量は９９Ｍｂｐｓのレベルを毎日保障しなくてはなりません。あるいは９９％の時間帯で通信速度を保障しなければならないということになります。

私は通信系は弱いのですが、サーバーの稼働時間９９％というのは１００時間のうち９９時間の稼動保障をするということになるわけですから大体５日に１時間くらいはダウンしても構わないということに（凄い甘い数字ですね）なります。製造業で９９％の稼働率であれば凄い数字だと言えますが、情報システムではひどく甘い数字です。

実際に９９．９％の稼動保障であれば、１年半に１時間程度のダウンは大目に見てくださいね、ということになります。この時間帯に機器を更新したり新しいシステムに切り替える作業などが許されます。実際には「障害」に対するサービスレベルの規定であり、機器やサービス機能の向上に伴うシステムダウンはまた別の問題です。大手のクラウド事業者であっても、「計画的な機器停止」というアナウンスは良くあることです。

当たり前ですがＳＬＡのレベルを上げるためには人的コスト、機器的なコストは上がります。例えば２４＊３６５日のＳＬを保障するのであれば、３交代制で人を貼り付ける必要がありますし、定期的なメンテナンスが必要な機器の二重化、冗長化が必要です。事業者側はそのためのコストを下げるために「量の論理」でコスト削減を考えなければなりません。

通信系でも１００Ｍのサービスを１Ｇのサービスに切り替えるという場合であれば、その間は通信が途切れるわけですから、これもＳＬの一部とは言いがたいのではないのかな、と思います。

多くの場合、事業者側にはＳＬＡが守れなければ「その分サービスしまっせ」という条項はあっても、サービスが途切れたことにより発生した顧客の直接的な「損害」は保障できない（しない）のが普通です。顧客が毎月１００万円のサービスを使って毎月１００億のビジネスをやっていて、サービスの障害によって１億の損害が出ても、事業者側としては毎月１００万円のサービスしか提供していませんから、その契約の中にビジネスの保障までは盛り込むのは無理というものです。そのような損害まで補償しろ、というのであれば、事業者ではなく、顧客は自前でサービスを構築すべきでしょう。

よくスペースシャトルで「シックスナイン」という言葉があります。９９．９９９９％という９が６つ並んだ数字を安全性として定義した言葉ですが、これも４０００日に一度は事故が起きるという「危険性」があるわけですね。スペースシャトルは３０年間の運用中に２度大きな事故を起したわけですが、その１３０回あまりのミッションで２度の事故なのか３０年あまりの運用機関における２度の事故と解釈するのかで大きな違いがあります。回数なのか時間なのか、品質なのかによってＳＬの定義は違うものになります。

また、障害の内容によっても詳細に規定されなければなりません。例えば生産や流通、決済に関する処理は営業中に確実に行われなければなりませんが、電子メールやグループウェア、定期的なバッチ処理の一部などは、ＳＬが多少落ちても大きな問題にならないケースもあります（もちろん放置すべき問題ではありません）

サービスレベルというのは、データセンターの事業者と顧客の間にあるだけではなく、企業の情報部門とエンドユーザ部門（経営側）にも規定している場合があります。このようなケースでは、サービスレベルはかなり下げています。例えば「営業時間、営業日は９９％の稼動を保障するが、営業時間では停止することもある」ということですね。実際に企業内部のシステム部門では２４＊３６５日のＳＬは保障できるだけの人的リソース、機器的リソースがないため、事前に計画された深夜や休日のメンテナンス、停止ということは頻繁に行われます。

また、組織内でのＳＬＡには「ペナルティ」という規定はほとんどない（あるところもあるかもしれませんが）ことが普通です。システム運用部門と利用者部門との間での「努力目標」として定義され、「実績主義」の中で評価されます。そういう意味ではペナルティがあるかもしれませんね。

実際に銀行のＡＴＭなどは深夜は稼動していません。深夜に「締めの処理」（バッチ処理）が必要だからです。バッチ処理をしながらも取引が継続できるようなシステムにするには莫大なシステムの再設計が必要となります。

そのようなケースも加味するとＳＬＡというのはさまざまなケースが考えられると言うことになります。

--
サービスのスタートアップにおいては、ＳＬ（サービスレベル）は甘い数字で提示すべきものだと思います。例えば、２４時間のうち、朝の９時から夜の９時までは９９％の稼動を保障するが夜９時から朝９時までは稼動を保障しないとかのＳＬから初めて、スタートアップの投資を低く抑えながらサービスを開始することもあります。今では大企業となった Google にしても最初はそのレベルで開始せざるを得なかったと推測するのは容易です。

まずは身の丈にあったＳＬから初めることです。


北海道にもデータセンターを誘致しようという勝手なプロジェクト

さくらインターネットには日本のクラウドを変える力があるはず。

日商エレ、北海道石狩市にデータセンターを開所～大阪、横浜に次ぐ3拠点目


よく、大手ゼネコンさんのまったく同じ部署の引越し手伝いましたね。「また引越しですか？」という感じです。たいていゼネコンさんって、新築のビルに引っ越すのですよ。よく聞くと、自社がオーナーさんに建てさせたビル。だけど立てたばっかりでは、誰も入居していないから、入居第一号として、自分が立てたオーナーさんのビルに入居します。

たいてい地下鉄の駅から遠かったり、妙に不便だったりするビルがこれらゼネコンさんがビルのオーナーさんたちに金出させて作ったビルに引っ越します。

ゼネコンさんも慣れたもので、荷物なんか開きません。ラベルを貼ったまま倉庫に荷物を放り込むだけ。どうせすぐ次に「建設直後」の建物に引っ越すからです。

ということで出来たばっかりのさくらインターネットの石狩データセンターの主要入居客として、大株主の双日系の日商エレクトロニクスが入居することになったようです。

　石狩湾は１９４０年の積丹沖地震で大災害を受けた（と思われる）土地。数十人の死者が出た災害の記録がなぜ道庁にも残っていないのか、それは当たり前なことで当時石狩にはほとんど誰も住んでいなかったからで何の被害もなかったからです。オロロン街道の北、苫前あたりではかなりの被害が出たそうです。

　戦時中の災害だったため、本格的な調査も何もありませんでした。だからさくらインターネットさんには同情します。何しろ１９７０年代の高度成長、重厚長大産業誘致の間違って作ってしまった工業団地の残骸をつかまされてしまったわけですね。何しろ泣く子も黙る石狩番屋の冬。松前藩の番人やアイヌの人々が冬は全部引き上げたという土地です。石狩湾からたっぷり塩分を含んだ潮風がビュービューと吹き荒れ、コンデンサや金属接合部を腐らせ。札幌市内から中央バスで６０分という至近距離（？）もちろんタクシーを使えば福沢諭吉を千歳空港で用意しておく必要があります。

さくらインターネットさんはいわゆる「色つき」のベンダー系ではなく、技術力もあるので私も長いこと使っています。

しかし、そう簡単に埋まらないラックを増資元に貸し出すというのは、なんとなく引越しばかりするゼネコンさんを思い出します。

この記事感じるものは「日本のクラウド」の現状です。クラウドが育たない政策、文化、法律、一部ＳＩ事業者に偏った公共システムの入札制度。企業のシステムに対する考え方など、さまざまな問題が透けて見えてきます。

新規事業のアイディアを実現するためには、日本の法律の縛りを逃れるため、海外に法人を作って海外のクラウドシステムを利用しようと誰もが考えてしまいます。

これでは、日本においてはクラウドの運用、構築技術、利用のアイディアなど、全てが流出する危機感を感じます。

まず、出来るところからクラウド化。まとまった地域でのデータセンターの構築、と言った課題を考えてみたいと思います。

今後も地域の先端としてぜひがんばってほしいところですが、石狩だけじゃないのよ、いい場所は。

石狩川流域をＩＴ産業振興しようという勝手なプロジェクト

最近注目されているＢＹＯＤって何だ？

BYOD (Bring Your Own Device)

当初、レストランに自分の好みのワインを持ち込みたいというお客さんがいました。 Bring Your Own の始まりです。この発想はオフィスでも同様で BYO(Drink) つまり、職場の外で買ったスターバックスのカフェラテや、自動販売機にはない健康ドリンクなどを自宅から持ち込むことを BYOD と言いました。

近年、スマートフォンやタブレットＰＣがヒットしているため、 BYOD の D は Device を意味するようになります。

ＢＹＯＤの難しさは

- 自社のシステムの「操作や参照」はできても、コピーを持たせない工夫が必要なこと
- ディザリング機能（自らがルータになる無線端末）のアクセス制御ができないこと
　（お父さんが自宅で仕事をしていたら子供のＰＳＰもつながっていた、なんてこともありえます）
- 端末をどう認識し、アクセス制限するか

という課題があります。


石狩川流域をＩＴ拠点に！　勝手なプロジェクト

北海道の第三セクターHARPがネットワンと公立学校校務支援システムを構築

北海道の各公立学校が共同利用する校務支援システム、ネットワンが構築

こういった自治体クラウドも今後の流れになるでしょう。

ところで、自治体クラウドは、都会の住民のためにあるのでしょうか、それとも地方都市にメリットがあるのでしょうか。雇用の面で、システム自体が北海道にあるなら問題ないのでしょうが、こういったシステムが大都会の企業に管理運用されているようでは、決して地方が豊かになるわけではありません。

いよいよ石狩データセンターがローンチ ー 高橋道知事も開所式

さくらインターネット、石狩DCを開所 - 北海道知事、石狩市長も列席

いよいよ、北海道庁期待のさくらの「石狩データセンター」がローンチしました。石狩川流域のＩＴ事業化促進の基点として、がんばってください。

石狩ＤＣの開所により、人的リソースの集積、北海道と極東圏との回線設備の強化が期待できます。

これは１企業の問題ではなく、北海道、そして地球温暖化までを含める大きなスケールにおける第一歩です。さくらインターネットさんだけではなく、もっと多くのＩＴ企業が、巨大なエネルギー消費産業と化したコンピュータビジネス拠点として、石狩川流域に注目してくれることを期待します。

北海道石狩川流域にデータセンターを誘致する勝手なプロジェクト

北海道総合通信網（北電子会社）がDRアプライアンス Novell Platespin Forge を用いたDR拠点構築に協力

クニエ、ノベルのDR/バックアップアプライアンス「PlateSpin Forge」を用いたソリューションを提供

Novell Platespin Forge は DR(惨事復旧)のためのハードウェアとソフトウェアを組み合わせたアプライアンスシステムです。箱から開けて１０分で惨事復旧のためのシステムが構築でき、しかも複雑な設定や操作は不要な優れたシステムです。

以前から PlateSpin Forge を使ったDR、BCP（業務継続計画）の拠点として、北海道が選んでみてはどうだろうと考えていました。

この記事では、クニエがフロントでセールス。Novell と Dell がサポート、実際の運用拠点は北海道総合通信網が行うようです。当初は小規模でしょうが、将来大規模なDR拠点として、奈井江、砂川に発電所があり、周囲の豊富な北電水力発電網を使ったDR拠点を石狩川流域に構築して欲しいとことです。


-Key word-

北海道　データセンター　北電、　Novell Platespin Forge 立地条件

勝手に石狩川流域にデータセンターを誘致するプロジェクト Surachipt Datastream<>/a

NTTコムウェアのデータセンターが北海道にBCP拠点

NTTコムウェアのデータセンターが長野と北海道に

具体的に「どの街」という記述はセキュリティ上書かれていませんが、長野と北海道というのは明らかに「寒冷地」狙いでしょう。PUE1.3目標というのはもちろん自然空調を主力としています。


勝手に北海道石狩川流域をシリコンバレー化するプロジェクト

NECが北海道にデータセンターを新設

NEC、札幌にデータセンターを新設　クラウドサービス提供環境を強化

NEC報道資料
標高、海岸線からの距離、地盤などを考慮しています。

札幌のどこなのかはもちろん公表できないのでしょうが、NECがデータセンターを札幌市内に新設するようです。新設するとなると、やはり札幌市郊外ということになるのでしょうか、おそらく東部、新札幌付近かな？

過去のデータセンターは単なる「コンピュータの置き場」だったわけですが、現在では巨大な施設産業となっています。ディーゼルエンジンの発電機、巨大な冷房施設。従来の静かな住宅地やビジネス街にひっそりと存在する都市型の「データセンター」とは性格が異なります。

評価したいのは、このように北海道、石狩川流域にデータセンターが分散して新設されることにより、北海道のIT産業、通信回線、人材が移動することによる、「石狩平野シリコンバレー」化です。

ただし、札幌市内であるということは「都市型データセンター」の性格は否めません。ヒートアイランド問題、大都市固有の交通障害、都市全体のシャットダウンに対する障害性があるのかどうか。この立地を選んだ理由にどこかメリットがあるのか、とても興味がありますね。


- Key Word -
北海道　データセンター　クラウド　立地条件　石狩　石狩平野　石狩川　雪熱冷房

勝手に石狩平野をシリコンバレーにするプロジェクト