Repository navigation
Conversation
VERIFICATION_RESULT 의 멱등 키가 verification_id 하나라, 수동 체크 성공(MANUAL_SUCCESS)을 당일 취소한 행이 D+2 에 실패로 굳어도 CONFIRMED_FAILURE 가 앞선 성공 알림의 UNIQUE 에 막혀 조용히 사라졌다. 키를 (verification_id, variant) 로 바꾼다. 같은 변형의 재발행은 그대로 한 번이다. 옛 키와 새 키가 겹치지 않아 마이그레이션은 없다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
배포 때마다 옛 태스크가 SqsClient 가 닫힌 뒤에도 5초 폴러를 돌려 moderation_receive_failed (Connection pool shut down · RejectedExecutionException) ERROR 를 남겼다. ContextClosedEvent 는 빈 파괴보다 먼저 오므로 그때 수신을 멈추고, 그 순간 이미 시작된 수신의 실패는 로그로 남기지 않는다. UserModerationQueue 도 같은 문제라 함께 고친다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
stg(1GB 태스크) JVM RSS ~800MB 중 힙은 256MB 였고 glibc malloc 아레나가 ~200MB 를 차지해 (ECS Exec 로 /proc/1/smaps 실측) RSS 가 천천히 차올라 ECS-06-80 이 하루쯤마다 다시 울렸다. 태스크 메모리는 늘리지 않고 아레나 수를 묶는다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…-by-variant fix: 당일 취소한 수동 체크도 이틀 뒤 「실패로 확정됐어요」 알림을 받는다
fix: 종료가 시작되면 모더레이션 큐 폴링을 멈춘다
fix: 배포 이미지에 MALLOC_ARENA_MAX=2 — stg 하드 메모리 80% 경보 반복
「등록한 장소에 머물지 않았다」는 판정이 성립하지 않아 유형째 뺀다. 카탈로그 1101~1110 을 지우고(V12), 회피 판정 분기·스침 유예 설정· ENTERED_AVOID_ZONE 문구·인증 안내 예시를 걷어낸다. 이미 만든 방은 지우지 않고 직접 인증으로 바꾼다 — 템플릿만 없어진 채 자동으로 두면 휴리스틱이 GEOFENCE 를 「장소 방문」으로 읽어 정반대로 판정한다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
첫 잠금 해제는 누워서 알람만 꺼도 잡히고 일어나서 휴대폰을 안 보면 실패한다. 00:00 ~ 목표 시각 + 30분 안에 Health Connect 걸음이 10걸음 이상이면 기상으로 본다. 유예·걸음 수는 실기기 테스트로 찾을 값이라 설정(app.verification.wake-grace-minutes·wake-min-steps)으로 뺐다. 앱은 requiredPermissions 로 수집 지표를 정하므로 템플릿과 이미 만든 방의 권한을 READ_STEPS 로 바꾼다(V13) — 앱 수정 없이 걸음이 온다. 걸음 출처 게이트·겹침 제거는 움직임 판정과 같은 코드를 쓴다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat: 기상 루틴을 잠금 해제가 아니라 일어나 걸은 걸음으로 판정한다
0명 방도 봇방장으로 넘기기만 해서, 하루 1번 유령방 삭제 배치가 지울 때까지 (정산 대기가 있으면 1주 넘게) 탐색·인기에 남고 남이 가입해 되살릴 수 있었다. 자진 탈퇴·회원 탈퇴·자동 강퇴에서 남는 활성 멤버가 없으면 삭제 표시한다 — 탐색·인기·상세·가입이 즉시 막히고, 이력과 실제 삭제는 같은 배치가 이어서 한다. 멤버가 1명 이상 남으면 지금처럼 봇방장 체제다. 이탈 탭은 닫힌 방도 기록으로 보여 준다. 이미 남아 있는 0명 방은 V14 로 닫는다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fix: 마지막 멤버가 나가면 봇방장으로 넘기지 않고 방을 닫는다
노션 「모니터링」 10/15 리뷰 반영. P0 는 조건 충족 후 1~2분 안에 호출, P1 은 대부분 5분 이내. - API-01 판정 창 5분 → 2분, API-02 → 3분(slo_core) - 공개 점검을 한 실행에 30초 간격 두 번 — EDGE-01 은 두 번 연속 실패, EDGE-02 는 2분(4회) 중 2회 - NATIVE-01 1분, NATIVE-02 2분, RES-01/03/04 1분, OBS-01 하트비트 2분 - 신규 P0: DB-10 RDS CPU ≥99% 1분, DB-11 Freeable ≤RAM 5% 1분 + Swap 증가(DbMemoryCritical) - OBS-04 를 Healthchecks.io 전까지 CloudWatch 하트비트 5분 누락 P0 로 대신 - P1 ECS·JVM·풀·RDS·Redis·SQS·외부 연동 창을 표대로 줄임 - 시험: P0 평가 창이 2분을 넘지 않는지 고정 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
노션 10/15 리뷰 「JVM 대시보드 지표 보강」. 힙 영역별 사용·최대 힙, GC 정지 최대·횟수, 스레드 상태, 클래스 로딩, direct/mapped 버퍼, 프로세스 CPU·업타임을 RuntimeOpsSampler 가 RuleUp/Ops 로 낸다. Micrometer jvm.* 를 통째로 내보내면 태그 조합이 70개를 넘어 필요한 19개만 직접 잰다. 경보는 없다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
alerting/pagerduty.py setup 이 에스컬레이션 정책(1차 → 10분 → 팀원, 2회 반복)·서비스(항상 high, ACK 15분 재호출, 자동 종료 끔)·공식 CloudWatch 연동을 만들고 서울·버지니아 SNS ruleup-prod-pagerduty 를 HTTPS 로 구독시킨 뒤 원장에 ID 만 적는다. p0_p1.py 를 다시 돌리면 P0 경보에 토픽이 붙는다. test-trigger·test-resolve 로 실수신·에스컬레이션을 시험한다. API 키·연동 키·이메일은 저장소에 두지 않는다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat: P0 온콜 — 1차 담당 → 10분 미응답 시 팀원 (PagerDuty)
pagerduty.py setup 결과. 이메일·API 키·연동 키는 넣지 않았다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
test-trigger 가 PagerDuty 토픽에만 메시지를 보내서 Slack(#ruleup-alert·긴급 채널 멘션)이 빠졌다. 시험 경보 ruleup-prod-P0-ONCALL-TEST 를 실제 P0 와 같은 AlarmActions 로 두고 set-alarm-state 로 상태만 바꾼다. 아무도 내지 않는 지표를 missing=ignore 로 봐서 다음 평가에서 OK 로 돌아가지 않으므로 10분 에스컬레이션도 그대로 볼 수 있다. tests_pagerduty 를 CI 에 넣는다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
chore: PagerDuty 개통 — 원장 ID 기록
fix: 온콜 시험이 Slack 까지 실제 P0 와 같은 경로로
실제 인가 코드는 1회용이라 로그인 부하를 줄 수 없다. OAUTH_LOAD_TEST_ENABLED=true(prod 프로파일엔 빈이 없다)일 때 code 가 loadtest- 로 시작하고 codeVerifier 가 DEV_TOKEN_SECRET 과 같은 요청만 IdP 호출을 건너뛰고, 그 뒤 실제 로그인 트랜잭션은 그대로 탄다. 다른 요청은 켜 둔 동안에도 실제 IdP 로 간다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
app.challenge.draft.rate-limit-per-minute(기본 10). 부하테스트 동안 stg 에서만 올린다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat: stg 부하테스트 준비 — 로그인 우회 스위치·AI 초안 한도 설정값
데이터소스를 감싸 커넥션 대여·커밋·SQL 문장을 기록하는 시험 전용 SqlRecorder 와, 로그인·리프레시·템플릿 초안· 생성·홈의 DB 작업을 출력하는 RequestDbProfileIT. 부하테스트(2026-10)에서 로그인·생성이 과한지 보려고 만들었다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
인증된 요청마다 user_activity upsert 가 돌아 GET 하나가 곧 DB 쓰기 하나·커넥션 대여 하나였다. 값이 날짜라 같은 날 반복은 결과가 같으므로 태스크마다 오늘 기록 여부를 기억하고 건너뛴다. 로그인·가입은 touchNow 로 반드시 쓴다(같은 날 앞선 기록이 탈퇴 상태라 무시됐을 수 있다). 로그인은 저장 전후로 두 번 쓰던 것을 저장 뒤 한 번으로. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
배포·스케일아웃마다 워밍업이 Unable to connect to Redis 로 실패해 회로가 열리고 5분 스윕까지 탐색이 SQL 폴백으로 돌았다(stg·prod 모두). 컨테이너에서 연결+PING 은 7ms 라 네트워크 문제가 아니라 0.5 vCPU 에서 막 뜬 JVM 의 첫 핸드셰이크 지연이다. 워밍업 전에 PING 을 최대 5회(2·4·6·8초 간격) 시도하고, 실패 원인은 감싼 예외가 아니라 맨 안쪽 원인까지 남긴다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
draft() 가 @transactional 이라 시작 시점에 커넥션을 잡고 LLM 응답(수 초, 재시도·폴백 시 수십 초)까지 쥐고 있었다. 태스크 풀 15개 중 동시 AI 초안 수만큼이 묶인다. DB 작업은 등급 조회·초안 저장 둘뿐이라 각자 리포지토리 트랜잭션으로 충분하다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
같은 사용자의 sync 가 겹치면(재전송·백로그, 빈도 제한기가 태스크마다 메모리에 있어 두 태스크로 나뉘면 못 막는다) 세션 갱신·신호 INSERT IGNORE·판정 갱신을 하는 긴 트랜잭션이 서로의 잠금을 잡아 한쪽이 데드락으로 졌다 — 부하테스트 피크 5xx 11건 전부. 봉투 검증·빈도 제한은 한 번만 하고 트랜잭션 본문만 최대 3회 다시 돈다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
stg·prod 접속 주소(env)가 기본 주소를 통째로 덮어 rewriteBatchedStatements 가 빠져 있었다 — 신호 일괄 적재가 행마다 따로 나갔다. 프로파일에서 드라이버가 CPU 의 16% 였다. 문장 캐시·세션 상태 로컬 관리·autocommit 왕복 생략을 hikari.data-source-properties 로 둬 주소와 상관없이 적용한다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@scheduled 54개가 기본 스레드 1개를 나눠 써서 긴 작업 뒤에 다른 작업이 밀렸다. 밀린 cron 작업은 다른 태스크의 ShedLock 최소 잠금이 풀린 뒤에 시작해 같은 날 중복 실행됐다(00:40 일별 집계가 태스크 3대에서 각각 00:40·00:41·00:43). SCHEDULER_POOL_SIZE 로 조정한다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SDK 기본은 호출 시간 제한이 없어 SQS·S3 가 느려지면 요청(과 커넥션)이 끝없이 붙잡힌다. 알림 보내기 3초(소비자 롱폴링은 그대로), S3 15초(시도당 8초). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 고스트 푸시(1시간): joined_at 순으로 멤버 전체를 FOR UPDATE 로 훑어(REPEATABLE READ 라 훑은 행이 잠김) 그대로 FCM 을 최대 200건 보냈다. (status, setup_status, joined_at) 인덱스로 대상만 읽고, 푸시는 커밋 뒤에 보낸다. - 인기 점수 배치(5분)·일별 지표: 최근 24시간 가입 사건을 시각 범위로 세는데 시각 인덱스가 없어 누적 사건 전체를 훑었다 (느린 쿼리 로그: 3.3만 행, 부하 중 4초). (joined_at, challenge_id) 인덱스. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
DAU 2만 재측정용 — 홈·방 홈·랭킹·생성·가입·AI 초안 p95 목표, 저장·가입이 실제로 된 건수와 429/409 를 API·상태별로, steps(500→1000→1500→회복)·spike(30초에 3배), 한계점은 핵심 화면 p95 3초 초과로도 멈춤, 시드는 ROOM_EVERY 명 중 1명만 방 생성. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
초당 10건+10% 는 DAU 2만(평균 ~17 RPS)에서 월 ~2,700만 건 ≈ $135 로 ECS 비용보다 크다. 월 ~470만 건 ≈ $23. 분석용 표본으로는 충분하다(드문 오류·느린 요청은 로그·지표가 본다). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 인기 목록이 요청마다 인기 방 20곳의 ACTIVE 멤버를 모두 셌다(느린 쿼리 1위: 5,869행 × 678회/30분). 정원이 없거나 저장된 참여자 수가 정원보다 5 넘게 남은 방은 「마감 아님」이 확실하다 — 마감 근처 방만 원천에서 센다(가입은 여전히 잠금으로 판정). - 시작일 활성화·종료 완료 배치가 status+날짜 인덱스 없이 방 전체를 FOR UPDATE 로 훑어, 1분마다 모든 방 행이 잠겼다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
5분마다 공개 방 전부의 challenge_stats 를 UPDATE 해(부하테스트: 수천 행, 느린 쿼리 81건) 통계 재계산 잠금과 부딪혔다. 지금 저장된 값과 같이 읽어 달라진 방만 고른다. popularity_updated_at 을 읽는 곳은 없다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
findById 로 없음을 확인한 뒤 save() 가 merge 로 같은 PK 를 한 번 더 SELECT 했다. 가입 1건에 동의 5종 × 2 + 소셜 토큰 2 = 12 SELECT → 6. Persistable 로 새 행임을 알린다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
빨라질수록 같은 사용자의 sync 가 10초 간격에 걸려 성공 건수가 줄어드는데, 허용 상태라 어디에도 안 잡혔다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
꽉 찬 인기 방은 Top 20 에 오래 머물러 요청마다 그 방 멤버 전체를 셌다 (단계 시험 느린 쿼리 1위: 5,200행 × 10,483회). 저장값은 늦으면 실제보다 적으므로 그 값으로 이미 찼다면 지금도 찼다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
RDS 강제 장애조치(stg, 부하 중) 동안 요청이 커넥션을 30초씩 기다리다 500 으로 끝났다(55초간 수백 건). 커넥션 대기 상한을 5초로 줄이고(DB_CONNECTION_TIMEOUT_MS), 풀 대기 초과·연결 끊김은 503 으로 구분한다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
부하테스트 장애 주입(stg): Redis 재부팅으로 파생 인덱스가 비자, 새로 뜬 태스크가 30분짜리 재구성 잠금을 잡고 진행 중인 방 3.5만 개의 통계를 전부 다시 세다 RDS 장애조치에 걸려 사라졌다 — 탐색·인기 503 이 25분 넘게 이어졌다. - 재구성 잠금은 2분으로 잡고 도는 동안 30초마다 늘린다(주인일 때만). - 워밍업 재구성은 통계를 다시 세지 않고 지금 값으로 인덱스를 만든다. 통계는 MySQL 에 있어 Redis 유실과 무관하다. 대신 보정 기준 시각을 30분 앞에 남겨, 바로 이어지는 5분 보정이 유실 가능 구간만 증분으로 다시 센다. 전체 재계산은 03:30 대조가 그대로 맡는다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
방 3.5만 개의 HMGET 을 파이프라인 하나에 실으면 응답 전체가 Redis 명령 제한 시간(2초)을 넘겨 재구성이 통째로 실패했다(부하테스트 2026-10 Redis 재부팅 복구, stg). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
트레이스 감사(2026-10)에서 DB 왕복의 ~10% 가 SET SESSION TRANSACTION READ ONLY/READ WRITE 였다. RDS 가 다음 병목이고 비용도 가장 커서 왕복을 줄인다. 쓰기 막기는 JPA readOnly(flush 끔)가 계속 맡는다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
탐색 투영의 원천 리비전 MAX(m.updated_at) 과 5분 통계 보정 대상 고르기가 방의 멤버 전체를 훑었다 — 방 5만 개에서 전수 조회가 56만 행·최대 74초(부하테스트 2026-10, RDS CPU 포화 구간). (challenge_id, updated_at) 인덱스를 둔다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
급증(500→1,500명)에서 요청 스레드 200개가 커넥션 15개를 기다리며 쌓여 쓰기 API p95 가 50초를 넘었고 ALB 가 60초에 끊어 504 가 났다. 받을 수 있는 만큼만 받아 받은 요청은 제 속도로 끝낸다. APP_HTTP_MAX_INFLIGHT(0=끔)·APP_HTTP_INFLIGHT_WAIT_MS 로 켠다. 헬스체크는 관리 포트라 영향 없다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 기상 걸음 신뢰 출처가 삼성헬스·구글 피트니스 둘뿐이라, 그 앱이 없는 폰(Health Connect 플랫폼·기기 자체 걸음)은 매일 UNTRUSTED_ORIGIN 으로 빠져 늦잠이 됐다. 기상은 10걸음 문턱이라 출처를 넓힌다(손입력은 계속 뺀다). - 앱은 sync 마다 그날 걸음 기록을 다시 보내고 기록 앱은 같은 기록의 걸음 수를 키워 가며 고치는데, 기상·걸음 판정이 같은 기록 id 의 처음 값만 남겨 첫 sync 의 작은 값에 묶였다. 마지막에 받은 값을 쓴다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 같은 앱 안에서 화면을 옮기면 PAUSED(A)→RESUMED(B)→STOPPED(A) 순인데, 화면 구분이 없어 STOPPED(A) 가 B 세션을 닫아 사용 시간이 빠졌다(최소 사용형 오실패). 세션이 열린 직후(5초 안) STOPPED 는 앞 화면 것으로 본다. - 앱은 화면 꺼짐을 보내지 않아, 닫힘 없이 끊긴 세션이 창 끝(자정)까지 늘어 최대 사용형이 USAGE_EXCEEDED 로 잘못 실패했다. 창이 닫히면 열린 세션을 그 기기에서 마지막으로 받은 시각에서 닫는다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… 사용자 실행 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
가입부터 하면 가입 몰림이 풀 대기로 503 이 되어 정원 경합까지 가지 못했다(2차 J1: 300명 중 46명). HOT_USER_BASE(사용자 번호 시작)·START_DELAY_MS(setup 이 정한 공통 출발 시각). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
필터에서 난 예외는 GlobalExceptionHandler 를 거치지 않고 /error 로 가는데 거기엔 인증이 없어 401 LOGIN_REQUIRED 가 됐다. 부하테스트(2026-10 J2, 300명 동시 참여)에서 풀 대기 5초 초과 49건이 전부 401 로 나갔다 — 앱은 로그아웃 화면으로 간다. 컨트롤러 안과 같게 503 으로 맞춘다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
VU 하나가 사용자 한 명을 붙잡으면 그 사람 오늘 신호가 시험 내내 쌓여(2차 소크 뒤 ~160명이 하루 ~2,400건) sync 마다 전부 다시 판정하느라 요청당 CPU 가 1.7배가 됐다 — 실제 사용 패턴이 아니다. SYNC_POOL·SYNC_SALT. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-17 결정: 지금 prod 규모(CPU 평균 5%)에선 0.5 vCPU 를 유지하고, 지연·오류가 생기면 가장 먼저 CPU 를 올린다. 기본 실행은 헬스체크 관리 포트 분리·메모리 오토스케일 정책 삭제·X-Ray 규칙만 한다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
sync 가 신호를 저장할 때 보관 기간 전체 날짜 범위로 「이미 받은 기록인가」를 묻는데, 기존 인덱스 앞 칸이 날짜 범위라 사용자 신호 전체를 훑었다(2차 P0 재측정 느린 쿼리 4,358건/30분, 스레드 덤프 sync 3위). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2차 P0 재측정(최종 코드, sync 사용자 순환) 스레드 덤프 71회에서 일하던 요청 스레드의 72% 가 sync 였고 대부분 DB 대기였다. 상위는 방마다 하는 챌린지 PK 조회(1위)와 그날·이웃 날 신호 전체 읽기(2위). 챌린지는 IN 한 번으로 묶고, 신호는 sync 한 번 동안의 읽기 창에 두어 확정된 날(어제가 이미 끝난 멤버뿐이면 그저께 하루치)을 읽지 않는다. 판정 결과는 그대로다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fix: 기상·스크린타임 최대 사용형이 잘 인증되지 않던 서버 원인 4가지
perf: DAU 2만 부하테스트 — 처리량 1.55배·p95 6초→1.3초, 장애 전파 차단
This was referenced Oct 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
요약
dev → main(prod). 10/15 이후 dev 에만 있던 변경을 prod 로 낸다. 머지 전에 아래 「머지 전」 단계를 사용자가 직접 실행해야 한다(prod AWS 변경·온콜). 근거·결과는 노션 「부하테스트 및 성능개선」 맨 위 결과 보고와 9절.
포함 변경
머지 전 (사용자)
bash infra/capacity/restore_prod_image.sh(10/17 수명주기로ruleup-api:prod가 지워짐, main 3a05925 로 다시 빌드해 둠)python3 infra/capacity/apply_prod_dau2.py— 헬스체크 관리 포트 8081·메모리 정책 삭제·X-Ray 초당 1건+5%. CPU 는 그대로(10/17 결정, 문제 시--cpu 1024가 1순위)머지 후 확인
explore:rebuild_lock)이 남아 최대 30분 503 일 수 있다(stg 에서 재현). 길어지면 그 키만 지운다🤖 Generated with Claude Code