こんにちは！
BFT名古屋支店の佐野です。
今回は佐野が勝手に進めるブログプロジェクト「GCPクイックスタートガイド」の第７回です。
前回まででGCP環境上のネットワークの整え方を解説しましたので、今回からはそのネットワーク上に配置するGCPリソースについて扱っていきます。
今回はGCP上で仮想マシンを作成する代表格のサービス、Google Compute Engine（GCE）のお話です。
GCPの仮想マシン作成サービス、Google Compute Engine（GCE）
クラウドサービスを利用してシステムを構築する際に、大半は使用することになる仮想マシン。
GCPにおいては、一般的に仮想マシンと指すものはGoogle Compute Engine（GCE）を使って作成します。
AWSで言えばEC2に相当するGCEですが、EC2と比べるとパフォーマンス面で優れていると言われており、実際にEC2とGCEで作成できる最高スペックのインスタンスを単純に比較すると以下の差があります。
| インスタンスタイプ | vCPU | メモリ | ストレージ | ネットワーク帯域幅 |
|---|---|---|---|---|
| Amazon EC2 z1d |
48 | 384 GiB | 900 GB NVMe SSD |
25 Gbps |
| GCE N2D-standard-224 |
224 | 896 Gib | カスタムディスクタイプとサイズ (最大64TBまで可能) |
32 Gbps |
AWS、GCPどちらの環境においても、ここまでのスペックを必要とするケースは稀ですが、引き出せるパフォーマンスの最大値は明らかにGCPの方が上です。
しかしAWSにあってGCPにない点もあります。それは「MacOSがサポートされているか」です。
EC2はMacOSを搭載したインスタンスをコンソール上で難なく作成できますが、GCEではMacOSがサポートされていないため、実質MacOS搭載のインスタンスが作成できません。
その他、EC2とGCEは扱う上で似通う点が多いものですが、GCEの作成時にはEC2に慣れていると戸惑うこともあるかもしれません。
というのも、EC2では最初に利用するOSやマシンイメージを選択し、その後インスタンスタイプを一覧形式のプルダウンから選ぶ形なのに対して、GCEはインスタンスの種類を選んでからvCPUとメモリがプリセットされたインスタンスタイプを選んだりvCPUやメモリなどをカスタムする形式を選んだりした後、設定の終盤部分でようやく「ブートディスク」という形でOS（イメージ）を設定する形式となっています。
この「ブートディスク」でOSを変えるという点もやや気づきにくく、知らないと見過ごしてデフォルトとなっているDebian OSでインスタンスを作成してしまいがちです。
これに限った話ではありませんが、AWSとGCPはコンソールの作りの考え方に結構な差があるので、片方に少し慣れ始めた人は何となくで進めるとハマってしまうこともあるでしょう。
特に顕著な箇所のひとつがこのEC2とGCEであるので、紹介しました。
そしてGCEが持つ独自の点であり、大きな利点でもある要素にライブマイグレーション機能があります。
ライブマイグレーション機能
GCEにはライブマイグレーションという機能がデフォルトで有効になっています。
これはGoogle側によるGCPのメンテナンス時、動ているインスタンスをそのまま同一ゾーン内の別の内部サーバへ移動することで、インスタンスへの影響を出すことなくメンテナンスを実施するという仕組みです。
例えばAWSの場合はEC2インスタンスの運用中にメンテナンスが発生した場合、AWS上のシステムを運用している方々にメンテナンス告知のメールが送られ、インスタンス再起動などの対処を求められます。
GCPにおいてもAWSと同じように、むしろAWS以上に頻繁にメンテナンスが行われますが、ライブマイグレーションが有効になっているインスタンスであればメンテナンスの影響をほとんど受けることなく、そのまま稼働し続けることができます。
また内部サーバ要因の障害が起こりそう、という時にもライブマイグレーションが行われ、実際に障害になってしまう前にその内部サーバで稼働しているインスタンスを別のサーバに移すということが行われています。
ライブマイグレーションの動きはGCEのシステムログに記録され、それを見ればいつマイグレーションが起こったのかを知ることができますが、実際にマイグレーションによってVMが停止するのは1秒にも満たない時間で、パケットロスや接続切れが起きることもありません。
そのため、マイグレーションの発生をわざわざシステムログから監視するようなことがなければ、運用上においてマイグレーションが起きた瞬間に「マイグレーションされた」と感じることは滅多にないでしょう。
なおライブマイグレーション機能は無効にできず、後述するSpotVMにはライブマイグレーション機能は適用されません。
GCEインスタンスの作成
では実際にGCEインスタンスの作成の仕方を作成画面を踏まえて解説します。
本記事では筆者主観ながら特に作成画面において抜けやすい、あるいは分かりにくいと考える点を重点的に見ていきます。
GCEインスタンスの作成はナビゲーションメニューから「Computing Engine」を選択し、その配下の「VM インスタンス」を選んだ後、コンソール上の「インスタンスを作成」から行えます。
その先の「インスタンスの作成」で作成するインスタンスの内容を決めます。
まず最初に決めるのはインスタンスの「名前」、そしてインスタンスを配置する「リージョン」および「ゾーン」です。
リージョンとゾーンは、作成する先、つまり配置先のリージョンとゾーンを定めるので、ひとつのリージョンとゾーンにのみ配置可能であり、作成後はリージョンもゾーンも変更できません。
また「タグとラベルを管理」を展開すると「ラベルを管理」と「ADD TAG」が選択できるようになります。
それぞれでラベルとタグを作成するインスタンスに割り当てることができます。
ラベルは主に共通のセキュリティポリシーを適用する時や、自動化スクリプトなどによってインスタンスを管理する場合におけるインスタンスの識別に、タグは前回の記事で述べたファイアウォールポリシーの適用先の指定やロードバランシング時の宛先の識別に使用します。
その後にインスタンスの性能を決める「マシンの構成」があります。
先述の通りGCEでの性能の選び方は、まず先にマシンタイプファミリーを選んでから、インスタンスサイズを選択する形です。
CPU数、メモリ数のパターンが数多く揃っているため、その中から用途に適するものを選びます。
また「マシンタイプ」でプリセットではなくカスタムを選択すると、コア数とメモリを自分で決めて、独自のインスタンスサイズを設定することができます。
（ただしその場合、追加料金が発生します）
ここの詳細設定を展開すると「vCPUとコアの比率」と「可視コアの数」が設定可能です。
直下の「可用性ポリシー」では「VMプロビジョニングモデル」を設定できます。
ここで「スポット」を選択すると、作成するインスタンスをスポットインスタンス(Spot VM)にできます。
Spot VMはGCEの余剰キャパシティを使ったインスタンスになるため、通常と比べて安く利用できますが、余剰キャパシティが他の用途に回される際にはGCP側で停止・削除される可能性があるものです。
詳しくは以下の公式ドキュメントを参照ください。
また詳細設定を展開すると「自動再起動」の設定を行なえます。
オンにした状態であれば、メンテナンスや障害によってインスタンスが終了した場合でも、GCP側から再起動の処理が行われます。
「ホストメンテナンス時」も項目としてはあり、これがライブマイグレーションに相当するものですが、「VMインスタンスを終了」の選択肢はSpot VMでのみ利用可能なため、実質的に変更不可能です。
設定も後半になり、前述したブートディスク設定が見えてきました。
ブートディスクまでのうち、特筆して設定すべきは「表示デバイス」で、これを有効化するとGCP上で仮想表示デバイスを立ち上げ、踏み台サーバを使用せずにリモートデスクトップ接続を行なえるようになります。
Confidential VMs サービスはGCP側すら確認できないキーでインスタンスの暗号化を行ない、データの保護を強化するものですが、使用できるマシンタイプファミリーやインスタンスサイズが限定されます。
またコンテナはインスタンスにコンテナイメージをデプロイするための設定であるため、コンテナを利用しない場合は設定しません。
（本記事ではコンテナのデプロイについては取り扱いません）
ブートディスクの設定は「ブートディスク」の「変更」を選択することで行なえます。
ブートディスクの設定では、インスタンスのOSやディスクサイズを設定できます。
OSイメージは公開されたイメージやユーザが用意したカスタムイメージ、スナップショットから選ぶことができ、公開イメージの場合は以下図の通りのOSを利用できます。
またディスクタイプは４種類から選ぶことができ、それぞれのディスクの比較も「ディスクタイプを比較」から行えます。
また詳細設定を展開すると、インスタンス削除時にブートディスクを保持するか削除するか、暗号化形式の設定や自動スナップショットのスケジュール適用の設定が行えます。
その後、インスタンスに付与するサービスアカウントを選択します。
ここでは、可能であれば予めサービスアカウントを作成し、ここでそのサービスアカウントを割り当てるという形を取るのがベストですが、無ければデフォルトのサービスアカウントを選択しておくのがよいでしょう。
デフォルトのサービスアカウントを選択した場合、さらにアクセススコープを設定できますが、特にAPIへのアクセス権を絞る要件が無ければ「デフォルトのアクセス権を許可」あるいは「すべてのCloud APIに完全アクセス権を許可」としておきましょう。
現在のGCPではアクセススコープではなくサービスアカウントによる権限管理を行なうのがベストとされているため、ここで詳細な権限を設定するよりはサービスアカウント側で権限を設定し、インスタンスに割り当てるのがよいです。
最後に詳細オプションからネットワーキングを展開し、ネットワーク設定を行ないます。
（これを行なわないと、意図しないIPがインスタンスに割り振られてしまう上、詳細オプションを展開しないと設定できないために見逃しがちなので注意しましょう）
ネットワーキングでは特に「ネットワークタグ」の設定と「ネットワークインターフェース」の設定が重要です。
ネットワークタグは前回の記事で述べた通り、ファイアウォールルールの適用先を識別するために必要なものなので、設定しておくとよいでしょう。
ただしファイアウォールルール適用先をサービスアカウントで識別する場合は不要です。
ネットワークインターフェースは最初はDefaultのものが設定されていますが、基本的に使用しないようにしましょう。
インターフェース名の右側のごみ箱を選択すれば、そのインターフェースを削除することができます。
そして「新しいネットワークインターフェース」を選択すると、新たなネットワークインターフェースの作成設定を行なうことができます。
そこで用意したVPCとサブネット上にインスタンスが配置できるよう、「ネットワーク」と「サブネットワーク」を指定して、必要であれば「プライマリ内部IPv4アドレス」を「エフェメラル（カスタム）」として、任意のＩＰを設定しましょう。
また内部アクセスのみのプライベートなインスタンスを作成したい場合は「外部IPv4アドレス」を「なし」にすることで、外部IPを持たないインスタンスにできます。
以上を設定したら最下部の「作成」を選択すればインスタンスを作成できます。
区切り
GCEは何となく手なりでインスタンスを作成すると、意図しない設定を多く含んだインスタンスができてしまいがちと筆者は思っています。
（そういうケースが起きがちだったというのもあります）
今回紹介した点に注意してしっかり設定することで、必要なインスタンスを間違いなく作成しましょう。
今回は基本的なインスタンスの作成でしたので、次回はデータベースインスタンスの作成について解説します。
【次回】
【前回】
