Bigtable 인스턴스는 데이터의 컨테이너입니다. 인스턴스에는 클러스터가 한 개 이상 있으며 이러한 클러스터는 서로 다른 영역에 있습니다. 클러스터마다 노드가 최소 1개 이상 있습니다.
테이블은 클러스터나 노드가 아닌 인스턴스에 속합니다. 인스턴스에 클러스터가 두 개 이상 있으면 복제를 사용하고 있는 것입니다. 즉, 개별 클러스터에 테이블을 할당하거나 인스턴스의 클러스터마다 고유한 가비지 컬렉션 정책을 만들 수 없습니다. 또한 각 클러스터가 같은 테이블에 서로 다른 데이터 집합을 저장하도록 할 수 없습니다.
인스턴스에는 알아야 할 몇 가지 중요한 속성이 있습니다.
스토리지 유형(SSD 또는 HDD)
복제를 사용하는 인스턴스에 주로 사용되는 애플리케이션 프로필
다음 섹션에서는 이러한 속성을 설명합니다.
스토리지 유형
인스턴스를 만들 때 인스턴스 클러스터에서 데이터를 솔리드 스테이트 드라이브(SSD) 또는 하드 디스크 드라이브(HDD) 중 어디에 저장할지를 선택해야 합니다. SSD 저장소가 가장 효율적이고 경제적인 선택인 경우가 많습니다.
SSD 또는 HDD 선택은 되돌릴 수 없으며 인스턴스의 모든 클러스터가 동일한 유형의 스토리지를 사용해야 하므로 사용 사례에 맞는 저장 유형을 선택해야 합니다. 스토리지 결정에 유용한 자세한 내용은 SSD와 HDD 스토리지 중 선택을 참조하세요.
애플리케이션 프로필
인스턴스를 만들면 Bigtable에서 해당 인스턴스를 사용하여 애플리케이션 프로필 또는 앱 프로필을 저장합니다. 복제를 사용하는 인스턴스의 경우 앱 프로필에서 애플리케이션이 인스턴스 클러스터에 연결하는 방법을 제어합니다.
앱 프로필에 대한 자세한 내용은 애플리케이션 프로필을 참조하세요. 인스턴스의 앱 프로필을 설정하는 방법은 앱 프로필 구성을 참조하세요.
클러스터
클러스터는 특정 위치의 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이 클러스터의 워크로드를 처리하는 데 필요한 대로 노드를 추가하고 삭제할 수 있습니다.
클러스터를 만들 때 클러스터를 항상 2노드 단위로 확장하도록 설정하는 구성인 2배 노드 확장을 사용 설정할 수 있습니다. 자세한 내용은 노드 확장 계수를 참고하세요.
노드
인스턴스의 각 클러스터에는 노드가 1개 이상 있으며, 이러한 노드는 Bigtable이 데이터를 관리하는 데 사용하는 컴퓨팅 리소스입니다.
백그라운드에서 Bigtable은 테이블의 모든 데이터를 별도의 태블릿으로 분할합니다. 태블릿은 노드와 분리되어 있지만 노드와 동일한 영역에 있는 디스크에 저장됩니다. 태블릿은 단일 노드와 연결됩니다.
클러스터에는 현재 워크로드와 클러스터에 저장되는 데이터 양을 지원하기에 충분한 노드가 있어야 합니다. 그렇지 않으면 클러스터가 수신한 요청을 처리하지 못해 지연 시간이 길어질 수 있습니다. 클러스터의 CPU와 디스크 사용량을 모니터링하고 측정항목이 용량 계획의 추천을 초과하면 인스턴스에 노드를 추가합니다.
Bigtable에서 데이터를 저장하고 관리하는 방법에 대한 자세한 내용은 Bigtable 아키텍처를 참조하세요.
처리량이 높은 읽기 작업의 경우 클러스터의 노드 대신 Bigtable용 Data Boost를 사용하여 컴퓨팅할 수 있습니다.
Data Boost를 사용하면 핵심 애플리케이션이 클러스터 노드를 컴퓨팅에 계속 사용하는 동안 서버리스 컴퓨팅을 사용하여 대규모 읽기 작업과 쿼리를 전송할 수 있습니다.
자세한 내용은 Data Boost 개요를 참고하세요.
복제된 클러스터의 노드
인스턴스에 클러스터가 두 개 이상 있는 경우 자동 확장의 최대 노드 수를 구성하거나 노드를 수동으로 할당할 때는 페일오버를 고려해야 합니다.
한 클러스터에서 다른 클러스터로 수동으로 장애 조치하거나 자동 장애 조치가 발생하는 경우 수신 클러스터에 부하를 지원할 수 있는 충분한 용량이 있는 것이 좋습니다. 많은 비용이 들 수 있지만 장애 조치를 지원하기에 충분한 노드를 항상 할당할 수도 있고, 트래픽 장애 조치 시 자동 확장을 사용하여 노드를 추가할 수도 있지만 클러스터를 수직 확장할 때 성능에 잠시 영향을 미칠 수 있습니다.
모든 앱 프로필에서 단일 클러스터 라우팅을 사용하는 경우 각 클러스터에 다른 수의 노드가 있을 수 있습니다. 클러스터의 워크로드를 기준으로 필요에 따라 각 클러스터의 크기를 조정합니다.
Bigtable은 클러스터마다 별도의 데이터 사본을 저장하기 때문에 디스크 사용량을 지원하고 클러스터 간에 쓰기를 복제하기에 충분한 노드가 각 클러스터에 있어야 합니다.
필요한 경우 한 클러스터에서 다른 클러스터로 수동으로 장애 조치할 수 있습니다. 그러나 한 클러스터에 다른 노드보다 더 많은 노드가 있고, 더 적은 수의 노드가 있는 클러스터로 장애 조치해야 하는 경우 먼저 노드를 추가해야 할 수 있습니다. 장애 조치가 필요할 때 추가 노드를 사용할 수 있다는 보장은 없습니다. 미리 노드를 예약하는 유일한 방법은 클러스터에 노드를 추가하는 것입니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eBigtable utilizes instances as containers for data, with each instance comprised of one or more clusters located in different zones, and each cluster containing nodes for data management and maintenance.\u003c/p\u003e\n"],["\u003cp\u003eWhen creating an instance, the storage type, either SSD or HDD, must be selected, and this choice is permanent for all clusters within the instance, with every cluster using the same storage type.\u003c/p\u003e\n"],["\u003cp\u003eClusters, which represent the Bigtable service in a specific location, belong to a single instance and handle requests to that instance, and an instance can have up to 8 regions.\u003c/p\u003e\n"],["\u003cp\u003eEach node within a cluster is a compute resource responsible for managing data tablets, handling reads and writes, and performing maintenance tasks like compactions, ensuring sufficient nodes are present to support the workload.\u003c/p\u003e\n"],["\u003cp\u003eInstances with multiple clusters utilize replication, keeping separate copies of data in each cluster's zone and synchronizing updates between them, allowing for traffic isolation, load balancing, and failover capabilities.\u003c/p\u003e\n"]]],[],null,["Instances, clusters, and nodes\n\nTo use Bigtable, you create *instances* , which contain *clusters* that\nyour applications can connect to. Each cluster contains *nodes*, the compute\nunits that manage your data and perform maintenance tasks.\n\nThis page provides more information about Bigtable instances,\nclusters, and nodes.\n\n- To learn how to create an instance, see [Create an instance](/bigtable/docs/creating-instance).\n- To learn how to add or delete clusters, see [Modify an instance](/bigtable/docs/modifying-instance#clusters).\n- To learn how to monitor an instance and its clusters, see [Monitoring an\n instance](/bigtable/docs/monitoring-instance).\n- To learn how to update the number of nodes in a cluster, see [Add or\n remove nodes](/bigtable/docs/modifying-instance#nodes).\n\n\nBefore you read this page, you should be familiar with the\n[overview of Bigtable](/bigtable/docs/overview).\n\nInstances\n\nA Bigtable instance is a container for your data. Instances have\none or more [clusters](#clusters), located in different zones. Each\ncluster has at least 1 [node](#nodes).\n\nA table belongs to an instance, not to a cluster or node. If you have an instance\nwith more than one cluster, you are using replication. This means you can't\nassign a table to an individual cluster or create unique garbage collection\npolicies for each cluster in an instance. You also can't make each cluster store\na different set of data in the same table.\n\nAn instance has a few important properties that you need to know about:\n\n- The *storage type* (SSD or HDD)\n- The *application profiles*, which are primarily for instances that use replication\n\nThe following sections describe these properties.\n\nStorage types\n\nWhen you [create an instance](/bigtable/docs/creating-instance), you must choose whether\nthe instance's clusters will store data on solid-state drives (SSD) or hard disk\ndrives (HDD). SSD is often, but not always, the most efficient and\ncost-effective choice.\n\nThe choice between SSD and HDD is permanent, and every cluster in your instance\nmust use the same type of storage, so make sure you pick the right storage type\nfor your use case. See [Choosing between SSD and HDD storage](/bigtable/docs/choosing-ssd-hdd)\nfor more information to help you decide.\n\nApplication profiles\n\nAfter you [create an instance](/bigtable/docs/creating-instance), Bigtable uses\nthe instance to store [application profiles](/bigtable/docs/app-profiles), or app profiles. For\ninstances that use replication, app profiles control how your applications\nconnect to the instance's clusters.\n\nIf your instance doesn't use replication, you can still use app profiles to\nprovide separate identifiers for each of your applications, or each function\nwithin an application. You can then [view separate charts for each app profile\nin the Google Cloud console](/bigtable/docs/monitoring-instance#console-monitoring-resources).\n\nTo learn more about app profiles, see [application profiles](/bigtable/docs/app-profiles). To\nlearn how to set up your instance's app profiles, see [Configuring app\nprofiles](/bigtable/docs/configuring-app-profiles).\n\nClusters\n\nA cluster represents the Bigtable service in a specific location.\nEach cluster belongs to a single Bigtable instance, and an\ninstance can have clusters in up to 8 regions.\nWhen your application sends requests to a Bigtable instance, those\nrequests are handled by one of the clusters in the instance.\n\nEach cluster is located in a single zone.\nAn instance can have clusters in up to 8 regions where\nBigtable is available.\n\n\nEach [zone in a region](/docs/geography-and-regions#regions_and_zones) can contain only\none cluster.\n\nFor example, if an instance has a cluster in `us-east1-b`, you can add a cluster\nin a different zone in the same region, such as `us-east1-c`, or a zone in a separate\nregion, such as `europe-west2-a`.\n\nThe number of clusters that you can create in an instance depends on the number\nof available zones in the regions that you choose. For example, if you create\nclusters in 8 regions that have 3 zones each, the maximum number of clusters\nthat the instance can have is 24. For a list of zones and regions where\nBigtable is available, see\n[Bigtable locations](/bigtable/docs/locations).\n\nBigtable instances that have only 1 cluster don't use\nreplication. If you add a second cluster to an instance,\nBigtable automatically starts replicating your data\nby keeping separate copies of the data in each of the clusters' zones and\nsynchronizing updates between the copies. You can choose which cluster your\napplications connect to, which makes it possible to isolate different types of\ntraffic from one another. You can also let Bigtable balance traffic\nbetween clusters. If a cluster becomes unavailable, you can fail over from one\ncluster to another. To learn more about how replication works, see the\n[replication overview](/bigtable/docs/replication-overview).\n\nIn most cases, you should [enable autoscaling](/bigtable/docs/autoscaling) for a\ncluster, so that Bigtable adds and removes nodes as needed to\nhandle the cluster's workloads.\n\nWhen you create a cluster, you can enable 2x node scaling, a configuration that\nsets the cluster to always scale in increments of two nodes. For more\ninformation, see [Node scaling\nfactor](/bigtable/docs/scaling#node-scaling-factor).\n\nNodes\n\nEach cluster in an instance has 1 or more\nnodes, which are compute resources that Bigtable uses to manage\nyour data.\n\nBehind the scenes, Bigtable splits all of the data in a\ntable into separate [*tablets*](/bigtable/docs/overview#architecture). Tablets are stored on disk,\nseparate from the nodes but in the same zone as the nodes. A tablet is\nassociated with a single node.\n\nEach node is responsible for:\n\n- Keeping track of specific tablets on disk.\n- Handling incoming reads and writes for its tablets.\n- Performing maintenance tasks on its tablets, such as periodic [compactions](/bigtable/docs/overview#compactions).\n\nA cluster must have enough nodes to support its current workload and the amount\nof data it stores. Otherwise, the cluster might not be able to handle incoming\nrequests, and latency could go up. [Monitor your clusters' CPU and\ndisk usage](/bigtable/docs/monitoring-instance#cpu-and-disk), and [add nodes](/bigtable/docs/modifying-instance#nodes) to an instance\nwhen its metrics exceed the recommendations at\n[Plan your capacity](/bigtable/docs/performance#planning-your-capacity).\n\nFor more details about how Bigtable stores and manages data, see\n[Bigtable architecture](/bigtable/docs/overview#architecture).\n\nFor high-throughput read jobs, you can use Data Boost for\nBigtable for compute instead of your cluster's nodes.\nData Boost lets you send large read jobs and queries using serverless\ncompute while your core application continues using cluster nodes for compute.\nFor more information, see [Data Boost\noverview](/bigtable/docs/data-boost-overview).\n\nNodes for replicated clusters\n\nWhen your instance has more than one cluster, failover becomes a consideration\nwhen you configure the maximum number of nodes for autoscaling or manually\nallocate the nodes.\n\n- If you use [multi-cluster routing](/bigtable/docs/app-profiles#routing) in any of your app profiles,\n [automatic failover](/bigtable/docs/failovers#automatic) can occur in the event that one or\n more clusters is unavailable.\n\n- When you manually fail over from one cluster to another, or when automatic\n failover occurs, the receiving cluster should ideally have enough capacity to\n support the load. You can either always allocate enough nodes to support\n failover, which can be costly, or you can rely on autoscaling to add nodes\n when traffic fails over, but be aware that there might be a brief impact on\n performance while the cluster scales up.\n\n- If all of your app profiles use [single-cluster routing](/bigtable/docs/app-profiles#routing), each\n cluster can have a different number of nodes. Resize each cluster as needed\n based on the cluster's workload.\n\n Because Bigtable stores a separate copy of your data with\n each cluster, each cluster must always have enough nodes to support your\n disk usage and to replicate writes between clusters.\n\n You can still [fail over manually](/bigtable/docs/failovers#manual) from one cluster to\n another if necessary. However, if one cluster has many more nodes than\n another, and you need to fail over to the cluster with fewer nodes, you\n might need to [add nodes](/bigtable/docs/modifying-instance#nodes) first. There is no\n guarantee that additional nodes will be available when you need to fail\n over---the only way to reserve nodes in advance is to add them to your\n cluster.\n\nWhat's next\n\n- [Create a Bigtable instance.](/bigtable/docs/creating-instance)\n- [Monitor a Bigtable instance.](/bigtable/docs/monitoring-instance)\n- [Find out how replication works.](/bigtable/docs/replication-overview)"]]
