WAS 튜닝, 쿼리 성능 튜닝

✅ WAS 튜닝

 

🔸 튜닝 목적

• 처리 속도 향상, 동시 사용자 처리, 장애 방지

🔸 튜닝 종류

JVM 튜닝	- Heap Size 설정 - GC 방식 선택 (G1, ZGC) - 메모리 Leak 방지
Thread Pool	- 최대/최소 Thread 설정 - 동시 요청 처리 최적화
Connection Pool (DB)	- 최소/최대 커넥션 수 설정 - Idle 커넥션 관리
Timeout 설정	- 세션 타임아웃 - DB 커넥션 타임아웃 - Socket Timeout 설정
GC 튜닝	- Full GC 발생 최소화 - Old/Young 영역 비율 조정
로깅 최적화	- 필요 없는 Debug 로그 OFF - 로그 레벨 최적화
WAS 자체 설정	- Tomcat: maxThreads, acceptCount - WebLogic, JBoss 유사

 

🔸 주요 툴

• Whatap, Pinpoint → 애플리케이션 성능 모니터링 (APM)
• VisualVM, JConsole → JVM 상태 확인
• Kibana, Grafana → 로그 및 메트릭 시각화
• WAS 자체 로그 → catalina.out (Tomcat)

🔸 튜닝 과정

1. APM(Whatap)에서 응답 지연 발생 확인

2. Thread Dump → 스레드 대기 상태, Deadlock 확인

3. GC 로그 분석 → Full GC 빈도, 메모리 부족 여부 확인

4. 커넥션 풀 상태 확인 → Connection Leak 탐색

5. 로그량 과다 → I/O 병목 여부 확인
6. JVM 힙 메모리, Thread Pool 사이즈 조정

7. 배포 → 성능 테스트 → 적용

 

 

✅ 대용량 데이터 쿼리 튜닝

 

🔸 튜닝 목적

• 대량 조회, 집계, 배치 시 속도 향상 + Lock 최소화 + 부하 분산

🔸 튜닝 종류

인덱스 최적화	- 적절한 Index 추가 - 불필요한 Index 삭제
쿼리 구조 개선	- 서브쿼리 → JOIN 변환 - EXISTS 사용 - IN 최소화
데이터 분할	- 파티셔닝 (Range, List) - 테이블 샤딩
Batch 처리 최적화	- Commit 단위 조정 - Bulk Insert / Update
쿼리 힌트 활용	- /*+ INDEX /, /+ PARALLEL */ 등
통계 최신화	- DB 통계 정보 갱신으로 옵티마이저 정확도 향상
Materialized View 활용	- 복잡한 집계 결과를 미리 저장해서 빠른 조회

 

🔸 주요 툴

• SQL Developer (Oracle)
• pgAdmin (PostgreSQL)
• AWR, ASH (Oracle)
• SQL Plan + Explain Plan
• DBeaver, DataGrip (다중 DB 지원)

🔸 튜닝 흐름 

1. SQL 실행 계획 확인 (EXPLAIN PLAN)

2. Full Scan 발생 → 인덱스 존재 여부 확인

3. 인덱스 추가 → 성능 개선 확인

4. 서브쿼리/IN → JOIN/EXISTS로 변경

5. 데이터가 많은 테이블 → 파티셔닝 적용

6. 쿼리 실행 시간 개선 확인

 

 

★★★	병목 찾기	어디서 느린지 명확히 파악해야
★★	Thread/Connection 최적화	동시 사용자 처리에 핵심
★★★	쿼리 튜닝	대부분의 성능 이슈는 SQL 문제
★★	GC 튜닝	메모리 누수, Full GC 예방
★★★	배치 성능 개선	금융권은 대용량 배치 매우 중요

 

 

"실제 금융권에서 대용량 배치나 실시간 API 성능 이슈는 주로 SQL 튜닝과 Thread Pool, Connection Pool 설정으로 해결했습니다. APM으로 병목 구간을 파악하고, WAS 튜닝은 JVM Heap, GC 로그 분석으로 메모리 누수를 방지했습니다. 또한, SQL은 Explain Plan으로 Full Scan 여부를 확인하고 인덱스 최적화, 파티셔닝 적용 등으로 성능을 개선했습니다."

 

 

 

---

✅  ERD(Entity Relationship Diagram) 설계 접근법

 

🔸 개념

• ERD는 데이터베이스 내 엔티티(테이블)와 그 관계를 시각적으로 표현한 다이어그램입니다.
• 시스템의 데이터 구조와 비즈니스 규칙을 명확하게 설계하는 첫 단계

🔸 설계 접근법

• 요구사항 분석: 업무 프로세스와 도메인 용어, 엔티티를 파악
• 주요 엔티티 도출: 핵심 객체(예: 고객, 상품, 거래 등) 정의
• 속성 결정: 각 엔티티에 필요한 컬럼과 데이터 타입 설계
• 관계 설정: 1:1, 1:N, N:M 관계를 명확히 하여 외래키(FK)로 연결
• 정규화 수행: 데이터 중복 방지 및 무결성 유지 위해 3NF 이상 권장
• 비즈니스 규칙 반영: 제약조건(Unique, Not Null, Check 등) 설정
• 실무 협업 고려: 팀과 공유, 변경 관리 용이하도록 문서화

---

✅ 쿼리 튜닝 기본 

🔸 주요 내용

• 인덱스 최적화: 적절한 컬럼에 인덱스 생성, 불필요한 인덱스 제거
• 조인 최적화: 조인 순서 조절, 불필요한 조인 제거
• 쿼리 작성법 개선: 서브쿼리 대신 조인 사용, 불필요한 컬럼 조회 줄이기
• 실행계획 확인: EXPLAIN PLAN 등을 통해 병목 구간 파악
• 통계정보 최신화: 옵티마이저가 올바른 실행계획 세우도록 유지
• 파티셔닝 고려: 대용량 테이블은 파티셔닝으로 처리 성능 향상

🔸 금융권 특화 포인트

• 대용량 데이터 처리: 거래 기록, 로그 등 방대한 데이터에 최적화 필수
• 실시간 처리 및 응답속도 중요: 고객 거래에 영향 미치므로 튜닝 엄격 적용
• 보안 제약조건: 민감정보 컬럼에 암호화 적용 시 성능 저하 고려
• 트랜잭션 격리 수준과 락 경합 최소화: 다중 사용자 환경에 맞춘 최적화 필요

🔸 주의할 점

• 인덱스 과다 생성 시 쓰기 성능 저하 주의
• 쿼리 튜닝 후에도 테스트 환경과 운영 환경 성능 차이 검증 필수
• 데이터 모델 변경 시 기존 쿼리 영향 고려
• 비즈니스 요구사항 변경에 따른 ERD 및 쿼리 유연성 확보

 

“ERD 설계 시에는 우선 비즈니스 요구사항을 명확히 분석하고, 주요 엔티티와 관계를 도출하는 데 집중합니다. 정규화를 통해 데이터 중복과 무결성을 유지하고, 제약조건을 통해 업무 규칙을 강제합니다. 쿼리 튜닝은 인덱스 최적화와 실행계획 분석을 기본으로 하며, 특히 금융권에서는 대용량 데이터 처리와 실시간 응답 속도에 맞춰 최적화하는 것이 중요합니다. 저는 경력 2년 동안 PostgreSQL과 Oracle에서 이러한 쿼리 튜닝 경험을 쌓으며 운영 환경에서 성능 향상을 이뤄낸 바 있습니다.”