顧客が求めるパブリッククラウドの移植性
IaaSのマルチクラウド対応を比較 AWS、Azure、Googleの共通点と違いは?
主要IaaSベンダーはある種のマルチクラウドに対応するサービスを提供しているが、顧客が望むシームレスな移植性を実現するためにやらなければならないことは残っている。
大手IaaS(Infrastructure as a Service)ベンダーは、伝統的に自社のプラットフォームと他のパブリッククラウドとの間で、ワークロードの移行を容易にするための相互運用性の標準を策定してこなかった。だがマルチクラウドモデルに対する企業の関心が高まるにつれ、こうした姿勢を見直しているベンダーもある。
Amazon Web Services(AWS)、Microsoft、Googleなどの大手ベンダーには幾つかの大きな違いがあるものの、マルチクラウドのサポートについては多くの共通点を持っている。まず、どのベンダーも主にサービスまたはAPIドリブンということだ。これにより、ユーザーはAWS、Google、Microsoftの各クラウドテクノロジーのサービスやAPIを組み合わせ、アプリケーションを構築、実行できる。一般的にクラウドベンダーが自社のサービスをAPI経由で公開している場合、ベンダーのプラットフォームでアプリケーションがホストされていなくても、ユーザーや他のベンダーはAPIを使ってそのサービスにアクセスできる。
大手IaaSベンダーの主な共通点
大手IaaSベンダーはマーケットプレースを運営しており、そこでユーザーは特定のIaaSベンダーのサービスと連携可能なサードパーティー製サービスを見つけることができるという共通点もある。管理ツール、監視ツール、セキュリティツールなど、サードパーティー製品の多くは複数のクラウドベンダーで利用できる。
別の共通点はデータだ。プラットフォームに関係なく、どのようなワークロードでもパブリッククラウドで稼働しているクラウドネイティブのデータベースや、サードパーティー製データベースのデータにアクセスできる。適切なネットワークアクセスと資格情報があれば、3つのパブリッククラウドプラットフォームのデータベースからの異なるデータをアプリケーションで使用できる。
これらの特徴は大手IaaSベンダー3社に共通するものだが、マルチクラウド利用をサポートする各ベンダー固有のネイティブなサービスもある。以下で、各ベンダーのサービスを詳しく紹介する。
AWS
AWSが提供するコアテクノロジーの一つが、「Amazon Simple Queue Service」だ。このキューイングサービスによって、マイクロサービスや他のクラウドプラットフォームを含む分散システム、サーバレスアプリケーションとの接続と切断が可能になる。企業はこのサービスを利用して、クラウドネイティブアプリケーションとリモートでホストするアプリケーションとの間でメッセージを送受信できる。
「AWS Service Catalog」は、管理者がAWSでの利用を承認した仮想マシン(VM)からアプリケーションまでの一連のITサービスとリソースを構築するのに役立つツールだ。AWS Service Catalogはマルチクラウド環境でも利用できる。AWS Service Catalogの主なメリットの一つは、ITサービス管理ツール「ServiceNow」などのSaaS(Software as a Service)アプリケーションに接続する機能だ。この機能により、ITチームはServiceNowをAWS Service Catalogにつなぎ、ストレージやコンピューティングなどといったAWSのリソースを要求できる。
Microsoft
Microsoftがクラウド監視サービスベンダーCloudynを買収したことで獲得したテクノロジーをベースにした「Azure Cost Management」は、クラウドコンピューティングのコストを監視、確保、最適化する機能を提供する。この機能は「Microsoft Azure」でメリットがあるだけでなく、AWSや「Google Cloud Platform」(GCP)のコストの分析や追跡にも利用できる。
これはCloudynのツールが、複数のプラットフォームをサポートするようMicrosoft Azure外部で作られたという事実の表れだ。今後は特定のクラウド用に作成した管理/監視ツールを、外部ベンダーもサポートできるように拡張する可能性がある。
GCPと他のクラウドプラットフォームをうまく連携させる必要がある場合は、「Google Cloud Endpoints」に目を向けてみよう。このサービスはOpenAPI Specification(OAS)を使用して、APIを作成・管理するフレームワークとツールを提供する。さらに「Stackdriver Monitoring」「Stackdriver Trace」「Stackdriver Logging」を使用し、APIのパフォーマンスを可視化する。
考え方はシンプルだ。Googleはクラウドで顧客が必要とするかもしれない全ての機能を提供しているわけではないため、「AWS Lambda」といった他のクラウドサービスでも利用できるAPIを作成・導入するためのフレームワークをGoogle Cloud Endpointsで提供している。ただし、Google Cloud Endpointsを含めて即座に連携できるテクノロジーはない。他のサービスとの接続を有効にするには、APIを作成して導入しなければならない。
結局のところ、全ての大手IaaSベンダーがAPIの作成・管理機能を提供してはいるが、大半のユーザーが望んでいるような「プラグアンドプレイ」ではない。もし大手IaaSベンダーがこのユーザーの需要を察知しなければ、他のサードパーティーベンダーが気付きその役割を担うだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[ゾーホージャパン株式会社] サイバー攻撃からネットワークを守る上で確実に押さえておきたいポイントとは? -
事例
[アルプス システム インテグレーション株式会社] 中小企業でも安心して活用できる「手ごろなSOCサービス」とは? -
製品資料
[株式会社シーイーシー] 脱VMwareに成功した企業は何をどう実践した? 事例に学ぶ戦略立案&実装のコツ -
製品資料
[株式会社オービックビジネスコンサルタント] ランサムウェア攻撃を“二重の防御構造”で防ぐ、クラウド型基幹システムの実力 -
製品資料
[株式会社オービックビジネスコンサルタント] 動画で知るランサムウェア被害企業のリアル、会計データが無事だった理由とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
鹿島建設のDXを阻む「10年前のAWS」 安全性と自由度を両立したモダナイズ
-
3
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
4
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
5
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
6
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
7
IT製品の導入に関するアンケート「PC&デバイス」編
-
8
年収700万超エンジニアに共通するスキルと「もっと勉強すべきだった分野」
-
9
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
10
生データを隠してデータ連携 KDDIが4000万人の顧客情報を安全に分析できた理由
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー