1017 ~ 1030

# 1017 ~ 1030

# 1018 - MySQL Explain 실행계획 사용법 및 분석

# MySQL Explain란?

MySQL 튜닝에서 가장 중요한 것은 쿼리와 스키마 최적화이다. 스키마 설꼐는 한번 진행되면 그 테이블을 사용하는 모든 쿼리에 영향을 주기 때문에 좀처럼 변경하기 힘들지만 쿼리는 해당 쿼리만 수정하면 되므로 변경하기 쉽다. Slow Query를 없애는 것은 성능을 향상 시키기 위한 매우 중요한 수단이므로 어플리케이션의 성능을 향상시키고 싶다면 우선적으로 쿼리의 튜닝을 컴토해봐야 한다.

성능 진단의 가장 첫걸음은 실행한 SQL이 DB에서 어떻게 처리되는지를 파악하는 것이다. 사람이 이해할 수 있는 언어로 구성된 SQL을 실행하도록 DB에 명령을 내리면 DB는 내부적으로 SQL 파싱(문법 체크 및 DB에서 실행하기 위한 형태로 변환하는 단계)을 하고 옵티마이징(데이터를 찾는 가장 빠른 방법을 찾아내는 단계)을 거친 후 실제로 데이터를 찾는다. 사용자가 느끼기에는 SQL만으로 모든 조작이 이루어지는 것처럼 보이나 실제로는 조금이라도 빠르게 데이터를 찾아내기 위해 DB 내부적으로는 의외로 많은 단계를 거친다.

MySQL Explain 이란 DB가 데이터를 찾아가는 일련의 과정을 사람이 알아보기 쉽게 DB 결과 셋으로 보여주는것이다. MySQL Explain을 활용하여 기존의 쿼리를 튜닝할 수 있을 뿐만 아니라 성능 분석, 인덱스 전략 수립 등과 같이 성능 최적화에 대한 전반적인 업무를 처리할 수 있다.

# MySQL Explain 사용방법

EXPLAIN [EXTENDED] SELECT ... FROM ... WHERE ...

# MySQL Explain 결과의 각 항목 별 의미

id : select 아이디로 SELECT를 구분하는 번호
table : 참조하는 테이블
select_type : select에 대한 타입
type : 조인 혹은 조회 타입
possible_keys : 데이터를 조회할 때 DB에서 사용할 수 있는 인덱스 리스트
key : 실제로 사용할 인덱스
key_len : 실제로 사용할 인덱스의 길이
ref : Key 안의 인덱스와 비교하는 컬럼(상수)
rows : 쿼리 실행 시 조사하는 행 수립
extra : 추가 정보

# [ id ]

행이 어떤 SELECT 구문을 나타내는 지를 알려주는 것으로 구문에 서브 쿼리나 UNION이 없다면 SELECT는 하나밖에 없기 때문에 모든 행에 대해 1이란 값이 부여되지만 이외의 경우에는 원 구문에서 순서에 따라 각 SELECT 구문들에 순차적으로 번호가 부여된다.

# [ table ]

행이 어떤 테이블에 접근하는 지를 보여주는 것으로 대부분의 경우 테이블 이름이나 SQL에서 지정된 별명 같은 값을 나타낸다.

# [ select_type ]

SIMPLE : 단순 SELECT (Union이나 Sub Query가 없는 SELECT 문)
PRIMARY : Sub Query를 사용할 경우 Sub Query의 외부에 있는 쿼리(첫번째 쿼리) UNION을 사용할 경우 UNION의 첫 번째 SELECT 쿼리
UNION : UNION 쿼리에서 Primary를 제외한 나머지 SELECT
DEPENDENT_UNION : UNION과 동일하나, 외부쿼리에 의존적임 (값을 공급 받음)
UNION_RESULT : UNION 쿼리의 결과물
SUBQUERY : Sub Query 또는 Sub Query를 구성하는 여러 쿼리 중 첫번째 SELECT문
DEPENDENT_SUBQUERY : Sub Query와 동일하나, 외곽쿼리에 의존적임 (값을 공급 받음)
DERIVED : SELECT로 추출된 테이블 (FROM 절 에서의 서브쿼리 또는 Inline View)
UNCACHEABLE SUBQUERY : Sub Query와 동일하지만 공급되는 모든 값에 대해 Sub Query를 재처리. 외부쿼리에서 공급되는 값이 동이라더라도 Cache된 결과를 사용할 수 없음.
UNCACHEABLE UNION : UNION과 동일하지만 공급되는 모든 값에 대하여 UNION 쿼리를 재처리

# [ TYPE ]

system : 테이블에 단 한개의 데이터만 있는 경우
const : SELECT에서 Primary Key 혹은 Unique Key를 살수로 조회하는 경우로 많아야 한 건의 데이터만 있음
eq_ref : 조인을 할 때 Primary Key
ref : 조인을 할 때 Primary Key 혹은 Unique Key가 아닌 Key로 매칭하는 경우
ref_or_null : ref와 같지만 null이 추가되어 검색되는 경우
index_merge : 두 개의 인덱스가 병합되어 검색이 이루어지는 경우
unique_subquery : 다음과 같이 IN 절 안의 서브쿼리에서 Primary Key가 오는 특수한 경우

SELECT *  
FROM tab01  
WHERE col01 IN (SELECT Primary Key FROM tab01);

index_subquery : unique_subquery와 비슷하나 Primary Key가 아닌 인덱스인 경우

SELECT *  
FROM tab01  
WHERE col01 IN (SELECT key01 FROM tab02);

range : 특정 범위 내에서 인덱스를 사용하여 원하는 데이터를 추출하는 경우로, 데이터가 방대하지 않다면 단순 SELECT에서는 나쁘지 않음
index : 인덱스를 처음부터 끝까지 찾아서 검색하는 경우로, 일반적으로 인덱스 풀스캔이라고 함
all : 테이블을 처음부터 끝까지 검색하는 경우로, 일반적으로 테이블 풀스캔이라고 함

# [ possible_keys ]

쿼리에서 접근하는 컬럼들과 사용된 비교 연산자들을 바탕으로 인덱스를 사용할 수 있는지를 표시해준다.

# [ key ]

테이블에 접근하는 방법을 최적화 하기 위해 어떤 인덱스를 사용하기로 결정했는지를 나타낸다.

# [ key_len ]

MySQL이 인덱스에 얼마나 많은 바이트를 사용하고 있는지를 보여준다. MySQL에서 인덱스에 있는 컬럼들 중 일부만 사용한다면 이 값을 통해 어떤 컬럼들이 사용되는 지를 계산할 수 있다.

# [ ref ]

키 컬럼에 나와 있는 인덱스에서 값을 찾기 위해 선행 테이블의 어떤 컬럼이 사용되었는지를 나타낸다.

# [ rows ]

원하는 행을 찾기 위해 얼마나 많은 행을 읽어야 할 지에 대해 예측값을 의미한다.

# [ extra ]

using index : 커버링 인덱스라고 하며 인덱스 자료 구조를 이용해서 데이터를 추출
using where : where 조건으로 데이터를 추출. type이 ALL 혹은 Index 타입과 함께 표현되면 성능이 좋지 않다는 의미
using filesort : 데이터 정렬이 필요한 경우로 메모리 혹은 디스크상에서의 정렬을 모두 포함. 결과 데이터가 많은 경우 성능에 직접적인 영향을 줌
using temporary : 쿼리 처리 시 내부적으로 temporary table이 사용되는 경우를 의미함

MySQL Explain 상 일반적으로 데이터가 많은 경우 Using Filesort 와 Using Temporary 상태는 좋지 않으며 쿼리 튜닝 후 모니터링이 필요하다.

# 1026 - @Transactional 동작원리

트랜잭션 처리를 위한 @Transactional 애노테이션은 Spring AOP의 대표적인 예이다. @Transactional 역시 Proxy 형태로 동작한다. (Spring은 JDK Proxy, Spring Boot는 CGLib Proxy를 기본으로 하기 때문에, 사용하는 것에 따라 생성된 프록시 객체 형태는 다를 수 있다.)

@Transactional은 AOP를 사용하여 구현된다. transaction의 begin과 commit을 메인 로직 앞 뒤로 수행주는 기능을 담당한다. @Transactional가 붙은 메소드가 호출되기전 begin을 호출하고, 메서드가 종료되고 commit을 호출한다. 이 때 Spring AOP는 기본적으로 PROXY 패턴을 사용한다.

@Transactional 애노테이션을 발견하면 그 빈의 다이나믹 프록시를 생성.
그 프록시 객체는 트랜잭션 매니저에 접근하고 트랜잭션이나 커넥션을 열고 닫도로 요청
트랜잭션 매니저는 JDBC 방식으로 코드를 실행

# 1027 - @Transactional 전파 레벨 정리

@Transactional을 클래스 또는 메소드 레벨에 명시하면 해당 메소드 호출시 지정된 트랜잭션이 작동하게 된다. 단, 조건이 있다. 해당 클래스의 Bean을 다른 클래스의 Bean에서 호출할 때만 @Transactional을 인지하고 작동하게 된다. (같은 빈 내에서 @Transactional이 명시된 다른 메소드를 호출해도 작동하지 않는다.) Spring Framework는 내부적으로 AOP를 통해 해당 어노테이션을 인지하여 프록시를 생성하여 트랜잭션을 자동 관리하기 때문이다.

# 전파레벨(Propagation)

***[ Propagation.REQUIRED(기본 값) ]

@Transactional(propagation = Propagation.REQUIRED)
public void doSomething() { ... }

특정 메소드의 트랜잭션이 Propagation.REQUIRED로 설정되었을 때의 트랜잭션 동작은 다음과 같다. 기본적으로 해당 메소드를 호출한 곳에서 별도의 트랜잭션이 설정되어 있지 않았다면 트랜잭션을 새로 시작한다.(새로운 연결을 생성하고 실행한다.) 만약, 호출한 곳에서 이미 트랜잭션이 설정되어 있다면 기존의 트랜잭션 내에서 로직을 실행한다.(동일한 연결 안에서 실행된다.) 예외가 발생하면 롤백이 되고 호출한 곳에도 롤백이 전파된다. 이러한 REQUIRED 동작 방식을 원할 경우 기본값으로 설정되어 있기 떄문에 생략가능하다.
만약, 해당 메소드가 호출한 곳과 별도의 쓰레드라면 전파 레벨과 상관없이 무조건 별도의 트랜잭션을 생성하여 해당 메소드를 실행한다. Spring은 내부적으로 트랜잭션 정보를 ThreadLocal 변수에 저장하기 때문에 다른 쓰레드로 트랜잭션이 전파되지 않는다.

***[ Propagation.REQUIRES_NEW ]

@Transactional(propagation = Propagation.REQUIRES_NEW) 
public void doSomething() { ... }

Propagation.REQUIRES_NEW로 설정되었을 때에는 매번 새로운 트랜잭션을 시작한다. (새로운 연결을 생성하고 실행한다.) 만약, 호출한 곳에서 이미 트랜잭션이 설정되어 있다면(기존의 연결이 존재한다면) 기존의 트랜잭션은 메소드가 종료할 때까지 잠시 대기 상태로 두고 자신의 트랜잭션을 실행한다. 새로운 트랜잭션 안에서 예외가 발생해도 호출한 곳에는 롤백이 전파되지 않는다. 즉, 2개의 트랜잭션은 완전히 독립적인 별개의 단위로 작동한다.

***[ Propagaion.NESTED ]

@Transactional(propagation = Propagation.NESTED) 
public void doSomething() { ... }

Propagation.NESTED는 기본적으로 앞서 설명한 Propagation.REQUIRED와 동일하게 작동한다. 중요한 차이점은, SAVEPOINT를 지정한 시점까지 부분 롤백이 가능하다. 유의할 점은, 데이터베이스가 SAVEPOINT 기능을 지원해야 사용이 가능하다.

# 1028 - AOP(Aspect Oriented Progamming)

관점 지향 프로그래밍 : 객체를 핵심관심과 횡단관심으로 구분하여 처리하는 프로그래밍 기법

핵심 기능(Core Concerns, Primary Concerns): 핵심 업무 로직을 수행하는 기능
부가 기능(Cross-cutting Concerns): 핵심 기능을 도와주는 부가적인 기능(로깅, 보안 등)

[ 용어 ]

Joinpoing
- 메소드를 호출하는 '시점', 예외가 발생하는 '시점'과 같이 애플리케이션을 실행할 때 특정 작업이 실행되는 '시점'을 의미
Advice
- joinpoint에서 실행되어야 하는 코드
- 횡단관점에 해당함(트랜잭션/로그/보안/인증 등)
Target
- 실질적인 비즈니스 로직을 구현하고 있는 코드
- 핵심관점에 해당함(업무로직)
Pointcut
- Target 클래스와 Advice가 결합(Weaving) 될 때 둘 사이의 결합규칙을 정의하는 것이다.
- 예로 Advice가 실행된 Target의 특정 메소드등을 지정
Aspect
- Advice와 Pointcut을 합쳐서 하나의 Aspect라고 한다.
- 즉 일정한 패턴을 가지는 클래스에 Advice를 적용하도록 지원할 수 있는 것을 Aspect라고 한다.
Weaving
- AOP에서 Joinpoint들을 Advice로 감싸는 과정을 Weaving이라고 한다.
- Weaving 하는 작업을 도와주는 것이 AOP툴이 하는 역할이다.

# 1029 - Spring AOP Weaving

# Weaving 이란?

Weaving은 Pointcut에 의해서 결정된 타겟의 Join Point에 부가기능(Advice)를 삽입하는 과정을 뜻한다.
Weaving은 AOP가 핵심기능(타겟)의 코드에 영향을 주지 않으면서 필요한 부가기능(어드바이스)를 추가할 수 있도록 해주는 핵심적인 처리과정이다.

Pointcut : 어드바이스를 적용할 타겟의 메서드를 선별하는 정규표현식이다.

Advice : 어드바이스는 타겟에 제공할 부가기능을 담고 있는 모듈이다.

Join Point : 어드바이스가 적용될 수 있는 위치를 말한다.

# Weaving의 종류

[ Compile Time Weaving(CTW) ]

AspectJ에는 AJC(AspectJ Compiler)라는 컴파일러가 있는데 Java Compiler를 확장한 형태의 컴파일러이다.
AJC를 통해 java파일을 컴파일 하며, 컴파일 과정에서 바이트 코드 조작을 통해 Advisor 코드를 직접 삽입하여 위빙을 수행한다.
장점으로는 3가지 위빙 중에서는 가장 빠른 퍼포먼스를 보여준다. 하지만 컴파일 과정에서 lombok과 같이 컴파일 과정에서 코드를 조작하는 플러그인과 충돌이 발생할 가능성이 아주 높다.(거의 같이 사용 불가)

[ Runtime Weaving(RTW) ]

Spring AOP에서 사용하는 방식으로, Proxy를 생성해 실제 타깃 오브젝트의 변형없이 위빙을 수행한다.
실제 런타임시 Method 호출 시에 위빙이 이루어지는 방식이다.
소스파일, 클래스 파일에 변형이 없다는 장점이 있지만, Point Cut에 대한 Advice 수가 늘어날수록 성능이 떨어진다는 단점이 있다.

[ Load Time Weaving(LTW) ]

ClassLoader를 이용해 클래스가 JVM에 로드될 때 바이트 코드 조작을 통해 위빙되는 방식으로 컴파일 시간은 상대적으로 CTW보다 짧다. 하지만 오브젝트가 메모리에 올라가는 과정에서 위빙이 일어나기 때문에 런타임시 시간은 CTW보다 상대적으로 느리다.
Application Context에 객체가 로드될 때, 객체 핸들링이 발생하므로 퍼포먼스가 저하된다.

[ Post-Compile Weaving ]

컴파일 후 기존 클래스 파일과 JAR파일을 위빙하는데 사용, Compile Time Weavng 같은 방식으로 처리한다.

# Spring AOP와 AspectJ

AspectJ가 Compile 시점과 Load 시점 Weaving을 사용.
Spring AOP는 RunTime Weaving을 사용.
Spring AOP보다 AspectJ가 속도와 기능적인 측면에 조금 좋은 성능을 보이지만 바이트 코드 조작을 위해 JVM의 실행 옵션을 변경하거나, 별도의 바이트코드 컴파일러를 사용 등에 번거로운 작업이 따르므로 Spring AOP 사용 후 그 이상의 기능이 필요한 경우 AspectJ를 확장해서 사용하는 것을 추천한다.

# 1030 - Spring AOP와 AspectJ 비교

[ Spring AOP ]

순수 Java로만으로도 구현됨
복잡한 과정이 필요 없음
런타임 Weaving만 가능함
메서드 레벨의 Weaving만 지원함
Spring Container에 의해 관리되는 빈즈에만 적요할 수 있음
메서드 실행 Point cut만 지원함
대상 객체의 Proxy가 생성되고 Aspect는 이러한 Proxy를 대상으로 적용됨
AspectJ에 비해 훨씬 느리다
배우고 적용하기 쉽다

[ AspectJ ]

추가 도구(자바 프로그램)를 통해 구현됨
로드 시즘 Weaving을 사용하더라도 AspectJ compiler(ajc)가 필요하다
런타임 Weaving이 불가능함. 컴파일 시점/컴파일 전/로드 시점 Weaving을 지원함
필드, 메서드, 생성자, final클래스/메서드 등 다양하게 지원함
모든 객체를 대상으로 적용 가능함
모든 Pint cut을 지원함
Aspect는 애플리케이션이 실행되기 전에 코드에 바로 Weaving됨(런타임 이전)
Spring AOP에 비해 좋은 성능
Spring AOP에 비해 복잡하다

1010 ~ 1016 1031 ~ 1113