수치 기반 사고(Observability + Capacity Planning)
아래와 같은 면접 질의응답이 있다고 치자.
면접관: 만약 유저의 트래픽을 클라우드 워치로 추적해 지표 알림을 설정한다고 칩시다 몇%일때 어떤 설정을 업데이트해야될까요?
+ 여기서 내가 휴리스틱하게 80%요, 80퍼가 차면 api gateway기능 캐싱을 통해 증가세 억제하지 않을까요. 라고 답을하면
면접관: 80퍼면 너무 늦지 않나.. 다른 방법은요?
나: 음.. 그럼 70%? 30퍼때 캐싱기능을 업데이트하고 70%일때 lambda provisioned concurrency를 on 하던가...
면접관: 왜 30퍼고 왜 70인데요? 구체적인 근거점요.
수치 기반 사고 #
자 위에 면접 내용을 보자 개처참하다. 저런 답을 하면 안된다.
성능을 고려할때 트래픽이 많은 프로젝트라면 더더욱더 휴리스틱을 버려야한다.
즉 이런 질문에서는 퍼센트(임계치)의 값을 말하는 것이 아닌, 결정 과정(근거 공식)을 말해야한다.
면접관은 실제 수치를 묻는것이 아니라 그 임계치는 논리적으로 어떻게 어떤 데이터로 결정했는가를 묻는것이다.
임계치는 사전에 계산된 최대 처리량(capacity) 기준을 ㅗ정합니다.
과거 2~4주간의 **피크 트래픽**, **처리시간**, api gateway/lambda 단일 인스턴스당 **처리량**을 수집한 이후
피크 대비 여유 버퍼 (보통 20~30퍼센트)를 두고 임계치를 정합니다.
cloud watch 알람의 임계치는 고정 값이 아니라 capacity 대비 사용률 = (현재 처리량 / 사전 계산된 최대 처리량) 으로 설정합니다.
위와 같이 대답해야 일단은 면접관이 오 일단 답을 하긴하네라고 생각한다.
퍼센트 기준은 이렇게 설명해라 #
퍼센트는 근거가 있어야한다. 예시로 이런 기준을 제시할 수 있다.
- 60%: 상승 추세 감지(Scaling 예열 단계)
- 75%: Lambda Provisioned Concurrency:사전 warm-up 시작
- 85%: api gateway cache 확대 or TTL 조정 검토
- 90%: 긴급 알람, 자동 확장 쿼터 점검
그리고 반드시 아래를 붙인다.
이 수치는 절대값이 아니라
해당 시스템의 TPS, Lambda Duration, Cold Start 발생률,
과거 버스트 트래픽 패턴을 기반으로 산출해야합니다.
알람 대응 전략은 시간 + 예열 관점에서 말해야됨 #
면접관이 80이면 늦지않아요? 라고 말한 이유는
프로비저닝 동시성은 예열 시간이 필요하기 때문이다
따라서
Provisioning Concurrency는 적용되기까지 몇 분의 예열 시간이 필요하기 때문에
실제 부하가 오기 전에는 트래픽 추세(Slope)를 감지하여 선제적으로 확장해야합니다.
그래서 절대값(80퍼센트)이 아니라 단기 이동 평균의 기울기(예: 1분 5분 15분 baseline을 비교)를 이용한 Early Signal을 활용합니다.
총총 #
임계치 퍼센트는 고정된 숫자가 아니라,
사전에 계산한 시스템 최대 처리량을 기준으로 동적으로 설정합니다.
저는 먼저 Lambda의 평균 처리시간(Duration), 동시성(Concurrency), API Gateway의 RPS,
그리고 지난 2~4주 피크 트래픽을 기반으로 ‘Max Capacity’를 구합니다.
CloudWatch 지표는 이 Max 대비 사용률로 설정합니다.
예열이 필요한 Provisioned Concurrency는 트래픽 증가 기울기가 일정 기준 이상이거나
Capacity의 약 60~70%를 넘기기 시작할 때 사전 예열을 걸고,
캐싱은 CPU·메모리보다 RPS 증가율이 빠르게 치솟을 때,
즉 75~85% 부근에서 TTL 조정이나 온오프를 고려합니다.
중요한 점은 퍼센트 자체가 아니라,
과거 트래픽 패턴과 최대 처리량 계산을 기준으로
‘언제 예열이 필요하고 언제 지연이 발생하는지’를 근거로 임계치를 설정한다는 것입니다.
Lambda Concurrency: 동시에 실행중인 람다 함수 인스턴스 개수라고 함 즉, 한 시점에 몇개 람다 함수가 동시에 실행되고 있는지 숫자로 나타낸 지표로 요청이 들어올대마다 람다는 새로운 실행 환경을 실행하거나(콜드 스타트) 기존 환경을 재사용함 따라서 트래픽이 증가하면 동시에 실행되는 람다수가 급증하고 이게 Concurrency
예: 1초 동안 200개의 요청이 들어오고, 각 요청의 평균 처리 시간이 0.5초이면, 동시에 약 100개의 Lambda가 실행됨.Concurrency가 많아지면 Quota(한도)를 넘게될수있으며 넘으면 스로틀링됨. 그래서 Provisioned Concurrency로 해결할 수 있는데 이는 콜드 스타트를 방지하는 기능임. 자세한건 aws lambda에서 알아보겟다