Rlog

기존에 Spring 의 @Async 를 CustomThreadPool 을 이용해서 사용했었는데, 해당 부분이 엄청나게 빠른 요청이 초당 들어와서 Thread 가 부족해서 비즈니스 요건 상 discard 해도 크게 타격은 없기에 discardPolicy 를 사용하기도 했었다. 요즘 코루틴을 공부하면서 Coroutine 이 얼마나 효율적인지 배우고 있는데 이를 실무에 적용해봤더니 위와 같은 결과가 나왔다. 사실 근데 의문은 Coroutine 은 Continuous 를 Heap 에 담아두고 있는데 왜 Heap 사용량이 오히려 줄었지? 이런 생각이 들었다. 여하튼 아래를 보면 알 수 있듯이 CPU 사용량이 올랐다. 팍 튄 부분은 배포때문이고 16:00 때부터 코루틴으로 배포됬다고 생각하면 된다. CPU 사용량은..

우리는 MSA 환경의 Spring 에서 주로 Sleuth 라는 Library 를 사용한다. Sleuth 는 B3-Propagation 을 이용하여 서버간의 Request 흐름을 알 수 있게 해준다. Zipkin 등을 이용하면 UI 측면에서 쉽게 추적할 수 있다. 일단 Sleuth 가 어떻게 되어 있는지 간단하게 살펴보자. 기본적으로 Sleuth 는 아래와 같이 trace_id 와 span_id 를 가진다. Spring Sleuth 를 사용하게 되면 Multi Thread 간의 문제도 최신버전에서는 해결해준다. @Async 를 썼을때 다른 Thread 로 Context 가 넘어가더라도 traceId 를 잘 복사해주는 것을 확인했었다. 하여튼 TraceId 를 통해서 우리는 아래와 같이 하나의 요청이 들어왔..

Kotlin Coroutines 는 다른 언어에 있는 async / await 과 유사한 부분을 구현할 수 있게 만든 library 라고한다. Kotlin 의 suspend function 은 비동기 함수를 다루는데 Java 의 Future 보다도 안전하고 더 적은 버그가 있다고 한다. 일단 백문이 불여 일타 라고 코드로 먼져 보도록 하자 실습 fun main() = runBlocking { // this: CoroutineScope launch { // launch a new coroutine and continue delay(1000L) // non-blocking delay for 1 second (default time unit is ms) println("World!") // print afte..

Trace Method 란? HTTP Method 중 하나인 Trace Method 는 Client - Server Side 간 Loop back Test 를 진행할 수 있게 도와준다. 아래 실제로 TraceMethod 를 날린 결과값을 보자. 위의 메소드의 결과물을 보면 TLS Handshake 가 잘 맺어졌고, CERT 도 통과하고 등등 서버에서 어떤 일이 일어나는지 확인할 수 있다. HTTP2 를 이용해서 multiplexing 이용하고 있음을 알 수 있다. 이렇듯이 내가보낸 통신이 어느지점에서 에러가 났는지 Trace 하기 위해서 사용하는 메소드이다. 주로 Via 나 X-Forward-For 와 함께 사용하여 추적도 가능하나, 두개의 헤더는 사실상 조작하는 경우도 많아서 완전히 신뢰해서는 안된다...

변수의 스코프를 최소화 해라 만약 loop 안에서만 변수가 쓰인다면 loop 안으로 변수를 넣어서 scope 를 최소화 해라. 보통의 언어 에서 변수의 scope 는 보통 curly braces 안으로 생성지만, Kotlin 에서는 외부의 변수에도 접근 가능하다. 음, 내가 생각해도 뭔가 잘 읽기 힘들게 적은거 같아 코드로 적어보려고 한다. val a = 1 fun fizz() { val b = 2 print(a+b) } val buzz = { val c = 3 println(a + c) } 위의 예시를 보면, buzz 와 fizz 의 curly braces 지역 scope 에서 외부 변수인 a 에 접근할 수 있음을 알 수 있다. 반대로 모두 알고 있겠지만 Outer area 에서 inner functi..

현재 팀내 Legacy Code 에서는 TS 기반의 TypeORM 이 존재하는데 걷어내야 될 존재라 Flow 만알고, 이 프레임워크가 어떻게 돌아가는지는 잘 공부하진 않았다. Migration 대상에 시간을 투자하는건 별로 효율적이지 못하다고 생각해서이다. 최근에 SlowQuery 를 개선하며 DBA 분과 이야기하는데, 왜 이부분에서 distinct query 가 예전부터 날라오는지 잘 모르겠다. 라며 이야기를 해주셨고, 그 코드를 한번 파헤쳐봤는데 distinct 가 될만한 거리는 보이지 않았다. TypeORM 에서 distinct 를 하기 위해서는 .disctinct(true) 를 하거나 .select('select distinct a') 이런식으로 적어줘야 한다고 알고 있었다. 하지만 우리의 코드에..

가변성을 제한해라 들어가기에 앞서 이건 완전한 번역글이 아닙니다. 원서를 읽고 느낀점을 적은 글 입니다. 본문 일단 첫장 부터 가변성을 제한하라고 적혀있다. 책에서 나온 글귀중 이런 글이 있다. When an element holds state, the way it behaves depends not only on how you use it, but also on its history 나는 이뜻을 이렇게 해석했는데 element 가 상태를 지니고 있을때 상태를 다루는 방법은 오직 어떻게 사용하는 것에만 의존하는 것이 아니라 그것의 History(객체의 변화 상태를 보여주는 것이라고 나는 해석했다) 에도 관련있다. 그래서 아래 예시가 나오는데 같이 한번보자. class BankAccount { var ba..

이번에 새로 진행하는 신규 프로젝트를 작업중이였는데 모니터링을 하던 도중 의도치 않게 MinorGC 가 자주 발생하고, 시간 또한 긴것을 발견하였다. 그래서 이를 어떻게 개선했는지 그 방법에 대해서 적어보려고 한다. 탐색 일단 Spring Application Proccess 의 번호를 알아야 한다. jps 프로세스를 알았다면 현재 HeapDump 를 떠서 확인해야 한다. (내 프로세스 번호는 6485번 이였다.) jmap -dump:format=b,file=heapdump.hprof 6485 잘 dump 가 떠졌다면 아래와 같이 heapdump.hprof 라는 파일을 확인할 수 있을 것이다. 이 파일을 열기 위해서 GC 를 Monitoring 할 수 있는 도구인 VisualVM 을 이용했다. Dump ..

AWS LogInsight Query 를 사용하다보면 이런 생각이 문득든다. @message field 안에 들어있는 메세지들을 어떻게 분리하여 검색조건으로 사용할 수 있을까? 혹은 @message 안에 텍스트들을 내가 특별하게 변수로 활용할 수 있을까? AWS LogInsight Query 를 공부해보거나 많이 사용해봤다면 알수도 있겠지만 이런 방법에 대해 설명해보려고 한다. 이제 어떻게 @message 내부를 검색의 조건으로 사용할 수 있는지 알아보도록 하자 예시 위의 사진을 보라 @message 본문의 내용들이다. 밑에 SELECT * FROM 뭐시기와 같은 field 도 적혀있다. 다만 보안상 쿼리는 보여줄 수 없어서 적지 않았지만 생김새는 RDS 의 slowQuery log 를 생각하면 된다. ..

HTTP Pipelining 기존 HTTP/1.0 에서는 여러개의 Request 와 Response 를 순차적으로 받기 위해 아래와 같은 방식으로 Transaction 에서 요청과 응답을 처리했다. 위와 같은 형테이므로 여러건의 요청이 오게됬을때 하나의 과정 (요청을 보내고 응답을 받기까지) 이 마치고 난뒤에야 다음 요청에 대한 과정을 진행할 수 있는 구조였다. 그래서 여러건의 요청을 보내야 하는 요청-응답의 구조가 순차적이므로 상황에서는 시간이 오래걸릴수 밖에 없었다. 또한, 한가지 문제가 더 있었는데 똑같은 도메인에 대해 요청건을 많이 보내게 될 경우가 대다수인 브라우저 환경에서 새로운 요청을 보낼때 다시 TCP Connection 을 맺게 되는 경우 TCP 의 Slow Start 나, 다시 3-Wa..