ハイブリッドクラウド時代必修 ITインフラの基礎知識 · 2020-02-13 ·...

ハイブリッドクラウド時代必修ITインフラの基礎知識

111111

111

0000000

1

0000

000

111

0

0000000

000

1

0

1

1

0

0

1

0

0

1

1

0

0

0

1

000000

00

111

000

0

11

1

11110000000000000000000000000000000000000000011111111111111000000000000000000000111111111111111111111000000000000000000000000000000000011111111111111111111111

0

00

1

0

0

1

1111111111

11111111111111111111111111

000000000クラウディアン株式会社〒 150-0002 東京都渋谷区2-11-6 ラウンドクロス渋谷6F電話：03-6418-6466 Email：[email protected]

Cloudian、Cloudianロゴ、HyperStoreは、Cloudian Inc&KKの登録商標か商標です。他の商標は、すべて各所有者の資産です。

インプレス「IT Leadersオンライン」より転載

2

ビジネスが求める“アジャイル”に合わせITインフラは変革を遂げた………………… 4

次世代ITインフラへの鍵となる「仮想化＋分散処理」… ……………………………… 7

次世代ITインフラはソフトウェアが定義する… ………………………………… 10

システム拡張はスケールアップとスケールアウトで… ………………………… 13

セルフサービスが経営スピードを高め情報リスクを抑える………………………… 16

アプリケーション活用の鍵を握るAPI………………………………………………… 18

エコシステムが実現するハイブリッドクラウド… …………………………………… 21

リソースの管理効率を高めるマルチテナント………………………………………… 24

ハードが壊れてもデータを保護できるITインフラに… …………………………… 27

DR／BCにはマルチデータセンターが不可欠……………………………………… 30

ハードウェアが壊れても“Always…On”でサービスを止めない…………………… 33

自動階層化（Auto-Tiering）で次世代ITインフラにスムーズに移行する… ……… 36

ハイブリッドクラウドはオンプレミスもクラウド型に変革…………………………… 39

第1回

第2回

第3回

第4回

第5回

第6回

第7回

第8回

第9回

第10回

第11回

第12回

第13回

CONTENTS

3

本橋信也（もとはし・しんや）クラウディアン…取締役COO。主に経営戦略や、計画、企画分野において約30年の経験を有する。現在は、日本と米国シリコンバレーとを開発拠点とするクラウディアンにおいて、同社の主力製品であるソフトウェアデファインドのスケールアウト型オブジェクトストレージ製品「CLOUDIAN…HyperStore」の事業開発・展開に注力している。著書に『NOSQLの基礎知識（ビッグデータを活かすデータベース技術）』（リックテレコム刊）がある。他にも、多数の専門誌にてリーダーや企画担当者に向けた解説記事を執筆している。

筆者プロフィール

ビッグデータ／クラウドの時代になり、企

業の情報システム像は大きな変革期を迎

え、ハイブリッドクラウド化が進んでいる。

しかし、ハイブリッド化の恩恵を最大限に享

受するためには、オンプレミスなシステム

環境においても次世代化、すなわちクラウ

ドと同等の進化を遂げなければならない。

本書では、（1）計算処理を担うサーバー、

（2）データを保存するストレージ、（3）デー

タをやり取りするネットワークの 3要素から

なるITインフラ（IT Infrastructure）を対

象に、次世代 ITインフラに求められる要件

の基本的な考え方を紹介していく。

4

第1回ビジネスが求める“アジャイル”に合わせITインフラは変革を遂げた今日、私たちが活用するアプリケーションや ITサービスのすべてが、インターネットや社内ネットワークへの接続を前提に作られています。さらに今後は、ビッグデータ活用や IoT（Internet of Things:モノのインターネット）への取り組みが、特別なことではなくなってくるでしょう。そこでは、米 Amazon.comや米 Googleに代表されるように、クラウドコンピューティングを前提にしたITインフラ（IT Infrastructure）の構築が求められてきます。なぜ、既存のITインフラでは次のステージへと進めないのでしょうか。

　最初にITインフラ（IT…Infrastructure）の歴史を少し振り返ってみましょう。　企業におけるコンピューター利用が始まってから1980年代までは、メインフレームを中心とした集中処理の時代でした。90年代に入り、ITインフラはクライアント／サーバーの時代を迎えます。ただ、ソフトウェアやツール、アプリケーションなどは、サーバーやストレージなどのハードウェアベンダーごとに用意され、採用したハードウェアベンダー単位にシステムがサイロ化する例が一般的でした。

仮想化がITインフラの姿を変えていった

　2000年の後半になると、サーバーの仮想化が始まります。物理サーバー上にハイパーバイザーが構築した仮想的なサーバー（VM：Virtual…Machine）を利

用するようになったのです（図 1）。物理サーバーとしては、米Intel製プロセッサの「x86」アーキテクチャーを採用した機種が多用され、これが現在に続くITインフラの主役になっています。　仮想化により、物理サーバー単位のサイロ化からは逃れたものの、仮想サーバー単位のサイロ化が起こっています。　仮想サーバー時代を迎え、多数の仮想サーバー資源を貯めて（プールして）、個々の仮想サーバーへの割当や構築を自動化できるソフトウェア製品も登場してきます。仮想サーバーのプロビジョニングや管理など、従来はITシステム担当者が時間をかけて行っていた作業をエンドユーザー自らが短時間で簡単に利用できるITインフラの構築が可能になってきたのです。　この仮想化の流れは、サーバーに続き、ストレージとネットワークにも広がっています。ハードウェアには汎用サー

バーを使い、ソフトウェアでストレージ装置やネットワーク装置の機能を実現する方法です。「So f tw a r e … D e f i n e d…Storage（SDS）」や「Software…Defined…Network（SDN）」と呼ばれています。　最近では、サーバーやストレージ、ネットワークなどITインフラのすべてをソフトウェアで構築し運用することが可能になり、そこに向けたテクノロジーや製品を開発・提供する動きが高まっています。こうしたITインフラは、「SDI（Software…Defined…Infrastructure：ソフトウェア定義による基盤）」とも呼ばれます。

ビッグデータがレガシーなITインフラの限界を表面化

　こうした ITインフラ自体のテクノロジーやアーキテクチャーの変化と並行して、アプリケーション領域で起こった大きな変化がビッグデータです。ITインフラ上に蓄積されたデータを分析し、そこから得た知見に基づいて既存ビジネスを加速したり次のビジネスを生み出したりする“データ駆動型ビジネス”への関心が一気に高まりました。　ビッグデータという言葉の定義はあいまいですが、ここでは「多種多様（Variety）な、大量データ（Volume）を、迅速に（Velocity）、経済的に（Value）処理すること」と定義しておきます。問題は、これらを満たすためには、レガシーなITインフラでは困難だという点です。　従来、レガシーな ITインフラが扱うデータの多くは、リレーショナルデータ図1：仮想サーバーのイメージ

仮想サーバー（VM）

ハイパーバイザー

物理サーバー（x86アーキテクチャー）

出所：クラウディアン





5

ベース（RDB）が処理しやすい構造に整形され活用されてきました。処理対象になるデータを厳選しているため、データ量は大きな問題にはなりませんでした。　しかし、ビッグデータの考え方が広がり、大量の記録データである「ログ」など、従来は処理の対象にならなかったデータからも、分析によって新たな価値が生み出させることへの理解が高まりました。結果、ログに代表される非構造で多種多様な大量データに対応できるITインフラが必要になってくるのです。　ビッグデータ分析は、ビジネスでの活用が目的です。大量のデータ処理とはいえ、常にスピードが求められます。当然のことながら、データ量の増大に対しITコストが直線的に増えることが許されるはずはありません。経済性も重要な要件になります。ビッグデータに対応することは、レガシーなITインフラにすれば“想定外”だったと言えるでしょう。

クラウドの台頭がITサービスの本質を変えた

　もう1つ、ITの利用者に大きな影響を与えているのがクラウドサービスの登場です。「IaaS（Infrastructure…as…a…Service）」は、クラウドでITインフラを提供するサービスです。多くのクラウドサービス事業者が、サーバー、ストレージ、ネットワークというITインフラの3要素をサービスとして提供しています。　クラウドサービスが提供する価値は大きく、次の3つです。

● 利用した分だけの低廉な料金 ● 容量制限のない拡張性 ● 使いたい時にすぐに使える俊敏性

　以前からインターネット経由で、データセンター内に設置されたサーバーやストレージを貸し出すサービスは提供されてきました。ときおり、こうした既存サービスもクラウドと総称されていますが、これらはレガシーなITインフラをベースにしており、クラウドサービスとは本質が異なります。なぜなら、既存のネット型サービスは、データセンター内に設置された物理装置を貸し出しているにすぎないからです（図2）。　既存のサービスでは、サービス提供者は、物理装置に投資しているため、投資回収リスクを避けるために“定額”によるサービス提供が一般的です。物理装置ですので“容量制限”があります。サービス

提供者が物理装置を調達・設置する手間などもあるため、例えば「サービス開始まで3カ月」といったように、利用開始までに“時間がかかる”ことになります。これらは、クラウドの3大価値を満たしていません。　クラウドサービスであれば当たり前に提供できていることが、レガシーなITインフラでは実現できない。利便性の差に対する利用者側のフラストレーションは高まる一方でしょう。

「仮想化＋分散処理」に向かう次世代ITインフラ

　ところで、仮想化されたITインフラをクラウドと呼ぶことがあります。既存のネットワーク型サービスにおいても仮想化されたITインフラを利用しているケースは存在します。

図2：ホスティングとクラウドサービスの違い


企業A 企業B

物理ハードウェアを割当

ホスティング（設備の預り・貸出）

クラウドサービス（リソースの提供）

企業C 企業A 企業B

物理ハードウェアを仮想リソースに分割して提供

企業C

インターネット

6

　しかし、クラウドコンピューティングで重要なことは、分散処理にあります（図3）。いつでもサービスが利用できる可用性と、データの成長に合わせてシステム容量を増加できる拡張性、無料を含む低価格なサービスを実現できる経済性を同時に両立させようとすれば、巨大なサーバーによる集中処理では対応し切れません。　米Amazon.comや米Google、米Facebookなどのクラウドサービス事業者は、経済的な汎用サーバーを数千台、数万台といった単位で大量に導入し、同時並行的に分散して処理する分散処理技術を活用しています。　つまり、クラウドコンピューティングを実現しているITインフラにおいては、「仮想化＋分散処理」が重要な構成要素になっているのです。

企業のITインフラもクラウド同等になることが求められる

　上述したように、利用者側のニーズは、「ビッグデータ処理に対応すると同時に、クラウドサービスと同等のIT環境を使いたい」という方向がますます強くなっていくことでしょう。結果、企業が構築・運用するITインフラもクラウドコンピューティングのためのITインフラに変革せざるを得ません。　クラウド型のITインフラは、「仮想化＋分散処理」をコアテクノロジーに、様々な要件を満たす必要があります。主な要件を列挙してみましょう。

● ソフトウェア定義（ S o f t w a r e Defined）：汎用サーバーを使い様々な機能をソフトウェアで構築する

● スケールアウト（Scale Out）：物理装置の置換ではなく、追加によりシステム全体を拡張する

● セルフサービス（Self service）：エンドユーザー自身が ITインフラ資源を設定する

● API（Application Programming Interface）：アプリケーションにプログラミングインタフェースを提供する

● エコシステム（EcoSystem）：ITインフラを利用できるアプリケーションの豊富さを確保する

● マルチテナント（Multi Tenant）：多数の利用者がそれぞれ独立したITインフラ資源を共有する

● 堅牢なデータ保護（Robust Data

Protection）：1台の物理装置ではなくITインフラ全体でデータ保護を管理する

● マルチデータセンター（Multi Data Center）：複数データセンター間にITインフラを構築・運用する

● オールウェイズオン（Always On）：サービスを停止することなく、いつでも使えるようにする

● ティアリング（Tiering）：頻繁に使うデータと、そうでないデータを効率的に階層化する

● ハイブリッド（Hybrid）：オンプレミスとクラウドのITインフラを連携する

　次回から、これらの次世代ITインフラの要件のそれぞれについて順番に解説していきます。次回はコア部分の「仮想化＋分散処理」について解説します。

図3：分散処理の概念…


サーバーサーバーサーバーサーバーサーバーサーバー

複数のサーバーに分散して計算処理

複数のサーバーに割り当て

ビッグデータ


7

ビッグデータ活用や IoT（Internet of Things:モノのインターネット）への取り組みはもはや ITマターではなく、ビジネスマターになりました。そこでは第1回で指摘したように、クラウドコンピューティングを前提にしたITインフラ（IT Infrastructure）の構築が企業においても求められます。今回は、クラウド型の ITインフラのコアテクノロジーである「仮想化＋分散処理」について説明します。

次世代ITインフラへの鍵となる「仮想化＋分散処理」第2回

次世代ITインフラでは利用者は物理的なリソースを意識しない

　そもそも、仮想とは「本来ないものを存在するかのように見せる」ことです。現在、「仮想化」という用語は種々の文脈で使われています。それを実現するための技術も1つではなく、適用領域によって様々です。　ネットワークであれば、物理的なネットワーク通信装置を隠ぺいしながら通信経路を柔軟に制御したり、多数の利用者が共有しているにもかかわらず特定の利用者が専有しているかのように通信経路を提供したりするのが仮想化です。ストレージであれば、単体のストレージ装置の物理構成を隠ぺいしたり、物理的な制約を拡張して見せたり、逆に複数のストレージ装置を統合して、あたかも1つの巨大なストレージ空間のように見せることが仮想化です。　このように、仮想化を特定の技術で定義することは難しいのです。ですが、クラウド型のITインフラにおいては非常に重要な意味を持ちます。物理リソースの制約があると、多種多様な大量のデータを

柔軟に処理し、かつ低コストのサービスとして提供することが難しいからです。　一方の分散処理も、仮想化同様にクラウド型の ITインフラでは非常に重要です。例えば、インターネットは分散処理の代表選手と言えます。世界中を飛び交う通信を、中央の交換装置で集中処理するのではなく、スイッチやルーター群が分散して処理しています。　コンピューティングにおける分散処理は、数十台、数百台といった汎用的なサーバーを並列に稼働させ、それらに計算処理を分散することで、1台の大型

サーバーで処理するよりも速く、大量のデータ処理を可能にするものです。　従来は、多数のサーバーを同時に制御するためには複雑で特別な技術が必要だと考えられ、特定分野での利用が中心でした。それも今は、OSS（Open…Source…Software）の「Apache…Hadoop」などの登場により、身近な技術になってきています。　以下では、ITインフラの主要リソースである、サーバー、ストレージ、ネットワークの3要素における仮想化を考えてみます。

サーバーにおける仮想化

　サーバーの仮想化では、物理的なコンピューターリソースを、システムやアプリケーション、利用者から隠ぺいし、仮想的なリソースとして提供します。このメリットは、いくつもありますが、その最大の

仮想化（Virtualization）の定義：コンピュータのリソースを抽象化すること。CPUやメモリー、ディスク、ネットワークインタフェースなどといった物理的な特性を隠ぺいし、本来は別の形で存在しているものを、利用者が求める形に見せること

分散処理（Distributed Processing）の定義：ネットワークで接続された複数の装置に仕事を分担させて、1つの巨大な装置で処理するのと同様の結果を得るための考え方や、その仕組み

図1：物理サーバー…vs…仮想サーバー


物理サーバーを利用仮想サーバーを利用アプリケーションアプリケーション

物理サーバー物理サーバー物理サーバーを追加

仮想サーバーを設定空き

リソース消費リソース

新アプリ新アプリ

仮想サーバー

仮想サーバー

仮想サーバー

仮想サーバー

消費リソース

空きリソース

8

ものは、1つの物理サーバーを複数の仮想的サーバー、すなわち「VM（Virtual…Machine：仮想マシン）」に分割できることです（前ページの図1）。　一般に、企業が利用しているアプリケーションは、それぞれがWindowsやLinuxなど異なるOS、さらには異なるバージョンを利用しています。かつては、これらそれぞれに物理サーバーを用意してきたわけですが、仮想化により物理サーバー上に複数の仮想サーバーを用意できれば、複数の異なるアプリケーション／OSを1つの物理サーバー上で利用できます。　個々の物理サーバーは、リソースに制限があります。仮にアプリケーションごとに別々の物理サーバーを利用するとすれば、あるアプリケーションが利用している物理サーバーはフル稼働しているものの、別のアプリケーションが動作している物理サーバーは全く稼働していないというバラツキが生じます。このバラツキも仮想化により解消でき、物理的な制約から生じるリソースの無駄を減らせます。　こうしたサーバーの仮想化は現在、オンプレミスのITインフラにおいても広く利用されており、次世代ITインフラ固有のテクノロジーというわけでもありません。

ストレージにおける仮想化

　　ストレージにおける仮想化は、少し複雑です。ストレージの複数の階層で仮想化が実行されているためです。まず、

ディスクレベルの仮想化では、ハードディスクの物理的構造を隠ぺいし、論理的なリソースにします。その上位レイヤーであるブロックの仮想化では、ハードディスクの物理的な制約を隠ぺいし、論理的なボリューム（ひと塊の記憶領域）を作りだしています。　さらに、その上位レイヤーとなるファイルシステムの仮想化では通常、単体のストレージ装置に紐づくファイルへの経路（パス）を、実際には複数のストレージ装置にまたがっている場合でも、1つのパスでファイルにアクセスできるようにしています。これを「グローバルネームスペース」と呼びます。　またネットワークに接続されている複数のストレージ装置を、あたかも1つの大きなストレージ装置のように統合（プール）し、1つのコンソールから制御する仮想化もあります（図2）。　クラウドのような不特定多数が利用する環境では、単に統合するだけでなく、同時に仮想的に分割し、それぞれが利用者にとって独立した専有ストレージとして提供できなければなりません。つまり、複数のストレージ装置を統合しながらも、それぞれの装置に依存することなく、分割・独立した専有ストレージ空間を個別に提供するのです。　これらの仕組みを実現するために現在、ストレージ装置分野では，ソフトウェ

アで制御する「Software…Defined（ソフトウェア定義）」の採用が進んできています。Software…Definedについては、第3回で取り上げます。

ネットワークにおける仮想化

　ネットワークにおける仮想化とは、ネットワーク回線やネットワーク装置に仮想化技術を適用することです。従来、ネットワークの仮想化といえば、V L A N（Virtual…LAN）が一般的でした。これは、1つの物理的なネットワークを複数の異なるLANに仮想的に分割する仕組みです。しかし、VLANの場合、物理的なスイッチごとに設定する必要があり、結局のところ物理的な装置に依存していました。　ネットワークが物理的な回線や機器のままでは、サーバーやストレージが仮想化されても、仮想化環境としてのメリットは活かせません。なぜなら、ネットワークを変更する都度、スイッチやルーター、ファイヤウォール、ロードバランサーといった物理的なネットワーク装置を接続したり設定を変更したりしていては柔軟な運用が難しいからです。　最近では、ネットワーク仮想化といえば、第 3回で取り上げる So f twa r e…D e f i n e d 技術を適用した S D N（Software…Defined…Network：ソフト

図2：ストレージの仮想化イメージ


統合されたストレージ空間仮想的に割り当てられた専有ストレージ領域


9

ウェア定義ネットワーク）を指すことが増えています。　SDNは、従来の IPネットワークがパケット伝送と経路制御に、両機能が一体化した物理的なスイッチを用いていたのに対し、両機能を分離した仕組みです。　一例としては、「OpenFlow」というソフトウェアによる制御技術を使ったコントローラーで、パケット伝送機能のみを担当するスイッチを制御するSDNがあります。OpenFlowによって、プログラムが可能で仮想的に経路制御をするネットワークを構築します。　さらにスイッチやロードバランサーなど、すべてのネットワーク機能を、汎用的なサーバーを使って実現するための「NFV（Network…Feature…Virtualization）」という動きもあります。

クラウドは「仮想化＋分散処理」で実現されている

　さて、次世代ITインフラを最大限に活用しているクラウドですが、その語源として、「インターネット経由で預けるデータの行き先が『雲（Cloud）』のようだから」と説明されることがあります。これは、クラウドを外から観れば、“雲”のような仮想リソースだからということから来ているのでしょう。　しかし、クラウドの本来の語源は、分散処理を意味する「クラウド（Cloud）コンピューティング」の短縮系です。最近話題の「クラウド（Crowd）ソーシング」は、クラウドのスペルは違いますが、多くの知

恵やスキルを集めて事に当たるという点では類似しています。　また、OSSの世界では、「Apache…Cassandra」をはじめNoSQLデータベースが多数、登場しています。NoSQLデータベースとは、RDB（Relational…DataBase）の標準操作言語であるSQL言語を使わないデータベース群であり、大量データを扱う用途で多数利用されています。これらNoSQLデータベースは、複数のサーバーを使う分散処理技術を採用することで、大量データに対応しています。　同様の分散処理は、IT…インフラをクラウドサービスとして提供する I a a S（Infrastructure…as…a…Service）では当たり前に使われています。代表例が、AWS（Amazon…Web…Services）のオブジェクトストレージ「Amazon…S3」でしょう。安価な汎用サーバーを多数並列に設置した分散処理により、2兆個ものオブジェクト（ファイル）を格納していると公表されている、巨大で拡張性のあるストレージ空間を構築しています。　S3では、分散処理により物理的なサーバーが故障したとしても、システム全体としてサービスが停止しない仕組みを備えたり、データが喪失しないように複数の物理サーバーにデータを複製し保護したりしています。　こうして見ると、仮想化と分散処理は

「卵の白身と黄身」のような関係にあることが分かります。仮想化は、アプリケーションや利用者から見える外側（白身）であり、その内側にある仕組み（黄身）が分散処理というわけです（図 3）。すなわちクラウドの本質とは、分散処理で動く物理リソースが、仮想化を使いアプリケーションや利用者から隠ぺいされていることです。　クラウド型のITインフラは、この「仮想化＋分散処理」の組み合せによって実現しなければなりません。サーバーを仮想化しているだけの環境をクラウドと呼ぶケースも見られますが、これは単に物理サーバーを複数の仮想サーバーに分割しているにすぎません。ストレージとネットワークも仮想化され、かつ複数の物理装置を統合的に制御できる分散処理が伴って初めて、本物のクラウド、あるいはクラウド型のITインフラと言えるのです。　既に企業ITのインフラにおいても仮想化は一般的になりました。次のステージは、そこに分散処理を加えることです。両者が組み合わさることで、多種多様な大量データを迅速に、かつ経済的に処理できるクラウド型のITインフラへの変革が可能になります。

　次回は、仮想化の項で登場したSoftware…Defined（ソフトウェア定義）について解説します。

図3：雲の外（仮想化）と中（分散処理）のイメージ


利用者

仮想サーバー

仮想ネットワーク

仮想ストレージ分散処理

物理サーバー

10

クラウドサービスを提供するための次世代 ITインフラは、汎用サーバーとソフトウェアで構築する「SDI（Software Defined Infrastructure：ソフトウェア定義インフラストラクチャー）」への流れを強めています。発端は、サーバーの仮想化でしたが、この動きがストレージやネットワークにも広がり、ITインフラ全体をソフトウェアで定義できるようになってきたからです。今回は、ソフトウェア定義（Software Defined）を取り上げます。

第3回次世代ITインフラはソフトウェアが定義する

専用ハードウェアが消え、すべては汎用ハードウェアに

　多くのITベンダーが「ソフトウェア定義（Software…Defined）」という表現を使い始めています。対象製品も幅広く、その実現方法なども異なるため、上記の定義にしても正確だとはいえないかもしれません。現在、ソフトウェア定義という表現は、大きく次の3つの製品群で使われています。　1つは、x86アーキテクチャーを採用した物理サーバーと、Linuxのような汎用的な基本ソフト（OS：Op e r a t i n g…System）の上で動作する、アプリケーションに近いソフトウェアがITインフラとして機能する製品です。　第2は、汎用的なOSではなく、ファイルシステムのようなコンピューターリソースを管理するOSの機能を補完・強化するために、独自OSまでを含むソフトウェア製品です。　そして最後が、コントロール層（Control…PlaneやController）を物理的な装置から切り離し、物理的に複数ある装置を統合して管理するソフトウェア製品です。従来は、このコントロール層がファームウェアとして物理的な装置の一部であったり、コントローラー自体が

ハードウェア装置として提供されたりしていました。　このように、ソフトウェア定義の実現方法や、果たす役割が異なっています。しかし、いずれにも共通しているのは、ハードウェアは専用装置ではなく、汎用的なハードウェア（主にはサーバー）を使うという点です。

ITインフラを構成する物理装置はすべてが“コンピューター”

　ITインフラの基本的な構成要素は、演算処理をするCPU、処理内容やデータを保存したり処理結果を受け取ったりするメモリー、データを長期的に保存するための記憶領域であるHDD（Ha rd…Disk…Drive：ハードディスク装置）、外部機器と接続するためのネットワークインタフェースです。つまり、ITインフラを構成する物理装置の大半がコンピューターです。　一般にコンピューターといえば、物理的なサーバーがイメージされるでしょう。クライアントや端末からのリクエストに対して、業務アプリケーションやミドルウェア、データベースなどのソフトウェアを動かしています。　しかし、OSが、ハードウェアの基本的

な機能を管理し制御しているという意味では、ストレージ装置もネットワーク関連機器もコンピューターです。前者は、データの記憶と高速アクセスに特化し大量のHDDを搭載したコンピューターであり、後者はデータの通信機能の提供に特化したコンピューターです。　ただし、ストレージ装置やネットワーク装置は、その役割をより高度にするために、ハードウェアやOSが独自に開発され、全体を制御するためのソフトウェアは予め装置に組み込まれるファームウェアでした。その中身はブラックボックスです。ハードウェアとソフトウェアは一体化しており、分離できません。同じコンピューターだといっても、例えばサーバーに転用するといったことは考慮されていないのです。　しかし、米 Am a z o n . c o mや米Google、米Facebookといった大手クラウドサービス事業者は、ベンダーが開発・販売しているストレージ装置やネットワーク装置を、一部にしか、あるいは全く利用していないと言われています。なぜならば、数十～百ペタバイト、さらにはエクサバイトとも言われる大量データを取り扱い、無料を含む低廉な料金でクラウドサービスを提供するためには、高価なベンダー製品では実現が難しいからです。　そこで彼らは、経済的に大量データを扱うために、汎用的なハードウェアを使って、スケールアウト型のオブジェクトストレージといった独自のストレージ環境を自ら開発して利用しているのです。

ソフトウェアデファインド（Software Defined）の定義：汎用的なハードウェアを使いながら、ソフトウェアによって必要な機能を実現することで、専用ハードウェアと変わらぬ機能を実現すること、および，その仕組み


11

ソフトウェアが定義するITインフラ（SDI）のメリットは経済性と俊敏性

　大量データを経済的に扱うITインフラを実現する鍵は、汎用的なハードウェアと汎用的なOSを活用することにあります。広く普及しているx86アーキテクチャーのプロセッサを搭載した標準的なサーバーや、Linuxのようなオープンソース化されているOSと比べ、特殊な装置にベンダー独自のOSを組み込んだ装置は、相対的に高価にならざるを得ません。　次世代インフラにおけるソフトウェア定義では、これら汎用的なサーバーとOS上で動作するストレージ用やネットワーク機器用のソフトウェアを開発することで、大量のデータ処理に最適化したス

トレージやネットワークの機能を実現します（図1）。　いまやサーバーの処理能力は巨大です。CPUのコア数を増やすことで処理速度の高速化を図れれば、搭載できるメモリー容量もテラバイト級にまで増えています。HDDも1つのサーバーに100台近く搭載できるものもありますし、HDDの1台当たりの容量も5テラ～8テラバイトといった大容量の製品が登場しています。　実際、汎用サーバーは、性能や容量は増える一方で、販売価格は下落し続けています。このような汎用サーバーをハードウェアとして活用することで、データ単位の平均コストを長期にわたり引き下げられることが期待できるのです。　また、ベンダー独自に開発・提供されるストレージ装置やネットワーク装置は、ブラックボックスであり、装置の増設や置

換の際にも同一ベンダーを使い続けざるを得ません。つまり、“ベンダーロックイン”に陥りがちです。さらに、例えばデータをバックアップしたりアーカイブしたりしようとすれば、そのベンダーが提供する機能を追加料金を払って利用せざるを得ないケースもあります。　汎用サーバーとソフトウェアにより構築するソフトウェア定義の ITインフラ（ S D I：S o f t w a r e … D e f i n e d…Infrastructure）であれば、主要機能はもとより、ハードウェアが故障した際のオペレーションの継続性や性能の向上などにも特殊な装置に依存しなくて済みます。新機能の追加も基本的にはソフトウェアの修正・追加で対応できるため、ハードウェアのアップグレードという手間もありません。つまり、新たなアプリケーションニーズに俊敏に対応できるのです。

図1：専用装置…vs…ソフトウェア定義


専用装置ソフトウェア定義

ファームウェア

基本ソフト（OS）

CPU、メモリー、HDD、ネットワークインタフェース

機能を定義するソフトウェア

基本ソフト（OS）

CPU、メモリー、HDD、ネットワークインタフェース

統合

ソフトウェア製品

汎用OS（例：Linux）

ハードウェア製品

12

　ところで、次世代ストレージ装置として「オールフラッシュアレイ」が注目を集めています。HDDを一切使わず、すべてをフラッシュメモリーに置き換えることで、高速処理を実現します。HDDは物理的なディスクからデータを読み込むため、データの読み出し時間がかかるからです。

次世代ITインフラは超高速化と大容量化に2極化

　このオールフラッシュアレイもコンピューターです。しかし、一般的なストレージ装置と同様に、ハードウェアやOS、製品としての機能を提供するソフトウェアも一体としてゼロから、ベンダー各社が独自に設計・開発しています。フラッシュをストレージ装置として利用するための標準化が進んでいないこともあり、高速処理の実現に向けてフラッシュの能力を最大限に引き出すために各社が独自のアーキテクチャーを競い合っているのが現状です。　ここでフラッシュとは、フラッシュメモリーのことです。データの消去・書き込みが自由にでき、電源を切っても内容が消えない半導体メモリーです。半導体メモリーには、データを読み書きはできるものの電源を切ると内容が消えるRAM（Random…Access…Memory）と、データの消去はできないが電源を切っても内容が消えない ROM（R e a d … O n l y…Memory）があります。フラッシュは、これらRAMとROMの良いところを兼ね備

えています。　半導体メモリー自体は今後、増産され、そのコストが低下することでしょう。それにつれ、オールフラッシュアレイのような高速処理を実現するストレージ装置が広く普及することは間違いがありません。しかし、次世代ITインフラが目指す方向は高速化に加え、安価に大容量というニーズをすぐに満たす必要があります。　こういったITインフラを構築するためのソフトウェアは、大手クラウド事業者が自社サービスのために自社開発して活用してきました。経済性はもちろん、利用者ニーズに応じたサービスを迅速に、かつ柔軟に実現できるITインフラを必要としているためです。

　そして、彼らが開発したソフトウェアや、それと同等の機能をもつソフトウェアが、OSS（Open…Source…Software：オープンソースソフトウェア）として公開され、あるいは、そうしたOSSをベースに、機能拡張やサポートを提供するディストビューターが登場しています。こうしてソフトウェア定義の技術は成熟され、普及しようとしています。　従って、次世代ITインフラは、「安価に大容量」か「高価で高速処理」かの方向を目指し2極化が進み、それを実現するために最適な製品・技術が選択されてゆくことでしょう（図2）。

　次号は、スケールアップとスケールアウトについて解説します。

図2：2極化する次世代ITインフラ


高価で高速処理

安価で大容量

● ホットデータ● フラッシュ活用● IOPS中心● 仮想マシン最適化● 多種多様なアプローチ

● クール／コールドデータ● オブジェクトベース● スケールアウト（数ペタバイト）● ソフトウェア中心● クラウド互換


13

世界中で発生するデータ量は「2年で倍増する」とされています。このビッグデータの波には近い将来、すべての企業が立ち向かわなければならないのは間違いありません。ただ個々の企業にすれば、その波が到来するタイミングやサイズの予測が難しいのも事実です。それだけに、現状に見合った性能や容量から始めながらも、段階的に成長できるITインフラを実現しなければなりません。そこでは、スケールアップとスケールアウトの両方への対応が求められます。

第4回次世代ITインフラはスケールアップとスケールアウトでシステム拡張

ITインフラは柔軟に拡張できるほうが良い

　ビッグデータの時代を迎え、次世代ITインフラは従来のITインフラが想定していなかった“量”の大きさに対応できなければなりません。次世代ITインフラを構築する際に、当初から大量のデータが存在するのであれば、必ずしも小規模からスタートし拡張できるITインフラである必要はないかもしれません。　しかし多くの場合は、最初から一大プロジェクトを立ち上げ、大規模システムを構築するよりも、小規模から始め段階

的に移行したいと考えるのが一般的ではないでしょうか。数年先を見越して余剰設備を大量に抱えておくのではなく、データ量の増加に合わせ、物理的な装置の性能や容量の制約を極力受けることなく柔軟に拡張できるITインフラが望ましいのです。　処理件数やデータ量が増え、ITインフラを構成するシステムの性能が劣化したり許容量が限界に達したりした際に、そのシステムを拡張方法には大きく、「スケールアップ」と「スケールアウト」の2つの方法があります（図1）。　スケールアップは、上位機種など高性

能・大容量な装置に“置換”することで、処理性能や容量を拡張する考え方です。この場合、システム環境は再設定する必要があります。特にストレージ専用装置では、格納しているデータを移行するという運用作業も伴います。　一方のスケールアウトは、設備を“追加”することでシステム全体の性能を高め容量を拡張する考え方です。システムを構成する複数の設備（これを「ノード」と呼びます）を、あたかも1つのシステムであるかのように統合制御しなければなりません。　一般的には、ビッグデータへの対応ではスケールアウトが望ましいとされています。なぜなら、データ量が突然、想定以上に増えるような場合でも、ノードを追加するだけで済むからです。設備の置換やデータの移行といった運用面の手間が軽減されます。　しかし、第3回で説明したように、次世代ITインフラはソフトウェア定義によって汎用サーバーを使う形態になります。汎

スケールアップ（Scale up）の定義：高性能・大容量の上位機種に設備を置換し、性能や容量を拡張すること、および、その仕組み

スケールアウト（Scale out）の定義：複数設備から構成されるシステムに設備を適宜追加していくことで、システム全体としての性能や容量を拡張すること、および、その仕組み

図1：スケールアップとスケールアウトの違い


スケールアップスケールアウト

14

用サーバーの性能は年々向上しているだけに、サーバー1台当たりの性能向上や大容量化のメリットを享受するためには、スケールアウトと同時にスケールアップにも対応できることが重要になってきます（図2）。

スケールアップにも対応できるスケールアウトの要件

　スケールアウトを実現するアーキテクチャー（構成）には、マスター／スレーブ方式とP2P（Peer…to…Peer）方式の2つがあります（図3）。　マスター／スレーブ方式は、システム全体を統括管理する役目（マスター）と、その指示に従う役目（スレーブ）が分かれている構成です。マスター／スレーブ方式でスケールアウトを実現している製品としては、ビッグデータ分析に用いられる分散処理フレームワークである「Apache…Hadoop」が有名です。ストレージ製品にも、コントローラーがマスターの役割を果たし、スレーブとなるHDDを追加することでスケールアウトするものがあります。　いずれも、マスターノードの管理下でスレーブノードがスケールアウトします。スレーブノードは、マスターノードの指示に従うだけです。逆にマスターノードの性能限界がシステム全体に影響を及ぼします。よりスケールアウトさせるには、マスターノードのスケールアップが必要になるのです。　一方、P2P方式は、すべてのノードが

同じ役割を果たしています。相互に監視・管理し、仕事を分担し合うのです。P2P方式でスケールアウトを実現している製品としては、NoSQLデータベースの「Apache…Cassandra」などが有名です。分散型のP2P方式においても、スケールアップへの対応は外せません。この理由を説明していきましょう。　P2P方式は、例えば10台のノードを並列に配置し、それぞれのノードが仕事を均等に分担することで、システム全体としては1台のノードの10倍の仕事量をこなせるという仕組みです。ここで、10台のうち3台を高性能・大容量の汎用サーバーにスケールアップするとしましょう。　この場合、スケールアップした3台には、残りの7台より多くの仕事を割り振ればシステム全体としての性能が向上しま

す。つまり、ノードの実力に応じて、システム内の負荷を適切に割り振ることができれば、システム内で異なる世代や機種の混在を許容できるということです。　また、3台のノードを置換する作業を、残りの7台だけが働いている間に実施することができれば、3台を加えた13台でまず稼働させ、適切なタイミングで元の10台の中から3台を取り外して10台に戻すという方法もあります。ここでは、台数の増減に合わせて仕事の負荷を自動的にバランスし再配置できなければなりません。　このようにスケールアウトでは、設備を追加することでシステム全体の性能や容量を拡張するわけです。しかし同時に、設備の置換（スケールアップ）にも対応できる仕組みを備えていなければ、汎用サーバーを使うソフトウェア定義型のIT

図2：スケールアップに対応するスケールアウトの効果


スケールアップノードのスケールアップにより性能・容量を向上

スケールアウトノードの台数の増加とともに直線的に性能・容量が向上

性能・容量

ノード台数


15

インフラのメリットは限定的になってしまうのです。

スケールアップ＋スケールアウトで性能向上と容量拡張を図る

　これからのITインフラの理想像は、小規模から利用でき、データの増加と共に、例えばペタバイト級にまでシステム全体を柔軟に拡張できるものです。その点では、マスター／スレーブとP2Pのいずれの方式にも一定の限界があります。　まず「小さく始める」点ですが、マスター／スレーブ方式では、マスターノードの冗長性を確保する必要があり、マスターノード2台とスレーブノード数台がスタート時の最小構成になります。P2P方式では、マスターノードが不要な分、ノー

ド数台から始められます。小規模なスタートという点では、P2P方式の方が有利と言えます。　一方、ペタバイト級への拡張性については、両方式それぞれに限界があります。マスター／スレーブ方式の場合は、1台のマスターノードが管理できるスレーブノードの台数に制限があります。マスターノードが管理できる台数を越えれば、別のマスター／スレーブによるシステムを追加しなくてはなりません。　P2P方式の場合、論理的には無制限に拡張できそうですが、それぞれのノードが互いの状況を常に監視するための通信が発生しているため、あまりに多くのノードで構成したシステムでは、システム内のネットワーク帯域が混雑し遅延が生じるなど、別のボトルネックから制限を受

けるのです。　マスター／スレーブとP2Pのいずれの方式であっても、各社の製品では、それぞれの制約を独自の方法で解決している場合があります。「xx台までスケールアウト可能」とあらかじめ製品の拡張規模を定めているものもあります。　これらの制約をどう考えるかは利用企業の判断に委ねられますが、どんな製品を選ぶにしても、スケールアップにしか対応できない製品ではなく、スケールアップにも対応できるスケールアウト型の製品のほうが、ハイブリッドクラウド時代の次世代ITインフラには望ましいと言えるでしょう。

　次号はセルフサービスについて解説します。

図3：マスター／スレーブ方式とP2P方式の比較

マスター／スレーブ方式

マスターの管理下でスケールアウトノード同士が相互に監視・管理して仕事を分担しながらスケールアウト

P2P方式

スレーブ


マスター

16

クラウドの普及に伴い、エンドユーザーはセルフサービスの便利さに慣れ、IT部門にITインフラの調達・設定を頼み、数カ月後に、やっと利用できるという状況には満足できなくなっていきます。結果、社員が個人契約したクラウドサービスを利用し始めるBYOC（Bring Your Own Cloud）による情報の外部流出に伴うリスクが懸念されます。正しい利用法を教育し、監視・規制することも重要ですが、それよりもクラウドと同等のセルフサービスに対応することが本質的な解決策です。

セルフサービスが経営スピードを高め情報リスクを抑える第5回

仮想化と自動化が可能にするセルフサービス

　第2回でクラウドを卵にたとえ、白身（外）が仮想化で、黄身（中）が分散処理だと説明しました。セルフサービスと、第6回で紹介する AP I（Ap p l i c a t i o n…Programming…Interface）は、卵の殻の部分に相当します。セルフサービスのお陰でクラウドは、便利に扱えます。このセルフサービスを提供するために重要な役割を果たしているのが、仮想化と自動化です。　仮想化は、CPU、メモリー、ストレージ、ネットワークというリソース（資源）をメニュー化するために必要です。物理装置を使って、これらのメニューを提供しようとすれば、様々な性能と容量の機種を用意し、かつ装置の在庫も考慮しなければなりません。ITインフラの物理リソースを仮想リソース化することで、エンドユーザーが選択しやすいメニューを柔軟に提供できます（図1）。　自動化は、セルフサービスメニューから選択された仮想リソースのプロビジョニングのために必要です。エンドユーザーからの申し込みを受け、人手で仮想マシンを準備しているようでは、迅速なサービス提供はできません。容量を増減

する際には、自動的かつ弾力的に拡張できることも求められます。エンドユーザーから要求があった場合や障害時などに、必要な分だけ、コンピューターリソースを動的に別のシステムに割り当てる必要もあります。　当然のことながら、将来必要なITインフラの規模を事前に予測し、それに見合ったサーバー等の物理リソースを準備しておくことも必要です。ただし、準備が多すぎれば在庫になり、足りなければ満足なリソースを提供できなくなります。だからこそ、ハイブリッドクラウド時代のITインフラには、第4回で説明したように、小規模からスタートし成長とともに

ノードを追加することで拡張できるスケールアウトが求められるのです。　最近では、仮想マシンの安定性や処理能力に物足りなさを感じる利用者向けに、ベアメタルと呼ばれる物理リソースがクラウドサービスとして提供されている場合があります。これは、OSをインストールしていない物理サーバーを収納ラックに用意しておき、申し込みがあれば割当を設定するサービスですが、人手の関与が最小限になるよう、その運用は自動化されているはずです。

セルフサービスには可視化と標準化が不可欠

　ITインフラを仮想リソースとしてセルフサービス化する製品は、従来から各ベンダーが積極的に取り組んでおり、多数販売されています。「Apache…Cloud…Stack」や「Apache…OpenStack」といっ

ITインフラにおけるセルフサービス（Self service）の定義：エンドユーザーや管理者が、サービスポータルから必要なコンピューティングやストレージ、ネットワークのリソースを選び、それらを組み合わせて即時に利用をできること、および、それを実現するための仕組み

図1：仮想リソースによるセルフサービスメニューのイメージ


17

たOSS（Open…Source…Software）もあり、比較的手軽に試してみることができます。　ただし、本番環境として導入するためには、利用状況を可視化できる製品を選択するか可視化ツールを追加し、かつ社内のITニーズを標準化しなければなりません（図2）。　可視化は、あるエンドユーザーが無尽蔵にリソースを消費することがないよう、リソースの利用量を適切に把握し管理するために必要です。特に、エンドユーザーの消費量を統計情報として提供し、部門などの単位で適切に課金（チャージバック）して、コストを意識させなければなりません。利用量制限といった使いすぎを防ぐ機能が備わっている製品もあります。　一方の標準化は、ITインフラに不慣れなエンドユーザーにとっては不可欠です。仮想リソースをメニュー化するだけではなく、良く使うシステムやサービスをカタログ化したり、スペックをテンプレート化したりして、分かり易く使い易い形で提供するためです。　ハイブリッドクラウド時代には、パブリッククラウドとプライベートクラウド、オンプレミスを適材適所で使い分けることが求められます。可視化ツールや標準化されたメニュー、カタログなどが、それぞれの環境で異なっていては混乱を招くばかりです。クラウド、オンプレミス問わず、これらは統一され連携していることが理想的です。　最近は、リーンスタートと言われるよう

に、事業展開の速さが重視されています。新規ビジネスのアイデアがあれば、短期間でWebサービスなどの最小限の機能を開発し、まずは市場に投入。その反応をみながら機能の追加や高度化を図るなどです。このとき、ITインフラがボトルネックになり、ビジネスのスピード感を損なうようでは困ります。クラウドを優先して利用する「クラウドファースト」への動機が高まるのは当然でしょう。

セルフサービスの利便性が情報流出リスクも抑える

　クラウドファーストをポリシーにしている企業であれば、その管理体制も整っていると考えられます。しかし、管理体制が未整備な状況で、開発者が個人契約し、自分のクレジットカードで支払いをし、IT部門の管理を越えて利用している場合には、問題が生じる場合もあります。　例えば、クラウド先進国である米国のソフトウェア開発企業では、会計監査時に開発者それぞれが個人契約しているクラウドへの支払いを集計してみたところ、年間2億円規模になっていました。さらに、本来は社外秘扱いとされる重要なデータがファイヤウォールの外側に置かれていました。同社のCTOは、管理責任

を問われ解雇されています。　しかし、この事例においては、こうした問題が生じる根本的な原因に着目することが重要です。その原因は、開発者が満足できるITインフラを提供できていなかったことです。使いたい時に必要なリソースをすぐに利用できるようセルフサービスのITインフラを整えておくべきでした。　こうしたことは、アプリケーション開発を目的とする企業や職場だけの問題ではありません。事務系の職場でも、例えば、割り当てられたファイルサーバーの容量が制限され、容量を拡張するための手続きが面倒だったり時間がかかったりするようでは、エンドユーザーにはストレスがたまります。結果、IT部門の管理を越えて、セルフサービスで利用できる個人契約のオンラインストレージサービスにファイルを預け始めてしまうのです。　セルフサービスに対応する次世代ITインフラは、ビジネスのスピードアップにつながることは当然ですが、クラウドよりも利便性が劣ることで生じてしまう情報の外部流出に伴うリスクを最小限に抑える効果もあるのです。

　次回は「API（Application…Program…ming…Interface）」について解説します。

図2：利用量を可視化するセルフサービスポータルのイメージ

18

第 5回で説明したセルフサービスと、今回説明するAPI（Application Programming Interface）は、クラウドと同等の利便性を次世代 ITインフラの利用者に提供するために欠かせません。特にクラウドサービスの APIは独自に開発・提供され、それぞれが異なっているだけに、いずれの APIに対する互換性を自社の次世代 ITインフラに持たせるかで、利用できるアプリケーションやハイブリッドに利用するクラウドの種類や数に影響が出てきます。

アプリケーション活用の鍵を握るAPI第6回

API互換がハイブリッドクラウドを可能にする

　APIは元々、1台のコンピューターのなかで、その基本ソフト（OS）やアプリケーションの機能を、他のアプリケーションから呼び出すための手順や記述方法を定めたものです。　最近では、他のアプリケーションに自分の機能の一部を使わせるために、さま

ざまなアプリケーションやソフトウェアがAPIを採用し公開しています。他のアプリケーションが提供する機能を利用すれば、同等の機能をプログラミングする必要がなくなり、開発期間を短縮できるというメリットがあるからです。　私たちは、TwitterでのつぶやきをFacebookにも同時に投稿したり、Googleマップをホームページやブログなどに表示させたり、あるいは、そうした

形での投稿やホームページなどを見ることが増えています。これもAPIのお陰です。WebアプリケーションやWebサービスにおいて、ネットワーク経由で機能を共有するためのAPIは「Web…API」と呼ばれ、広く活用されています。　一方で最近、インフラ系のエンジニアから、「APIには、これまであまり馴染みがなかった」と聞きました。企業のITインフラでは、W i n d o w s の C I F S（Common…Internet…File…System）やLinuxのNFS（Network…File…System）など、LAN（Local…Area…Network）上でのファイル共有プロトコル（手順）による相互接続を基本にしているためかもしれません（図1）。

API（Application Programming Interface）の定義：コンピューターの基本ソフト（OS）や、アプリケーション、Webアプリケーション、クラウドサービスなどが、自身の機能を外部のアプリケーションやソフトウェアに利用させるための仕様や、その仕組み

図1：ファイル共有プロトコルとWeb…APIの違い


クライアントファイル共有プロトコル

（CIFS、NFS等）

Web API● 現在地の地図を探す● 地図を表示する

ファイルサーバー

● OSに依存した独自の通信プロコトルを使用● サーバーとの接続に専用のクライアントソフトが必要● LAN内での使用が前提で、ファイアウォール越しの通信は考慮されていない

ファイルの共有

Webサービス

アプリケーション

リクエスト：（例：現在地の位置情報）

レスポンス：（例：現在地の地図）

● 通信プロコトルとしてWeb標準のHTTP/HTTPSを使用● プロコトルがOSや開発言語に依存しないので、アプリケーションとWebサービスの連携が容易● ほとんどのファイアウォールはHTTP/HTTPSの通信を許可しており、ファイアウォール越しの通信が容易


19

　TwitterとFacebookの例のように、Web上に公開されている情報を加工したり編集したりして活用することを「マッシュアップ」と呼びます。Web…APIは、Webサービスの利便性を高め、利用者を増やすために欠かせなくなっています。APIで他のサービスと連携し加入者を拡大すれば、新たな経済圏が誕生することから、「APIエコノミー」とも言われ、大手のWebサービス会社が積極的にAPIを公開しています。　APIは、次世代ITインフラにおいても大変に重要です。その理由は、第5回で紹介した「セルフサービス」が次世代インフラに欠かせないことと同じです。次世代ITインフラの利便性がクラウドサービスと同等でなければ、利用者がクラウドサービスの利用を優先してしまうからです。　ハイブリッドクラウドを実現するという

点でも、次世代ITインフラはAPIに対応していなければなりません。従来、オンプレミスでの利用を前提とした多くの企業向けアプリケーションも、クラウドサービスのAPIを追加実装し始めています。これにより、データの保存先（ターゲット）を変えるだけで、「外部に預けられるデータはパブリッククラウド、内部に留めるべきデータはオンプレミス」といったハイブリッドな使い方が容易になります。

クラウドサービスのAPIのベースはREST API

　クラウドサービスでは、サービスごとに独自のAPIが提供されています。しかし、いずれのAPIも「HTTP（Hypertext…Transfer…Protocol）」と「HTTPS（HTTP…over…SSL）」いうインターネットの通信プロ

トコルをベースにしている点は共通です。インターネットを経由してデータを読み書きするためです。なかでも主流になっているのが「REST（Representational…state…transfer）API」です。　REST…APIのメリットは、APIを使ってWebサービスから呼び出すテキストや画像、動画、音楽のファイルなど、情報リソースの場所を示し識別するためのIDとして「URL／URI（Uniform…Resource…Identifier）」が割り当てられる点です。　URL／URIは、「http://cloudian.jp/」など、私たちに馴染みのあるインターネットアドレスです。URL／URIをクリックすれば、インターネットブラウザーを経由し、ホームページだけではなく、PDFなどインターネット上で公開されている情報リソース（公開URL）に直接アクセスできます。

図2：Amazon…S3のAPIの例


Get

Get Bucket(List Object)

Get Bucket Website

Put Bucket ACL

Put Bucket Put Bucket Website

Delete Bucket Delete Bucket Website

Head Bucket List Multipart upload

Get Object Get Object ACL

Put Object Put Object ACL

Delete Object Put Object (Copy)

Head Object Delete Multiple Objects

Options Object

Post Object

Initiate Multiple Upload

Upload Part

Upload Part - Copy

Complete Multipart Upload

Abort Multipart Upload

List Part

Get Bucket Lifecycle

Get Bucket Policy

Get Object Torrent

Put Object Restore

Get Bucket Tagging

Put Bucket Lifecycle

Delete Bucket Lifecycle

Delete Bucket Policy

Get Bucket CORS

Get Bucket Location

Get Bucket Logging

Get Bucket Notification

Get BucketrequestPayment

Get Bucket Versioning

Put Bucket Logging

Put Bucket Notification

Put Bucket Tagging

Put BucketrequestPayment

Delete Bucket CORS

Delete Bucket Taggingバケットにおける操作

オブジェクトにおける操作

追加機能

サービスにおける操作

シンプルな操作中程度の操作高度な操作

20

　REST…APIの基本は、「PUT：ファイル等リソースの状態の変更や更新」「GET：リソースの呼び出し」「POST：リソースの作成」「DELETE：削除」という操作です。当然、これらのシンプルな操作だけでは種々のサービスは提供できません。AWS（Amazon…Web…Service）やGoogle、Microsoft…Azureなどのクラウドサービスでは、REST…APIのルールに従い、より高度な操作ができるよう独自APIを開発し提供しているのです（前ページの図2）。

クラウドサービスのAPIは陣取り合戦が進行中

　クラウドサービスのAPIが、それぞれ独自であり異なるという点は、今後の次世代ITインフラのあり方に大きな影響を与えます。現状、あるクラウドサービスに対応しているアプリケーションやソフトウェアを、他のクラウドサービスで利用しようとすると、改修が不可欠です。　基本的なAPIだけを使い、それぞれのクラウドサービスを操作するのであれば、大きな改修を伴わず、そのまま利用できることもあるようです。しかし、各社のクラウドサービスを最大限利用するためには、独自開発されたAPIに対応しなければならず、アプリケーション側では、それなりの改修が必要になります。　理想的には、クラウドサービスのAPIが標準化され、統一されることが望ましいでしょう。そのような動きを取る標準化団体もありますが、業界全体に大きな影響力を与えるには至っていません。現

実的には、利用者は、クラウドサービスのAPIに“囲い込まれる”ことになってしまいます。　ここで、敢えてクラウドサービスではなく、「クラウドサービスのAPI」と表現したことに意味があります。それは、同じAPIを提供するクラウドサービス間であれば、1つのアプリケーションを共有できるからです（図 3）。例えば、AWSに準拠するAPIを提供するクラウドサービスは国内外でいくつも運営されています。AWSから変更しても、アプリケーションをそのまま利用できることがウリです。　同様に、OSSの「Apache…Open…Stack」を採用するベンダーが増えています。各社が特殊なAPIを開発し追加していなければ、OpenStackを採用するクラウドサービス間ではアプリケーションの互換性が確保されるでしょう。　アプリケーション側としては、できる限

り人気が高く、利用者が多いクラウドサービスのAPIを実装したいところです。そのため、クラウドサービスのAPI側では、ユーザー会を組織したり、コミュニティ活動を通じて利用者を増やしたりすることで、より多くのアプリケーションに対応してもらえるよう陣取り合戦を繰り広げています。　特に、パブリッククラウドとオンプレミスを使い分けるハイブリッドクラウド時代の次世代ITインフラにとっては、いずれのクラウドサービスのAPIを選択し、互換させるかが重要になります。利用者の少ないクラウドサービスのAPI互換では、利用できるアプリケーションが限られる可能性が高く、連携できるクラウドサービスの選択肢も狭まってしまいます。

　次回は、クラウドサービスのAPIを取り巻く「エコシステム」について解説します。

図3：API互換のメリット


オンプレミス

1つのアプリケーションをAPI互換のクラウドとオンプレミスが

ハイブリッドに活用クラウドA

クラウドB

クラウドC



21

オンプレミスの次世代ITインフラとパブリッククラウドが相互に連携するハイブリッドクラウドに進むためには、クラウドサービスの API（Application Programming Interface）に対応しなければなりません。しかし、既存のITインフラが、その APIに対応しない限り、そこにはギャップが残ります。クラウドサービスのセルフサービス化も、誰もが便利に使えるまでには、まだしばらく時間がかかるのも事実です。こうしたギャップを埋めるために、重要な役割を果たすのがエコシステムです。

エコシステムが実現するハイブリッドクラウド第7回

ハイブリッドクラウドへのギャップを埋める

　クラウドのインフラサービスは本来、ネットワークを経由してデータを預かり、計算処理し、読み書きさせるというシンプルなものです。それをビジネスニーズに応え、迅速に使えるようセルフサービス化し、誰もが簡単に使えるようにメニュー化しているのです（第6回参照）。セルフサービス化とメニュー化により、クラウドサービスは安価になり、大量消費できるようになりました。　それは例えば、セルフサービスのファストフードのようなものです。高級レストランで食事をすれば、お店側がメニューの相談に乗り、テーブルまで料理を運んでくれます。セルフサービスでは、顧客の側がメニューの内容を理解していることが前提です。適当に頼むと「期待はずれだった」という経験は誰にもあるでしょうし、初めてのお店であれば戸惑うことばかりです。このメニュー化されたセルフサービスを、利用者のニーズに合わせて使いこなすために重要な役割を果たすのがエコシステムです。　クラウドサービスは単体ではなく、その周りにあるコミュニティや、コンサルタント、インテグレーター、パートナー、

サードパーティーなどなどが連携し、相互に補い、依存し合うエコシステムを形成しています。このエコシステムが、使い慣れたレガシーなITインフラと、新たに登場したクラウドサービスの間に存在するギャップを埋めてくれます。

企業ITが活用するソリューションのギャップを埋める

　クラウドに限らず、企業ITで利用するソリューションにおいても、エコシステムは非常に重要です。いくつかの例を紹介しましょう。

例1＝クラウドゲートウェイを介した連携　第6回で、クラウドサービスはREST（Representational…state…transfer）API（A p p l i c a t i o n … P r o g r amm i n g…Interface）を使いデータを読み書きすると説明しました。しかし、現時点で、REST…APIに対応している企業ITシステムは、それほど多いとは言えないでしょう。　例えばストレージ環境をみても、企業ITでは、ブロックストレージは「iSCSI（Internet…Small…Computer…System…Interface）」や「SCSI」「Fiber…Channel」が、ファイルストレージであれば「CIFS

（Common…Internet…File…System）」や「SMB（Server…Message…Block）」「NFS（Network…File…System）」といったLAN（Local…Area…Network）内で使われるファイル共有プロトコルが、それぞれ一般的に使われています。　これらオンプレミスのITインフラとクラウドサービスの間を連携させるためには、これらのプロトコルとREST…APIを変換する仕組みが必要になります。これを実現するアプリケーションや装置は、「クラウドゲートウェイ」あるいは「クラウド・オン・ランプ」とも呼ばれています（次ページの図1）。後者は、高速道路に見立てたクラウドに対する入り口（ランプ）という意味です。　オンプレミスの ITインフラとクラウドサービス間に位置し、そのギャップを埋めるエコシステムの一部を構成します。

例2＝オンプレミスとクラウドサービス間のセキュリティを提供

　クラウドのセキュリティに対する懸念を聞くことがあります。実際のところ、SSLに対応するHTTPSを利用したり、VPNや専用線接続したりすることでインターネット通信の安全性を担保しています。またクラウド内部におけるサーバー間のデータ通信は暗号化されています。　ただし、さらなる安全性を求め、暗号を解く鍵をクラウド側ではなくオンプレミスで管理したいというニーズもあります。そのため、データをアプリケーション側で暗号化してからクラウドに預けられる製品群が登場しています。これらもエコ

IT分野におけるエコシステムの定義生物学の生態系（ecosystem）に由来し、IT分野では、関係し合う技術要素や、製品／サービスだけでなく、組織や人などが連携し、相互に補い依存し合うことで動的に形成されるシステムや、それに基づくビジネス、およびそのための仕組み

22

システムの一部を形成しています。

例3＝性能・経済性・利便性を向上　重複するデータを削除したり、データそのものを圧縮したりすることで、クラウドに預けるデータ量を少なくする製品群があります。これによりクラウドサービスの利用に伴うコストや時間を小さくできます。すべてのデータをクラウドに預ける前に、頻繁に利用するデータを手元にキャッシュすることで、ネットワークの影響を受けずにオンプレミスでのデータの読み書きを速くするといった製品群もあります。　これらの多くは、もともとはオンプレミスにあるITインフラのデータバックアップやアーカイブ製品です。クラウドサービスのAPIを追加・実装することで、オン

プレミスだけではなく、クラウドサービスにも対応できるエコシステムの一部を形成しているのです（図2）。

クラウドサービスのAPI間のギャップを埋める

　ここまで、オンプレミスのITインフラとクラウドサービスとのギャップを埋めるエコシステムを紹介してきました。少し先の動きも見据えて考えてみましょう。　クラウドサービスの利用に当たり、国外のデータセンターにデータを預けることに安全保障の観点や利用者のポリシーから生じる懸念を聞くことがあります。そのため、クラウドサービス事業者は、公的な各種の証明書や資格を取得することに加え、データセンターを主要国内に新設

する“現地化”を積極的に進めています。　その延長にあるのが、インタークラウドやマルチクラウドです。インタークラウドは、クラウド間の地域冗長やデータバックアップのために、クラウドサービス間を相互接続すること、マルチクラウドは、利用者が複数のクラウドサービスを使い分けたりすることです。こうした動きが顕在化し始めているほか、クラウドサービス間の相互接続を仲介するクラウドブローカーも登場しつつあります。　今後のクラウドサービスが、ガラパゴス島のように外部から完全に隔離され、その内部だけで独自に進化を続けるとは考えられません。複数のクラウドサービスのAPIに対応し、それら相互間のギャップを埋める製品やサービスが成熟することで、複数のクラウドサービスが連携す

図1：クラウドゲートウェイの概念


REST APII

REST APII

REST APII

現在のデータストレージ

クラウドサービスのAPIに対応する次世代ITインフラ

クラウドサービスA

クラウドサービスB

ファイル共有プロトコルクラウドサービスのAPI

SAN

クラウドゲートウェイ

ファイル共有プロコトルを

クラウドサービスのAPIに変換

NAS

● SCSI● iSCSI● FC

● CIFS● NFS● SMB


23

る大きなエコシステムが形成されていくはずです。

エコシステムの大きさや充実度が重要な選択基準に

　そうなると、オンプレミスの次世代ITインフラとしては、いずれかのクラウドサービスのAPIを選択しなければなりません。その基準は様々あります。日本にデータセンターがある、料金が安い、機能が豊富、日本語サポートが可能、関連資料が充実、コミュニティが活発、営業が熱心、広告宣伝でよく見かけるなどなどです。　Webサービスのように、自社開発したWebアプリケーションを、特定のクラウドのインフラサービスで利用するのであれば、ガラパゴス的なエコシステムであっても大した影響はないかもしれません。しかし、クラウドサービスとオンプレミスの次世代ITインフラを連携させハイブリッドクラウドとして利用するためには、クラウドサービスのAPIを取り巻くエコシステムの大きさや充実度を選択の基準に加えることが重要になります。　すぐに活用できるアプリケーションの選択肢が増え、ハイブリッドクラウドへの移行がスムースになり、かつ将来のクラウドサービス間の相互接続がもたらすメリットを優先的に、かつ主体的に享受できる可能性を高められるからです（図3）。

　次回は、「マルチテナント」について解説します。

図2：クラウドサービスAPIのエコシステムの概念

図3：クラウドサービスAPI間の連携


Webアプリケーション

サードパーティ

パートナーコンサルタント

コミュニティ

インテグレーター

プライベートクラウド

オンプレミス

パブリッククラウド

クラウドゲートウェイ

ファイル同期・共有セキュリティ

サーチ

BI アーカイブ

階層化

ビッグデータ分析

バックアップ

クラウドサービスのAPI


オンプレミス

クラウドA クラウドB

クラウドD

クラウドCクラウドブローカー

国内地域冗長のために提携

データバックアップ、アーカイブ

データの種類や料金で使い分け

国外リージョン提供のために提携

容量確保のために提携

24

複数ユーザーが 1つの ITインフラを利用するのと、複数の組織やグループが 1つの ITインフラに同居するのとでは、ITリソースの利用効率が異なります。1つの ITインフラに複数の組織やグループが同居できれば、サイロ化を防げ、コストや運用作業の軽減が図れるほか、組織単位でリソースを効率的に管理できます。これがマルチテナントのメリットです。

リソースの管理効率を高めるマルチテナント第8回

「複数ユーザー」と「マルチテナント」は異なる

　ITシステムにおけるマルチテナントは一般に、「複数のユーザーが1つのITシステムを共有すること」と定義されることが多いようです。しかし、この定義では多少

の誤解を招きます。というのも通常、アプリケーションは複数のユーザー（マルチユーザー）が利用することを前提に開発されており、ITシステムを複数のユーザーが利用するのは当たり前とも言えます。そのため、「複数のユーザー」ではなく、あえてマルチテナントと呼ばなければ、

その理由と特徴が分かりにくくなります。　そもそもテナントとは、賃貸借契約のもとで不動産を借り受ける個人や店舗、事務所のことです。マルチテナントとは、複数のテナントが、賃貸マンションやアパート、商業施設、オフィスビルに同居することです。店舗や事務所の場合には社員がおり、これらの社員が施設を利用する実際のユーザーです。　ITインフラにおけるマルチテナントも考え方は同じです。クラウドサービスは、クラウドという同居施設をWebサービスやアプリケーションといった複数のテナン

マルチテナントの定義：ITシステムを構成する物理装置やソフトウェア、データベースなどに複数の組織やグループ（テナント）が同居する環境、およびその仕組み

図1：マルチテナントの階層構造


システム管理者

テナント

管理者

ユーザー


25

図2：ITインフラのマルチテナント


ユーザー

システム管理者

「仮想化＋分散処理」次世代ITインフラ

テナント

管理共通部門

課金・利用料管理・グループ管理

研究開発

テナント

設計製造

テナント

運用

テナント

マーケ

テナント

営業

監視・統計システム管理

トが賃貸借契約で利用しているようなものです。多くの場合、それぞれのWebサービスやアプリケーションを利用する実際のユーザーがいます。　企業や組織であれば、各部門やプロジェクトがテナントであり、そこに所属する社員がユーザーです。1つのITインフラに各部門やプロジェクトが同居しますが、リソースやデータは論理的に他のテナントから隔離され、独立しています。テナントに所属するユーザー間も同様です。　つまり、マルチテナントでは、テナントが管理単位です。システム管理者がテナントを、テナント管理者がユーザーをそれぞれ管理するという階層構造があることが前提になります（図1）。テナント管理者は、ユーザーが利用するリソースやデータにアクセスができますし、ユー

ザー間では、許可したデータを共有できます。

マルチテナント対応のITインフラは運用効率が高い

　マルチテナントの仕組みは、アプリケーションやデータベースで実現されている場合もあれば、ITインフラとして実現されているケースもあります。　アプリケーションを利用するユーザーの視点からすれば、いずれの方法で実現されていても大きな違いはないかもしれません。しかし、ハイブリッドクラウド時代に企業が導入する次世代ITインフラにおいては、ITインフラ自体がマルチテナントに対応している方が、より大きなメリットを得られるでしょう（図2）。　マルチテナント対応で得られるメリット

の多くは、第2回の「仮想化」の中で説明しました。複数のテナントがサーバーやネットワーク、ストレージのリソースを論理的に隔離された状態で独立して利用するためには、テナントそれぞれに物理的なリソースを割り当てるのではなく、仮想化されたリソースを割り当てることで実現されるからです。　1つのITインフラに同居できることで、物理的なサーバーやストレージのITインフラが部門やアプリケーションごとにサイロ化することを防げます。同時に、複数部門やプロジェクトのITインフラを集約することでコストを低減できます。アップグレードなどの作業においても、複数のITインフラを個別に管理するよりも運用作業を軽減できます。　部門単位やプロジェクト単位の収支管理の面でも、マルチテナントは有効です。

26

テナントを管理単位にすることで、ITインフラの利用量を組織単位で把握しやすくなります。利用量に応じた課金（チャージバック）をすることで、部門やプロジェクトが、それぞれのITインフラコストを意識できます。　特に、部門やプロジェクトによって、リソースの使い方は異なります。全社的な観点から、ITインフラコストを厳格にコントロールしたいのであれば、それぞれのテナントごとの利用量の敷居値を管理できる仕組み（QoS：Quality…of…Service）を備えることも1つの方法です。　いずれの場合も、ITインフラの同居単位を、ユーザーではなく、テナントという組織単位にすることで、ITインフラの管理が効率的になります。それは、共同施設オーナーが、店舗やオフィスを利用する社員ではなく、テナントを単位として管理することと同じです。

マルチテナント対応ITインフラにもセルフサービス化が必要

　アプリケーションのマルチテナント化は比較的容易です。既存のアプリケーションをクラウドサービスの S a a S（Software…as…a…Service）として提供できるようにするための製品が発売されています。　これに対し、既存のITインフラを改造しマルチテナント化することは、その及ぼす範囲や影響が大きく簡単ではありません。ハイパーバイザーや、ネットワーク、ストレージのそれぞれについて、各

図3：マルチテナントを実現するITインフラ製品の連携


テナントテナントテナントテナントテナント

ハイパーバイザー製品

ネットワーク製品

ストレージ製品

VM VM


VM

社が提供するマルチテナント対応製品や、それらを連携させるソリューションを使いながら、マルチテナントに対応した次世代ITインフラを構築することになります（図3）。　その際、ITインフラで実現するマルチテナントは、仮想マシンや、ネットワーク、ストレージのリソース制御も含めて、その運用はテナント管理者に任せることになります。　ITインフラ全体を管理するシステム管理者は、情報システム部門が担当することになると思いますが、テナント管理者は事業部門に任せることが多くなりそう

です。ただし、仮にその事業部門がアプリケーション開発部門であっても、ITインフラのリソース管理にまで熟知している開発者は多くはないのが現実です。　クラウドのインフラサービスと同等のセルフサービスであれば、すでに使い慣れている多くの開発者がいます。そのため、マルチテナントのメリットを享受するためには、次世代ITインフラはクラウドサービスと同等に変革してゆくことが重要になるのです。

　次回は、「次世代 ITインフラにおけるデータ保護」について解説します。


27

クラウドと同等の次世代 ITシステムは、経済性の観点から汎用サーバーを多数使って構築します。半面、ハードウェアに障害が発生する率も高くなります。それを前提に、データのバックアップやアーカイブにオンラインで対応するだけでなく、保存したデータを消失することなくサービスを継続できる、堅牢なデータ保護の仕組みを備えていなければなりません。

ハードが壊れてもデータを保護できるITインフラに第9回

バックアップはデータを元の状態に戻すための手段

　データ保護は、文脈に応じてさまざまな意味合いで使われる用語です。不正アクセスから守ることや、安全なデータ管理などを指すこともあります。今回は、ITインフラにおけるデータ保護を対象にします。　ITインフラにおけるデータ保護とは、ハードディスクやサーバーといった物理的なハードウェアが故障したとしても、保存・格納しているデータを消失させないことです。　データ保護の代表的な方法は、バックアップです（図1）。定期的にデータを複製

しておき、必要な際に復旧（リストア）することでデータの消失を防ぎます。その対象はファイルだけではありません。例えば仮想サーバーは、ハイパーバイザーというソフトウェアで構築されているため、物理サーバーに障害が起これば仮想サーバーも失われます。速やかな復旧のためには、仮想サーバーのイメージやテンプレートもバックアップの対象になります。　バックアップと混同されることも多いのがアーカイブです。アーカイブとは、データを整理したうえで、長期保管することです。復旧のためのバックアップとは本来の目的が異なります　バックアップ、特にアーカイブでは、DVDや磁気テープといった外部メディア

にデータを移動し保管することがあります。オフラインの媒体に保存した場合、データを元に戻すには時間がかかります。この点でも、アーカイブは迅速な復旧のためというよりは、世代管理や、記録、証拠といった安全対策が目的です。　オフラインではないものの、読み出しに時間のかかるオンライン、すなわちニアラインによるデータ保管もあります。すぐに利用することがないデータを安価に長期保管するために、AWS（Amazon…Web…Services）の「Glacier」といったクラウドのアーカイブサービスも提供されています。　こうした不測の事態からの復旧のためのバックアップや、長期保管のためのアーカイブは、データを元の状態に戻すための仕組みです。しかし、ハードウェアなどに障害が発生しても、サービスを停止することなくデータを保護するためには、別の仕組みが必要になります。

データ保護（Data protection）の定義：重要なデータが破損したり、消失したりすることを防ぐこと、およびその仕組み

図1：データ保護の俯瞰図


データ保護の目的と種類

堅牢性（データを消失しない）可用性（サービスを継続できる）

データ格納先代表的なデータ保護の方式

ローカル単体処理ネットワーク経由・分散処理

アーカイブ

バックアップ RAIDDVD、テープなど外部記録メディア

ハードディスク、SSD

オフライン

長期保管

復旧

レプリケーション

イレージャーコーディング

オンライン

28

ハードディスクは必ず壊れる

　クラウドと同等に、経済的な汎用サーバーを多数使う次世代ITインフラでは、ハードウェアが故障することは想定の内です。データを実際に保存するハードディスクは、回転し続けるディスクに機械的な仕組みでデータを記録するため、ある程度利用し続ければ壊れるからです。　私たちが普段利用しているPCなどでも、ハードディスクが壊れ、大事なデータを読み出せなくなってしまったという経験はないでしょうか。こうした状況を可能な限りなくすには、例えば機械的な故障がないフラッシュなどの半導体メモリーを使うのも1つの対策です。しかし、大量データを扱うとなると、それなりのコストを覚悟しなければなりませんし、書き込み回数に制限があるなど別の問題が浮上してきます。　ハードディスク障害に備えたデータ保護においては、現時点では「RA I D（Redundant…Arrays…of…Inexpensive…Disks）」を採用するのが一般的です。RAIDとは、複数のハードディスクにデータを複製（ミラーリング）または分割・分散して保存すると同時に、物理的な装置を隠ぺいする仮想化により、複数のハードディスクをあたかも1つの格納場所（ドライブ）として扱う仕組みです。　ここで説明したRAIDは、単体サーバーに内蔵されたハードディスクの故障に備えたデータ保護です。複数のサーバーを統合制御する分散処理形態では、

サーバーそのものが故障してもデータを消失しない仕組みが用意されています。

分散処理のデータ保護は速さとコストのトレードオフ

　分散処理におけるデータ保護の基本的な考え方は、単体サーバーにおけるデータ保護と同じです。データを複製するか分割するかして複数のサーバーに保存しておきます。

（1）複製方式によるデータ保護　データを複製して保護することは、単体サーバーではミラーリングと呼びますが、ネットワーク経由で複数のサーバーを使う分散処理やデータベースでは「レプリケーション」と呼ばれます。　レプリケーション方式は、データを単に2重化するだけではなく、複製する数

と格納するサーバー数を増やすことで、データ保護に対する堅牢性を高めています（図 2）。一般的なデータ保護方式で、分散処理フレームワークの「Apache…Hadoop」や分散型NoSQLデータベースである「Apache…Cassandra」などのOSS（Open…Source…Software）でも使われています。　ただし、レプリケーション方式は、データ量が複製数の倍に増えるため、それに見合ったディスク容量を準備しなければならずコスト高になります。

（2）分割方式によるデータ保護　レプリケーションによるディスク容量の増大を回避するための方法が、分割（イレージャーコーディング）方式によるデータ保護です。オブジェクトストレージで使われています。　イレージャーコーディングでは、1つの

図2：レプリケーションの仕組み


クライアントからファイルを保存

指定した数の複製を保存後、処理完了を通知

複製複製


29

データを複数に分割し、分割したデータとは別に「消失訂正符号（パリティ）」を追加します。そして、分割したデータと消失訂正符号を、別々のサーバーにそれぞれ保存します（図 3）。消失訂正符号は、欠損したデータを復元するためのもので、サーバーが故障し、そこに保存されていた分割データの一部が読み出せなくなっても、元のデータに復元できるようにします。　分割数や方式にもよりますが、イレージャーコーディングでは元データの0.2～0.5倍程度のデータ量が追加されるだけなので、少なくとも2倍以上のディスク容量を必要とするレプリケーションと比べ経済的だといえます。　ただし、イレージャーコーディングの場合には、少なくともデータの分割数と消失訂正符号の数を合わせただけの

図3：イレージャーコーディングの仕組み


データを複数に分割

分割データと消失訂正符号を別々のサーバーに保存

消失訂正符号を付加

サーバー台数が必要です。そのため、小規模からのスタートには適していません。データを復元する際には、複数のサーバーからデータを集め再構築する必要があり、読み出す時間がかかります。　つまり、レプリケーションはコストは高いが読み出しは速い、イレージャーコーディングはコストは低いが読み出しは遅い、というトレードオフの関係となります。従って、次世代ITインフラのデータ保護においては、アクセス頻度の高いデータにはレプリケーションを使い、アクセス頻度の低いデータのアーカイブにはイレージャーコーディングを使うなど、目的に応じて使い分けることが望ましいでしょう。

　次回は、「マルチデータセンター」について解説します。

30

ハイブリッドクラウド時代の次世代 ITインフラでも、DR（Disaster Recovery：災害復旧）／BC（Business Continuity：事業継続）対策のために複数のデータセンターが必要になります。パブリックなクラウドサービスを活用しながらも、外部には預けられない重要なデータはオンプレミスに保存することになるからです。さらに、単なるバックアップ用のデータセンターを追加するのではなく、複数のデータセンターを一体運用できる「マルチデータセンター対応」が求められます。

DR／BCにはマルチデータセンターが不可欠第10回

ハイブリッドクラウド時代にも複数のデータセンターが必要

　第9回で、次世代ITインフラにおけるデータ保護について説明しました。ただし、そこで取り上げたのは、サーバー内蔵のハードディスクやサーバー自体に障害が起こってもデータを消失することなく保護する仕組みでした。いずれも、1つのデータセンター内で起こり得るリスクです。

　これに対し、「マルチデータセンター」は、複数のデータセンターがITインフラのリソースを共有することで、仮に1部のデータセンターに障害が発生してもデータを保護し、かつサービスを継続するための仕組みです。　クラウドサービスは、「いつでも使える」という可用性の高さがメリットの1つです。それが提供できるのは、マルチデータセンター対応をしているからです。ですので、クラウドサービスをDR

（Disaster…Recovery：災害復旧）／BC（Business…Continuity：事業継続）対策として活用することは有効な方法です。ちなみに、DRは災害が起きた際にITシステムを復旧できることであり、BCはDRを含め事業を継続するためのプロセスや手順のことです。　ただし、次世代ITインフラにおいても、マルチデータセンター対応は必要です。なぜなら、今後はクラウドサービスとオンプレミスを使い分けるハイブリッドクラウド展開が主流になるからです（図1）。　ハイブリッドクラウドの場合、オンプレミスには、頻繁に利用するデータや外部には預けられない機密データを保管。それ以外のデータはクラウドサービスに預けるといったケースが多くなるでしょう。

マルチデータセンター（Multi Datacenter）の定義複数のデータセンターのITインフラリソースをネットワーク経由で共有するクラスターを構成し一体運用すること、およびその仕組み

図1：ハイブリッドクラウドにおける使いわけ


オンプレミスのデータセンター

クラウドサービス

● 頻繁に利用するデータ● 内部保管データ

● 頻繁に利用しないデータ● 外部保管データ


31

図2：一般的なDR／BC対策における複数データセンター


メインのデータセンター

サーバー

ネットワーク

ストレージ

バックアップ用データセンター

夜間等に定期的にバックアップ

サーバー

ネットワーク

ストレージ

いずれのデータも重要に保護されるべきであり、DR／BC対策が求められます。

単なるバックアップセンターでは不十分

　これまでも、DR／BC対策として複数のデータセンターでデータを保護するソリューションが多数提供されてきました。多くは、バックアップ用のデータセンターを追加するものです。メインのデータセンターと同じITインフラ環境を用意することで、災害時にはバックアップ用データセンターに切り替え、サービスを継続します（図2）。しかし、これはITインフラを2重に所有する方法であり、単純にコストが倍になるうえ、保守要員を考慮する必要もあります。　メインとバックアップの ITインフラ環境が常時同じであるためには、データの整合性も常に同じに保たれなければなりません。ネットワークを経由し、リアルタイムでバックアップ用データセンターと同期させるためには、充分なネットワーク帯域を確保する必要もあります。複数拠点で確実にデータが書き込まれたことを担保するために「2相コミット（Two-Phase…Commit）」といった仕組みを導入すると、IT機器への負荷増大やユーザーへの応答遅延、複数拠点での障害時の処理不能など、様々な技術的課題が浮上してきます。　こうしたことから、「バックアップが常時同じ」は現実的ではありません。DR／BC対策としては、復旧目標を定め、それが

実現できる仕組みに留めるのが一般的です。　復旧目標としては、復旧時間の目標である「 R T O（ R e c o v e r y … T i m e…Objective）」やデータ損失の程度に対する復旧時点の目標…の「RPO：Recovery…Point…Objective」」があります。RTO／RPOを満たすよう、その時間内で仮想サーバーなどのITインフラを再起動できるようにしたり、1日に数回もしくは夜中に非同期で複数のデータセンター間を同期させるたりするのです。　しかし、クラウド型のITインフラであれば、従来型のITインフラよりも柔軟にマルチデータセンター対応が可能です。当然ながら、仮想化は必須です。遠隔地にあるデータセンターに赴き、物理サーバーやネットワークを設定するようでは、適切な RTOは実現できません。仮想サーバーのスナップショットをデータセン

ター間で共有すれば、遠隔からネットワークを経由して同じ環境を設定できます。　一方、複数データセンターにおけるデータの整合性を常に保つ仕組みは、一部の分散型NoSQLデータベースやオブジェクトストレージに実装されています。マルチデータセンター対応の仕組みを、第9回で説明したレプリケーションを例に説明します。

複数のデータセンターを一体で運用する

　レプリケーションは、複数のサーバーにデータの複製を保存することで、サーバーに障害が発生してもデータを消失させない仕組みであると説明しました。レプリケーションのマルチデータセンター対応とは、1つのデータセンター内のサーバーだけではなく、ネットワーク経由

32

で別のデータセンターにあるサーバーにもデータを複製できることです（図3）。　その際、指定したデータの複製数が、複製数と同じ数のサーバーに保存されたことが確認できてから、クライアントに処理終了を通知します。従って、そのデータを次に読み出す際には、いずれのデータセンターにあるサーバーにアクセスしても、同じデータを得ることが保証されます。つまり、データの整合性が複数データセンター間で保たれるということです。　ただし、複製処理が完了するまでは、そのデータは読み出せません。複数のデータセンターにネットワーク経由で複製するため、データの書き込み処理が完了するまでの時間はかかります。　書き込み処理を早く終了させたい場合

は、サーバー間での複製が完了しなくても、例えば、1つのサーバーだけにデータを保存できた時点で、クライアントに書き込み終了を通知することもできます。　その場合、複製処理が終了するまでは、サーバー間でのデータの整合性は保てません。ですが、非常に短い時間を経て、複数データセンター間にあるサーバー内のデータは結果として同期が図れます。これを「結果整合性（Eventual…Consistency）」と言います。　この操作は都度、より完全同期に近い準同期で実施されるため、１日複数回しかデータの同期を図れない仕組みよりも、複数データセンター間におけるデータの整合性を高く保てます。　ここまで、同期・非同期の面から説明し

てきましたが、レプリケーションの仕組みで最も重要なことは、複数のデータセンターが1つのクラスターになり、その中のリソースをシェアしているということです。つまり、1つのデータセンターであろうが、複数のデータセンターであろうが、データを3つ複製するのであれば3台のサーバーが必要になります。　それを複数のデータセンターに構築したクラスター内のサーバーに分散して配置しているにすぎません。つまり、マルチデータセンターは、バックアップのデータセンターを追加する2重化とは、本質的に異なるのです。

　次回は、「オールウェイズオン」について解説します。

図3：マルチデータセンターレプリケーション。図は3複製の場合


データセンター2

複数データセンターにデータの複製完了後、処理終了を通知


複数データセンター間のデータを都度、完全に同期


データセンター1でデータの複製完了後、処理終了を通知


複数データセンター間のデータは短い時間後に同期（結果整合性）

データセンター1から2にデータを準同期で複製


33

第11回

クラウドと同等の次世代ITインフラはこれまで説明してきたように、仮想化に加え、経済的な汎用サーバーを使うために、多数のサーバーで大量の処理を並行して進める分散処理をコアテクノロジーに採用しています。高価で堅牢な専用装置ではないため、仮にハードウェアの 1 部が壊れたとしても、常にサービスを継続できるよう

「Always On（オールウェイズオン）」の仕組みを備えています。

ハードウェアが壊れても“Always…On”でサービスを止めない

図1：スタンドバイ構成のイメージ


サーバー

ネットワーク

ストレージ

VM VM


VM VM VM VM


VM

Always Onの基本はスタンドバイ構成

　この世の中に絶対に壊れないものや、24時間365日永遠に停止しないものが、果たして存在するのかは不明ですが、それに限りなく近い条件がITインフラには求められます。　利用できる度合いの高さは「Availability（可用性）」と言われます。可用性を高めるためには、ハードウェアやソフトウェアが故障する頻度が少なく、たとえ故障しても直ぐに復旧できるような信頼性の高さが重要な要件です。また、仮に故障したとしても、保守性に優れていれば、可用性は高くできます。　一方、故障が起こり得ると想定していても、Fail…over（フェイルオーバー）の仕組みが整っていれば、可用性を高く維持できます。フェイルオーバーとは、異常事態が発生した際に自動的に予備機に切り替わることです。人手で切り替えることはSwitch…over（スイッチオーバー）と言います。　このように、予備機に切り替えることで可用性を高める仕組みは、Stand…by（スタンドバイ）構成と呼ばれ、それを実現す

る各種製品やソリューションが多数用意されています（図1）。　例えばある製品では、次のような仕組みで仮想サーバーのスタンバイ構成を実現しています。

　まず、ハイパーバイザーが稼働する物理的なサーバーと、そのハイパーバイザーにより制御される仮想サーバーとを常にモニタリングすることで、物理サーバーの障害を自動的に検出します。そして、物理サーバーの障害により影響を受ける仮想サーバーをスタンバイ側の物理サーバー上ですぐに起動し、物理サーバーが停止したらすぐにスタンバイ側の仮想サーバーに切り替えます。　最近では、ハイパーバイザーが稼働する物理サーバーに障害が発生した場合に、事前に用意しておいたスタンバイ側の仮想サーバーを起動するのではなく、

Always On（オールウェイズオン）の定義：分散処理システムにおける高可用性（HA : High Availability）のこと。24時間365日、可能な限り停止時間をなくし、ITインフラが利用できる状態を継続すること、およびその仕組み。一般的には、スタンドバイ構成によって高可用性を実現しているが、それとは異なる仕組みのため、両者の違いを強調するために、Always Onと表現している。

34

影響を受ける仮想サーバーを別きょう体あるいは別拠点のハイパーバイザーに移行する機能を持つ製品も一般化してきました。これを「live…migration（ライブマイグレーション）」と呼びます。　またスタンドバイ構成のストレージ製品は、2つ以上のコントローラを備えています。仮に1つのコントローラに障害が発生しても、もう1つのコントローラに瞬時に切り替えることで、サービスを継続します。　ネットワーク製品も同様です。一部のハードウェアに障害があることでネットワーク全体に影響を与えてしまう単一障害点（SPOF：Single…Point…Of…Failure）がない構成にします。　このようなスタンドバイ構成は、最も一般的な実現方法であり、HA（H i g h…Availability）構成とも呼ばれます。しかし、従来の一般的なHA構成では、障害箇所やHAの方法にもよりますが、切り替え時にサービスが瞬断することがありました。実行中だった処理を取り消したり（rollback）や再適用したり（replay）するための仕組みが必要になり、サービスの“無停止”を実現することは簡単ではなかったのです。

理解しやすいマスター／スレーブ方式によるAlways On

　さて、大規模クラウドであれば、数千台を越えるサーバーが稼働しています。毎日数台のハードディスクやサーバーが故障することは当たり前だと想定してい

ます。そのため、クラウド型の次世代ITインフラでは、一部が故障しても、残り全員で仕事を分担することで、サービスの継続には何ら影響を与えない仕組みを備えています。　そのコアテクノロジーである分散処理には、マスター／スレーブ方式とP2P（Peer…to…Peer）方式があると第4回で説明しました。このうち、マスター／スレーブ方式のほうが、Always…Onの仕組みは感覚的に理解できるでしょう。　マスター／スレーブ方式では、全体に指示を出すマスターとなるサーバー（以下、ノードと言います）と、指示を受けるスレーブがあります。マスターはSPOFにならないよう2重化され、スタンドバイ構成を取ります。それ以外のスレーブ

ノードには予備機という考え方はありません。常にスレーブノード全員が均等に仕事を分担しています。　スレーブノードは、マスターノードから常に監視されており、仮に1部のスレーブノードに障害があれば、自動的にネットワークから切り離され、残ったスレーブノードだけでサービスを継続するよう指示されます（図2）。　故障したハードウェアは、人手で交換せざるを得ませんが、新規にノードが加わったことをマスターが認識すれば、自動的に再設定します。

少し複雑なP2P方式によるAlways On

図2：マスター／スレーブ方式におけるAlways…Onの仕組み


スタンバイ

マスターが故障したスレーブの仕事を

他のスレーブに割り振り

マスター

スレーブ


35

　一方、P2P方式の場合、指示を出すマスターが存在しないため、少々複雑です。クラスターを構成するすべてのノードが同じ役割をします。これらのノードは、ゴシップ・プロトコル（Gossip…Protocol）といった方法でお互いが通信し合い、相互の状態を監視し合っています。　外部からデータや処理要求が送られてくると、負荷分散装置であるロードバランサーがノードに対し均等に仕事を割り振り、そのなかで選ばれたノードが、そのデータや処理に責任を持ちます（図3）。　例えば、「データの保存」というリクエストがあれば、選ばれたノードは、障害のないノードに対し、データを複製して保存するよう指示します。その処理が完

了すれば、クライアントに通知します。「データの読み出し」というリクエストがあれば、データが保存されているノードを探し出し、そのノードへのアクセスを指示します。　障害が生じたノードの仕事は、残りのノードすべてで分担します。例えば、3複製でのデータ保護にもかかわらず、ノード障害があり、一部のデータが2複製になれば、残りのノードに新たな複製を作ります。　ここでも、故障したノードを取り換えることは人手です。しかし、ノードが取り換えられた時点で、あるべき姿に修復するための処理を実行します。新規にノードが追加された場合も、残りのノードと仕事の負荷が均等になるよう、ノード間で

自動調整を始めます。　従って、クラウド型の次世代ITインフラは、予備機に頼るのではなく、負荷を分散し合うことで可用性を高めています。これは、「負荷分散構成」とも言われています。　従来のITインフラは、ハードウェアに高い信頼性を求めることで高可用性を実現してきました。当然のことながら、それはコストにも反映されます。クラウド型の次世代ITインフラは、ハードウェアは壊れても大丈夫という仕組みをソフトウェアで実現することで、可用性に加え、経済性も高めているのです。

　次回は、「階層化」について解説します。

図3：P2P方式におけるAlways…Onの仕組み


正常時

ノードノード

ゴシッププロトコルでノードが通信し、相互に稼働状況を監視

異常発生時

故障したノード

故障したノードの仕事を他のノードが分担して継続

処理故障したノードが実行していた処理

36

クラウドと同等の次世代 ITインフラを構築しても、既存の ITインフラからの移行という課題があります。しかし、移行のためだけに一大プロジェクトを立ち上げて労力と時間をかけたくはありません。サービス停止やデータ消失などのリスクを抑えつつ、日々のオペレーションの延長線上で限りなくスムーズに実現したいものです。それを実現できるのが自動階層化です。クラウドサービスを階層に加えれば、ハイブリッドクラウド環境へ段階的に移行できます。

自動階層化（Auto-Tiering）で次世代ITインフラにスムーズに移行する第12回

経済性と効率性を同時に実現する

　何事につけ1分1秒を争う時代にあっては、「すべてのデータ処理は高速であるべき」と考えがちです。確かに、業務システムや基幹システム、データベースなどの処理には、マイクロ秒単位の処理性能が求められることは多いでしょう。　とはいえ、それらはコンピュータ処理のスピードです。人間がファイルサーバーにファイルを保存したりWebサービスを利用したりするのであれば、ミリ秒単位の処理速度で充分です。　つまり、ITインフラを構成するすべてのシステムが、高速で高性能である必要はありません。データの種類や目的に応じて、高速だけれども高価格だったり、低速だけれども安価だったりするシステムを適切に使い分けられれば、ITインフラ全体としての効率性と経済性を両立できます。　例えば、データを保管するための記憶媒体であれば、高速処理が必要なデータには、フラッシュメモリーのSSD（Solid…State…Drive）や、HDD（Hard…Disk…Dr ive）でも高性能・高信頼性な SAS（Serial…Attached…SCSI）を使う。大量に保管したいデータは、性能よりも価格を

重視したHDDのSATA（Serial…ATA）を使い分けるといったことです。　しかも、これらを別々に使うのではなく、処理要求があったデータを、まずは高速のSSDに保存し、一定のタイミング

で低価格のSATAに移動すれば、高速処理を保ちながらデータの保管コストを抑えられます。これが階層化のメリットです。　ITインフラにおけるストレージであれば、高速処理が可能なSAN（Storage…Area　Network）やNAS（Network…Attached…Storage）をプライマリーストレージとし、経済性と拡張性の高いオブジェクトストレージをセカンダリーストレージにするといった構成になります。

階層化（Tiering）の定義：データ保護や、処理速度、利用頻度などの特性に応じてデータを分類し、その最適な処理と保存のためにITシステムを使い分けること、およびそのための仕組み

図1：ITインフラにおける階層化のイメージ



オブジェクトストレージ

テープ、DVDなどの外部メディア

サーバー

HA（スタンバイ）

SAN NAS

VM VM


VM

プライマリーストレージ

高価・高速＝

セカンダリーストレージ

経済的・拡張性・大容量＝


37

それらに続く層として、オンラインやニアラインのクラウドサービスや、DVDやテープによる外部メディアが構成要素になります（図1）。　この階層化を都度判断しながら人手で対応していては、IT担当者のルーティン作業を増やすだけです。あらかじめ定めた保存期間やアクセス頻度といったポリシー基づき、自動的にデータを転送し階層化しなければなりません。これが自動階層化（Auto-Tiering）です。

8割のファイルはアクセスされない

　ある調査によれば、ファイルサーバーに保存された約8割のファイルは1年以

上アクセスされていません。つまり、2割程度のファイルは、頻繁に参照されますが、一定期間が過ぎれば放置されたままになるのです。　しかし、企業ではオフィス文書などのファイルが日々増えてゆく一方です。そのため社員は、IT部門から割り当てられたファイルサーバーの容量を越えないよう自身で管理し、不要なファイルを削除するというのが、一般的な運用ではないでしょうか。　ただ、容量を超えそうなファイルが本当に削除されていれば良いですが、小型の外付けHDDや個人向けのオンラインストレージに退避し、個々人が勝手に保管しているとなると少々問題です。簡単に持ち出せることになり、情報管理のリ

スクが高まります。　また、社員任せにせずIT部門が管理するにしても、所有者の承諾を得ずに勝手に削除する訳にもいきません。結果、社員に放置されたファイルがサーバーのディスク容量をひっ迫し、ファイルサーバーの買い換え、置き換えを繰り返すばかりになるのです。　ここに自動階層化を導入すれば、例えば、1年間アクセスのないファイルは高価なプライマリーのファイルサーバーから、経済的なセカンダリーのストレージに自動的に転送できるようになります(図2)。すなわち、データをライフサイクルに応じて管理するのです。このような管理手法を「ILM（Information…Lifecycle…Management…:…情報ライフサイクル管

図2：自動階層化のイメージ


自動階層化ツールサーバー


セカンダリーストレージプライマリーストレージファイルのサイズや更新日時、

利用頻度といったポリシーに応じて、ファイルを自動的に転送

長期間アクセスのないファイルをセカンダリーストレージに保管し、プライマリーの容量と性能を維持

38

理）」と呼びます。　自動階層化を実現する機能は、AST（Automated…Storage…Tiering）対応のストレージ製品が備えるほか、ストレージ製品のオプション、あるいは専用のツールやソリューションが提供されています。これらを使うことで、階層化管理に伴う面倒な作業やリスクの軽減を図ることができます。

クラウドとオンプレミスを自動階層化で使い分ける

　この自動階層化の仕組みは、既存のITインフラからクラウド型の次世代ITインフラへの段階的な移行に活用すべきです。　通常、ITインフラの刷新に当たっては、既存のストレージに保存されたデータを消失することなく、オールウェイズオンの状態で移行することに、周到な準備と慎重な作業が要求されます。そのため、既存のITインフラの構成を大きく変更するような一大プロジェクトを立ち上げるケースも少なくありません。　しかし、自動階層化を適用すれば、現行のストレージをそのまま使いながら、スケールアウト型の次世代ITインフラのストレージをセカンダリーとして利用できます。段階的にデータを移行し階層化すれば、現行のストレージも有効活用ができます。容量に余裕が生まれ、性能も高いまま維持できるからです。　さらに、内部で保存すべき機密データはオンプレミスに残し、外部に保管でき

るデータはオンラインやニアラインのクラウドサービスに預けるようにすれば、オンプレミスとクラウドを使い分けるハイブリッドクラウド環境も段階的に実現できます。　第1回で、ビッグデータがクラウド型の次世代ITインフラへの変革を促すと説明しました。ビッグデータは、オフィス文書などのファイルにとどまりません。これまで収集も保管もしていなかったようなログなど、多種多様なデータの塊です。いわゆるビッグデータ分析は、そのデータの塊に隠された宝物を探し当てるような作業です（図3）。　データの種類は今後、ますます多様化し、希少データとその他の大量データとが混在することになります。これらデータのすべてを一律均等に扱い続けること

は、データ管理の正しい姿ではありません。高価で高機能なストレージに、あるがままにビッグデータを保存しているようでは、あまりにも時代認識とコスト意識が低いと言わざるを得ません。　特に今、スケールアップにしか対応できないレガシーなストレージを使っているのであれば、データの増加スピードには充分注意を払うべきです。導入時には想定していないサイクルで置換作業を繰り返すことにもなりかねません。将来にわたり、想定外の作業を繰り返すことのないように自動階層化を使い、日々のオペレーションの中で次世代ITインフラへの移行を始めるべきです。

　次回は、「ハイブリッドクラウド」について解説します。

図3：ビッグデータ分析のイメージ


ビッグデータ

ビッグデータ分析では、大量データのなかから希少データを探しだす

長期間アクセスのないファイルをセカンダリーストレージに保管し、プライマリーの容量と性能を維持


39

第13回

ハイブリッドクラウドは、異種のクラウドを“適材適所”で活用することです。例えば、オンプレミスとパブリッククラウドでデータの格納先を使い分けたり、パブリッククラウドの仮想マシンを使いながらもデータはオンプレミスのストレージに保存したりするなどです。ハイブリッドクラウドを実現するためには、これまで説明してきたように、オンプレミスのITインフラをクラウド型に変革しなければなりません。

ハイブリッドクラウドはオンプレミスもクラウド型に変革

図1：ハイブリッドクラウドのイメージ


ハイブリッドクラウドマルチクラウドインタークラウドパブリッククラウドとオンプレミスの連携

同種パブリッククラウドの使い分け

パブリッククラウド間の相互接続


仮想サーバー

オンプレミス

仮想サーバー

分散ストレージ


分散ストレージ

データをバックアップ／階層化

料金、性能、機能、提供地域などで使い分け

クラウド間でレプリケーションクラウドブローカー





異なるクラウドを組み合わせてこそハイブリッド

　ハイブリッドとは本来、生物学的に異種を掛け合わせることで生まれる交配種を意味しています。最近では、ガソリンと

電気という異なる動力源を組み合わせたハイブリッドカーなどにおいて、交配可能な異種を組み合わせ使い分けることで新たなメリットが得られることが広く理解されています。　従って、ハイブリッドクラウドとは、パ

ブリッククラウドとオンプレミスのクラウド型ITインフラという異種のクラウドを組み合わせ、それらを使い分けることです（図1）。　ですので、オンプレミスのITインフラがクラウド型でない場合、それは異種のクラウドの組み合わせにならず、ハイブリッドクラウドには位置付けられません。正しく言えば、パブリッククラウドを活用するオンプレミスのITインフラ、もしくはハイブリッドITとでも表現されるべきでしょう。

ハイブリッドクラウド（Hybrid Cloud）の定義：オンプレミスとパブリックという異種のクラウドを連携して使い分け、両者のメリットを最大限活用すること、およびそのための仕組み

40

　これも混同されることが多いのですが、同種のクラウドであるパブリッククラウドを組み合せたのであれば、それはマルチクラウドです。さらに同種のクラウド同士が相互に接続し補完し合うことはインタークラウドであり、いずれもハイブリッドクラウドとは区別が必要です。

企業の「できない」という事情をハイブリッドクラウドで解消

　今、ITインフラがハイブリッドクラウドを指向しているのは、パブリッククラウドとオンプレミスを連携させ使い分けることに、明らかな合理性があるからです。　多くの企業には、パブリッククラウドにすべてのITインフラを依存したり、データを預けられないという事情があります。ネットワーク経由での処理では性能要求が満たせないことや、機密データを外部には預けられないなどが理由です。しかし、機密性のないデータであれば、パブリッククラウドと連携できれば、オンプレ

ミスで処理して保存するデータ量を適正な水準に維持できます。　預けられないという理由に該当しない、ソーシャルメディアやデジタルマーケティング、IoT（Internet…of…Things:モノのインターネット）やM2M（Machine…to…Machine）などによる機器間通信のログデータの収集とその分析、キャンペーンなどで突然アクセスが増える（バーストする）ような処理であれば、インターネット側にあるパブリッククラウドで扱う方が効率的です。　つまり、ハイブリッドクラウドは、パブリッククラウドとオンプレミスのいずれかに偏ったITインフラよりも多くのメリットを企業にもたらすのです。では、ハイブリッドクラウドは、どのように活用すれば新たなメリットをもたらすのでしょうか。いくつかの例を挙げましょう。

【活用例1】データをハイブリッドに保存・格納する　外部に預けられない機密データはオン

プレミスに、それ以外はパブリッククラウドに保存・格納することがハイブリッドクラウドの典型的な使い分けの例です。ですが、それだけではありません。　オンプレミスとパブリッククラウドによるデータ階層化が可能になります。つまり、利用頻度や、データのサイズ、アクセス頻度といったデータ特性に応じてデータを分類し、オンプレミスとパブリッククラウドに階層を設けて保存・格納するのです。　これにより、オンプレミスでプライマリーに使うフラッシュアレイのような高性能のストレージ装置に全データを長期間保管しなくて済みます。スケールアップが必要になるストレージ装置の置換サイクルを伸ばし、運用コストを適切に維持できるようになります。　同様に、DR（Disaster…Recovery:災害対策）／BC（Business…continuity：事業継続）対策の延長として、データの格納先にパブリッククラウドを追加すれば、信頼性や可用性をより高められます。

図2：ハイブリッドクラウドにおける処理と保存の使い分け



オンプレミス


仮想サーバーパブリッククラウドでアプリケーションを処理するが、データはオンプレミスに保存



41

【活用例2】パブリッククラウドで処理し、オンプレミスに保存する

　パブリッククラウドが提供する仮想マシンだけを使い、データはオンプレミスのストレージに保存するという活用方法があります（図2）。　例えば、インターネット経由でファイルを同期させながら、複数の利用者で共有し、協同作業ができるサービスやアプリケーションでは、パブリッククラウドの仮想マシン上でアプリケーションを稼働させ、ファイルの格納先としてオンプレミスのオブジェクトストレージを指定できるものがあります。ファイルは暗号化されるなど、インターネットを経由するうえでのセキュリティ面での対策が取られています。　他にも、ビッグデータ分析をクラウド上で提供するサービスなど、様々なアプリケーションが、クラウドサービスの仮想マシン用としてマーケットプレイスにも公開されています。こうしたアプリケーションをクラウドサービスの仮想マシンを使って運用し、データだけはオンプレミスやプライベートクラウドに保存・格納するのがハイブリッドな活用方法です。

【活用例3】パブリッククラウドで開発しテストする　開発環境と本番環境をハイブリッドに使い分けるという方法があります。つまり、開発時はクラウドの仮想サーバーを使い、ソフトウェアを作っては壊しを繰り返し、完成した時点で本番環境をオンプレミスに構築するというものです。

　この延長線上には、β版のようにテストサービスとしてリリースし、利用者の反応を見極めたうえで、本番サービスをオンプレミスで提供することも考えられます。ただし、テストサービスの段階から人気を博し、クラウドサービスへの支払額が膨大になったり、オンプレミスへの移行に苦労したりという“うれしい悲鳴”をあげることがあるかもしれません。

ハイブリッドクラウドへの道は、まず“適材”への変革から

　ここまで説明してきたように、ハイブリッドクラウドの本質は「適材適所」です。適材適所の語源は、森林に囲まれた日本が、伝統的な日本家屋や寺社などに、適切な木材を適切な場所で使い分けてきたことにあります。日本企業にとって、この考え方は至極自然に受け入れられるのではないでしょうか。　ただ繰り返しますが、オンプレミスのITインフラは、クラウドと同等な“適材”になることで初めて、ハイブリッドクラウドの“適所”に活用できるようになるのです。クラウドと同等となるITインフラのキーワードをまとめると、以下の通りになります。

●「仮想化＋分散処理」をコアテクノロジーにしている

● 汎用サーバーをハードウェアに使うソフトウェア定義である

● スケールアップに対応できるスケールアウト型である

● セルフサービスとAPI（Application Programming Interface）によって利用者の利便性を高める

● マルチテナントにより効率的に管理できる

● ハードウェア障害が起こってもデータを消失しない

● マルチデータセンターによりDR／BC対策が打たれている

● 障害発生時にもサービスが停止せず“オールウェイズオン（Always On）”である

　そうです、本書で取り上げてきたキーワードは、すべてハイブリッドクラウドのためのキーワードです。クラウドやテクノロジーの最前線にいるITインフラエンジニアであれば、これらのキーワードは理解しているはずです。ただ、既存システムを安定的に運用し続けることも求められるITリーダーや企画担当者にすれば、まだ先の話に聞こえたかもしれません。　しかし近い将来、これらのキーワードが満載の次世代ITインフラの導入を提案されるはずです。なぜならグローバル市場での競争相手は既に、次世代ITインフラの導入に着手し、そのメリットを享受し始めており、ITベンダー各社も顧客ニーズに応える形でハイブリッドクラウドを見据えた品揃えの強化に舵を切っているからです。　そうした次世代ITインフラの提案をスピード感をもって的確に評価し、正しい意思決定につなげられることに、本書が少しでもお役に立てば、望外の喜びです。


111111

111

0000000

1

0000

000

111

0

0000000

000

1

0

1

1

0

0

1

0

0

1

1

0

0

0

1

000000

00

111

000

0

11

1

11110000000000000000000000000000000000000000011111111111111000000000000000000000111111111111111111111000000000000000000000000000000000011111111111111111111111

0

00

1

0

0

1

1111111111

11111111111111111111111111

000000000クラウディアン株式会社〒 150-0002 東京都渋谷区2-11-6 ラウンドクロス渋谷6F電話：03-6418-6466 Email：[email protected]

Cloudian、Cloudianロゴ、HyperStoreは、Cloudian Inc&KKの登録商標か商標です。他の商標は、すべて各所有者の資産です。

インプレス「IT Leadersオンライン」より転載

ハイブリッドクラウド時代必修 ITインフラの基礎知識 · 2020-02-13 ·...

Documents

Transcript of ハイブリッドクラウド時代必修 ITインフラの基礎知識 · 2020-02-13 ·...