• 프린터

• 멀티 스레드 : 일반적으로 프로그램을 실행하게 되면, main() 함수가 실행되면서, 하나의 프로세스가 진행된다. 이런 하나의 프로세스를 메인 스레드라고 보면 되는데, 메인 스레드 하나만 있는 것을 싱글 스레드(single-thread) 라고 하며, 스레드가 여러개인 것을 멀티 스레드(Multi-thread) 혹은 다중 스레드라 한다.

• 스레드 세이프티 :

  • synchronized : 해당 영역에 락을 걸어서 쓰레드 세이프하도록 유지한다. 장점은 멀티 쓰레드 간에 공유된 데이터에 대해서 동기화를 보장한다는 장점이 있지만, 락을 걸기 때문에 멀티 다소 지연이 발생할 수 있고 최악의 경우 다수의 병목현상이 발생할 수 있다.
    • block scope : 특정 영역을 block scope로 걸어둔다.
    • method scope : 메소드에 동기화를 보장한다.
  • volatile : 멀티 쓰레드 환경에서 동기화된 데이터의 가시성을 보장하기 위함이다. 대신 다수의 쓰레드가 write할 경우엔 동기화를 보장할 수 없고, 하나의 쓰레드가 write를 수행하고 다른 쓰레드는 read하는 경우에만 유효하다. 그 이유는 멀티 쓰레드 환경에서 각각의 쓰레드는 쓰레드 캐시를 가지고 있으며 사용하는 데이터는 쓰레드 캐시에서 관리된다. 그러나 데이터가 변경될 때 메인 메모리에서 직접 수행하고 쓰레드 캐시에 반영된다. non-volatile 변수에 대한 작업은 JVM 이 메인 메모리로부터 CPU 캐시로 변수를 읽어들이거나, CPU 캐시로부터 메인 메모리에 데이터를 쓰거나 할 때에 대한 어떠한 보장도 하지 않는다. 한 쓰레드가 volatile 변수를 수정할 때, 단지 이 volatile 변수만이 메인 메모리로 저장되는 것이 아니라, 이 쓰레드가 volatile 변수를 수정하기 전에 수정한 모든 변수들이 함께 메인 메모리에 저장(flushed)된다.
  • concurrentpage → atomic***

• 스레드 풀 : 스레드를 미리 생성해놓은 일련의 스레드 집합이다. 스레드 풀이 필요한 이유는 어떤 프로세스가 실행될 때 스레드를 생성할수도 있겠지만 실행될때마다 스레드를 생성하고 소멸하는 비용은 무시하지 않을 수 없다. 그러므로 특정 스레드를 미리 생성하여 프로세스가 실행될때마다 스레드풀을 사용하여 프로세스를 수행하게 되면 더 효율적으로 프로세스를 수행할 수 있다. 자바에서는 스레드풀을 생성하고 사용할 수 있도록 java.util.concurrent Package에서 ExecutorService 인터페이스와 Excutors 클래스를 제공하고 있다. Executors의 다양한 정적 메서드를 통해 Executor Service 구현객체를 만들어서 사용할 수 있으며, 그것이 바로 스레드 풀이다.

  • 스레드 풀을 실행시키기 위한 메소드는 execute(), submit()이 있다.
  • 장점
    • 프로그램 성능을 향상 시킬 수 있다.
    • 다수의 사용자 요청을 빠르게 처리 가능하다.
  • 단점
    • 너무 많이 생성해놓으면 오히려 메모리 낭비가 발생할 수 있다.
    • 노는 스레드가 발생될 수 있다. 이를 방지하기 위해서는 자바에서는 forkJoinPool을 지원한다.
  • ForkJoinPool의 절차를 조금 더 자세히 이야기 하면
    1.  큰 업무를 작은 단위의 업무로 쪼갠다.
    2. 부모 쓰레드로 부터 처리로직을 복사하여 새로운 쓰레드에서 쪼개진 업무를 수행(Fork) 시킨다.
    3. 2을 반복하다가, 특정 쓰레드에서 더이상 Fork가 일어나지 않고 업무가 완료되면 그 결과를 부모 쓰레드에서 Join하여 값을 취합한다.
    4. 3을 반복하다가 최초에 ForkJoinPool을 생성한 쓰레드로 값을 리턴하여 작업을 완료한다.

  그림으로 따지면 아래와 같이 Fork가 한번 일어난 타스크에서에서는 Join을 해서 결과를 취합하는 방식이라고 볼수 있다..

  그림 1)

  

hashtable과 hashmap

HashMap과 HashTable은 동일한 내부 구조를 가지고 있지만 HashTable의 경우는 동기화된 메소드로 구성되어 있기 때문에 멀티 스레드가 동시에 이 메소드를 실행할 수 없고, 하나의 스레드가 실행을 완료해야만 다른 스레드가 실행가능하다.

이는 멀티 스레드 환경에서 안전하게 객체를 추가, 삭제할 수 있다는 것을 의미한다. 일반적으로 동기화가 필요 없다면 HashMap을, 동기화 보장이 필요하다면 Hashtable을 사용하면된다.

HashMap과 Hashtable은 동기화를 보장하느냐 하지 않느냐는 측면 이외에는 차이가 거의 없다. 사용법도 똑같아, put() 메서드로 데이터를 삽입하고, get() 메서드로 추출하면된다.

Vector는 데이터(Data)에 해당하는 객체만을 이용했지만, Hashtable은 Map 인터페이스를 구현한 클래스이기 때문에 검색을 위한 키와 값을 함께 넣어주어야 한다.

• 직렬화란 data를 외부 시스템에도 사용할 수 있도록 byte 형태로 제공해주기 위한 기능이다.
• serialversionUID값은 직렬화하면서 함께 정의해주는데 그 이유는 역직렬화할 경우에 모델의 구조가 변경될 경우 UID가 변경되어 오류를 발생할 수 있기 때문이다.
• String -> StringBuilder, int -> long으로 변경해도 역직렬화에서 Exception이 발생합니다.
• 자바 직렬화는 상당히 타입의 엄격하다는 것을 알 수 있습니다.
• 멤버 변수가 빠지게 된다면 Exception 대신 null값이 들어가는 것을 확인할 수 있습니다.

위 그림의 동작 플로우를 간단히 설명하면 다음과 같습니다.

0. WebSecurityConfigurerAdapter 는 스프링 시큐리티에서 기본적으로 제공하는 보안 설정으로 구성된 클래스 구현체이다. 이를 상속받아 필요한 부분만 수정하면 된다. 그래서 접근 권한이나 로그인 처리방식 등등에 대해 어떻게 처리할건지 결정하여 configure 기능에 구현하면 된다.
1. 사용자가 로그인 정보와 함께 인증 요청(Http Request)
2. AuthenticationFilter가 이 요청을 가로챕니다. 이 때 가로챈 정보를 통해 UsernamePasswordAuthenticationToken이라는 인증용 객체를 생성합니다.
3. AuthenticationManager의 구현체인 ProviderManager에게 UsernamePasswordAuthenticationToken 객체를 전달합니다.
4. 다시 AuthenticationProvider에 UsernamePasswordAuthenticationToken 객체를 전달합니다.
5. 실제 데이터베이스에서 사용자 인증정보를 가져오는 UserDetailsService에 사용자 정보(아이디)를 넘겨줍니다.
6. 넘겨받은 사용자 정보를 통해 DB에서 찾은 사용자 정보인 UserDetails 객체를 만듭니다. 이 때 UserDetails 는 인증용 객체와 도메인용 객체를 분리하지 않고 인증용 객체에 상속해서 사용하기도 합니다.
7. AuthenticationProvider는 UserDetails를 넘겨받고 사용자 정보를 비교합니다.
8. 인증이 완료되면 권한 등의 사용자 정보를 담은 Authentication 객체를 반환합니다.
9. 다시 최초의 AuthenticationFilter에 Authentication 객체가 반환됩니다.
10. Authentication 객체를 SecurityContext에 저장합니다.

최종적으로 SecurityContextHolder는 세션 영역에 있는 SecurityContext에 Authentication 객체를 저장합니다. 세션에 사용자정보를 저장한다는 것은 스프링 시큐리티가 전통적인 세션-쿠키 기반의 인증 방식을 사용한다는 것을 의미합니다.

메시지 큐의 장점

• 비동기(Asynchronous): Queue에 넣기 때문에 나중에 처리할 수 있습니다.

• 비동조(Decoupling): 애플리케이션과 분리할 수 있습니다.

• 탄력성(Resilience): 일부가 실패 시 전체에 영향을 받지 않습니다.

• 과잉(Redundancy): 실패할 경우 재실행 가능합니다.

• 보증(Guarantees): 작업이 처리된걸 확인할 수 있습니다.

• 확장성(Scalable): 다수의 프로세스들이 큐에 메시지를 보낼 수 있습니다.

메시지 큐 사용처

• 다른 곳의 API로 부터 데이터 송수신이 가능합니다.

• 다양한 애플리케이션에서 비동기 통신을 할 수 있습니다.

• 이메일 발송 및 문서 업로드가 가능합니다.

• 많은 양의 프로세스들을 처리할 수 있습니다.

RabbitMQ

• 구성이 쉽다.

• 유연한 라우팅이 가능하면 관리 UI 가 편리하다.

• 제품 성숙도가 높다.

• 개방형 프로토콜을 위한 AMQP 를 구현위해 개발

• 필요에 따라 동기/비동기식이 가능함

• 소비자중심의 설계

• 20k/sec 처리를 보장

Apache Kafka

• 구독방식의 비동기식 구성

• 고성능 고가용성

• 분산처리에 효과적으로 설계 됨.

• 생산자 중심의 설계

• 범용 메세징 시스템에서 제공되는 다양한 기능은 제공되지 않음.

• 100k/sec 처리를 보장

• 결론

  기존의 메시징 시스템에서는 broker가 consumer에게 메시지를 push해 주는 방식인데 반해, Kafka는 consumer가 broker로부터 직접 메시지를 가지고 가는 pull 방식으로 동작합니다. 따라서 consumer는 자신의 처리능력만큼의 메시지만 broker로부터 가져오기 때문에 최적의 성능을 낼 수 있습니다.

  • 기존의 push 방식의 메시징 시스템에서는 broker가 직접 각 consumer가 어떤 메시지를 처리해야 하는지 계산하고 어떤 메시지를 처리 중인지 트랙킹하였다면, Kafka에서는 consumenr가 직접 필요한 메시지를 broker로 부터 pull하므로 broker의 consumer와 메시지 관리에 대한 부담이 경감되었습니다.

  • 메시지를 pull 방식으로 가져오므로, 메시지를 쌓아두었다가 주기적으로 처리하는 batch consumer의 구현이 가능합니다.

  큐의 기능은 **기존의 JMS의 AMQP 기반의 RabbitMQ(데이터 기반 라우팅, 페데레이션 기능 등)**등에 비해서는 많이 부족하지만 대용량 메세지를 지원할 수 있는 것이 가장 큰 특징입니다. 특히 분산환경에서 용량 뿐 아니라, 복사본을 다른 노드에 저장함으로써 노드 장애에 대한 장애 대응성을 가지고 있기 때문에 용량에는 확실하게 강점을 지니고 있습니다.

• Filter와 Interceptor는 실행되는 시점이 다르다.

• Filter는 Web Application에 등록을 하고, Interceptor는 Spring의 Context에 등록을 한다.

• Interceptor는 ServletDispatcher 내에 실행함. 따라서 @ControllerAdvice @ExceptionHandler를 이용해 예외 처리가 가능하다

• Interceptor는 Handler를 실행하기전(preHandle), Handler를 실행한 후(postHandle), view를 렌더링한 후(afterCompletion) 등, Servlet내에서도 메서드에 따라 실행 시점을 다르게 가져간다.

• Filter는 ServletRequest 혹은 ServletResponse를 교체할 수 있다. 아래와 같은 일이 가능하다.

  public class SomeFilter implements Filter {
    //...
    
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
      chain.doFilter(new CustomServletRequest(), new CustomResponse());
    }
  }

• Interceptor와 Filter는 Servlet 단위에서 실행된다. <> 반면 AOP는 메소드 앞에 Proxy패턴의 형태로 실행된다.

• 필터는 빈은 아니다.

• 하지만 빈 설정으로 등록은 할수 있다.

• 필터는 빈은 아니기 때문에 해당 필터를 다른 빈에 주입될수는 없다.

• 필터는 본인은 주입될순 없어도 다른 빈들을 주입하여 사용할순 있다.

• 그러므로 서블릿 필터랑 스프링 시큐리티 필터는 같은 범위이다.

• 차이가 있다고 하면 시큐리티 필터는 시큐리티에 관한 빈들을 사용한 확장 기능을 가지고 있다.

• 한 트랜잭션에서 읽어간 데이터를 다른 트랜잭션에서 배타적으로 수정하기 위해 락을 획득하려 할때 (읽어가는 것은 허용) 기다리게 만들고 싶다면SELECT ... LOCK IN SHARE MODE 사용
• 한 트랜잭션에서 읽어간 데이터를 다른 트랜잭션에서 배타적으로 읽거나, 수정하기 위해 락을 획득하려할 때 기다리게 만들고 싶다면 SELECT ... FOR UPDATE 사용

데이터베이스 튜닝의 3단계

• 인덱스는 하나의 테이블을 생성해 값을 저장해놓고 사용한다. 그래서 다른 테이블에 의존적인 새로운 테이블이 하나 생성된다는 점에서 무분별한 인덱스 생섵은 오히려 성능 저하를 초대할 수 있다.

• 인덱스 테이블은 '이진트리 검색'을 사용하기 때문에 기본적으로 정렬되어 있다. 그래서 만약 인덱스 테이블이 참조하는 테이블에서 '삽입', '삭제', '수정'이 자주 일어나게 된다면 인덱스 테이블에서는 데이터를 정렬하면서 삽입, 삭제, 수정이 이루어지기 때문에 전체적인 성능 저하를 초래할 수 있다.

• 인덱스는 '검색'에 최적화된 기능이기 때문에 삽입, 삭제, 수정이 자주 일어나는 비즈니스 로직 혹은 테이블 사용 용도에 따라 인덱스 사용 여부를 신중하게 고민해봐야 한다.

• 결합 인덱스를 언제 사용하면 좋을까?

  - AND 연산자에 의해 자주 같이 질의 되는 컬럼들

  - 다수의 여러 개의 질의가 특정 컬럼들을 질의

• 즉, 여러 컬럼으로 인덱스를 잡는다면 카디널리티가 높은순에서 낮은순으로 (group_no, from_date, is_bonus) 구성하는게 더 성능이 뛰어납니다.

• 인덱스 조회시 주의 사항

  • between, like, <, > 등 범위 조건은 해당 컬럼은 인덱스를 타지만, 그 뒤 인덱스 컬럼들은 인덱스가 사용되지 않습니다.
    • 즉, group_no, from_date, is_bonus으로 인덱스가 잡혀있는데 조회 쿼리를 where group_no=XX and is_bonus=YY and from_date > ZZ등으로 잡으면 is_bonus는 인덱스가 사용되지 않습니다.
    • 범위조건으로 사용하면 안된다고 기억하시면 좀 더 쉽습니다.
  • 반대로 =, in 은 다음 컬럼도 인덱스를 사용합니다.
    • in은 결국 =를 여러번 실행시킨 것이기 때문입니다.
    • 단, in은 인자값으로 상수가 포함되면 문제 없지만, 서브쿼리를 넣게되면 성능상 이슈가 발생합니다.
    • in의 인자로 서브쿼리가 들어가면 서브쿼리의 외부가 먼저 실행되고, in 은 체크조건으로 실행되기 때문입니다.
  • AND연산자는 각 조건들이 읽어와야할 ROW수를 줄이는 역할을 하지만, or 연산자는 비교해야할 ROW가 더 늘어나기 때문에 풀 테이블 스캔이 발생할 확률이 높습니다.
    • WHERE 에서 OR을 사용할때는 주의가 필요합니다.
  • 인덱스로 사용된 컬럼값 그대로 사용해야만 인덱스가 사용됩니다.
    • 인덱스는 가공된 데이터를 저장하고 있지 않습니다.
    • where salary * 10 > 150000;는 인덱스를 못타지만, where salary > 150000 / 10; 은 인덱스를 사용합니다.
    • 컬럼이 문자열인데 숫자로 조회하면 타입이 달라 인덱스가 사용되지 않습니다. 정확한 타입을 사용해야만 합니다.