Phantom File
SNS 파일 공유 시 서버 영구 기록 및 만료 누락 문제를 해결하는 휘발성 보안 파일 공유 서비스
$5 미만
월 운영비
671ms
P99 응답 속도
100%
장애 재처리 성공률
0건
요청 유실
K6 부하 테스트 - 결과 문서
Lambda 설정별 응답 분포 관찰과 서버리스 환경의 실측 성능 분석
Problem
→ 서버리스의 콜드 스타트와 동시성 한계를 사전에 파악하기 위해 부하 테스트를 수행했습니다.
서버리스는 콜드 스타트와 동시성 한계가 있기 때문에 실제 동시 요청이 몰렸을 때 어떻게 동작하는지 사전에 파악하고 싶었습니다. 테스트 목표는 절대 성능 수치보다 'Lambda 설정(메모리·동시성)을 바꿨을 때 응답 분포가 어떻게 달라지는가'를 관찰하는 것이었습니다.
- ▸Lambda 콜드 스타트가 실제 사용자 경험에 미치는 영향 미검증
- ▸Lambda 메모리 설정(128MB/512MB/1024MB)별 응답 성능 차이 미확인
- ▸동시 요청이 몰렸을 때 스로틀링 발생 지점 미파악
- ▸비용 대비 최적의 Lambda 메모리 설정값 근거 부재
Trade-off
→ 실제 사용 흐름을 시나리오로 작성하여 K6로 Lambda 설정별 응답 분포를 비교 관찰했습니다.
장점
- 설정이 간단함
- 개별 API 동작 확인에 적합
단점
- 동시 요청 시뮬레이션 불가
- Lambda 설정별 응답 분포 비교 어려움
- 반복 실행 자동화 어려움
장점
- 실제 사용 흐름(업로드 URL 요청 → 업로드 완료 → 파일 조회) 시나리오 작성 가능
- 가상 사용자 수 및 램프업 설정으로 점진적 부하 증가
- P50, P95, P99 등 상세 응답 분포 분석
- Lambda 메모리 설정별 반복 측정으로 비교 가능
단점
- 실제 파일 업로드(멀티파트) 시나리오 구현이 어려워 단순화 필요
- 테스트 환경과 프로덕션 환경 차이 존재
의사결정
파일 업로드 URL 요청 → 업로드 완료 처리 → 파일 조회 흐름을 K6 시나리오로 작성하고, Lambda 메모리 설정을 변경하며 반복 측정하여 응답 분포 변화를 관찰하는 방식을 선택했습니다.
Architecture
→ 최대 50 VUs, 10분간 약 9,800건 처리. 링크 생성 → 목록 조회 → 단건 조회 → 다운로드 → 삭제 전체 흐름을 시나리오로 구성했습니다.
K6로 실제 사용 흐름(링크 생성 → 목록 조회 → 단건 조회 → 다운로드 → 삭제)을 시나리오로 작성하고, 최대 50 VUs(가상 사용자)로 10분간 부하를 인가했습니다. 각 API 엔드포인트별 P95 임계치를 설정하고, Lambda 메모리 설정(128MB/512MB/1024MB)을 변경하며 응답 분포 변화를 관찰했습니다.
구현 흐름
- 1K6 시나리오 작성: create_link → list_links → get_link → download → delete_link 실제 사용 흐름 구현
- 2임계치 설정: create_link P99 < 3000ms, 나머지 API P95 < 2000ms, 오류율 < 5%
- 3가상 사용자 램프업: 0 → 50 VUs 점진적 증가, 10분간 유지
- 4Lambda 메모리 설정별(128MB/512MB/1024MB) 반복 측정으로 응답 분포 비교
Verification
→ 전체 체크 100% 통과, P99 671ms 달성. 512MB → 1024MB 증설 시 비용 대비 개선 폭이 작아 512MB가 최적 설정임을 확인했습니다.
10분간 약 9,865건의 HTTP 요청을 처리하며 18,832건의 체크를 100% 통과했습니다. 개인 서비스 규모의 동시 사용자 기준으로 측정한 것이며, 대규모 프로덕션(수백~수천 TPS)과 직접 비교할 수 없습니다. 이 테스트에서 얻은 핵심 인사이트는 메모리를 512MB → 1024MB로 올렸을 때 비용 대비 응답 개선 폭이 작아 512MB가 적절한 설정이라는 판단입니다.
9,865건
총 HTTP 요청 수
10분간 평균 16.4 req/s, 최대 50 VUs
100%
체크 통과율
18,832건 전체 통과 (응답 코드, 응답 본문 검증 포함)
671ms
create_link P99
링크 생성 API — 콜드 스타트 영향이 가장 큰 엔드포인트
28.8ms
get_link P95
단건 조회 — DynamoDB 키-값 조회 성능 확인
665ms
list_links P95
목록 조회 — 스캔 기반으로 상대적으로 높은 지연
17.61%
HTTP 오류율
Lambda 동시성 제한(계정 할당값 10)으로 인한 스로틀링 — 임계치 5% 초과
- create_link P95 35ms, delete_link P95 38ms, download P95 36ms — 대부분의 API가 안정적인 응답 분포
- list_links P95 665ms — 스캔 기반 조회로 다른 API 대비 높은 지연, 인덱스 최적화 검토 필요
- Lambda 메모리 512MB → 1024MB 증설 시 P95 개선 폭 미미 — 비용 대비 512MB가 최적 설정으로 판단
- 오류율 17.61%는 Lambda 동시성 한도(계정 할당값 10) 기인 — Reserved Concurrency 상향으로 해결 가능
Retrospective
→ 단순화된 시나리오와 개인 서비스 규모 한계를 인지하고, 실사용자 트래픽 기반 재측정을 계획합니다.
한계점
실제 파일 업로드(멀티파트) 시나리오를 K6로 구현하기 어려워, Pre-signed URL 발급까지만 테스트하고 실제 S3 업로드는 단순화했습니다. 실제 사용자 경험과 차이가 있을 수 있습니다.
보완 방향
향후 실사용자 트래픽 패턴이 축적되면 해당 데이터를 기반으로 시나리오를 보완하고 재측정할 계획입니다. S3 업로드 지연까지 포함한 E2E 시나리오 구성을 검토합니다.
한계점
개인 서비스 규모(최대 50 VUs, 16.4 req/s)에서 측정한 결과이며, 대규모 프로덕션 환경(수백~수천 TPS)과 직접 비교할 수 없습니다.
보완 방향
서비스 규모가 커질 경우 VUs를 단계적으로 늘려 스로틀링 발생 지점을 재확인하고, Reserved Concurrency 상향 또는 ECS Fargate 이관 시점을 판단하는 기준 데이터로 활용할 수 있습니다.