성능·비용 감사에서 나온 provisioning 구역 항목을 모아 인계한다. 이 구역은 최근 3주 커밋 대부분이 unhak 명의라 소유 구역 규칙(AGENTS.md §함정 2)에 따라 직접 고치지 않고 이슈로 넘긴다.
발견은 코드 실측이고 가장 급한 것은 9-3(ECR) 이다 — 유일하게 시간에 비례해 실제 청구서가 늘어난다.
| # |
위치 |
문제 |
제안 |
| 9-3 |
EcrImageRegistry.java |
lifecycle policy 미설정 — putLifecyclePolicy·batchDeleteImage 호출이 하나도 없다. 배포마다 push 되는 이미지 태그와 untagged 레이어가 영구 누적되고 ECR 은 GB 단위로 과금된다 |
리포지토리 생성 시 putLifecyclePolicy 1회 적용(untagged 1일, tagged 최근 N개) |
| 9-1 |
AwsCredentialsResolver.java:34-83 |
STS AssumeRole 을 작업마다 새로 호출하고 StsClient·DefaultCredentialsProvider 도 매번 생성. 상태 폴러 4종(서버 20s·RDS 30s·CDN 30s·EIP 10m)이 각자 15분짜리 세션을 계속 발급한다. 코드 주석이 "캐시하지 말라(폴링 중 만료 위험)" 고 적고 있다 |
StsAssumeRoleCredentialsProvider 는 만료 전 자동 갱신을 제공한다 — 연결 ID 키로 캐시하면 주석의 우려가 해소된다 |
| 9-2 |
RdsProvisioner.java:136-140 · CloudFrontDistributionProvisioner.java:207-211 · S3StaticSiteStore.java:264-268 · AcmCertificateProvisioner.java:105-109 · EcrImageRegistry.java:136-140 |
SDK 클라이언트를 호출마다 빌드하고 UrlConnectionHttpClient(커넥션 풀 없음)를 쓴다 |
연결별 클라이언트 캐시(9-1 과 묶어서), S3 업로드처럼 잦은 경로는 ApacheHttpClient |
| 9-4 |
ProvisionedServerStatusWorker.java:125 |
부트 타임아웃 terminate 경로에 EIP release 호출이 없다 |
OrphanElasticIpSweeper(10분)가 회수하므로 노출은 ≤10분이지만, 즉시 release 하면 스윕 의존이 사라진다 |
| 9-5 |
ServerHealthMonitorWorker.java:69 |
최대 50서버 × (TCP 2s + HTTP 3s)를 직렬 프로브 → 최악 250초 동안 스케줄러 스레드를 독점한다. 값이 안 바뀌어도 서버당 매분 UPDATE 1건 |
병렬 프로브 + 전용 executor 위임 + 값 불변 시 UPDATE skip |
| 9-6 |
OrphanElasticIpSweeper.java:34 |
10분마다 연결당 DescribeAddresses |
1시간이면 충분(자기치유 성격) |
| 보류 |
프로비저닝 폴러 6종(15~30초, ProvisionedServerStatusWorker·RdsProvisionStatusWorker·DockerDbProvisionStatusWorker·BackendDeployWorker·S3CdnProvisionWorker·ServerReplacementService) |
각자 DB 를 따로 친다 |
하나의 "provisioning tick" 으로 병합 가능 — 판단은 이 구역 담당자 몫 |
이미 잘 되어 있는 것(재작업 방지): 서버 terminate 시 EIP release + SSM/S3 정리, EIP 고아 스윕, CloudFront 고아 스윕, CdnDeletionReaper, RDS 삭제 시 skipFinalSnapshot·deleteAutomatedBackups — 종료 경로의 과금 자원 누수는 구조적으로 막혀 있다. 위 항목은 전부 생성·유지 경로 쪽이다.
관련: #335(스케줄러 스레드 풀 1→6, 9-5 의 영향 완화) · 성능 감사 전체 계획은 .agent-team/00-plan/perf-cost-plan.md
성능·비용 감사에서 나온 provisioning 구역 항목을 모아 인계한다. 이 구역은 최근 3주 커밋 대부분이 unhak 명의라 소유 구역 규칙(AGENTS.md §함정 2)에 따라 직접 고치지 않고 이슈로 넘긴다.
발견은 코드 실측이고 가장 급한 것은 9-3(ECR) 이다 — 유일하게 시간에 비례해 실제 청구서가 늘어난다.
EcrImageRegistry.javaputLifecyclePolicy·batchDeleteImage호출이 하나도 없다. 배포마다 push 되는 이미지 태그와 untagged 레이어가 영구 누적되고 ECR 은 GB 단위로 과금된다putLifecyclePolicy1회 적용(untagged 1일, tagged 최근 N개)AwsCredentialsResolver.java:34-83StsClient·DefaultCredentialsProvider도 매번 생성. 상태 폴러 4종(서버 20s·RDS 30s·CDN 30s·EIP 10m)이 각자 15분짜리 세션을 계속 발급한다. 코드 주석이 "캐시하지 말라(폴링 중 만료 위험)" 고 적고 있다StsAssumeRoleCredentialsProvider는 만료 전 자동 갱신을 제공한다 — 연결 ID 키로 캐시하면 주석의 우려가 해소된다RdsProvisioner.java:136-140·CloudFrontDistributionProvisioner.java:207-211·S3StaticSiteStore.java:264-268·AcmCertificateProvisioner.java:105-109·EcrImageRegistry.java:136-140UrlConnectionHttpClient(커넥션 풀 없음)를 쓴다ApacheHttpClientProvisionedServerStatusWorker.java:125OrphanElasticIpSweeper(10분)가 회수하므로 노출은 ≤10분이지만, 즉시 release 하면 스윕 의존이 사라진다ServerHealthMonitorWorker.java:69OrphanElasticIpSweeper.java:34DescribeAddressesProvisionedServerStatusWorker·RdsProvisionStatusWorker·DockerDbProvisionStatusWorker·BackendDeployWorker·S3CdnProvisionWorker·ServerReplacementService)이미 잘 되어 있는 것(재작업 방지): 서버 terminate 시 EIP release + SSM/S3 정리, EIP 고아 스윕, CloudFront 고아 스윕,
CdnDeletionReaper, RDS 삭제 시skipFinalSnapshot·deleteAutomatedBackups— 종료 경로의 과금 자원 누수는 구조적으로 막혀 있다. 위 항목은 전부 생성·유지 경로 쪽이다.관련: #335(스케줄러 스레드 풀 1→6, 9-5 의 영향 완화) · 성능 감사 전체 계획은
.agent-team/00-plan/perf-cost-plan.md