폐관코딩

이걸 카카오 cdn에 저장하는건가?

닥치고개돌 — Fri, 22 Nov 2024 14:24:02 +0900

plugins.bundle.min.js

2.16MB

이걸 카카오 cdn에 저장하는건가?

[TDD한걸음] 2편 따라하면 바로 완성되는 TDD

닥치고개돌 — Tue, 26 Mar 2024 18:56:03 +0900

(comming soon)

HttpStatus 잘 사용하는법

닥치고개돌 — Thu, 21 Mar 2024 11:48:12 +0900

RestAPI 요청을 하면 HTTP status와 함게 응답을 내려준다.
이 글은 요청에 대한 값이 없을때 http status가 200인가,400인가 ,404인가에 대한 고민을 하다가 찾아본 결과를 정리하는 글이다.

Resources와 representation의 차이

먼저 RFC에서 404 Not Found에 대한 정의를 보자

[https://tools.ietf.org/html/rfc7231#section-6.5.4](https://tools.ietf.org/html/rfc7231#section-6.5.4)The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not    willing to disclose that one exists. A 404 status code does not    indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.   
A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see  
 [Section 4.2.2 of [RFC7234]](https://datatracker.ietf.org/doc/html/rfc7234#section-4.2.2)).

요청한 리소스가 없을 때 가리킨다. 더 정확히는 요청한 리소스에 대한 현재 representation 을 찾을 수 없을 때 사용한다고 한다. 간단하게 설명하면 해당 링크가 존재하지 않는다는 뜻

여기서 resource와 representation을 구분해보자

GET 메서드의 정의는 다음과 같다.

The GET method requests transfer of a current selected representation
for the target resource.

즉, target resource에 대한 현재의 선택된 representation 하나를 반환한다.

위 정의에서 “target resource”란 https://example.org/greeting 라는 uri가 가리키는 리소스, 바로 HTTP 요청의 대상이다.

그럼 “현재의 선택된 representation”이란 무엇인가? 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보이다. 하나의 representation은 representation data와 representation metadata로 구성된다.

위의 리소스에서 hello라는 응답이 왔으면 “hello”가 representation data이고, “Content-Type: text/plain”과 “Content-Language: en”이 representation metadata이다.

쉽게말해 resource는 요청한 uri, representation은 리소스에 대한 리턴값이라고 생각하면된다. 즉 성공시 리턴값, 실패시 에러메시지 또한 representation이다.
-> 사실 깊게 들어가면 http메시지의 payload로 전달되는 모든 것도 하나의 representation이지만 여기선 httpstatus에 대한 주제를 다룸으로 리턴값으로만 한정. 자세한 내용은 (https://blog.npcode.com/2017/04/03/rest%EC%9D%98-representation%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80/)

더 자세히 정리하고 싶었지만 계속된 조사결과 해당 문제는 필수가 아닌 개발 규칙에 맞게 적용하면 되는것 같다.
실제로 많은 회사들이 자신들만의 규칙을 정해놓고 사용중이었다.

그래서 조사한 결과를 바탕으로 결로만 정리해보면

GET /users/{userId} : 조회한 userId가 없을경우 404
-> 위에 첨부된 404 내용을 보면 리소스가 존재하고, 그에대한 응답(에러메시지)도 존재함으로 404가 적합함

GET /usersff/{userId} : 해당 리소스가 없음으로 404

GET /users?name='test' : 검색한 name이 없을경우 200
-> /users란 리소스는 존재, representation도 빈값으로 존재

POST /users/login : 로그인 요청시 페이로드가 잘못된경우 ??
-> 가장 논란이 많은부분. 계정이 없는경우 400, 404, 200 등 다양한 의견이 있다.
내용을 들어보면 모두 그럴듯함. 400은 로그인은 이미 존재하는 계정이라는 전제하에 시도하는데 없는 계정을 요청했다면 요청자체가 잘못이라 400이다, 없는 계정요청이니 404다, 요청은 성공했고 로그인에 대한 예외상태를 상세히 나누면 해커들의 먹이가되기에 200으로 하고 로그인 실패만 나타낸다 등.
고민하고 회사에 맞게 잘 사용하면 될듯

나머지 부분은 논란의 여지가 크지않아 명세에 맞게 잘 사용하면 될듯!

과제테스트 회고

닥치고개돌 — Tue, 19 Mar 2024 13:23:02 +0900

과제 테스트를 끝냈다.
기간은 일주일이 주어졌지만 실질적으로 작업 한 시간은 주말 2틀정도?
왜 하필 그 전주에는 해외여행다녀와서 여독이 있었으며, 업무는 왜 또 많았고, 술자리도 많았을까? 머피의 법칙 같은걸까?(머피 rosha...)
핑계는 이정도하고 잘한 점, 잘못한 점, 아쉬웠던 점, 앞으로 점점 발전할 점에 대한 회고를 기록하려 한다.
다른 사람이 과제 테스트를 진행하기 전에 이 글을 보면 도움이 될 수 있도록 상세히...

잘한 점

뭐가 있으려나? 있긴하려나
굳이 생각해보자면, 과제테스트를 시도했던 점? 뭔가 결과를 내기위해 몰입했던 점?, 실제로 TDD로 구현했던 점? 좋은 코드를 짜기위해 고민했던 점?
생각해보니 많은데 전부 잘 한 부분이면서 못한 부분인 아이러니한 상황
먼저, 과제테스트를 시도했던점은 제일 잘 한 부분인것같다. 밑에서 적겠지만 이번 과제테스트로 굉장히 많이 배우고, 성장한게 느껴졌다. 일단 부딪혀봐야 깨지고 성장한다는 말이 뭔지 느낄 수 있었다.

이 세계 벽 절대 안 높아. 할 수 있어!
남자는 뭐? 자신감! 자신감! 남자는 뭐? 자신감이야.
일단 붙어봐야 될 것 아니야. 저질러보고. 깨지고, 박어.
가슴만 뛰는 개발자 아니라, 가슴하고 내가 같이 뛰어야 돼.

갓웅정의 명언. 겪어보고 나서야 이해가 되는 말이었다.

두번째로 결과를 내기 위해 몰입 했던 점은, 내가 개발하면서 하루종일 앉아서 집중하고, 늦은 시간까지 열정적으로 무언갈 만든게 최근 몇 년간 있었던가? 익숙해서 나태해진 업무의 코드들, 혼자 짜다보니 짜게식은 코딩컨벤션 등 나태해진 내 상태를 바로 알 수 있게 하였다.

세번째로 TDD는 말로만 해야지~ 또는 업무코드는 너무 복잡하고, 급한 이슈부터 처리해야지~ 하다가실제로 처음 적용해봤다. 미친놈이지. 시간도 없고, 할줄도 모르는 상태에서 처음시도해보다니. 근데 막상 적용하니 좋은 점이 많았다.

매번 빌드해서 포스트맨으로 테스트하던 내가 테스트 코드가 익숙해지고, 검증이 완성된 코드를 적용하였다.
제출 6시간 전 발견했던 버그 및 미구현 기능들을 고치고 추가하는데 적은 시간이 들었다.
테스트하기 쉽게 기능들을 파일로 나누었고, 그결과 자동적으로 객체지향적인 코드작성이 가능했고 리팩토링이나 기능수정 시 버그가 현저히 줄었다.
리팩토링 대상이 줄었으며 막상 진행해도 굉장히 쉬웠고 안정적이었다.

네번째로 좋은 코드를 짜기위해 고민했던 점인데 그동안 책이나 블로그로 열심히 눈동냥했던 내용들을 적용해봤다. 정책은 언제든 변경이 일어나기때문에 확장 가능한 코드를 짜고싶었다. 그외에도 스태틱빌드패턴, TDD, 테스트모듈화 등 다양한 기능을 적용해본것 같다.

잘한 점이 있긴 한가? 해놓고 많이쓴 느낌...

잘못한 점

잘못한 점은 너무 명확했다.
준비가 안돼있었다. 아쉬운 점에 쓸까 하다가 여기 적는게 맞는것 같다.
평소에 준비안한게 내 잘못이다.
성공에 운이 정말 중요하다고 하지만 그 운도 볼 줄 모르고, 능력도 안되면 잡을 수 없는것같다.
"난 내가 능력이 좋아서 성공했다고 생각하지 않아요. 정말 운이 좋았어요" 라고 말하는 사람들은 본인 기준이 높을뿐 그 운을 잡을 능력이 있었고 준비된 사람이라 생각한다.
또 과제를 진행하며 잘못한 점은 침착하지 못했던 것 같다.
평소였으면 큰 문제가 있다면 작은 단위로 나눠서 해결하여 진행했을 것 같은데, 겁많은 개가 사납게 짖는걸까? 뭔가 이만큼이나 알고있다고 보여주고 싶어서였을까? 큰그림을 그려놓고 크게 개발을 해버렸다.
큰 그림을 그리고 작은단위로 완성해나가야 하는데 그 부분이 아쉬웠다. 이부분은 밑에 아쉬운 점에 나오겠지만 평소에 구현해보지 않았던 스프링시큐리티가 큰 부분을 차지하는 것 같다. 개념도 잘모르고, 구현할줄도 모르는데 이틀만에 하려다보니 시간에 쫒기는 느낌... 평소에 준비가 너무 안된게 드러났다.

아쉬웠던 점

잘못한 점과 마찬가지로 준비가 너무 안돼있었다.
평소에 보일러플레이트처럼 과제테스트용으로 준비된 레포가 있었다면 기본적인 구현시간은 줄일 수 있지 않았을까?
그 시간에 비즈니스적으로 처리할 로직이나, 예외처리등 진행이 부족했던게 너무 아쉽다.
실제 평가 기준이 어떨지 모르지만 내가 심사를 한다면 이런 비중에 더 큰 점수를 주지 않을까?
알면서 못한게 가장 아쉽다.. 지금 내가 하는 업무, 강조되는 부분이 그 부분인데!!!
구현에 바빠 로직에 신경쓰지 못한게 이번 과제테스트에서 가장 아쉬운 부분이다. readme도 @쌈뽕하게 적고, 예외처리도 이런것 까지 생각했어? 들 정도로 하고싶었는데...
지금이라도 생각나는 부분을 적어보자면

정책적으로 정해져야 할 부분정리, 그중 임의로 하나 진행후 주석으로 표시
스크래핑시 컬림이 있을경우, 없을경우
스크래핑 요청이 여러번 올 경우 처리 방안(처리하긴햇는데.. 중복조건 잘못줌..연도별로 스크래핑 하는건데 중복 조건에 연도가 빠졌어요 담당자님....)
외부api요청시 타임아웃관련 설정들
jwt refreshToken관련
예외처리 부분에 대한 좀 더 상세한 테스트코드
등등
다음에 잘할게요는 없다. 이 글을 읽으신 분은 지금부터 잘하길... 나도 지금부터 잘할게요

발전할 점

징징댈거 다 징징댔고, 그래서 어떻게 발전할까?
먼저 잘못된 점에서 발전 할 부분은 평소에 준비를 해놔야겠다.
스프링은 php와 다르게 공부할 부분이 너무 많다. 정말 뛰어난 개발자들이 구현한 기능을 잘 가져다 쓰면되는 편함도 있지만, 알지못하면 제대로 쓰지도 못한다... 컨벤션도 빡빡하고,,, 공부할게 많다.
주변에 있는(이번에 이직하는) 개발자친구는 새로운 기술이나 관심있는 기술이 있다면 깃허브 저장소 하나 파서 붙여본다고 한다...역시 이직자는 뭐가 달라도 다르다. 내가 생각하는 이직하는 사람의 기준은 회사에서,적어도 팀에서 가장 잘하고 인정받는 사람인것같다. (나처럼 운이좋거나, 옆그레이드가 아닌 하고싶은 도메인이나, 원하는 회사로 이직하는 사람 기준)
아무튼, 기본적인 기술에 대해서는 가볍게라도 적용 해 봄으로써 사용법정도는 익혀놔야할것같다.
그래야 필요한 부분이 있으면 추가로 적용하고, 고칠 수 있으니 말이다.
이번 잘한점에서 적은 TDD도 업무에 적용해서 고도화 시키면 과제테스트 같은 간단한 테스트는 금방 짤 수 있을 것같다. 우선 테스트코드가 익숙해질 수 있도록 테스트 방식이나 어노테이션들 정리를 진행 할 예정.
우선 가볍게 이정도? 이정도만 발전해도 다음 과제테스트가 있을때

~~(없길바래봄)~~

구현에 힘쓰지않고 좀더 도메인의 비즈니스로직이나 예외처리 부분에 집중할 수 있을 것 같다 .

느낀점

매일 한걸음씩 성장했다고 했을 때 이번 과제테스트로 세단뛰기는 한 것 같은 성장을 경험했다.
이 글을 읽을 누군가도 갓웅정의 명언을 따라 이 경험을 해봤으면 좋겟다.
나는 이만 또 깨지로 가야겠다.(어제 한 마이그레이션 잘 못 된듯)

Spring Security 개념정리

닥치고개돌 — Tue, 12 Mar 2024 13:35:59 +0900

대부분의 시스템에서는 회원의 관리를 하고 있고, 그에 따른 인증(Authentication)과 인가(Authorization)에 대한 처리를 해주어야 한다. Spring에서는 Spring Security라는 별도의 프레임워크에서 관련된 기능을 제공하고 있는데, 이번에는 Spring Security에 대해서 알아보도록 하겠다.

먼저 보안용어를 이해하고 넘어가야 한다.

접근 주체(Principal) : 보호된 리소스에 접근하는 대상
인증(Authentication) : 보호된 리소스에 접근한 대상에 대해 이 유저가 누구인지, 애플리케이션의 작업을 수행해도 되는 주체인지 확인하는 과정
인가(Authorize) : 해당 리소스에 대해 접근 가능한 권한을 가지고 있는지 확인하는 과정(After Authentication, 인증 이후)
권한 : 어떠한 리소스에 대한 접근 제한, 모든 리소스는 접근 제어 권한이 걸려있다. 즉, 인가 과정에서 해당 리소스에 대한 제한된 최소한의 권한을 가졌는지 확인한다.

1. Spring Security란?

Spring Security란?

Spring Security는 Spring 기반의 애플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 하위 프레임워크이다. Spring Security는 '인증'과 '권한'에 대한 부분을 Filter 흐름에 따라 처리하고 있다. Filter는 Dispatcher Servlet으로 가기 전에 적용되므로 가장 먼저 URL 요청을 받지만, Interceptor는 Dispatcher와 Controller사이에 위치한다는 점에서 적용 시기의 차이가 있다. Spring Security는 보안과 관련해서 체계적으로 많은 옵션을 제공해주기 때문에 개발자 입장에서는 일일이 보안관련 로직을 작성하지 않아도 된다는 장점이 있다.

Spring Security 인증관련 아키텍쳐

Spring Security 주요 모듈

[ SecurityContextHolder ]

SecurityContextHolder는 보안 주체의 세부 정보를 포함하여 응용프래그램의 현재 보안 컨텍스트에 대한 세부 정보가 저장된다. SecurityContextHolder는 기본적으로 SecurityContextHolder.MODE_INHERITABLETHREADLOCAL 방법과SecurityContextHolder.MODE_THREADLOCAL 방법을 제공한다.

[ SecurityContext ]

Authentication을 보관하는 역할을 하며, SecurityContext를 통해 Authentication 객체를 꺼내올 수 있다.

[ Authentication ]

Authentication는 현재 접근하는 주체의 정보와 권한을 담는 인터페이스이다. Authentication 객체는 Security Context에 저장되며, SecurityContextHolder를 통해 SecurityContext에 접근하고, SecurityContext를 통해 Authentication에 접근할 수 있다.

[ UsernamePasswordAuthenticationToken ]

UsernamePasswordAuthenticationToken은 Authentication을 implements한 AbstractAuthenticationToken의 하위 클래스로, User의 ID가 Principal 역할을 하고, Password가 Credential의 역할을 한다. UsernamePasswordAuthenticationToken의 첫 번째 생성자는 인증 전의 객체를 생성하고, 두번째 생성자는 인증이 완려된 객체를 생성한다.

[ AuthenticationProvider ]

AuthenticationProvider에서는 실제 인증에 대한 부분을 처리하는데, 인증 전의 Authentication객체를 받아서 인증이 완료된 객체를 반환하는 역할을 한다. 아래와 같은 AuthenticationProvider 인터페이스를 구현해서 Custom한 AuthenticationProvider을 작성해서 AuthenticationManager에 등록하면 된다.

[ Authentication Manager ]

인증에 대한 부분은 SpringSecurity의 AuthenticatonManager를 통해서 처리하게 되는데, 실질적으로는 AuthenticationManager에 등록된 AuthenticationProvider에 의해 처리된다. 인증이 성공하면 2번째 생성자를 이용해 인증이 성공한(isAuthenticated=true) 객체를 생성하여 Security Context에 저장한다. 그리고 인증 상태를 유지하기 위해 세션에 보관하며, 인증이 실패한 경우에는 AuthenticationException를 발생시킨다.

AuthenticationManager를 implements한 ProviderManager는 실제 인증 과정에 대한 로직을 가지고 있는 AuthenticaionProvider를 List로 가지고 있으며, ProividerManager는 for문을 통해 모든 provider를 조회하면서 authenticate 처리를 한다.

위에서 설명한 ProviderManager에 우리가 직접 구현한 CustomAuthenticationProvider를 등록하는 방법은 WebSecurityConfigurerAdapter를 상속해 만든 SecurityConfig에서 할 수 있다. WebSecurityConfigurerAdapter의 상위 클래스에서는 AuthenticationManager를 가지고 있기 때문에 우리가 직접 만든 CustomAuthenticationProvider를 등록할 수 있다.

[ UserDetails ]

인증에 성공하여 생성된 UserDetails 객체는 Authentication객체를 구현한 UsernamePasswordAuthenticationToken을 생성하기 위해 사용된다. UserDetails 인터페이스를 살펴보면 아래와 같이 정보를 반환하는 메소드를 가지고 있다. UserDetails 인터페이스의 경우 직접 개발한 UserVO 모델에 UserDetails를 implements하여 이를 처리하거나 UserDetailsVO에 UserDetails를 implements하여 처리할 수 있다.

[ UserDetailsService ]

UserDetailsService 인터페이스는 UserDetails 객체를 반환하는 단 하나의 메소드를 가지고 있는데, 일반적으로 이를 구현한 클래스의 내부에 UserRepository를 주입받아 DB와 연결하여 처리한다. UserDetails 인터페이스는 아래와 같다.

[ Password Encoding ]

AuthenticationManagerBuilder.userDetailsService().passwordEncoder() 를 통해 패스워드 암호화에 사용될 PasswordEncoder 구현체를 지정할 수 있다.

[ GrantedAuthority ]

GrantAuthority는 현재 사용자(principal)가 가지고 있는 권한을 의미한다. ROLE_ADMIN나 ROLE_USER와 같이 ROLE_*의 형태로 사용하며, 보통 "roles" 이라고 한다. GrantedAuthority 객체는 UserDetailsService에 의해 불러올 수 있고, 특정 자원에 대한 권한이 있는지를 검사하여 접근 허용 여부를 결정한다.

java8 람다 표현식

닥치고개돌 — Fri, 1 Mar 2024 22:58:11 +0900

람다란 무엇인가?

람다 표현식은 메서드로 전달할 수 있는 익명 함수를 단순화한 것이다.

즉, 람다는 어떤 함수의 매개변수로 다른 함수를 넣고 싶을 때 사용한다.

익명 : 보통의 메서드와 달리 이름이 없으므로 익명이라 표현한다.

함수 : 람다는 메서드처럼 특정 클래스에 종속되지 않으므로 함수라고 부른다.

전달 : 람다 표현식을 메서드 인수로 전달하거나 변수로 저장할 수 있다.

간결성 : 익명 클래스처럼 많은 자질구레한 코드를 구현할 필요가 없다.

람다의 구성 요소
- 파라미터 리스트
- 화살표 : 파라미터 리스트와 바디를 구분한다
- 바디 : 람다의 반환값에 해당하는 표현식

함수형 인터페이스는 정확히 하나의 추상 메서드를 지정하는 인터페이스이다.

@FunctionalInterface 어노테이션을 붙여 주면 메서드가 2개 이상일 경우 컴파일 단계에서 에러를 발생 시킬 수 있다.

함수형 인터페이스 사용

Predicate

java.util.function.Predicate 인터페이스는 test라는 추상 메서드를 정의하며 test는 제네릭 형식 T의 객체를 인수로 받아 boolean을 반환한다.

Consumer

java.util.function.Consumer 인터페이스는 제네릭 형식 T 객체를 받아서 void를 반환하는 accept라는 추상 메서드를 정의한다. T 형식의 객체를 인수로 받아서 어떤 동작을 수행하고 싶을 때 Consumer 인터페이스를 사용할 수 있다.

Function

java.util.function.Function 인터페이스는 제네릭 형식 T를 인수로 받아서 제네릭 형식 R 객체를 반환하는 apply라는 추상 메서드를 정의한다. 입력을 출력으로 매핑하는 람다를 정의할 때 Function 인터페이스를 활용할 수 있다. 자바 8에서는 기본형을 입출력으로 사용하는 상황에서 오토박싱 동작을 피할 수 있도록 특별한 버전의 함수형 인터페이스를 제공한다.

Supplier

매개 변수는 없고, 반환 값이 있는 함수형 인터페이스이다.
추상 메소드 T supplier()를 가진다.

메서드 레퍼런스

메서드 레퍼런스는 특정 메서드만을 호출하는 람다의 축약형이다. 메서드 레퍼런스를 새로운 기능이 아니라 하나의 메서드를 참조하는 람다를 편리게 표현할 수 있는 문법으로 간주 할 수 있다.

람다	메서드 레퍼런스 단축 표
(Apple a) → a.getWeight()	Apple::getWeight
() → Thread.currentThread().dumpStack()	Thread.currentThread()::dumpStack
(str, i) ⇒ str.substring(i)	String::substring
(String s) → System.out.println(s)	System.out::println

람다, 메서드 레퍼런스 활용하기

아래와 같은 순서로 사용하면 편하다

코드전달 → 익명 클래스 사용 → 람다 표현식 사용 → 메서드 레퍼런스 사용

Comparator는 Comparable 키를 추출해서 Comparator 객체로 만드는 Function 함수를 인수로 받는 정적 메서드 comparing을 포함한다. 그러므로 다음처럼 사용할 수 있다.

import static java.util.Comparator.comparing;

inventory.sort(comparing((a) -> a.getWeight()));

메서드 레퍼런스를 사용했을 때

inventory.sort(comparing(Apple::getWeight));

람다 표현식을 조합할 수 있는 유용한 메서드

역정렬

비교자 구현을 그대로 재사용하여 사과의 무게를 기준으로 역정렬할 수 있다.

// 무게를 내림차순으로 정렬

Inventory.sort(comparing(Apple::getWeight).reserved());

Comparator 연결

thenComparing은 함수를 인수로 받아 첫 번째 비교자를 이요해서 두 객체가 같다고 판단되면 두 번째 비교자에 객체를 전달한다.

// 무게를 내림차순으로 정렬하고 두 사과의 무게가 같으면 국가별로 정렬할것

inventory.sort(comparing(Apple::getWeight)

.recered()

.thenComparing(Apple::getContry));

Predicate 조합

Predicate 인터페이스는 복잡한 Predicate를 만들 수 있도록 negate, and, or 세 가지 메서드를 제공한다.

// 빨간색이면서 무거운(150그램 이상) 사과 또는 그냥 녹색 사과

Predicate<Apple> redAndHeavyAppleOrGreen =

redApple.and(a -> a.getWeight() > 150)

.or(a -> "green".equals(a.getColor()));

Function 조합

Function 인터페이스는 andThen, compose 두 가지 디폴트 메서드를 제공한다. andThen 메서드는 주어진 함수를 먼저 적용한 결과를 다른 함수의 입력으로 전달하는 함수를 반환한다.

Function<Integer, Integer> f = x -> x + 1;

Function<Integer, Integer> g = x -> x * 2;

Function<Integer, Integer> h = f.andThen(g);

int result = h.apply(1); // 4

compose 메서드는 인수로 주어진 함수를 먼저 실행한 다음에 그 결과를 외부 함수의 인수로 제공한다.

Function<Integer, Integer> f = x -> x + 1;

Function<Integer, Integer> g = x -> x * 2;

Function<Integer, Integer> h = f.compose(g);

int result = h.compose(1); // 3

[TDD한걸음] 1편 Springboot TestAnotation정리

닥치고개돌 — Tue, 20 Feb 2024 19:52:13 +0900

TDD 들어가기 전에 기본적으로 테스트 코드를 작성하기 위한 문법을 알아야 TDD도 가능하다.
먼저 테스트 코드 작성을 돕는 어노테이션들을 알아보자!

Spring Boot는 기본적으로 웬만한 테스트 라이브러리들을 한데 뭉쳐놓은 테스트 스타터를 제공한다. (spring-boot-starter-test)

먼저 기본적으로 자주 사용되는 어노테이션들을 살펴보자

@SpringBootTest
@WebMvcTest
@DataJpaTest
@RestClientTest
@JsonTest

@SpringBootTest

@SpringBootTest는 통합 테스트를 제공하는 기본적인 스프링부트 테스트 어노테이션이다.
애플리케이션이 실행될 때의 설정을 임의로 바꾸어 테스트를 진행할 수 있으며 여러 단위 테스트를 하나의 통합된 테스트로 수행할 때 적합하다. Spring Boot 프로젝트를 만들면 메인 클레스와 함께 기본으로 제공된다.
@SpringBootTest는 만능이라 할 수 있는데, 실제 구동되는 애플리케이션과 똑같이 ApplicationContext를 로드하여 테스트하기 때문에 하고 싶은 테스트를 모두 수행할 수 있다.

단, 애플리케이션에 설정된 빈을 모두 로드하기 때문에 애플리케이션의 규모가 클수록 느려진다.

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;

@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringBootTestApplicationTests {

    @Test
    public void contextLoads() {
    }
}

이 클래스를 실행하면 애플리케이션 컨텍스트를 로드하여 스프링 부트 테스트를 진행한다.

@RunWith 어노테이션을 사용하면 JUnit에 내장된 러너를 사용하는 대신 어노테이션에 정의된 러너 클래스를 사용한다. @SpringBootTest 어노테이션을 사용하려면 JUnit 실행에 필요한 SpringJUnit4ClassRunner 클래스를 상속받은 @RunWith(SpringRunner.class)를 꼭 붙여서 사용해야 한다. 그렇지 않으면 정상적으로 동작하지 않는다.

JUnit5부터는 @ExtendWIth(SpringExtension.class) 이렇게 사용!

@ActiveProfiles("test") : 프로파일 환경(개발, QA, 운영 환경)마다 다른 데이터소스(DataSource)를 갖는다면, @ActiveProfiles("test")과 같은 방식으로 원하는 프로파일 환경값을 부여
@Transactional 을 사용하면 테스트를 마치고 나서 수정된 데이터가 롤백된다.
@SpringBootTest는 기본적으로 검색 알고리즘을 사용하여 @SpringBootApplication이나 @SpringBootConfiguration 어노테이션을 찾는다. 스프링 부트 테스트이기 때문에 해당 어노테이션 중 하나는 필수

@DataJpaTest

@DataJpaTest 어노테이션은 JPA 관련 테스트 설정만 로드한다.
데이터소스의 설정이 정상적인지, JPA를 사용하여 데이터를 제대로 생성, 수정, 삭제하는지 등의 테스트가 가능하다. 또한 내장형 DB를 사용하여 실제 데이터베이스를 사용하지 않고 테스트 데이터베이스로 테스트할 수 있다.

@DataJpaTest는 기본적으로 인메모리 임베디드 데이터베이스를 사용하며, @Entity 클래스를 스캔하여 스프링 데이터 JPA 저장소를 구성한다. 만약, 최적화한 별도의 데이터소스를 사용하여 테스트하고 싶다면 기본 설정된 데이터소스를 사용하지 않도록 다음과 같이 설정한다.

@RunWith(SpringRunner.class)
@DataJpaTest
@ActiveProfiles("...") // ← 여기에 주목
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
public class JpaTest {
    // ...
}

@AutoConfigureTestDatabase 어노테이션의 기본 설정값인 Replace.Any를 사용하면 기본적으로 내장된 데이터소스를 사용한다. 위와 같이 Replace.NONE으로 설정하면 @ActiveProfiles에 설정한 프로파일 환경값에 따라 데이터소스가 적용된다.

이 외에도 자동 설정 방식을 이용해 설정할 수도 있다. application.yml에서 프로퍼티 설정을 spring.test.database.replace: NONE으로 변경하면 된다.

@DataJpaTest는 JPA 테스트가 끝날 때마다 자동으로 테스트에 사용한 데이터를 롤백한다. 또한 어떤 테스트 데이터베이스를 사용할 것인지도 선택할 수 있다. spring.test.database.connection: H2와 같이 프로퍼티를 설정하는 방법과, @AutoConfigureTestDatabase(connection = H2) 어노테이션으로 설정하는 방법이 있다. connection의 옵션으로 H2, Derby, HSQL 등의 테스트 데이터베이스 종류를 선택할 수 있다.

또한 @DataJpaTest에서 EntityManager의 대체제로 만들어진 테스트용 TestEntityManager를 사용하면 persist, flush, find 등과 같은 기본적인 JPA 테스트를 할 수 있다.

@RunWith(SpringRunner.class)
@DataJpaTest
public class BoardJpaTest {

    @Autowired
    private TestEntityManager boardTestEntityManager;

    @Autowired
    private BoardRepository boardRepository;

    @Test
    void Board_save_and_delete_test() {
        Board board1 = Board.builder()
                        .title("제목")
                        .createdAt(LocalDateTime.now()).build();
        boardTestEntityManager.persist(board1);

        Board board2 = Board.builder()
                        .title("제목2")
                        .createdAt(LocalDateTime.now()).build();
        boardTestEntityManager.persist(board2);

        boardRepository.deleteAll();
        assertThat(boardRepository.findAll(), IsEmptyCollection.empty());
    }
}

위 예제처럼 boardRepository의 deleteAll을 테스트하고싶을경우 save에 의존하지않고 저장된 Board객체가 두개 다 삭제 됐는지 테스트할 수 있다.

@RestClientTest

@RestClientTest는 REST 관련 테스트를 도와주는 어노테이션이다. REST 통신의 데이터형으로 사용되는 JSON 형식이 예상대로 응답을 반환하는지 등을 테스트할 수 있다.

@JsonTest

@JsonTest는 JSON 테스트를 지원하는 어노테이션이다. JSON의 직렬화와 역직렬화를 수행하는 라이브러리인 Gson과 Jackson API의 테스트를 제공한다. 각각 GsonTester와 JacksonTester를 사용하여 테스트를 수행한다.

JSON 테스트는 크게 두 가지로 나뉜다. 문자열로 나열된 JSON 데이터를 객체로 변환하여 변환된 객체값을 테스트하거나 그 반대의 경우이다.

@RunWith vs @ExtendWith

해당 어노테이션들은 JUnit Test를 Spring TestContext Framework와 결합하는 것이다. JUnit 버전에 따라 다음과 같이 사용해야 한다.

// JUnit4
@RunWith(SpringRunner.class)

// JUnit5
@ExtendWIth(SpringExtension.class)

추가조사

@ContextConfiguration

@EnableAutoConfiguration

@AutoConfigureRestDocs

@AutoConfigureMockMvc

@Mock

@Spy

@MockBean

@Bean

@InjectMocks
@Autowired

@Nested

@Captor

@BeforeEach

@AfterEach

@ParameterizedTest

@ValueSource

@TestConfiguration

msa란? msa 고도화

닥치고개돌 — Sun, 4 Feb 2024 21:54:19 +0900

msa 개념

MicroService Architecture(MSA)는 loosely coupled를 기반으로 여러 개의 작은 서비스로 구성되어 각 서비스가 독립적으로 개발되고 빠른 배포주기, 폴리그랏 프로그래밍, 관심사의 집중 등의 장점을 발휘해 Enterprise IT에서 가장 주목받고 있는 아키텍처이다.
폴리그랏 프로그래밍 : 단일 언어로 제공되지 않는 추가 기능과 효율성을 극대화 하기 위해 여러 언어로 코드를 작성하는 것

msa 장점

MSA를 도입하여 느슨한 결합, 관심사의 집중, 단일 책임 원칙, 빠른 배포주기, 폴리그랏, Scalability, 장애의 격리, 유연성, 확장성 등 여러 이점

msa 단점

Shared 관계형 데이터베이스 장점 사용 불가
- 데이터를 효율적으로 보관하고 조회/삭제 등 기능의 효율을 높이는 장점
- 테이블 조인을 통한 통합 뷰 제공
- ACID 원칙에 따른 트랜잭션 기능
서비스가 뭉쳐져 있을 때 발휘되던 장점을 활용하지 못함

현재 서비스의 단점

이 글을 쓰는 이유이자 공유의 목적이다.
현재 서비스가 msa 구조로 나뉘어 질 때 같이 개발하지 않았지만, 인수인계도 없이 현재 서비스를 맡았을 때 이해가지 않거나, 아쉽게 구현된 msa환경의 불편함을 공유하여 같은 실수를 겪지 않았으면 한다.

무분별한 서비스 분리
- Monolithic한 구조에서 MSA로 가기위해선 서비스를 어떻게 분리할 것인지 기준이 있어야한다.
- 대표적으로 비즈니스 구조를 기반으로 분리, 도메인간의 결합도, 응집도에 따라 분리
- 비즈니스 구조를 기반으로 분리한다면 현재 대상 서비스가 세금계산서 하나여서 분리하기 어려움
- 도메인간 결함도,응집도에 따라 분리해야 하는데, 이게 분리돼야하는 서비스인가?하는 부분까지 별도의 api로 분리돼있음 예를들어 유니크한 문서번호만을 생성하는 api가 있다. 왜 32자리의 대,소문자+숫자 조합의 유니크한 값을 별도의 서비스가 생성해야하는거지?
- 문서 번호생성은 결국 문서생성 api와 결합도가 생길 것이고 이러한 작은 기능까지 별도의 서비스로 분리하여 관리 할 api가 많아지면 개발복잡도 증가는 물론, 패킷유실, 트랜잭션처리 등 msa의 단점만 커지는것 같다.
Database Per Service가 지켜지지 않음
msa의 목적은 결국 응집력은 높이고 결합도를 낮춰 서비스를 독립적으로 개발,배포 및 확장시키고 서비스간 유기적인 통신을 하는것이다. 하지만 현재 구조는 Database하나를 여러 서비스가 참조하고, 하나의 서비스가 여러 데이터베이를 참조하는 강결합을 보여주고있다.
서비스가 나눠져있으니 상관없는게 아니냐?라고 생각할 수 있지만 이런 형태는 우선 트랜잭션 처리를 어렵게한다. 트랜잭션은 결국 데이터베이스에서 관장하는데 하나의 요청에 서로 다른 데이터베이스가 변경돼야하면 트랜잭션처리는 할수 없다.(보상 트랜잭션이 있지만... 결국 서비스단에서의 추가 요청이고, 보상트랜잭션이 실패한다면..?)
또한 데이터베이스의 컬럼추가나 서비스의 변경으로 데이터베이스가 변경되면 관련 서비스들도 전부 개발 및 배포가 이루어 져야한다. 관리 repo가 많아지면 결국 이 DB가 어느 api를 보고있는지, 어디를 고쳐야하는지 찾기힘들어지고 버그 포인트만 늘어나게된다. 이는 결국 비싸고 유실많은 TCP통신을 하며, 코드 검색 및 관리하기도 힘든 api들로 이루어진 초 거대 Monolithic 구조로 개발하는것이다.

MSA 단점 보완(Event Driven MicroService 란?)

위처럼 msa의 단점이 극대화 된 경우 이를 보완하는 다양한 방법으로 EDM을 추천하곤한다.
EDM이란? MSA가 적용된 시스템에서 이벤트 발생시 해당 이벤트 로그를 보관하고 이를 기반으로 동작하며, 비동기 통신을 통해 시스템 내 통합(integration)을 수행하는 Architecture이다.

EDM의 특징

이벤트 : 상태의 변경. 즉, 데이터의 변경,생성,삭제(CUD)를 통해 발생하는 서비스의 의미있는 변화
비동기 통신 : amqp, mqtt, jms 등 메세징 프로토콜을 통한 메세지 큐 방식이 자주 사용, 서비스에서 데이터의 생성,변경,삭제(CUD)를 통해 이벤트가 발생하면 발행 서비스는 메세지의 형태로 이벤트를 발행하고, 해당 이벤트에 관심이 있는 서비스에서 구독을 수행
시스템 내 통합(integration) : Database Per Service를 적용하면 Shared Database 구성의 DBMS 레벨에서 제공하던 기능을 Application 레벨에서 해결해준다.

EDM의 효과

비즈니스 흐름에 따른 로직 수행
분산 트랜잭션 처리
서비스 간 반정규화 데이터 동기 처리
적절한 시스템 내 통합
최종적인 일관성
동기 통신비용의 절감

참고 : https://medium.com/dtevangelist/event-driven-microservice-%EB%9E%80-54b4eaf7cc4a

각종 타임아웃(timeout)설명과 설정 팁

닥치고개돌 — Sun, 4 Feb 2024 17:37:35 +0900

Connection Timeout

클라이언트가 서버측으로 connection을 맺길 원하지만 서버의 장애 상황으로 connection조차 맺어지지 못할 때 발생하는 timeout이다.
우리가 흔히 알고있는 TCP 3 way handshake를 통해 TCP 연결이 생성되지 못한것을 의미함.

Read Timeout

클라이언트와 서버가 connection을 맺으면 하나의 데이터 덩어리가 아닌 여러개의 패킷으로 나눠서 전송하게 되는데, I/O작업이 길어지거나 락이 걸려 요청이 처리되지 못하고 있을 때 클라이언트는 더 이상 기다리지 못하고 커넥션을 끊는다. 즉, 응답을 기다리지 못하는 것이다. 이런 상황을 Read Timeout 이라고 하는데 java에서는 SocketTimeout Exception이 떨어진다.

java에서의 Connection, Socket/Read timeout과 관련된 예외

java.net.SocketException

: Thrown to indicate that there is an error creating or accessing a Socket. → connection timeout

java.net.SocketTimeoutException : Signals that a timeout has occurred on a socket read or accept. → socket timeout, read timeout

Write Timeout

클라이언트가 서버로 패킷을 보낼 수 있는 timeout을 설정할 수 있다. 클라이언트와 서버가 connection은 맺어졌지만 설정된 timeout의 값 보다 데이터를 보내는(요청) 시간이 길어지면 Write Timeout이 발생하여 Exception이 떨어진다.

Statement Timeout

네트워크 연결 장애에 대한 timeout을 담당하는 것이 아니다.
Statement 하나가 얼마나 오래 수행되어도 괜찮은지에 대한 한계 값이다. JDBC API인 Statement에 타임아웃 값을 설정하며, 이 값을 바탕으로 JDBC 드라이버가 StatementTimeout을 처리한다. JDBC API인 java.sql.Statement.setQueryTimeout(int timeout) 메서드로 설정한다.
네트워크 장애에 대비하는 타임아웃은 JDBC Driver SoecketTimeout이 처리해야 한다.

Transaction Timeout

프레임워크나 애플리케이션 레벨에서 유효한 타임아웃이다.
간단히 설명하면 "StatementTimeout x N(Statement 수행 수) + α(가비지 컬렉션 및 기타)"라고 할 수 있다. 전체 Statement 수행 시간을 허용할 수 있는 최대 시간 이내로 제한하려 할 때 TransactionTimeout을 사용한다.
Statement 한 개를 수행할 때 0.1초가 필요하다면, 몇 개 안 되는 Statement를 수행할 때에는 문제가 없다. 그러나 Statement 10만 개를 수행할 때에는 일만 초(약 7시간)가 필요하다. TransactionTimeout은 이런 경우에 사용할 수 있다.

JDBC Driver’s SocketTimeout

JDBC Driver Type4는 소켓을 사용하여 DBMS에 연결하는 방식이고, 애플리케이션과 DBMS 사이의 ConnectTimeout 처리는 DBMS에서 하지 않는다.
JDBC 드라이버의 SocketTimeout 값은 DBMS가 비정상으로 종료되었거나 네트워크 장애(기기 장애 등)가 발생했을 때 필요한 값이다. TCP/IP의 구조상 소켓에는 네트워크의 장애를 감지할 수 있는 방법이 없다. 그렇기 때문에 애플리케이션은 DBMS와의 연결 끊김을 알 수 없다. 이럴 때 SocketTimeout이 설정되어 있지 않다면 애플리케이션은 DBMS로부터의 결과를 무한정 기다릴 수도 있다(이러한 Connection을 Dead Connection이라고 부르기도 한다). 이러한 상태를 방지하기 위해 소켓에 타임아웃을 설정해야 한다. SocketTimeout은 JDBC 드라이버에서 설정할 수 있다. SocketTimeout을 설정하면 네트워크 장애 발생 시 무한 대기 상황을 방지하여 장애 시간을 단축할 수 있다.
SocketTimeout 값을 Statement의 수행 시간 제한을 위해 사용하는 것은 바람직하지 않다. 그러므로 SocketTimeout 값은 StatementTimeout 값보다는 크게 설정해야 한다. SocketTimeout값이 StatementTimeout보다 작으면, SocketTimeout이 먼저 동작하므로 StatementTimeout 값은 의미가 없게 되어 동작하지 않는다.

SocketTimeout에는 아래 두 가지 옵션이 있고, 드라이버별로 설정 방법이 다르다.
- Socket Connect 시 타임아웃(connectTimeout): Socket.connect(SocketAddress endpoint, int timeout) 메서드를 위한 제한 시간
- Socket Read/Write의 타임아웃(socketTimeout): Socket.setSoTimeout(int timeout) 메서드를 위한 제한 시간

OS level socket timeout 설정

SocketTimeout이나 ConnectTimeout을 설정하지 않으면 네트워크 장애가 발생해도 애플리케이션이 대부분 이를 감지할 수 없다. 따라서 연결이 되거나 데이터를 읽을 수 있을 때까지 애플리케이션이 무한정 기다리게 된다. 그러나 서비스에서 발생한 실재 장애 상황에서는 30분 후에 애플리케이션(WAS)이 재연결을 시도하여 문제가 해결되는 경우가 많다. OS에서도 SocketTimeout 시간을 설정할 수 있기 때문이다. 해당 설정 값을 통해 OS 레벨에서 네트워크 연결 끊김을 확인하는 것이다. 만약 리눅스 서버의 KeepAlive 체크 수행 주기가 30분이면 SocketTimeout 설정을 0으로 해도 네트워크 장애로 인한 DBMS 연결 장애 지속 시간이 30분을 넘지 않는 것이다. Linux 서버에서 KeepAlive 체크 수행 주기는 tcp_keepalive_time로 조정할 수 있다.

TCP Retransmission

사실상 TCP 이야기가 나오면 항상 메인 토픽으로 다뤄지는 이야기가 있다. 바로 재전송 (Retransmission)에 관한 내용이다. TCP는 송신에 대한 응답이 오지않는 경우 일정시간을 대기 후에 다시 재전송을 한다. TCP Protocol 자체가 전송에 관한 Protocol이고 그 특성으로 Reliability를 갖고 있는 만큼 재전송에 대한 이야깃거리가 상당히 많다. 그중 대표적인 두가지가 RTO와 RTT 이다. RTO는 Retransmission Timeout 을 뜻하는 말로 타이머가 작동하는 시간을 의미, RTT는 Round Trip Time을 뜻하는 말로 네트워크 통신을 하는 두 노드 간에 패킷이 전달되는데 소요된 시간을 의미한다.
TCP Handshake를 하기 위한 첫 번째 SYN 패킷은 상대방과의 RTT에 대한 정보가 전혀 없기 때문에 InitRTO라고 부르는 값을 사용하고 OS 마다 값이 조금씩 다르지만, Linux에서는 1초로 되어 있다. 1초 --> 2초 --> 4초 이런 식으로 InitRTO 값은 2의 제곱수로 늘어남. 따라서 애플리케이션에서는 timeout 설정 시 최소 1초 이상을 설정 해야 함.(커넥션 풀 방식으로 네트워크 세션을 미리 만들어 두고 통신하는 경우에는 InitRTO가 발생할 일이 없기 때문에 더 작은 값으로 설정해도 무방함.)

Timeout 설정 팁

위에 설명한 것처럼 InitRTO의 경우는 1초로 설정되어 있기 때문에 애플리케이션의 타임아웃은 1초보다 큰 값으로 설정해야 한다. 이미 맺어진 세션에서의 재전송은 RTT를 기반으로 생성되기 때문에 대부분 1초를 넘기지 않겠지만, TCP Handshake를 맺는 과정에서의 재전송은 최소 1초는 소요되기 때문에 애플리케이션에서 타임아웃을 1초로 설정한다면 재전송으로 커버 가능한 통신을 타임아웃 에러로 끊어 버릴 수 있음.

이상적인 Connection Timeout

보통 커넥션 타임아웃은 3초 로 한번정도 애플리케이션 단에서 재전송 하는게 이상적이고 그 이상은 서버 문제가 있지 않은지 확인해야함.

이상적인 Read Timeout

Read Timeout에 영향을 주는 패킷 재전송을 위한 타임아웃 값인 RTO가 RTT를 기준으로 만들어져서 보통 1초보다 짧기 때문에 RTO의 최소값은 200ms + 상대 서버의 프로세스 처리 시간이 가장 이상적인 값
단순 조회의 경우 짧게 가져가고, 복잡한 로직의경우 프로세스 시간을 여유있게주는게 좋음.
하지만 이도 로드밸런서나 서버단의 idle timeout을 넘지 않도록 설정해야한다.

결론

재전송은 TCP 메커니즘에 의해서 반드시 발생할 수밖에 없다.
TCP 통신 장애가 일어나지 않게 기도하는 것이 중요한 게 아니고, 재전송이 빨리 일어날 수 있도록 해주는 것이 중요하다.

인덱스(index)란? 인덱스 알고쓰기!

닥치고개돌 — Thu, 1 Feb 2024 13:18:58 +0900

인덱스란?

인덱스란 데이터의 저장(INSERT, UPDATE, DELETE) 의 성능을 희생하고 그 대신에 데이터의 읽기 속도를 높이는 테이블의 동작속도(조회)를 높여주는 자료구조이다.

따라서 사이트의 성능개선의 가장 기본은 효율적인 인덱스 설정이다.

인덱스를 사용하는 SQL을 만들어 효율적으로 사용한다면 매우 빠른 응답 속도를 얻을 수 있고, 쿼리의 부하가 줄어들기 때문에 시스템 전체 성능이 향상되는 효과를 얻는다.

그러나 인덱스 자체 역시 하나의 데이터 덩어리 이기 때문에, 데이터베이스에 전체 크기의 10%나 되는 추가적인 공간을 할당해줘야 하고, 잘못 사용할 경우 성능이 오히려 크게 떨어질 수 있다는 단점이 있다.

(ex. 변경 작업이 자주 일어나는 경우, 인덱스가 적절하지 않은 경우)

인덱스 저장방식 (알고리즘)

데이터 저장 방식별로 구분하는 것은 사실 상당히 많은 분류가 가능하겠지만, 가장 보편적인 방식은 B-Tree 방식 알고리즘을 다루겠다.

인덱스는 B-tree구조를 사용하며 데이터가 정렬된 상태를 유지한다. 때문에 어떤 값에 대해서도 같은 시간에 결과를 얻을 수 있게 된다 (트리의 높이가 다른 경우 약간의 차이는 있을 수 있지만 O(logN)의 시간을 가진다).

인덱스 타입 종류

인덱스의 타입은 크게 두가지로 나뉘는데 Primary(클러스터) 인덱스 와 Secondary(보조) 인덱스로 나뉘어 진다.

클러스터 인덱스는 처음부터 정렬이 되어있는 영어 사전 과 같은 개념이고, 보조 인덱스는 책 뒤의 찾아보기 의 개념과 비슷하다.

클러스터 인덱스 (Primary Index)

클러스터형 인덱스는 테이블 전체가 정렬된 인덱스가 되는 방식
그래서 클러스터형 인덱스 생성 시에는 데이터 페이지 전체가 다시 정렬된다.
하지만 이러한 정렬 특징 때문에, 이미 대용량의 데이터가 입력된 상태라면 클러스터형 인덱스 생성은 심각한 시스템 부하를 줄 수 있다.
한개의 테이블당 한개만 만들 수 있다. 특정 컬럼을 PK로 지정하면 클러스터형 인덱스를 생성, 혹은 Unique + Not null로 지정해도 클러스터형 인덱스를 생성, PK가 우선으로 선정됨
본래 인덱스는 생성 시 데이터들의 배열정보를 따로 저장하는 공간을 사용하나, 클러스터 인덱스는 따로 저장하는 정보 공간을 적게 사용하면서 테이블 공간 자체를 활용한다.
인덱스 자체의 리프 페이지가 곧 데이터이기 때문에 인덱스 자체에 데이터가 포함되어있다고 볼 수 있다.
보조 인덱스 보다 검색 속도는 더 빠르지만 입력/수정/삭제는 더 느리다.
MySQL에서는 Primary Key가 있다면 Primary Key를 Clustered INDEX로, 없다면 UNIQUE 하면서 NOT NULL인 컬럼을, 그것도 없으면 임의로 보이지않는 컬럼을 만들어 Clustered Index로 지정한다.

논 클러스터형 인덱스 (Non-Clustered Index)

이 인덱스는 보조 인덱스 (Secondary index) 라고도 불린다.
별도의 페이지에서 인덱스를 구성하니, 클러스터와는 달리 자동 정렬을 하지 않는다.
개념적으로는 후보키에만 부여 할 수 있는 인덱스다.
(후보키 : 고유 식별 번호, 주민번호 같이 각 데이터를 인식할 수 있는 최소한의 고유 식별 속성 집합)
보조 인덱스의 생성시에는 데이터 페이지는 그냥 둔 상태에서 별도의 페이지에 인덱스를 구성하여 실제 데이터를 가지고 있지 않다.
클러스터형 보다 검색 속도는 더 느리지만 데이터의 입력/수정/삭제는 덜 느리고 여러 개 생성할 수 있지만 많을수록 오히려 성능을 떨어뜨릴 수 있다. (테이블당 3~4개 권장)
각 데이터에 대해서 고유 값 (unique) 들이 있는 목록에 생성 할 수 있는 인덱스다. (unique key)

인덱스 설계 핵심 TIP

인덱스의 원리를 알았으니 실전으로 인덱스를 효율적으로 사용하는 설계의 핵심을 알아보자.

효율적인 인덱스 설계

WHERE 절에 사용되는 열 (WHERE 절에 사용되는 열이라도 자주 사용해야 가치가 있음)
중복도가 낮은 컬럼에 INDEX를 설정해야 한다
SELECT 절에 자주 등장하는 컬럼들을 잘 조합해서 INDEX로 만들어두면 INDEX 조회 후 다시 데이터에서 조회할 필요가 없으므로 빠르게 검색이 가능하다.
JOIN절에 자주 사용되는 열에는 인덱스의 효율이 좋음.
ORDER BY 절에 사용되는 열은 데이터 페이지가 자동 정렬됐기 때문에 클러스터형 인덱스가 유리
외래키는 자동으로 INDEX가 걸린다.

금지해야 할 인덱스 설계

조회보다 대용량 데이터가 자주 입력되는 경우,
클러스터형 INDEX 경우 빈번한 페이징이 일어나기 때문에 부하가 생긴다.
따라서 INDEX 필요한 경우 primary(클러스터) 대신 unique만 설정하는 게 좋을 수 있다.
데이터 중복도가 높은 열은 INDEX 효과가 없다.
예를 들어 성별 컬럼에 M, F만 있다고 하면 INDEX를 안쓰는 게 낫다. INDEX를 봤다가 데이터를 봤다가 하여 성능이 느려진다
따라서 일반 보조 인덱스보다 unique 보조 인덱스가 빠른 이유가 이것이다.
자주 조회되지 않으면 성능 저하를 초래할 수 있음. (INSERT만 주구장창 하는 시스템이라면, 사용해보지도 못하고 데이터 입력에 걸리는 작업량만 많아진다.

인덱스 주의할 점(금지와 연계)

데이터 변경(삽입, 수정, 삭제) 작업이 얼마나 자주 일어나는지 고려해야 함.
단일 테이블에 인덱스가 많으면 속도가 느려질 수있다. (테이블당 3~4개 권장)
검색할 데이터가 전체 데이터의 20% 이상이라면, MySQL에서 인덱스를 사용하지 않음. (강제로 사용할 시 성능 저하를 초래할 수 있음)
사용하지 않는 인덱스는 제거하는 것이 바람직함.
테이블에 클러스터형 인덱스가 아예 없는 것이 좋은 경우도 있음
테이블이 가지고 있는 전체 데이터양의 10~15% 이내의 데이터가 출력될때만 INDEX를 타는게 효율적

인덱스가 안 되는 쿼리

INDEX가 있다고 모든 쿼리에서 INDEX를 활용하는 것은 아니다.

인덱스 입힌 컬럼을 가공
- WHERE SUBSTR(컬럼명, 1,4) = ‘2019’
- 해결 → WHERE 컬럼명 LIKE ‘2019%’
인덱스 컬럼을 OR절 사용 비교는 비교해야할 Row를 늘리는 역할을 하여 풀스캔이 발생할 확률이 높다.
- WHERE 컬럼명 = 'A' OR 컬럼명 = 'B'
- 해결 → WHERE 컬럼명 IN ('A','B')
인덱스가 있는 열 이름에는 함수나 연산을 가함
- WHERE count*10=100
- 해결 → WHERE count=100/10
인덱스 컬럼의 묵시적 형변환(같은 타입으로 비교해야함)
- WHERE 컬럼명 = ‘20190730’
- 해결 → WHERE 컬럼명 = TO_DATE(‘20190730’, ‘YYYYMMDD’)
인덱스 컬럼 부정형 비교.
- WHERE 컬럼명 != ‘10’
- 해결 → WHERE 컬럼명 IN(‘20’, ‘30’)
LIKE %가 앞에 위치.
- WHERE 컬럼명 LIKE ‘%2019’
- 해결 → or 조건 사용 WHERE 컬럼명 IN(‘102019’,‘202019’,‘302019’)
between, like, <, > 등 범위 조건은 해당컬럼은 인덱스를 타지만, 그 뒤 인덱스 컬럼들은 인덱스가 사용되지 않음.

ORDER BY 와 GROUP BY에 대한 인덱스

INDEX는 ORDER BY와 GROUP BY에도 영향을 끼치는데 다음과 같은 경우에는 INDEX를 타지 않는다.

ORDER BY 인덱스컬럼1, 컬럼2 : 복수의 키에 대해서 ORDER BY를 사용한 경우
WHERE 컬럼1='값' ORDER BY 인덱스 컬럼 : 연속하지 않은 컬럼에 대해 ORDER BY를 실행한 경우
ORDER BY 인덱스컬럼1 DESC, 인덱스컬럼2 ASC : DESC와 ASC를 혼합해서 사용한 경우
GROUP BY 컬럼1 ORDER BY 컬럼2 : GROUP BY와 ORDER BY의 컬럼이 다른 경우
ORDER BY ABS(컬럼) : ORDER BY 절에 다른 표현을 사용한 경우

제약 조건을 설정할 때 인덱스 성능 주의점

보통 제약 조건의 설정은 대개 테이블의 생성 구문(create)에서 하거나, 테이블 생성하고 뒤에 alter문으로 따로 진행한다.
그러므로 아직 테이블에 데이터가 입력되기 전에 primary key 및 unique 키의 열에는 인덱스가 생성되어져 있기 때문에, 인덱스 자체를 구성하는 시간이 걸리지 않는다.

하지만 많은 데이터가 입력된 후에 alter문으로 unique 나 primary를 지정하면 인덱스를 구성하는데 많은 시간이 걸릴 수도 있다. (페이지 분할하고 다시 정렬하고 하니까)
즉, 업무시간에 함부로 기존에 운영되는 대량의 테이블의 인덱스를 생성하면 시스템이 엄청나게 느려져 심각한 상황이 발생될 수도 있으니 주의해야 한다. (데이터의 양에 따라서 몇 시간이나 그 이사의 시간이 걸릴 수도 있다.)

인덱스 정렬

인덱스를 생성할 때 인덱스에 포함되는 필드의 정렬 방식을 설정할 수 있다.
DESC 키워드를 사용하면 내림차순으로 정렬되며, ASC 키워드를 사용하면 오름차순으로 정렬된다.

sql

CREATE INDEX 인덱스이름
ON 테이블이름 (필드이름 DESC) -- 인덱스 지정한 필드이름은 내림차순으로 정렬됨

CREATE INDEX 인덱스이름
ON 테이블이름 (필드이름 ASC) -- 인덱스 지정한 필드이름은 오름차순으로 정렬됨

다중 컬럼 인덱스

다중 컬럼 인덱스는 두개 이상의 필드를 조합해서 생성한 INDEX이다. (MySQL은 INDEX에 최대 15개 컬럼으로 구성 가능)

1번째 조건과 이를 만족하는 2번째 조건을 함께 INDEX해서 사용한다.

다중 컬럼 인덱스는 단일 컬럼 인덱스 보다 더 비효율적으로 INDEX/UPDATE/DELETE를 수행하기 때문에 신중해야한다.

때문에 가급적 UPDATE가 안되는 값을 선정 해야한다.

email, id 컬럼에 각각 단일 인덱스가 걸려있는 경우 어떤 컬럼의 수가 더 빠르게 검색되는지 판단 후 빠른쪽을 먼저 검색하고 그다음 다른 컬럼을 검색하는데 다중 컬럼 인덱스의 경우 INDEX를 저장할 때 email,id를 같이 저장하기 때문에 같이 색인하고 검색이 더빠르다

실제로 조회 쿼리 사용시 인덱스를 태우려면 최소한 첫번째 인덱스 조건은 조회조건에 포함되어야 한다.
첫번째 인덱스 컬럼이 조회 쿼리에 없으면 인덱스를 타지 않는다.

주의) 그렇지만 다중 컬럼 인덱스를 순서가 안맞거나 이빨빠지게 조회하면 인덱스의 효과를 기대하기 어렵다.

최근엔 개선됐다고 하지만 맞춰주는게 맘편함!