Terraform을 사용하여 Twemproxy 서버에 클라우드 리소스 제공

Twemproxy docker 이미지를 만든 후 GCP에서 에이전트를 사용하여Memorystore Redis 그룹을 배치하고 실행하는 데 필요한 자원을 제공하는 데 주의를 기울일 수 있습니다.IAC(infrastructure as code, 인프라스트럭처 즉 코드)를 사용하여 클라우드 리소스를 관리하는 것은 환경 전반에 걸쳐 일관성을 유지하고 모든 인프라스트럭처의 가시성을 확보하는 좋은 방법입니다.
Terraform은 비교적 유행하는 IAC 솔루션 중의 하나로 GCP에서 Redis 집단에 필요한 인프라 시설을 기획할 것입니다.
모든 자원의 세부 사항은 몇 편의 블로그 글을 필요로 하기 때문에 우리는 한 편의 관건적인 세부 사항을 주목할 것이다.부하 균형기에 필요한 네트워크와 하위 네트워크, 프록시 서버에 요청할 클라이언트 서비스에 대한 자세한 정보는 예시 코드에 명확하게 포함되지 않습니다.이 자원들이 이미 배치되었다고 가정해 보세요.이 블로그는 캐시 층을 추가하는 데 필요한 추가 자원을 중점적으로 소개할 것이다.

기억 상점

우리가 정의할 첫 번째 자원은 Memorystore 실례입니다.

locals {
    reserved_ips = ["10.0.0.24/29", "10.0.0.32/29", "10.0.0.40/29"]
}

resource "google_redis_instance" "redis_memorystore" {
    count = length(local.reserved_ips)

    provider           = google-beta
    region             = "us-east1"

    name               = "memorystore${count.index + 1}"
    tier               = "BASIC"
    memory_size_gb     = 1
    redis_version      = "REDIS_5_0"
    authorized_network = var.network.id
    reserved_ip_range  = local.reserved_ips[count.index]
    display_name       = "Memorystore Redis Cache ${count.index + 1}"
}

이 예에서, 우리는 모든 Memorystore 실례가 대응하는 CIDR 범위 목록을 가지고 있다.IP 주소는 원하는 주소일 수 있지만 IP 네트워크 접두어는 29이어야 합니다.reservered_ip_range 매개 변수를 삭제하고 GCP에 CIDR 범위를 할당할 수 있습니다. 이 때 count을 필요한 실례수의 정수로 설정할 수 있습니다.
이 리소스 블록에서 생성된 Memorystore 인스턴스는 테스트에서는 효과가 좋지만 프로덕션 환경에서는 변경이 필요할 수 있습니다.생산의 경우 tier을 STANDARD_HA으로 변경하고 memory_size_gb을 어플리케이션 요구 사항에 맞는 크기로 변경하는 것을 고려해야 합니다.

인스턴스 그룹 호스팅

다음은 컨테이너 서버를 실행하는 VM(가상 시스템) 호스팅 인스턴스 그룹에 TwenProxy 서버를 배치하는 데 필요한 리소스를 정의합니다.완전한 위탁 관리 실례 그룹 해결 방안을 배치하려면 상당히 많은 자원이 필요하다.우리는 실례 템플릿과 실례 그룹 자원을 위탁 관리하는 것부터 시작할 것이다.

resource "google_compute_instance_template" "twemproxy_template" {
    region       = "us-east1"

    name_prefix  = "twemproxy-"
    machine_type = "f1-micro"

    tags = ["fw-allow-lb-and-hc", "fw-allow-twemproxy-6380"]

    disk {
        source_image = "cos-cloud/cos-stable"
        boot         = true
    }

    network_interface {
        network    = var.network.name
        subnetwork = var.subnetwork.name
    }

    lifecycle {
        create_before_destroy = true
    }
}

resource "google_compute_instance_group_manager" "twemproxy_instance_group" {
    zone               = "us-east1-b"

    name               = "twemproxy-mig"
    base_instance_name = "twemproxy"
    target_size        = 0

    named_port {
        name = "proxy"
        port = 6380
    }

    version {
        name              = "twemproxy-template"
        instance_template = google_compute_instance_template.twemproxy_template.self_link
    }

    lifecycle {
        ignore_changes = [
        version,
        target_size
        ]
    }
}

이미지 템플릿 자원은 주로 자리 차지 문자로 위탁 관리 실례 그룹에 코드 배치에 독립된 인프라 시설을 제공할 수 있습니다.트랜잭션 실례 그룹의 초기 배치는 이 템플릿을 필요로 하지만, 프로그램 코드가 바뀌고 프록시 서비스가 재배치될 때마다 이 템플릿을 대체합니다.
실제 템플릿의 생성과 배치 - 저희 도커 이미지를 포함해서 다음 블로그에서 논의할 것입니다.배치 과정에서 새 템플릿을 만들 때, 자리 표시자에 표시된 것과 같은 표시를 포함해야 합니다.이러한 레이블은 아래 정의된 방화벽 규칙을 인스턴스 템플릿에서 만든 VM 인스턴스에 첨부하는 데 사용됩니다.
위탁 관리 실례 그룹의 목표 크기는 0개의 실례로 프록시 서버를 배치하기 전에 불필요한 비용이 발생하지 않습니다.인스턴스 그룹에는 Terraform이 인스턴스 템플릿 버전과 실행 중인 인스턴스 수에 대한 변경 사항을 무시하도록 하는 라이프 사이클 정보도 포함됩니다.
Terraform에 이 변경 사항을 무시하라고 말하지 않으면, terraform apply을 실행할 때, 트랜잭션 실례 그룹의 실례 수를 0으로 줄이고, 현재 사용하고 있는 템플릿을 덮어씁니다.

로드 이퀄라이저

현재, 우리는 트랜잭션 실례 그룹을 위해 내부 부하 평형기를 만들어야 한다.내부 부하 균형기는 세 가지 자원으로 구성되어 있는데 그것이 바로 전송 규칙, 백엔드 서비스와 운행 상황 검사이다.전달 규칙은 IP 주소와 사용 가능한 포트를 포함한 로드 밸런서의 클라이언트 대상 속성을 정의합니다.백엔드 서비스는 실례를 위해 운행 상황 검사를 제공하고 부하 균형기가 데이터를 실례에 분배하는 방식을 정의하며 트랜잭션 실례 그룹 자원에 대한 인용도 포함한다.

resource "google_compute_forwarding_rule" "twemproxy_internal_lb" {
    provider = google-beta
    region   = "us-east1"

    name                  = "twemproxy-internal-lb"
    ip_protocol           = "TCP"
    load_balancing_scheme = "INTERNAL"
    backend_service       = google_compute_region_backend_service.twemproxy_backend_service.self_link
    ip_address            = "10.0.0.50"
    ports                 = ["6380"]
    network               = var.network.name
    subnetwork            = var.subnetwork.name
}

resource "google_compute_region_backend_service" "twemproxy_backend_service" {
    name          = "twemproxy-backend-service"
    region        = "us-east1"
    health_checks = [google_compute_health_check.twemproxy_health_check.self_link]

    backend {
        group          = google_compute_instance_group_manager.twemproxy_instance_group.instance_group
        balancing_mode = "CONNECTION"
    }
}

resource "google_compute_health_check" "twemproxy_health_check" {
    name               = "twemproxy-health-check"
    timeout_sec        = 1
    check_interval_sec = 1
    tcp_health_check {
        port = 6380
    }
}

방화벽 규칙

우리가 정의해야 할 마지막 자원은 방화벽 규칙이다.

resource "google_compute_firewall" "allow_lb_and_hc" {
  name    = "fw-allow-lb-and-hc"
  network = var.network.name

  source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
  target_tags   = ["fw-allow-lb-and-hc"]

  allow {
    protocol = "tcp"
  }
}

resource "google_compute_firewall" "allow_twemproxy" {
    name          = "fw-allow-twemproxy-6380"
    network       = var.network.name
    source_ranges = ["0.0.0.0/0"]
    target_tags   = ["fw-allow-twemproxy-6380"]

    allow {
        protocol = "tcp"
        ports    = ["6380"]
    }
}

위에서 정의한 첫 번째 방화벽 규칙을 사용하면 로드 밸런서와 상태 점검을 통해 관리되는 인스턴스 그룹의 VM과 통신할 수 있습니다.source_ranges 매개 변수에 분배된 IP 범위는 구글이 documentation에 제공하여 부하 평형기를 설정하는 데 사용되며 예시 코드의 정의와 완전히 일치해야 한다.
두 번째 방화벽 규칙은 네트워크의 다른 자원을 TwenProxy 서버와 통신할 수 있도록 허용한다.프록시를 사용하는 애플리케이션의 IP 주소와 일치하도록 source_ranges 속성을 변경해야 합니다.이 방화벽 규칙의 소스와 대상 리소스를 지정할 수 있는 옵션은 IP 범위 및 태그 외에도 있습니다.이러한 옵션과 해당 제한 사항에 대한 정보는 here입니다.
모든 필수 리소스를 정의한 후 현재 terraform validate과 terraform plan을 실행하여 모든 작업이 제대로 완료되었는지 확인하고 Terraform이 지정된 계획에 제공할 최종 리소스 목록을 볼 수 있습니다.
일단 모든 것이 정상이 되면 우리는 terraform apply -auto-approve을 운행할 수 있다.Terraform은 우리의 모든 자원을 제공하기 시작할 것이며, 배치가 성공했는지, 해결해야 할 문제가 있는지 알 수 있습니다.
다음 블로그에서 Twemproxy 서버를 새로 설정된 클라우드 자원에 배치하고 클라이언트 서비스의 코드를 Memorystore와 직접 통신하지 않고 프록시 서버를 사용할 수 있도록 변경할 것입니다.