클라우드 VM과 클라우드 브라우저는 시간 기준으로 과금되므로 배치 작업은 할당량 초과가 쉽게 발생합니다. 소비량을 추정하고 실제로 쓸 수 있는 동시 실행 상한을 정한 뒤, 초과 시 대응 순서를 명확히 해 두는 것이 중요합니다.
시간 기준으로 과금되는 리소스의 청구 방식은 단순합니다. 실행 시간에 인스턴스 수를 곱하면 됩니다. 할당량은 명확한 상한입니다. 한도에 도달하면 작업이 단순히 느려지는 것이 아니라 바로 실패합니다. 새 인스턴스를 만들 수 없고, 실행 중인 인스턴스가 회수될 수 있으며, API가 속도 제한 오류를 반환하기 시작합니다. 문제가 생긴 뒤 예산을 늘리는 것보다 현재 상한까지 얼마나 남았는지 파악하는 편이 훨씬 유용합니다.
먼저 필요한 소비와 불필요한 소비를 구분하기
같은 할당량도 어떤 작업에 쓰느냐에 따라 결과가 크게 달라집니다. 먼저 전체 작업을 점검하고, 정말 실시간 실행이 필요한지 여부에 따라 구분합니다.
상시 실행 작업은 할당량을 가장 쉽게 소모하는 유형입니다. 하루 종일 켜져 있어도 실제로 일하는 시간은 몇 분뿐일 수 있습니다. 상시 모니터링을 예약 실행으로 바꾸면 비즈니스에 거의 영향을 주지 않으면서 소비량을 크게 줄일 수 있습니다. 특정 시간대에 몰리는 피크 작업은 시간대를 옮길 수 있고, 일회성 작업은 필요할 때만 시작하면 됩니다.
그다음 스스로 묻습니다. 이 작업이 6시간 늦게 실행되면 비즈니스에 영향이 있는가? 그렇다면 크리티컬 패스에 남겨 두고 실시간으로 실행합니다. 그렇지 않다면 낮은 우선순위의 배치 작업으로 전환해 할당량이 여유로운 시간대에 배치합니다. 경쟁사 가격 모니터링을 매시간에서 하루 두 번으로 줄여도 대부분의 경우 정보 가치가 실질적으로 떨어지지는 않습니다.
소비량을 추정하고 동시 실행 수를 정하는 방법
인스턴스 실행 시간 기준으로 과금될 때 한 배치의 총소비량은 대략 단일 작업의 평균 소요 시간에 작업 수를 곱한 값입니다. 동시 실행 수를 얼마나 높게 잡는지는 총소비량과 무관하며, 배치가 얼마나 빨리 끝나는지만 결정합니다. 동시 실행 수와 직접 관련된 것은 순간 부하입니다. 동시에 시작하는 인스턴스가 많을수록 리소스 풀의 동시 실행 상한이나 플랫폼 측 속도 제한에 걸릴 가능성이 커집니다.
따라서 동시 실행 수는 가장 작은 값부터 시험합니다. 먼저 작업 하나를 실행해 평균 소요 시간과 성공률을 확인합니다. 그런 다음 몇 개, 다시 열 개 남짓으로 단계적으로 늘리면서 실패율과 재시도 횟수를 기록합니다. 어느 지점부터 실패율이 뚜렷하게 올라간다면 그 지점이 실제로 사용할 수 있는 상한입니다. 그 이상 높여 봐야 재시도로 인해 아낀 시간을 다시 잃게 됩니다.
추정할 때 로그인 대기, 페이지 로딩, 검증 단계, 실패 후 재시도 같은 숨은 시간을 빼먹지 마십시오. 이런 구간이 주 처리 흐름보다 더 오래 걸리는 경우도 많습니다. 분 단위로 정확하게 계산하려 하기보다 각 작업에 여유 시간을 두는 편이 더 실용적입니다.
할당량이 소진되면 어떤 모습인가
할당량 소진은 다른 문제처럼 보이는 경우가 많아 알아보기 어렵습니다.
한 가지 증상은 환경이나 인스턴스 생성 요청이 거부되어 작업이 시작 단계에서 멈추고, 로그에는 모호한 실패 메시지만 남는 것입니다. 또 다른 경우에는 실행 도중 인스턴스가 회수되어 앞선 진행이 모두 무효가 됩니다. 속도 제한 오류가 발생하거나, 일부는 성공하고 일부는 실패하거나, 처리할 수 있는 워커 없이 큐만 계속 길어질 수도 있습니다.
가장 오진하기 쉬운 것은 가짜 멈춤 상태입니다. 인스턴스는 여전히 존재하고 작업도 실행 중인 것처럼 보이지만, 실제로는 대기 상태에서 막혀 있고 시간에 따라 할당량은 계속 소모됩니다. 이런 경우 먼저 할당량 사용 패널을 확인한 뒤 작은 작업 하나를 따로 실행해 봅니다. 작은 작업도 시작되지 않으면 할당량이나 권한 문제를 확인해야 합니다. 정상적으로 실행된다면 동시 실행 수나 환경 재사용이 원인일 가능성이 높습니다.
복구 순서
먼저 비용이 들지 않는 조치부터 시행합니다.
첫째, 가치가 낮은 상시 소비를 중단하고 모니터링 작업을 예약 실행으로 바꿉니다. 둘째, 지연 가능한 작업을 할당량이 여유로운 시간대로 옮겨 소비 곡선을 평탄하게 만듭니다. 셋째, 동시 실행 상한을 낮추고 큐를 추가해 모든 작업을 한꺼번에 시작하는 대신 가용 용량에 맞춰 처리합니다. 넷째, 불필요한 소비를 줄입니다. 같은 리소스를 반복해서 가져오지 않도록 캐시를 사용하고, 가능하면 한 번의 요청에서 더 많은 데이터를 가져오며, 실패가 확실한 요청은 빠르게 종료하고 무한 재시도하지 않습니다.
이 네 단계를 마친 뒤에야 예산을 늘리거나 더 높은 서비스 등급으로 바꿀 필요가 있는지 판단합니다. 실제로 필요한 할당량이 처음 예상보다 적다는 사실을 발견하는 경우가 많습니다. 반대로 예산부터 늘리면 비효율적인 습관까지 함께 비용으로 떠안게 됩니다.
컴퓨팅 계층과 함께 환경 계층까지 압축하지 않기
할당량을 아끼려 할 때 흔히 하는 실수는 같은 환경은 한 번만 띄우면 된다는 이유로 여러 작업이 하나의 브라우저 환경을 공유하게 만드는 것입니다.
대가는 즉시 나타납니다. 세션이 서로 덮어쓰고, 로그인 상태가 밀려나며, 캐시가 섞이고, 한 작업의 실패가 다른 작업까지 끌어내릴 수 있습니다. 조금 아낀 인스턴스 실행 시간은 장애 분석과 재실행 과정에서 몇 배로 되돌아옵니다.
이 두 계층은 분리해서 봐야 합니다. 컴퓨팅 계층은 작업 로직을 실행하고 필요에 따라 스케줄링하며 비용 효율을 추구합니다. 환경 계층은 신원과 격리를 담당하며 작업마다 독립된 환경을 두어 안정성을 추구합니다. 컴퓨팅 자원이 부족하다는 이유로 환경 계층까지 압축하는 것은 서로 다른 두 종류의 비용을 혼동하는 것입니다. 환경을 대량으로 만들고 회수하는 일은 환경 계층의 도구가 중앙에서 관리해야 합니다. PurpleMark처럼 환경별로 세션과 캐시를 격리하면 상위 계층의 작업과 실행기를 더 유연하게 스케줄링할 수 있습니다.
마지막으로, 비용 절감을 규정 위반 방향으로 가져가지 마십시오. 할당량을 아끼기 위해 비공식 서비스를 이용하지 말고, 요청 빈도를 높여 억지로 처리량을 밀어 올리지 마십시오. 속도 제한이 걸린 뒤의 재시도는 통제된 속도로 실행하는 것보다 더 많은 할당량을 소비합니다.
