IaaS、PaaS、SaaSをどう組み合わせるか
「マルチクラウド」と「ハイブリッドクラウド」を徹底比較 意外なIT担当者の認識
マルチクラウドとハイブリッドクラウド、いずれのアーキテクチャも事業に柔軟性をもたらす。関連するパブリッククラウドとプライベートクラウドがどれだけ統合されているかの程度が、この2つの違いだ。
「マルチクラウド」はIT用語としては新しい。「パブリッククラウド」「プライベートクラウド」「エンタープライズクラウド」「ハイブリッドクラウド」などの用語は以前からあるが、どれもマルチクラウドが持つアーキテクチャを説明するものでないことは明らかだ。では、マルチクラウドという不思議な環境は厳密にどのようなもので、他のクラウドとはどう違うのだろうか。
用語から明らかなように、マルチクラウドには複数のクラウドが含まれている。これについてはハイブリッドクラウドも同様だ。だが、マルチクラウドとハイブリッドクラウドには大きな違いがある。その違いによって市場の注目はわずかにマルチクラウドの方に集まっている。
ハイブリッドクラウドは1つの独立した存在だ。プライベートクラウドと1社以上のパブリッククラウドが混在するものと定義される。SaaS(Software as a Service)、IaaS(Infrastructure as a Service)、PaaS(Platform as a Service)、その他の「as a Service」の任意の組み合わせになる。複数のクラウドの組み合わせでも、ハイブリッドクラウドは単一の存在を表す。
マルチクラウドとハイブリッドクラウドの本質的な違い
マルチクラウドは本質的に1つの存在ではない。寄せ集めて管理する必要がある一連の複数の存在だ。
マルチクラウドとハイブリッドクラウドという用語は、意味論的に見ればこの2つを置き換えても大きな支障はない。だが一般的に、ハイブリッドクラウドにはパブリッククラウドとプライベートクラウドが混在している一方で、マルチクラウドは運用するクラウドの種類を区別しない。マルチクラウドにはプライベートクラウドが一切含まれないこともある。「Amazon Web Services」(AWS)と「Microsoft Azure」で大半のものを運用し、Googleの「G Suite」を一部利用する――これもマルチクラウドの環境だ。
マルチクラウドとハイブリッドクラウドを比較する際、意識すべき違いがもう一つある。マルチクラウドの環境ではクラウド同士が統合されずに運用されてもよく、それがマルチクラウドを複数の存在であると表現する理由だ。一方でハイブリッドクラウドは、コンポーネントが統合されて、結合した単一の存在になるという思い込みがあるようだが、それは誤った想定だ。
クラウドの進化
クラウドに対するユーザーの考え方が変わってきたように、クラウドを説明する用語も以下のように変化している。
- プライベートクラウドでは、全てが企業のデータセンター内に存在する。サービスには独自のサンドボックスがあり、アプリケーションはモノリシック(全体が1つのモジュールでできていること)な設計になっている。
- パブリッククラウドはデータセンターの外部にある。サービスとアプリケーションが中心で、各アプリ間は境界線で区切られている。クラウドでの利用を前提とするアプリケーションはモジュール構造になる。だがユーザーは考え方を変えずに、この環境をまだデータセンターとして扱っている。
- ハイブリッドクラウドは、プライベートクラウドとパブリッククラウドの両方の要素が入っている。それぞれは分離しているが、両方で全体が形成される。大抵の場合はアプリケーション中心の利用となっている。分散アプリケーションの始まりでもある。
- マルチクラウドでは、アプリケーションをクラウド全体に広げることができるが、必須ではない。アプリケーションのコンポーネントは、理にかなった場所ならどこにでも配置できる。ユーザーはデータセンターのことを考えなくなっている。ユーザーはアプリケーションのコンポーネントを結び合わせる大規模なファブリック(各ハードウェアを高速のインターコネクトでつないだシステム)だと捉えている。
このリストは変遷を示すことを意図しており、包括的に説明しているものではない。
マルチクラウドとハイブリッドクラウドのメリットを比較
ハイブリッドクラウドは、オンプレミスのプライベートクラウドとパブリッククラウドの両方からサービスを利用できる柔軟性がある。両方のクラウドにワークロードを導入することもできる。例えば重要なセキュリティ要件がある、業務を遂行する上で不可欠なワークロードは、企業がインフラやソフトウェアスタックを制御するプライベートクラウドに導入する。Webサーバやテスト環境など、その他のワークロードはパブリッククラウドに導入することが多い。これにより、企業ではワークロード全てについて、プライベートクラウドのインフラに全面的に投資する必要がなくなる。パブリッククラウドに導入するワークロードには、使用したリソースに対してのみコストを支払うことが可能だ。
ハイブリッドクラウドでは、パブリッククラウドが持つ拡張性を活用して、必要に応じて負荷の大きな処理ができる。大規模な「Apache Hadoop」クラスタの作成を伴うビッグデータ分析などだ。また、企業がクラウド間でリソースを共有できるようにもなる。ワークロードのデータがパブリッククラウドに保管されていても、プライベートクラウドからそのワークロードを実行できる。リソースのコストが変動型である利点を利用して、ネットワークトラフィックに応じてパブリッククラウドとプライベート間でワークロードを移行させることも可能だ。
マルチクラウドではその環境全体が作業場になり、パブリッククラウドとプライベートクラウドをさまざまな組み合わせで利用することができる。それらを密接に統合することは必ずしも要求されない。当然、サービスの利用方法によっては統合が推奨される場合もあるが、本質的に必要なものではない。例えば、いずれかのクラウドに障害が生じた場合の保護を目的として、分散アプリケーションの異なる要素をマルチクラウドに導入する。
マルチクラウドでは、アプリケーションやワークロードを構成する個別のコンポーネントを企業やアプリケーション開発者が選ぶこともできる。乗り越えるべき技術的なハードルは存在しない。開発者は単一のベンダーから提供されるものを我慢して利用するのではなく、自身のニーズを満たす特定のサービスを選択できる。
デメリットを比較
ここまでのマルチクラウドとハイブリッドクラウドの説明では両アプローチのメリットを紹介してきた。とはいえ、デメリットも存在する。ハイブリッドクラウドでは導入と保守が複雑になることがある。ハイブリッドクラウドに適用するプライベートクラウドの要素を導入することは、それ自体が大変な作業になる。インフラに関して広範囲に及ぶ責任が生じ、担当者に高い専門知識が求められる。その上、ハイブリッドクラウドのモデルになるには、プライベートクラウドに加えて、ソフトウェアスタックが利用できる1社以上のパブリッククラウドを統合しなければならない。プライベートクラウドを複数のパブリッククラウドと統合する場合は、さらに大変で複雑な作業になる。
ハイブリッドクラウドには独自の管理やセキュリティ、オーケストレーションに関する課題もある。合理的な効率性の水準を保つために、できる限り詳細にプライベートクラウドとパブリッククラウドの両面を統合することが推奨される。そのためには、統合された一貫性のあるID管理と認証のプロセスを実現する方法が必要になる。統合するサービスによっては、他の脆弱(ぜいじゃく)性が潜んでいることも注意する必要があるだろう。例えば、APIのトラフィック交換のセキュリティ保護などだ。オーケストレーションの観点では、パブリッククラウドのコスト、セキュリティ、トラフィック、可用性などの基準によって、ワークロードの配置先を決定できるインテリジェントなツールがハイブリッドクラウドで求められる場合もある。
マルチクラウド構成を使用すると、セキュリティの問題が次々と起こるだろう。使用するクラウドが増えるほどセキュリティの課題は大きくなる。セキュリティについては、攻撃対象領域にハッカーが攻撃を仕掛けてくる恐れがあることを忘れてはならない。マルチクラウド環境にサービスを追加すればするほど、攻撃対象領域は広がり、悪意のある攻撃者が弱点を見つける機会を増やす。
マルチクラウドでは気を付けなければコストが手に負えない状況に陥る可能性がある。クラウドの請求額が急増して驚くユーザーは少なくない。複数のクラウドを使用しているとそうした状況はさらに悪化する。データベースのクエリの構築が不完全だと、CPUが過度に使用されて予算に大損害を与える恐れもある。
最後に、ガバナンスの問題がある。適切なガバナンスと監視によって大半のデメリットに対処することができるが、ガバナンスが適切に実施されていない企業は少なくない。一部の開発者は依然としてガバナンスと指揮統制の取り組みを同一視している。それは全くの見当違いといえる。ガバナンスは今後成功するための土台を作るものだ。一方、指揮統制は、悪者によって引き起こされる出来事に対処する通常の取り組みだ。適切なガバナンスによって、開発者や組織が有益な成果を生み出すための活動にますます集中できるようになるし、許容できないほどのリスクも回避できるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[株式会社マクニカ] アイカ工業に学ぶ脆弱性対策 情シスが把握できずにいたアセットも正確に把握 -
製品資料
[株式会社マクニカ] 「脆弱性総まとめ」解説 被害事例から考える必須の対策ポイント -
製品資料
[Splunk Services Japan合同会社] サイバー脅威「トップ50」完全解説ガイド、新たな攻撃手法に対抗するには -
製品資料
[株式会社うるる] 「入札市場」完全ガイドブック:メリットから資格取得のポイントまで -
市場調査・トレンド
[株式会社うるる] はじめての「自治体/官公庁入札」 必要な知識がすぐに学べる入門ガイド
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
2
Oracle巨大ITプロジェクトはなぜつまずいたのか 8年で導入1割、追加で170億ドル
-
3
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
4
ISMSの“コンサル丸投げ”が招く数千万円の無駄 NTTドコモビジネスの脱出劇
-
5
「VMware離れ」は本当か 3000社がVCF 9にかじを切った現実的な理由
-
6
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
7
「AI活用を前提とした業務PCへの移行」に関するアンケート
-
8
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4%
-
9
「技術屋」で終わらないために 情シスが今取るべき認定資格5選
-
10
Netflixのバックエンドは「ほぼJava」 3000超のアプリを支える開発基盤の裏側
ホワイトペーパーランキング PR
-
1
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
2
AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
-
3
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
4
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
5
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
6
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
7
PostgreSQLの「機能」「性能」「運用」「拡張性」に関する悩みの解消法
-
8
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
9
Macの安全神話は崩壊? 最新の脅威動向から見えた攻撃のトレンドと有効な対策
-
10
情報セキュリティ対策早分かりガイド:25の自社診断で弱点と解決策を理解
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー