めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

OpenStackユーザーのためのGoogle Cloud Platform入門(パート3)

前置き

これは、GCPの公式文書ではありません。公式ドキュメントについては、公式ホームページを参照ください。

Google Cloud Platform

実際に試してみたい方は、60日の無料トライアルをお試しください。(クレジットカードの登録が必要ですが、トライアル終了後は明示的に課金設定を行わない限り、勝手に課金されることはありませんので、ご安心ください。)

cloud.google.com

本記事のパート2はこちらです。

enakai00.hatenablog.com

パート3では、VMインスタンスに関連するコンポーネントとして、OpenStackのNova/CinderとGCPのCompute Engineを比較します。

インスタンスサイズ

OpenStackでは、インスタンスのサイズ(インスタンスに割り当てる仮想CPUの個数とメモリー容量)は、「インスタンスタイプ」から選択します。インスタンスタイプの内容は、システム管理者によって定義されており、一般の利用者が新しいインスタンスタイプを追加することはできません。

一方、Compute Engineでは、インスタンスのサイズは、「マシンタイプ」として定義されています。インスタンスの起動時にマシンタイプを選択するところはOpenStackと同じですが、必要な際は、CPUの個数とメモリー容量を個別に指定して「カスタムマシンタイプ」でインスタンスを起動することも可能です。

(参考)
Machine Types
Creating an Instance with a Custom Machine Type

ストレージオプション

OpenStackのEphemeral DiskとCinder Volume

 OpenStackでは、インスタンスに接続するディスクの種類として、「Ephemeral Disk」と「Cinder Volume」が選択できます。元々は、OSをインストールしたシステム領域にはEphemeral Diskを利用して、永続データの保存領域としてCinder Volumeを利用するという使い方が標準的とされていました。しかしながら、この構成の場合は、Live Migrationができないなどの制限があるため、現在では、システム領域にもCinder Volumeを利用する事が多くなりました。

Ephemeral Diskを使用する場合は、Glanceが管理するテンプレートイメージの複製をコンピュートノードのローカルディスクにダウンロードした後に、これを用いてインスタンスを起動します。インスタンスを停止・破棄するとローカルディスク上のディスクイメージも同時に破棄されます。一方、Cinder Volumeの実体は、外部のストレージ装置に存在する永続的なディスク領域です。典型的な構成では、iSCSIプロトコルでコンピュートノードに接続した後に、これを用いてインスタンスを起動します。インスタンスを停止・破棄してもボリュームの実体はそのまま残りますので、他のインスタンスに再度、接続して利用することが可能です。

・Ephemeral DiskとCinder Volumeの違い

Ephemeral Diskは、ディスクイメージの実体がコンピュートノードのローカルディスクに配置されるため、ディスク性能が要求される場合に利用されることがあります。Cinder Volumeについては、性能要件の異なるストレージ装置を用意しておき、利用者がボリュームを作成するストレージ装置を選択することも可能です。

その他には、インスタンスのゲストOSから、OpenStack Swiftが提供するオブジェクトストレージを使用することも可能です。

Compute Engineのストレージオプション

Compute Engineのインスタンスに接続するディスクは、「Persistent Disk」と呼ばれる永続的なディスク領域が基本となります。OpenStackと同様に、OSをインストールしたシステム領域に加えて、永続データの保存領域として追加のディスクを接続することも可能です。ディスクへの書き込み時は、自動的に暗号化の処理が行われるようになっています。1本のディスクは最大64TBまで拡張可能ですが、インスタンスのサイズによって、実際に接続できる最大容量が制限されています。

また、高い性能要件が求められる場合は、ローカル接続のSSDを使用することもできます。357GBのSSDを8本接続することで、最大3TBの容量が使用できます。また、ローカルSSDを接続している場合でもLive Migrationが可能です。ただし、ホスト間でSSDの内容のコピーが行われるため、Live Migrationの実行中は、ディスクアクセス性能が一時的に低下します。

その他には、インスタンスのゲストOSから、Cloud Storageが提供するオブジェクトストレージを使用することも可能です。

(参考)
Storage Options

メタデータ機能

OpenStackのメタデータサービス

OpenStackでは、「メタデータサービス」を利用することにより、インスタンス内部のゲストOSから、インスタンスに固有の情報を取得することができます。具体的には、「http://169.254.169.254/latest/meta-data/」以下のURLにHTTPでアクセスすることにより、対応する情報が取得されます。インスタンスタイプ、セキュリティグループ、IPアドレスなどの情報が取得可能です。その他には、独自のメタデータを「Key-Value」形式で付与することもできます。

その他に、「user-data」と呼ばれる特別なメタデータがあります。インスタンス作成時にuser-dataにテキストファイルを与えると、ゲストOSの初回起動時に「cloud-init」と呼ばれるエージェントがこれを受け取って、ゲストOSの初期設定に利用します。例えば、スクリプトファイルを与えると、cloud-initによって自動的に実行されるので、アプリケーションのインストール処理などをスクリプトで自動化することができます。

Compute Engineのメタデータサーバー

Compute Engineでは、「メタデータサーバー」の機能により、インスタンス内部のゲストOSから、インスタンス固有の情報を取得することができます。以下のいずれかのURLを使用します。

http://metadata.google.internal/computeMetadata/v1/
http://metadata/computeMetadata/v1/
http://169.254.169.254/computeMetadata/v1/

提供されるメタデータには、インスタンスに固有の「Instance metadata」と、インスタンスが所属するプロジェクトの情報を提供する「Project metadata」があります。Instance metadataとProject metadataのそれぞれについて、独自のメタデータを「Key-Value」形式で付与することも可能です。

特に「startup-script」と呼ばれるメタデータに任意のスクリプトファイルを与えると、ゲストOSの起動時に「compute-image-packages」が提供するエージェントによって自動的に実行されるので、アプリケーションのインストール処理などをスクリプトで自動化することができます。OpenStackのuser-dataと異なり、startup-scriptは、インスタンスを再起動した際にも実行されます。また、インスタンスを停止する際に実行される「shutdown-script」を利用することも可能です。

(参考)
Storing and Retrieving Instance Metadata

ゲストOSで動作するエージェント

OpenStackのcloud-init

OpenStackでは、ゲストOSにcloud-initと呼ばれるエージェントをインストールすることにより、初回起動時の初期設定を行います。これには、ルートファイルシステムの拡張、SSH認証鍵の設定、user-dataの実行などが含まれます。

Compute Engineのcompute-image-packages

Compute Engineでは、compute-image-packagesが提供するエージェント群をインストールすることにより、初回起動時の初期設定に加えて、ゲストOSが稼働中の動的な構成変更などを行います。初回起動時の初期設定は、OpenStackと同様に、ルートファイルシステムの拡張、SSH認証鍵の設定、startup-scriptの実行などが含まれます。

ゲストOSが稼働中の構成変更については、SSH認証鍵の追加設定やロードバランサー配下に組み込む際のネットワーク設定変更などがあります。Cloud Console、もしくは、gcloudコマンドを利用すると、稼働中のインスタンスに対して、新たなSSH認証鍵を生成して登録することが可能ですが、これは、ゲストOS内のエージェントを利用して設定作業が行われます。

なお、ゲストOSを外部から操作する際は、メタデータサーバーの機能が利用されます。Compute Engineのメタデータサーバーは、メタデータの更新をエージェントに通知する機能があり、メタデータの更新をトリガーにして、エージェントによる設定変更作業を行います。

(参考)
Scripts and tools for Google Compute Engine Linux images.

ゲストOS内から他のサービスへのアクセスについて

Compute EngineのゲストOSには、GCPの他のサービスにアクセスするためのSDK(gcloudコマンドなど)が事前に導入されており、「サービスアカウント」の権限によって、他のサービスを利用することができます。この時、IAMの機能により、サービスアカウントから利用可能なサービスの範囲がインスタンスごとに設定されます。たとえば、Cloud Storageに対しては、デフォルトでは、読み込み権のみが設定されます。したがって、Cloud Storageに書き込みを行う際は、Cloud Console、あるいは、gcloudコマンドを用いて、サービスアカウントに対するアクセス権限の変更を行う必要があります。これは、インスタンスごとに利用可能なサービスの範囲が制御されるようになっており、インスタンス上で許可されたサービスにアクセスする際は、パスワードやクレデンシャルコードの入力は不要になります。

(参考)
Creating and Enabling Service Accounts for Instances

次回予告

次回は、典型的な3層Webアプリケーションを構築する際に使用するコンポーネント(サービス)をOpenStackとGCPで比較したいと思います。

enakai00.hatenablog.com