LoginSignup
1
0

【Google Cloud】ある日突然AlloyDBインスタンスが起動できなくなった件

Posted at

はじめに

本記事はGoogle CloudのプライベートサービスアクセスやAlloyDBサービスをある程度理解していることが前提となります。
用語等を解説しきれていないところがありますので、必要に応じて以下等でサービスや用語の確認をお願いします。

・G-GEN様ブログ「AlloyDB for PostgreSQLを徹底解説!」
https://blog.g-gen.co.jp/entry/alloydb-for-postgresql-explained

結論

  • AlloyDBのクラスタ作成後に"「プライベートサービスアクセス」の「サービスに割り当てられたIP範囲」"を解放してしまったことが原因
  • 解放した"「プライベートサービスアクセス」の「サービスに割り当てられたIP範囲」"を元に戻すことで解消した

事象

Google Cloud(GCP)のAlloyDBを使ってプロジェクトの機能検証をしており、不要な課金を減らすためにクラスタ(ストレージ)は残してインスタンスだけ毎日削除、作成するようにしていた。
そうしたところ、前日までは正常に既存クラスタに対してインスタンスが作成できていたのだが、ある日突然「クラスタ名 で インスタンス名 を作成できませんでした」というオペレーションエラーメッセージ(詳細は以下)が表示され、インスタンスが作成できない事象が発生してしまった。

【エラー詳細】
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The request was invalid: error Reserved range: 'サービスプロデューサーのVPC名' not found for consumer project: 'プロジェクト番号' network: 'ユーザ作成のVPC名'. com.google.api.tenant.error.TenantManagerException: Reserved range: 'サービスプロデューサーのVPC名' not found for consumer project: 'プロジェクト番号' network: 'ユーザ作成のVPC名'., see https://cloud.google.com/alloydb/docs/configure-connectivity for details
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

事象再現手順

以下にて、事象再現するための手順を説明する。

1.関連ネットワークの作成

1-1.VPCネットワークを作成※設定は以後の手順に関係ないため任意
001.png

1-2.作成したVPCネットワークの詳細の「プライベートサービスアクセス」の「サービスに割り当てられたIP範囲」より「IP範囲の割り振り」を選択
※サービスプロデューサーのVPCにサブネットを作成するイメージの作業
003.png

1-3.内部IP範囲の割り振りを実施(1つ目)
004.png

1-4.内部IP範囲の割り振りを実施(2つ目)(IP範囲を2つ以上作成した際に事象が発生するため、2つ作成)
005.png

1-5.作成したVPCネットワークの詳細の「プライベートサービスアクセス」の「サービスのプライベート接続」より「接続を作成」を選択
※サービスプロデューサーのVPCと1-1で作成したVPC間でVPCピアリング設定を行う
006.png

1-6.「1-3」並びに「1-4」で作成したIP範囲を選択して接続を作成
007.png

1-6.「接続名」が「servicenetworking-googleapis-com」の行に「割り当て」に「1-3」並びに「1-4」で作成したIP範囲の名前が表示されることを確認
※サービスプロデューサーのVPCとのVPCピアリングの名称は「servicenetworking-googleapis-com」で固定
008.png

2.AlloyDBの作成

2-1.AlloyDBのページの「クラスタを作成」より新規クラスタの作成。この際設定項目「ネットワーキング」の項目について以下を選択
 ・「ネットワーク」:「1-1」で作成したVPC 
 ・「割り振られているIP範囲」:「1-3」で作成したIP範囲のみ※「1-4」で作成したIP範囲は選択しない
 ・他の項目は任意の値もしくはデフォルト値でOK
101.png

2-2.AlloyDBのクラスタ並びにインスタンスが作成されたことを確認したら、プライマリインスタンスの操作から「削除」を選択してインスタンスを削除する
102.png

2-3.AlloyDBのインスタンスが削除されたことを確認する
103.png

3.VPC設定より「サービスに割り当てられたIP範囲」の削除

3-1.「1-1」で作成したVPCネットワークの詳細の「プライベートサービスアクセス」の「サービスに割り当てられたIP範囲」より「1-4」で作成したIP範囲にチェックをつけた上で「解放」を選択
010.png

3-2.「解放」を押下して「1-4」で作成したIP範囲を削除
011.png

3-3.IP範囲が削除されたことを確認
012.png

4.AlloyDBのインスタンスの再作成

4-1.プライマリクラスタの操作から「プライマリインスタンスの作成」を選択※この後作成に失敗するため設定値はデフォルトで問題なし
103.png

4-2.インスタンスの作成途中にエラー発生してインスタンスの作成に失敗【事象発生】
104.png

※以下は赤枠の「詳細」を押下した際に表示されるメッセージ
105.png

解消方法

5-1.作成したVPCネットワークの詳細の「プライベートサービスアクセス」の「サービスに割り当てられたIP範囲」より「IP範囲の割り振り」を選択し、「3-1」で解放したIP範囲を再度作成する
※「1-4」と同様の操作
※名前、内部IP範囲共に「1-4」と一致させる必要がある
201.png
005.png
202.png

※作成したVPCネットワークの詳細の「プライベートサービスアクセス」の「サービスのプライベート接続」の設定(「servicenetworking-googleapis-com」の設定)は不要。自動的に再作成したIPが追加されている。
※後述するが、実際は設定が消えていなかったが正しそう。
203.png

5-2.「4-1」と同様の操作で、インスタンスの再作成

5-3.「2-1」で作成したプライマリクラスタにプライマリインスタンスが再作成されたことを確認する
204.png

〜手順完了〜

原因想定、補足

AlloyDBのインスタンス作成時にクラスタで設定したネットワークとのプライベート接続(「servicenetworking-googleapis-com」)に割り当て済みのIP範囲のチェックが入っていると思われる。その際、AlloyDBで利用しているIP範囲だけでなく割り当て済みのIP範囲が全て存在していないと何故かだめらしい。

「プライベートサービスアクセス」の「サービスのプライベート接続」の「servicenetworking-googleapis-com」の設定を確認すると、「3-1」で解放したにも関わらず割り当てに「1-4」で作成したIP範囲が残っていることがわかる。
※本当は自動的に割り当てから削除されていて欲しいところ。
301.png

「servicenetworking-googleapis-com」部分を押下すると設定の更新画面が表示されるが、解放済みのIP範囲が表示されず、割り当てから外すことも不可。
303.png

なお、サービスに割り当てられたIP範囲」の一つを解放する前に割り当てから外しておけないかと試したが、
「servicenetworking-googleapis-com」部分を押下して表示された設定の更新画面では全て灰色になっており、設定変更が不可。そのため、一度設定した割り当ては変更ができないように思われる。
302.png

IP設計が変わって別のサービス用にIP範囲を使いまわしたい場合があるかもしれないが、そういった際に柔軟な対応ができないと思われる。(ピアリングの再作成等でできるかもしれないが、その際には既存のAlloyDB等のサービスプロデューサーのVPC内に作成したリソースも再作成になると思われるため、現実的ではないと考える。)

この辺りはサービスプロデューサーのVPC(Google管理のVPC)内にリソースを作成することからGoogleがコントロールする(ブラックボックスな)部分が多くなっている印象であり、少し不便であると感じる。
※AWSは自分で作成したVPC(サブネット)内にマネージドDBを作成するので、柔軟性、コントロールできる領域が広いという点ではAWSの方に優位性があるように思える。

ちなみに本事象は、自分の検証中に他のメンバが別の検証目的で追加のIP範囲の作成&「servicenetworking-googleapis-com」へのIP範囲の割り当てをして、検証が終わった後に追加のIP範囲を解放したことから発生しました。
「servicenetworking-googleapis-com」(サービスプロデューサーのVPCとのピアリング)は1つしか作成できないので、複数人で作業する場合は互いにコミュニケーションを取り合って作業するか、プロジェクトやVPCを分けて互いに影響を与えないように作業するのが無難だなと思いました。

終わりに

Googleのネットワークは少し特殊なところがある(Googleのコントロール下にあるものが多い)ので、どのような仕組みとなっているのかを細かいところまで把握しないとつまづくことがあるかと思います。
特に作るだけなら簡単なのですが、付随されて作成されるリソースがある場合はリソースを作り直す際に問題となったりいつ何のために作成したのか後でわからなくなる場合があるので、リソースの関係性も意識して作成する必要があるかなと思いました。

なお、本ブログの内容については全てマネジメントコンソールからの操作であり、CLIやAPIを利用した際は別の対処方法があるかもしれません。ご容赦ください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0