| 항목 |
애플리케이션 변경 |
인프라 구성 변경
|
- 1. 느린 쿼리 및 DB 테이블 확인 ★★★
- 가능한 경우, 실행계획까지 확인하면 더욱 좋다. (쿼리 내부에서 어디가 병목인지 확인)
- 쓰기가 느린가? 읽기가 느린가?
- 인덱스(PK, UNIQUE, INDEX)가 적절히 설정되었는가?
- JOIN 관계는 적절한가?
- 불필요하게 많은 테이블을 JOIN하고 있지는 않은가?
- FULL JOIN을 LEFT JOIN으로 바꿔볼 수는 없는가?
- 너무 많은 컬럼/행
- 테이블에 너무 많은 컬럼이 있는 것은 아닌가?
- 너무 많은 컬럼을 SELECT 하고 있는 것은 아닌가?
- 너무 많은 행을 가진 테이블은 없는가?
- 여러 테이블/DB로 분산해보면 어떨까? 예: 샤딩
- 자주 조회되는 간단한 요약 정보가 있다면 요약 테이블을 따로 만들어보면 어떨까?
- 게으른 처리
- 실시간 갱신이 필요한 것이 아니라면, 다른 곳에 쌓아놨다가 야간(어쨌든 바쁘지 않은 시간)에 처리할 수는 없을까?
- N+1 문제?
- 혹시 ORM을 사용한다면 N+1 문제가 없는지 살펴보자.
|
3️⃣
|
0️⃣
|
- 2. DB 상태 확인 및 튜닝
- DB 상태를 확인하고 설정(DB 파라미터)이 적절한지 검토한다.
- 적절한 크기의 DB 캐시 설정은 매우 중요하다.
- OS의 메모리 크기와, DB에 할당한 메모리의 크기, DB 캐시의 크기는 적절한가?
- 필요시 advisory 도구를 활용해볼 수도 있다.
|
0️⃣
|
0️⃣
|
- 3. DB 구성 확인 및 개선
- 수평 확장 - 1대라면 Replication이나 Clustering 구성으로 2~3대로 늘려보면 어떨까?
- 수직 확장 - CPU나 메모리 사용률이 높다면 해당 리소스를 높여보면 어떨까?
|
수평 확장(1️⃣~2️⃣)
수직 확장 0️⃣
|
수평 확장(3️⃣)
수직 확장 0️⃣
|
- 4. DB 캐시 구성
- Redis/Memcached 등으로 캐시를 적용해보면 어떨까?
- 자주 조회되지만 변경은 별로 없고, 쿼리 결과물의 크기는 큰 경우(특히 여러 테이블 JOIN), 효과가 좋을 수 있다.
|
1️⃣~2️⃣
|
1️⃣
|
- 5. 기타
- 어쨌거나 앞단에서 DB Hit를 줄일 수 없는가?
- DB 내용 중 일부를 다른 DB, object storage로 분산
- webcache 도입 (애플리케이션 특성에 따라 DB Hit 줄이는 효과가 별로 없을 수도 있다.)
- 다른 DB 추가 도입
- 특정 컬럼에 매우 긴 글(text)가 있고, 부분문자열 검색(LIKE %%)을 자주 하는 경우하는 경우 → 해당 테이블을 Elasticsearch에 복제하여 검색하는 방법 검토
|
1️⃣
|
2️⃣
|
