OpenStack ユーザーのための Google Cloud Platform

この記事は、ハイブリッド デプロイの移行や実装を検討しているかどうかに関係なく、OpenStack に関する詳しい知識を持つデベロッパーが、Google Cloud Platform(GCP)を開始するための重要な概念を習得することを念頭に記述されています。

概要

この記事ではまず、OpenStack と GCP 上に作成される 3 階層ウェブ アプリケーションのサンプル アーキテクチャを比較します。次に OpenStack と GCP の機能を比較し、OpenStack の用語とコンセプトが GCP の用語とコンセプトにどのように対応しているかを、簡単な参照表を用いて説明します。

OpenStack と GCP が提供する SDK、API、コマンドライン ツールの比較は、この記事には含まれていません。

Google Cloud Platform のプロダクト一覧については、プロダクトとサービスをご覧ください。

クラウド コンピューティング サービス

クラウド コンピューティング サービスは、コンピューティング、ストレージ、ネットワーキング、アクセス管理、データベース サービスなどの一連の基本サービスを提供します。

OpenStack の基本サービスには、次のサービスが含まれます。

  • コンピューティング: OpenStack Compute(Nova と Glance)
  • ストレージ:OpenStack ブロック ストレージ(Cinder)
  • ネットワーキング: OpenStack ネットワーキング(Neutron)
  • ID とアクセス管理: OpenStack アイデンティティ サービス(Keystone)

Cloud Platform の基本サ-ビスには、次のサービスが含まれます。

Google Cloud Platform での料金体系

GCP 上のサービスの大半は、秒単位または分単位の課金および利用状況に応じた自動割引を含む、従量制の料金モデルに基づいて提供されます。GCP 料金モデルは、カスタム マシンタイプなどの柔軟なリソース割り当てと組み合わせることで、アプリケーションのパフォーマンスをコスト効率的に最適化できます。

迅速な料金見積もりツールと詳細については、料金計算ツールをご覧ください。

Google Cloud Platform を選ぶ理由

過去 15 年間に渡り、Google は、世界中で、最速、最強、最高品質のクラウド インフラストラクチャを構築してきました。Google 内部では、このインフラストラクチャを GmailマップYouTube検索といったトラフィック量の多いグローバル規模のサービスで使用しています。GCP では、このインフラストラクチャをいつでも利用できます。

サンプル アーキテクチャの比較

ここでは、OpenStack と GCP 上に 3 階層ウェブ アプリケーション システムを構築する方法を比較します。

  • OpenStack の構成ではアクティブ - バックアップ構成になります。
  • GCP の構成ではマネージド サービスを利用するアクティブ - アクティブ構成になります。

一般的な 3 階層ウェブ アプリケーションは、次のコンポーネントで構成されています。

  • ロードバランサ
  • ウェブサーバー
  • アプリケーション サーバー
  • データベース サーバー

OpenStack: アクティブ - バックアップ構成

図 1 に示す OpenStack のサンプル構成には、次のような特徴があります。

  • 冗長性を確保するために、2 つの障害ドメインとして 2 つのリージョンにまたがってリソースをデプロイします。
  • ネットワークは各リージョンのすべての階層に単一のサブネットを使用し、すべてのサーバーは仮想マシン(VM)のインスタンスです。
  • 4 つのサーバーの役割に合わせてセキュリティ グループを定義し、それらを適切なインスタンスに割り当てます。
  • Cinder ボリュームは、データ ボリュームとしてデータベース サーバーに接続されています。障害ドメイン間の冗長性を確保するため、アクティブ リージョン内のデータベースはオブジェクト ストレージにバックアップされ、必要に応じてバックアップ リージョン内のデータベースにリストアされます(このアーキテクチャでは、リージョン間で帯域幅が制限されるため、リアルタイムのデータベース複製は使用されません)。
  • このアーキテクチャはアクティブ - バックアップ構成を提供します。サービスを別のリージョンにフェイルオーバーすると、バックアップ リージョンのデータベース サーバーに最新のバックアップがリストアされます。

3 階層ウェブアプリ

図 1: OpenStack 上の 3 階層ウェブ アプリケーション システム

GCP: アクティブ - アクティブ構成

図 2 に示す同じサンプル GCP 構成には、次の特徴があります。

  • 冗長性を確保するために、1 つのリージョン内の複数ゾーンをカバーする単一のサブネットにリソースをデプロイします。
  • ウェブサーバーとアプリケーション サーバーを VM インスタンスとしてデプロイします。
  • タグを使用してファイアウォール ルールを定義し、パケットの宛先を指定します。
  • Cloud SQL 構成の一部として、ソース IP アドレスに基づいてデータベース接続のアクセス制御を設定します。Cloud SQL は、複数のゾーン間でデータを複製する MySQL データベース向けの GCP マネージド サービスです。スケジュールされたデータのバックアップとフェイルオーバー プロセスは自動化されており、同じリージョンの複数のゾーンからデータベースにアクセスできます。ゾーン間のフェイルオーバーは、VM インスタンス上で動作するアプリケーションに影響しません。複数のゾーンから単一の Cloud SQL インスタンスにアクセスできます(Cloud SQL には、Cloud SQL 第 1 世代と Cloud SQL 第 2 世代という 2 つの世代があります。2 つの世代間には、レプリケーションとフェイルオーバーの特徴とデフォルトの動作に違いがあります。)
  • Google Cloud Load Balancing は、単一のグローバル IP アドレス(VIP)を使用して複数のリージョンやゾーンにクライアントアクセスを配信できる、HTTP(S) ロードバランシング サービスです。
  • このアーキテクチャは、複数のゾーンにまたがるアクティブ - アクティブ構成を提供し、障害ドメイン全体に冗長サービスを提供します。

3 階層ウェブアプリ 2

図 2: GCP 上の 3 階層ウェブ アプリケーション システム

機能の比較

ここでは、サンプル アーキテクチャで使用されている機能の詳細を比較します。

ネットワーク アーキテクチャ

ここでは、リージョンやゾーン内で OpenStack ネットワークと GCP ネットワークがどのように機能するか比較し、プロジェクトやテナント、IP アドレスとフェイルオーバー、ファイアウォール ルールについて説明します。

リージョンとゾーン

OpenStack の用語とコンセプトは、次のように GCP の用語とコンセプトに対応しています。

OpenStack GCP メモ
リージョン リージョン OpenStack では、リージョンが複数のデータセンターにまたがることができます。GCP では、リージョンは通常複数の独立した建物を持つデータセンター キャンパスに該当します。
可用性ゾーン ゾーン OpenStack では、共通の属性を持つ一連のサーバーを識別するために、可用性ゾーンが一般的に使用されます。

GCP では、ゾーンはデータセンター内のクラスタに該当します。

OpenStack では、「リージョン」は専用コントローラ ノードによって管理される単一クラスタとして定義されます。リージョンは、「可用性ゾーン」から構成されます。可用性ゾーンを使用して、計算ノードやストレージ エンクロージャなど、複数のリソース グループを定義します。

GCP では、「リージョン」は「ゾーン」で構成される独立した地理的な場所です。リージョン内のロケーションのラウンドトリップ ネットワーク レイテンシは、95% 程度が 5 ミリ秒未満になります。OpenStack の可用性ゾーンと同様に、ゾーンはリージョン内にある GCP リソースのデプロイエリアです。ゾーンは単一の障害ドメインとみなすことができます。

GCP はすべてのリージョンに及ぶ専用の内部ネットワークを提供するため、同じリージョン内であれば、異なるゾーン間の帯域幅とレイテンシとリージョン全体の帯域幅とレイテンシは同じ程度です。ゾーン間の帯域幅とレイテンシを気にせずに、密結合クラスタ アプリケーションを複数のゾーンにまたがってデプロイできます。

いずれのプラットフォームでも、複数のゾーンまたはリージョンにまたがってアプリケーションをデプロイすることで、予期せぬ障害からアプリケーションを保護することができます。ゾーンは GCP の独立した障害ドメインとみなされます。一方 OpenStack では、リージョンが(可用性ゾーンではなく)独立した障害ドメインとみなされます。これは、単一リージョンに含まれる可用性ゾーンが、同じコントローラ ノードを共有するためです。GCP のリージョンとゾーン一覧については、Cloud のロケーションをご覧ください。

プロジェクトとテナント

OpenStack の用語とコンセプトは、次のように GCP の用語とコンセプトに対応しています。

OpenStack GCP メモ
テナント プロジェクト GCP のすべてのリソースは、プロジェクトに属している必要があります。ユーザーは独自の新しいプロジェクトを作成できます。

OpenStack では、管理者だけが新しいテナントを作成できます。

GCP サービスを使用するには、Google アカウントを設定する必要があります。GCP はプロジェクト別にサービスの利用状況を分類します。デベロッパーとして同じアカウントに複数の個別のプロジェクトを作成でき、そのメンバー ユーザーも各自のアカウントに独自のプロジェクトを作成できます。単一のプロジェクト内のリソースは、たとえば内部ネットワーク経由の通信など、リージョンとゾーンのルールに従って簡単に連携できます。各プロジェクト内のリソースは、他のプロジェクトのリソースとは互いに分離されていて、外部ネットワーク接続を介してのみ相互接続できます。

このモデルでは、会社内の別の部門やグループ用に独立したプロジェクト スペースを作成できます。このモデルは、テスト目的でも役立ちます。プロジェクトを終了した後、プロジェクトを削除すると、そのプロジェクトによって作成されたすべてのリソースも削除されます。

OpenStack は、異なるグループ間でリソースを分離する同様の機能に対して「テナント」という用語を使用します。OpenStack では、システム管理者だけが新しいテナントを作成できます。

ネットワーク構成

OpenStack の用語とコンセプトは、次のように GCP の用語とコンセプトに対応しています。

OpenStack GCP メモ
Neutron Cloud Virtual Network Cloud Virtual Network は、マネージド ネットワーク サービスです。GCP では、プロジェクト内に複数のネットワークを定義することができます。各ネットワークは独立しています。
仮想プライベート ネットワーク
仮想プライベート ネットワーク 単一の GCP 仮想プライベート ネットワークは、GCP の内部ネットワーク経由で接続されたすべてのリージョンにまたがっています。Neutron 仮想プライベート ネットワークは、1 つのリージョン内のすべての可用性ゾーンにまたがっています。

通常の OpenStack Neutron のデプロイでは、各テナントの仮想ネットワークは専用のネットワーク空間に含まれています。図 1 に示すように、必ずしも複数のサブネットを使用する必要はありませんが、必要に応じて複数のサブネットを構成できます。図 3 は、1 つの仮想ルーターと 3 つの仮想スイッチで構成される OpenStack 仮想ネットワークを示しています。仮想スイッチの 2 つは、仮想ルーター経由で外部ネットワークに接続します。AZ-1 および AZ-2 は可用性ゾーンです。

仮想ネットワーク

図 3: OpenStack ネットワーク構成の例

GCP には、「レガシー」と「サブネット」という 2 種類のネットワークがあります。

レガシー ネットワークは、図 4 に示すように、世界中のすべてのリージョンにまたがる単一のプライベート サブネットを提供します。

図 5 に示すサブネット ネットワークでは、仮想スイッチは OpenStack Neutron の仮想ルーターに相当し、内部ネットワークを介して接続されています。すべてのサブネットはプライベート IP アドレスで相互にルーティング可能であるため、リージョン間通信にグローバル IP アドレスまたはインターネットを使用する必要はありません。

GCP では、プロジェクト内でレガシー ネットワークとサブネット ネットワークを組み合わせて使用できます。新たに作成されたプロジェクトごとに「default」という定義済みネットワークがあり、同様にリージョンごとの「default」というサブネットが含まれます。

レガシー ネットワーク

図 4: Google Cloud Platform レガシー ネットワークの設定例

サブネット ネットワーク

図 5: Google Cloud Platform サブネット ネットワークの設定例

IP アドレス

OpenStack の用語とコンセプトは、次のように GCP の用語とコンセプトに対応しています。

OpenStack GCP
インスタンスは、プライベート内部 IP アドレスを持っています。必要に応じて、グローバル IP アドレス(フローティング IP アドレス)を割り当てることができます。

インスタンスは、プライベート内部 IP アドレスを持っています。さらに、`gcloud` コマンドライン ツールを使用してインスタンスを作成すると、エフェメラル IP アドレスが自動的に割り当てられます。必要に応じて静的 IP アドレスを割り当てることもできます。
異なるリージョン、または異なる仮想ルーターの管理下にあるインスタンス間の通信には、グローバル IP アドレスが必要です。 すべてのリージョンのサブネットはプライベート IP アドレスで相互にルーティング可能であるため、インスタンス間の通信にグローバル IP アドレスまたはインターネットを使用する必要はありません。

Neutron では、プライベート ネットワーク内の VM インスタンスは、起動時に割り当てられたプライベート IP アドレスを使用して仮想スイッチとルーターを通じて通信します。グローバル IP アドレスはデフォルトでは割り当てられません。

仮想ルーターは VM インスタンスから外部ネットワークへのアクセスを処理するため、インスタンスは仮想ルーターに割り当てられた共通グローバル IP アドレスを共有します。インスタンスを外部ネットワークに公開し、外部ユーザーからの接続を許可するには、グローバル IP アドレスのプールからインスタンスにフローティング IP アドレスを割り当てます。

仮想ネットワークは単一のリージョンに含まれているため、異なるリージョンのインスタンスは、外部ネットワークを通じて通信するためにフローティング IP アドレスを使用する必要があります。

単一のネットワークに複数の仮想ルーターを含めることができます。異なるルーターに接続された VM インスタンス同士は、プライベート IP アドレスを使用して直接通信することはできませんが、フローティング IP アドレスを使用すれば外部ネットワーク経由で通信できます。

GCP では、すべての VM インスタンスは起動時に内部 IP アドレスと外部 IP アドレスが割り当てられます。必要に応じて、外部 IP アドレスを切り離すことができます。

デフォルトでは、外部 IP アドレスは一時的(エフェメラル)です。つまり、インスタンスの存続期間に関連付けられています。インスタンスをシャットダウンしてもう一度起動すると、別の外部 IP アドレスが割り当てられることがあります。永続的な IP アドレスもリクエストできます。これは「静的 IP」と呼ばれ、インスタンスに関連付けます。静的 IP アドレスはユーザーが解放するまでそのユーザーのもので、ユーザーが VM インスタンスに明示的に割り当てます。静的 IP アドレスは、必要に応じてインスタンスに関連付けたりインスタンスから切り離したりできます。

前述の 3 階層ウェブ アプリケーションのサンプル アーキテクチャで説明したように、OpenStack では異なるリージョンで同じグローバル IP アドレスを使用できないため、フェイルオーバー時にはダイナミック DNS などの追加メカニズムを使用して、クライアントが同じ URL を使用してサービスに引き続きアクセスできるようにする必要があります。

一方、GCP では、Cloud Load Balancing が提供する単一のグローバル IP アドレス(VIP)を使用して、クライアント アクセスを複数のリージョンおよびゾーンに分散できます。これにより、クライアントが意識することなく、リージョンとゾーン間のフェイルオーバーが実現します。

ファイアウォール

OpenStack の用語とコンセプトは、次のように GCP の用語とコンセプトに対応しています。

OpenStack GCP メモ
セキュリティ グループにょってファイアウォール ルールを適用します。 ルールとタグによってファイアウォール ルールを適用します。 OpenStack セキュリティ グループには複数の ACL が含まれています。これらの ACL は、インスタンスの役割別に定義されてからインスタンスに割り当てられます。

OpenStack セキュリティ グループは、リージョンごとに定義する必要があります。

GCP のルールとタグは、一度定義するとすべてのリージョンで使用できます。

OpenStack では、単一のセキュリティ グループに複数のアクセス制御リスト(ACL)が含まれています。この ACL は VM インスタンスに依存しません。VM インスタンスにセキュリティ グループを割り当て、そのインスタンスに ACL を適用します。通常、「ウェブサーバー」や「データベース サーバー」などの VM インスタンスの役割に従ってセキュリティ グループを定義します。

たとえば、サンプル アーキテクチャでは、リージョンごとに次のセキュリティ グループを定義します。

セキュリティ グループ ソース プロトコル
load-balancer 任意 HTTP/HTTPS
管理サブネット SSH
web-server load-balancer HTTPS
管理サブネット SSH
web-application web-server TCP 8080
管理サブネット SSH
database web-application MYSQL
管理サブネット SSH

パケットソースは、サブネット範囲またはセキュリティ グループの名前で指定できます。上の表では、管理サブネットは、メンテナンスの目的でシステム管理者がゲスト OS にログインするサブネット範囲を表します。

このアーキテクチャでは、クライアント SSL はロードバランサで終端し、ロードバランサは HTTPS を使用してウェブサーバーと通信することを前提としています。ウェブサーバーは TCP 8080 を使用してアプリケーション サーバーと通信します。データベース サーバーには MySQL が使用されます。

これらのセキュリティ グループを定義したら、次のように各インスタンスに割り当てます。

インスタンス セキュリティ グループ
ロードバランサ load-balancer
ウェブサーバー web-server
アプリケーション サーバー web-application
データベース サーバー database

GCP では、Cloud Virtual Network によって、「ルール」と「タグ」を組み合わせて、すべてのリージョンにまたがるファイアウォール ルールを定義できます。タグは VM インスタンスに関連付ける任意のラベルで、複数のタグを単一の VM インスタンスに割り当てることができます。「ルール」は、次の条件を指定してパケットフローを許可する ACL です。

  • ソース: IP 範囲、サブネット、タグ
  • 宛先: タグ

たとえば、宛先ポートが TCP 80 のパケットを任意の IP アドレスから「web-server」タグに送信することを許可する、というルールを最初に定義します。次に、任意の VM インスタンスにこの web-server タグを追加して、HTTP 接続を許可することができます。タグを管理してインスタンスの役割を指定し、ルールを管理して役割に個別に対応する ACL を指定します。

図 6 は、新しく作成されるプロジェクトに含まれる default ネットワークについて、事前定義されたルールを示しています。たとえば、10.128.0.0/9 は、すべてのリージョンにある基幹サブネットを含むサブネット範囲です。このサブネットの範囲は、プロジェクトごとに異なる場合があります。ルールでは上から順に、次のネットワーク接続が許可されています。

  • 任意の外部ソースからのインターネット コントロール メッセージ プロトコル(ICMP)パケット。
  • default ネットワークに接続されているすべてのインスタンス間のパケット。
  • 任意の外部ソースからのリモート デスクトップ プロトコル(RDP)接続。
  • 任意の外部ソースからのセキュアシェル(SSH)接続。

定義済みのファイアウォール ルール

図 6: デフォルトのネットワークの仮想クラウド ネットワークに事前に定義されているファイアウォール ルール

詳細については、ネットワークとファイアウォールの使用をご覧ください。

GCP ファイアウォール ルールでは、タグを使用してパケットの宛先を指定し、サブネット範囲またはタグを使用してパケットのソースを指定します。このシナリオでは、以下のルールを定義します。

ソース 宛先 プロトコル
130.211.0.0/22 web-server HTTP、HTTPS
web-server web-application TCP 8080
管理サブネット web-server, web-application SSH

上の表で、130.211.0.0/22 は、ロードバランサ / ヘルスチェック システムがウェブサーバーにアクセスするサブネット範囲です。管理サブネットは、メンテナンスの目的でシステム管理者がゲスト OS にログインするサブネット範囲を表します。web-serverweb-application はそれぞれウェブサーバーとアプリケーション サーバーに割り当てられたタグです。セキュリティ グループを使用する場合のようにルールを割り当てるのではなく、インスタンスの役割に合わせてタグを割り当てます。

データベース接続のアクセス制御は、Cloud SQL 構成の一部として、ソース IP アドレスに基づいて設定されます。

ストレージ

OpenStack の用語とコンセプトは、次のように GCP の用語とコンセプトに対応しています。

OpenStack GCP メモ
Cinder ボリューム 永続ディスク インスタンスに接続している永続ストレージ

GCP 永続ディスクの場合、データはインスタンスから永続ディスク ストレージに移動する前に、自動的に暗号化されます。

エフェメラル ディスク なし インスタンスに接続しているエフェメラル ストレージ
OpenStack Swift Cloud Storage オブジェクト ストレージ サービス
エフェメラル ディスクと Cinder ボリューム

OpenStack には、インスタンスに接続しているディスクの選択肢として、エフェメラル ディスクと Cinder ボリュームの 2 つがあります。

エフェメラル ディスクは、オペレーティング システム ファイルを含むシステム ディスクとして使用することを念頭に設計されており、Cinder ボリュームは永続的アプリケーション データを保存することを念頭に設計されています。ただし、エフェメラル ディスクではライブ マイグレーションを利用できないため、システム ディスク用に Cinder ボリュームを使用することもよくあります。

エフェメラル ディスクをシステム ディスクとして使用すると、OS テンプレート イメージが compute ノードのローカル ストレージにコピーされ、ローカル イメージがインスタンスに接続されます。インスタンスが破棄されると、接続したイメージも破棄されます。

Cinder ボリュームは、外部ストレージ デバイスに常駐する永続的なディスク領域を提供します。一般的なデプロイでは、ブロック デバイスは iSCSI プロトコルを使用して compute ノードに接続され、インスタンスに仮想ディスクとして接続されます。インスタンスが破棄されても、接続されたボリュームは外部デバイスに残り、別のインスタンスから再利用できます。

インスタンス上で動作するアプリケーション ソフトウェアは、OpenStack Swift が提供するオブジェクト ストレージにもアクセスできます。

エフェメラル ディスクと Cinder ボリューム

図 7: OpenStack のエフェメラル ディスクと Cinder ボリュームの比較

永続ディスク

GCP では、OpenStack の Cinder ボリュームと同様の永続ディスク形式で、インスタンスに接続された永続ストレージが提供されています。オペレーティング システム ファイルを含むシステム ディスクとして永続ディスクを使用し、永続的アプリケーション データを保存します。データは、インスタンスから永続ディスク ストレージに移動する前に自動的に暗号化されます。単一の永続ディスクを最大 64 TB まで拡張できますが、接続されるディスクの最大容量は、インスタンス サイズに基づいて制限されます。詳細については、ストレージ オプションをご覧ください。

高性能のローカル ストレージが必要な場合は、ローカルのソリッド ステート永続ディスク(SSD)を使用することもできます。各ローカル SSD のサイズは 375 GB ですが、インスタンスごとに最大 8 台のローカル SSD デバイスを接続して、3 TB の合計ローカル SSD ストレージ容量を利用できます。ライブ マイグレーションは、ローカル SSD が接続されているインスタンスで使用できることに注意してください。ライブ マイグレーション中にローカル SSD のデータがインスタンス間でコピーされるため、ストレージのパフォーマンスが一時的に低下する可能性があります。

インスタンス上で実行されるアプリケーション ソフトウェアは、Cloud Storage 提供のオブジェクト ストレージにアクセスできます。このホスト型サービスは、サイズの異なる大量のバイナリ オブジェクト(blob)の格納やアクセスに利用できます。

VM インスタンス

OpenStack の用語とコンセプトは、次のように GCP の用語とコンセプトに対応しています。

OpenStack GCP
インスタンスのタイプ マシンタイプ OpenStack では、一般ユーザーはカスタム インスタンス タイプを作成できません。

GCP では、どのユーザーもカスタム マシンタイプを作成できます。
メタデータ サービス メタデータ サーバー OpenStack はインスタンスに関する情報のみを提供します。

GCP はプロジェクトに関する情報も提供します。

OpenStack で新しい VM インスタンスを起動するときは、vCPU の数やメモリの量など、インスタンスのサイズを指定する「インスタンス タイプ」を選択します。システム管理者によって適切なアクセス権が割り当てられている場合は、追加のインスタンス タイプを定義できます。一般ユーザーはカスタム インスタンス タイプを追加できません。

GCP では、インスタンスのサイズはマシンタイプとして定義されます。あらかじめ定義されたマシンタイプから 1 つのタイプを選択し、さらに、ユーザーは、vCPU の数とメモリ量を別々に変更して、「カスタム マシンタイプ」を作成することができます。詳細については、マシンタイプをご覧ください。

メタデータ

OpenStack には、インスタンス タイプ、セキュリティ グループ、割り当てられた IP アドレスなどの VM インスタンス情報を、インスタンスのゲスト オペレーティング システム(ゲスト OS)から取得するメタデータ サービスが用意されています。キー - 値形式でカスタム メタデータを追加することもできます。OpenStack には user-data というメタデータのタイプが用意されています。新しいインスタンスの起動時に user-data に実行可能テキスト ファイルを指定し、ゲスト OS で実行される cloud-init エージェントに、ファイルの内容に従ってスタートアップ構成タスク(アプリケーション パッケージのインストールなど)を実行させることができます。ゲスト OS からメタデータへのアクセスには http://169.254.169.254/latest/meta-data の URL を使用します。

GCP には、インスタンスのゲスト OS からインスタンスとプロジェクトに関する情報を取得するためのメタデータ サーバーが用意されています。プロジェクト メタデータは、プロジェクト内のすべてのインスタンスによって共有されます。インスタンス メタデータとプロジェクト メタデータの両方にカスタム メタデータをキー - 値形式で追加することができます。GCP には startup-scriptshutdown-script という特別なメタデータがあり、それぞれインスタンスを起動または停止するときに実行されます。

OpenStack の user-data とは異なり、startup-script はインスタンスを再起動するたびに実行されます。startup-scriptshutdown-script の 2 つのスクリプトは、OS テンプレート イメージにあらかじめインストールされている compute-image-packages に含まれるエージェントによって処理されます。詳細については、インスタンス メタデータの格納と取得をご覧ください。

ゲスト OS からメタデータへのアクセスには、次のいずれかの URL を使用します。

  • http://metadata.google.internal/computeMetadata/v1/
  • http://metadata/computeMetadata/v1/
  • http://169.254.169.254/computeMetadata/v1/
ゲスト オペレーティング システム エージェント
OpenStack GCP メモ
cloud-init 設定タスク エージェント パッケージ compute-image-packages 設定タスク エージェント パッケージ OpenStack エージェントは初期ブート設定のみを処理します。

GCP エージェントは、インスタンスの実行中に初期ブート設定と動的な設定変更を処理します。

OpenStack では、標準のゲスト OS イメージに cloud-init というエージェント パッケージがあらかじめインストールされています。ルート ファイルシステム スペースの拡張、SSH 公開鍵の格納、user-data として提供されたスクリプトの実行など、最初のブート時の初期設定タスクを処理します。

GCP では、compute-image-packages というエージェント パッケージが標準ゲスト OS イメージにあらかじめインストールされています。最初のブート時に startup-script を使用して初期設定タスクを処理し、新しい SSH 公開鍵の追加や HTTP 負荷分散のためのネットワーク設定の変更など、ゲスト OS の実行中の動的システム設定も処理します。インスタンスを起動した後も、Google Cloud Platform Console または gcloud コマンドライン ツールを使用して新しい SSH 認証鍵を生成し追加できます。

Google Cloud SDK は、GCP 上の標準ゲスト OS イメージにあらかじめインストールされています。デフォルトで特定の特権が付与されているサービス アカウントを使用して、ゲスト OS から GCP 上のサービスにアクセスできます。

アクセス制御

GCP では、Google Cloud IAM によってインスタンスごとにアクセス制御を適用します。たとえば、アプリケーションをインスタンス上で実行して Google Cloud Storage にデータを保存する場合は、そのインスタンスに読み書き権限を割り当てることができます。Cloud IAM を使用すると、インスタンス上で実行されているアプリケーションのパスワードや認証情報コードを手動で準備する必要はありません。詳細については、インスタンスのサービス アカウントの作成と有効化をご覧ください。

OpenStack Keystone では、ユーザー アカウント ベースでサービス API のアクセス制御を提供しますが、インスタンス ベースでアプリケーション API のアクセス制御(オブジェクト ストレージやデータベースに対する読み書き権限など)を提供することはありません。必要に応じて、アプリケーション API のカスタム アクセス制御を実装できます。

IaaS を超えて: サービスとしてのプラットフォーム(PaaS)

この記事では、IaaS にとって不可欠な コンポーネントとサービスが OpenStack と Google Cloud Platform でどのような形で提供されているかを比較してみました。しかし、GCP を可用性、スケーラビリティ、オペレーション効率の面で最大限に活用するには、システム全体のビルディング ブロックとしてマネージド サービスを結合する必要があります。

GCP が現在提供するサービス群には以下も含まれ、IaaS プラットフォームの従来の概念をはるかに超えて拡張されています。

次のステップ

  • Google Cloud Dataproc と、GCP 全体のストレージ サービス、コンピューティング サービス、モニタリング サービスを統合して、完全なデータ処理プラットフォームを作成する方法について詳しく学習する。
  • Google Stackdriver を使用したモニタリング、ログ、診断について詳しく学習する。
  • Google BigQuery(サーバーレス プラットフォームを提供する、分析向けのフルマネージド データ ウェアハウス)について詳しく学習する。ペタバイト規模のデータセットでも SQL を使用してデータ分析に集中することができます。
  • Google Cloud Platform のプロダクトとサービスについて詳しく学習する。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

OpenStack ユーザーのための Google Cloud Platform