2023年アドベントカレンダー21日目、私個人としてはこの記事で本カレンダー6本目の記事です。
1本目の記事はこちら。
Amazon InspectorとMicrosoft Defender for Cloudの比較①脆弱な環境準備AWS編
2本目の記事はこちら。
Amazon InspectorとMicrosoft Defender for Cloudの比較②Amazon Inspector有効化と分析結果編
3本目の記事はこちら。
Amazon InspectorとMicrosoft Defender for Cloudの比較③脆弱な環境準備Azure編
4本目の記事はこちら。
Amazon InspectorとMicrosoft Defender for Cloudの比較④Microsoft Defender for Cloud有効化と分析結果編
5本目の記事はこちら。
Amazon InspectorとMicrosoft Defender for Cloudの比較⑤まとめ
前の記事から少し時間が空いています。
空いてる間にふと「GCPの記事書いてないな」と思ったんで今回書きます。
これでAzure、AWS、GCPと3大クラウドはQiitaで記事を書いたことになります。
OCI(Oracle Cloud Infrastructure)も使ったことがあるのですが、これはまた別の機会に。
実はGCPはGoogle Cloudに名称変更している
はい。
知ってる人は知ってると思うんですが、念のため記載しておきます。
Google Cloud Platformの略でGPCだったんですが、2022年6月21日にGoogle Cloudに名称変更しています。
https://cloud.google.com/blog/ja/topics/developers-practitioners/introducing-new-homepage-google-cloud
略称は何になるんでしょうね？
私も知ってたんですが、SIerの現場ではまだGCPって言ってるんで、私もわざわざ「名称変更してるんですよ！」なんて言ってません。
今回やってみたこと
VMのリージョンを跨いだのバックアップ/リストアです。
インフラ屋さんとしてはかなり気になるところですね。
まぁ一番簡単なVM(Goole Cloud EngineでGCEと言います。)で検証してみました。
バックアップ対象のGCE構築
GCEは何も考えずに適当に構築するとDebian11で構築されます。
そこにapache2インストールして、一応Let's EncryptでSSL化してデフォルトのindex.htmlに構築日を記載しました。
分かりにくいですが画像上部の赤枠内がこの環境を構築した日時です。
画像下部の赤枠内の時間と合致しているので、構築したてホヤホヤだということがお分かりいただけると思います。
今回採用したバックアップの取得方法
今回は単純にスナップショットで実施しました。
AzureでいうところのAzure Site Recovery(ASR)のようなGCEにエージェントをインストールしてどうのこうのみたいなサービスもあったので一度構築してみたのですが、私自身が初めて触るサービスだったので結構手間がかかって大変でした。
これはまた連載モノにしないと収まらない分量だったので、冬休みの宿題にしようと思っています。
AWSのサービスも含めて、Azure、AWS、GCPの3大クラウドで類似サービスを比較する、という、結構連載の回を重ねる記事になると思います。
毎度のことですがこれも全部自腹なので、いつになるのかは私のタイミングでやらせてください。(なので冬休み中にできないかもしれません)
実際のバックアップ設定1.バックアップのスケジュールを作成する
ではバックアップ設定を行います。
結構簡単です。
画面最上部の赤枠内にあるprj-cross-region-backup01というのがプロジェクト名、Azureでいうところのリソースグループですね。
prj=Project
cross-region-backup=リージョン跨ぎのバックアップ
という意味で命名しました。
Azureだとリソースグループ=rgみたいな感じですね。
(あの命名規則気に入ってるんですよね。)
画面左上の三本線、漢数字の三みたいな赤枠内をクリックするとGCEはじめ色んなサービスが出てくるので、その下の赤枠内Compute Engineを選択します。
これがGCEを表しています。
その下の赤枠内スナップショットを選択します。
これで現在取得済みのスナップショット一覧が見れる画面に遷移しますが、現在何もスナップショットが無いので「表示するスナップショットはありません」と表示されています。
まぁ当たり前ですね。
次に画面上部にある赤枠内の[スナップショット スケジュールを作成]をクリックします。
最上部の赤枠はスナップショットスケジュールの名前を付けます。
次の赤枠はオプションなので設定値は無くてもデプロイ可能ですが、私はここにUTC時刻とJST時刻を記載します。
Google Cloudのスナップショットのスケジュール設定機能は現時点(2023年12月18日23時40分時点)ではUTCでのみ設定可能です。
これではパッと見た感じで分かりにくいので、この説明(Description)にUTC→JSTの変換を記載するように工夫しています。
次の赤枠、[リージョン]ですが、この設定値は重要です。必ずスナップショット所得対象のGCEと同じリージョンを選択してください！
次の赤枠、[スナップショットのストレージのロケーション]内の設定、ここも重要です。ここはマルチリージョンを選択してください！
これでこのスナップショットで取得したイメージをマルチリージョンに展開が可能になります！
更にその下、この画像内の最後の赤枠、これも重要です！ここはこのスナップショット対象のGCEをどこのリージョンにリストアしたいかを要件として設定を決めてください！
つまりどういうことかというと、このスナップショットで取得したイメージをどこのリージョンでリストア、復元したいか、ということです。
因みにこの設定値、現時点(2023年12月18日23時48分時点)、ではUS、EU、Asiaの3種類が選択可能です！
もう赤字や太字ばっかりなんで、何が大事かわからなくなってきていますが、このリージョン設定、マルチリージョンか否か、どのロケーション(リストアしたいリージョン)の3点がこの記事の肝です！
ここさえ抑えておけばリージョン間でのバックアップ/リストアは把握したと言っても良いでしょう。
実際のバックアップ設定2.バックアップ時刻の設定
先ほどの画面の続きです。
最初の赤枠内のスケジュール頻度は今回毎日にしました。
2番目の赤枠内の開始時刻(UTC)は日本時間(JST)の0時から1時にバックアップを取得したいので、UTCの15時から16時にしています。
3番目の赤枠内のスナップショットの自動削除までの期間はその次の赤枠内の削除ルール→31日以上経過したスナップショットを削除するという、一般的に言うリテンションポリシー(バックアップデータ世代保持ポリシー)の設定となっています。
今回は最大1か月間、31日間を選択しました。
これで31日間、毎日日本時間の0時から1時にスナップショットを自動で取得し、31日より古いデータは自動で削除してくれます。
最大で31日間まで遡れる、ということですね。
これで最後の赤枠内の[保存]をクリックします。
1分くらいでスナップショットのスケジュールが作成されます。
実際のバックアップ設定3.バックアップ対象のGCEのディスクを選択する
画面左の赤枠内VMインスタンスをクリックしてます。
画面の中で小さな赤枠内にGCEのインスタンス名がありますので、これをクリックします。
今回GCEのインスタンス名はgce-crbu01としました。
gec=そのまま、GCEですね。
crbu=Cross Region Backupという命名です。
Backupって結構BKって略されるんですが、今回は敢えてBUにしてみました。
(が、しかし違和感がすごいですね。インフラ屋さんしかわからない感覚でしょうか？)
画面右側の赤枠内のスクロールバーでGCEの詳細設定が見れる全体画面の真ん中より少し下くらいに画面を動かします。
[ストレージ]の項目に[ブートディスク]という項目があります。
今回は簡単なWebサーバなのでブートディスク(OSが入っているディスク)しか存在しないので、これ(画面所の名称はgce-crbu01)を選択します。
現状のブートディスクの設定を確認しましょう。
画面左側の赤枠内の[スナップショット スケジュール]が[なし]になっていますね。
では画面上部の赤枠内の[編集]をクリックします。
設定値が出現しますので、赤枠内の[スナップショット スケジュール]をクリックします。
で、出ました！
先の手順で作成した[スナップショット スケジュール]ですね！
最近使ってなかった集中線使いましょう！
これですよ、これ！
来ましたね！
もう勝ちなんでお風呂入りましょう！
(今社内のインフラ屋さん3名の間だけで流行っている言葉です。細かい意味はわかりません。)
はい。
興奮冷めやらぬ中ではありますが、[スナップショット スケジュール]が正しく選択されていることを確認してから、画面下部の[保存]をクリックします。
はい。
今日も日付変わっちゃいました！
たぶんバックアップ始まってるかもしれませんが、これからリストアして確認作業する体力は無いので、本日はここまで！