クラウドアーキテクチャとは
クラウドコンピューティングは過去 20 年間で急速に成長し、驚くべきスピードで拡大し続けています。基本的な SaaS（Software as a Service）サービスやIaaS（Infrastructure as a Service）サービスとして始まったものが、サーバーから Kubernetes クラスターまであらゆる用途に対応する巨大な クラウドネイティブ ソリューションのエコシステムへと進化しました。
この記事では、 クラウドアーキテクチャ （または クラウドコンピューティング・アーキテクチャ）について集中的に説明し、クラウドアーキテクチャを構成するコンポーネント、さまざまなクラウドコンピューティング・モデル、クラウドの利点や、オンプレミスアプリケーションをクラウドに移行する方法について十分な情報に基づいて決定する方法などを取り上げます。
クラウドアーキテクチャとは
さて、 クラウドアーキテクチャとは何でしょうか？また、 クラウドコンピューティング・アーキテクチャとは何でしょうか？クラウドアーキテクチャとクラウドコンピューティング・アーキテクチャは同じです。どちらの用語も、クラウドコンピューティング環境のインフラコンポーネントの設計を定義する「ブループリント」を指します。
クラウドアーキテクチャを概念化するためには、いくつかの方法があります。たとえば、クラウド・サービス・プロバイダーの観点では、クラウドアーキテクチャは次の要素で構成されています。
- ハードウェアレイヤー。 これには、ベアメタルサーバー、ネットワーク機器、ストレージデバイスが含まれます。
- 仮想化レイヤー。 これには、物理リソースを仮想化するためのハイパーバイザーと SDN（Software-Defined Networking）コンポーネントが含まれます。
- サービスレイヤー。 これには、プロバイダーがユーザーに提供するクラウドリソースが含まれます。
開発者や DevOps エンジニアなどのユーザーの考えでは、クラウドアーキテクチャのコンポーネントには次のものがあります。
- フロントエンド。たとえば、Web コンソール、アプリケーション・プログラミング・インターフェース（API）、コマンドラインインターフェース（CLI）、モバイルアプリ、その他のクライアントなどであり、クラウドサービスへのアクセスを可能にします。
- バックエンド。 これは、サービスを可能にするコンピューティングリソース、ストレージリソース、ソフトウェアリソースを提供します。
- ネットワーク。 これにより、クラウドリソースとサービス（DNS 解決など）の間の接続が可能になります。
クラウド環境のアーキテクチャの役割は、すべてのコンポーネントがどのように連携し、通信するかを定めることです。図 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 つの基本的なクラウド・サービス・モデルには、 パブリッククラウド とプライベートクラウドの 2 つがあります（表 1）。パブリック・クラウド・プラットフォームは一般に提供されており、インフラはクラウド・サービス・プロバイダーによって管理されています。プライベート・クラウド・プラットフォームは単一の組織専用です。
パブリッククラウドとプライベートクラウドは、シンプルさ（パブリッククラウド）とコントロール（プライベートクラウド）のトレードオフの関係にあります。パブリック・クラウド・ユーザーはサービスを利用するだけで、サービスプロバイダーがメンテナンスとインフラのプロビジョニングを担当します。ただし、パブリッククラウドのユーザーは、本質的にサービスプロバイダーが提供する機能しか利用できません。さらに、パブリッククラウドのデータはサービスプロバイダーのデータセンターに存在し、これはコンプライアンスとデータ主権に影響します。
反対に、プライベートクラウドのユーザーは、インフラと機能を完全にコントロールできます。欠点は、ユーザー（またはその代理を務めるサードパーティ）がインフラの保守、設定、パッチ適用といった複雑な問題に対処する必要があることです。
表 1：パブリッククラウドとプライベートクラウドの長所と短所
パブリッククラウドよりもプライベートクラウドの方が安全か
一般的に、プライベートクラウドにはパブリッククラウドと比較してセキュリティ上の利点が 2 つあります。
- プライベートクラウドは単一の組織専用です。
- プライベートクラウドは一般的に、公衆インターネット経由で直接アクセスすることはできません。
そのため、プライベートクラウドはパブリッククラウドよりも安全性が高いという主張がよく見られます。理論的には、プライベートクラウドを維持しているエンタープライズが設定やメンテナンスにおいて セキュリティのベストプラクティス を実践している場合、この主張は妥当です。他のすべての条件が同じであるなら、プライベートクラウドが分離されていることはセキュリティ上の利点となります。
しかし、多くの組織では、ハイパースケールのクラウドプロバイダーと同じ厳格さでインフラの強化、パッチ適用、検査、管理を行うためのセキュリティの専門知識とリソースが社内では不足しています。パッチが適用されていない、または不適切に設定されたプライベートクラウドは、パブリッククラウドよりも安全性が低い可能性があり、エンタープライズはそれを考慮してリスク評価を行う必要があります。
高度なクラウド展開モデル - ハイブリッドクラウドとプライベートクラウド
パブリッククラウドとプライベートクラウドの他にも、いくつかのクラウド展開モデルがあります。たとえば、米国国立標準技術研究所（National Institute of Standards and Technology）の 定義によると、 コミュニティークラウド は「共通の懸念を有する組織の特定の消費者コミュニティーが排他的に使用するためにプロビジョニングされている」クラウドインフラです。 しかし、高度なクラウドアーキテクチャ展開モデルとして最も一般的なのは次の 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 つの XaaS サービスモデル：SaaS、PaaS、IaaS
これら 3 つのクラウドコンピューティング・サービス・モデルの違いは、サービスプロバイダーとユーザーが何に対して責任を負うかです。表 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）など）は、クラウドプラットフォーム上でコンテナ化されたアプリを展開および管理するプロセスを合理化します
- マネージド型 Kubernetes プラットフォーム（AKS、EKS など）は、クラウド上の Kubernetes クラスターの自動オーケストレーションのためのホストされた Kubernetes サービスを提供します
- サーバーレスコンピューティング は、コンピューティングリソースに対する「オンデマンド」アプローチによって、ユーザーが基盤インフラを管理せずに機能を実行できるようにします。
クラウドコンピューティングの利点
クラウドコンピューティングは、消費者とエンタープライズの両方にとって有益です。従来のオンプレミスコンピューティングと比較して、 クラウドコンピューティング には次のような利点があります。
- 管理されたインフラ：サーバー、スイッチ、ラック、電源、冷却装置の設置、設定、保守にはコストと時間がかかります。クラウドサービスは、インフラ管理を複雑にすることなく、ソリューションのビジネス上のメリットを提供します。
- 弾力性のあるリソース：パブリッククラウドでは、クラウドの使用量を簡単に増減できます。この弾力性により、企業はボトルネックを回避できるため、ハードウェアへの過剰投資のリスクを負うことなく、迅速に拡張できます。
- 包括的な可観測性：多くの場合、クラウドプラットフォームには可観測性ツールとダッシュボードが付属しています。
- 組み込みのベストプラクティス：サービスプロバイダーは、 パフォーマンス、セキュリティ、ユーザビリティの適切なバランスを取るように奨励されています。また、スケールメリットという利点をお客様に提供することができます。その結果、ユーザーは適切なクラウドプラットフォームを使用するだけで、インフラのベストプラクティスからメリットを得られます。
クラウドアーキテクチャへの移行
クラウドで新しいプロジェクトを開始することもそうですが、既存のワークロードをクラウドに移行することもクラウドの活用方法です。あらゆるユースケースに対応する単一のアプローチはありませんが、適切にクラウドを展開するために利用できる一般的な原則とベストプラクティスがあります。
- クラウドへの移行が適切であることを確認する：すべてのワークロードがクラウドワークロードである必要はありません。クラウドへの移行のコストを、ワークロード全体を廃止する場合またはオンプレミスのままにする場合にかかるコストと比較して、ビジネスケースを作成します。
- クラウドプロバイダーを賢く選択する：機能とコストは重要ですが、方程式はこれらだけで成り立っているわけではありません。決定を下す際には、機能以外の要件、 サポート、サービスレベル契約、ベンダーの評判を考慮することが重要です。
- 自社に適したサービスモデルと展開モデルを選択する：パブリッククラウドとプライベートクラウド、IaaS と SaaS の違いは、コントロール、機能、ベンダーロックインのトレードオフの違いです。モデルを決定する前に、長所と短所を評価する必要があります。たとえば、オンプレミスの Exchange サーバーを IaaS プラットフォーム上の同等の仮想マシンに移行することは論理的かもしれませんが、Office 365 メール（SaaS）の方が優れたソリューションとなる可能性もあります。
- 予算を常に確認する：クラウドのコストは急速に増加します。ほとんどの主要なクラウドプロバイダーには クラウドコスト計算ツール があるため、これを使用して合理的な見積もりを取得し、予期せぬ事態を回避できます。また、可能な限り予算アラートを設定し、明細書をよく確認することが重要です。また、予算内に収めるためには、体系的なアプローチでコストを追跡する必要があります。
- 常に不測の事態を想定する：クラウドへの移行時のデータ損失とダウンタイムのリスクを緩和するためには、バックアップ、ロールバック計画、本番前テストが役立ちます。重要なワークロードを移行する際には、「念には念を入れる」アプローチを採用します。
- 複雑なモノリスには ストラングラー・フィグ・アプリケーション を検討する：リフト & シフトですべてに対応できるわけではありません。チームが複雑なモノリシックアプリケーションをクラウドに移行する必要がある場合は、ストラングラー・フィグ・アプリケーションを使用して、徐々にクラウドネイティブのマイクロサービスに移行することをご検討ください。
結論
クラウドアーキテクチャは難しいトピックであり、学ぶべきことがたくさんあります。ただし、ここで説明した内容を読めば、クラウド コンピューティングの基本的な 「何」、 「なぜ」、 「どのように」 についてしっかりと理解できるはずです。
