인스턴스, 클러스터, 노드

Bigtable을 사용하려면 애플리케이션에서 연결할 수 있는 클러스터가 포함된 인스턴스를 만듭니다. 각 클러스터에는 데이터를 관리하고 유지보수 작업을 수행하는 컴퓨팅 단위인 노드가 있습니다.

이 페이지에서는 Bigtable 인스턴스, 클러스터, 노드에 대해 자세히 설명합니다.

이 페이지를 읽기 전에 Bigtable 개요를 숙지해야 합니다.

인스턴스

Bigtable 인스턴스는 데이터의 컨테이너입니다. 인스턴스에는 클러스터가 한 개 이상 있으며 이러한 클러스터는 서로 다른 영역에 있습니다. 클러스터마다 노드가 최소 1개 이상 있습니다.

테이블은 클러스터나 노드가 아닌 인스턴스에 속합니다. 인스턴스에 클러스터가 두 개 이상 있으면 복제를 사용하고 있는 것입니다. 즉, 개별 클러스터에 테이블을 할당하거나 인스턴스의 클러스터마다 고유한 가비지 컬렉션 정책을 만들 수 없습니다. 또한 각 클러스터가 같은 테이블에 서로 다른 데이터 집합을 저장하도록 할 수 없습니다.

인스턴스에는 알아야 할 몇 가지 중요한 속성이 있습니다.

  • 스토리지 유형(SSD 또는 HDD)
  • 복제를 사용하는 인스턴스에 주로 사용되는 애플리케이션 프로필

다음 섹션에서는 이러한 속성을 설명합니다.

스토리지 유형

인스턴스를 만들 때 인스턴스 클러스터에서 데이터를 솔리드 스테이트 드라이브(SSD) 또는 하드 디스크 드라이브(HDD) 중 어디에 저장할지를 선택해야 합니다. SSD 저장소가 가장 효율적이고 경제적인 선택인 경우가 많습니다.

SSD 또는 HDD 선택은 되돌릴 수 없으며 인스턴스의 모든 클러스터가 동일한 유형의 스토리지를 사용해야 하므로 사용 사례에 맞는 저장 유형을 선택해야 합니다. 스토리지 결정에 유용한 자세한 내용은 SSD와 HDD 스토리지 중 선택을 참조하세요.

애플리케이션 프로필

인스턴스를 만들면 Bigtable에서 해당 인스턴스를 사용하여 애플리케이션 프로필 또는 앱 프로필을 저장합니다. 복제를 사용하는 인스턴스의 경우 앱 프로필에서 애플리케이션이 인스턴스 클러스터에 연결하는 방법을 제어합니다.

인스턴스에서 복제를 사용하지 않는 경우에도 앱 프로필을 사용하여 애플리케이션마다 또는 애플리케이션 내 각 함수에 별도의 식별자를 제공할 수 있습니다. 그러면 Google Cloud Console에서 앱 프로필마다 별도의 차트를 볼 수 있습니다.

앱 프로필에 대한 자세한 내용은 애플리케이션 프로필을 참조하세요. 인스턴스의 앱 프로필을 설정하는 방법은 앱 프로필 구성을 참조하세요.

클러스터

클러스터는 특정 위치의 Bigtable 서비스를 나타냅니다. 각 클러스터는 Bigtable 인스턴스에 속하며 인스턴스는 최대 8개의 리전에 클러스터를 포함할 수 있습니다. 애플리케이션이 Bigtable 인스턴스에 요청을 보내면 이 요청은 인스턴스의 클러스터 중 하나에서 처리됩니다.

각 클러스터는 단일 영역에 있습니다. 인스턴스는 Bigtable을 사용할 수 있는 리전 최대 8개에 클러스터를 포함할 수 있습니다. 리전의 각 영역에는 클러스터가 하나만 포함될 수 있습니다. 예를 들어 인스턴스에 us-east1-b에 클러스터가 있는 경우 동일한 리전의 다른 영역(예: us-east1-c) 또는 별도의 리전의 영역(예: europe-west2-a)에 클러스터를 추가할 수 있습니다.

인스턴스 하나에 만들 수 있는 클러스터 수는 선택한 리전에서 이용 가능한 영역 수에 따라 다릅니다. 예를 들어 영역이 각각 3개 있는 리전 8개에 클러스터를 만들면 인스턴스에 보유할 수 있는 최대 클러스터 수는 24개입니다. Bigtable을 사용할 수 있는 영역과 리전의 목록은 Bigtable 위치를 참조하세요.

클러스터가 1개뿐인 Bigtable 인스턴스에서는 복제를 사용하지 않습니다. 인스턴스에 2번째 클러스터를 추가하면 Bigtable은 각 클러스터 영역에 별도의 데이터 복사본을 유지하고 복사본 간에 업데이트를 동기화하여 자동으로 데이터 복제를 시작합니다. 애플리케이션에서 연결할 클러스터를 선택하여 서로 다른 유형의 트래픽을 격리할 수 있습니다. Bigtable이 클러스터 간에 트래픽을 분산하도록 할 수도 있습니다. 클러스터를 사용할 수 없게 되면 한 클러스터에서 다른 클러스터로 장애 조치할 수 있습니다. 복제 작동 방식에 대한 자세한 내용은 복제 개요를 참조하세요.

대부분의 경우 클러스터에 자동 확장을 사용 설정해야 Bigtable이 클러스터의 워크로드를 처리하는 데 필요한 대로 노드를 추가하고 삭제할 수 있습니다.

노드

인스턴스의 각 클러스터에는 노드가 1개 이상 있으며, 이러한 노드는 Bigtable이 데이터를 관리하는 데 사용하는 컴퓨팅 리소스입니다.

백그라운드에서 Bigtable은 테이블의 모든 데이터를 별도의 태블릿으로 분할합니다. 태블릿은 노드와 분리되어 있지만 노드와 동일한 영역에 있는 디스크에 저장됩니다. 태블릿은 단일 노드와 연결됩니다.

각 노드는 다음을 수행합니다.

  • 디스크의 특정 태블릿 추적
  • 태블릿에 수신된 읽기 및 쓰기 처리
  • 태블릿에서 유지보수 태스크 수행(예: 정기적인 압축)

클러스터에는 현재 워크로드와 클러스터에 저장되는 데이터 양을 지원하기에 충분한 노드가 있어야 합니다. 그렇지 않으면 클러스터가 수신한 요청을 처리하지 못해 지연 시간이 길어질 수 있습니다. 클러스터의 CPU와 디스크 사용량을 모니터링하고 측정항목이 용량 계획의 추천을 초과하면 인스턴스에 노드를 추가합니다.

Bigtable에서 데이터를 저장하고 관리하는 방법에 대한 자세한 내용은 Bigtable 아키텍처를 참조하세요.

복제된 클러스터의 노드

인스턴스에 클러스터가 두 개 이상 있는 경우 자동 확장의 최대 노드 수를 구성하거나 노드를 수동으로 할당할 때에는 페일오버를 고려해야 합니다.

  • 앱 프로필에서 멀티 클러스터 라우팅을 사용하면 클러스터를 사용할 수 없는 경우 자동 장애 조치가 발생할 수 있습니다.

  • 한 클러스터에서 다른 클러스터로 수동으로 장애 조치하거나 자동 장애 조치가 발생하는 경우 수신 클러스터에 부하를 지원할 수 있는 충분한 용량이 있는 것이 좋습니다. 많은 비용이 들 수 있지만 장애 조치를 지원하기에 충분한 노드를 항상 할당할 수도 있고, 트래픽 장애 조치 시 자동 확장을 사용하여 노드를 추가할 수도 있지만 클러스터를 수직 확장할 때 성능에 잠시 영향을 미칠 수 있습니다.

  • 모든 앱 프로필에서 단일 클러스터 라우팅을 사용하는 경우 각 클러스터에 다른 수의 노드가 있을 수 있습니다. 클러스터의 워크로드를 기준으로 필요에 따라 각 클러스터의 크기를 조정합니다.

    Bigtable은 클러스터마다 별도의 데이터 사본을 저장하기 때문에 디스크 사용량을 지원하고 클러스터 간에 쓰기를 복제하기에 충분한 노드가 각 클러스터에 있어야 합니다.

    필요한 경우 한 클러스터에서 다른 클러스터로 수동으로 장애 조치할 수 있습니다. 그러나 한 클러스터에 다른 노드보다 더 많은 노드가 있고, 더 적은 수의 노드가 있는 클러스터로 장애 조치해야 하는 경우 먼저 노드를 추가해야 할 수 있습니다. 장애 조치가 필요할 때 추가 노드를 사용할 수 있다는 보장은 없습니다. 미리 노드를 예약하는 유일한 방법은 클러스터에 노드를 추가하는 것입니다.

다음 단계