AkamaiがLayerXを買収へ、あらゆるブラウザ上でAI利用の制御を強化。 詳細を見る

クラウドアーキテクチャとは

Pavel Despot

執筆者

Pavel Despot

March 23, 2023

Pavel Despot

執筆者

Pavel Despot

Pavel Despot has more than 20 years of experience designing and deploying critical, large-scale solutions for global carriers and Fortune 500 companies around the world. He is currently the Senior Product Marketing for Cloud Computing Services at Akamai. In his previous role as Principal Cloud Solutions Engineer, he led application modernization and security initiatives for Akamai’s largest SaaS clients. Before joining Akamai, Pavel held various leadership roles on standards bodies, including the CTIA Wireless Internet Caucus (WIC), the CDMA Developers Group (CDG), and the Interactive Advertising Bureau (IAB). He has two patents in mobile network design, and currently resides in the Boston area.

 

クラウドアーキテクチャとクラウドコンピューティング・アーキテクチャは同じです。どちらの用語も、クラウドコンピューティング環境のインフラコンポーネントの設計を定義する「ブループリント」を指します。

クラウドコンピューティングは過去20年間で急速に成長し、驚くべきスピードで拡大し続けています。当初は基本的なSoftware as a Service(SaaS)やInfrastructure as a Service(IaaS)から始まり、現在ではサーバーからKubernetesクラスターに至るまで、あらゆるものをカバーするクラウドネイティブソリューションの広大なエコシステムへと進化しました。 

この記事では、クラウドアーキテクチャクラウド・コンピューティング・アーキテクチャとも呼ばれます)の基礎をわかりやすく解説します。クラウドアーキテクチャを構成する要素、クラウドコンピューティングのさまざまなモデル、クラウドのメリット、そしてオンプレミスアプリケーションをクラウドに移行する際の適切な判断方法について学びます。

クラウドアーキテクチャとは

クラウドアーキテクチャとはクラウド・コンピューティング・アーキテクチャとはクラウドアーキテクチャとクラウド・コンピューティング・アーキテクチャは同じです。どちらの用語も、クラウドコンピューティング環境のインフラコンポーネントの設計を定義する「ブループリント」を指します。

クラウドアーキテクチャを概念化するためには、いくつかの方法があります。たとえば、クラウド・サービス・プロバイダーの観点では、クラウドアーキテクチャは次の要素で構成されています。

  • ハードウェアレイヤーには、ベアメタルサーバー、ネットワーク機器、ストレージデバイスが含まれます。
  • 仮想化レイヤーには、物理リソースを仮想化するためのハイパーバイザーとSDN(Software-Defined Networking)コンポーネントが含まれます。 
  • サービスレイヤーには、プロバイダーがユーザーに提供するクラウドリソースが含まれます。 

開発者やDevOpsエンジニアなどのユーザーの考えでは、クラウドアーキテクチャのコンポーネントには次のものがあります。

  • フロントエンドは、Webコンソール、アプリケーション・プログラミング・インターフェース(API)、コマンドラインインターフェース(CLI)、モバイルアプリ、その他のクライアントなどであり、クラウドサービスへのアクセスを可能にします。 
  • バックエンドは、サービスを可能にするコンピューティングリソース、ストレージリソース、ソフトウェアリソースを提供します。 
  • ネットワークにより、クラウドリソースとサービス(DNS解決など)の間の接続が可能になります。 

クラウド環境のアーキテクチャの役割は、すべてのコンポーネントがどのように連携し、通信するかを定めることです。図1は、クラウドベースのドキュメント管理システムのアーキテクチャを表しています。

図 1 は、クラウドベースのドキュメント管理システムのアーキテクチャを表しています。 図 1:ドキュメント管理システムのクラウドアーキテクチャの例

これらのコンポーネントの設計、実装、およびユーザーへの提供(または抽象化)方法は、クラウド・デリバリー・モデルやクラウドコンピューティングの種類によって異なります。例えば、プライベートクラウド上の仮想マシンで動作するWebアプリケーションは、Kubernetesベースの分散型アプリケーションとは異なるアーキテクチャを持っています。 

すべてのクラウド実装に共通しているのは、クラウドがユーザーのためにある程度の複雑さを抽象化してくれるプラットフォームであるという点です。たとえば、Amazon Web Services(AWS)EC2インスタンスなどのIaaSサービスは、ハードウェアの複雑さを抽象化します。Google DocsなどのSaaSアプリでは、さらに抽象化が行われ、オペレーティングシステム、ミドルウェア、アプリケーションメンテナンスなど、あらゆるものがユーザーには見えません。

クラウドインフラの主要な物理コンポーネント

抽象化レイヤーの下で、クラウドコンピューティングにはオンプレミスのITインフラと同じ3つのプライマリレイヤーがあります。 

  • コンピューティングリソース(CPU、RAM、GPU)
  • ネットワークリソース(ネットワークインターフェースなど) 
  • ストレージリソース(SSD、HDDなど)

IaaSのようなモデルでは、多くの場合、請求はこれらのカテゴリ全体のリソース消費に基づいて行われます。 

:クラウドアーキテクチャとネットワークアーキテクチャを混同しないでください。クラウドアーキテクチャには、 関連するネットワークアーキテクチャも含まれます。たとえば、SD-WAN、SDN、DNSサービスはすべて、企業環境のクラウドアーキテクチャに含まれる場合があります。

基本的なクラウド導入モデル:パブリッククラウドとプライベートクラウドの比較

利用可能なクラウドサービスの基本的なモデルは、パブリッククラウドとプライベートクラウドの2つです(表1)。パブリック・クラウド・プラットフォームは一般に提供されており、インフラはクラウド・サービス・プロバイダーによって管理されています。プライベート・クラウド・プラットフォームは単一の組織専用です。 

パブリッククラウドとプライベートクラウドは、シンプルさ(パブリッククラウド)とコントロール(プライベートクラウド)のトレードオフの関係にあります。パブリック・クラウド・ユーザーはサービスを利用するだけで、サービスプロバイダーがメンテナンスとインフラのプロビジョニングを担当します。ただし、パブリッククラウドのユーザーは、本質的にサービスプロバイダーが提供する機能しか利用できません。さらに、パブリッククラウドのデータはサービスプロバイダーのデータセンターに存在し、これはコンプライアンスとデータ主権に影響します。 

反対に、プライベートクラウドのユーザーは、インフラと機能を完全にコントロールできます。欠点は、ユーザー(またはその代理を務めるサードパーティ)がインフラの保守、設定、パッチ適用といった複雑な問題に対処する必要があることです。 

表 1 は、パブリック・クラウド・プラットフォームとプライベート・クラウド・プラットフォームの長所と短所をまとめています。 表 1:パブリッククラウドとプライベートクラウドの長所と短所

パブリッククラウドよりもプライベートクラウドの方が安全か

一般的に、プライベートクラウドにはパブリッククラウドと比較してセキュリティ上の利点が2つあります。

  1. プライベートクラウドは単一の組織専用です。 
  2. プライベートクラウドは一般的に、公衆インターネット経由で直接アクセスすることはできません。

そのため、プライベートクラウドはパブリッククラウドよりも安全性が高いという主張がよく見られます。理論的には、プライベートクラウドを運用する企業がセキュリティのベストプラクティスを構成と保守に適用している場合、これは妥当な主張と言えます。他のすべての条件が同じであるなら、プライベートクラウドが分離されていることはセキュリティ上の利点となります。 

しかし、多くの組織では、ハイパースケールのクラウドプロバイダーと同じ厳格さでインフラの強化、パッチ適用、検査、管理を行うためのセキュリティの専門知識とリソースが社内では不足しています。 パッチが適用されていない、または不適切に設定されたプライベートクラウドは、パブリッククラウドよりも安全性が低い可能性があり、企業は リスク評価を行う際にこの点を考慮に入れる必要があります。 

高度なクラウド展開モデル - ハイブリッドクラウドとプライベートクラウド 

パブリッククラウドとプライベートクラウドの他にも、いくつかのクラウド展開モデルがあります。例えば、米国国立標準技術研究所(NIST)は、コミュニティクラウドを「共通の課題を持つ組織の特定のユーザーコミュニティ専用に提供されるクラウドインフラ」と定義しています。 しかし、高度なクラウドアーキテクチャ展開モデルとして最も一般的なのは次の2つです。

  • ハイブリッドクラウド:組織内で複数のクラウド展開モデルを組み合わせること。たとえば、パブリッククラウドとプライベートクラウドでデータベースを複製するチームは、ハイブリッド・クラウド・モデルを使用しています。 

  • マルチクラウド:組織内で複数の異なるパブリック・クラウド・プロバイダーを使用すること。たとえば、Azure Kubernetes Service(AKS)とAmazon Elastic Kubernetes Service(EKS)でクラスターを運営する企業は、マルチクラウドモデルを使用しています。

XaaS:クラウドコンピューティングのタイプ 

展開モデルだけでなく、クラウド・コンピューティング・サービス・モデルにもさまざまな種類があります。これらのモデルは総称して「anything as a service」またはXaaSと呼ばれます。XaaSモデルは多くの場合、サブスクリプションベースの料金体系でプロバイダーがユーザーにクラウド・コンピューティング・サービスを提供します。 

最も一般的なXaaSサービスモデルは、SaaS、PaaS(Platform as a Service)、IaaSの3つです(図2)。 

図 2 は、3 つの一般的な「Anything as a Service」(すなわち XaaS サービスモデル)であるSaaS、PaaS、IaaS を表す画像です。 図 2:最も一般的な 3 つの XaaS サービスモデル:SaaS、PaaS、IaaS

これら3つのクラウド・コンピューティング・サービス・モデルの違いは、サービスプロバイダーとユーザーが何に対して責任を負うかです。表2は、クラウドインフラの各側面を誰がコントロールするのかを、モデル別にまとめています。

表 2 は、クラウドインフラの各側面を誰がコントロールするのかをモデル別にまとめています。 表 2:3 つのクラウドコンピューティング・サービスにおけるプロバイダーとユーザーの責任

IaaSプラットフォームは、ユーザーが最もコントロールできますが、管理と保守が最も複雑です。ユーザーは、オペレーティングシステムの選択からパッチの適用まで、すべての責任を負います。それとは対照的に、Google DocsやSlackなどのSaaSプラットフォームは、アプリケーションレイヤー以外のすべてを抽象化します。 

PaaSプラットフォームは中間的で、ユーザーがアプリケーションとデータレイヤーをコントロールできます。たとえば、PaaSプラットフォームでは、ユーザーはMySQLデータベースに直接アクセスできますが、基盤となるMySQLバージョンやオペレーティングシステムにパッチを適用する責任はありません。 

IaaS、PaaS、SaaS以外のサービスモデル

IaaS、PaaS、SaaSは、クラウド・サービス・モデルの始まりにすぎません。過去10年間で、さまざまなユースケースをカバーする新しいクラウドサービスが爆発的に増加しています。 

知っておくべきその他のクラウド・サービス・モデルの概要は以下のとおりです。

  • Authentication as a service(AaaS)プラットフォーム(Okta、Duoなど)は、多要素認証(MFA)やシングルサインオン(SSO)などのサービスを提供します。
  • Desktop as a service(DaaS)プラットフォーム(Amazon Workspaces、Azure Virtual Desktopなど)は、クラウド上でマネージド型仮想デスクトップを提供します 
  • Containers as a service(CaaS)サービス(Google Cloud Run、Microsoft Azure Container Instances(ACI)など)は、クラウドプラットフォーム上でコンテナ化されたアプリを展開および管理するプロセスを合理化します
  • Managed Kubernetesプラットフォーム(AKS、EKSなど)は、クラウド上のKubernetesクラスターの自動オーケストレーションのためのホストされたKubernetesサービスを提供します 
  • サーバーレスコンピューティングは、コンピューティングリソースに対する「オンデマンド」アプローチによって、ユーザーが基盤インフラを管理せずに機能を実行できるようにします。

クラウドコンピューティングの利点

クラウドコンピューティングは、消費者と企業の両方にとって有益です。従来のオンプレミスのコンピューティングと比較した際、クラウドコンピューティングの主な利点は次のとおりです。

  • 管理されたインフラ:サーバー、スイッチ、ラック、電源、冷却装置の設置、設定、保守にはコストと時間がかかります。クラウドサービスは、インフラ管理を複雑にすることなく、ソリューションのビジネス上のメリットを提供します。 
  • 弾力性のあるリソース:パブリッククラウドでは、クラウドの使用量を簡単に増減できます。この弾力性により、企業はボトルネックを回避できるため、ハードウェアへの過剰投資のリスクを負うことなく、迅速に拡張できます。
  • 包括的な可観測性:多くの場合、クラウドプラットフォームには可観測性ツールとダッシュボードが付属しています。
  • 組み込みのベストプラクティス:サービスプロバイダーは、パフォーマンス、セキュリティ、使いやすさのバランスを適切に保つことが求められています。また、スケールメリットという利点をお客様に提供することができます。その結果、ユーザーは適切なクラウドプラットフォームを使用するだけで、インフラのベストプラクティスからメリットを得られます。 

クラウドアーキテクチャへの移行

クラウドで新しいプロジェクトを開始することもそうですが、既存のワークロードをクラウドに移行することもクラウドの活用方法です。あらゆるユースケースに対応する単一のアプローチはありませんが、適切にクラウドを展開するために利用できる一般的な原則とベストプラクティスがあります。 

  • クラウドへの移行が適切であることを確認する:すべてのワークロードがクラウドワークロードである必要はありません。クラウドへの移行のコストを、ワークロード全体を廃止する場合またはオンプレミスのままにする場合にかかるコストと比較して、ビジネスケースを作成します。 
  • クラウドプロバイダーを賢く選択する:機能とコストは重要ですが、方程式はこれらだけで成り立っているわけではありません。意思決定を行う際には、非機能要件、サポート内容、サービスレベル契約、およびベンダーの評判を考慮してください。 
  • 自社に適したサービスモデルと展開モデルを選択する:パブリッククラウドとプライベートクラウド、IaaSとSaaSの違いは、コントロール、機能、ベンダーロックインのトレードオフの違いです。モデルを決定する前に、長所と短所を評価する必要があります。たとえば、オンプレミスのExchangeサーバーをIaaSプラットフォーム上の同等の仮想マシンに移行することは論理的かもしれませんが、Office 365メール(SaaS)の方が優れたソリューションとなる可能性もあります。 
  • 予算を常に確認する:クラウドのコストは急速に増加します。主要なクラウドプロバイダーのほとんどは、見積もりを正確に算出し、予期せぬコスト増を防ぐためのクラウドコスト計算ツールを提供しています。また、可能な限り予算アラートを設定し、明細書をよく確認することが重要です。また、予算内に収めるためには、体系的なアプローチでコストを追跡する必要があります。 
  • 常に不測の事態を想定する:クラウドへの移行時のデータ損失とダウンタイムのリスクを緩和するためには、バックアップ、ロールバック計画、本番前テストが役立ちます。重要なワークロードを移行する際には、「念には念を入れる」アプローチを採用します。 
  • 複雑なモノリシックアプリケーションには、ストラングラー・フィグ・アプリケーションを検討してみてください:リフト&シフトですべてに対応できるわけではありません。チームが複雑なモノリシックアプリケーションをクラウドに移行する必要がある場合は、ストラングラー・フィグ・アプリケーションを使用して、徐々にクラウドネイティブのマイクロサービスに移行することをご検討ください。

結論

クラウドアーキテクチャは難しいトピックであり、学ぶべきことがたくさんあります。しかし、ここまで学んだ内容で、クラウドコンピューティングの基本的ななぜどのようにについて、しっかりと理解できるようになるはずです。



Pavel Despot

執筆者

Pavel Despot

March 23, 2023

Pavel Despot

執筆者

Pavel Despot

Pavel Despot has more than 20 years of experience designing and deploying critical, large-scale solutions for global carriers and Fortune 500 companies around the world. He is currently the Senior Product Marketing for Cloud Computing Services at Akamai. In his previous role as Principal Cloud Solutions Engineer, he led application modernization and security initiatives for Akamai’s largest SaaS clients. Before joining Akamai, Pavel held various leadership roles on standards bodies, including the CTIA Wireless Internet Caucus (WIC), the CDMA Developers Group (CDG), and the Interactive Advertising Bureau (IAB). He has two patents in mobile network design, and currently resides in the Boston area.