Api::V1::IssuesController#create (avg 2481ms, max 2615ms)
Fix Plan: Api::V1::IssuesController#create Latency
Changes#
cupixworks: applications/issue-service/src/lambda/issue/create.ts#
- What:
getIssueWithFullInfo()호출을 제거하고, 방금 write한 데이터 +findIssueType()에서 이미 조회한issueType객체를 in-memory로 조합하여 응답 구성. notification 호출을Promise.all()로 병렬화. - Why: write-then-read anti-pattern으로 DynamoDB 3회 불필요한 재조회(~60-90ms), 순차 Lambda Invoke await(~200-1000ms) 제거
- Lines: 98-111 — try 블록 내부 로직 변경
cupixworks: applications/issue-service/src/common/lambda-helper.ts#
- What:
LambdaClient를 모듈 스코프 singleton으로 변경. 각 함수에서 매번new LambdaClient()생성하던 것을 공유 인스턴스로 교체. - Why: warm start 시 connection 재사용으로 Lambda Invoke API 호출 latency 절감
- Lines: 1-28 — 모듈 상단에 singleton 선언, 함수 내부 client 생성 제거
cupixworks: applications/issue-service/src/common/config.ts#
- What: 모듈 스코프에 singleton
DynamoDBClient인스턴스 export 추가 - Why:
create.ts와findIssueType()에서 매번new DynamoDBClient(dynamoDBClientConfig)생성하는 것을 단일 인스턴스로 교체 - Lines: 5-7 — config 하단에 client instance export
cupixworks: applications/issue-service/src/common/dynamodb-helper.ts#
- What:
getIssueWithFullInfoexport는 유지하되, create handler에서 더 이상 호출하지 않음 (다른 Lambda handler에서 사용 가능성).getIssueTypById,getIssueTypByErrorCode함수의 client 파라미터는 유지 (singleton을 caller가 전달). - Why: 기존 API 호환성 유지하면서 create 경로의 불필요한 read-back 제거
- Lines: 변경 없음 (이 파일 자체는 수정하지 않음)
Acceptance Criteria#
-
create.ts에서getIssueWithFullInfoimport 및 호출이 제거됨 -
create.ts에서 응답 객체가 in-memory로 구성됨 (issueType 데이터 포함) - notification 호출이
Promise.all()로 병렬 실행됨 -
LambdaClient가lambda-helper.ts모듈 스코프 singleton으로 선언됨 -
DynamoDBClient가config.ts에서 singleton으로 export되어create.ts와findIssueType()에서 재사용됨 - 기존 error handling (try-catch) 구조 유지
-
issue.issue_type.error_code?.startsWith("AGT")조건 분기가 정상 동작
Tests#
- 기존 테스트:
applications/issue-service/src/code에 npm test 실행 - 신규 테스트: 없음 (기존 동작 유지, 성능 최적화만)