관찰력 문화는 엔지니어가 중점을 잡는 데 도움이 된다(예를 들어)

벌집에서 우리는 AWS 현장 실례의 충실한 팬이다.recent bill reduction exercise 테스트를 통해 API 서비스를 현장에서 실행하면 많은 비용을 절감할 수 있다는 사실을 알게 되었으며 이제 어디서나 사용할 수 있습니다.그러나 모든 서비스가 현장에 적합한 것은 아니다.지금까지 우리 중 많은 사람들이 필요에 따라 EC2 실례에서 서비스를 실행할 수 있었고 호스트가 수시로 종료되거나 고장이 날 수 있었지만 스팟을 사용하는 것과 비교하면 비교적 보기 드문 일이다. 스팟에서 현물 시장의 갑작스러운 변동으로 인해 당신의 실례가 2분의 경고 없이 사라질 수 있다.우리가 현장에서 새롭고 상태가 있으며 시간에 민감한 서비스를 운행하는 것을 고려할 때, 이것은 불가능한 것 같지만, 잠재적인 장점이 너무 좋아서, 우리는 시도해 보지 않을 수 없다.
우리의 강력한 관찰성 문화와 그것이 제공하는 환경은 우리가 안전하게 실험을 할 수 있다는 것을 의미한다.약간의 공사상의 심사숙고, 현대화된 배치 절차와 양호한 기기로 우리는 자신만만하게 전환할 수 있다.우리는 이렇게 했다.

우리는 무엇을 지지해야 하는가


UI에서 클릭 몇 번만으로 추적 감지 샘플링을 수행할 수 있는 기능을 개발하고 있습니다.백엔드 서비스 (내부 이름 Dalmatian) 는 버퍼 추적 이벤트를 책임지고 전체 추적에 대해 샘플링 결정을 내린다.올바르게 작동하려면 다음을 수행해야 합니다.
  • API의 연속적이고 무질서한 이벤트 흐름을 최대한 빨리 처리
  • 관련 사건을 그룹으로 나누고 충분한 시간을 버퍼링하여 결정하도록 한다
  • 동일한 레코드 트랙을 재처리하는 것을 피하고 도착 지연
  • 에 대해 동일한 레코드 트랙 ID에 대해 일치된 결정을 내린다.
    그룹을 완성하기 위해서, 우리는 확정적인 매핑 함수를 사용하여 ID를 같은 Kafka 구역으로 추적하고, 각 구역은 Dalmatian 호스트에서 처리합니다.우리가 처리한 흔적을 추적하기 위해서는 상태라는 얄미운 녀석이 필요하다.명확히:
  • 이벤트 흐름의 현재 편이도
  • 처리되지 않은 가장 오래된 기록도의 편이량
  • 처리된 추적 ID와 샘플링 결정의 최근 기록
  • 이 상태는 Redis와 S3의 조합에 저장되기 때문에 Dalmatian은 리셋 사이에 로컬로 저장할 필요가 없습니다.대신 상태가 주기적으로 외부 스토리지로 플러시됩니다.이것은 매우 간단하다.그러나 시작은 더욱 복잡하다. 이벤트 처리를 정확하게 복구하려면 정확한 절차를 수행해야 하기 때문이다.아직 해야 할 상태가 많습니다. 시간이 늘어나고 실패할 수도 있습니다.요컨대 서비스가 시작되면 배가 흔들리지 않도록 운행하는 것이 좋다.이 서비스를 현장에서 실행하기 전에 자주 드나드는 호스트에 추가적인 혼란을 도입하는 것을 고려해야 한다.

    묵인된 혼란


    우리가 벌집에서 열심히 추구하는 관찰 중심의 문화의 일부로서 우리embrace CI/CD.배치 인원은 매시간 한 번씩 외출한다.이러한 방법의 많은 장점 중 하나는 우리의 배치 시스템이 정기적으로 운행되고 우리의 서비스는 수시로 다시 시작된다는 것이다.이런 환경에서 복잡한 시작과 닫기 서열을 가진 상태 서비스를 구축하는 것은 이 서열의 오류가 곧 나타날 것을 의미한다.현장에서 Dalmatian (이중 관문어 줄 서기) 을 실행하는 것을 고려할 때, 우리는 리셋을 통해 우리의 상태 관리를 안정시켰고, 스팟이 도입할 수 있는 대부분의 문제가 처리되었다.

    핫스팟


    그러나 스팟을 사용하면 호스트를 정기적으로 떠나게 하는 것은 새로운 호스트가 나타나기를 기다려야 한다는 것을 의미한다.ASG 응답 시간, Chef와 배포 프로세스 사이에 새 호스트를 접속하는 데 평균 10분이 소요됩니다.우리는 언젠가 개선될 수 있기를 희망하지만, 우리는 아직 하지 못했다.파티션당 처리 호스트가 하나씩 있으므로 호스트를 분실하면 이벤트 처리가 최소 10분 지연될 수 있습니다.이것은 우리 고객들에게 나쁜 경험이다. 우리는 이런 경험을 피하기를 바란다.다행히도 스팟 인스턴스는 매우 싸다. 우리는 평균 70%의 인스턴스 비용을 절약했기 때문에 예비 모드에서 추가 호스트를 사용하여 실행할 수 있다.이것은 약간의 추가 지형 코드를 통해 실현된 것이다.
    min_size                  = var.dalmatian_instance_count[var.size] + ceil(var.dalmatian_instance_count[var.size] / 5)
    max_size                  = var.dalmatian_instance_count[var.size] + ceil(var.dalmatian_instance_count[var.size] / 5)
    
    우리의 프로세스 시작 코드에서 약간의 수정을 한 후에, 실례는 하나의 구역이 풀리기를 기다리고, 이 구역의 작업 부하를 즉시 수신할 것입니다.

    우리 뭐 하는지 보자.


    우리는 이 서비스의 운영 방식에 대해 중대한 변화를 했다.우리는 일이 예상대로 진행되었는지 어떻게 알 수 있습니까?그래, 우리 일을 정의해 보자. 즉, 우리 Service Level Objective 이다.우리는 심각한 섭취 지연이 우리의 핵심 제품 체험을 파괴할 수 있다고 생각하기 때문에Dalmatian과 새로운 기능에 대해 사건 처리와 납품 시간은 5분 이내, 즉 99.9%의 시간 내에 설정했다.
    SLO의 배경에서 Dell은 이 새로운 기능을 현장 팀으로 이전하고 추가 호스트가 손실된 경우에도 서비스 수준 목표를 유지할 수 있느냐는 질문에 대해 다시 한번 말씀드릴 수 있습니다.

    지난달 프로덕션 환경에서는 최소 10대의 호스트 교체가 관찰되었습니다.이는 우리의 과거 고객 이탈률보다 높지만, 스팟에 대한 우리의 기대이기도 하다.

    한 달 동안 SLO 준수 임계값(99.9%) 이상을 유지했습니다.이런 측면에서 볼 때, 이것은 성공적인 변혁인 것 같다. 우리는 이것이 우리를 위해 대량의 운영 비용을 절약했기 때문에 흥분된다.

    새로운 소방 능력은 반드시 계획의 일부분이어야 한다


    지금은 모든 것이 정상이지만 장래에는 붕괴될 수도 있다.불가피하게 우리는 자신이 사건 처리에 있어서 낙후되어 있다는 것을 발견할 수 있다.우리가 이 서비스를 위해 반드시 내려야 할 일련의 결정은 "우리가 어떤 실례에서 운행하고, 얼마나 큽니까?"이다.우리가 전송된 데이터를 따라잡을 때, 우리는 비교적 작은 실례 유형에서 운행할 수 있다.그러나 만약 우리가 뒤떨어진다면, 우리는 더 많은 계산을 해서 가능한 한 빨리 따라잡아야 하지만, 우리가 1년에 한 번만 필요로 하는 상황에서 그것을 계속 운행하는 것은 매우 비싸다.우리는 각 구역에 하나의 프로세서 모델이 있기 때문에, 우리는 진정으로 동적 확장을 할 수 없다.하지만 우리는 규모를 늘릴 수 있다!
    앞에서 언급한 10분 호스트 안내 시간 때문에 더 큰 실례로 모든 호스트를 교체하는 것은 이상적이지 않다.우리가 실례가 나타나기를 기다릴 때 우리는 더욱 뒤떨어질 것이다. 일단 규모를 줄이기로 결정하면 우리는 다시 뒤떨어질 것이다.만약 우리가 같은 규모의 함대를 세우고 더 큰 실례를 가지고 그 함대로 전환한다면?이 지형 규범은 우리가 소위 쫓는 함대를 정의했다.ASG는 dalmatian_catchup_instance_count가 0보다 클 때만 존재합니다.긴급한 상황에서 단선 차분은 그것을 온라인으로 연결할 수 있다.
    resource "aws_autoscaling_group" "dalmatian_catchup_asg" {
      name  = "dalmatian_catchup_${var.env}"
      count = var.dalmatian_catchup_instance_count > 0 ? 1 : 0
    
      # ...
    
      launch_template {
        launch_template_specification {
          launch_template_id = aws_launch_template.dalmatian_lt.id
          version            = "$Latest"
        }
    
        dynamic "override" {
          for_each = var.dalmatian_catchup_instance_types
          content {
            instance_type = override.value
          }
        }
      }
    }
    
    호스트가 준비되었을 때, 우리는 작은 기기의 모든 프로세스를 멈추고 그것들로 전환함으로써, '핫 스페어' 논리로 백업 기기를 시작할 수 있다.우리가 곤경에 빠졌을 때, 우리는 반대로 이 과정을 반복할 수 있다. 작은 팀에서 절차를 시작한 다음에 비교적 큰 팀을 멈출 수 있다.물론 벌집을 사용함으로써 우리는 이 해결 방안이 비교적 작은 환경에서 소방 훈련과 함께 일하는 것을 검증할 수 있다.

    관찰 중심의 문화적 장점을 발견하다


    그래, 그것만으로도 충분할지 모르지만, 여기서 중점은 우리가 새로운 체계 구조에 대해 실험을 하고 서비스 운영 방식에 대해 중대한 변경을 하는 능력은 우리가 신속하게 배치하고 이러한 변경이 시스템 행위에 어떻게 영향을 미치는지 찾아내는 능력에 달려 있다는 것이다.강력한 CI/CD 프로세스, 숙고하고 내용이 풍부한 도구, 그리고 소프트웨어 소유자로서 앞으로 이 기능을 지원하는 데 필요한 일에 대한 관심은 사용자들이 좋아하는 소프트웨어를 더욱 쉽고 안전하게 구축하고 발표할 수 있도록 합니다.
    새 소프트웨어를 발표하는 번거로움에서 벗어날 준비가 되었습니까?벌집은 이상치를 발견하고 사용자가 서비스를 어떻게 체험하는지 알아보는 데 도움을 줍니다. Get started for free!

    좋은 웹페이지 즐겨찾기