1. 왜 불편하게 살았는가?

할 일들은 많고 시간은 한정되어 있다. 그렇기 때문에 나의 리소스를 어떻게 할당해서 사용하느냐는 너무너무 중요한 문제임을 느끼고 있다. 또한, 회사의 규모와 문화에 따라 특정 직무가 수행하는 "일반적인 일"이 달라지기도 하고 추가로 다른 직무의 일도 하기도 한다.

나에게 Terraform 코드를 관리하는 일이 조금 그러했다. 담당하는 MS에 필요한 데이터독 Integration, Monitor, Metric 등의 리소스를 관리해야 했다. 이를 잘 관리하기 위해선 HCL 언어에 대한 이해도 필요하고 CI / CD도 필요하고 PR 정책 등도 필요하겠지만 많은 시간을 투자하지 않았다.

이게 허용이 되는 기준은 "운영상의 문제가 없는 한" 이라고 생각한다. 운영상의 문제가 있을 것이라 판단된다면 도움을 요청하거나 시간을 투자해야 한다.

프로세스 및 코드를 개선하지 않는다면 그만큼 더 꼼꼼하고 분명하게 확인 후에 진행해야 한다. 정확한 프로세스를 만들어둔다면 그 프로세스를 만들기까지는 오래 걸릴지라도 이후 운영상의 리소스 소모가 줄어들 것이다. 개인의 커리어가 쌓여감에 따라 새로운 기술을 받아들이는 속도도 빨라질 것이기에 잘 고려해서 판단해야 할 것이다.

2. variables.tf를 사용하여 개선

데이터독 metric을 Terraform으로 생성하기 위해 datadog_logs_metric 리소스를 사용한다.

resource "datadog_logs_metric" "metric_a" {
  name = "test.metric_a"
  compute {
    aggregation_type = "distribution"
    path             = "@a"
  }
  filter {
    query = "service:test"
  }
}

위 코드를 통해 생성된 test.metric_a 는 test라는 APM의 로그들을 조회해서 a를 수집 및 집계한다.

여기서 또 하나의 metric이 추가된다면 그냥 하나 더 정의했다.

resource "datadog_logs_metric" "metric_b" {
  name = "test.metric_b"
  compute {
    aggregation_type = "distribution"
    path             = "@b"
  }
  filter {
    query = "service:test"
  }
}

이제 test.metric_a 가 생성되었다.

이렇게 하나, 둘 20개가 넘는 metric이 필요했다.

눈으로 내가 작성한 코드에 필요한 메트릭이 있는지 꼼꼼히 확인하는 게 힘들어졌다.

Terraform에선 variables.tf에 필요한 변수들을 정의할 수 있었다. 변수를 정의한 뒤 .tfvars 파일에 동적으로 이 변수에 값을 할당할 수 있는데, 나는 단순히 variables.tf에 있는 변수 정의 시 default 값에 필요한 값들을 넣기로 하였다.

# variables.tf
variable "model_request" {
  type = list(string)
  default = [
    "a",
    "b",
    "c"
  ]
}

이제 이 변수를 사용하여서 a, b, c 3개의 메트릭을 한 번에 정의해 보자.

resource "datadog_logs_metric" "model_request" {
  count = length(var.model_request)
  name = "test.metric_${var.model_request[count.index]}"
  compute {
    aggregation_type = "distribution"
    path             = "@${var.model_request[count.index]}"
  }
  filter {
    query = "service:test"
  }
}

티스토리툴바