<Ahea> Java 개발자를 위한 공개세미나

1. 아해(Ahea) Java 개발자를 위한 공개세미나

듣기전에 …

온오프믹스에서 Java, Spring에 대해서 세미나가 있길래 바로 신청을 했다. 전부터 내가 주로 Java랑 Spring을 쓰다보니 관련 세미나가 있었으면 좋겠다 싶었는데 Ahea라는 곳에서 세미나를 열어서 바로 참석했다. 한빛미디어 건물을 처음가봐서 좀 해매다 들어갔다.. 

1. JAVA8 말고 JAVA9를 써볼까

• 자바 9에 개발관련된 부분이 바뀐부분이 많음
• JDK - 6개월마다 지원 LTS 장기적인 지원버전
• JDK 9 -> 추가된 부분 HTTP/2 클라이언트 추가 (이전에는 Blocking Mode 에서만 작동)
• Reactive 프로그래밍이란 비동기식 데이터를 처리하기 위함(Iterator + Observer)
• Iterator pull 방식 observer는 push 방식
• 크게 달라진 점중 하나 모듈 시스템 (캡슐화), 자신만의 모듈을 가질수 있음
• 모듈이 필요한 이유 불필요하게 전체 JDK 실행 되는 부분을 줄임(경량화)
• private 메소드 & 스테틱 추가, try-with-resource 향상
• 4가지 추가메소드 (takeWhile, dropWhile 등) Streams 메소드 추가됨
• JDK 10 에서 var 추가되어 타입 선언에 대한 부분의 코드를 줄일 수 있음
• 발표자료

2. if(Spring AOP== AspectJ) -> {Spring AOP에 대해}

• AspectJ를 많이 사용하지만 AOP의 일부분일 뿐 전부는 아니다.
• 프록시란 접근제어에 목적으로 사용되는 객체(사용자의 요청을 제어함)
• 사용자가 직접접근하면 DB에 부담됨 -> 로직을 추가(이경우 사이에 프록시를 둠)
• 프록시에는 타켓에 위임코드를 의무적으로 구현해야함
• 타켓의 메소드가 늘어날수록 프록시에서도 구현 위임코드 관리가 어려움
• 이를 자바 api가 도와줌 reflect을 이용 (Proxy.newProxyIntance(), InvocationHanlder 로 구현없이 생성)
• 인터페이스 복사 -> 프록시 요청 -> 타켓 -> ProxyClassFactory
• 아쉬운점
  • 하나이상의 Hanlder를 관리 못함
  • 여러 타켓을 관리하기 어려움, 핸들러를 중복사용 못함
• Spring에서는 다이나믹 프록시 한계를 대체
• ProxyFactoryBean -> advice(인터페이스) -> interceptor -> 메소드 인터셉터 (invoke)
• 여러핸들러를 ArrayList에 저장 -> adviser = pointcut + advice
• ProxyFactoryBean은 타킷에게 의존한다. -> AutoProxing
• 발표자료

3. 5G 초연결시대에 웹 HTTP의 대안은 QUIC?

가. TCP

• 3-way -> SSL(TLS) 암호화 (보안 핸드쉐이크) => RTT 증가
• HOL을 해결하기 위해 파이프라이닝 기법을 사용 => 지연을 최소화

나. UDP

• 3-way가 없음 RTT 빠름 , 데이터 손실가능 => 신뢰성하락
• 이를 해결하기 위해 UDP 홀펀칭 기법(릴레이서버를 둠)

다. HTTP/2

• 헤더, 데이터 프레임으로 구성, 바이너리 형식 인코딩 처리
• 스트림 단이로 통신 (HTTP1의 파이프라인의 단점을 해결하기 위한 멀티플렉싱)
• 스트림당위로 요청과 응답을 병렬처리 (HOL 문제로 인한 지연 해소)
• 서버 푸시 한꺼번에 보냄 (하나의 연결) ex) 네이버 웹툰 => connection 아이디가 같음 -> 큐에 쌓여서 처리
• 헤더 압축 - > 겹치는 부분을 제거하여 페이지 로드 시간 감소 (리퀘스트 1과 2[path만 전송])

라. QUIC

• HTTP3의 기반은 QUIC(퀵유디피인터넷커넥션) 프로토콜
• UDP 기반 구현 , QUIC 계층추가, TLS 1.3
• Connection ID를 통한 연결로 병렬 스트림 데이터를 동시에 전송 => 신뢰성보완
• H2 HPACK 순차스트림 에서 H3 QPACK 병렬 스트림으로 개선
• TLS 1.3 으로 0-RTT 1-RTT 제공(한번의 3-way만)
• UDP 기반 0-RTT 속도향상, TCP 장점 데이터의 신뢰성 보완
• 발표자료

4. MQ와 AMQP 프로토콜 원리

가. 필요한이유

• 어플과 DB의 강한 연결로 사용 => 의존성 제거, 비동기방식으로 진행, 쉽게 확장 가능
• MQ는 시스템간 메시지를 전달해주는 서비스
• RabbitMQ: AMQP 기반 , Kafka: 처리량많은 분산메세징 시스템에 적합

나. RabbitMQ

• 얼랭으로 개발 =? 높은 신뢰성, 클러스터링 구현
• AMQP 기반의 오픈소스 메시지 브로커
• 부하분산, 비동기, 컴포넌트간 메세지 전달
• 강점 : AMQP(메세지 프로토콜) , 단방향처리

다. amqp 메세지 발행과 소비 (3가지 컴포넌트)

• [Exchange(라우팅 규칙담당) —바인딩(라우팅)----> Queue]
• Exchange는 서로 다른 Queue로 유연하게 라우팅 가능, 4가지 유형이 존재
• 발표자료

5. Spring Webflux는 어떻게 적은 리소스로 많은 트래픽을 감당할까?

가. I/O

• blocking과 Non-blocking은 I/O에 속함, 비동기 컨텍스트 스위칭 타임이 발생

나. Event-Driven

• 버튼은 어떻게 click 되었는지 알까? -> 이벤트루프를 돌리면서 발생하면 핸들러에게 전달
• 이벤트 디스패쳐 스레드가 돌면서 발생하면 핸들러 => 큐에담음

다. MVC vs Webflux

• MVC 동기적인(하나의 스레드에 하나의 요청처리), Webflux은 비동기(더많은 커넥션처리)
• 엠브이씨는 클라이언트 요청들을 큐에 쌓이게 되고 스레드풀로 가서 스레드를 처리 -> 반납
• 이떄 대량의 트래픽이 몰린다면? => 큐에 계속쌓임 => 스레드풀Hell 발생
• 어플리케이션이 느린경우는 blocking 때문이다.(지속되는 블락킹)
• 워커스레드는 서버의 코어 개수만큼 생성됨

라. Webflux가 사용하는도구

• 비동기 Non-blocking은 콜백을 활용, Reactive프로그래밍은 변화에 반응한다.
• MVC와 Webflux는 커버할 수 있는 만큼의 스레드가 있다면 성능이 같음
• 많은 트래픽 커버, 적거나 제한된 리소스로 운영할때, I/O작업이 많이 일어날때 사용
• 논블락킹이 지원되지 않으면 => pushlishOn으로 처리(blocking을 비동기로 처리, 조금만)
• 제어할 수 없을 정도의 요청이 들어오면? => Back pressure
• 트래킹이 힘들다, 러닝커브가 크다.
• 발표자료

듣고난후…

앞에 두세션이 코드기반으로 발표를 해서 받아적어 정리하기가 어려웠던 부분이 아쉬웠다. 사실 Java9에 대한 부분만 들어보려고 했는데 새로운 부분들이 많아 모든 발표를 들었고 webflux나 HTTP3는 처음 접하니까 되게 재미있게 들었던것 같다. MQ나 AOP 나중에 블로그에 정리를 해봐야겠다… 

Ahea 블로그