基本技術
2017年10月13日
データセンター、クラウドサービス事業者の階層化
データセンター、クラウドサービス事業者の階層化
ファシリティ提供者
データセンターのファシリティ提供事業者は、データセンターの用地、建物、電力会社が提供する電源、予備電源、主なバックボーン回線を提供します。もちろん、自らIT機器を配置して、IT機器をサービスとして、時間貸やトラフィック量、CPU装置の利用量による課金も行います。まぁ、パンツとパジャマ、歯ブラシから、エレベータと玄関ホール、寝床まで提供するホテルの様なものです。データセンター専業の運用事業者や、巨大なインターネットサービス、例えば Facebook や Google なんかはこうしたデータセンターに投資します。勿論ピンキリがあって、都心のランドマークホテルから、地方の巨大なリゾートホテル、民宿程度の規模まで様々な企業がやるわけです。大手のSIベンダーやISP、通信事業者なんかも、こうしたファシリティに投資しています。中には、大手企業が「社員保養所」の様に、自ら土地建物、IT機器から通信設備まで、自社利用オンリーで運用するケースもあります。しかし、巨大なファシリティの利用率が自社だけで満たされない場合、余剰した設備をデータセンターとして「部屋貸し」することもあります。
IT機器のみの装置貸し
当然、巨額の費用をかけてファシリティを作ってもすぐに満室になるわけがないので、中小のデータセンター事業者は、こうした土地、建物を借りて、サーバールームを作り、IT機器を設置します。
よく、都心のホテル＆オフィスのビルディングの様に、２９階まではオフィスで３０階から４０階までホテル、４２、４３階と地下街はショッピング＆レストランのようなものですね。ビルと土地の所有者は「✖✖金融不動産」なんかが所有しています。立地条件が都心の様に利便性だけ考えると非常に高価な値付けができるデータセンターです。都心型のデータセンターの主な事業形態です。「✖✖インターネットサービス」なんていう感じの企業が主に借りて、ホテルとして経営して、パンツとパジャマ、部屋とベッドを提供します。エントランスやエレベーター、電源、通信インフラはファシリティ事業者が提供します。もっともファシリティ事業者の用意した回線容量が足りない場合は、部屋借りしている事業者が自前でエレベータ、ならぬケーブルを引いてくる事もあります。
自前の設備を持たない事業者、利用者
言わば「旅行代理店」や「結婚式場企画会社」のような事業者です。機器から電源、IT設備の全てはファシリティやデータセンター事業者から借りて、中のソフトウェアサービスだけ、自社で運用する、クラウドサービス専門の事業者です。ホテルの部屋まではファシリティ事業者や、データセンター事業者が提供し、内装レベルからホテルの備品程度のサービスまで差はありますが自前で提供する、という業者ですね。「隣の部屋」とはチト違うのよ、と言った「差別性」を持たせる事で、チト違うサービスをクラウドとして提供するわけです。多くの零細なクラウドサービス提供者のスタートアップ企業は、こうした「部屋借り」をします。もっとも、部屋にどういったIT設備を持つかはそれぞれの事業者で違ったりします。また、多くの顧客企業が「データセンターに機器を置いてユーザに提供する」形態のサービスもこの中に含まれます。
Google の様なサービスもスタートアップの時は自前のガレージに機器を置き、次にデータセンターの部屋貸りをして、次に自社のファシリティを作った方が安いし、余剰したリソースを逆に他人に貸し出すという具合にエスカレートして行きます。Amazon のクラウドサービスも書籍の小売りを始めたころのスタートアップは小さく、そのうちに貸し部屋に移り、そのうちに自社ファシリティを持ち、今では言わば 「Amazon 書店の空きリソース」を他人に貸し出したようなものです。Google も初期では、こうしたデータセンターを借りて運営させていましたが、自社でデータセンターを持った方が安価であるため、自社のファシリティを使い、かつて隣人だった、中小事業者にファシリティを貸し出すまでになっています。
石狩川流域をシリコンバレー化する勝手なプロジェクト
ファシリティ提供者
データセンターのファシリティ提供事業者は、データセンターの用地、建物、電力会社が提供する電源、予備電源、主なバックボーン回線を提供します。もちろん、自らIT機器を配置して、IT機器をサービスとして、時間貸やトラフィック量、CPU装置の利用量による課金も行います。まぁ、パンツとパジャマ、歯ブラシから、エレベータと玄関ホール、寝床まで提供するホテルの様なものです。データセンター専業の運用事業者や、巨大なインターネットサービス、例えば Facebook や Google なんかはこうしたデータセンターに投資します。勿論ピンキリがあって、都心のランドマークホテルから、地方の巨大なリゾートホテル、民宿程度の規模まで様々な企業がやるわけです。大手のSIベンダーやISP、通信事業者なんかも、こうしたファシリティに投資しています。中には、大手企業が「社員保養所」の様に、自ら土地建物、IT機器から通信設備まで、自社利用オンリーで運用するケースもあります。しかし、巨大なファシリティの利用率が自社だけで満たされない場合、余剰した設備をデータセンターとして「部屋貸し」することもあります。
IT機器のみの装置貸し
当然、巨額の費用をかけてファシリティを作ってもすぐに満室になるわけがないので、中小のデータセンター事業者は、こうした土地、建物を借りて、サーバールームを作り、IT機器を設置します。
よく、都心のホテル＆オフィスのビルディングの様に、２９階まではオフィスで３０階から４０階までホテル、４２、４３階と地下街はショッピング＆レストランのようなものですね。ビルと土地の所有者は「✖✖金融不動産」なんかが所有しています。立地条件が都心の様に利便性だけ考えると非常に高価な値付けができるデータセンターです。都心型のデータセンターの主な事業形態です。「✖✖インターネットサービス」なんていう感じの企業が主に借りて、ホテルとして経営して、パンツとパジャマ、部屋とベッドを提供します。エントランスやエレベーター、電源、通信インフラはファシリティ事業者が提供します。もっともファシリティ事業者の用意した回線容量が足りない場合は、部屋借りしている事業者が自前でエレベータ、ならぬケーブルを引いてくる事もあります。
自前の設備を持たない事業者、利用者
言わば「旅行代理店」や「結婚式場企画会社」のような事業者です。機器から電源、IT設備の全てはファシリティやデータセンター事業者から借りて、中のソフトウェアサービスだけ、自社で運用する、クラウドサービス専門の事業者です。ホテルの部屋まではファシリティ事業者や、データセンター事業者が提供し、内装レベルからホテルの備品程度のサービスまで差はありますが自前で提供する、という業者ですね。「隣の部屋」とはチト違うのよ、と言った「差別性」を持たせる事で、チト違うサービスをクラウドとして提供するわけです。多くの零細なクラウドサービス提供者のスタートアップ企業は、こうした「部屋借り」をします。もっとも、部屋にどういったIT設備を持つかはそれぞれの事業者で違ったりします。また、多くの顧客企業が「データセンターに機器を置いてユーザに提供する」形態のサービスもこの中に含まれます。
Google の様なサービスもスタートアップの時は自前のガレージに機器を置き、次にデータセンターの部屋貸りをして、次に自社のファシリティを作った方が安いし、余剰したリソースを逆に他人に貸し出すという具合にエスカレートして行きます。Amazon のクラウドサービスも書籍の小売りを始めたころのスタートアップは小さく、そのうちに貸し部屋に移り、そのうちに自社ファシリティを持ち、今では言わば 「Amazon 書店の空きリソース」を他人に貸し出したようなものです。Google も初期では、こうしたデータセンターを借りて運営させていましたが、自社でデータセンターを持った方が安価であるため、自社のファシリティを使い、かつて隣人だった、中小事業者にファシリティを貸し出すまでになっています。
石狩川流域をシリコンバレー化する勝手なプロジェクト
islandcenter at 17:42｜Permalink│Comments(0)
2015年05月18日
都市型ＤＣ、郊外型ＤＣ、地方型ＤＣ
都市型ＤＣ、郊外型ＤＣ、地方型ＤＣ
どういう違いがあるのでしょうか。
都市型ＤＣ
交通の便がよく、都心の高層ビル内にあり、駅から数分、セキュリティが高く、非常に高価。建物自体は事業者が所有しているのではなく、××不動産ビルなんて所の２０階から２９階までＤＣとしている、などというケースが多い。下手をすると、地下鉄の改札からノーチェックでＤＣのフロアまでは入り込めるケースもあるが、まぁそう言う所はまれ。ほとんど受付を通さないとエレベータも止まらない。
あまりに単価が高い事と、ＤＣとして設計された建物ではないケースでは、想定外の重量で床が抜けそうなので、実際のスペース効率はひどく悪く、「選ばれた客」以外は断られる事もある。何しろフロアの半分は空いているのだが、機器の重量に耐えられないのだ。当然単価に跳ね返ってくる。 環境負荷なんて考えないからＰＵＥは２．０以上ある事も当たり前で、そもそも機器が半分も入っていない部屋をガンガン冷やすため、凄いエネルギーを消費する。
しかし、事業者自身がＤＣとして設計した建物も多い。ＤＣ以外の利用目的がないため、単価はやっぱり非常に高い。ちょっと外れた湾岸地区なら倉庫から改造された建物もある。
ニーズは高いのだが、そもそも希少価値があるので、お値段も高い。
事業者のエンジニアの専門性もプライドも高い。
事業者の自社ビルじゃない場合は、当然「ＤＣの引っ越し」という大事業があるわけです。容易ではないでしょうね。
郊外型ＤＣ
交通の便は一般的に悪い。都心のターミナル駅から電車に３回くらい乗り換えて１時間半、多くは郊外の住宅地で駅からバスで１０分、徒歩５分のロケーション。大雨が降ったら行きたくない。数階建ての低層ビルで、事業者がビルを所有しているケースが多い。あるいは、倉庫会社などが、空き倉庫を使ってＤＣに転用しているケースがある。
エンジニアのレベルは一般的に高くはない。ＤＣ専門業者ならまだしも、大手のＳＩ事業者がやっている場合は「メンタル系」のやっちゃった経験者や、吸収合併した顧客のシステム子会社社員に、顧客の依頼で出向させて遠距離通勤を強いて「リストラ部屋」代わりに勤務させているケースも多く、優秀なエンジニアはほとんど外注の派遣社員や、常駐している業務提携先のエンジニアが多く、正社員のモチベーションはメチャクチャ低い所もある。
そもそも業界の流行を後追いして、自社の技術力ではなく、下請けの他人のフンドシを借りて仕事をするＳＩ事業者がやっている事は、レベルが低く、オーバースペックな設備を顧客に売るのが商売なので、これはこれで止むを得ないのかもしれない。
設備は思い切って設計できるため、免振床から生体認証、金属探知機、双発のディーゼル発電機など、事業者が思いっきりジマンできる面白いギミックが沢山詰め込む事ができる。何しろ、ビルの中で一番怪しい事をしそうな入館者は、センターの運営事業者自身の従業員だからである。
事業者は儲かっていないが、建設会社や設備関連の業者は笑いが止まらない。もっとも、顧客に買い取った大手さんの「いい顧客」を抱えているし、そういう顧客はシステム部門の専門家を丸ごとを売却してしまったため、価格を正当に評価できる人が居ないから「そんなもんか」程度に気軽にお金を落としてくれる。
首都圏から近いので、こういうシカケは年に一度くらいは顔を出す顧客受けには良いだろう。
サービスはそこそこ、単価もそこそこ。質は設備以外は期待しない方がいい。元々都市のヒートアイランド化と、東京湾から離れた内陸にあるため、ＰＵＥは恐ろしく高い。当然電源コストも高いので、決して安いとは言えない。元々都心型ＤＣの受け皿なので、それなりに稼働率は高い。お値段も、それなりの設備を見ればわかる通り、決して安くはない。
地方型ＤＣ
本来ホスティングの為に設計されたところが多く、ハウジング向けではない。それでも、ＢＣＰ拠点としてバックアップ用途に検討される事が多い。単価は安いが、年に一度もいくかどうかなので、存在すら忘れてしまう事もある。ハウジングするなら自己責任のリモート管理は必須。でもハウジングは止めた方がいい。多くの場合、非常に低い電力消費で動かすため、ＰＵＥは1.1前後が多く、そのレベルを目標としている。
エンジニアの専門性は高いが、ある意味では「専門バカ」に陥りやすい。どうも地方で仕事をしていると、専門性は高いが、世俗にいい意味でも悪い意味でも染まっていない。
質は高いが、ハウジングで利用するのは疑問。やっぱり「サービス」としてメニューから選択する方が正解。サービスとして見た場合、単価は馬鹿みたいに安い。IaaS や SaaS のクラウドサービスとして利用するのは正しい選択。
ホワイトデータセンター構想
どういう違いがあるのでしょうか。
都市型ＤＣ
交通の便がよく、都心の高層ビル内にあり、駅から数分、セキュリティが高く、非常に高価。建物自体は事業者が所有しているのではなく、××不動産ビルなんて所の２０階から２９階までＤＣとしている、などというケースが多い。下手をすると、地下鉄の改札からノーチェックでＤＣのフロアまでは入り込めるケースもあるが、まぁそう言う所はまれ。ほとんど受付を通さないとエレベータも止まらない。
あまりに単価が高い事と、ＤＣとして設計された建物ではないケースでは、想定外の重量で床が抜けそうなので、実際のスペース効率はひどく悪く、「選ばれた客」以外は断られる事もある。何しろフロアの半分は空いているのだが、機器の重量に耐えられないのだ。当然単価に跳ね返ってくる。 環境負荷なんて考えないからＰＵＥは２．０以上ある事も当たり前で、そもそも機器が半分も入っていない部屋をガンガン冷やすため、凄いエネルギーを消費する。
しかし、事業者自身がＤＣとして設計した建物も多い。ＤＣ以外の利用目的がないため、単価はやっぱり非常に高い。ちょっと外れた湾岸地区なら倉庫から改造された建物もある。
ニーズは高いのだが、そもそも希少価値があるので、お値段も高い。
事業者のエンジニアの専門性もプライドも高い。
事業者の自社ビルじゃない場合は、当然「ＤＣの引っ越し」という大事業があるわけです。容易ではないでしょうね。
郊外型ＤＣ
交通の便は一般的に悪い。都心のターミナル駅から電車に３回くらい乗り換えて１時間半、多くは郊外の住宅地で駅からバスで１０分、徒歩５分のロケーション。大雨が降ったら行きたくない。数階建ての低層ビルで、事業者がビルを所有しているケースが多い。あるいは、倉庫会社などが、空き倉庫を使ってＤＣに転用しているケースがある。
エンジニアのレベルは一般的に高くはない。ＤＣ専門業者ならまだしも、大手のＳＩ事業者がやっている場合は「メンタル系」のやっちゃった経験者や、吸収合併した顧客のシステム子会社社員に、顧客の依頼で出向させて遠距離通勤を強いて「リストラ部屋」代わりに勤務させているケースも多く、優秀なエンジニアはほとんど外注の派遣社員や、常駐している業務提携先のエンジニアが多く、正社員のモチベーションはメチャクチャ低い所もある。
そもそも業界の流行を後追いして、自社の技術力ではなく、下請けの他人のフンドシを借りて仕事をするＳＩ事業者がやっている事は、レベルが低く、オーバースペックな設備を顧客に売るのが商売なので、これはこれで止むを得ないのかもしれない。
設備は思い切って設計できるため、免振床から生体認証、金属探知機、双発のディーゼル発電機など、事業者が思いっきりジマンできる面白いギミックが沢山詰め込む事ができる。何しろ、ビルの中で一番怪しい事をしそうな入館者は、センターの運営事業者自身の従業員だからである。
事業者は儲かっていないが、建設会社や設備関連の業者は笑いが止まらない。もっとも、顧客に買い取った大手さんの「いい顧客」を抱えているし、そういう顧客はシステム部門の専門家を丸ごとを売却してしまったため、価格を正当に評価できる人が居ないから「そんなもんか」程度に気軽にお金を落としてくれる。
首都圏から近いので、こういうシカケは年に一度くらいは顔を出す顧客受けには良いだろう。
サービスはそこそこ、単価もそこそこ。質は設備以外は期待しない方がいい。元々都市のヒートアイランド化と、東京湾から離れた内陸にあるため、ＰＵＥは恐ろしく高い。当然電源コストも高いので、決して安いとは言えない。元々都心型ＤＣの受け皿なので、それなりに稼働率は高い。お値段も、それなりの設備を見ればわかる通り、決して安くはない。
地方型ＤＣ
本来ホスティングの為に設計されたところが多く、ハウジング向けではない。それでも、ＢＣＰ拠点としてバックアップ用途に検討される事が多い。単価は安いが、年に一度もいくかどうかなので、存在すら忘れてしまう事もある。ハウジングするなら自己責任のリモート管理は必須。でもハウジングは止めた方がいい。多くの場合、非常に低い電力消費で動かすため、ＰＵＥは1.1前後が多く、そのレベルを目標としている。
エンジニアの専門性は高いが、ある意味では「専門バカ」に陥りやすい。どうも地方で仕事をしていると、専門性は高いが、世俗にいい意味でも悪い意味でも染まっていない。
質は高いが、ハウジングで利用するのは疑問。やっぱり「サービス」としてメニューから選択する方が正解。サービスとして見た場合、単価は馬鹿みたいに安い。IaaS や SaaS のクラウドサービスとして利用するのは正しい選択。
ホワイトデータセンター構想
2014年11月27日
PUEに代わる、データセンターの省エネ評価指標 DPPEとは
DPPEとは Datacenter Performance Per Energy の略でグリーンIT推進協議会が推進する、日本発のデータセンター効率の指標です。
http://home.jeita.or.jp/greenit-pc/topics/release/100316_j.html
http://home.jeita.or.jp/greenit-pc/topics/release/pdf/dppe_j_20120824.pdf
DPPEは次の４つの指標で表されます。
ITEU: IT Equipment Utilization - IT機器の運用による最大効率化
ITEE : IT Equipment Energy Efficiency - IT機器の消費電力に対する効率
PUE: Power Usage Effectiveness - IT機器以外の付帯設備の効率
GEC: Green Energy Coefficient - グリーンエネルギーの効率的な利用
従来はPUEのみで、データセンターの効率を指数化していました。
DPPE は、これに加え、データセンターで使う機器の効率 ITEU（IT機器を最大パワーで動かせるか）、IT機器そのもののエネルギー性能比 - ITEE(同じ性能でも、どちらがエネルギー効率が高いIT機器か)、おなじみのPUE（付帯設備、特に冷房の効率化）、そして自然エネルギー効率GEC（どれだけ自然エネルギーを効率的に使うか）
という４つの指標を組み合わせて、データセンターの効率化を考えようというものです。
ITEU は、どれだけ、機材の性能を引き出すかがポイントとなります。これは、広い意味でソフトウェア的な視点です。運用（ソフトウェア）面で、どれだけ機材の性能を使いきるかがポイントです。アイドリングして無駄な電力を使わないで、負荷の高い機材とのロードバランスを取るためには高度なソフトウェア的な視点でのアプローチが必要です。
ITTE はハードウェア的な視点です。同じ性能のハードウェアでも、消費電力が少ない方を選択することは重要な事です。
PUE は皆さんご存知の通り、総消費電力における、付帯設備（冷房、照明）の消費電力の割合いを表します。
GECは、同じ敷地内でどれだけ、自然エネルギーを使っているのか、の指標です。
--
ただし私は幾つか重要な視点が欠けていると思います。まず、GECが「光、風」の自然エネルギーをどれだけ使っているか、という視点は視野が狭いと思います。これは、グリーンIT推進協議会が、太陽光パネルや風力発電と言ったモノを作る企業、団体が設立した事。これにより、自然エネルギーをどう普及させようかと言った狭い視点しか生まれません。
また、GECが、「敷地内」に限定されたことで、データセンターの立地条件である、自然エネルギーの供給源を「地域」として定義できない事です。データセンターの立地条件が必ずしも「風圧が高く自然冷却ができる沿海部」とか、日照率７０％以上の広い敷地であるとか、極論を言えば、水力発電所を併設するとかしなければ、高いGECは達成できません。
また、ITEE は、IT機器の性能に大きく関わります。当然新しいIT機器であれば、価格、使用電力量に対する性能比は大きく異なります。つまり「いつも最新の設備を使えばいい」という事になります。原発廃炉問題も含めると、原子力発電のコストは以外と高いと言われます。同じことがIT機器にも言えます。IT機器の廃棄コストと環境負荷の面でも指標が必要ではないでしょうか。これもグリーンIT推進協議会が最新のIT機器の調達を進めたいIT関連企業が作り出した指標の裏面です。
ITEU は運用上の問題です。当然ホスティングを行う事業者と、顧客の機器をハウジングする事業者との間では大きな運用の違いがあります。
限定された敷地というわがままがメーカーのわがままなら、周囲の地域というわがままは地域のわがままです。地域のわがままを考えると DEPP はそのままでは受け入れることはできないでしょう。それが、私たち「地域」の考えです。
PUEのみで語られるデータセンターの効率評価に対して、DPEEも「一つの指標」です。それぞれのデータセンターの運用目標の指針としての試みです。いずれにせよ、PUEのみで語られていた、データセンターの運用効率に代わる業界団体による、標準的な「データセンターの性能」を表す指標としては評価できるでしょう。
http://home.jeita.or.jp/greenit-pc/topics/release/100316_j.html
http://home.jeita.or.jp/greenit-pc/topics/release/pdf/dppe_j_20120824.pdf
DPPEは次の４つの指標で表されます。
ITEU: IT Equipment Utilization - IT機器の運用による最大効率化
ITEE : IT Equipment Energy Efficiency - IT機器の消費電力に対する効率
PUE: Power Usage Effectiveness - IT機器以外の付帯設備の効率
GEC: Green Energy Coefficient - グリーンエネルギーの効率的な利用
従来はPUEのみで、データセンターの効率を指数化していました。
DPPE は、これに加え、データセンターで使う機器の効率 ITEU（IT機器を最大パワーで動かせるか）、IT機器そのもののエネルギー性能比 - ITEE(同じ性能でも、どちらがエネルギー効率が高いIT機器か)、おなじみのPUE（付帯設備、特に冷房の効率化）、そして自然エネルギー効率GEC（どれだけ自然エネルギーを効率的に使うか）
という４つの指標を組み合わせて、データセンターの効率化を考えようというものです。
ITEU は、どれだけ、機材の性能を引き出すかがポイントとなります。これは、広い意味でソフトウェア的な視点です。運用（ソフトウェア）面で、どれだけ機材の性能を使いきるかがポイントです。アイドリングして無駄な電力を使わないで、負荷の高い機材とのロードバランスを取るためには高度なソフトウェア的な視点でのアプローチが必要です。
ITTE はハードウェア的な視点です。同じ性能のハードウェアでも、消費電力が少ない方を選択することは重要な事です。
PUE は皆さんご存知の通り、総消費電力における、付帯設備（冷房、照明）の消費電力の割合いを表します。
GECは、同じ敷地内でどれだけ、自然エネルギーを使っているのか、の指標です。
--
ただし私は幾つか重要な視点が欠けていると思います。まず、GECが「光、風」の自然エネルギーをどれだけ使っているか、という視点は視野が狭いと思います。これは、グリーンIT推進協議会が、太陽光パネルや風力発電と言ったモノを作る企業、団体が設立した事。これにより、自然エネルギーをどう普及させようかと言った狭い視点しか生まれません。
また、GECが、「敷地内」に限定されたことで、データセンターの立地条件である、自然エネルギーの供給源を「地域」として定義できない事です。データセンターの立地条件が必ずしも「風圧が高く自然冷却ができる沿海部」とか、日照率７０％以上の広い敷地であるとか、極論を言えば、水力発電所を併設するとかしなければ、高いGECは達成できません。
また、ITEE は、IT機器の性能に大きく関わります。当然新しいIT機器であれば、価格、使用電力量に対する性能比は大きく異なります。つまり「いつも最新の設備を使えばいい」という事になります。原発廃炉問題も含めると、原子力発電のコストは以外と高いと言われます。同じことがIT機器にも言えます。IT機器の廃棄コストと環境負荷の面でも指標が必要ではないでしょうか。これもグリーンIT推進協議会が最新のIT機器の調達を進めたいIT関連企業が作り出した指標の裏面です。
ITEU は運用上の問題です。当然ホスティングを行う事業者と、顧客の機器をハウジングする事業者との間では大きな運用の違いがあります。
限定された敷地というわがままがメーカーのわがままなら、周囲の地域というわがままは地域のわがままです。地域のわがままを考えると DEPP はそのままでは受け入れることはできないでしょう。それが、私たち「地域」の考えです。
PUEのみで語られるデータセンターの効率評価に対して、DPEEも「一つの指標」です。それぞれのデータセンターの運用目標の指針としての試みです。いずれにせよ、PUEのみで語られていた、データセンターの運用効率に代わる業界団体による、標準的な「データセンターの性能」を表す指標としては評価できるでしょう。
2014年07月04日
機器の故障と稼働率、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% の稼働率というのは１０００時間に１時間の停止時間ということですから、約４０日に１時間停止するということです。これでは使い物にならないと言われそうですね。９９．９９％程度であれば、大体１年は無停止ということになります。
石狩川流域をシリコンバレー化する勝手なプロジェクト
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% の稼働率というのは１０００時間に１時間の停止時間ということですから、約４０日に１時間停止するということです。これでは使い物にならないと言われそうですね。９９．９９％程度であれば、大体１年は無停止ということになります。
石狩川流域をシリコンバレー化する勝手なプロジェクト
2014年07月03日
データのバックアップ
データのバックアップと言えば、２０年ほど前はＤＡＴテープ。２０００年頃からＬＴＯ（リニアテープオープン）と呼ばれる規格のテープがこの十数年主流です。
テープバックアップの悪夢は、テープの中をスキャンしないと中に戻すべきデータがあるかどうかわからないという所です。１本のテープをスキャンするには数時間から丸一日かかる場合があります。その中に目的のデータがあればよし、なければ次のテープをスキャンする、という悪夢のような作業を繰り返して、やっと目的のテープのデータを見つけてリストアします。
ですから、通常はバックアップソフトウェアと組み合わせ、どのテープにどのデータが入っているかを管理し、必要なテープがどのテープなのかをできるだけ短時間で探し出す仕組みになっています。
そこで、バックアップのためのデータベースが障害を起こすと、これは困りものです。
もっとも、テープにラベルが貼ってあっても、ソフトウェアはそのラベルを読むわけではないので、「×月×日」と書かれたテープがソフトウェアのデータベースのリストにあるかどうか、一つ一つ調べるという、これまた悪夢のような作業があります。
テープバックアップ装置は、通常１本差しのものと、マガジンタイプのものがあります。実はこのマガジンタイプのものは、システム運用者にとって見たくない悪夢です。
テープの厚さは×ｎｍという薄いビニールです。これが秒速数百回転のリムに巻き取られます。当然熱も出ます。高熱による巻き込み事故というのもあります。また、テープは接触媒体なので、読み取りヘッダを定期的にクリーニングしなければなりません。
さらに、マガジンタイプの装置であれば、テープをマガジンから取り出して、装置にセットするためのロボットが付いています。
いちど、とある国立の研究機関で見たことがあるのですが、４畳半ほどの広さの「部屋」にテープが何千本と並んでいる「装置」を見たことがあります。部屋丸ごとバックアップ装置なのですね。
テープチェンジャは稼働部品が多い。壊れやすいのです。
また、マガジン装置自体はどのラベルのテープが交換されたか、という情報を保持するため、いったんマガジンを交換すると、内部のロボットが
「ギーガポン、ギーガポン」
と内部のテープをスキャンします。この時間もオペレータにとっては悪夢です。蓋を開けて閉めただけでこの動作ですから、一日何度もコーヒータイムができてしまいます。
一度だけ経験したことがありますが、２０本のテープをスキャンして、その中のわずか４本のテープからデータをリストアするまで３日かかったことがあります。
ということでシステム全体の障害というのは運用管理者にとって、最大の見たことにしたくないものなのです。
最近は、Ｄ２Ｄと呼ばれるディスク・ツー・ディスクのバックアップが主流です。これならば、いちいちテープをスキャンしたりしないため、リストアするためのデータに瞬時にアクセスできます。
また、テープメディアは１本１万五千円ほどしますが、最近のＨＤＤの場合、倍の容量でもその半額で済みます。しかも、テープメディアの信頼性が置けるバックアップは精々数回だけ。２０回も使えばエラーが出始めます。
しかし、まだテープ装置にはメリットがあります。
それはオフライン保管できるということです。
Ｄ２Ｄシステムの場合、オンラインでオペレーションのミスで瞬時にバックアップ内容が消去されますが、テープはオフラインで「耐火金庫に保管」という手段が取れるため、世代バックアップや何年もの間データを保管しておきたい場合などに有効です。ただ、サーバールームと同じ場所の耐火金庫であれば、火事で全部ダメになることもあるので、銀行の貸金庫や、「保管屋さん」と呼ばれる大金庫を持つ業者に預けるケースもよくあります。
日時のバックアップはディスクへ、月次のバックアップはテープで、という運用をしている運用担当者もいます。
不思議なもので、バックアップを丹念に管理しているお客様は、まず機材自体の故障という事故が起こりにくいようです。バックアップを粗雑にしている所では、よく機材が壊れて「御臨終」に立ち会うものです。
それでも古いテープメディアは新しい装置で読み込みができない場合もあります。ちょうど、今の時代のフロッピーディスクの様なものです。ここにデータがあるよ、とＦＤを出されても、読むための装置がない。これでは困りますね。
「北海道石狩平野をシリコンバレーに」
テープバックアップの悪夢は、テープの中をスキャンしないと中に戻すべきデータがあるかどうかわからないという所です。１本のテープをスキャンするには数時間から丸一日かかる場合があります。その中に目的のデータがあればよし、なければ次のテープをスキャンする、という悪夢のような作業を繰り返して、やっと目的のテープのデータを見つけてリストアします。
ですから、通常はバックアップソフトウェアと組み合わせ、どのテープにどのデータが入っているかを管理し、必要なテープがどのテープなのかをできるだけ短時間で探し出す仕組みになっています。
そこで、バックアップのためのデータベースが障害を起こすと、これは困りものです。
もっとも、テープにラベルが貼ってあっても、ソフトウェアはそのラベルを読むわけではないので、「×月×日」と書かれたテープがソフトウェアのデータベースのリストにあるかどうか、一つ一つ調べるという、これまた悪夢のような作業があります。
テープバックアップ装置は、通常１本差しのものと、マガジンタイプのものがあります。実はこのマガジンタイプのものは、システム運用者にとって見たくない悪夢です。
テープの厚さは×ｎｍという薄いビニールです。これが秒速数百回転のリムに巻き取られます。当然熱も出ます。高熱による巻き込み事故というのもあります。また、テープは接触媒体なので、読み取りヘッダを定期的にクリーニングしなければなりません。
さらに、マガジンタイプの装置であれば、テープをマガジンから取り出して、装置にセットするためのロボットが付いています。
いちど、とある国立の研究機関で見たことがあるのですが、４畳半ほどの広さの「部屋」にテープが何千本と並んでいる「装置」を見たことがあります。部屋丸ごとバックアップ装置なのですね。
テープチェンジャは稼働部品が多い。壊れやすいのです。
また、マガジン装置自体はどのラベルのテープが交換されたか、という情報を保持するため、いったんマガジンを交換すると、内部のロボットが
「ギーガポン、ギーガポン」
と内部のテープをスキャンします。この時間もオペレータにとっては悪夢です。蓋を開けて閉めただけでこの動作ですから、一日何度もコーヒータイムができてしまいます。
一度だけ経験したことがありますが、２０本のテープをスキャンして、その中のわずか４本のテープからデータをリストアするまで３日かかったことがあります。
ということでシステム全体の障害というのは運用管理者にとって、最大の見たことにしたくないものなのです。
最近は、Ｄ２Ｄと呼ばれるディスク・ツー・ディスクのバックアップが主流です。これならば、いちいちテープをスキャンしたりしないため、リストアするためのデータに瞬時にアクセスできます。
また、テープメディアは１本１万五千円ほどしますが、最近のＨＤＤの場合、倍の容量でもその半額で済みます。しかも、テープメディアの信頼性が置けるバックアップは精々数回だけ。２０回も使えばエラーが出始めます。
しかし、まだテープ装置にはメリットがあります。
それはオフライン保管できるということです。
Ｄ２Ｄシステムの場合、オンラインでオペレーションのミスで瞬時にバックアップ内容が消去されますが、テープはオフラインで「耐火金庫に保管」という手段が取れるため、世代バックアップや何年もの間データを保管しておきたい場合などに有効です。ただ、サーバールームと同じ場所の耐火金庫であれば、火事で全部ダメになることもあるので、銀行の貸金庫や、「保管屋さん」と呼ばれる大金庫を持つ業者に預けるケースもよくあります。
日時のバックアップはディスクへ、月次のバックアップはテープで、という運用をしている運用担当者もいます。
不思議なもので、バックアップを丹念に管理しているお客様は、まず機材自体の故障という事故が起こりにくいようです。バックアップを粗雑にしている所では、よく機材が壊れて「御臨終」に立ち会うものです。
それでも古いテープメディアは新しい装置で読み込みができない場合もあります。ちょうど、今の時代のフロッピーディスクの様なものです。ここにデータがあるよ、とＦＤを出されても、読むための装置がない。これでは困りますね。
「北海道石狩平野をシリコンバレーに」
2014年05月30日
Openstack:クラウドソフトウェアって何？
最近、クラウド関連の記事を読むと Openstack の記事が目につきます。
Openstack はクラウド管理ソフトウェアの一つで、他に Cloud Stack や Eucryptus(ユーカリプタス)などが代表的です。数年前は Eucryptus が先進的でした。最近は Openstack が注目を浴びています。
Openstack は元々 NASA が開発して、Rackspace などのクラウド事業者が中心となって開発されてきました。今は多くのコンピュータベンダーが採用して開発に参加している、巨大なオープンソースプロジェクトです。
--
さて、クラウドソフトウェアって何でしょうか。実は私も良くわかりません。数年前に Eucryptus の本を買って読みましたがちんぷんかんぷんでした。
それでも一言で言うと
「何百台ものハードウェアとハイパーバイザーで動作する何千台もの仮想システムを管理するためのソフトウェア」
とでも言えば良いのでしょうか。
クラウドと仮想化（１台のハードウェア上のハイパーバイザーで何台ものコンピュータソフトウェアシステムを動かす技術）は切っても切れないものです。
ハイパーバイザーと言うのは、システムを仮想化するための基本ソフトウェア（オペレーティングシステムのようなもの）です。
私のお客様では、数台のコンピュータでハイパーバイザーが動いていて４０台程度のシステムが動作している程度です。Openstack のような巨大なソフトウェアは必要としていません。
しかしあれば便利です。
実際の仮想化システムは、ハードウェアと仮想化ハイパーバイザーを管理している特権ユーザ(普通rootと言われる)が、仮想マシンを起動したり停止したり、作成したりします。
もし root 担当者が今日はお休みで。その場にいないのに、仮想システムがハングアップして再起動が必要になったとします。仮想システムを利用している利用者はシステムを操作する権限がないため再起動できません。
そこでクラウド管理ソフトウェアが必要となります。
例えば IaaS(Infrastructure as a Service)や、俗に言う「仮想マシン貸し」ＶＰＳサービスなどに利用されます。
例えば、ある小さな企業や個人が自分のウェブサイトを作ろうとしましょう。IaaS サービスに申し込むと、利用者アカウントとパスワードが与えられ、サービスのウェブサイトに接続できます。そこから、実際の「仮想コンピュータ」の root となって自由に仮想システムを作ったり、再起動することができます。しかし、実際のハイパーバイザーの root 権限はありません。
仮想上のシステムには、サービス事業者から与えられた ID とパスワードだけで root 権限で利用できます。
実際にインストール用のＤＶＤメディアも必要なければ、Windowsのような場合のアクティベーションライセンスキーを入力することもありません。
また、仮想コンピュータに１０Ｇバイトのディスクが必要だ、とした場合、利用者はそのディスクを準備する必要もありません。またインストール用のＤＶＤメディアも、サービス事業者がディスクスペースにインストール用イメージとしてプールしています。
これらの管理は全て、クラウド管理ソフトウェアが行います。
例えば、ユーザがＶＰＳサービスを申し込んで仮想コンピュータシステムを「作ろう」とした場合、どのハードウェアのハイパーバイザーであれば、必要なＣＰＵの空きがあり、どのハードディスクプール（貯蔵池）に余裕があるかを判断し、顧客にそのスペースを用意します。
また、ある機材の負荷が高くて、他の利用者に影響が出るような場合、余裕のあるハードウェアにシステムを「移動」させることもクラウドソフトウェアの機能です。
クラウド事業者は、例えばマイクロソフトなどから、必要なライセンスを購入済みであるとします。顧客が「Windows を１台ほしい」と思えば、プールしておいたライセンスから一つ分を顧客に与えます。
顧客がそのサービスを停止してしまえば、ライセンスは一つ空きができるため、この空きは別な顧客が利用できるという仕組みです。
また、顧客がどれくらいのＣＰＵ性能を利用したのか、ディスクをどれだけ占有しているのか、通信量はどれくらいか、によって事業者は課金します。従量課金ですね。
この計算もクラウド管理ソフトウェアが行います。
--
私のお客様の小規模なプライベートクラウドでは、利用者さんが「こんなシステムが欲しい」という場合、十分から数十分の時間でシステムを用意できる体制になっています。しかし、この作業はお客様の管理者が手動で行わなければなりません。ただし、ハードウェアの調達費用が全くかからないため、通常なら数日から数週間かけて行われる「稟議」「調達」「設置」という面倒な作業が一切かかりません。これがクラウドサービスの最大の利点です。
大企業でのプライベートクラウドでは、ある事業部門が「Windowsサーバーが１台欲しい」ということになれば、数百台規模でプールされているハードウェアの中の一部分の「空き資源」を使ってサーバーを準備します。その時に威力を発揮するのが、クラウド管理ソフトウェアです。
また、クラウド管理ソフトウェアは、外部のクラウド事業者、例えば Amazon AWS の様な IaaS サービスとの互換性が重要です。社内で開発した、例えばアンケートや短期間のキャンペーン情報の配信システム、選挙速報のシステムなど、テスト済みの「仮想コンピュータ」を外部に公開する場合、互換性は重要です。
北海道石狩川中流域にデータセンターを誘致する勝手なプロジェクト
Openstack はクラウド管理ソフトウェアの一つで、他に Cloud Stack や Eucryptus(ユーカリプタス)などが代表的です。数年前は Eucryptus が先進的でした。最近は Openstack が注目を浴びています。
Openstack は元々 NASA が開発して、Rackspace などのクラウド事業者が中心となって開発されてきました。今は多くのコンピュータベンダーが採用して開発に参加している、巨大なオープンソースプロジェクトです。
--
さて、クラウドソフトウェアって何でしょうか。実は私も良くわかりません。数年前に Eucryptus の本を買って読みましたがちんぷんかんぷんでした。
それでも一言で言うと
「何百台ものハードウェアとハイパーバイザーで動作する何千台もの仮想システムを管理するためのソフトウェア」
とでも言えば良いのでしょうか。
クラウドと仮想化（１台のハードウェア上のハイパーバイザーで何台ものコンピュータソフトウェアシステムを動かす技術）は切っても切れないものです。
ハイパーバイザーと言うのは、システムを仮想化するための基本ソフトウェア（オペレーティングシステムのようなもの）です。
私のお客様では、数台のコンピュータでハイパーバイザーが動いていて４０台程度のシステムが動作している程度です。Openstack のような巨大なソフトウェアは必要としていません。
しかしあれば便利です。
実際の仮想化システムは、ハードウェアと仮想化ハイパーバイザーを管理している特権ユーザ(普通rootと言われる)が、仮想マシンを起動したり停止したり、作成したりします。
もし root 担当者が今日はお休みで。その場にいないのに、仮想システムがハングアップして再起動が必要になったとします。仮想システムを利用している利用者はシステムを操作する権限がないため再起動できません。
そこでクラウド管理ソフトウェアが必要となります。
例えば IaaS(Infrastructure as a Service)や、俗に言う「仮想マシン貸し」ＶＰＳサービスなどに利用されます。
例えば、ある小さな企業や個人が自分のウェブサイトを作ろうとしましょう。IaaS サービスに申し込むと、利用者アカウントとパスワードが与えられ、サービスのウェブサイトに接続できます。そこから、実際の「仮想コンピュータ」の root となって自由に仮想システムを作ったり、再起動することができます。しかし、実際のハイパーバイザーの root 権限はありません。
仮想上のシステムには、サービス事業者から与えられた ID とパスワードだけで root 権限で利用できます。
実際にインストール用のＤＶＤメディアも必要なければ、Windowsのような場合のアクティベーションライセンスキーを入力することもありません。
また、仮想コンピュータに１０Ｇバイトのディスクが必要だ、とした場合、利用者はそのディスクを準備する必要もありません。またインストール用のＤＶＤメディアも、サービス事業者がディスクスペースにインストール用イメージとしてプールしています。
これらの管理は全て、クラウド管理ソフトウェアが行います。
例えば、ユーザがＶＰＳサービスを申し込んで仮想コンピュータシステムを「作ろう」とした場合、どのハードウェアのハイパーバイザーであれば、必要なＣＰＵの空きがあり、どのハードディスクプール（貯蔵池）に余裕があるかを判断し、顧客にそのスペースを用意します。
また、ある機材の負荷が高くて、他の利用者に影響が出るような場合、余裕のあるハードウェアにシステムを「移動」させることもクラウドソフトウェアの機能です。
クラウド事業者は、例えばマイクロソフトなどから、必要なライセンスを購入済みであるとします。顧客が「Windows を１台ほしい」と思えば、プールしておいたライセンスから一つ分を顧客に与えます。
顧客がそのサービスを停止してしまえば、ライセンスは一つ空きができるため、この空きは別な顧客が利用できるという仕組みです。
また、顧客がどれくらいのＣＰＵ性能を利用したのか、ディスクをどれだけ占有しているのか、通信量はどれくらいか、によって事業者は課金します。従量課金ですね。
この計算もクラウド管理ソフトウェアが行います。
--
私のお客様の小規模なプライベートクラウドでは、利用者さんが「こんなシステムが欲しい」という場合、十分から数十分の時間でシステムを用意できる体制になっています。しかし、この作業はお客様の管理者が手動で行わなければなりません。ただし、ハードウェアの調達費用が全くかからないため、通常なら数日から数週間かけて行われる「稟議」「調達」「設置」という面倒な作業が一切かかりません。これがクラウドサービスの最大の利点です。
大企業でのプライベートクラウドでは、ある事業部門が「Windowsサーバーが１台欲しい」ということになれば、数百台規模でプールされているハードウェアの中の一部分の「空き資源」を使ってサーバーを準備します。その時に威力を発揮するのが、クラウド管理ソフトウェアです。
また、クラウド管理ソフトウェアは、外部のクラウド事業者、例えば Amazon AWS の様な IaaS サービスとの互換性が重要です。社内で開発した、例えばアンケートや短期間のキャンペーン情報の配信システム、選挙速報のシステムなど、テスト済みの「仮想コンピュータ」を外部に公開する場合、互換性は重要です。
北海道石狩川中流域にデータセンターを誘致する勝手なプロジェクト
2014年05月28日
Linux は無料？
Linux は「オープンソースで無料」とメディアでは言われます。
「タダ」という言葉に私たちは非常に弱い。
しかし「タダより高いものはない」ともあるように、決してコストゼロではありません。
「オープンソース」とはソースコード（ソフトウェアの詳細な設計書）が公開されているソフトウェアです。しかし、守るべき著作権があります。オープンソースの著作権には様々な種類があります。は、ソースコードを再利用した場合は、変更したソースコードも併せて公開しなければならないというルールがあるもの、あるいは著作権保持者を明記しなければならない、などのルールです。
このルールがあるため、オープンソースにはウィルスを仕込んで配布するなどの事は事実上困難です。
--
Linux はオープンソースですが、無料で使えるものと、「商用Linux」と呼ばれる有料のものとがあります。
ソフトウェアには必ず「バグ」と呼ばれる不具合が付きものです。
無料で利用できるものは、全て「自己責任」で利用できます。しかし、バグの対応も自己責任です。先日も SSL と呼ばれる暗号通信の機能にバグが見つかり、大騒動になりました。
ソフトウェアの機能は単一のプログラムで完結していません。共通の機能を「ライブラリ」という形式で提供します。例えばあるプログラムに暗号化通信が必要であれば、そのプログラムはライブラリを利用すれば良いわけです。他の全てのプログラムはこの暗号通信用のライブラリを使えば、別なソフトウェアとして機能できます。
これを「ソフトウェアの依存性」と言います。
よくある話として、あるアプリケーションソフトウェアを動かそうとすると、この「依存性」の問題で動かないケースがあります。そこでライブラリを新しくすると、今度は別なプログラムが動作しないということがあります。これは日常茶飯事です。
無料の Linux の利用者はこの問題を自分で解決しなければならないのです。
一方、商用 Linux はこうした依存性の問題や不具合の対応を解決した状態で出荷され、それなりの費用を支払えば、見つかったバグにも、電話対応もしてくれるわけです。
--
格安のレンタルサーバーなどを運用するホスティング事業者は、コストを下げるために無料の Linux を使います。しかし、自社運用なので、それなりの技術者が必要です。大抵の場合、彼らは Linux のシステムに精通していて、海外のメーリングリストなどのコミュニティにバグの報告や改善方法を投稿し、時には自ら解決できる程の技術力があります。
私の様な一般的な「何でも屋」の技術レベルではこの様な高度なことはできません。ですから、お客様に提案する場合は必ず商用 Linux でサポートを受けられる体制を提案します。ただし、自己責任でテストするような場合は、無料の Linux を使います。
--
なぜ Windows にはオープンソースのアプリケーションがないのでしょうか。それは Linux を始めとする多くの UNIX 系のシステムには「コンパイラ」という機能があるからです。コンパイラはソースコードに書かれた詳細な設計図をプログラムに翻訳するソフトウェアです。
コンパイラがあって、ソースコードがあれば、ソースコードを自由に変更してコンパイル（翻訳）して修正することができます。（技術があればの話ですが）
しかし Windows にコンパイラは付属しません。なぜならマイクロソフトは昔からコンパイラのようなＰＣ向けの開発ツールを販売していたからです。ですから Windows 用の開発ツールは有料です。しかも、マイクロソフト以外の企業もコンパイラを販売しています。
したがって Windows 向けのソフトウェアはソースコードを添付して配布するという事ができません。ソフトウェアを開発したい人々は、マイクロソフトからコンパイラなどの開発キットを購入して、プログラムを書いて、コンパイルからセットアッププログラムにまで仕上げて配布します。
ここに悪意がある開発者がいると、セットアッププログラムにコンピュータウィルスを仕込む事が出来ます。何しろソースコードは配布されていないのです。
だから「信頼できないプログラムは実行してはならない」といるルールが出来上がります。
最近、Windows 用の中国製の文字変換プログラムや、韓国製のビデオソフトにこのような「悪意」を感じさせる機能が組み込まれていることが判明して、大きな話題になりました。
一般的には、ソースコードが公開されているオープンソースにはこのような機能を組み込むことは困難でしょう。
北海道石狩川流域をシリコンバレーに変える勝手なプロジェクト
「タダ」という言葉に私たちは非常に弱い。
しかし「タダより高いものはない」ともあるように、決してコストゼロではありません。
「オープンソース」とはソースコード（ソフトウェアの詳細な設計書）が公開されているソフトウェアです。しかし、守るべき著作権があります。オープンソースの著作権には様々な種類があります。は、ソースコードを再利用した場合は、変更したソースコードも併せて公開しなければならないというルールがあるもの、あるいは著作権保持者を明記しなければならない、などのルールです。
このルールがあるため、オープンソースにはウィルスを仕込んで配布するなどの事は事実上困難です。
--
Linux はオープンソースですが、無料で使えるものと、「商用Linux」と呼ばれる有料のものとがあります。
ソフトウェアには必ず「バグ」と呼ばれる不具合が付きものです。
無料で利用できるものは、全て「自己責任」で利用できます。しかし、バグの対応も自己責任です。先日も SSL と呼ばれる暗号通信の機能にバグが見つかり、大騒動になりました。
ソフトウェアの機能は単一のプログラムで完結していません。共通の機能を「ライブラリ」という形式で提供します。例えばあるプログラムに暗号化通信が必要であれば、そのプログラムはライブラリを利用すれば良いわけです。他の全てのプログラムはこの暗号通信用のライブラリを使えば、別なソフトウェアとして機能できます。
これを「ソフトウェアの依存性」と言います。
よくある話として、あるアプリケーションソフトウェアを動かそうとすると、この「依存性」の問題で動かないケースがあります。そこでライブラリを新しくすると、今度は別なプログラムが動作しないということがあります。これは日常茶飯事です。
無料の Linux の利用者はこの問題を自分で解決しなければならないのです。
一方、商用 Linux はこうした依存性の問題や不具合の対応を解決した状態で出荷され、それなりの費用を支払えば、見つかったバグにも、電話対応もしてくれるわけです。
--
格安のレンタルサーバーなどを運用するホスティング事業者は、コストを下げるために無料の Linux を使います。しかし、自社運用なので、それなりの技術者が必要です。大抵の場合、彼らは Linux のシステムに精通していて、海外のメーリングリストなどのコミュニティにバグの報告や改善方法を投稿し、時には自ら解決できる程の技術力があります。
私の様な一般的な「何でも屋」の技術レベルではこの様な高度なことはできません。ですから、お客様に提案する場合は必ず商用 Linux でサポートを受けられる体制を提案します。ただし、自己責任でテストするような場合は、無料の Linux を使います。
--
なぜ Windows にはオープンソースのアプリケーションがないのでしょうか。それは Linux を始めとする多くの UNIX 系のシステムには「コンパイラ」という機能があるからです。コンパイラはソースコードに書かれた詳細な設計図をプログラムに翻訳するソフトウェアです。
コンパイラがあって、ソースコードがあれば、ソースコードを自由に変更してコンパイル（翻訳）して修正することができます。（技術があればの話ですが）
しかし Windows にコンパイラは付属しません。なぜならマイクロソフトは昔からコンパイラのようなＰＣ向けの開発ツールを販売していたからです。ですから Windows 用の開発ツールは有料です。しかも、マイクロソフト以外の企業もコンパイラを販売しています。
したがって Windows 向けのソフトウェアはソースコードを添付して配布するという事ができません。ソフトウェアを開発したい人々は、マイクロソフトからコンパイラなどの開発キットを購入して、プログラムを書いて、コンパイルからセットアッププログラムにまで仕上げて配布します。
ここに悪意がある開発者がいると、セットアッププログラムにコンピュータウィルスを仕込む事が出来ます。何しろソースコードは配布されていないのです。
だから「信頼できないプログラムは実行してはならない」といるルールが出来上がります。
最近、Windows 用の中国製の文字変換プログラムや、韓国製のビデオソフトにこのような「悪意」を感じさせる機能が組み込まれていることが判明して、大きな話題になりました。
一般的には、ソースコードが公開されているオープンソースにはこのような機能を組み込むことは困難でしょう。
北海道石狩川流域をシリコンバレーに変える勝手なプロジェクト
2014年05月19日
カスタマイズが必要な日本の顧客：日本のガラパゴスクラウド
これはどこかの記事の受け売りなのですが、日本企業はとにかくパッケージソフトウェアでも何でもカスタマイズ（独自の修正）を求める傾向がある、と言われます。
パッケージソフトウェアは、特定の業務での最大公約数を併せ持った機能を備えています。パッケージソフトウェアを開発、提供している企業は、ターゲットとする業界に精通しています。つまり「この業界であれば、この機能があればほぼ業務はできる」という最大解決策（ベストプラクティクス）を満載して提供しているわけです。
しかし、それでも顧客は細かなカスタマイズを求めます。
そのため、日本には「ＳＩベンダー」と呼ばれる日本独特の専門ビジネスが成立し、多くの「カスタマイズされたスパゲッティ」を料理しています。シンプルなソーメンにケチャップをかけて、塩味が足りないからと醤油と豆板醤を足す。そんな仕事です。
レシピはますます複雑になりますから、システムの改修コストは馬鹿みたいに高価になり、ますますオリジナルの「素の味」がどんなであったか、顧客の目標がなんであったのかを忘れてカスタマイズ競争に走る訳です。
俗に、ヒト、モノ、カネを管理するためのＥＲＰ（「企業資源計画」というらしい）パッケージのカスタマイズは典型的です。有名な例では静岡銀行とＩＢＭの訴訟合戦などがあります。
ここに、なぜ日本のクラウドビジネスが小規模で高価で、規模を追求できないかの理由があるように思えます。
よく言われる事ですが、海外企業では導入したパッケージソフトウェアに合わせて業務を変更して効率化に成功します。なぜならパッケージソフトウェアを開発した企業は、その事業分野に精通していて、ベストプラクティスを提供できるからです。
しかし日本企業では事業部門の要求に合わせてパッケージソフトウェアを変更して使います。
日本企業では情報部門の力が経営に密着せず、単なる「システムのお守り」ほどの力量がないのに対して、業務部門の意見が経営者に通じやすい、というのも理由の一つです。
--
ある意味、 SaaS (Software as a Service) は究極のパッケージソフトです。しかし日本企業はそこにもカスタマイズを求めます。
これも受け売りなので申し訳ないのですが、日本のあるＩＴコンサルタントは、海外ベンダーがパッケージソフトやＳａａＳサービスを日本でも売りたい、という相談に対して、
「日本では商売にならないからやめとけ」
とアドバイスするのだそうです。Ｂ２Ｃ（個人向）ならいざ知らず、Ｂ２Ｂ（業務向）で海外製のパッケージを日本語化して成功したという事例はあまり聞いた事がありません。知っていたら教えてください。
実際、ＳＢＳ(Small Bissuines Server) と呼ばれる製品があります。電子メールからファイルサービス、ユーザの認証管理などを全て賄う、１０人～２５人程度のスタートアップ事業者向けのオフィスサーバ製品のパッケージです。なぜか海外ではＳＢＳは結構売れるのですが、同じものは日本では全く売れない、と某外資系ソフトウェアベンダーのセールスマン氏がぼやいていました。
--
例えば役場の住民管理だとか、学校の成績管理のシステムなどは、どのパッケージを使おうがほとんど差異はないのでしょうが、それでも顧客は独自仕様を求めます。
どうして、こういった共通の「業務」を共通化した仕様で構築できないのでしょうか。例えば地域で第三セクター化したデータセンターで集中管理してしまえば、導入、運用コストの大幅な削減ができます。現実に実施している自治体もあります。
しかしあまり大きな話題になることはありません。
ソフトウェアの共通化ができないため、必然的にシステムはオンプレミス（自社内運用）か、せいぜいデータセンターにハウジングして預けてしまう、程度のデータセンター利用しか期待できなくなります。
データセンターでのハウジングサービスはあくまでもオンプレミスの延長でしかありません。単にオフィスの電源や冷房コスト、騒音とスペース削減、物理的なセキュリティ面に役立つだけです。あくまでも非効率で電源を食いまくるサーバーを、仮想化して効率化して使用電力や無駄なディスクスペース、メモリを効率化することもせずに、「置き場所」を変えただけです。
--
この様に考えると、大都市圏のデータセンターの空きスペースが中々埋まらないのは当然の事です。何しろオンプレミスの延長でしかなく、引き換えに１２．５Ｍバイト秒(100Mbpsとすると)しか出ない光回線、高価なハウジングコスト、バックアップテープを交換するだけでオフィスから片道１時間の距離。目で確認できないステータスランプ。
データセンターを使う上で何のメリットもないのです。だから首都圏のＤＣは空きが多い。埋まらないのです。
--
そこで、データセンターを「半製品化」して規格化することが一つの解決策として提案できます。
例えば NetIQ/Novell の Platespin や Barracuda の様な、Ｖ２Ｐ２Ｖのバックアップ、ＢＣＰ（事業継続プラン）の専用アプライアンス製品を専門に扱う地方のデータセンター。これなら、ハードウェアもソフトウェアも共通化できるため、事業者側のスタッフも顧客向けの特別な訓練は必要ありません。
あるいは iSCSI の専用ハードディスクデバイスやテープカートリッジのオートローダーを並べたデータセンターなど、IaaS でもなければ、特殊なＢＣＰ対策を目的としたビジネスもあり得るでしょう。
--
しかしそういった単目的であってもカスタマイズを要求する日本の顧客。顧客の意識をかえなければならないのですが、ＤＣビジネスのために顧客の意識が変わるわけもありません。やはりＳＩベンダー偏重の顧客意識全体が変わらない限り、相変わらず日本のクラウド、データセンタービジネスはガラパゴス化するしかないのでしょうか。
さすがに、単なる企業紹介のウェブサイトなどは、ホスティング業者を使う事が当たり前になりました。しかし電子メールはコンプライアンス云々の問題から、ホスティングされているものをそのまま利用できない。あるいは独自の機能を付加したいと言った要望があるようです。
昨年の記事ですが
変貌を遂げるデータセンタービジネス
でさくらインターネットの石狩データセンターが開所１年あまりで単月黒字となりました。しかし彼らにも悩みがあります。
例えば、ラックを貸し出す「ハウジング」では、1ラック当たりの月商は15万円程度に過ぎない。しかし、物理サーバーを貸し出す「ホスティング」の場合、1ラック当たりの月商は100万円ほどになり、仮想サーバーを貸し出す「クラウド」や「VPS（仮想プライベートサーバー）」では、1ラック当たりの月商は300万～400万円にも達する。当然ながら利益額も、、ハウジングなどよりホスティングやクラウドの方が大きい。
にも関わらず
「東日本大震災以降に、BCP（ビジネス継続計画）需要が急増した」（田中社長）ため、石狩DCは当初の想定よりも「ハウジングが売れてしまった」（同）という。
つまり、圧倒的にハウジングよりホスティングの方が効率的なのです。このコスト差は自然と顧客の支払うコストに跳ね返ります。
ここにも、日本固有の「ベンダー主導」の日本の情報業界の特殊性があります。なぜなら、ＳＩベンダーとしては「機械が売れてソフトウェアが売れて単価の高いエンジニアを効率よく働かせる」ことが利益の根源だからです。
従って、上辺では「クラウド」を口にしながらも、現実には土地価格の高い首都圏の周辺の自社のデータセンターに「ハウジング」サービスを誘導しようとします。カタログには「都心から何十分」とか「東日本震災を想定した耐震、免震構造」「堅牢なセキュリティ」を謳います。当然、ラックの中に収まるのは自社扱い製品のサーバーや通信機器です。移動経費のかからない「自社のエンジニアが常時待機」できるわけですね。
当然、ラックのレンタル料金は高額になります。
だから首都圏のデータセンターは空きが多い。
もし、発想を全て逆回転すれば、
「クラウドは全てを仮想化して抽象化する」
わけですから、ハードウェアがどこにあろうが関係ないのです。処理用のＣＰＵが首都圏にあって、バックアップシステムが地方にあってもおかしくない。また、自社のシステムがＦ通なのかＮ石なのかほーむぺーじなのか、出るなのかは関係ありません。ひょっとしたら無印のホワイトボックス（フルカスタム）サーバーなのかを知る必要もないのですね。
それがクラウドの本来の姿です。オンプレミスの延長ではありません。
ただ、その決断ができるのが、果たして情報部門なのか、経営層なのか利用者部門なのか、それが問題なのです。
北海道石狩川中流域にデータセンターを誘致する勝手なプロジェクト Surachipt Data Stream
パッケージソフトウェアは、特定の業務での最大公約数を併せ持った機能を備えています。パッケージソフトウェアを開発、提供している企業は、ターゲットとする業界に精通しています。つまり「この業界であれば、この機能があればほぼ業務はできる」という最大解決策（ベストプラクティクス）を満載して提供しているわけです。
しかし、それでも顧客は細かなカスタマイズを求めます。
そのため、日本には「ＳＩベンダー」と呼ばれる日本独特の専門ビジネスが成立し、多くの「カスタマイズされたスパゲッティ」を料理しています。シンプルなソーメンにケチャップをかけて、塩味が足りないからと醤油と豆板醤を足す。そんな仕事です。
レシピはますます複雑になりますから、システムの改修コストは馬鹿みたいに高価になり、ますますオリジナルの「素の味」がどんなであったか、顧客の目標がなんであったのかを忘れてカスタマイズ競争に走る訳です。
俗に、ヒト、モノ、カネを管理するためのＥＲＰ（「企業資源計画」というらしい）パッケージのカスタマイズは典型的です。有名な例では静岡銀行とＩＢＭの訴訟合戦などがあります。
ここに、なぜ日本のクラウドビジネスが小規模で高価で、規模を追求できないかの理由があるように思えます。
よく言われる事ですが、海外企業では導入したパッケージソフトウェアに合わせて業務を変更して効率化に成功します。なぜならパッケージソフトウェアを開発した企業は、その事業分野に精通していて、ベストプラクティスを提供できるからです。
しかし日本企業では事業部門の要求に合わせてパッケージソフトウェアを変更して使います。
日本企業では情報部門の力が経営に密着せず、単なる「システムのお守り」ほどの力量がないのに対して、業務部門の意見が経営者に通じやすい、というのも理由の一つです。
--
ある意味、 SaaS (Software as a Service) は究極のパッケージソフトです。しかし日本企業はそこにもカスタマイズを求めます。
これも受け売りなので申し訳ないのですが、日本のあるＩＴコンサルタントは、海外ベンダーがパッケージソフトやＳａａＳサービスを日本でも売りたい、という相談に対して、
「日本では商売にならないからやめとけ」
とアドバイスするのだそうです。Ｂ２Ｃ（個人向）ならいざ知らず、Ｂ２Ｂ（業務向）で海外製のパッケージを日本語化して成功したという事例はあまり聞いた事がありません。知っていたら教えてください。
実際、ＳＢＳ(Small Bissuines Server) と呼ばれる製品があります。電子メールからファイルサービス、ユーザの認証管理などを全て賄う、１０人～２５人程度のスタートアップ事業者向けのオフィスサーバ製品のパッケージです。なぜか海外ではＳＢＳは結構売れるのですが、同じものは日本では全く売れない、と某外資系ソフトウェアベンダーのセールスマン氏がぼやいていました。
--
例えば役場の住民管理だとか、学校の成績管理のシステムなどは、どのパッケージを使おうがほとんど差異はないのでしょうが、それでも顧客は独自仕様を求めます。
どうして、こういった共通の「業務」を共通化した仕様で構築できないのでしょうか。例えば地域で第三セクター化したデータセンターで集中管理してしまえば、導入、運用コストの大幅な削減ができます。現実に実施している自治体もあります。
しかしあまり大きな話題になることはありません。
ソフトウェアの共通化ができないため、必然的にシステムはオンプレミス（自社内運用）か、せいぜいデータセンターにハウジングして預けてしまう、程度のデータセンター利用しか期待できなくなります。
データセンターでのハウジングサービスはあくまでもオンプレミスの延長でしかありません。単にオフィスの電源や冷房コスト、騒音とスペース削減、物理的なセキュリティ面に役立つだけです。あくまでも非効率で電源を食いまくるサーバーを、仮想化して効率化して使用電力や無駄なディスクスペース、メモリを効率化することもせずに、「置き場所」を変えただけです。
--
この様に考えると、大都市圏のデータセンターの空きスペースが中々埋まらないのは当然の事です。何しろオンプレミスの延長でしかなく、引き換えに１２．５Ｍバイト秒(100Mbpsとすると)しか出ない光回線、高価なハウジングコスト、バックアップテープを交換するだけでオフィスから片道１時間の距離。目で確認できないステータスランプ。
データセンターを使う上で何のメリットもないのです。だから首都圏のＤＣは空きが多い。埋まらないのです。
--
そこで、データセンターを「半製品化」して規格化することが一つの解決策として提案できます。
例えば NetIQ/Novell の Platespin や Barracuda の様な、Ｖ２Ｐ２Ｖのバックアップ、ＢＣＰ（事業継続プラン）の専用アプライアンス製品を専門に扱う地方のデータセンター。これなら、ハードウェアもソフトウェアも共通化できるため、事業者側のスタッフも顧客向けの特別な訓練は必要ありません。
あるいは iSCSI の専用ハードディスクデバイスやテープカートリッジのオートローダーを並べたデータセンターなど、IaaS でもなければ、特殊なＢＣＰ対策を目的としたビジネスもあり得るでしょう。
--
しかしそういった単目的であってもカスタマイズを要求する日本の顧客。顧客の意識をかえなければならないのですが、ＤＣビジネスのために顧客の意識が変わるわけもありません。やはりＳＩベンダー偏重の顧客意識全体が変わらない限り、相変わらず日本のクラウド、データセンタービジネスはガラパゴス化するしかないのでしょうか。
さすがに、単なる企業紹介のウェブサイトなどは、ホスティング業者を使う事が当たり前になりました。しかし電子メールはコンプライアンス云々の問題から、ホスティングされているものをそのまま利用できない。あるいは独自の機能を付加したいと言った要望があるようです。
昨年の記事ですが
変貌を遂げるデータセンタービジネス
でさくらインターネットの石狩データセンターが開所１年あまりで単月黒字となりました。しかし彼らにも悩みがあります。
例えば、ラックを貸し出す「ハウジング」では、1ラック当たりの月商は15万円程度に過ぎない。しかし、物理サーバーを貸し出す「ホスティング」の場合、1ラック当たりの月商は100万円ほどになり、仮想サーバーを貸し出す「クラウド」や「VPS（仮想プライベートサーバー）」では、1ラック当たりの月商は300万～400万円にも達する。当然ながら利益額も、、ハウジングなどよりホスティングやクラウドの方が大きい。
にも関わらず
「東日本大震災以降に、BCP（ビジネス継続計画）需要が急増した」（田中社長）ため、石狩DCは当初の想定よりも「ハウジングが売れてしまった」（同）という。
つまり、圧倒的にハウジングよりホスティングの方が効率的なのです。このコスト差は自然と顧客の支払うコストに跳ね返ります。
ここにも、日本固有の「ベンダー主導」の日本の情報業界の特殊性があります。なぜなら、ＳＩベンダーとしては「機械が売れてソフトウェアが売れて単価の高いエンジニアを効率よく働かせる」ことが利益の根源だからです。
従って、上辺では「クラウド」を口にしながらも、現実には土地価格の高い首都圏の周辺の自社のデータセンターに「ハウジング」サービスを誘導しようとします。カタログには「都心から何十分」とか「東日本震災を想定した耐震、免震構造」「堅牢なセキュリティ」を謳います。当然、ラックの中に収まるのは自社扱い製品のサーバーや通信機器です。移動経費のかからない「自社のエンジニアが常時待機」できるわけですね。
当然、ラックのレンタル料金は高額になります。
だから首都圏のデータセンターは空きが多い。
もし、発想を全て逆回転すれば、
「クラウドは全てを仮想化して抽象化する」
わけですから、ハードウェアがどこにあろうが関係ないのです。処理用のＣＰＵが首都圏にあって、バックアップシステムが地方にあってもおかしくない。また、自社のシステムがＦ通なのかＮ石なのかほーむぺーじなのか、出るなのかは関係ありません。ひょっとしたら無印のホワイトボックス（フルカスタム）サーバーなのかを知る必要もないのですね。
それがクラウドの本来の姿です。オンプレミスの延長ではありません。
ただ、その決断ができるのが、果たして情報部門なのか、経営層なのか利用者部門なのか、それが問題なのです。
北海道石狩川中流域にデータセンターを誘致する勝手なプロジェクト Surachipt Data Stream
2013年09月03日
夏のＰＣ熱対策 - ＤＣ運用は北海道で！
今年の東京の夏は暑いですね。特に残暑が厳しいです。
この季節はデータセンター運用担当者にとってはとても厳しい季節です。
猛暑 故障ＰＣ相次ぎ修理に
-雷-
２週間ほど前、落雷が近所にありまして、見事にモデムが壊れました。
雷様は「ヘソを取る」と言いますが、北海道空知地方ではあまり落雷がありません。珍しく雷がなると、外へ出て本当に「稲光」があるのかどうか「ヘソを取られる」よりも興味があったものです。
-室温-
今年もＨＤＤが一台、お陀仏になりました。ＨＤＤだけではなく、コンピューターのセンサーが自動的に高温を検出してコンピュータの電源を切ってしまいます。
「電源は入れど立ち上がらない」
「一旦ファンは回るのだけれど立ち上がらない」
などの現象が出ます。
この場合、コンピュータの電源を抜いて数十分放置して、風を当てて電源を元に戻すと直る場合があります。これは以外と原因がわかりにくい。
こういう事象を繰り返すとＨＤＤにも余分な負担がかかって更なる故障の原因となる場合があります。
石狩平野は、常時日本海と太平洋の冷気が通う平原地帯なので、７月の終わりの週を除けばまず、最高気温が３０℃をこえることがありません。一般家庭ではまずエアコンはありませんし、北海道でのクーラーの普及率は１０数％だそうです。
-熱対策-
コンピューターのクロック周波数を少し落として見ました。あまり変わらないようです。Linux の場合ＨＤＤを自動的に停止させる hdparm というコマンドがあるため、これを使ってＨＤＤのスピンをとめています。しかしあまり効果はないようですけど。
-竜巻-
昨日、埼玉県地方で竜巻被害があり、停電も発生しました。北海道では２００６年に佐呂間町で大規模な竜巻被害が出ています。
竜巻被害は大規模なもので、北米では「竜巻シェルター」を装備するのが住宅設計の基本、という地域もあります。
北海道ではこうした突発的な天候被害はフェーン現象が発生しやすい道東地方に多いようです。
-噴煙-
もし富士山が噴火したら。考えるのも怖いのですが、交通だけではなく電気、通信あらゆるインフラが混乱します。
中部空知で一番近い活火山は、洞爺湖、有珠岳付近です。６０年に一度は必ず噴火するので、おおよその被害の予測は付きます。一度噴火したときは、庭の草花の表面にうっすらと降灰がありました。その程度です。
東には大雪山がありますが、北海道は一般的に西風なので、距離的には有珠岳より近いのですが被害はほとんど考えにくいでしょう。
この季節はデータセンター運用担当者にとってはとても厳しい季節です。
猛暑 故障ＰＣ相次ぎ修理に
-雷-
２週間ほど前、落雷が近所にありまして、見事にモデムが壊れました。
雷様は「ヘソを取る」と言いますが、北海道空知地方ではあまり落雷がありません。珍しく雷がなると、外へ出て本当に「稲光」があるのかどうか「ヘソを取られる」よりも興味があったものです。
-室温-
今年もＨＤＤが一台、お陀仏になりました。ＨＤＤだけではなく、コンピューターのセンサーが自動的に高温を検出してコンピュータの電源を切ってしまいます。
「電源は入れど立ち上がらない」
「一旦ファンは回るのだけれど立ち上がらない」
などの現象が出ます。
この場合、コンピュータの電源を抜いて数十分放置して、風を当てて電源を元に戻すと直る場合があります。これは以外と原因がわかりにくい。
こういう事象を繰り返すとＨＤＤにも余分な負担がかかって更なる故障の原因となる場合があります。
石狩平野は、常時日本海と太平洋の冷気が通う平原地帯なので、７月の終わりの週を除けばまず、最高気温が３０℃をこえることがありません。一般家庭ではまずエアコンはありませんし、北海道でのクーラーの普及率は１０数％だそうです。
-熱対策-
コンピューターのクロック周波数を少し落として見ました。あまり変わらないようです。Linux の場合ＨＤＤを自動的に停止させる hdparm というコマンドがあるため、これを使ってＨＤＤのスピンをとめています。しかしあまり効果はないようですけど。
-竜巻-
昨日、埼玉県地方で竜巻被害があり、停電も発生しました。北海道では２００６年に佐呂間町で大規模な竜巻被害が出ています。
竜巻被害は大規模なもので、北米では「竜巻シェルター」を装備するのが住宅設計の基本、という地域もあります。
北海道ではこうした突発的な天候被害はフェーン現象が発生しやすい道東地方に多いようです。
-噴煙-
もし富士山が噴火したら。考えるのも怖いのですが、交通だけではなく電気、通信あらゆるインフラが混乱します。
中部空知で一番近い活火山は、洞爺湖、有珠岳付近です。６０年に一度は必ず噴火するので、おおよその被害の予測は付きます。一度噴火したときは、庭の草花の表面にうっすらと降灰がありました。その程度です。
東には大雪山がありますが、北海道は一般的に西風なので、距離的には有珠岳より近いのですが被害はほとんど考えにくいでしょう。
2013年06月26日
時代遅れのＰＵＥ：データセンターの効率指標として適切か？
久しぶりの更新です。
よくデータセンターのエネルギー利用率を表す指標として PUE (Power Usage Effectiveness)という単位が使われます。PUE が 2.0 であればコンピュータの稼動するエネルギーと同じ（トータルで２倍）の電気エネルギーを冷却などで使う、PUE 1.0 であればコンピュータ稼動の電力のみで、冷却や、事務所の電灯や冷房などのいわゆる「ホテルサービス」も一切電源を使わない、という事になります。ＰＵＥを指標とした場合、１．０を切る値というものは存在しません。
しかしコンピュータの設備というのは大変エネルギーを食うものなのです。
実際ＰＵＥが１．０に限りなく近くても、その分だけ明らかにエネルギーを消費しているわけです。
この逆の発想で考えられたのが DCiE（Data Center Infrastructure Efficiency）です。 PUE 1.0 の場合の DCiE は 100&, PUE 2.0 の場合は DCiE 50& (半分はＩＴ機器以外で使われている)ということになります。ICiE を使った指標であれば、データセンターの放熱によるコ・ジェネレーションシステムと合わせて１００％の数値を切ることもあり得るということになります。
他に WUE (Water Usage Effectiveness)というのがあり、「どの程度の水を冷却に使っているか」という指標のようです。
--
問題は「データセンター」という単体の設備でエネルギー効率を測定しても無駄なことなのです。
例えば、中部空知で研究されている「雪熱冷房」システムを使ったデータセンター構想は、莫大な量の「投げる雪」（日本の標準語では「捨てる雪」の意味）を使います。本来は「ごみ」に近い扱いなのですが、実際この「雪」を集めるという作業には多くの化石燃料とＣＯ２排出を伴います。もっとも、これらの冷房エネルギーも地元にゴッソリ降る「粉雪」を原料とした「地産地消」なので、それほど環境負荷が高いわけではありません。大間のマグロを築地に運ぶ程度のCO2排出量でしょう。
おそらく中部空知地区にデータセンターを作り、雪熱冷房を使った水冷却システムを導入すれば、PUE値は限りなく 1.0 に近づくでしょう。
PUE 1.0 以下という指標は現実にはあり得ません。コンピューターは水力でも風力でも動かないのです。電力が必要です。
コンピュータが発生した熱を回収して、例えば凍結した道路のロードヒーティングに使うとか、水路の凍結防止に使うとか。こうしたエネルギーの再循環を考えたとき、PUEという指標がいかに「狭義」で自己満足的な指標であるか、と感じます。データセンターという巨大なエネルギー源を使った、コ・ジェネーレーションシステムを構築した場合、実質、
あるいは、データセンター全体を動かすために、あるいは、ＤＣに通勤するオペレーターのエネルギー利用量など、どれだけの環境負荷が発生しているのか、といった指標が必要なのかも知れません。
石狩川流域をクラウド化、勝手に北海道に石狩川流域にデータセンターを誘致するプロジェクト
よくデータセンターのエネルギー利用率を表す指標として PUE (Power Usage Effectiveness)という単位が使われます。PUE が 2.0 であればコンピュータの稼動するエネルギーと同じ（トータルで２倍）の電気エネルギーを冷却などで使う、PUE 1.0 であればコンピュータ稼動の電力のみで、冷却や、事務所の電灯や冷房などのいわゆる「ホテルサービス」も一切電源を使わない、という事になります。ＰＵＥを指標とした場合、１．０を切る値というものは存在しません。
しかしコンピュータの設備というのは大変エネルギーを食うものなのです。
実際ＰＵＥが１．０に限りなく近くても、その分だけ明らかにエネルギーを消費しているわけです。
この逆の発想で考えられたのが DCiE（Data Center Infrastructure Efficiency）です。 PUE 1.0 の場合の DCiE は 100&, PUE 2.0 の場合は DCiE 50& (半分はＩＴ機器以外で使われている)ということになります。ICiE を使った指標であれば、データセンターの放熱によるコ・ジェネレーションシステムと合わせて１００％の数値を切ることもあり得るということになります。
他に WUE (Water Usage Effectiveness)というのがあり、「どの程度の水を冷却に使っているか」という指標のようです。
--
問題は「データセンター」という単体の設備でエネルギー効率を測定しても無駄なことなのです。
例えば、中部空知で研究されている「雪熱冷房」システムを使ったデータセンター構想は、莫大な量の「投げる雪」（日本の標準語では「捨てる雪」の意味）を使います。本来は「ごみ」に近い扱いなのですが、実際この「雪」を集めるという作業には多くの化石燃料とＣＯ２排出を伴います。もっとも、これらの冷房エネルギーも地元にゴッソリ降る「粉雪」を原料とした「地産地消」なので、それほど環境負荷が高いわけではありません。大間のマグロを築地に運ぶ程度のCO2排出量でしょう。
おそらく中部空知地区にデータセンターを作り、雪熱冷房を使った水冷却システムを導入すれば、PUE値は限りなく 1.0 に近づくでしょう。
PUE 1.0 以下という指標は現実にはあり得ません。コンピューターは水力でも風力でも動かないのです。電力が必要です。
コンピュータが発生した熱を回収して、例えば凍結した道路のロードヒーティングに使うとか、水路の凍結防止に使うとか。こうしたエネルギーの再循環を考えたとき、PUEという指標がいかに「狭義」で自己満足的な指標であるか、と感じます。データセンターという巨大なエネルギー源を使った、コ・ジェネーレーションシステムを構築した場合、実質、
あるいは、データセンター全体を動かすために、あるいは、ＤＣに通勤するオペレーターのエネルギー利用量など、どれだけの環境負荷が発生しているのか、といった指標が必要なのかも知れません。
石狩川流域をクラウド化、勝手に北海道に石狩川流域にデータセンターを誘致するプロジェクト
2013年01月31日
“ローグクラウド”実装が急増 管理部門の新しい頭痛の種
“ローグクラウド”実装が急増 管理部門の新しい頭痛の種
Rogue というのは、"一匹狼",はぐれ者"から転じて、"ローグクラウド" というのは「組織が管理できないクラウドサービスを利用する」という風に考えてよいのでしょうか。
上の記事では DropBox や SkyDrive などの例を挙げています。他にも「組織外とのプロジェクトをスムーズに行うため」に情報部門が関与できないところでクラウドサービスを利用している例がたくさんあるということです。ｌ例えば、ＳＮＳの機能を利用して、「何気なく社外」で「社外の関係者」などのステークスホルダーを集めてプロジェクトの管理を行ったりするケースは増えていると思います。極端な例を言えば、橋下大阪府知事が Twitter を使って発言するのも Rouge Cloud の一種かもしれません。本来、議会制民主主義が前提であれば「議会での発言」がオフィシャルなものとなるはずなのですね。
しかし、閉鎖した中での業務遂行というのは閉鎖社会であり、革新性を生み出すことは出来ません。社会の中にこのような「はぐれ者」が存在し、「はぐれ者」が他の社会と接触することで、情報や文化、経済に変化が訪れるわけです。
「面倒を見きれない奴」が何かをやらかすと脅威にもなり、時には革新的なアイディアを作り出すのですが、ほとんどの場合は組織にとって「脅威」と感じる人が多いのではないのかなと思います。
現代の情報技術では、ネットワークに繋がったパソコンのみならず、スマートフォンやタブレットでも無線キーボードを繋いでしまえば、ほとんど重要な仕事をこなすことができます。これはシステム管理者の制御の範囲外です。
ほとんどの利用者は善良であり、決して「悪意ある」利用者ばかりではないのでしょうが、お上（システム管理側）からすると「厄介な掟破り」として映ってしまうわけです。掟破りである以上、善良なユーザであっても何らかの形で抜け穴となり、脆弱性の入り口となる場合もあるわけです。
結局、セキュリティ論議というのは、「パスワードは複雑に」とか「これやっちゃいけない」と言った運用ポリシーによる「根性論」が中心です。根性をシステムとして組み込むことが困難だという事です。「武」（システム）によるマツリゴトではなく併せて「文」による善政（柔軟な運用ポリシー）も組織のトップには求められるのです。
石狩川流域をクラウド化、勝手に北海道に石狩川流域にデータセンターを誘致するプロジェクト
2012年11月30日
MBs と mbps の違い、転送速度と通信容量の表現
よく 8メガ ADSL とか 100メガ光などという言葉を使いますよね。
この単位の意味は何なんでしょう。
通常 100メガ と言う場合 100mbps (mega bit/second:ビット/秒)です。
しかし、ファイルをコピーするときに MB/s とあるのは MB/second (Mega Byte/second: バイト/秒)です。
さて、ここで数学に弱い私（皆さんも？）は混乱し始めるわけですね。
基本的に 1 Byte = 1bit × 8 です。
だから 100mbps の回線で送れるデータ転送量は 100 の8分の1 = 12.5 つまり 12.5MB/sec なのです。
さて、ここで更に私のような数字に弱いヒトはお怒りになるわけです。
「１００Ｍだから１００Ｍのデータを送るのに８秒もかかるのはおかしい！」
とても大事なことなのですが単位が違うのですね。
また、話がややこしいことに 1000 = 1K ではないのですね。実際に 2 の倍数なので 1024 byte = 1 Kbyte, 1M byte =(およそ) 1024 kbyte ということになります。
--
普通、通信規格 bit per second の場合 bps と小文字で書き、転送速度 Mega Byte/Sec は MBs などと大文字で表現することが一般的なのですが、必ずしも「ルール」ではないので「光１００メガ」などという広告表現がまかり通ってしまいます。
※実際 100Mbps の回線でデータを送っても途中の経路にある装置やディスクの速度によって 100Mbps で送受信、できる転送量は理論上 12.5MB/s なのですが実際の条件が良い環境でも現実には 8MB/s 程度のようです。
また、マンションのような集合住宅の場合、マンションの入り口は 100Mbps でも、中の100軒がみんな使えば１家庭あたり 1Mbps しか割り当てられません。同じことは無線回線にも言えることで、「４０Ｍの高速無線通信回線」と言っても、同じ周波数をみんなで利用するわけですから、うたい文句ほど性能は出ません。以外と利用者の少ない地方都市の方が性能が出るケースは当たり前なのですね。
最近のパソコンでは GBe (ギガビットイーサネット)の端子が付いているのでギガビット対応の HUB とケーブル同士で繋げると、一秒間に １０００分の８ つまり 125MB/s 程度のデータを理論上できることになります。ＤＶＤ一枚分のデータをわずか１分弱で送れるということです。
しかし実際は 70MB/s 以上の転送はできないようです。これはまだ録画したビデオのデータのような巨大なデータ（シーケンシャルデータ）の場合で「数Mb のデジカメデータ数百本」などランダムなデータを転送する場合は 10MB/s も出ればよいほうです。これは送信する側の性能と受信する側の性能が異なれば、当然遅い方に合わせて転送されます。
当然ＤＶＤに書かれたデータを読み出すにはＤＶＤの駆動装置がその速度に耐えられないわけです。
一般にデータセンターなどで使われるサーバー用ディスクは普通のパソコン用のものとは、一桁違う精度のものを使っています。性能はファミリーカーのエンジンとＦ１マシンほども違います。精度や回転数、耐久性は数倍、価格も一桁違います。もちろん全てがこのような高性能なものを使うわけではないのですが、アクセスの頻繁なデータベースシステムなどでは良く使われますし、逆に１日に一度もアクセスされれば良いような、このブログのようなデータはもっと安くて遅いディスクが使われます。
石狩川流域をシリコンバレーに、勝手なプロジェクト
この単位の意味は何なんでしょう。
通常 100メガ と言う場合 100mbps (mega bit/second:ビット/秒)です。
しかし、ファイルをコピーするときに MB/s とあるのは MB/second (Mega Byte/second: バイト/秒)です。
さて、ここで数学に弱い私（皆さんも？）は混乱し始めるわけですね。
基本的に 1 Byte = 1bit × 8 です。
だから 100mbps の回線で送れるデータ転送量は 100 の8分の1 = 12.5 つまり 12.5MB/sec なのです。
さて、ここで更に私のような数字に弱いヒトはお怒りになるわけです。
「１００Ｍだから１００Ｍのデータを送るのに８秒もかかるのはおかしい！」
とても大事なことなのですが単位が違うのですね。
また、話がややこしいことに 1000 = 1K ではないのですね。実際に 2 の倍数なので 1024 byte = 1 Kbyte, 1M byte =(およそ) 1024 kbyte ということになります。
--
普通、通信規格 bit per second の場合 bps と小文字で書き、転送速度 Mega Byte/Sec は MBs などと大文字で表現することが一般的なのですが、必ずしも「ルール」ではないので「光１００メガ」などという広告表現がまかり通ってしまいます。
※実際 100Mbps の回線でデータを送っても途中の経路にある装置やディスクの速度によって 100Mbps で送受信、できる転送量は理論上 12.5MB/s なのですが実際の条件が良い環境でも現実には 8MB/s 程度のようです。
また、マンションのような集合住宅の場合、マンションの入り口は 100Mbps でも、中の100軒がみんな使えば１家庭あたり 1Mbps しか割り当てられません。同じことは無線回線にも言えることで、「４０Ｍの高速無線通信回線」と言っても、同じ周波数をみんなで利用するわけですから、うたい文句ほど性能は出ません。以外と利用者の少ない地方都市の方が性能が出るケースは当たり前なのですね。
最近のパソコンでは GBe (ギガビットイーサネット)の端子が付いているのでギガビット対応の HUB とケーブル同士で繋げると、一秒間に １０００分の８ つまり 125MB/s 程度のデータを理論上できることになります。ＤＶＤ一枚分のデータをわずか１分弱で送れるということです。
しかし実際は 70MB/s 以上の転送はできないようです。これはまだ録画したビデオのデータのような巨大なデータ（シーケンシャルデータ）の場合で「数Mb のデジカメデータ数百本」などランダムなデータを転送する場合は 10MB/s も出ればよいほうです。これは送信する側の性能と受信する側の性能が異なれば、当然遅い方に合わせて転送されます。
当然ＤＶＤに書かれたデータを読み出すにはＤＶＤの駆動装置がその速度に耐えられないわけです。
一般にデータセンターなどで使われるサーバー用ディスクは普通のパソコン用のものとは、一桁違う精度のものを使っています。性能はファミリーカーのエンジンとＦ１マシンほども違います。精度や回転数、耐久性は数倍、価格も一桁違います。もちろん全てがこのような高性能なものを使うわけではないのですが、アクセスの頻繁なデータベースシステムなどでは良く使われますし、逆に１日に一度もアクセスされれば良いような、このブログのようなデータはもっと安くて遅いディスクが使われます。
石狩川流域をシリコンバレーに、勝手なプロジェクト
通信回線は「遅い早い」は誤り「細い太い」が正解
「もしもし、黒柳さーン」
「．．．はぃ、黒柳でぇーす」
よく７０年代にはやった衛星通信ごっこですね。
--
通信事業者はよく「早い遅い」という言葉を使いますが、これは大きな誤りだという話です。
地球の周囲は４万ｋｍ、静止衛星の高度は３．６万Ｋｍ、光は１秒で地球を７周半する。
この３つの数字で説明しましょう。
仮に久米さんが地球の裏側の黒柳さんに衛星電話をかけた場合、少なくとも３６０００Ｋｍの向こうの衛星まで飛んでいって、地球の反対側まで３６０００Ｋｍの距離を帰ってくるわけです。地球には半径があるので、まぁ仮に往復８００００Ｋｍとしましょう。
一方で、地球の周囲は４００００Ｋｍ。これはナポレオンがメートル法を決めたとき、地球の周囲の４００００分の１を１ｍとしようということで、誤差はありますが４００００Ｋｍジャストです。これで地球半周の通信にかかる距離は２００００Ｋｍですね。久米さんが黒柳さんの返事を待つ１／４で到達できることになります。
ところで、電気信号の早さはほとんど光と同じだといわれています。つまり一秒で地球７週半、３０万キロほど進むということです。
--
海外にデータセンターを設置するということは、この「光と同じ速度」が実はネックになります。それだけレスポンスに影響があるのですね。まだ、Evernote や iCloud のサービスのように「裏で同期してくれる」ようなサービスや、単なるバックアップ拠点であれば全く気にならないのですが、ファイルサーバーやイントラネットのサービスを海外に求めると、必然的に「なんだか反応が遅いなぁ」という気分になってしまいます。ほんの数ｍｓの差なのですが、「行って帰って」が多いアプリケーションサービスであれば致命的です。多くの事業者が首都圏にDCを建設して、首都圏の顧客にサービスをするのも、この「距離」が重要だということです。
逆にバックアップ用途であれば、どこにサーバーがあってもかまいません。
--
実は、信号の伝わる速度というのは、アナログモデムを使っても、デジタル回線を使っても同じなのですね。３０万キロというとほとんど月ほどの距離があるので、伝わる信号が「遅いなぁ」と思うのはデジタル回線でもアナログ回線でも同じなのです。
-周波数-
通信速度は変わりなくても周波数が上がると、単位時間の「通信容量」は増えます。
なぜ「早い、遅い」と感じるのでしょうか。それは「処理が終わるスピードが早い」からに他ありません。
ボーレートというものがありまして、インターネットがまだテスト段階だった８０年代は１２００ボーなどの数字でした。これは１秒間に１２００の信号を送れるということです。９０年代半ばのボーレートは１９２００ボーくらいの「周波数」になりました。今８ＭのＡＤＳＬで８００００ボーくらいになります。
速度が上がったのではなく「通信量」が増えて「早く処理が終わった」ため「早い、遅い」と感じるわけですね。
石狩平野シリコンバレー化勝手なプロジェクト
「．．．はぃ、黒柳でぇーす」
よく７０年代にはやった衛星通信ごっこですね。
--
通信事業者はよく「早い遅い」という言葉を使いますが、これは大きな誤りだという話です。
地球の周囲は４万ｋｍ、静止衛星の高度は３．６万Ｋｍ、光は１秒で地球を７周半する。
この３つの数字で説明しましょう。
仮に久米さんが地球の裏側の黒柳さんに衛星電話をかけた場合、少なくとも３６０００Ｋｍの向こうの衛星まで飛んでいって、地球の反対側まで３６０００Ｋｍの距離を帰ってくるわけです。地球には半径があるので、まぁ仮に往復８００００Ｋｍとしましょう。
一方で、地球の周囲は４００００Ｋｍ。これはナポレオンがメートル法を決めたとき、地球の周囲の４００００分の１を１ｍとしようということで、誤差はありますが４００００Ｋｍジャストです。これで地球半周の通信にかかる距離は２００００Ｋｍですね。久米さんが黒柳さんの返事を待つ１／４で到達できることになります。
ところで、電気信号の早さはほとんど光と同じだといわれています。つまり一秒で地球７週半、３０万キロほど進むということです。
--
海外にデータセンターを設置するということは、この「光と同じ速度」が実はネックになります。それだけレスポンスに影響があるのですね。まだ、Evernote や iCloud のサービスのように「裏で同期してくれる」ようなサービスや、単なるバックアップ拠点であれば全く気にならないのですが、ファイルサーバーやイントラネットのサービスを海外に求めると、必然的に「なんだか反応が遅いなぁ」という気分になってしまいます。ほんの数ｍｓの差なのですが、「行って帰って」が多いアプリケーションサービスであれば致命的です。多くの事業者が首都圏にDCを建設して、首都圏の顧客にサービスをするのも、この「距離」が重要だということです。
逆にバックアップ用途であれば、どこにサーバーがあってもかまいません。
--
実は、信号の伝わる速度というのは、アナログモデムを使っても、デジタル回線を使っても同じなのですね。３０万キロというとほとんど月ほどの距離があるので、伝わる信号が「遅いなぁ」と思うのはデジタル回線でもアナログ回線でも同じなのです。
-周波数-
通信速度は変わりなくても周波数が上がると、単位時間の「通信容量」は増えます。
なぜ「早い、遅い」と感じるのでしょうか。それは「処理が終わるスピードが早い」からに他ありません。
ボーレートというものがありまして、インターネットがまだテスト段階だった８０年代は１２００ボーなどの数字でした。これは１秒間に１２００の信号を送れるということです。９０年代半ばのボーレートは１９２００ボーくらいの「周波数」になりました。今８ＭのＡＤＳＬで８００００ボーくらいになります。
速度が上がったのではなく「通信量」が増えて「早く処理が終わった」ため「早い、遅い」と感じるわけですね。
石狩平野シリコンバレー化勝手なプロジェクト
2012年10月31日
データセンターと仮想化
仮想化は古くからある技術でもあり、新しい技術です。
古くは数億円するメインフレームではＣＰＵ時間を「借りる」ビジネスだったため「仮想化」は当たり前の技術だったようですが、ＰＣサーバーがコンピューターシステムの中心となってから、仮想化は再びコンピュータシステムでは「ごく当たり前」の技術として認識されています。
-仮想化を支えるハードウェアの進化-
仮想化は、ソフトウェア技術者にとっては夢の技術だったのですが、この技術を満たせるハードウェアが、ＩＢＭをはじめとするメインフレームの大型コンピューターの技術でした。しかし、私が初めてPC用の XEN という仮想化技術にトライしたときの驚きは、今までの概念を全て打ち壊すくらいのインパクトを感じました。
それまで「エミュレータ」というアプリケーションでの仮想化技術を見てきたエンジニアにとっては、実ハードウェアと同じ性能を出す仮想化という技術は大変なイノベーションを感じました。
今の時点では単に「仮想化」という場合、１台のコンピュータシステム上に複数のコンピュータシステムをカプセルの中で動作させる技術の一つでかなり広い意味に使われるようになりました。
-背景-
背景としては、コンピュータのハードウェアの進化がソフトウェアの進化より早いということが一つの理由です。またソフトウェアを利用する私たちがそれほどのハードウェアの性能を必要としないことも一つの理由です。
例えば、今安いパソコンをを３万円で買っても十分な記憶装置が付いてきます。２０万円も出すと、一般的な利用者では使いきれないほどの性能のコンピュータが手に入ります。
また、コンピュータの性能の一部分に「ＣＰＵクロック」というものがあります。これは「１秒間に何回計算できるか」の指標の一つですが、この数年３．５Ｇｈｚ程度を境に向上していません。その代わり、１つのＣＰＵに複数のＣＰＵ機能（コア）を詰め込み「１秒間の計算能力×ＣＰＵコア数」で性能を稼ぐようになりました。しかし、この複数のＣＰＵコアを使いきれるだけのソフトウェア（アプリケーション）はまだあまり多くはありません。
であれば、「使い切れない分」を複数の機能に分割してカプセル化して何台もの資源にしてしまえばよいではないか、ということが一つの理由です。
-さまざまな用途に最適化-
コンピュータを使ったインフラストラクチャにはさまざまな目的のものがあります。ＣＰＵの性能や記憶域をほとんど使わないが、その代わり通信機能に大きな負担がかかるもの、メモリや記憶域は沢山必要だがＣＰＵ能力が低くてもいいもの、記憶域は少なくてもよいが、ＣＰＵ性能が必要なもの。
それぞれの必要に応じてコンピュータを買い換えたり追加することは大変な手間と費用がかかり、また、多くの場合、それだけの性能が必要はないことが多いのです。また、実際にサービスを開始するまで、時間がかかるため、問題解決をするためのスタートアップが遅くなります。
また、それだけのコンピュータを動作させるための配線や電源、スペースも用意する必要があります。
そこで、「仮想化ホスト」コンピュータを１台準備すれば、その中に素早く新しいシステムを導入して、少ないコストで素早いサービス開始が行えることになります。また、１台のコンピュータに何十台ものコンピュータシステムを「仮想動作」させて、性能が低下するようであれば、別なコンピュータに資源をバラして各コンピュータにバランスよく計算資源や記憶領域を配置すれば、必要な性能が確保できます。
-短期間で利用開始、短期間で利用終了-
コンピュータの利用目的はさまざまです。電子メールやグループウェア、ファイルサービス、各種データベースのように数年、数十年にわたって利用する必要があるものもあれば、セールスプロモーションキャンペーン、選挙管理、人気のあるゲームやソフトウェアの配布、などのように数日から数ヶ月短期間稼動すればよいものもあります。
短期間稼動させるシステムのために、３年償却のコンピュータシステムを導入するのはあまりにも無駄です。そこで、データセンターに配置した「仮想子コンピュータ」の資源を短期間「借りる」ことになります。
-UNIX/Linuxが中心-
主なデータセンターで利用される仮想化技術はＵＮＩＸ／Ｌｉｎｕｘを中心とした XEN や KVM と呼ばれるオープンソース技術がよく使われます。ライセンス費用や制限が緩やかなことが最大の理由です。Windows を使うとそれぞれに厳しいライセンス費用が発生するため、コスト的に仮想化には向いていません。（たとえ使っていなくてもライセンス費用がかかります）それでも運用者側の理由（エンジニアの訓練費用）の面で Windows を仮想化に利用するケースはあります。また VMware 社が開発したソフトウェアは、大手企業のプライベートクラウドで運用されています。ライセンス料は非常に高価なので、一般的に低コストでサービスを提供するＤＣ事業者では人気がありません。
-仮想化でホットな話題-
今、仮想化の技術で一番ホットな話題は「仮想システムの適切な再配置」を行う技術です。今どのコンピューターが忙しく、どのコンピューターが暇であるかを判断し、「仮想コンピュータ」を切り替える技術です。
また、テストで作ったサービスに問題がなければ、クラウドサービスとして公開する場合にもこれらの技術が必要となります。
Openstack, Opencloud, Eucalyptus(ユーカリプタス)などのオープン製品や Novell 社の Platespin などがあります。特に Platespin Forge というハードウェアと一体化した製品（アプライアンス製品）は、通信さえ設定できてしまえば、遠隔地のバックアップセンターに災害対策拠点が作れるため、非常に人気が高いようです。また、通信経路を自動的に適切に配置するための「ネットワーク仮想化」という技術も注目されています。
ただし、仮想化システムを適切に分散配置するには、まだ「自動化」を完全にする技術で定評があるものが少ないのが実情です。
例えば「クラスタリング（複数の機器をまとめて１台のシステムに見せかける技術）」「フェイルオーバー（故障した機器を自動的に切り替える）」とか「ロードバランシング（付加分散）」といった技術があります。これは機器が壊れたり、高い負荷で応答が遅くなった場合に自動的に他の資源に割り当てる機能として、大型のシステムでは普通に利用されている技術なのですが、ロードバランシングを除いて、あまり進化が進んでいません（というより、一番ホットな話題だということです）
これは、インターネットという、「あまり信頼性のない」緩やかな通信経路を使って「データの１００％の信頼性」を確保することが難しいことにもよります。
雪熱冷房、勝手に北海道、空知にデータセンターを誘致するプロジェクト
古くは数億円するメインフレームではＣＰＵ時間を「借りる」ビジネスだったため「仮想化」は当たり前の技術だったようですが、ＰＣサーバーがコンピューターシステムの中心となってから、仮想化は再びコンピュータシステムでは「ごく当たり前」の技術として認識されています。
-仮想化を支えるハードウェアの進化-
仮想化は、ソフトウェア技術者にとっては夢の技術だったのですが、この技術を満たせるハードウェアが、ＩＢＭをはじめとするメインフレームの大型コンピューターの技術でした。しかし、私が初めてPC用の XEN という仮想化技術にトライしたときの驚きは、今までの概念を全て打ち壊すくらいのインパクトを感じました。
それまで「エミュレータ」というアプリケーションでの仮想化技術を見てきたエンジニアにとっては、実ハードウェアと同じ性能を出す仮想化という技術は大変なイノベーションを感じました。
今の時点では単に「仮想化」という場合、１台のコンピュータシステム上に複数のコンピュータシステムをカプセルの中で動作させる技術の一つでかなり広い意味に使われるようになりました。
-背景-
背景としては、コンピュータのハードウェアの進化がソフトウェアの進化より早いということが一つの理由です。またソフトウェアを利用する私たちがそれほどのハードウェアの性能を必要としないことも一つの理由です。
例えば、今安いパソコンをを３万円で買っても十分な記憶装置が付いてきます。２０万円も出すと、一般的な利用者では使いきれないほどの性能のコンピュータが手に入ります。
また、コンピュータの性能の一部分に「ＣＰＵクロック」というものがあります。これは「１秒間に何回計算できるか」の指標の一つですが、この数年３．５Ｇｈｚ程度を境に向上していません。その代わり、１つのＣＰＵに複数のＣＰＵ機能（コア）を詰め込み「１秒間の計算能力×ＣＰＵコア数」で性能を稼ぐようになりました。しかし、この複数のＣＰＵコアを使いきれるだけのソフトウェア（アプリケーション）はまだあまり多くはありません。
であれば、「使い切れない分」を複数の機能に分割してカプセル化して何台もの資源にしてしまえばよいではないか、ということが一つの理由です。
-さまざまな用途に最適化-
コンピュータを使ったインフラストラクチャにはさまざまな目的のものがあります。ＣＰＵの性能や記憶域をほとんど使わないが、その代わり通信機能に大きな負担がかかるもの、メモリや記憶域は沢山必要だがＣＰＵ能力が低くてもいいもの、記憶域は少なくてもよいが、ＣＰＵ性能が必要なもの。
それぞれの必要に応じてコンピュータを買い換えたり追加することは大変な手間と費用がかかり、また、多くの場合、それだけの性能が必要はないことが多いのです。また、実際にサービスを開始するまで、時間がかかるため、問題解決をするためのスタートアップが遅くなります。
また、それだけのコンピュータを動作させるための配線や電源、スペースも用意する必要があります。
そこで、「仮想化ホスト」コンピュータを１台準備すれば、その中に素早く新しいシステムを導入して、少ないコストで素早いサービス開始が行えることになります。また、１台のコンピュータに何十台ものコンピュータシステムを「仮想動作」させて、性能が低下するようであれば、別なコンピュータに資源をバラして各コンピュータにバランスよく計算資源や記憶領域を配置すれば、必要な性能が確保できます。
-短期間で利用開始、短期間で利用終了-
コンピュータの利用目的はさまざまです。電子メールやグループウェア、ファイルサービス、各種データベースのように数年、数十年にわたって利用する必要があるものもあれば、セールスプロモーションキャンペーン、選挙管理、人気のあるゲームやソフトウェアの配布、などのように数日から数ヶ月短期間稼動すればよいものもあります。
短期間稼動させるシステムのために、３年償却のコンピュータシステムを導入するのはあまりにも無駄です。そこで、データセンターに配置した「仮想子コンピュータ」の資源を短期間「借りる」ことになります。
-UNIX/Linuxが中心-
主なデータセンターで利用される仮想化技術はＵＮＩＸ／Ｌｉｎｕｘを中心とした XEN や KVM と呼ばれるオープンソース技術がよく使われます。ライセンス費用や制限が緩やかなことが最大の理由です。Windows を使うとそれぞれに厳しいライセンス費用が発生するため、コスト的に仮想化には向いていません。（たとえ使っていなくてもライセンス費用がかかります）それでも運用者側の理由（エンジニアの訓練費用）の面で Windows を仮想化に利用するケースはあります。また VMware 社が開発したソフトウェアは、大手企業のプライベートクラウドで運用されています。ライセンス料は非常に高価なので、一般的に低コストでサービスを提供するＤＣ事業者では人気がありません。
-仮想化でホットな話題-
今、仮想化の技術で一番ホットな話題は「仮想システムの適切な再配置」を行う技術です。今どのコンピューターが忙しく、どのコンピューターが暇であるかを判断し、「仮想コンピュータ」を切り替える技術です。
また、テストで作ったサービスに問題がなければ、クラウドサービスとして公開する場合にもこれらの技術が必要となります。
Openstack, Opencloud, Eucalyptus(ユーカリプタス)などのオープン製品や Novell 社の Platespin などがあります。特に Platespin Forge というハードウェアと一体化した製品（アプライアンス製品）は、通信さえ設定できてしまえば、遠隔地のバックアップセンターに災害対策拠点が作れるため、非常に人気が高いようです。また、通信経路を自動的に適切に配置するための「ネットワーク仮想化」という技術も注目されています。
ただし、仮想化システムを適切に分散配置するには、まだ「自動化」を完全にする技術で定評があるものが少ないのが実情です。
例えば「クラスタリング（複数の機器をまとめて１台のシステムに見せかける技術）」「フェイルオーバー（故障した機器を自動的に切り替える）」とか「ロードバランシング（付加分散）」といった技術があります。これは機器が壊れたり、高い負荷で応答が遅くなった場合に自動的に他の資源に割り当てる機能として、大型のシステムでは普通に利用されている技術なのですが、ロードバランシングを除いて、あまり進化が進んでいません（というより、一番ホットな話題だということです）
これは、インターネットという、「あまり信頼性のない」緩やかな通信経路を使って「データの１００％の信頼性」を確保することが難しいことにもよります。
雪熱冷房、勝手に北海道、空知にデータセンターを誘致するプロジェクト
2012年10月25日
ＳＬＡ(Service Level Agreement)とは
情報用語やデータセンターのサービス用語でＳＬＡ(Service Level Agreement)という言葉があります。
簡単に言うと「これだけの機能と性能(Service Level)を規定して、できない場合はたとえばその分値段を安くするなどの措置をとりますよ」という「合意(Agreement)」のことです。重要なのは「合意」であり「保障」ではない点です。
実際、さくらインターネット石狩データセンターでは、サービス開始時にありがちな初期不良でいくつかの有料サービスのうち無料試用期間を延ばすなどの良心的な処置を取っています。
「ADSL 12M ベストエフォート」などというサービスであれば「繋がれば良い」程度のサービスを保証しているわけです。一方３６５日１００Ｍｂｐｓ９９％保障というサービスレベルであれば、少なくとも「拠点」とデータセンター間との通信容量は９９Ｍｂｐｓのレベルを毎日保障しなくてはなりません。あるいは９９％の時間帯で通信速度を保障しなければならないということになります。
私は通信系は弱いのですが、サーバーの稼働時間９９％というのは１００時間のうち９９時間の稼動保障をするということになるわけですから大体５日に１時間くらいはダウンしても構わないということに（凄い甘い数字ですね）なります。製造業で９９％の稼働率であれば凄い数字だと言えますが、情報システムではひどく甘い数字です。
実際に９９．９％の稼動保障であれば、１年半に１時間程度のダウンは大目に見てくださいね、ということになります。この時間帯に機器を更新したり新しいシステムに切り替える作業などが許されます。実際には「障害」に対するサービスレベルの規定であり、機器やサービス機能の向上に伴うシステムダウンはまた別の問題です。大手のクラウド事業者であっても、「計画的な機器停止」というアナウンスは良くあることです。
当たり前ですがＳＬＡのレベルを上げるためには人的コスト、機器的なコストは上がります。例えば２４＊３６５日のＳＬを保障するのであれば、３交代制で人を貼り付ける必要がありますし、定期的なメンテナンスが必要な機器の二重化、冗長化が必要です。事業者側はそのためのコストを下げるために「量の論理」でコスト削減を考えなければなりません。
通信系でも１００Ｍのサービスを１Ｇのサービスに切り替えるという場合であれば、その間は通信が途切れるわけですから、これもＳＬの一部とは言いがたいのではないのかな、と思います。
多くの場合、事業者側にはＳＬＡが守れなければ「その分サービスしまっせ」という条項はあっても、サービスが途切れたことにより発生した顧客の直接的な「損害」は保障できない（しない）のが普通です。顧客が毎月１００万円のサービスを使って毎月１００億のビジネスをやっていて、サービスの障害によって１億の損害が出ても、事業者側としては毎月１００万円のサービスしか提供していませんから、その契約の中にビジネスの保障までは盛り込むのは無理というものです。そのような損害まで補償しろ、というのであれば、事業者ではなく、顧客は自前でサービスを構築すべきでしょう。
よくスペースシャトルで「シックスナイン」という言葉があります。９９．９９９９％という９が６つ並んだ数字を安全性として定義した言葉ですが、これも４０００日に一度は事故が起きるという「危険性」があるわけですね。スペースシャトルは３０年間の運用中に２度大きな事故を起したわけですが、その１３０回あまりのミッションで２度の事故なのか３０年あまりの運用機関における２度の事故と解釈するのかで大きな違いがあります。回数なのか時間なのか、品質なのかによってＳＬの定義は違うものになります。
また、障害の内容によっても詳細に規定されなければなりません。例えば生産や流通、決済に関する処理は営業中に確実に行われなければなりませんが、電子メールやグループウェア、定期的なバッチ処理の一部などは、ＳＬが多少落ちても大きな問題にならないケースもあります（もちろん放置すべき問題ではありません）
サービスレベルというのは、データセンターの事業者と顧客の間にあるだけではなく、企業の情報部門とエンドユーザ部門（経営側）にも規定している場合があります。このようなケースでは、サービスレベルはかなり下げています。例えば「営業時間、営業日は９９％の稼動を保障するが、営業時間では停止することもある」ということですね。実際に企業内部のシステム部門では２４＊３６５日のＳＬは保障できるだけの人的リソース、機器的リソースがないため、事前に計画された深夜や休日のメンテナンス、停止ということは頻繁に行われます。
また、組織内でのＳＬＡには「ペナルティ」という規定はほとんどない（あるところもあるかもしれませんが）ことが普通です。システム運用部門と利用者部門との間での「努力目標」として定義され、「実績主義」の中で評価されます。そういう意味ではペナルティがあるかもしれませんね。
実際に銀行のＡＴＭなどは深夜は稼動していません。深夜に「締めの処理」（バッチ処理）が必要だからです。バッチ処理をしながらも取引が継続できるようなシステムにするには莫大なシステムの再設計が必要となります。
そのようなケースも加味するとＳＬＡというのはさまざまなケースが考えられると言うことになります。
--
サービスのスタートアップにおいては、ＳＬ（サービスレベル）は甘い数字で提示すべきものだと思います。例えば、２４時間のうち、朝の９時から夜の９時までは９９％の稼動を保障するが夜９時から朝９時までは稼動を保障しないとかのＳＬから初めて、スタートアップの投資を低く抑えながらサービスを開始することもあります。今では大企業となった Google にしても最初はそのレベルで開始せざるを得なかったと推測するのは容易です。
まずは身の丈にあったＳＬから初めることです。
北海道にもデータセンターを誘致しようという勝手なプロジェクト
簡単に言うと「これだけの機能と性能(Service Level)を規定して、できない場合はたとえばその分値段を安くするなどの措置をとりますよ」という「合意(Agreement)」のことです。重要なのは「合意」であり「保障」ではない点です。
実際、さくらインターネット石狩データセンターでは、サービス開始時にありがちな初期不良でいくつかの有料サービスのうち無料試用期間を延ばすなどの良心的な処置を取っています。
「ADSL 12M ベストエフォート」などというサービスであれば「繋がれば良い」程度のサービスを保証しているわけです。一方３６５日１００Ｍｂｐｓ９９％保障というサービスレベルであれば、少なくとも「拠点」とデータセンター間との通信容量は９９Ｍｂｐｓのレベルを毎日保障しなくてはなりません。あるいは９９％の時間帯で通信速度を保障しなければならないということになります。
私は通信系は弱いのですが、サーバーの稼働時間９９％というのは１００時間のうち９９時間の稼動保障をするということになるわけですから大体５日に１時間くらいはダウンしても構わないということに（凄い甘い数字ですね）なります。製造業で９９％の稼働率であれば凄い数字だと言えますが、情報システムではひどく甘い数字です。
実際に９９．９％の稼動保障であれば、１年半に１時間程度のダウンは大目に見てくださいね、ということになります。この時間帯に機器を更新したり新しいシステムに切り替える作業などが許されます。実際には「障害」に対するサービスレベルの規定であり、機器やサービス機能の向上に伴うシステムダウンはまた別の問題です。大手のクラウド事業者であっても、「計画的な機器停止」というアナウンスは良くあることです。
当たり前ですがＳＬＡのレベルを上げるためには人的コスト、機器的なコストは上がります。例えば２４＊３６５日のＳＬを保障するのであれば、３交代制で人を貼り付ける必要がありますし、定期的なメンテナンスが必要な機器の二重化、冗長化が必要です。事業者側はそのためのコストを下げるために「量の論理」でコスト削減を考えなければなりません。
通信系でも１００Ｍのサービスを１Ｇのサービスに切り替えるという場合であれば、その間は通信が途切れるわけですから、これもＳＬの一部とは言いがたいのではないのかな、と思います。
多くの場合、事業者側にはＳＬＡが守れなければ「その分サービスしまっせ」という条項はあっても、サービスが途切れたことにより発生した顧客の直接的な「損害」は保障できない（しない）のが普通です。顧客が毎月１００万円のサービスを使って毎月１００億のビジネスをやっていて、サービスの障害によって１億の損害が出ても、事業者側としては毎月１００万円のサービスしか提供していませんから、その契約の中にビジネスの保障までは盛り込むのは無理というものです。そのような損害まで補償しろ、というのであれば、事業者ではなく、顧客は自前でサービスを構築すべきでしょう。
よくスペースシャトルで「シックスナイン」という言葉があります。９９．９９９９％という９が６つ並んだ数字を安全性として定義した言葉ですが、これも４０００日に一度は事故が起きるという「危険性」があるわけですね。スペースシャトルは３０年間の運用中に２度大きな事故を起したわけですが、その１３０回あまりのミッションで２度の事故なのか３０年あまりの運用機関における２度の事故と解釈するのかで大きな違いがあります。回数なのか時間なのか、品質なのかによってＳＬの定義は違うものになります。
また、障害の内容によっても詳細に規定されなければなりません。例えば生産や流通、決済に関する処理は営業中に確実に行われなければなりませんが、電子メールやグループウェア、定期的なバッチ処理の一部などは、ＳＬが多少落ちても大きな問題にならないケースもあります（もちろん放置すべき問題ではありません）
サービスレベルというのは、データセンターの事業者と顧客の間にあるだけではなく、企業の情報部門とエンドユーザ部門（経営側）にも規定している場合があります。このようなケースでは、サービスレベルはかなり下げています。例えば「営業時間、営業日は９９％の稼動を保障するが、営業時間では停止することもある」ということですね。実際に企業内部のシステム部門では２４＊３６５日のＳＬは保障できるだけの人的リソース、機器的リソースがないため、事前に計画された深夜や休日のメンテナンス、停止ということは頻繁に行われます。
また、組織内でのＳＬＡには「ペナルティ」という規定はほとんどない（あるところもあるかもしれませんが）ことが普通です。システム運用部門と利用者部門との間での「努力目標」として定義され、「実績主義」の中で評価されます。そういう意味ではペナルティがあるかもしれませんね。
実際に銀行のＡＴＭなどは深夜は稼動していません。深夜に「締めの処理」（バッチ処理）が必要だからです。バッチ処理をしながらも取引が継続できるようなシステムにするには莫大なシステムの再設計が必要となります。
そのようなケースも加味するとＳＬＡというのはさまざまなケースが考えられると言うことになります。
--
サービスのスタートアップにおいては、ＳＬ（サービスレベル）は甘い数字で提示すべきものだと思います。例えば、２４時間のうち、朝の９時から夜の９時までは９９％の稼動を保障するが夜９時から朝９時までは稼動を保障しないとかのＳＬから初めて、スタートアップの投資を低く抑えながらサービスを開始することもあります。今では大企業となった Google にしても最初はそのレベルで開始せざるを得なかったと推測するのは容易です。
まずは身の丈にあったＳＬから初めることです。
北海道にもデータセンターを誘致しようという勝手なプロジェクト
2012年10月18日
Google のデータセンターが公開されました。
Google のデータセンターが公開されました。
http://www.google.com/about/datacenters/gallery/#/
もちろん丸秘の部分は公開されていないのでしょうが、綺麗に色分けされた配線、水冷パイプ、ポンプ施設や非常用電源など、情報産業が一つの「設備産業」となっていることが良くわかります。
北米ののんびりとした田園風景にあるこの施設は石狩川流域の風景にも似ています。
People を見ると、決してITエンジニアだけの世界じゃない、装置全体をメンテナンスするためにさまざまな人々が働く場所であるということがよくわかります。
石狩川流域にデータセンターを誘致する勝手なプロジェクト
http://www.google.com/about/datacenters/gallery/#/
もちろん丸秘の部分は公開されていないのでしょうが、綺麗に色分けされた配線、水冷パイプ、ポンプ施設や非常用電源など、情報産業が一つの「設備産業」となっていることが良くわかります。
北米ののんびりとした田園風景にあるこの施設は石狩川流域の風景にも似ています。
People を見ると、決してITエンジニアだけの世界じゃない、装置全体をメンテナンスするためにさまざまな人々が働く場所であるということがよくわかります。
石狩川流域にデータセンターを誘致する勝手なプロジェクト
