Google Cloud Japan Advent Calender 2022 (今から始める Google Cloud) の 5 日目です！
本日のテーマは Compute Engine です。GCE と呼ばれることが多いですが、正式名称は Compute Engine です。Compute Engine はいわゆる IaaS と呼ばれる仮想マシン (VM) を提供するサービスで、ユーザーは OS 以上のレイヤーをカスタマイズできるので自由度が高く、オンプレからクラウドへ移行する際の移行先サービスとして最も多く選ばれています。
ただし、OS 以上のレイヤーを自由にカスタマイズできるということは、PaaS や SaaS といったサービスと比べて各プラットフォームごとの機能差異が出にくいという性質もあります。そこで本日の記事では、機能差異が出にくいと言われる IaaS サービスの中にある Compute Engine において、Compute Engine ならではの特徴的な機能についてご紹介します。
1. Compute Engine の概要
Compute Engine は仮想マシンを提供するサービスと記載しました。仮想マシンを起動するためにはスペックを選び、OS を含むデータを格納するためのディスクをアタッチし、通信を行うためにネットワークに属してファイアウォールの設定を行う必要があります。このあたりはオンプレや他クラウドでも同様ですが、Compute Engine ではどのような選択肢があるかを簡単にご紹介します。
1-1. マシン ファミリー / マシンシリーズ / マシンタイプ
仮想マシンのスペックを決める際に選ぶのがマシン ファミリー / マシンシリーズ / マシンタイプです。マシン ファミリーとは特定の目的に合わせて最適化されたマシン群の総称、マシンシリーズとは同じ機能や制限などをもつマシン群の総称、マシンタイプとはサーバー スペックごとに定められた個別のマシン名になります。
下記の図を基に説明すると、コスト最適化やバランス、スケールアウト最適化がマシン ファミリー名、E2 や N2、N2D がそれぞれマシンシリーズ名になります。そしてマシンタイプは、n2-standard-4 (N2 シリーズの 4 vCPU / 16 GB メモリー マシン)、c2-standard-8 (C2 シリーズの 8 vCPU マシン / 32 GB メモリー マシン) のように各マシンシリーズ内でさらに特定のスペックを持つマシンを表す名称です。
図 1. マシン ファミリー / マシンシリーズ / マシンタイプの例
1-2. ブロック デバイス
OS やアプリケーション データなどを保存するためには Persistent Disk や Local SSD というブロック デバイスを利用します。それぞれのブロック デバイスの 基本的な用途は以下の通りで、データの永続化の必要性や求められるパフォーマンス (IOPS / スループット) に応じていずれかを選択します。(OS は永続化が必要なので Persistent Disk が必須です)
- Persistent Disk：OS やデータを保存するブロック デバイス
- Local SSD：(Optional) 高いパフォーマンスが必要な際に利用する揮発性のブロック デバイス
なお、Persistent Disk のパフォーマンスはディスクタイプとディスクサイズに依存します。Persistent Disk には Standard、Balanced、SSD、Extreme という 4 種類のディスクタイプが存在し、Extreme が最も高いパフォーマンスが得られますが、その分高価 (1 GB 単位あたりの単価についてはこちら) です。また、Persistent Disk のサイズは 1 GB 単位で指定可能であり、得られるパフォーマンスはディスク サイズに比例して増減します。(各ディスク タイプに応じて上限があります)
ディスク パフォーマンスの算出方法については 2 年前のアドベント カレンダーのこちらの記事も参考になりますので、ぜひご確認ください。
1-3. ネットワーク
ネットワークと言っても幅が広いので、ここでは通信に最低限必要となる IP アドレスの話をします。一般的なサーバーと同様に、Compute Engine には内部 IP アドレスと外部 IP アドレスを割り当てることができます。Google Cloud のネットワーク サービスである VPC については 4 日目の記事もぜひご参考ください。
内部 IP アドレス
内部 IP アドレスは、VPC (専用線で接続されたオンプレミス環境含む) に属する他の仮想マシンと通信をする場合に利用されます。Compute Engine は仮想マシンなので、VPC 内の任意のサブネットへのデプロイが必須です。既定ではサブネット内の任意の IP アドレスが内部 IP アドレスとして割り当てられ、通信に利用されます。(内部 IP アドレスの固定も可能です)
外部 IP アドレス
外部 IP アドレスは、外部インターネットや Google サービス (Google サービスの API (*.googleapis.com) など) との通信に利用されます。外部 IP アドレスを付与しないことも可能ですが、その場合には既定では外部インターネットや Google サービスとの通信はできません。
ただし、セキュリティ リスクを鑑み、仮想マシンに外部 IP アドレスを付与しない運用は非常に一般的です。そして外部 IP アドレスを付与しない場合でも外部インターネットや Google サービスにアクセスしたい場合も当然考えられます。このような場合には、Cloud NAT というサービスで NAT を行うことで外部インターネットにアクセスしたり、サブネット単位で限定公開の Google アクセスという機能で Google サービスへアクセスできます。(本記事ではこれ以上の詳細は割愛します)
1-4. ファイアウォール
ファイアウォールについても 4 日目の記事でも説明がありましたが、重要な部分なので再度簡単に記載します。Compute Engine を VPC 内にデプロイすればどんな宛先の通信も可能というわけではありません。Compute Engine では、セキュリティを担保することを目的として暗黙的なファイアウォールによって Ingress の通信、つまり仮想マシンが受信する通信は既定ではすべて拒否されています。そのため、仮想マシンに対して何らかの通信を行いたい場合はファイアウォール ルール (ファイアウォール ポリシーも存在しますが、今回は割愛します) を作成し、当該通信を許可する必要があります。(Egress の通信、つまり仮想マシンから送信される通信は既定ですべて許可されています)
ファイアウォール ルールは VPC 単位で設定するものであり、以下の項目によって通信を制御します。
- 通信の向き (Ingress / Egress)
- ファイアウォール ルールの適用対象 (VPC 内のすべて / 特定のタグが付与された仮想マシン etc)
- 送信元、もしくは送信先 (IP アドレス / タグ)
- プロトコルとポート
例えば、同一の VPC 内に複数の Compute Engine がデプロイされており、その中の 1 台だけに対して HTTPS (443) の通信を許可したいとします。この場合、対象の仮想マシンに任意のタグ (“webserver” などの意味のあるタグを推奨します) を付与し、ファイアウォール ルールの適用対象にタグ名を指定します。
なお、ファイアウォールは境界型のファイアウォールではなく分散ファイアウォールです。同一 VPC 内の複数の仮想マシンに対して別々のファイアウォールを適用することも可能であるため、仮想マシンの役割ごとにサブネットを切る必要は必ずしもありません。
2. Compute Engine の特徴的な機能
ここまでで、Compute Engine を利用する上で必ず必要となるサービスやオプションなどについてご紹介しました。ここからは Compute Engine ならではの仕組みについてご紹介します。
2-1. カスタム マシンタイプ
マシンのスペックはマシンタイプごとにあらかじめ決まっています。n2-standard-4 であれば 4 vCPU / 16 GB メモリーというスペック、c2-standard-8 であれば 8 vCPU マシン / 32 GB メモリーというスペックです。しかし、あらかじめ用意されたマシンタイプが要件を満たさない場合もあります。例えば 4 vCPU は必要だがメモリーは 8 GB で十分な場合でも、N2 のマシン シリーズには 4 vCPU / 8 GB メモリーというぴったりスペックのマシンタイプがありません。そのため、vCPU の要件を満たすために n2-standard-4 を選ぶ必要がありますが、余分なコストが発生してしまいます。(vCPU やメモリーを多く積めばその分コストがかかります)
この場合に有用なのがカスタム マシンタイプです。カスタム マシンタイプは vCPU 数やメモリー容量を独自にカスタマイズできる機能で、あらかじめ用意されたマシンタイプ内に要件にぴったり合うサイズがない場合でも、必要なサイズのマシンを自由に作ることができます。先の例の場合、n2-custom-4-8192 というマシンタイプを作ることでコストが最適化されます。
ただし、vCPU : メモリーの比率はマシン シリーズごとに決められているため、4 vCPU / 256 GB メモリーのような極端な vCPU : メモリー比率のマシンタイプを作ることはできません。
2-2. ライブ マイグレーション
Compute Engine の最大の特徴がライブ マイグレーションです。IaaS サービスを利用する場合、通常はサービス プロバイダー側のメンテナンスによる再起動などの影響を避けることはできません。特に、仮想マシンが稼動している物理ホストのアップデートを行う場合にはどうしても仮想マシンを別の物理ホストへ移動させる必要があるために再起動が必要となり、例えば揮発性領域に保存されたデータが削除されるといった影響が生じます。
ライブ マイグレーションの機能を有効化 (既定で有効) することで、上記のようにユーザーが制御することができないような物理ホストのアップデートを含むメンテナンス時にも再起動は不要となり、揮発性領域に保存されたデータやメモリー内に格納されたデータなどを保持したまま仮想マシンが別の物理ホストへ移動します。アプリケーションへの影響を抑えて透過的にメンテナンスが完了するので、Compute Engine では実はメンテナンスの事前通知は行われません。
ライブ マイグレーションは、コマンドひとつでシミュレーションが可能です。アプリケーションが稼働した状態で以下のコマンドを実行することで、自社アプリケーションへの影響を調べることができます。
gcloud compute instances simulate-maintenance-event VM_NAME --zone ZONE
2-3. 確定利用割引と継続利用割引
さまざまなクラウド サービスで、サービスをお得にご利用いただくための仕組みが用意されています。IaaS サービスでは、一定期間 (1 年、もしくは 3 年が一般的) の利用を予約することで割引を受けられる仕組みを提供するサービスが多いです。Compute Engine では、このような割引提供の仕組みも特徴的です。
確定利用割引 (CUD : Committed Use Discount)
1 年、もしくは 3 年間の利用を確約いただくことで割引が受けられる仕組みです。このような仕組み自体はよくありますが、一般的には特定のマシンタイプ単位 (e.g. n2-standard-8 を 10 台) で利用を確約します。つまり、スケールアップ / ダウンによって仮想マシンのサイズを変えた場合、割引を受けられません。
一方で、CUD ではマシン シリーズのリソース単位 (e.g. N2 シリーズの vCPU を 80 コア / メモリーを 320 GB) で利用を確約します。そのため、同一のマシン シリーズであれば、仮想マシンのサイズを変えた場合でも割引を受けられます。
継続利用割引 (SUD : Sustained Use Discount)
CUD を利用することで Compute Engine をお得に利用できますが、どれだけのリソースを使うかがわからない状態で 1 年、もしくは 3 年間の利用を確約することは難しい場合もあります。Compute Engine は仮想マシンを停止していればコストは発生しませんが、CUD で確約したリソースは仮想マシンを使っていない場合でも支払いが発生するため、なるべく必要な分だけ利用を確約したいところです。
SUD は、CUD と違ってリソースの利用を確約せずとも割引が受けられる仕組みです。具体的には、下記の図のように 1 ヶ月の間に仮想マシンを起動した時間に応じて割引が適用され、例えば N1 マシン シリーズの場合は 1 ヶ月仮想マシンを起動し続けていると 30% の割引が受けられます。そして嬉しいのは、SUD の利用に設定などは必要なく、自動で適用されます。(SUD が利用できないマシン シリーズもあります)
図 2. SUD における起動時間と割引率の関係性
3. FAQ
いろんな機能を紹介し続けているとやたらと長くなるので、この章ではみなさんが気になっているかもしれないいろんな疑問にお答えします！記事の長さの都合上すべてを詳細に説明できないのでできる限り参考資料をポイントします。
3-1. Compute Engine の SLA はどれくらいですか
単一インスタンスの場合は 99.5%、マルチゾーンへデプロイを行うと 99.99% です。(資料)
3-2. どのような OS が利用できますか
Windows や各 Linux ディストリビューションなど、一般的に利用されている OS は基本的に利用可能です。各 OS のイメージも Google Cloud で用意しているので簡単にデプロイできますし、イメージをインポートすることもできます。
3-3. バックアップの仕組みはありますか
あります。バックアップを行う場合、以下の 2 つの選択肢があります。
- Persistent Disk のスナップショットを取得する
- Google Cloud Backup & DR Service を利用する
3-4. 自動スケーリングは可能ですか
可能です。Managed Instance Group と呼ばれる機能を利用することで仮想マシンの自動スケーリングができます。
3-5. コンテナは動きますか
動きます。通常の Windows / Linux OS で docker などを利用してコンテナを実行することもできますし、COS (Container-Optimized OS) と呼ばれるイメージを選択してコンテナを実行することもできます。
3-6. ディスクは冗長化されていますか
はい、冗長化されています。なお、Persistent Disk には Zonal Persistent Disk と Regional Persistent Disk という種類があり、 Regional Persistent Disk を利用することで 2 つのゾーン間にまたいだ冗長性が担保されます。
4. おわりに
説明だらけになってしまいましたが、本ブログでは Compute Engine の基本的な機能や特徴についてご紹介しました。Compute Engine は OS 以上を自由にカスタマイズできるので比較的取っつきやすく、冒頭で書いたとおり移行先として広く選ばれています。基本的には今日ご紹介した選択肢を考慮すれば簡単にデプロイもできますし、ぜひ一度デプロイだけでもお試しいただければと思います。
明日は Compute Engine と並んで Google Cloud のサービスとして広く使われている Google Kubernetes Engine です！お楽しみに！！
Discussion