Cloud Run 함수에 자동 확장 처리 도구 배포

자동 확장 처리 도구는 유연하도록 설계되었으며 운영팀과 애플리케이션팀 간 기존의 책임 분리를 수용할 수 있습니다. Spanner 인스턴스의 자동 확장을 구성하는 책임은 단일 운영팀으로 중앙 집중화하거나 해당 Spanner 인스턴스에서 제공하는 애플리케이션에 더 가까운 팀으로 분산할 수 있습니다.

이 문서는 다음을 포함하는 시리즈의 일부입니다.

• Spanner 자동 확장
• 자동 확장 처리 도구 개요
• Spanner용 자동 확장 도구를 Google Kubernetes Engine (GKE)에 배포합니다.

이 시리즈는 운영 오버헤드를 줄이고 Spanner 배포 비용을 최적화하려는 IT, 운영, 사이트 안정성 엔지니어링(SRE) 팀을 대상으로 합니다.

이 페이지에서는 요구사항에 따라 Cloud Run 함수에 자동 확장기를 배포하는 세 가지 방법을 소개합니다.

• 프로젝트별 배포 토폴로지입니다. 자동 확장 처리 인프라는 자동 확장되어야 하는 Spanner와 동일한 프로젝트에 배포됩니다. 자체적으로 자동 확장 처리 구성과 인프라를 관리하려는 개별 팀이 이 토폴로지를 사용하는 것이 좋습니다. 프로젝트별 배포 토폴로지는 자동 확장 처리의 기능을 테스트하기에 좋은 출발점이기도 합니다.
• 중앙 집중식 배포 토폴로지입니다. 자동 확장 처리 도구가 한 프로젝트에 배포되며 여러 프로젝트에서 Spanner 인스턴스 하나 이상을 관리합니다. 자동 확장 처리의 구성요소와 구성을 중앙 위치에서 유지하는 동시에 하나 이상의 Spanner 인스턴스의 구성 및 인프라를 관리하는 팀이 이 토폴로지를 사용하는 것이 좋습니다. 중앙 집중식 토폴로지에서 자동 확장 처리 프로젝트 외에 추가적으로 두 번째 프로젝트를 설정합니다. 이 튜토리얼에서는 이를 애플리케이션 프로젝트라고 합니다. 애플리케이션 프로젝트는 Spanner를 포함한 애플리케이션 리소스를 보관합니다.
• 분산형 배포 토폴로지입니다. 대부분의 자동 확장 처리 인프라가 한 프로젝트에 배포되지만 일부 인프라 구성요소는 다른 프로젝트에서 자동 확장되는 Spanner 인스턴스와 함께 배포됩니다. Spanner 인스턴스를 소유한 팀이 인스턴스의 자동 확장 처리 구성 매개변수만 관리하고 나머지 자동 확장 처리 인프라는 중앙 팀에서 관리하는 등 여러 팀이 있는 조직에 이 토폴로지를 사용하는 것이 좋습니다.

쉬운 배포 및 관리를 위한 서버리스

이 모델에서 자동 확장 처리 도구는 Cloud Run 함수, Pub/Sub, Cloud Scheduler, Firestore와 같은 서버리스 및 관리가 적은 Google Cloud 도구만을 사용하여 빌드됩니다. 이 접근 방식은 자동 확장 처리 도구 실행 비용과 운영 오버헤드를 최소화합니다.

자동 확장 처리 도구는 기본 제공되는 Google Cloud 도구를 사용하여 인증과 승인에 Identity and Access Management (IAM)를 최대한 활용할 수 있습니다.

구성

자동 확장 처리 도구는 Cloud Scheduler에 정의된 구성을 통해 Spanner 인스턴스를 관리합니다. Spanner 인스턴스 여러 개를 동일한 간격으로 폴링해야 하는 경우 같은 Cloud Scheduler 작업에서 이러한 인스턴스를 구성하는 것이 좋습니다. 각 인스턴스 구성은 JSON 객체로 표시됩니다. 다음 예시는 Cloud Scheduler 작업 하나로 Spanner 인스턴스 2개를 관리하는 구성입니다.

[
  {
    "projectId": "my-spanner-project",
    "instanceId": "my-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "NODES",
    "minSize": 1,
    "maxSize": 3
  },
  {
    "projectId": "different-project",
    "instanceId": "another-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "PROCESSING_UNITS",
    "minSize": 500,
    "maxSize": 3000,
    "scalingMethod": "DIRECT"
  }
]

Spanner 인스턴스는 다양한 Cloud Scheduler 작업에 대해 여러 구성을 가질 수 있습니다. 예를 들어 인스턴스에 일반 작업을 위한 선형 방법이 포함된 하나의 자동 확장 처리 구성이 있을 수 있지만 계획된 일괄 워크로드에 대한 직접식 방법이 있는 또 다른 자동 확장 처리 구성이 있을 수도 있습니다.

Cloud Scheduler 작업이 실행되면 Pub/Sub 메시지가 Polling Pub/Sub 주제로 전송됩니다. 이 메시지의 페이로드는 동일한 작업에서 구성된 모든 인스턴스에 대한 구성 객체의 JSON 배열입니다. Poller README 파일에서 전체 구성 옵션 목록을 참조하세요.

프로젝트별 토폴로지

프로젝트별 토폴로지 배포에서 자동 확장되어야 하는 Spanner 인스턴스가 있는 각 프로젝트에는 자동 확장 처리 구성요소의 자체적인 독립 배포도 있습니다. 자체적으로 자동 확장 처리 구성과 인프라를 관리하려는 개별 팀이 이 토폴로지를 사용하는 것이 좋습니다. 또한 자동 확장 처리 도구 기능을 테스트할 수 있는 좋은 출발점입니다.

다음 다이어그램은 프로젝트별 배포의 대략적인 개념을 보여줍니다.

앞선 다이어그램에 표시된 프로젝트별 배포에는 다음과 같은 특성이 있습니다.

• 애플리케이션 1과 애플리케이션 2의 두 애플리케이션은 각각 자체 Spanner 인스턴스를 사용합니다.
• Spanner 인스턴스(A)는 애플리케이션 1과 애플리케이션 2 프로젝트 각각에 있습니다.
• 독립된 자동 확장 처리(B)는 프로젝트 내 인스턴스 자동 확장이 제어되도록 각 프로젝트에 배포됩니다.

프로젝트별 배포에는 다음과 같은 장단점이 있습니다.

장점:

• 가장 간단한 설계: 프로젝트별 토폴로지는 모든 자동 확장 처리 구성요소가 자동 확장되는 Spanner 인스턴스와 함께 배포되므로 3가지 토폴로지 중에서 가장 간단한 설계입니다.
• 구성: Spanner 인스턴스를 소유한 팀에서 스케줄러 매개변수를 제어하므로 팀이 중앙 집중식 또는 분산 토폴로지 보다 필요에 따라 자동 확장 처리를 더 자유롭게 조정할 수 있습니다.
• 인프라 책임의 경계 명확: Cloud Spanner 인스턴스의 팀 소유자는 자동 확장 처리 인프라의 소유자이기도 하므로 프로젝트별 토폴로지 설계는 자동 확장 처리 인프라에 대한 책임과 보안의 명확한 경계를 설정합니다.

단점:

• 더 많은 전체 유지보수: 각 팀이 자동 확장 처리 구성과 인프라를 담당하므로 회사 전체의 모든 자동 확장 처리 도구가 같은 업데이트 가이드라인을 따르게 하기가 어려워질 수 있습니다.
• 보다 복잡한 감사: 각 팀에 높은 수준의 제어가 있기 때문에 중앙 집중식 감사가 더 복잡해질 수 있습니다.

프로젝트별 토폴로지를 사용하여 자동 확장 처리를 설정하는 방법을 알아보려면 프로젝트별 배포 단계별 가이드를 참고하세요.

중앙 집중식 토폴로지

프로젝트별 토폴로지와 마찬가지로 중앙 집중식 토폴로지에서는 모든 자동 확장 처리 도구 구성요소가 같은 프로젝트에 있습니다. 하지만 Spanner 인스턴스는 다른 프로젝트에 있습니다. 이 배포는 중앙에서 자동 확장 처리 도구 단일 배포를 통해 여러 Spanner 인스턴스의 구성과 인프라를 관리하는 팀에 적합합니다.

다음 다이어그램은 중앙 집중식 프로젝트 배포에 대한 대략적인 개념을 보여줍니다.

앞의 다이어그램에 표시된 중앙 집중식 배포의 특징은 다음과 같습니다.

• 애플리케이션 1과 애플리케이션 2의 두 애플리케이션은 각각 자체 Spanner 인스턴스를 사용합니다.
• Spanner 인스턴스(A)는 애플리케이션 1과 애플리케이션 2 프로젝트 각각에 있습니다.
• 자동 확장 처리(B)가 애플리케이션 1 및 애플리케이션 2 프로젝트 모두에서 Spanner 인스턴스 자동 확장을 제어하기 위해 별도의 프로젝트에 배포됩니다.

중앙 집중식 배포에는 다음과 같은 장단점이 있습니다.

장점:

• 중앙 집중식 구성 및 인프라: 단일 팀이 스케줄러 매개변수와 자동 확장 처리 인프라를 제어합니다. 이 방식은 규제가 심한 업계에서 유용할 수 있습니다.
• 전체 유지보수 감소: 일반적으로 유지보수 및 설정은 프로젝트별 배포에 비해 더 쉽게 유지됩니다.
• 중앙 집중식 정책 및 감사: 팀 간 권장사항을 지정하고 수행하기가 더 쉬울 수 있습니다. 감사는 실행하기 더 간편할 수 있습니다.

단점:

• 중앙 집중식 구성: 자동 확장 처리 매개변수에 대한 모든 변경사항은 변경을 요청하는 팀에서 Spanner 인스턴스를 소유하고 있더라도 중앙 집중식 팀을 거쳐야 합니다.
• 추가 위험 가능성: 자동 확장 처리 인프라가 고가용성을 염두에 두고 설계된 경우에도 중앙 집중식 팀 자체가 단일 장애점이 될 수 있습니다.

중앙 집중식 토폴로지를 사용하여 자동 확장 처리를 설정하는 방법을 알아보려면 중앙 집중식 배포 단계별 가이드를 참고하세요.

분산 토폴로지

분산 토폴로지 배포에서는 자동 확장되어야 하는 Cloud Scheduler 및 Spanner 인스턴스가 같은 프로젝트에 있습니다. 자동 확장 처리 도구의 나머지 구성요소는 중앙에서 관리되는 프로젝트에 있습니다. 이 배포는 하이브리드 배포입니다. Spanner 인스턴스를 소유한 팀은 인스턴스의 자동 확장 처리 구성 매개변수만 관리하며 중앙 팀은 나머지 자동 확장 처리 인프라를 관리합니다.

다음 다이어그램에서는 분산 프로젝트 배포에 대한 대략적인 개념을 보여줍니다.

앞의 다이어그램에 표시된 하이브리드 배포에는 다음과 같은 특성이 있습니다.

• 애플리케이션 1과 애플리케이션 2의 두 애플리케이션은 자체 Spanner 인스턴스를 사용합니다.
• Spanner 인스턴스(A)는 애플리케이션 1과 애플리케이션 2 프로젝트 모두에 있습니다.
• 독립된 Cloud Scheduler 구성요소(C)가 각 프로젝트, 즉 애플리케이션 1과 애플리케이션 2에 배포됩니다.
• 나머지 자동 확장 처리 구성요소(B)가 별도의 프로젝트에 배포됩니다.
• 자동 확장 처리 도구는 각 프로젝트의 독립된 Cloud Scheduler 구성요소에서 전송한 구성을 사용하여 애플리케이션 1 및 애플리케이션 2 프로젝트 모두에서 Spanner 인스턴스를 자동 확장합니다.

전달자 함수

Cloud Scheduler는 동일한 프로젝트의 주제에만 메시지를 게시할 수 있으므로 배포 토폴로지의 경우 전달자 함수라는 중간 구성요소가 필요합니다.

전달자 함수는 Cloud Scheduler에서 Pub/Sub로 메시지를 게시하고, 해당 JSON 구문을 확인하고, 이를 Poller Pub/Sub 주제로 전달합니다. 주제는 Cloud Scheduler에 대해 개별 프로젝트에 속할 수 있습니다.

다음 다이어그램은 전달 메커니즘에 사용되는 구성요소를 보여줍니다.

앞의 다이어그램에 표시되었듯이 Spanner 인스턴스는 애플리케이션 1이라는 프로젝트와 애플리케이션 2라는 프로젝트에 있습니다.

1. Cloud Scheduler는 Spanner 인스턴스와 동일한 프로젝트입니다.

2. (2a) Cloud Scheduler는 애플리케이션 1 및 애플리케이션 2 프로젝트의 전달자 주제로 메시지를 게시합니다.

   (2b) 전달자 함수는 전달자 주제에서 메시지를 읽습니다.

   (2c) 전달자 함수가 자동 확장 처리 프로젝트에 있는 폴링 주제로 메시지를 전달합니다.

3. Poller 함수는 Poller 섹션에 설명된 대로 폴링 주제에서 메시지를 읽고 프로세스가 계속됩니다.

분산형 배포에는 다음과 같은 장단점이 있습니다.

장점:

• 애플리케이션팀이 구성 및 일정 제어: Cloud Scheduler는 자동 확장되는 Spanner 인스턴스와 함께 배포되므로 애플리케이션팀이 구성 및 예약을 더 세밀하게 제어할 수 있습니다.
• 운영팀에서 인프라 제어: 자동 확장 처리 도구의 핵심 구성요소가 중앙에서 배포되어 운영팀에서 자동 확장 처리 인프라를 제어할 수 있습니다.
• 중앙 집중식 유지보수: Scaler 인프라가 중앙 집중화되어 오버헤드가 줄어듭니다.

단점:

• 더욱 복잡한 구성: 애플리케이션팀이 폴링 주제에 쓸 수 있는 서비스 계정을 제공해야 합니다.
• 추가 위험 가능성: 인프라가 고가용성을 염두에 두고 설계된 경우에도 공유 인프라가 단일 장애점이 될 수 있습니다.

분산 토폴로지를 사용하여 자동 확장 처리를 설정하는 방법을 알아보려면 분산 배포 단계별 가이드를 참고하세요.

다음 단계

• GKE에 자동 확장 처리 도구를 배포하는 방법을 알아보세요.
• Spanner 권장 기준에 대해 자세히 알아보기
• Spanner CPU 사용률 측정항목 및 지연 시간 측정항목에 대해 자세히 알아보기
• 핫스팟을 방지하고 Spanner에 데이터를 로드하기 위한 Spanner 스키마 설계 권장사항 알아보기
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기