Compute可用性設計: GCPのRegional MIG・GKE regional cluster・複数region backendで考える

Computeレイヤーの可用性は、VMやPodをどこに複数配置するかで決まります。

本記事では、Compute可用性という一般的な設計テーマを、GCPのRegional MIG、GKE regional cluster、複数region backendを例に整理します。

整理の軸は以下です。

• VM / Pod単体障害: インスタンスを複数持つ
• zone障害: 1region内の複数zoneに分散する
• region障害: 複数regionにbackendを置く

本記事では、Regional MIG、GKE regional cluster、複数region backendの違いを整理します。

VM単体障害: MIGで複数台を維持する

Managed Instance Group（MIG）は、同じ設定のVM群を作って維持する管理単位です。VMが落ちたら作り直し、指定台数を維持します。

flowchart TB
  mig["Managed Instance Group"]
  vm1["VM #1"]
  vm2["VM #2"]
  vm3["VM #3"]

  mig --> vm1
  mig --> vm2
  mig --> vm3

Load Balancer、Backend Service、MIG、VMの関係は『GCPのLoad Balancer・Backend Service・MIG・VMの関係を整理する』で扱っています。

zone障害: Regional MIG

Regional MIGは、1つのregion内の複数zoneにVMを分散します。

flowchart TB
  lb["Regional Load Balancer"]

  subgraph r1["Region A"]
    subgraph z1["Zone A"]
      vm1["VM #1"]
    end

    subgraph z2["Zone B"]
      vm2["VM #2"]
    end

    subgraph z3["Zone C"]
      vm3["VM #3"]
    end
  end

  lb --> vm1
  lb --> vm2
  lb --> vm3

この構成はzone障害に強いです。Zone Aが落ちても、Zone B/CのVMで応答できます。

ただし、Region A全体が使えなくなった場合は、この構成だけでは止まります。

• Regional MIGは1region内の複数zoneに分散する
• zone障害対策にはなる
• region障害対策ではない

zone障害: GKE regional cluster

GKE regional clusterは、1つのGKEクラスタを1region内の複数zoneにまたがって作る構成です。

flowchart TB
  ingress["Ingress / Service"]

  subgraph r1["Region A"]
    cp["GKE Control Plane<br/>regional"]

    subgraph z1["Zone A"]
      node1["Node / Pod"]
    end

    subgraph z2["Zone B"]
      node2["Node / Pod"]
    end

    subgraph z3["Zone C"]
      node3["Node / Pod"]
    end
  end

  ingress --> node1
  ingress --> node2
  ingress --> node3
  cp -. "manages" .-> node1
  cp -. "manages" .-> node2
  cp -. "manages" .-> node3

Regional MIGと同じく、これは1region内のzone冗長です。

region障害: 複数region backend

region障害に備えるには、backend自体を複数regionに置きます。

flowchart TB
  user["Users"]
  glb["Global External Load Balancer"]

  subgraph r1["Region A"]
    app1["Regional MIG / GKE cluster"]
  end

  subgraph r2["Region B"]
    app2["Regional MIG / GKE cluster"]
  end

  user --> glb
  glb --> app1
  glb --> app2

この構成では、Region Aに問題が起きたときにRegion Bへ逃がす余地があります。

ただし、アプリだけ複数regionにしても、DBやStorage、オンプレ接続、DNS/LB、運用手順が単一region依存なら、システム全体の可用性は上がりきりません。

GKE regional clusterと複数region GKEは違う

混同しやすい点です。

構成	クラスタ数	範囲	主な目的
GKE regional cluster	1つ	1region内の複数zone	zone障害対策
複数region GKE	複数	複数region	region障害対策

GKE regional clusterは1つのクラスタを複数zoneに分散する構成で、複数region GKEはregionごとにクラスタを作る構成です。

複数region GKEのようにGKE Clusterを複数使う構成は、マルチクラスタGKEの一例です。FleetやMCSまで含めた関係は『GKE Fleet・マルチクラスタGKE・MCSの関係まとめ』で整理しています。

まとめ

• VM単体障害には複数VM/MIGで備える
• zone障害にはRegional MIGやGKE regional clusterで備える
• region障害には複数region backendが必要
• regional は複数regionではなく、基本的に1region内の複数zoneを意味する
• アプリを複数regionにしても、DBや入口まで含めて設計しないとシステム全体の可用性にはならない

参考

• Managed instance groups
• Regional managed instance groups
• Creating a regional cluster