대형 금융사의 PoC를 한 분기에 2번이나 하게 되다니, 정말이지 바쁜 2분기였습니다.

이번 회고에선 2개의 PoC를 진행하며 각각 무슨 일을 했는지를 되돌아볼까 합니다.

두 가지 도전 과제

버그 수정, 기능 개선과 신규 기능들으 여럿 개발했지만, 그 중 가장 기억에 남는게 두 가지가 있습니다.

2번의 PoC에서 요구되었던 사항들에 대해 얘기해볼까 해요.

첫 번째 과제, 유량 제어

첫 PoC에서 나온 요구 사항이었습니다. 어찌보면 처음 담당한 큰 규모의 기능 개발인 것 같아요.

제가 속한 팀이 담당하는 제품인 AnyLink는 Inbound / Outbound 어댑터를 통해 기관끼리의 연결, 통신을 담당하고 있어요.

보통 유량 제어, RateLimiter의 동작은 주로 서버가 감당할 수준의 요청만을 처리하기 위해 유입되는 트래픽을 제어한다고 생각합니다.

위 AnyLink 서비스 플로우 엔진 트리거링 사진에서 보면 Inbound Adapter에서 요청이 인입될 때 제어하는거겠죠.

그런데, 이미 유량 제어에 대한 설정 화면이 존재하네요.

이미 거래라는 단위로 유량을 제어하는 기능이 존재했는데, 간단히 말하면 호출되는 API별로 트래픽을 제어할 수 있었어요.

그렇다면 어째서 유량 제어 기능을 또 구현하게 된걸까요?

바로.. Outbound Adapter에서 트래픽을 제어하는 기능에 대한 요구였기 때문입죠.

이 부분에서 트래픽을 제어해야 합니다.

Flow Engine은 사용자가 정의한 Flow에 맞춰 동작을 수행하다가, Outbound에 대한 요구를 만나면 Delivery Channel을 통해 Outbound Adapter로 해당 동작을 위임합니다.

이런 저런 고민을 한 후, Outbound Adapter에서 외부로 요청을 보낼 때 제어 여부를 판단해 로직을 blocking하는 비교적 간단한 방법을 적용해봤어요.

blocking 하는 방법은 뭐.. 여러 가지가 있습죠. LockSupport를 이용하는 방법, CountDownLatch를 이용하는 방법, 아니면 Thread.sleep()이나 Thread.wait() 등..?

무엇을 이용했던 해당 방식으로 구현 후 테스트를 진행했습니다. 처음에는 아~~무 문제 없이 동작했죠. 구현한대로 많은 양의 트래픽을 발생시켜도 요청 우선 순위에 따라 거래를 수행했어요.

다만, 2가지 문제가 생겼는데

1. 스레드 고갈

인터페이스 프레임워크인 AnyLink는 사용자가 특정 거래에 대해 사용할 스레드 풀을 선택하고, 해당 스레드 풀의 최대/최소 스레드 수 등 자세한 설정을 할 수 있습니다.

blocking 방식의 문제는 여기서 처음 시작되는데...

최대 스레드 개수가 100개일 경우, 100개의 요청이 대기중이라면 유량 제어하는 거래와는 상관없는 거래들 또한 수행하지 못하게 되었습니다.

더 큰 문제는 Outbound Adapter만 멈추는 것이 아닌, Inbound Adapter 또한 동작을 할 수 없었다는거죠. 사용 가능한 스레드가 없으니깐요.

2. EventLoop blocking

거래에 사용하는 스레드풀이 마르는 현상뿐만 아니라 다른 문제도 존재했는데요. 참 문제가 많은 방식이었네요,,,

TCP Adapter는 기본적으로 비동기로 동작합니다. 외부로 요청을 보내는 메소드를 호출해도, 실제 요청은 이벤트 루프 스레드가 수행한 후 응답이 오면 콜백을 통해 알려주는 식이예요.

문제는 해당 어댑터 동작 과정 중 이벤트 루프 내부에서 재귀적으로 외부 요청을 수행하는 경우가 존재했다는거죠.

이벤트 루프가 외부 요청을 수행했을 경우, 해당 거래가 유량 제어 설정이 되어있다면 모든 요청을 처리하는 이벤트 루프 스레드가 blocking 되어버리는 대 참 사가 발생했습니다.

그래서?

그래서 기존 프레임워크의 동작에 맞게 비동기 방식으로 동작하도록 수정했습니다. 스레드 자체를 멈춰버리던 기존 방식을 버리고, Outbound Adapter가 유량 제어 설정을 확인하면 해당 정보를 RateLimiter에 전달하고, 수행하던 거래 흐름을 끊습니다. 이후 RateLimiter는 제어 설정과 우선 순위에 따라 저장해놨던 정보를 통해 Delivery Channel에 다시 전달하고, 거래가 다시 수행되는 흐름으로 변경했습니다.

다행히도 잘 동작했네요..!

두 번째 과제, HTTP 2.0

두 번째 PoC에서 나온 요구 사항이었습니다. 신규 프로토콜을 추가하는 요구에 대응하기 위해선 참 많은 것들이 개발되어야 했는데요.

연결 정보를 설정하는 웹 어드민에 설정 화면이 추가되어야하고, 데이터를 관리하는 데이터 통합 서버에 저장을 해야하며, 인터페이스를 정의하는 스튜디오에 설정하는 화면과 로직이 추가되어야 합니다. 마지막으론 거래 로직을 수행하는 런타임 엔진에도 기능이 추가되어야 하죠.

제품의 코어 로직을 제외한 모든 것을 추가해야하는... 그래서 작업량이 꽤 많았습니다.

HTTP 2.0 명세도 파악해야하고, 파악한 명세에 대해 설정 화면은 어떻게 가져갈건지, 어떤 방식으로 거래를 수행하도록 할 것인지 등등

프로토콜을 처음 추가해봤다보니 이런저런 버그들도 많이 생겼구요. (화면 출력이 잘 안된다거나,,, 이클립스 기반 어플리케이션 개발은 참 복잡한 것 같습니다) 기능 추가 완료 후에 확인해보니 1만줄가량 코드가 추가됐더라구요.

기회가 된다면 공부했던 HTTP/2에 대해 공유하는 글을 작성해볼까 해요.

마무리하면서

취업 준비할때는 글 쓰는게 참 재밌었던 것 같은데, 바쁘게 살다보니 글을 잘 안쓰게되고, 실력도 줄고, 재미도 없어지는 것 같아요,,

그래도 써야지.. 하면서 8월에 되어서야 2분기 회고를 들고 오네요.

이제 어느정도 적응도 했고, 최근엔 덤프 분석, 버그 분석부터 동시성 이슈도 몇 개 수행했습니다. 다만, 저런 세부적인 내용은 블로그에 자세히 쓰기 좀 그러니 3분기 회고엔 이런저런 쓸 이야기가 별로 없을 것 같네요 :(

다들 행복하셨으면 좋겠습니다! 그럼 안녕

굉장히 오랜만에 글을 작성하는 것 같아요. 글 쓰는 것 자체가 어색한 느낌이 드네요. :)

마지막 글을 쓴 24년 10월 이후로 많은 일들이 있었습니다. 취업도 하고, 본가에서 나와 자취도 시작하고.. 그러다보니 1분기 회고를 4월이 다 되어서야 적게 되네요.

3개월마다 회고를 적으려 했지만 한달이나 늦어버린 절 반성하면서.. 25년 1분기 회고를 시작하겠습니다.

진짜 회고

0. 취업

24년 12월, 운이 좋게도 한 회사에 취업했습니다. 3개월간의 수습 기간이 있었고, 적응하는데 집중했던 것 같습니다.

신입의 경우, 수습 기간동안 무언가를 하고, 이걸 기반으로 발표를 해야 했기에 이후 2달은 발표를 위한 수습 프로젝트를 진행했습니다.

1. 수습 기간

저는 AnyLink라는 인터페이스 프레임워크를 개발하는 팀에 속해 있습니다.

여러 서버, 어플리케이션, 프로토콜 간 통신을 중간에서 중개해주는 채널을 담당한다고 할 수 있을 것 같아요.

이 AnyLink에는 거래라는 개념이 있습니다. 간단하게 설명하면 중개를 진행한 하나의 요청 흐름 이라고 할 수 있을 것 같아요.

처음엔 간단한 이슈들을 진행하며, AnyLink에 대해 적응하고, 알아가는 시간을 가졌습니다. 백만줄 단위의 코드 베이스를 처음 접해보다보니 처음엔 너무 어려웠지만, 좋은 팀원분들이 많이 알려주셔서 빠르게 적응할 수 있던 것 같아요.

2. 수습 과제

거래에 장애가 발생했을 시, 문제를 추적하기 위해선 로그를 확인해야 합니다. 기존 로그는 많은 정보를 알려주고 있었습니다만, 수십, 수백, 수천, 수만 TPS를 감당하는 AnyLink의 로그에서 원하는 정보만을 찾는 작업은 힘들었어요.

초당 1000개의 요청을 중개한다고 생각해봤을 때, 1000개의 거래 로그가 뒤죽박죽 찍히고 있었고, 거래의 unique한 식별자를 검색하여 로그 라인을 봐야했거든요.

이런 불편함을 해소하기 위해 트랜잭션 로그 매니저라는 거래 단위로 로그 블럭을 찍어주는 시스템을 추가했습니다.

저런 식으로 동작하는데, 거래가 시작하고 끝날 때 까지 로그를 모아놓고, 종료 시 설정에 따라 해당 이벤트들을 한번에 로그로 변경하여 찍어주는 방식을 설계하고 개발했어요.

다만, 몇가지 걱정되는 부분이 있었는데

1) 실패 저항성

중요한 정보를 로깅하기 위해선 코어 로직에 트랜잭션 이벤트를 생성하는 과정이 필요했고, 이 과정에서 문제가 생긴다면 어플리케이션 자체가 중단될 수 있다고 생각했습니다.

Queue에 적재된 이벤트들은 거래가 끝나는 시점에 소비되고 사라지는데, 거래가 종료되기 전 죽어버린다면 갈곳 없는 이벤트들이 Queue에 적재될테고, 결국 OOM까지 발생할 수도 있는 상황이였어요.

최대한 분석을 진행했고, 개발 이후에도 여러 오류를 내보며 테스트를 진행했음에도 마음이 놓이지 않는 부분입니다.

테스트, 그리고 거래에 대해 저보다 더 잘 아시는 QA팀의 도움을 받아 해당 문제를 체크하는 방향으로 진행될 것 같아요.

2) 메모리 문제

1번처럼 문제가 발생해 GC가 제대로 이뤄지지 않는 경우에도 OOM이 발생하겠지만, 정상적으로 동작함에도 문제가 발생할 수 있어요.

트랜잭션 이벤트들은 이벤트가 종료(성공 혹은 실패)되기 전까지 이벤트들을 Queue에 적재해놔야 합니다. 거래 로직이 길어질수록 이벤트는 오래 살아남게되며, 요청이 많아질수록 Old Gen까지 살아남는 늙은 객체들이 많아질거예요.

결국, 높은 TPS와 복잡한 거래가 많은 환경에선 Full GC가 더 자주, 더 많이 발생할테고, 이는 여러 시스템 상의 채널을 담당하는 AnyLink에선 큰 문제가 될 것 같았습니다.

로컬에서 1000TPS까지 테스트했을 땐 기존과 크게 차이나진 않았지만, QA에서 더 높은 수준의 스트레스 테스트를 통해 정확한 성능 측정이 필요할 것 같았고, 만약 해당 기능을 사용할거라면 Young Gen 사이즈를 조금 더 크게 가져갈 필요가 있어보였습니다.

3) 성능 이슈

이벤트를 소비해 로그로 변환하는 과정에선 문자열 연산이 발생합니다. 물론 가변 인자를 사용해 파라미터를 전달받고, 로깅이 가능할 때만 문자열 연산을 진행하도록 구현했지만, 로깅이라는 부가적인 로직이 주요 로직에 영향을 줄 수도 있을 것 같았어요.

이 부분 역시 로컬에서의 테스트로 확인하기엔 한계가 있었기에 QA팀의 도움을 받기로 했습니다.

3. 수습 발표

발표엔 생각보다 많은 분들이 참여해 주셨습니다. 실장님, 타 팀의 팀장님, 그리고 같이 일하는 저희 팀장님과 팀원분들이 참석해주셨고, 다양한 질문을 해주셨어요.

그 중 기억나는 질문은 아래와 같았습니다.

1) 매 거래마다 Queue를 생성하는 방식은 성능 문제가 발생하지 않을까요?

다양한 의견들이 많았지만, 제가 내린 결론은 "영향이 미비하다" 였습니다.

하나의 Queue 객체의 생명주기는 거래가 시작하고 끝날 때 까지이고, 이와 동일한 시점에는 아무리 적어도 5개의 트랜잭션 이벤트가 발생합니다.

빈 Queue 객체의 생성 비용이 그렇게 크다고 생각하지 않았으며, 문제가 발생한다면 트랜잭션 이벤트 객체의 생성과 삭제에 의해 발생될 것이라고 생각했어요.

이 문제는 Queue에 대한 처리가 아닌 트랜잭션 이벤트 객체를 재사용하는 방식, LMAX Disruptor 혹은 트랜잭션 로그 매니저를 별도의 외부 어플리케이션으로 추출하는 방법이 필요할 것 같다고 판단했습니다.

2) 지금도 웹 어드민에서 거래 트레이스를 볼 수 있는데, 필요 없는 것 아닌가요?

그럴 수 있다고 생각합니다. 다만, 트레이스의 경우 어디서 문제가 발생했는지는 한 눈에 볼 수 있겠지만, 명확한 원인 파악이 힘들며, 거래량이 늘어날수록 수많은 트레이스를 조회하는 DB에 부하가 많이 가해져 대형 고객사에선 잘 사용하지 않는 상황이었습니다.

또한, 예외의 트레이스를 볼 수 없기에 로그 파일에 적재되는 엔진 로그를 봐야했는데, "트랜잭션 로그 매니저"는 엔진 로그에서 거래 흐름과 문제가 발생한 부분, 스택 트레이스를 모두 볼 수 있습니다.

특정 거래, 대상 시스템에 대해서만 로깅할 수 있도록 구현했기에 디버깅에 도움이 될 거라고 생각합니다.

마치면서

아직 QA팀에서 테스트가 끝나지 않아 무슨 문제가 발생했는지 모르는 상태예요.

또한, 꽤나 큰 규모의 POC에 참여하느라 굉장히 바쁜 나날을 보내고 있습니다.

새로 구현중인 기능인 전송 유량제어(타겟 시스템으로의 유량 제어) 기능도 고민할 거리가 많아 재밌습니다.

3달 뒤 2분기 회고에선 POC를 진행하며 발생했던 문제들, 이슈를 진행하며 했던 고민들에 대해 적어볼까 합니다.

긴 글 읽어주셔서 감사합니다!

ps. 너무 오랜만에 글을 쓰니 너무 힘드네요,,, 책 좀 많이 읽어 필력을 길러야겠습니다.

모두의 음악 프로젝트는 그룹 기반의 커뮤니티 서비스입니다. 특정 내용의 게시글 검색 기능이 필요한 상태예요.

사용자 A는 일렉 기타 에 관한 게시글을, 사용자 B는 클래식 에 관한 게시글을 보고 싶을 수 있거든요.

검색 기능

기본적으로 문서의 내용 전체를 검색하는 전문(fulltext) 검색이 필요할 것 같아요.

1. LIKE

가장 간단하게 실행해볼 수 있는 LIKE 키워드를 통해 해당 기능을 구현해봤어요.

일본 이라는 텍스트를 검색했을 때 605ms, 즉 0.6초가 걸렸네요. 빠른 응답까진 아니더라도 사용하지 못할 정도는 아니라고 느껴졌어요.

보다 덜 사용될 것 같은 데카르트 라는 단어를 검색해봤습니다. 3.15s 라는 좋지 않은 결과가 나왔네요. 슬슬 문제로 인식되기 시작했어요.

머스탱 이라는 단어를 검색하니 무려 8.19s가 걸렸습니다. LIKE의 경우, 페이지를 채우기 위한 데이터 개수를 찾기 위해 레코드의 평문을 순회하며 확인하게되고, 이 때문에 사용 빈도가 적은 키워드의 검색에 오랜 시간이 걸리는 것 같아요. LIKE 연산의 경우 index를 타지도 않으니 지금 상태로는 시간을 줄이기 힘들겠네요.

2. mysql fulltext index

전문 검색을 위해 MySQL이 지원하는 FULLTEXT 라는 인덱스가 존재합니다. 이는 inverted index 방식으로 동작하며, 단어가 포함된 문서를 저장하여 빠르게 검색할 수 있도록 도와줘요.

검색할 필드인 content 컬럼에 FULLTEXT 인덱스를 적용했습니다.

인덱스 설정에 2시간이 걸렸어요. 운영되는 서비스일 경우엔 시간대를 잘 선택해야 할 것 같아요.

기존에 원하던 기능인 단어가 포함된 게시글을 검색하기 위한 쿼리를 작성해봤습니다. 일본 검색의 경우 기존 0.6s 가 걸렸지만 인덱스를 적용하니 2.49s 로 증가했어요.

뭔가 이상해 기존에 8.19s 가 걸린 머스탱 검색을 해봤습니다. 0.1s 만에 완료되네요.

혹시 FULLTEXT 인덱스를 선택하지 않는 걸까? 실행 계획을 확인해봤습니다. 인덱스는 정상적으로 선택하네요. 다만, 정렬에 filesort 를 사용한다고 해요.

정렬을 하지 않는 일본 키워드 검색은 어떤 성능을 보일까요? order by 구문만 제거했음에도 0.1s 이하로 내려왔네요. filesort 에 의해 성능이 저하됨을 확인했어요.

왜 filesort 가 발생하는지에 대한 두가지 가정을 세워봤습니다.

1. 너무 많은 데이터에 대한 정렬을 시도함

첫번째는 정렬에 사용되는 sort_buffer 을 초과할 데이터에 대해 정렬을 시도해 filesort 가 발생했다는 가정이예요.

sort_buffer 를 기존 256kb에서 8mb로 변경했음에도 여전히 filesort 가 발생합니다.

이 가정은 아닐 확률이 높고, 맞다고 해도 sort_buffer 크기를 데이터 크기가 증기함에 따라 키울 수는 없기에 FULLTEXT 인덱스를 사용하긴 힘들 것이라는 생각이 드네요.

2. 인덱스 선택

FULLTEXT 인덱스는 연관성 점수를 측정한다고 합니다. inverted index 라는 특징 때문에 일반 인덱스로 지정할 수 없죠.

현재 실행 계획은 FULLTEXT 인덱스를 사용하는 것으로 결정됐고, 실제로도 이 계획이 모든 레코드를 순회하는 것보다 좋을 거예요. 다만, 이럴 경우 index를 정렬에 사용할 수 없기에 filesort 가 발생했고, 자주 사용되어 많은 결과가 나오는 키워드에 대해 좋지 않은 성능을 보여준 것이죠.

검색 기능을 2.49s 까지 줄였지만 아직도 사용할 수 없는 수준이네요.

3. 전문 검색엔진 도입

결국 전문 검색 엔진인 ElasticSearch 를 도입했습니다.

데이터 이관

이를 사용하기 위해선 몇가지 사전 준비가 필요했어요. 데이터 저장소인 MySQL 과 ElasticSearch 간의 데이터 정합성(sync)를 맞춰야하며, 기존에 존재하던 300만건의 게시글 데이터 또한 ElasticSearch 에 옮겨줘야하죠.

ELK Stack이라 불리는 ElasticSearch + Log stash + Kibana 의 조합을 많이 사용하지만, 프로젝트에 이미 Kafka 를 사용중이기에 Kafka Connect를 사용했습니다.

데이터 이관 및 sync 작업에 대한 내용은 추후 기회가 된다면 다른 게시글에서 다뤄볼게요!

검색 테스트

ElasticSearch 에서 게시글의 identifier인 ID 를 조회하고, 해당 데이터를 통해 MySQL 에서 데이터를 반환해줬습니다.

이제 MySQL 에서 테스트해봤던 여러 키워드들을 조회해볼까요?

1. "일본" 검색 → 68ms

2. "머스탱" 검색 → 66ms

3. "드루이드" 검색 → 54ms

4. "데카르트" 검색 → 55ms

평균 60ms의 굉장히 빠른 성능을 보여줍니다. 이제 실제 서비스에서 사용할 수준이 된 것 같아요! 배포 후 동작을 확인해볼까요?

만족스러운 결과네요!

참고 자료

MySQL 문서 - FULLTEXT

FULLTEXT 인덱스가 매우 느림 - StackOverflow

모두의 음악은 네이버 밴드와 같은 커뮤니티 기반의 게시판 서비스예요.

유명 커뮤니티인 인벤과 루리웹에서 추출한 총 47만개의 게시글 데이터를 반복해서 삽입, 총 300만개의 게시판 데이터를 삽입했습니다.

이제 게시판이 제대로 동작하는지 확인해볼까요?

페이징 쿼리 개선

시작하자마자 문제가 발생했네요. 일반적인 게시글 조회에 총 4분 51초가 걸렸습니다.

쿼리는 의도한대로 발생하는 것 같아요.

다만, 단 한번의 요청만으로 서버의 부하가 엄청나게 상승했습니다. 가장 많이 발생할 요청이기에, 동시 접속자가 10명만 되어도 서버가 터질 것 같아요.

QueryDSL의 페이징 쿼리를 확인해봤습니다. 아차, 여기서 실수가 있었네요.

JPA의 fetch-join을 사용해 JOIN 과 Pagination 을 하나의 쿼리에서 수행할 시 모든 데이터를 메모리에 올린 후 자체적으로 페이징을 처리합니다.

이 때문에, 3백만건의 데이터를 모두 자바 어플리케이션에서 처리해 문제가 발생한 것 같아요.

페이징과 실제 조회 쿼리를 분리했습니다. 페이징 쿼리에서 조회할 데이터들을 찾고, 찾은 데이터들만 조인을 통해 조회하는거죠.

쿼리를 분리함으로써 4분 51초에서 0.1초로 응답 시간이 개선됐네요. 서버에도 비정상적인 부하가 발생하지 않을거예요.

글자수 제한

페이징을 테스트하던 중 데이터 크기가 급격히 늘어났어요. 이유를 보니 엄청난 장문의 글이 포함되어있네요. 가장 긴 게시글을 찾아보니 78만자의 내용을 갖고 있네요.

게시글 목록에서 모든 데이터를 노출시키지 않을 것이기 때문에 모든 데이터를 보내는 건 불필요하다고 생각했습니다. 이에, 미리보기를 위한 내용 300자만 보내는 것으로 결정했어요. 해당 게시글을 단건으로 조회할 때 모든 데이터를 보내주는거죠.

추가적으로 DTO 반환을 채용함으로서 불필요해진 fetch-join과 필요 없던 group 테이블 조인을 제거해줬어요.

자, 이제 바뀐걸 확인해볼까요?

데이터 크기가 168kb -> 4.4kb로 164kb(97.3%) 감소했고, 응답 시간 또한 115ms -> 71ms로 44ms 감소했네요.

모두의 음악 프로젝트엔 가상의 결제 서비스 가 존재합니다. 이 결제 기능 은 두가지 조건을 가정하고 있어요.

1. 결제 과정에 꽤 긴 시간이 소요된다.
2. 결제 실패 후 단순 재시도 시 중복 결제가 발생한다.

1번의 경우 Kafka를 도입해 비동기 통신으로 전환했으며, 2번은 DB를 통한 이벤트 추적 방식으로 처리된 시점을 기록해 중복 결제를 방지했죠.

왜 비동기를 사용해야 할까?

Springboot의 기본 WAS인 Apache Tomcat은 Thread per Request, 즉 하나의 요청을 하나의 스레드가 전담하여 처리합니다.

Thread 생성 비용을 줄이기 위해 ThreadPool을 통해 스레드를 재사용하게 되는데, 이 때문에 시간이 오래 걸리는 작업이 존재한다면 해당 스레드가 반납되지 않고 오래 점유되어 스레드를 할당받지 못한 요청들이 대기를 하게 되죠.

그게 얼마나 큰 차인데?

말로는 알아도 얼마나 차이가 날지는 잘 모르겠어요. 그래서 해봤습니다!

Sync vs Async 실험

전제

보다 극적인 성능 차이를 관측하기 위해 결제 기능 에 5초 의 sleep을 주었습니다. 이제 결제 기능 은 실행 시 5초 가 걸리는 엄청난 동작이 된거죠.

Sync with RestTemplate

동기 방식의 실험은 위 그림과 같은 흐름으로 진행했어요. 프로젝트가 MSA 구조를 띄고 있다 보니, API-GATEWAY 를 통해 HTTP 요청을 보냈죠.

이제 GROUP-SERVICE 에서 발생한 요청과 그에 대응하는 스레드는 PAYMENT-SERVICE 의 처리가 끝나야 같이 마무리 될 거예요.

JMeter 결과

요청 조건은 다음과 같습니다.

payment → Thread 30, Ramp-up : 10, Duration : 300 search → Thread 50, Ramp-up : 1, Duration : 300

시간이 지날수록 search 기능의 속도가 기하급수적으로 느려졌어요. 이는 오랜 시간을 필요로 하는 payment 기능이 대부분의 스레드를 점유하고 있기 때문이죠.

결과적으론 약 12TPS의 성능을 보여줬네요.

Grafana

스레드 상태를 모니터링해보니 timed-waiting 이 많이 늘은 걸 볼 수 있었어요. 많은 스레드들이 결제 기능 에 묶여있는 걸 확인할 수 있었죠.

Async with kafka

그렇다면 Kafka를 통한 비동기 방식은 어떨까요? 요청 조건은 위와 동일하게 설정했어요.

JMeter

처음엔 잘못 본 줄 알았습니다. 1006 TPS를 기록했네요. 기존과 89.82배나 차이나는 결과를 얻었습니다.

Grafana

스레드 상태는 기존과 차이가 별로 없네요.

비교

두 요청의 스레드 상태 변화를 관측했더니 굉장히 유사한 모습을 보여줍니다. 다만 성능은 89배 차이라는 점..!

비동기 적용 이후

드라마틱한 성능 향상을 보여준 비동기, 드디어 광명 찾은걸까요?

컨슈머 랙

카프카 컨슈머 랙을 확인해봤습니다.

또 잘못본 줄 알았습니다. 요청된 결제 기능 11만 9100건 중 11만 8900건이 처리되지 않고 대기중이네요.

결국 실질적으로 결제 처리가 된건 약 200건밖에 되지 않는다..는 겁니다.

이러면 안되는거 아니냐

실제 처리된 결제 기능 의 수는 조금 아쉽지만, 그럼에도 불구하고 굉장한 효과가 있어요.

GROUP-SERVICE는 더이상 결제 성능에 영향을 받지 않습니다.

기존 결과를 다시 봐볼까요?

오래 걸리는건 결제 기능 인데도 불구하고, 단순한 조회 요청에 대한 성능도 엄청나게 떨어졌죠.

Tomcat 자체 성능에 영향을 끼치는 스레드 점유 문제를 해결한 것만으로도 충분히 제 할일을 해주었다고 봐요.

그럼 컨슈머 랙은?

결제 기능 이 5초나 걸리는 조금 과장된 전제가 깔려서일까요? 굉장한 컨슈머랙이 발생했는데요.

발생한 요청의 개수는 5분간 약 12만건, 분당 2만 4천건의 결제 이벤트가 발생합니다. 컨슈머랙을 완전히 발생시키지 않으려면 초당 400건의 이벤트를 처리해야 하고, 5초가 걸리는 특성 상, 해당 토픽의 파티션과 컨슈머 그룹의 컨슈머 개수가 약 2000개는 되어야겠네요.

이전 포스트에서 이어지는 내용입니다. 이전 내용을 모르셔도 읽는 데 지장은 없어요!

지극히 개인적인 의견이 담긴 글입니다.

어벤져스 인피니티 워에선 지식의 저주라는 말이 나옵니다. 영화에선 아이언맨이 불확실한 미래(위협)를 기술(아이언맨 슈트)로 해결하려는 것을 의미했어요. 다만, 실제로 사용되는 의미는 조금 다릅니다.

대화

1. 지식의 저주

지식의 저주의 원래 의미는 뭘까요? 위키백과엔 다음과 같이 정의되어 있네요.

지식의 저주(curse of knowledge)란 어떤 개인이 다른 사람들과 의사소통을 할 때 다른 사람도 이해할 수 있는 배경을 가지고 있다고 자신도 모르게 추측하여 발생하는 인식적 편견이다.

조금 다르게 표현해보자면 상대방의 수준을 오해해서 생기는 문제라고 생각됩니다.

일상생활에선 이 지식의 저주에 걸린 대화가 종종 발생합니다. 게임을 할 때, 관심사가 다른 친구와 대화할 때, 지인에게 운전을 알려줄 때 등, 내겐 당연하다고 느껴지는 것들이 타인에겐 당연하지 않을 때가 존재하죠.

2. 대화의 수준

이전 포스트에서 말했듯, 효율적인 대화는 목적과 수준을 만족해야 한다고 생각합니다. 대화의 목적은 상호 간 공통된 관심사를 달성하기 위함이며, 간단하게 말하면 듣고 싶은걸 말해줘야 한다였어요.

반면, 대화의 수준은 위에서 언급했던 지식의 저주와 관련이 있습니다. 이 지식의 저주는 비단 지식의 수준 뿐만 아니라, 상황에 대한 이해가 부족할 때, 특정 산업군에서만 통용되는 단어를 사용할 때 등 다양하게 나타납니다.

3. 해커톤에서의 경험

얼마 전 F-Lab에서 개최한 해커톤에 참여했습니다. 주어진 토픽에 대해 아이디어를 도출하는 단계였어요. 브레인스토밍을 통해 다양한 아이디어를 모으고 있었죠.

해커톤에 대한 자세한 내용은 별도의 포스트로 다뤄볼게요!

이 과정에서 지식의 저주를 몸소 실천해버렸습니다..! 어떤 대화가 오갔는지 확인해볼까요?

나 : ○님! 다른 분들이랑 주기적으로 진행하시는 스크럼이 있지 않으신가요?! ◇ : ??? △ : ?????? ○ : 아, 제가 주기적으로 다른분들과 회고를 진행하는데요! 이후 생략...

갑자기 생각난 아이디어에 너무 신나버렸고, 결국 다른 팀원들의 경험을 고려하지 못했죠.

정말 다행히도 저주에 면역이 있는 팀원분이 빠르게 AS 해주셨습니다! 하하...

4. 보다 일상적인 예시

개인적인 경험은 잠깐 뒤로하고, 조금 더 일상적인 예시를 봐볼까해요.

판교 사투리에 대해 알고 계신가요?

엄...

판교에서 일을 해보지 않은 저는 이해하기 조금 힘들었는데요. 그렇다면 위 대화가 안좋은 대화, 대화의 수준을 맞추지 못했다고 말해도 될까요?

결론부터 말하면 아니라고 생각합니다. 효율적인 대화라는건 의사 전달을 잘 하기 위함이고, 이를 위한 대화의 목적과 수준은 청자, 즉 대화에 함께 참여하는 사람에 의해 정해진다고 생각하거든요.

물론 위 대화가 판교 근처에 가본적도 없는 저와 같은 사람을 대상으로 한다면 좋지 않은 대화라고 생각합니다. 화자가 잘못된 수준을 선정했기에 의사 전달이 효율적으로 이뤄지지 않을 것이라 생각해요.

5. 누구보다 착한 고인물

높은 곳에서 내려다보면 세상은 작게 보인다.

라는 말을 종종 하곤 합니다. 이미 깨달음을 얻은 사람은 깨닫지 못한 사람의 수준을 알지 못한다는 의미로 사용하는데요.

대학교에서 기초 과목 멘토링 멘토 역할을 할 때도, 졸업 후 F-Lab에서 멘티로 중급 개발자 교육을 받을 때도 수준이 다르면 볼 수 있는게 다르다라는 생각을 항상 했던 것 같아요.

見樹不見林, 견수불견림 : 나무는 보되 숲은 보지 못한다.

당장 눈 앞에 보이는 지엽적인 것만 좇지 말라는 좋은 의미가 담겨있지만, 조금 다른 시각으로 바라봐볼까 해요.

숲을 보기 위해선 어떻게 해야 할까요?

• 나무보다 큰 키로 태어나 자연스럽게 숲을 보게 되었다던가 (재능)
• 숲 밖으로 나가 외부에서 숲을 본다던가 (노력)

하는 과정이 필요하다고 생각합니다. 숲 안에서 나무 밑동만 보고 자란 사람은 숲이 어떻게 생겼는지조차 모를테니까요.

본론으로 돌아와서, 시야가 다른 두 사람이 같은 주제로 대화하기 위해 필요한 최소한의 조건은 수준, 눈높이를 맞추는 것이라 생각합니다. 올려다 보는건 한계가 명확하니 해당 상황에 더 높은 수준을 가진 사람이 맞춰줘야겠죠.

뉴비를 게임에 적응시키기 위해 눈높이를 맞춰주는 고인물이야말로 누구보다 친절한 대화를 실천하고 있던게 아닐까요..!

마치며

효율적인 대화의 두번째 조건인 대화의 수준에 대한 생각을 적어봤어요. 막상 글을 적고나니 대화의 목적때와 비슷하게 당연한 말들만 잔뜩 풀어낸 것 같네요.

커뮤니케이션에 대한 새로운 생각이 떠오르면 돌아오겠습니다..! 긴 글 읽어주셔서 감사해요!

이전 두 포스트에선 MSA 환경에서 결제를 담당하는 payment-service 에 결제를 요청, 처리하는 과정에 대해 알아봤어요.

이번 포스트에선 결제 처리 과정에서 발생할 수 있는 실패 시나리오를 생각해보고, 어떤 방식으로 해결할지에 대해 적어볼까 해요.

시나리오

1. 결제 요청 실패

group-service 가 어떠한 이유로 결제 요청 이벤트 발행에 실패했을 경우입니다. Kafka에 문제가 생겼거나, group-service 내부 로직에서 예외가 발생하는 등 메시지가 미들웨어에 도착하기 전 문제가 발생한 경우죠.

이 경우, 크리티컬한 문제가 아니라고 생각했습니다. 결제 프로세스 자체가 진행되지 않을 뿐더러, group-service 에서 재시도 로직을 진행하던가, 진행되지 않았다고 알려주기만 한다면 사용자가 얼마든지 재시도할 수 있을 거예요.

물론 UX에는 안좋겠지만..!

2. 결제 실패

결제 요청 이벤트 가 성공적으로 발행된 후 실패한 경우입니다. 아래 상황들을 고려했어요.

1. 이벤트를 받지 못함

먼저, 이벤트 컨슘에 문제가 생긴 경우를 생각했어요. 데이터 포맷 이 다르다던지, 컨슈머에 장애가 발생하는 등의 상황이 존재할 것 같아요.

데이터 포맷 에서 문제가 생길 경우, 이 요청은 절대로 실행되지 않을거예요. 다행히도, Kafka에는 이벤트 컨슘 실패 시 재시도 로직이 존재합니다. 또한 Spring Kafka 는 ErrorHandler를 통해 Dead Letter Queue 를 간편하게 사용할 수 있도록 지원합니다.

2. 내부 로직에서 예외가 발생

애플리케이션 로직 혹은 결제 중 문제가 발생한 경우입니다. 잔액 부족 등으로 인해 결제가 실패한 경우죠.

3. 선택

위 상황들을 포함해 결제 실패 라는 상황 자체는 크리티컬하지 않다고 생각했어요. 서비스 이용에 불편하겠지만, 결국 금전적인 손해는 일어나지 않았기 때문이예요.

이 경우에도, 1번 상황의 결제 요청 실패와 동일하게 재시도 로직, 실패 알람 등으로 해결 가능할 것이라 생각했습니다.

3. 결제 성공 이벤트 발행 실패

이번 포스트에서 주로 다룰 케이스예요.

결제 성공 후 어떠한 이유에 의해 이벤트 발행이 실패한 경우예요. 돈은 나갔는데, 피드백이 없는 경우죠. 이 케이스가 가장 크리티컬하다고 생각했습니다.

4. 결제 성공 이벤트 수신 실패

2번의 결제 실패, 그 중 1. 이벤트를 받지 못함과 유사한 상황이라고 생각해요. 다만 결제가 이미 진행됐기에, 보다 빠르게 피드백이 이뤄질 필요가 있어보여요.

실패 처리

이제 위 시나리오들을 순서대로 고려하며 실패에 대한 처리를 진행해볼게요.

1. 재시도

가장 먼저 고려한 방법입니다. 실패한 요청에 대해 반복하여 시도해보는 가장 단순하면서도 직관적인 방법이라고 생각해요.

이 방법의 경우, 1. 결제 요청 실패 케이스에서 발생하는 문제를 대부분 해결할 수 있을 것 같아요. 다만 아래의 두 케이스에 대해선 동일한 작업을 반복해도 영원히 실패할 수 밖에 없겠죠.

1) 잘못된 계좌 번호가 들어옴

2) 잘못된 포맷의 이벤트 발행

2. Dead Letter Queue(DLQ)

잘못된 계좌 번호가 들어옴 등, 사용자의 요청 자체가 잘못된 경우엔 사용자로부터 제대로 된 요청을 다시 입력받아야겠죠.

1) 사용자에게 정상 데이터 요청

그렇다면 잘못된 포맷의 이벤트 발행은 어떨까요? 이는 어플리케이션에서 발생하는 문제예요. 자체적으로 재시도를 하던가, 사용자로부터 다시 정보를 입력받는 방법으로는 절대로 성공할 수 없을 것이라 생각해요.

위 케이스를 해결하기 위해선 어플리케이션 로직 수정이 필요해요. 여유롭게 수정하고 처리할 수 있다면 정말 좋겠지만, 해당 이벤트 이후에 발급된 정상적인 이벤트들 또한 처리되지 않고 무한정 대기하게 되겠죠.

다행히도, 이러한 문제를 해결하기 위해 Dead Letter Queue 라는 방법이 존재합니다. 반복적으로 실패하는 이벤트를 별도의 실패 토픽에 옮기는 방식이예요. 이를 통해 잘못된 이벤트 이후의 정상 데이터를 처리할 수 있게 되겠죠.

2) 실패한 이벤트를 저장, 문제 해결 후 재시도

3. 이벤트 저장

이벤트 처리가 불가능한 케이스에 대한 처리를 진행했어요. 이제 문제 없이 동작할까요? 아쉽게도 여전히 문제가 존재하네요.

결제 성공 후 이벤트 발행 실패 케이스를 다시 봐볼까요?

결제가 성공해 이미 고객의 돈은 빠져나갔습니다. 하지만, 이후의 어떠한 로직이 실패했고, 결국 결제 성공 이벤트 발행에 실패했네요. 이 경우에도 반복되지 않는 문제라면 단순한 재시도를 통해 해결할 수 있을테고, 반복되는 문제라면 DLQ를 통해 해결할 수 있지 않을까요?

정말 슬프게도 그렇게 되지 않았습니다. 결제 성공 후 동일한 이벤트를 재시도 할 경우, "결제 자체가 다시 실행된다", 즉 중복 결제가 발생한다는거죠.

이러한 문제를 해결하기 위해 이벤트를 저장, 추적 하는 방식을 사용했습니다.

실패 처리 흐름

1. 도식

중복 결제를 방지하기 위한 흐름은 아래와 같습니다.

1) 이벤트 정보 저장

이벤트 발생 시 발생한 정보를 저장합니다. 저는 RDBMS를 사용해 저장했어요.

2) 이벤트 커밋

이벤트를 저장하고 난 뒤 곧바로 해당 이벤트를 커밋합니다. 저장된 후의 이벤트는 RDBMS가 책임지지, Kafka의 책임이 아니니까요.

커밋되지 않는다면 도중에 실패한 이벤트를 다시 꺼내와서 처리할테고, 이는 결국 중복 결제로 이어지겠죠.

3) 결제 진행 및 결제 결과 기록

결제를 진행한 후, 결과를 기록합니다.

다만, 프로젝트엔 해당 부분이 실제로 구현되어있진 않습니다. :)

4) 결제 성공 이벤트 발행

결제에 성공했을 시 결제 성공 이벤트를 발행합니다. 실패했을 경우엔 해당 단계는 건너뜁니다.

5) 이벤트 처리 시점 기록

모든 로직이 처리된 후의 시점을 기록합니다. 결제 성공 여부와는 관계없이 모든 이벤트에 동일하게 적용되는 부분이예요.

2. 구현

1) 이벤트 정보 저장 & 커밋

acknowledge() 호출 시 즉시 커밋을 진행하는 MANUAL_IMMEDIATE 설정을 사용했어요. MANUAL 설정의 경우, 다음 poll() 동작이 진행될 때 커밋되므로 즉시 커밋해야하는 지금과 같은 상황엔 MANUAL_IMMEDIATE 설정이 필요합니다.

이벤트를 컨슘한 후, 곧바로 이벤트의 정보를 저장합니다. 이후 이벤트를 소비했음 을 의미하는 커밋을 진행해요.

2) 이벤트 처리

이벤트를 처리하는 실질적인 부분입니다. 저장된 이벤트를 찾아 결제를 진행하고, 이벤트 결과를 기록합니다. 나머지 로직을 진행하고, 이벤트가 완전 처리된 시점을 기록합니다.

3. 효과

이러한 방식을 통해 어떤 효과를 얻을 수 있을까요? 바로바로... 이벤트가 어디까지 진행됐는지를 추적할 수 있다는 거예요!

1) 이벤트 컨슘 실패

이벤트의 책임이 아직 Kafka에 존재합니다. 여기서 실패할 경우, 재시도 혹은 DLQ를 이용해 시패 처리를 진행하면 되겠죠.

2) 결제 여부 저장 안됨

데이터베이스에 결제 성공 여부가 저장되지 않은 경우입니다. 이는 결제가 진행되며 문제가 발생했음을 의미하며, 결제 자체를 재시도해야겠죠.

3) 이벤트 처리 시점 저장 안됨

데이터베이스에 이벤트 최종 처리 시점이 저장되지 않은 경우입니다. 이는 결제가 진행됐으며, 이후의 로직에서 문제가 발생했음을 의미해요. 중복 결제가 발생하는 실질적인 부분이지만, 현재는 결제가 진행됐는지를 알 수 있기 때문에 방지할 수 있죠.

현재 어플리케이션에선 결제 성공 여부를 보고 성공이라면 성공 이벤트 발행 동작만 재시도 하면 될 거예요.

마치며

DB에 이벤트 진행 과정을 기록함으로써 중복 처리를 피하는 로직을 구현해봤어요. 다만 실질적인 재시도 로직은 아직 존재하지 않습니다. 이는 추후 배치 프로그램을 추가 개발해 처리할 예정이예요!

지극히 개인적인 의견이 담긴 글입니다.

커뮤니케이션

상호 간 소통을 위해 사용되는 매체로는 구어(口語)와 문어(文語)는 물론 몸짓, 자세, 표정, 억양, 노래, 춤 등과 같은 비언어적 요소들까지 포함된다.

위키백과에 나와있는 커뮤니케이션의 정의입니다.

학교를 가고, 친구를 만나고, 업무를 할 때 조차 우리는 다양한 사람들과 소통합니다. 위에서 말했듯, 커뮤니케이션엔 말 뿐만 아니라 표정, 눈빛 등도 포함됩니다.

앞으로 3개의 포스트에 걸쳐 커뮤니케이션 중, 구어와 문어에 대한 생각을 적어볼까 해요. 편의를 위해 대화라고 간단히 표현할게요.

대화

1. 좋은 대화의 조건

만약 좋은 대화라는게 있다면, 어떤 대화가 좋은 대화일까요?

다시 한번 위키백과의 힘을 빌려보니, 공손성의 원리(정중어법) 이라는 것이 있네요.

간단하게 요약하자면 겸손하되, 비방하지 말며, 의견이 다름을 강조하지 말고, 부담되는 표현을 피하며, 칭찬을 많이 하라는 것입니다.

정중어법은 배려하는 소통을 위한 최소한의 규칙을 나타낸 것 같아요.

다시 생각해보니 좋은 대화라는 표현이 모호한 감이 있네요. 물론 배려하는 소통 또한 중요하지만, 최소한의 노력으로 최대 효과를 끌어내는 효율적인 대화를 위해선 어떻게 해야 할까요?

효율적인 대화는 목적과 수준을 만족해야 한다고 생각합니다. 이번 포스트에선 대화의 목적에 대해 이야기해볼게요.

2. 목적이란

목적이란 뭘까요? 또 다시 위키백과의 힘을 빌려야겠어요.

목적(目的)이란 어떤 것을 하는 목표를 의미한다.

우리는 어떠한 목적을 갖고 대화합니다. 일상에서 발생하는 간단한 대화들을 생각해볼게요.

병원에 가면 의사는 환자의 증상을 정확히 파악하고, 적절한 치료를 하기 위해 여러 대화를 합니다. 마찬가지로, 카페 종업원은 손님이 무슨 음료를 시킬 지 알기 위해 대화를 하죠.

반대로, 환자는 의사에게 제대로 된 치료를 받기 위해선 증상을 명확하게 전달해야 합니다. 또한, 손님은 카페 종업원에게 어떤 음료를 먹을지 자신의 의사를 명확히 전달해야 하죠.

이렇게 생각해보니, 대화는 상호 간 공통된 관심사를 달성한다는 목적을 갖는 것 같아요.

3. 몇가지 예시

애니메이션 "에반게리온" 에선 로봇 조종사인 주인공 일행과 장군 간 재밌는 대화가 나옵니다.

장군 : 자네들이 할 일이 무엇인지 아나? 조종사 : 로봇을 조종하는거요. 장군 : 아니? 이기는거야.

조금 다른 버전으로 볼까요? 소프트웨어 개발자와 고용주의 관계로 생각해볼게요.

고용주 : 자네들이 할 일이 무엇인지 아나? 개발자 : 좋은 아키텍처, 클린 코드, ... 고용주 : 아니? 잘 동작하게 하는거야.

애석하게도, 위 대화들은 공통된 관심사에 대해 말하고 있지 않습니다. 두 사람이 서로 다른 목적을 갖고 있죠. 이래선 효율적인 대화가 이뤄지긴 힘들거예요.

4. 조금 더 구체적인

보다 일상에서의 예시로 다시 살펴볼게요. 이번엔 PC를 사려는 고객과 영업 사원의 관계를 가정하겠습니다.

고객 : 이 컴퓨터는 뭐가 좋죠?

위 질문에는 어떤 대답을 해야 할지 생각해볼까요?

사원1 : 이 컴퓨터는 HDD가 아닌 SSD가 들어가 기존 PC보다 더 빠르게 작동합니다!

사원2 : 이 컴퓨터는 HDD가 아닌 SSD가 들어갔는데, 헤드를 물리적으로 움직여 데이터를 읽는 HDD와는 다르게 어쩌구 저쩌구...

사원2는 이번 달 실적을 보면 조금 슬플 것 같네요.

5. 결론

위의 예시들을 통해 궁극적으로 전달하고 싶은 내용은 상대방이 원하는 정보를 제공해야 한다 즉, 듣고 싶은걸 말해줘야 한다는 거예요.

소프트웨어 장인 139 페이지엔 다음과 같은 내용이 나옵니다.

고객들, 고용주들이 관심 있는 사항은 소프트웨어가 그들의 필요를 충족시키느냐이다.

소프트웨어 사용자들은 소프트웨어가 제대로 동작하기만 하면 됩니다. 어떤 아키텍처로 구성되어있는지, 어떤 개발 방법론으로 개발을 진행했는지는 중요하지 않다는 거죠.

무조건 간단히 말하라는게 아닙니다. 대화 상대가 고객, 고용주가 아니고 개발 팀장이라면 개발 팀장이 듣고 싶어하는 말을 해야겠죠.

마치며

효율적인 대화의 조건 중 대화의 목적에 대한 생각을 적어봤어요. 적어보니 굉장히 당연하고 사소한 것처럼 느껴지지만, 이런 사소한 것들이 모여 상대방의 필요와 관심사를 정확히 파악하고, 그에 맞는 정보를 제공하는 효율적인 대화를 할 수 있게 되지 않을까요!

다음 포스트에선 두 번째 조건인 대화의 수준에 대해 적어보겠습니다.

구현 방법?

1. 분산 트랜잭션

가장 먼저 고려해본건 분산 트랜잭션, 그 중 Saga Pattern 이었습니다.

Saga Pattern, 그 중 Choreography 방식은 로컬 트랜잭션의 실패 여부를 이벤트로 발행, 이미 진행된 로컬 트랜잭션을 되돌리면 보상 트랜잭션을 실행함으로써 데이터 정합성을 맞출 수 있어요.

위 그림처럼 이벤트 흐름이 진행될거예요. 실패했을 때도 생각해볼까요?

결제 실패 시 실패했다는 이벤트를 발행하고, 이 토픽을 group-service 에서 구독하여 롤백을 진행하게 됩니다.

잠깐!

분산 트랜잭션이 왜 필요할까?

라는 원초적인 고민을 했었습니다. 서로 다른 마이크로서비스에서 일어나는 동작이 있기에, 로컬 트랜잭션으로 처리할 수 없는 동작이기에 필요하다는 결론에 다다랐는데요.

그렇다면 로컬 트랜잭션으로 해결하면 되지 않을까?

2. 이벤트 기반 통신

위 의문을 해결하기 위해 고안한 방식입니다. 기존과는 달리 결제 성공 시 그룹 인원을 증가시키고 있어요. 결제가 완료되기 전 미리 값을 변경시키지 않기에 보상 트랜잭션이 필요없어졌고, 하나의 트랜잭션으로 처리할 수 있게 되었습니다.

분산 트랜잭션이 단순한 이벤트 기반 통신으로 바뀜으로써 복잡도가 상당히 감소했다고 생각해요.

분산 트랜잭션 구현 전략 : 분산 트랜잭션을 피하라

Simple AWS에 기고된 내용 중 일부입니다. 관심 있으신 분들은 한 번 읽어봐도 좋을 것 같아요.

구현

1. BDUF, 그리고 TDD

구현에 앞서 겪었던 어려움에 대해 잠깐 이야기해보려 해요.

결제를 담당하는 마이크로서비스 payment-service 를 구현하기 위해 위와 같은 구조를 설계했습니다. 하지만 막상 구현하려니 너무 막막했어요.

실제 PG사를 연동하는 작업은 나중으로 미룰 생각이였음에도 너무나 많은 생각이 머리속을 떠나지 않았었죠.

얼마 전 소프트웨어 장인이라는 책을 읽었습니다. 해당 책에선 과한 설계를 피하기 위해, Agile하게 개발하기 위해 TDD를 적용하라는 작가의 추천이 있었어요.

에라 모르겠다! 아무 진전 없이 고민만 하고 있는 것보단 뭐라도 하는게 좋을 것 같아 TDD 방법론을 적용해보기로 했습니다.

    @Test
    @DisplayName("결제에 성공한다")
    void success_pay_process() {
        //given
        Long userId = 1L;
        BigDecimal amount = new BigDecimal("100.00");

        //when
        PayEvent payEvent = payService.processPayment(userId, amount);

        //then
        verify(payEventRepository, times(1)).save(payEvent);
    }

잘 모르겠고 일단 테스트를 작성했습니다. 최소한의 테스트를 작성하고, 이를 통과하는 코드를 작성합니다. 동일한 과정을 반복하며 살을 점점 붙이는 방식이예요.

    @Test
    @DisplayName("결제에 성공한다")
    void success_pay_process() {
        //given
        Long userId = 1L;
        BigDecimal amount = new BigDecimal("100.00");
        PayEvent payEvent = PayEvent.builder()
                .amount(amount)
                .userId(userId)
                .build();
        when(payEventRepository.save(any(PayEvent.class))).thenReturn(payEvent);

        //when
        PayEvent savedEvent = payService.processPayment(amount, userId);

        //then
        assertEquals(userId, savedEvent.getUserId());
        assertEquals(amount, savedEvent.getAmount());
        verify(payEventRepository, times(1)).save(any(PayEvent.class));
    }

사실 너무 익숙하지 않아 어느정도 틀이 잡히고 나선 TDD를 적용하지 않았습니다! 그래도 덕분에 과잉 설계를 피해 개발할 수 있었던 것 같아요.

2. 카프카 이벤트 흐름

1. 먼저 group-service 에서 그룹 인원 증가 요청 토픽에 이벤트를 발행합니다.

2. payment-service 는 요청 토픽을 구독하여 그룹 인원 증가 에 대한 결제를 수행합니다.

3. 결제 성공 시 payment-service는 그룹 인원 증가 응답 토픽에 이벤트를 발행합니다.

4. group-service 는 응답 토픽을 구독하여 그룹 인원 증가 동작을 수행합니다.

구현 코드는 이곳에서 확인하실 수 있습니다.

의문

1. 결합도를 낮춘다?

메세지 큐를 찾아보면 나오는 장점들 중 Decoupling이라는 것이 있습니다. Message Queue라는 미들웨어를 통해 통신함으로써 결합도를 낮춰 확장성, 유연성 등을 얻을 수 있다는 거죠.

위 그림을 다시 볼까요?

group-service 는 Kafka에 이벤트를 발행하기만 합니다. payment-service 발행된 이벤트가 무엇이던지 구독하여 처리합니다. 이로써 각 서비스는 서로를 몰라도 되고, 결국 약한 결합을 실현할 수 있다는 거죠.

하지만 이렇게만 하면 정말 결합도를 낮춘걸까요?

2. 너무 구체화된 이벤트

메세지 큐가 결합도를 어떻게 낮추는지에 대해 생각해봤습니다. Kafka의 경우, 이벤트를 통해 서로의 존재를 몰라도 각 서비스의 로직을 진행할 수 있도록 설계함으로써 결합도를 낮출 수 있다고 생각했어요.

위 그림은 제가 생각한 이상적인 이벤트 기반 통신입니다. 이벤트가 발행되고, 여러 서비스는 해당 이벤트를 구독하여 각자의 로직을 처리하는 방식이예요.

다만, 현재 제 프로젝트는 위 그림과 같은 구조로 되어있다고 느꼈습니다. Kafka를 통해 각 서비스간 통신을 진행했지만, group-service 가 발행한 이벤트는 결국 payment-service 를 목적으로 발행한 이벤트였기에 여전히 강하게 결합되어 있다고 느꼈으며, 이는 높은 확장성이라는 메세지 큐의 장점을 전혀 활용하지 못한다고 생각했어요.

마치면서

이번 개발을 진행하며 많은 키워드와 의문을 얻을 수 있었어요. 분산 트랜잭션과 Kafka, 이벤트 기반 아키텍처, 그리고 TDD 까지 많은 의문을 남게 하는 주제였네요.

특히나 이벤트 기반 아키텍처, EDA는 결제 기능 구현 시작부터 포스팅을 적고 있는 지금까지, 약 1달동안 계속 찾아보는 중인데도 갈피가 잘 안잡히네요.

로깅 시스템 을 구현할 때 이벤트에 대해 다시 한번 깊게 고민해봐야겠습니다.!

참고 자료

Saga패턴을 이용한 분산 트랜잭션 제어(결제 프로세스 실습) Distributed Transactions in Event-Driven Architectures 회원시스템 이벤트기반 아키텍처 구축하기 #우아콘2022

동시성 문제와 synchronized 에선 과금을 통해 그룹의 최대 회원수를 늘리는 비즈니스 모델을 제안, 구현했어요.

이번 포스트에선 결제를 담당하는 임의의 서비스 payment-service 를 구현하고 group-service 와 카프카를 통해 요청을 주고 받는 내용에 대해 적어보겠습니다.

방법

1. 직접 통신

가장 처음 생각해본 방법이예요. HTTP API를 통해 요청하는 방식이죠. 프로젝트 구성을 볼까요?

요청이 들어올 시 API Gateway를 통해 요청이 각각의 서비스로 relay 됩니다.

조금 더 현재 상황에 맞춰볼까요?

group-service 는 결제를 요청하기 위해 payment-service 가 제공하는 HTTP API로 요청을 보냅니다. 이후, API Gateway를 통해 요청이 전달되고, 결제 성공 여부에 따라 gruop-service 에서 추가적인 로직이 수행되겠죠.

다만, 이러한 방식은 몇가지 문제가 존재합니다. 문제점은 아래에서 조금 더 자세히 적어볼게요.

2. 중간에 무언가 존재하는 방식

통신을 담당하는 미들웨어가 존재하는 방식입니다. 이 미들웨어엔 주로 메시지 브로커인 RabbitMQ나 이벤트 스트리밍 플랫폼 Kafka를 주로 사용합니다.

선택

전 위 방법들 중 미들웨어가 존재하는 방식, 그 중 Kafka를 사용한 방식을 채택했습니다.

1. 동기적 방식의 문제

직접 통신 방식에서 발생하는 문제입니다. Spring mvc 의존성의 기본 WAS인 Apache Tomcat은 하나의 요청을 하나의 스레드가 처리하는 Request per Thread 모델입니다. 즉, 동시에 처리될 수 있는 요청 수가 Thread-pool 개수로 정해지죠.

직접 통신의 경우 group-service 의 요청은 결제 서비스의 모든 동작이 끝날때까지 기다립니다. payment-service 에서 1초, 2초, 10초가 걸리면 그 시간동안 group-service 의 스레드가 대기해야하므로 서버의 성능이 그만큼 저하될 거예요.

2. Kafka를 선택한 이유

전통적인 메세지 브로커, RabbitMQ와 같은 미들웨어도 존재하지만 Kafka를 선택한 이유는 다음과 같아요.

1) pub / sub 모델

Kafka는 메시지 브로커가 아닌 Event-Streaming-Platform 이라는 정체성을 갖고 있습니다. 이는 일반적인 메시지 브로커와는 다른 몇가지 특징이 있기 때문인데, 그 중 한가지는 발행 / 구독 모델을 사용한다는 거예요.

Kafka는 크게 3가지로 구성되어 있습니다. 이벤트를 보관하는 토픽, 토픽에 이벤트를 발행하는 Producer, 토픽에서 데이터를 가져가는 Consumer로 구성됩니다.

Kafka의 이벤트는 메시지 브로커와는 달리 영속합니다. 특정 토픽을 구독하는 Consumer A가 존재한다고 가정해볼게요. 메시지 브로커의 경우 소비한 메세지는 사라지지만, Kafka는 그렇지 않습니다. 동일한 토픽을 구독하는 Consumer B가 토픽에 존재하는 모든 이벤트를 동일하게 수신할 수 있습니다.

컨슈머 그룹이 달라야겠지만요!

이런 특성 덕분에 높은 확장성을 가진다고 느껴졌습니다.

현재 모두의 음악 프로젝트엔 별도의 로깅 시스템이 존재하지 않습니다. 이를 추후 구현할 개발 과제로 남겨두고 있는 상황이예요.

Kafka를 사용하게 될 시, 이후 추가될 로깅 시스템 연동이 굉장히 편할 것 같았으며, 로깅 시스템이 개발되기 전에 발생한 이벤트 또한 영속시키기에 임시 이벤트 저장소로 사용할 수도 있을 것 같았어요.

2) 분산 시스템

Kafka는 분산 시스템에서 동작하는 것을 목적으로 제작되었습니다.

클러스터링, 레플리케이션을 직접 지원하므로 브로커(카프카 서버)가 다운되어도 데이터 유실을 방지할 수 있죠. 이는 또한 대용량 데이터 처리라는 장점으로도 다가와요.

서비스가 마이크로서비스 아키텍처를 지향하고 있기 때문에, 확장에 용이한 Kafka가 프로젝트에 더 적합할 것 같았습니다.

마치며

한 포스트에 전부 적을 생각이였지만 구현하며 한 고민들이 많기에 두개의 포스트로 나눠 적기로 결정했습니다..!

다음 포스트엔 구현과 구현하며 한 고민들에 대해 적어보겠습니다!!

참고 자료

도서 - 아파치 카프카 애플리케이션 프로그래밍 with 자바 [서버] 메세지 큐(Message Queue) 을 알아보자

모두의 음악 프로젝트는 그룹 기반 커뮤니티 서비스입니다.

이번 개발 사항으론 서비스에서 가장 많이 사용될 것으로 예측되는 게시글 목록 조회 기능을 구현했어요.

API를 구현하며 진행한 선택과 그 이유에 대해 정리해볼까해요.

페이지네이션

페이징, 페이지네이션은 기본적으로 정보를 나눠받기 위해 존재한다고 생각해요.

페이징은 크게 전통적인 방식의 오프셋 기반 페이징과 페이스북, 인스타그램에서 볼 수 있는 무한 스크롤 에 자주 사용되는 커서 기반 페이징으로 구분할 수 있습니다.

1. 오프셋 기반 페이징

오프셋 기반 페이징은 페이지(오프셋) 을 입력받아 해당 페이지에 해당하는 데이터를 조회해요. 한 페이지(LIMIT) 가 10 일 때, 페이지가 0 이라면 조회 결과에서 1~10 번째에 해당하는 결과를 받을 수 있어요.

이러한 오프셋 기반 페이징은 구현이 굉장히 간단하다는 장점이 존재해요. Java의 경우 Page 인터페이스를 통해 간편하게 구현할 수 있죠. 다만, 몇가지 단점이 존재합니다.

단점

1. Count Query 의 필요성

오프셋 기반 페이징은 내 페이지가 몇 번째 아이템부터 시작하는지를 확인하기 위해 조회 결과의 개수를 알아야 해요. 이 때문에 Count Query 가 추가로 발생하게되므로, 최소 2번의 쿼리가 발생해요.

2. 성능 문제

오프셋 기반 페이징을 검색할 시 항상 딸려오는 성능 문제 또한 존재해요.

간단히 설명하자면, 특정 페이지에 해당하는 정보를 찾기 위해 가장 처음부터 순회를 한 후, 필요없는 데이터를 버리는 방식 때문이예요.

오프셋 페이징이 느린 진짜 이유 포스트에 굉장히 자세히 설명되어 있어요!

즉, 500 페이지 를 읽기 위해선 0~499 페이지를 읽은 후 버리고 500 페이지 를 가져올 수 있다는 말입니다. 이 때문에 오프셋 기반 페이징은 뒤쪽 페이지를 요청할수록 성능이 저하되는 문제가 발생해요.

2. 커서 기반 페이징

커서 기반 페이징은 오프셋 기반 페이징의 성능 문제를 해결하며 등장했어요. 마지막으로 읽은 값 이후로 LIMIT 만큼만 가져오기에 오프셋 기반 페이징에서 발생하는 Count Query 가 불필요하며, 앞에서부터 읽지 않기에 점점 저하되는 성능 문제를 해결할 수 있었죠.

다만, 커서 기반 페이징에도 단점은 존재해요.

단점

1. 보다 복잡한 구현

커서 기반 페이징은 오프셋 기반 페이징에 비해 복잡한 구현이 필요해요. 특히, 정렬할 key 가 unique 하지 않은 경우, 데이터의 누락이 발생할 수 있기 때문에 조심해야 해요.

예를 들어 볼까요? 날짜에 의해 정렬된 데이터가 존재하며 LIMIT 는 2 라고 가정해볼게요.

첫 조회에선 커서부터 2개의 7월 17일 데이터를 가져올거예요. 다음 조회를 볼까요?

커서의 검색 조건 이 7월 17일보다 큰 으로 들어가기에 3번째 데이터를 건너뛰게되고, 데이터 누락이 발생해요.

2. 제한

뿐만 아니라 커서 기반 페이징은 상황에 따라 도입하기 힘들 수도 있어요.

한번에 여러 페이지를 건너뛰어야 한다.

이러한 요구 사항이 존재할경우, 마지막 Item을 기준으로 다음 것을 조회하는 커서 기반 페이징은 도입하기 힘들거예요.

구현

구현엔 QueryDSL을 사용했어요. 보다 쉽게 동적 쿼리 를 작성할 수 있게 도와준답니다.

1. 오프셋 기반 페이징

오프셋 기반 페이징은 위에서 말한 것처럼 Count Query 를 추가로 작성해줘야 합니다.

inner join 을 진행하기에 Count Query 에선 조인을 제외했어요.

    @Override
    public Page<Post> searchRecentPosts(PostSearchCondition cond, Pageable pageable) {
        List<Post> content = queryFactory
                .select(post)
                .from(post)
                .join(post.group, group).fetchJoin()
                .join(post.profile, profile).fetchJoin()
                .where(
                        groupIdEq(cond.getGroupId()),
                        postScopeEq(cond.getPostScope()),
                        post.state.eq(cond.getState())
                )
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .fetch();

        Long totalCount = queryFactory
                .select(post.count())
                .from(post)
                .where(
                        groupIdEq(cond.getGroupId()),
                        postScopeEq(cond.getPostScope()),
                        post.state.eq(cond.getState())
                )
                .fetchOne();

        return new PageImpl<>(content, pageable, totalCount);
    }

    private BooleanExpression postScopeEq(PostScope postScope) {
        return postScope != null ? post.postScope.eq(postScope) : null;
    }

    private BooleanExpression groupIdEq(Long groupId) {
        return groupId != null ? post.group.id.eq(groupId) : null;
    }

2. 커서 기반 페이징

커서 기반 페이징에선 위와 다르게 .offset() 이 사라지고, where 절에 cursorIdLt() 가 추가되었어요.

또한 게시글이 등록된 순서대로 조회할 것이기에 별다른 정렬 조건은 필요하지 않아 생각보다 편하게 구현할 수 있었습니다.

    @Override
    public Slice<Post> searchRecentPosts(Long cursorId, PostSearchCondition cond, Pageable pageable) {
        List<Post> content = queryFactory
                .select(post)
                .from(post)
                .join(post.group, group).fetchJoin()
                .join(post.profile, profile).fetchJoin()
                .where(
                        groupIdEq(cond.getGroupId()),
                        postScopeEq(cond.getPostScope()),
                        post.state.eq(cond.getState()),
                        cursorIdLt(cursorId) // 커서 적용
                )
                .orderBy(post.id.desc())
                .limit(pageable.getPageSize() + 1)
                .fetch();

        boolean hasNext = false;
        if (content.size() > pageable.getPageSize()) {
            content.remove(pageable.getPageSize());
            hasNext = true;
        }
        return new SliceImpl<>(content, pageable, hasNext);
    }

    private BooleanExpression cursorIdLt(Long cursorId) {
        return cursorId != null ? post.id.lt(cursorId) : null;
    }

    private BooleanExpression postScopeEq(PostScope postScope) {
        return postScope != null ? post.postScope.eq(postScope) : null;
    }

    private BooleanExpression groupIdEq(Long groupId) {
        return groupId != null ? post.group.id.eq(groupId) : null;
    }

성능 테스트

테스트를 위해 약 1만개의 게시글 데이터를 준비했습니다.

로컬 환경에서 테스트했기에 일관된 테스트가 진행되지 않았습니다. 차선책으로 여러 번 테스트한 후 판단했습니다.

테스트는 두 방식으로 구현된 API의 성능 차이를 확인하기 위해 JMeter를 사용해 진행했습니다.

테스트는 특정 지점에 있는 데이터를 조회하는 방식으로 진행했습니다. 오프셋 기반 페이징은 0, 250, 500, 750, 999 페이지를 조회했으며, 커서 기반 페이징 마지막, 7500번, 5000번, 2500번, 50번 Item을 조회했습니다.

오프셋 기반 페이징의 경우, 250 페이지 까진 일정한 Throughput 을 기록했지만, 이후부턴 조금씩 감소함을 확인할 수 있었어요. 마지막 페이지 의 경우엔 약 40% 의 성능 하락이 발생함을 확인할 수 있었습니다.

커서 기반 페이징의 경우, 처음엔 오프셋 기반 페이징보다 조금 더 낮은 성능을 기록했어요. 하지만, 뒤쪽의 데이터를 조회해도 성능이 감소하지 않았어요.

테스트 결과는 아래쪽에 사진으로 남겨놓았답니다.

오프셋 기반 페이징

0 페이지

250 페이지

500 페이지

750 페이지

999페이지

커서 기반 페이징

10000번째

7500번째

5000번째

2500번째

50번째

선택

1. 성능 상 이점?

모두의 음악 프로젝트는 모바일 환경을 메인으로 합니다. 게시글 조회 또한 무한 스크롤 방식으로의 구현을 생각하고 있습니다.

커서 기반 페이징이 일정한 성능을 보장할 수 있음을 알았습니다. 그럼에도 불구하고, 성능 때문에 커서 기반 페이징을 도입할 이유는 없다고 느껴졌어요.

서비스의 특성

커뮤니티 기반의 게시글 서비스이고, 어플리케이션의 주 목적은 음악 동아리 를 타겟한 네이버 밴드 와 같은 서비스를 기획했어요.

이러한 특성을 생각하면 최신 게시글 이 가장 빈번하게 조회될테고, 성능에 영향이 가기 위해선 최소 500번 가량의 스크롤링이 진행되어야 합니다. 500 번 이상 스크롤을 내릴 가능성이 현저히 적을 것이라 생각했으며, 만약 이전 게시글을 봐야한대도 검색 기능 을 이용할 것이라 생각했어요.

사용자가 늘어나 게시글이 많아지고, 스크롤을 많이 내리는 현상이 잦아질 경우 구현하는 것이 더 좋다고 판단했습니다.

2. 그럼에도 커서 기반 페이징을 선택한 이유

그럼에도 불구하고 커서 기반 페이징을 도입한 이유는 UX(사용자 경험)에 있습니다.

오프셋 기반 페이징은 페이지를 기반으로 데이터를 조회합니다. 다음과 같은 상황을 생각해볼까요.

처음 조회 시 페이지 0 의 10 ~ 6 에 해당하는 Item을 조회합니다. 스크롤링 발생 시 페이지 1 을 조회할거예요.

문제는 여기서 발생합니다. 첫 조회 이후 스크롤링이 발생하기 전 새로운 게시글이 등록되었다고 가정해볼까요?

새로운 Item이 등록되었기에 페이지가 밀리게되고, 사용자의 화면엔 ID 가 6 인 게시글이 2개 보이게 됩니다. 활성화된 그룹일수록 글이 많이 등록될테고, 중복 게시글이 화면을 뒤덮을 확률 또한 존재했습니다.

이러한 현상은 사용자에게 버그로 인식될테고, 사용자에게 부정적인 경험을 야기하게 됩니다. 결국 사용자는 모두의 음악 서비스를 떠나게 되겠죠.

그것만은 안된다!

참고 자료

Wonit - 오프셋 페이징이 느린 진짜 이유 minsangk - 커서 기반 페이지네이션 구현하기 Lifealong - Apache JMeter를 사용해보자

로컬 환경에서의 실행은 docker-compose 를 통해 간편하게 실행할 수 있도록 했습니다.

물론 혼자 개발하는 1인 프로젝트 이다보니 docker-domcpose 를 통한 로컬 환경 실행만으로도 충분할 수 있겠지만, 팀원이 늘어나거나 front-end 등 다름 팀과의 협업이 발생한다면 실제 환경과 유사한 상태로 실행되고 있는 개발 환경 이 필요하다고 생각되었어요.

본 포스트는 운영과 유사한 개발 환경을 구성하기 위한 과정과 발생한 문제, 해결 과정을 기록했습니다. 자세한 설정 방법은 다루지 않습니다.

발생 문제 & 해결 과정

1. 불필요한 작업 발생 & CI/CD 파이프라인 구성

최신 코드를 서버에서 실행하기 위해선 github 에 존재하는 코드를 내려받아 Test & Build 과정을 거쳐 실행하는 과정이 필요합니다.

물론 배포 스크립트를 작성해 서버에 접속 후 실행하면 된다지만, 최신 코드가 갱신될 때마다 개발 서버에 접속해 매번 배포 스크립트를 실행하는 건 큰 피로로 다가올 뿐만 아니라, 실수하기도 쉬운 작업 환경이 만들어진다고 생각했어요.

위와 같은 불필요한 작업, 실수하기 쉬운 환경을 해결하기 위해 CI/CD 파이프라인을 구축하기로 했어요.

CI/CD는 간단하게 말해서 최신 코드를 테스트, 빌드하는 CI(지속적인 통합)와 테스트한 코드를 릴리즈하는 CD(지속적인 배포)로 구성되어 있습니다.

CI/CD 파이프라인을 구현하는 방법은 크게 Github Actions를 사용하는 방법과 Jenkins를 사용하는 방법으로 나눠집니다.

각 방법은 여러 장단점이 존재하지만, 전 Jenkins를 사용했어요. Github Actions가 적용하기 더 편하다는 내용 또한 있었지만, Jenkins가 MSA 프로젝트의 배포에 관한 자료를 찾기 쉬웠기 때문에 선택했습니다.

2. Jenkins와 공용 라이브러리 의존성 문제

모두의 음악 프로젝트는 각 마이크로서비스에서 공통적으로 사용되는 로직을 별도의 라이브러리로 추출하여 사용중입니다. 로컬 환경에선 maven local 에 라이브러리를 배포해 사용중이었습니다.

다만, 이렇게 유지해온 라이브러리는 Jenkins의 CI 과정에선 주입받을 수 없었어요. Nexus Repository와 같은 라이브러리 보관소를 사용할 수도 있었지만, Jenkins 컨테이너 내부의 maven local 을 이용해 보다 간편하게 빌드 과정에서 라이브러리를 주입받을 수 있었습니다.

이는 또한, 밑에서 설명할 multi-branch build strategy를 통해 라이브러리 배포 또한 쉽게 할 수 있을 것이라고 생각돼요.

3. Github webhook 502 에러 발생

자동화된 배포를 위해선 코드가 업데이트될 시 자동적으로 CI 과정이 실행될 필요가 있습니다. 이를 위해 필요한 것이 Github webhook 입니다. Github에 코드가 push되면 Github webhook이 이벤트를 발생시켜, Jenkins의 CI/CD 파이프라인이 실행되는 방식이예요.

webhook 발생 후 Http status 502를 마주쳤습니다. 요청이 정상적으로 전달되지 않았다는 의미였어요. 찾아보니 ACG와 ACL에 의해 요청이 필터링되어 제대로 전달되지 않았다는 걸 알 수 있었습니다.

github metadata에서 github의 webhook이 발생되는 IP를 허용해주었고, 이후 정상적으로 작업이 진행될 수 있었어요.

4. 배포 시간 오래걸림

Github Repository엔 마이크로서비스들, 서비스 디스커버리, API 게이트웨이 등 다양한 개별 어플리케이션이 존재합니다. Github webhook을 이용해 빌드 과정을 자동화했지만, 거슬리는 부분이 존재했어요.

Github webhook은 폴더 단위의 작업을 지원하지 않기에 변경이 발생하면 모든 어플리케이션을 빌드해야 한다는 단점이 존재했죠.

인증/인가를 담당하는 user-service, MSA 구조를 위한 api-gateway 와 eureka-discovery 는 빌드가 1분 내로 완료되는 간단한 어플리케이션입니다. 다만, 다른 것들과 같이 빌드되어 4분이 넘는 시간이 걸렸습니다.

서비스 확장이 발생할 때 마다, 테스트가 추가될 때마다 빌드 시간이 기하급수적으로 증가할 것이기에 CI/CD의 효과를 보기 위해선 이 문제를 반드시 해결해야 한다고 생각했어요.

다행히도, 비슷한 문제에 대한 자료를 찾을 수 있었습니다. Jenkins Multibranch Pipeline 개선기에선 한 레포지토리에서 back-end 와 front-end 코드를 관리하고 있었습니다. 마이크로서비스가 개별로 빌드되길 원하는 제 상황과 유사했고, 해결법 또한 자세히 설명되어 있었습니다.

이후, Multibranch build strategy를 적용하여 개별 스크립트가 동작할 수 있도록 설정했습니다.

기존 4분 이상 걸리던 빌드 과정을 1분대로 줄일 수 있었습니다. 약 80%의 시간이 단축되었고 테스트가 적은, 소규모의 어플리케이션이라면 더욱 짧아지겠죠. 이는 서비스가 확장될수록 더 큰 효과를 발휘할거예요!

참고 자료

Chris - Jenkins Multibranch Pipeline 개선기

아래 추천코드를 입력해주시면 25년 이내에 신청 시 20만원, 26년엔 10만원 할인이 적용된다고 해요!

추천코드 : 커넥터스2371

추운 겨울이었던 1월 초에 시작했던 멘토링이 여름이 되어서야 끝났습니다.

멘토링을 신청하게 된 계기와 진행하며 얻은 것들에 대해 이야기해볼까 합니다.

멘토링을 신청하게 된 계기

0. F-Lab이란?

F-Lab 멘토링에 대한 정보를 짤막하게 공유하고 후기를 시작해볼까 합니다.

F-Lab은 상위 1% 개발자의 1:1 과외라는 슬로건을 걸고 있습니다.

제가 진행한 Java Backend 이외에도 다양한 멘토링 코스가 존재하며, 신청한 후 F-Lab 내부의 어떠한 기준을 통해 멘토님과의 매칭이 진행됩니다.

1. 개발을 시작한 계기

글을 적다보니 이것저것 말하고 싶은게 많아 주절주절 적게 되네요.

만약 멘토링에 대한 정보나 후기만 필요하신 분들은 다음 토픽부터 읽으시면 됩니다!

어쩌다보니 컴퓨터공학과에 진학했고, 코딩 경험이라곤 스크래치와 윤성우의 열혈 C 프로그래밍 책 한권 따라쳐본게 전부였던지라.. 걱정이 많았지만 다행히도 꽤 적성에 맞았습니다.

고민은 생각하지 못했던 부분에서 시작됐는데, 학교 수업이야 듣고 공부하면 되지만 front-end, back-end 혹은 android 등 많은 직무 중 어떤 길을 선택해야 할 지에 대한 고민이 대부분이었습니다.

군 복무를 하면서 대부분은 놀았지만 React 와 같이 진로에 대해 결정하기 위해 다양한 분야의 책을 읽으며 공부했습니다.

전역 후, 3학년으로 복학했을 때 수강했던 네트워크 보안 수업이 기억에 남습니다. 처음 보안이라는 분야에 대해 공부했고, 흥미가 있어 꽤나 열심히 공부했던 것 같아요.

대학원이라는 선택지도 있었지만, 실무라는 것에 대해 막연한 기대감이 있었기에, 사실 연구라는 것에 큰 의미를 갖지 못한채로 대학원이라는 도피성 선택을 하기 싫었던 게 더 컸기에 교내 현장실습으로 눈을 돌렸던 것 같습니다.

막론하고, 실무를 경험하기 위해 LINC 사업단에서 진행하는 현장실습을 지원했고 운이 좋게도 보안 스타트업에서 6개월간의 인턴을 진행했습니다.

2. 멘토링을 시작한 이유

더닝 크루거 효과라는 것이 있습니다. 능력이 부족한 사람은 자신의 능력을 과대평가하고, 능력이 뛰어난 사람은 자신의 능력을 과소평가하는 현상을 의미합니다. 아래의 그림으로 보면 조금 더 익숙할 것 같아요.

사실 아래 그래프 또한 잘못 알려진 그래프랍니다. 다만, 제가 전달하고자하는 의미와 잘 맞아서 그냥 사용했습니다!

학부생 시절에도 어느정도 적성에 맞았다고 생각했고, 인턴을 하면서도 꽤나 업무 효율이 좋았다고 생각했습니다. 구현엔 자신있었기에 그만큼 빠르게 개발할 수 있었죠. 이 때가 위 그림에서의 우매함의 봉우리였던 것 같아요.

저는 엔진이라는 파트를 맡았습니다. SOAR라는 보안 관제 제품 내부에서 로그를 수집하거나 대응 자동화를 위한 모듈, batch-job 등 무언가 뒤에서 돌아가는 모듈과 프로그램 개발을 담당했습니다.

제품이 개발되는 과정이었기에 빠르게 구현할 수 있는 제 능력이 꽤나 효율이 좋았습니다. 처음엔 말이죠. 요구 사항이 빈번하게 변경되는 상황이었고, 코드 또한 요구 사항에 맞춰 변경되어야 했습니다. 물론 인턴이라 비교적 쉬운 일 위주로 맡았으며, 작성한지 얼마 되지 않은 코드였기에 수정 작업도 비교적 쉬웠습니다.

다만, 요구 사항이 조금이라도 변경될 때마다 갈아 엎어야되는 코드를 보며 의심이 싹텄습니다. 동시에 자신감의 하락도 시작되었죠.

물론 내리막에 몸을 맡기진 않았습니다. 추상화를 적용해 확장성 있는 설계 를 적용했고, 단일 모듈의 경우 진행되는 로직의 절차를 고려하여 가독성 높은 코드를 작성하려고 노력했습니다. 자신감의 하락 구간을 벗어나기 위해 이것저것 많이 했었죠.

아쉽게도 내리막은 생각보다 가팔랐고, 점점 미끄러지게 되었습니다. 코드에 대한 의심이 시작된 후 보안이라는 관심사에 대해 멀어지게 됐고, 이후론 단 하나의 관심만이 머리속에 존재했습니다.

어떻게 하면 좋은 코드를 작성할 수 있을까?

서론이 너무 길었네요. 멘토링을 시작한 이유를 한줄로 표현하자면 아래와 같습니다.

개발은 너무 즐겁지만 전문성 없이 실무에 뛰어들고 싶지 않았습니다.

회사에선 좋게 평가해주셨지만, 스스로 만족하지 못했기에 공부에 집중하는 시간을 가져보기로 마음먹었습니다.

3. F-Lab을 선택한 이유

요즘은 정말 많은 교육이 존재하는 것 같습니다. 광고 또한 제 관심사에 맞춰 제공되니 과할 정도로 많은 부트캠프, 교육에 대한 정보들이 들어왔어요.

대다수의 교육들은 취업 책임제라는 달콤한 보상을 제시했던 것 같아요. 다만, 제 목적은 단순히 취업이 아니었기에 그 당시엔 그닥 끌리는 제안이 아니었습니다.

전 생활코딩 페이스북 페이지를 즐겨봅니다. 여느때처럼 퇴근길에 커뮤니티를 보던 중, F-Lab 대표님이신 핏츠님의 글을 봤습니다.

자바 백엔드 기술 면접 대비하기 - 1편을 보고 난 후 하루종일 머리가 띵 했습니다. 그래도 학부생 때 나름 애정을 갖고 사용했던 Java 언어인데 질문의 절반 이상을 답변을 못하거나, 애매한 답변만 생각났으니까요.

이외에도 F-Lab 기술 블로그엔 다양한 토픽의 글이 올라와 있었습니다. 주니어 개발자가 신경써야 할 것들, 면접관 입장에서 본 좋은 개발자 등 양질의 포스팅이 많이 있었고, 이런 멘토링 플랫폼의 도움이라면 자신감의 하락 구간을 벗어나는 데에 큰 힘이 될 것 같았습니다.

장점

1. 매칭 시스템

첫 멘토링을 시작하기 2주 전 쯤, 멘토님과 사전 미팅이 있었습니다. 첫 미팅이라 긴장도 되고, 어색한 분위기일 줄 알았지만 다행히도(?) 멘토님이 잘 리드해 주셨습니다.

첫 미팅을 돌이켜보니, 굉장히 인상적인 질문을 하나 받았었습니다.

좋은 글을 쓰기 위해선 어떻게 해야 할까요?

답이 정해진 질문이 아니기에 사람마다 다른 답을 할 수 있겠습니다만, 전 좋은 글을 많이 읽는 것이라고 생각했습니다.

좋은 코드를 작성하기 위해선 어떻게 해야 할까요?

사전 미팅 시작 10분만에 어떻게 하면 좋은 코드를 작성할 수 있을까? 라는 고민에 대한 실마리를 찾은 기분이었어요.

좋은 글을 쓰기 위해선 좋은 글을 많이 읽는 것이 중요하다면, 좋은 코드를 작성하기 위해선 좋은 코드를 많이 읽는 것이라고 생각했습니다.

이외에도 전 멘토님과의 성향이 굉장히 잘 맞았던 것 같습니다. 물론 멘토님이 맞춰주셔서 그랬겠지만..! 잘 맞는 멘토님을 매칭해준 F-Lab의 매칭 시스템에 고마움을 느끼고 있습니다.

2. 자유로운 커리큘럼

이전부터 커리큘럼이 정해진 교육에 막연한 거부감이 있었습니다. 커리큘럼이 정해져있으면 책, 강의보고 혼자서도 할 수 있지 않을까? 라는 생각이 있어 그랬던 것 같습니다.

F-Lab의 교육은 어느정도의 틀은 존재했지만 정해진 커리큘럼은 없었습니다. 이 또한 멘토님의 수업 방식에 따라 상이하며, 수업의 난이도가 안맞거나 방식이 마음에 들지 않는다면 얼마든지 요청을 통해 바꿀 수 있는 것으로 알고 있어요.

3. 자유로운 일정

멘토링을 시작한지 4주 쯤 지났을 때, 절망의 계곡에 빠졌었습니다. F-Lab은 경력 이직을 준비하는 분들이 많은 비중을 차지한다고 느꼈어요. 비교는 좋지 않지만, 너무 뒤쳐지는 것 같다 라던지 이렇게 공부하는 게 맞나? 라는 걱정들이 많이 들었습니다.

엎친데 덮친 격으로, 건강 문제가 기다렸다는듯이 터져나왔습니다. 눈병에 걸려 일상생활이 힘들 정도로 시력이 떨어졌고, 원인 모를 전신 두드러기에 야외 활동도 힘들어졌거든요. 이때는 정말 절망의 계곡이 지하 3층까지 있었구나라는 생각이 들 정도로 힘들었습니다.

정신적, 그리고 신체적으로 몰린 상황에서 더 이상 붙잡고 있긴 힘들다고 판단했습니다. 다행히도, F-Lab의 멘토링은 1대1로 진행되기에 커리큘럼이 정해진 수업과는 다르게 자유롭게 일정을 관리할 수 있었고, 4주간의 휴식을 가질 수 있었습니다.

4. 1대1 교육

약 한달동안 모니터를 보지 않고 살았더니, 그동안 공부했던 게 기억이 잘 안나는 대참사가 일어났습니다. 때문에 프로젝트 진행이 힘들다고 판단, 3주간 기술 면접, 라이브 코딩 테스트 등을 진행에 대해 요청드렸고, 멘토님은 흔쾌히 받아주셨습니다.

예전부터 전 질문에 대해 함께 고민하고, 관심사에 대해 공유하는 것을 즐겼습니다. 이러한 성향 때문일까요? 멘토님과 함께 진행했던 모의 기술 면접, 라이브 코딩 테스트는 정말이지 너무 재밌었습니다. 진행 후 부족한 부분에 대한 피드백, 진행할 때 팁들에 대해서도 얻어갈 수 있었어요.

F-Lab의 1대 1 교육이기에 가능했던 경험인 것 같아요.

5. 시니어 개발자의 코드 리뷰

가장 기대했던 경험이었습니다. 그동안 코드 리뷰에 목말라 있었던데다 IBM, AWS 경력의 시니어 개발자가 내 코드를 리뷰해준다니, 정말 꿈만 같았어요.

이 부분에 대해선 더 할말이 없을 정도로 좋은 경험이었습니다.

6. 생각의 전환

멘토링 시작 전엔 구현 위주의 고민들을 했던 것 같아요. OAuth는 어떻게 적용하지? 혹은 ○○기능을 어떻게 구현할까? 등 어떻게에 초점이 맞춰져 있었습니다.

멘토링을 진행하며, 언제부터인가 생각하는 방식이 바뀌었던 것 같아요. 같은 기능을 구현해도 JWT를 읽어 로그인 정보를 받아오는 메소드를 서비스 클래스에서 사용하는 게 맞을까? 와 같이, 이전보다 더 구체적이고 깊이 있는 고민을 할 수 있게 된 것 같습니다.

7. 소프트 스킬

제가 느낀 멘토님을 한 단어로 표현하자면 유연한 사람이라고 생각해요. 한줄의 코드를 적을때도 고민하고 생각해서 적어야 한다. 라고 말씀해주셨는데, 이러한 멘토님의 개발 원칙은 코드 리뷰시에도 적용됐었습니다.

트랜잭션은 재사용할 수 없다구요! 포스팅에선 트랜잭션 처리 전략을 변경하여 비즈니스 문제를 해결한 과정이 있습니다.

이 문제에 대해서 멘토님은 일관성 있는 트랜잭션 처리, 즉 2번의 별도의 메소드를 구현하는 방법이 더 좋을 것 같다 라는 의견을 남겨주셨지만, 멘토님의 생각을 강요하진 않으셨어요.

많이 고민하고 작성하셨잖아요?

물론 저 또한 관련 주제에 대해 얘기를 나눈 후엔 2번 방법이 더 좋다고 생각했지만, 멘토님의 말은 항상 듣는 사람을 배려한다는 느낌이 강하게 들었습니다.

학부생 시절, 프로젝트 리딩에 실패한 경험이 있습니다. 소통을 위한 이런저런 노력을 많이했음에도 커뮤니케이션이 잘 되지 않는다는 느낌을 받았었죠. 첫 회고땐 그저 팀원들의 문제라고 생각하며 탓하기 바빴고, 두번째 회고땐 내 실력이 모자라 리딩에 실패했다고 생각했습니다. 멘토님의 커뮤니케이션 방식을 경험하고서야 배려가 부족한 소통을 하고 있진 않았나 라는 생각이 들었죠.

함께 일하고 싶은 사람 - 1. 업무 습관 포스팅엔 독성 말투가 없는 이라는 파트가 있습니다.

독성 말투는 은연중에 조직에 해를 주게 됩니다. 말 하나에 팀워크가 깨지고, 팀 전체의 사기를 저하시키기도 합니다. ‘말’에 대한 속담이 많은 이유가 있는 것 같습니다.

멘토링과 실패에 대한 세번의 회고를 통해 커뮤니케이션, 소프트 스킬에 대한 중요성을 몸소 깨달을 수 있었던 굉장히 귀중한 경험이었어요.

8. 커뮤니티

F-Lab은 슬랙 채널, ZEP 온라인 모각코와 같은 커뮤니티들을 운영하고 있어요. 커뮤니티에선 종종 온라인 컨퍼런스도 진행되며, 대표 멘토님의 이력서 세미나도 종종 열립니다.

모르는 걸 물어보고, 힘들 때 고민을 털어놓을 선배 개발자들이 존재한다는 것, 다양한 경험을 할 수 있다는 것이 공부할 때 큰 도움이 되었습니다.

단점

1. 금액

금액이 꽤나 부담스러웠습니다. 취준생 입장이다보니 더 부담스러웠던 것 같아요.

멘토링 자체는 상당히 만족스러웠기에 다른 단점은 못느꼈습니다.

후기

1. 주도적 학습

F-Lab의 멘토링은 혼자서 공부할 수 있는 방법을 알려준다고 생각합니다.

두발 자전거를 처음 탄다고 생각해볼까요.

A라는 친구는 직접 운전하지 않고, 보호자가 운행하는 2인용 자전거 뒤에 타고 달려나갑니다.

B라는 친구는 1인용 자전거를 탑니다. 대신, 보호자가 뒤에서 잡아줍니다.

시작한 지 얼마 지나지 않았을 땐, A 친구가 빠르게 앞서 나갈 수 있겠죠. 운전자가 없어진다면 어떻게 될까요? A는 그제서야 혼자 자전거 타는 방법을 배워야 합니다.

그렇다면 B는 어떨까요? 처음엔 자전거를 잘 타지 못합니다. 뒤에서 잡아줘도 넘어질테고, 달리지 못하기에 재미도 없고, 뒤쳐지기에 조마조마 하겠죠. 하지만, 보호자가 없어졌을 땐 A와는 반대의 상황이 펼쳐집니다. 혼자 타는 법을 알려줬기에, B는 혼자서도 목적지를 향해 나아갈 수 있습니다. 물론 비틀거리겠지만요!

장점 2번의 자유로운 커리큘럼 파트에서도 말했듯이, 저는 길이 정해진 교육에 거부감이 있습니다.

물론 멘토링 초반엔 힘들었습니다. 이게 맞는지도 모르겠고, 여러 기술들을 적용하는 다른 프로젝트들을 볼때면 뒤쳐지는 느낌도 많이 받았었죠.

힘들게 먹은 과육이 더 달콤하다고 하던가요. 단순 구현만 고민하던 과거와는 달리 보다 깊이있는, 왜? 라는 고민을 하게 된 제 자신을 볼때마다 기분이 굉장히 좋습니다.😄

2. 아쉽다🥲

이제 막 깨달음의 오르막을 오르기 시작했다고 생각합니다. 분명 많이 공부했고, 아는 것도 많아졌는데 모르는 건 더 많아진 기분이 종종 드네요.

가끔 이런 생각을 하곤 합니다.

지금 상태에서 멘토링을 시작했다면 더 많이 배워갈 수 있을텐데!

물론 F-Lab의 멘토링은 월 단위로 연장이 가능합니다만, 언제까지고 보호자가 자전거를 잡아줄 순 없다고도 생각이 듭니다.

언제까지고 보호받을 순 없으니까요!

그 동안 배웠던 것들을 되새기며 홀로 서기에 도전해야겠습니다.

깨달음의 오르막을 지나 지속 가능성의 고원에 도달하기까지..!

혜택!

초반에 이미 언급했지만, 많은 분들이 관심을 가져주신 덕분에 후기 글이 구글 검색 상위에 노출되었네요. 글 쓰는건 좋아했지만 이런적은 처음이라 뻘쭘하기도 하고,,,,,

제 글을 보시고 멘토링에 관심이 생겼다! 하시는 분들은 아래 추천 코드를 입력해주시면 25년 이내에 신청 시 20만원, 26년엔 10만원 할인이 적용된다고 해요!

추천코드 : 커넥터스2371

모두 행복한 개발 하시길 바래요~!

들어가기에 앞서

그룹 가입 서비스 로직은 아래와 같이 작성되어있다.

    @Transactional
    public void joinGroup(GroupJoinRequestDto dto, Long groupId) {
        Group group = findGroupById(groupId);

        if (joinRequestService.pendingRequestExists(group.getId())) {
            throw new DuplicateElementException("이미 가입 요청한 그룹입니다.");
        }

        try {
            Profile profile = profileService.getLoggedInProfile(groupId);

            switch (profile.getState()) {
                case RESTRICTED -> {
                    throw new UnAuthorizedException("추방당한 회원입니다. userId : " + profile.getUserId());
                }
                case GENERAL -> {
                    throw new DuplicateElementException("이미 가입한 그룹입니다.");
                }
                case DELETED -> {
                    if (group.getJoinCondition() == JoinCondition.OPEN) {
                        profileService.checkGroupSize(group);
                        profile.setState(State.GENERAL);
                    } else {
                        joinRequestService.createNewGroupJoinRequest(dto, group);
                    }
                }
            }
        } catch (NoLoggedInProfileException e) {
            if (group.getJoinCondition() == JoinCondition.OPEN) {
                profileService.checkGroupSize(group);
                profileService.createNewProfile(dto.getNickname(), GroupRole.MEMBER, group);
            } else {
                joinRequestService.createNewGroupJoinRequest(dto, group);
            }
        }
    }

흠... 작성하고보니 어디서 똥냄새가 스멀스멀 올라오는게 뭔가 별로인 것 같다. 어디서 냄새가 나는지 알아보고, 향기 나는 보다 읽기 편한 코드로 리팩토링하는 과정을 정리해본다.

문제

1. 읽기 불편함

가장 처음 생각한 문제는 읽기 불편함, 즉 가독성이 떨어진다는 것이다. 타 개발자가 해당 코드를 리뷰한다면 어떤 생각이 들까?

1. 그룹을 찾는다.
2. 가입 요청이 있는지 확인한다.
3. 프로필을 조회한다.
4. 프로필 상태가 RESTRICTED 일 때의 처리
5. 프로필 상태가 GENERAL 일 때의 처리
6. 프로필 상태가 DELETED 일 때 6-1. 그룹의 JoinCondition 이 OPEN 일 때의 처리 6-2. 이외의 처리
7. 프로필을 찾지 못했을 때 7-1. 그룹의 JoinCondition 이 OPEN 일 때의 처리 7-2. 이외의 처리

하나의 메소드를 리뷰함에 있어서 모든 비즈니스 요구사항을 알아야 한다.

또한, 흐름에 따른 절차를 나열하는 식으로 구현되었기에 가독성이 더욱 저하된다고 생각한다.

띄어쓰기를하지않으면읽기불편해지는것과같은느낌이라고생각한다.

현재는 30~40줄의 코드이기에 금방 읽을 수 있지만, 100줄, 200줄이 넘어가면 리뷰 난이도가 기하급수적으로 올라갈 것이다.

2. 개방/폐쇄 원칙

만약 비즈니스 요구사항이 변경된다면 어떻게 될까? 현재 상황에선 서비스 로직 자체가 수정되어야 한다. 이는 변경에 닫혀있어야 한다 라는 OCP를 위반하며, 변경에 취약한 프로그램을 만드는데 일조한다.

    @Transactional
    public void joinGroup(GroupJoinRequestDto dto, Long groupId) {
        ...
        try {
            Profile profile = profileService.getLoggedInProfile(groupId);

            switch (profile.getState()) {
                case SOMETHING -> {
                    // 새로운 상태 추가
                }
                case RESTRICTED -> {
                    // 혹은 기존 처리 로직 변경
                    // throw new UnAuthorizedException("추방당한 회원입니다. userId : " + profile.getUserId());
                }
                case GENERAL -> {
                    throw new DuplicateElementException("이미 가입한 그룹입니다.");
                }
                case DELETED -> {
                    ...
                }
            }
        }
        ...
    }

방법 도출

1. 전략 패턴

전략 패턴이란 행위를 캡슐화한 인터페이스를 두고, 해당 인터페이스를 구현하는 전략 클래스를 통해 객체의 행위를 동적으로 바꾸는 디자인 패턴이다.

전략 패턴은 특히 전략이 빈번하게 추가되어야 할 때 빛을 발하는데, 기존 비즈니스 로직을 수정할 필요 없이 전략 클래스를 새로 생성하는 것만으로도 처리 로직을 추가할 수 있기 때문이다.

2. Consumer

Consumer는 Java에서 함수형 프로그래밍을 구현하기 위해 Java 1.8부터 도입된 함수형 인터페이스이다.

이를 통해 특정 상태에 대한 처리 로직을 추출할 수 있다.

해결

1. 선택

위에서 알아본 두 방법 중 무엇을 선택해야 할까?

현재의 요구 사항을 확인하며 어떤 선택이 더 효율적일지 생각해보자.

1. 처리 상태가 추가될 가능성은 희박하다.
2. 처리 로직이 변경될 가능성은 존재한다.

필자는 Consumer를 선택했다. 이유는 다음과 같다.

1. 상태가 추가될 가능성이 희박하다. 전략 패턴의 장점이 빛을 발하지 못한다.
2. 전략 패턴은 인터페이스를 분리해야한다. 3개의 상태를 추가하기 위해 인터페이스와 전략 클래스 등을 추가로 구현해야 한다.

결론은 전략 패턴을 사용하여 얻는 이득보다 구현에 필요한 노력이 더 크다고 생각했기에, Consumer를 사용했다.

2. 구현

먼저 Consumer들을 관리할 범용 클래스를 만들어주었다.

@Component
@RequiredArgsConstructor
public class Consumers {

    private final GroupService groupService;
    private final GroupJoinRequestService joinRequestService;
    private final ProfileService profileService;

    private Map<State,BiConsumer<Profile, GroupJoinRequestDto>> groupJoinConsumerMap;

    public BiConsumer<Profile, GroupJoinRequestDto> getGroupJoinConsumer(State state) {
        return groupJoinConsumerMap.get(state);
    }

    @PostConstruct
    public void initGroupJoinConsumerMap() {
        groupJoinConsumerMap = new EnumMap<>(State.class);

        groupJoinConsumerMap.put(State.RESTRICTED, (profile, dto) -> {
            throw new UnAuthorizedException("추방당한 회원입니다. userId : " + profile.getUserId());
        });

        groupJoinConsumerMap.put(State.GENERAL, (profile, dto) -> {
            throw new DuplicateElementException("이미 가입한 그룹입니다.");
        });

        groupJoinConsumerMap.put(State.DELETED, (profile, dto) -> {
            Group group = profile.getGroup();
            if (group.getJoinCondition() == JoinCondition.OPEN) {
                groupService.checkGroupSize(group);
                group.increaseProfileCount();
                profile.setState(State.GENERAL);
            } else {
                joinRequestService.createNewGroupJoinRequest(dto, group);
            }
        });
    }
}

Consumers 클래스는 빈으로 등록해 관리해준다. @PostConstruct를 통해 어플리케이션 실행 시에 처리할 로직들을 등록해준다.

    @Transactional
    public void joinGroup(GroupJoinRequestDto dto, Long groupId) {
        Group group = groupService.findGroupById(groupId);

        if (joinRequestService.pendingRequestExists(group.getId())) {
            throw new DuplicateElementException("이미 가입 요청한 그룹입니다.");
        }

        try {
            Profile profile = profileService.getLoggedInProfile(groupId);

            // 상태에 맞는 컨슈머를 받아옴
            BiConsumer<Profile, GroupJoinRequestDto> action = 
                consumers.getGroupJoinConsumer(profile.getState());

            if (action != null) {
                action.accept(profile, dto);
            } else {
                log.warn(NoStateExceptionMessage, "그룹 가입", profile.getState());
                throw new IllegalStateException("No action found : " + profile.getState());
            }
        } catch (NoLoggedInProfileException e) {
            firstJoinProcess(dto, group);
        }
    }

    private void firstJoinProcess(GroupJoinRequestDto dto, Group group) {
        if (group.getJoinCondition() == JoinCondition.OPEN) {
            groupService.checkGroupSize(group);
            profileService.createNewProfile(dto.getNickname(), jwtReader.getUserId(), GroupRole.MEMBER, group);
        } else {
            joinRequestService.createNewGroupJoinRequest(dto, group);
        }
    }

트랜잭션 스크립트 형식으로 나열되었던 기존 비즈니스 로직들이 모두 사라지고 Consumers 클래스에게 책임을 위임했다. 이를 통해 기존 40줄 정도였던 코드를 20줄 내외로 단축시킬 수 있었다.

바뀐 코드를 리뷰할 때 드는 생각은 어떨까.

1. 그룹을 찾는다.
2. 가입 요청이 있는지 확인한다.
3. 프로필을 조회한다.
4. 프로필에 따라 가입 로직을 실행한다.
5. 프로필을 찾지 못했을 때 첫 가입 로직을 실행한다.

이전보다 확연히 간단해졌고, 비즈니스 요구사항을 알지 못해도 코드 자체를 리뷰할 수 있도록 변경되었다.

마치면서

이번 리팩토링을 진행하면서 가장 많으 느꼈던 것은

남이 보기 좋은 코드를 작성해야 한다.

였다. 항상 그렇게 코드를 짜고 있다고 생각은 했지만, 그건 나만의 생각 전혀 그렇지 않다는 것을 깨달은 아주 값진 경험이었다..!

참고 자료

전략 패턴 if, switch문 Map으로 대체하기 Consumer 인터페이스 사용 방법

이전 두 포스트에선 synchronized 키워드를 통한 문제 해결 방법과 배타적 락을 이용한 문제 해결 방법을 알아보았다.

배타적 락을 이용한 문제 해결은 성능 저하와 데드락 문제를 발생시킬 수 있어 다른 해결 방법을 찾고 있었다.

이번 포스트에선 다른 해결 방법에 해당하는 user-name-lock과 Redis 의 분산 락을 다뤄보겠다.

구현

두 방법 모두 Spring AOP를 통해 구현하였다. 이유는 다음과 같다.

1. 동시성 문제 해결 로직은 많은 곳에서 재사용되는 공통된 관심사이다.
2. 따라서, @Transactional과 같이 어노테이션 기반으로 다양한 로직에서 쉽게 재사용할 수 있게 한다.

1. MySQL의 user-name-lock

프로젝트는 이곳에서 확인하실 수 있습니다. 내용은 Real MySQL을 기반으로 작성하였습니다.

먼저, user-name-lock(USER LOCK 혹은 네임드 락) 에 대해 알아보자.

Real MySQL에선 다음과 같이 나와있다.

GET_LOCK() 함수를 이용해 임의로 잠금을 설정할 수 있다. 이 잠금의 특징은 대상이 테이블이나 코드 또는 AUTO_INCREMENT와 같은 데이터베이스 객체가 아니라는 것이다.

유저 락은 단순히 사용자가 지정한 문자열(String)에 대해 획득하고 반납하는 잠금이다.

... 여러 클라이언트가 상호 동기화를 처리해야 할 때 데이터베이스의 유저 락을 이용하면 쉽게 해결할 수 있다.

먼저, 특정 키를 가진 락을 획득/반환하는 메소드를 만들었다.

@Repository
@RequiredArgsConstructor
public class UserNameLockDAO {

    private final JdbcTemplate jdbcTemplate;

    public void getLock(String key, int timeoutSeconds) {
        String sql = "SELECT GET_LOCK(?, ?)";
        jdbcTemplate.queryForList(sql, key, timeoutSeconds);
    }

    public void releaseLock(String key) {
        String sql = "SELECT RELEASE_LOCK(?)";
        jdbcTemplate.queryForList(sql, key);
    }
}

AOP를 통해 구현할 것이기에 어노테이션을 만들어주었다.

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface UserNameLock {
    // 잠금에 설정할 문자열 키
    String key();

    // 락을 획득하기 위해 대기할 시간
    int leaseTime() default 3;
}

트랜잭션 처리를 위한 별도의 클래스를 만들어주었다. 이유는 아래에서..!

@Component
public class AopForTransaction {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public Object proceed(ProceedingJoinPoint pjp) throws Throwable {
        return pjp.proceed();
    }
}

이후, 락을 획득/반납하는 로직을 구현하였다. 락의 반납은 반드시 이루어져야 하기에, try-finally 구문을 사용했다.

@Slf4j
@Aspect
@Component
@RequiredArgsConstructor
public class UserNameLockAop {

    private final UserNameLockDAO lockDAO;
    private final AopForTransaction aopForTransaction;

    @Around("@annotation(어노테이션_경로.UserNameLock)")
    public Object lock(ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        UserNameLock lock = method.getAnnotation(UserNameLock.class);

        String key = lock.key();
        log.info("key : {}", key);

        try {
            lockDAO.getLock(key, lock.leaseTime());
            return aopForTransaction.proceed(joinPoint);
        } finally {
            lockDAO.releaseLock(key);
        }
    }
}

자. 이제 구현한 user-name-lock을 사용해보자.

    @UserNameLock(key = "'group:'.concat(#groupId)")
    public void joinGroup(GroupJoinRequestDto dto, Long groupId) {
        ...
    }

2. Redis의 분산 락

Redis는 Remote Dictionary Server의 약자로 키(Key) - 값(Value) 쌍의 해시 맵과 같은 구조를 가진 비관계형(NoSQL) 데이터베이스 관리 시스템(DBMS)이다.

Redis는 in-memory 데이터 구조 저장소로 메모리에 데이터를 저장하기에, 디스크에 접근하는 DB보다 빠른 속도를 자랑하며, 이 때문에 주로 캐시 서버로 사용된다.

Redis는 싱글 스레드로 동작한다는 특징 또한 있는데, 이 때문에 동시성 문제를 해결하는데에 자주 사용된다.

프로젝트는 이곳에서 확인하실 수 있습니다. 구현은 Kurly Tech blog를 참고해 구현하였습니다.

먼저 의존성을 추가한다. 버전은 이곳에서 볼 수 있다.

dependencies {
    implementation 'org.redisson:redisson-spring-boot-starter:3.31.0'
}

마찬가지로 어노테이션을 생성한다.

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RedisLock {

    // 잠금 설정할 문자열 키
    String key();

    TimeUnit timeUnit() default TimeUnit.SECONDS;

    // 락을 얻기 위해 대기할 최대 시간
    long waitTime() default 5L;

    // 락을 보유할 수 있는 최대 시간
    long leaseTime() default 3L;
}

Redisson 구현체를 사용하기 위한 설정을 한다. 필요한 정보를 적고, RedissonClient를 빈으로 등록한다.

# .yml 설정 파일
spring:
  data:
    redis:
      host:
      port: 

@Slf4j
@Configuration
public class RedissonConfig {

    @Value("${spring.data.redis.host}")
    private String redisHost;

    @Value("${spring.data.redis.port}")
    private int redisPort;

    private static final String REDISSON_HOST_PREFIX = "redis://";

    @Bean
    public RedissonClient redissonClient() {
        log.info("Connecting to Redis at {}:{} ", redisHost, redisPort);
        Config config = new Config();
        config.useSingleServer().setAddress(REDISSON_HOST_PREFIX + redisHost + ":" + redisPort);
        return Redisson.create(config);
    }
}

이제 AOP를 통해 락 처리에 대한 로직을 작성해보자. 위와 마찬가지로 트랜잭션을 위한 클래스를 만든다.

@Component
public class AopForTransaction {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public Object proceed(ProceedingJoinPoint pjp) throws Throwable {
        return pjp.proceed();
    }
}

이후 락을 획득/반납하는 로직을 구현한다.

@Slf4j
@RequiredArgsConstructor
@Aspect
@Component
public class RedisLockAop {
    private static final String REDIS_LOCK_PREFIX = "LOCK:";

    private final RedissonClient redissonClient;
    private final AopForTransaction aopForTransaction;

    @Around("@annotation(어노테이션_경로.RedisLock)")
    public Object lock(ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        RedisLock redisLock = method.getAnnotation(RedisLock.class);

        String key = REDIS_LOCK_PREFIX + CustomSpringELParser.getDynamicValue(
                signature.getParameterNames(), joinPoint.getArgs(), redisLock.key());

        RLock rLock = redissonClient.getLock(key);

        try {
            boolean available = rLock.tryLock(redisLock.waitTime(), redisLock.leaseTime(), redisLock.timeUnit());
            if (!available) {
                return false;
            }
            return aopForTransaction.proceed(joinPoint);
        } catch (InterruptedException e) {
            throw new InterruptedException();
        } finally {
            try {
                rLock.unlock();
            } catch (IllegalMonitorStateException e) {
                log.info("이미 반납된 락 : {}", key);
            }
        }
    }
}

Redisson 구현체는 pub/sub 방식의 재시도 로직을 지원하기에 별도로 구현할 필요가 없다. 또한, 이는 디폴트 구현체인 Lettuce의 스핀 락 방식보다 Redis에 더 적은 부하를 가한다.

자. 이제 구현한 어노테이션을 사용해 락을 적용해보자.

    @RedisLock(key = "'group:'.concat(#groupId)")
    public void joinGroup(GroupJoinRequestDto dto, Long groupId) {
        ...
    }

왜?

1. 별도의 트랜잭션?

두 방법 모두 트랜잭션을 시작하는 별도의 클래스를 두었다.

@Component
public class AopForTransaction {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public Object proceed(ProceedingJoinPoint pjp) throws Throwable {
        return pjp.proceed();
    }
}

동시성 문제와 synchronized의 스프링의 선언적 트랜잭션 관리 에서 이미 언급한 문제인데, 락을 획득하기 전에 트랜잭션이 이미 시작되는 문제가 존재한다.

메소드 자체에 @Transactional을 통해 구현한다면 다음과 같은 흐름을 갖는다. 락을 획득하기 전에 트랜잭션이 시작되기에, REPEATABLE READ 격리 수준에선 동시성 문제를 아예 해결할 수 없다.

또한, 트랜잭션보다 락이 먼저 해제되기 때문에 첫번째 트랜잭션이 커밋되기 전 두번째 트랜잭션이 락을 획득할 가능성 또한 존재한다.

AopForTransactional 클래스를 도입한 후의 흐름을 보자. 락을 획득한 후, 트랜잭션을 시작하며 트랜잭션이 종료되어 변경이 모두 반영된 후에 락을 반납한다.

이를 통해 기존의 문제였던 REPEATABLE READ와 @Transactional 문제를 해결한다.

2. 트랜잭션 전파

AopForTransactional 클래스를 보면 전파 수준이 REQUIRES_NEW로 지정한 것을 볼 수 있다.

이를 알아보기 위해 한가지 상황을 생각해보자.

어떠한 로직 내부에서 joinGroup() 메소드를 호출해야 한다.

@Transactional
public void 어떠한_메소드() {
    ...
    joinGroup(...);
}

만약 전파 수준이 디폴트인 REQUIRED로 되어있다면, joinGroup() 메소드의 트랜잭션은 어떠한_메소드 의 트랜잭션에 참여하게 될 것이다.

AopForTransaction이라는 별도의 클래스를 뒀음에도 동일한 문제가 발생한다. 기존 트랜잭션에 참여하기에 트랜잭션 시작 시점과 락 해제 시점 모두 뒤틀리게 된다.

REQUIRES_NEW 전파 수준을 사용함으로써 joinGroup() 메소드를 독립적인 트랜잭션으로 동작함을 지정함으로써 다시 발생한 동시성 문제를 해결한다.

무엇을 선택해야 할까

1. MySQL의 USER-LEVEL-LOCK

USER-LEVEL-LOCK을 사용했을 때 느꼈던 가장 큰 장점은

별도의 무언가가 추가 될 필요가 없다.

Redis를 사용하기 위해서 했던 작업들은 다음과 같다.

1. Redis 설치
2. Redis client 구현체 확인
3. 스프링 적용 방법 확인, 구현

하지만, USER-LEVEL-LOCK을 사용할 땐 락 획득을 위한 쿼리만 작성해주면 되기에 훨씬 비교적 간단했다.

다만, DB가 락을 관리한다는 것은 그만큼 많은 작업을 DB에 위임한다는 것이며, 그만큼의 부하가 추가된다는 단점이 존재한다.

2. Redis

Redis는 많은 곳에서 사용하고 있는 만큼 자료가 많았다. 락의 관리를 별도의 Redis 서버에서 관리하기에 DB 부하가 그만큼 감소한다는 장점 또한 있다.

다만, Redis 또한 단점이 존재하는데, 락을 위해 Redis를 도입함으로써 Redis가 단일 장애지점이 될 수 있다는 것이다. 이에 Redis측은 클러스터링과 Red Lock 알고리즘을 사용하여 문제를 해결한다. 채널톡 개발 볼로그에 의하면 성능 저하가 극심하기에 가용성이 중요한 상황이라면, Redis Cluster보다는 Zookeeper Cluster를 활용하는 것이 더 올바른 방향이고, Zookeeper는 많이 무겁다고 한다.

또한, Redis라는 관리 대상이 하나 추가되기에 인프라 관리에 보다 많은 관심을 요하게 된다.

3. trade-off

모두 구현해보며 현재 상황에서 가장 좋다고 느낀 것은 USER-LEVEL-LOCK이다.

단순히 Locking을 위해 Redis를 도입하는 건 굉장한 낭비라고 생각되었다. 도입하기 위해 투자할 시간, 도입한 후 관리에 투자할 시간을 모두 합한다면 가성비가 좋지 않다고 느껴졌다.

다만, USER-LEVEL-LOCK은 결국 DB가 관리하기에 데이터베이스에 부하가 추가되기에 Locking 작업이 많아질 경우 성능 저하에 대해서도 고려해야 할 것이다.

Redis를 이미 사용중이거나 다른 문제를 해결하기 위해 도입을 생각하는 중이라면 충분히 도입할 만 하다고 생각한다.

참고 자료

Kurly Tech blog - 풀필먼트 입고 서비스팀에서 분산락을 사용하는 방법 - Spring Redisson 레디스란 무엇인가? - 특징, 장단점, 사용 사례 redis docs - distributed lock 채널톡 개발 블로그 - Distributed Lock 구현 과정

들어가기에 앞서

프로젝트를 진행하며 동시성 문제가 발생했다.

단일 시스템

이전 포스트에선 synchronized 키워드를 통해 임계 영역을 지정하여 해결하는 전통적인 방식을 구현해보았다.

분산 시스템

다만 위와 같은 방법은 여러 컴퓨터가 네트워크를 통해 연결되어 하나의 시스템처럼 동작하도록 설계된 분산 시스템에선 의도한대로 동작하지 않는다.

그렇다면 분산 시스템에선 어떻게 동시성 문제를 해결해야 할까?

데이터베이스 락킹

비관적 락과 낙관적 락

DB 레벨에서의 락킹을 찾아봤을 때 가장 먼저 나온 것들이다.

비관적 락 은 현재 변경하고자 하는 레코드를 다른 트랜잭션에서도 변경할 수 있다는 비관적인 가정 을 하기에 비관적 락 이라고 부르며,

낙관적 락 은 각 트랜잭션이 같은 레코드를 변경할 가능성이 희박할 것이라 낙관적인 가정 을 하기에 낙관적 락 이라 부른다.

무슨 차이가 있을까?

아이러니하게도 낙관적 락은 보통 DB 레벨에서 지원하지 않는다. 낙관적 락은 보통 어플리케이션 레벨에서 지원하며, JPA는 보다 간단하게 낙관적 락을 사용할 수 있도록 지원하고 있다.

비관적 락은 변경하고자 하는 레코드에 대한 락을 획득한 후 작업을 진행한다. 기본적으로 MySQL의 InnoDB 엔진은 비관적 락을 채택하고 있다.

아쉽게도 이 포스트에선 낙관적 락을 다루지 않는다. 다만, 잘 정리된 포스트가 존재하기에 공유해본다.

잡설

비관적 락 과 낙관적 락 을 공부하며 개인적으로 synchronized 와 CAS 알고리즘 의 차이가 떠올랐다.

synchronized 는 메소드 혹은 블록 수준에 임계 영역을 지정하여 다른 스레드로부터의 접근을 차단하는 방법이다. CAS 알고리즘 은 Atomic한 자료형에서 사용하는 방법인데, 기대하는 값과 다르다면 연산을 진행하지 않는 방법이다.

공유 락과 배타적 락

비관적 락은 크게 공유 락 과 배타적 락 으로 구분된다.

공유 락 은 다른 트랜잭션이 읽거나 또 다른 공유 락 의 접근을 허용한다. 다만, 배타적 락 의 접근, 즉 쓰기 작업을 제한한다.

# 공유 락
SELECT * FROM table_name WHERE id = 1 FOR SHARE;

배타적 락 은 다른 트랜잭션이 해당 레코드에 접근하는 것 자체를 막는다. 단, 락을 사용하지 않는 읽기 작업은 접근을 허용한다.

# 배타적 락
SELECT * FROM table_name WHERE id = 1 FOR UPDATE;

구현

현재 비즈니스 로직은 다음과 같다.

그룹 가입 시, 현재 인원이 제한 인원에 걸리는지 확인 후 가입을 진행한다.

두 트랜잭션이 동시에 접근한다고 가정해보자. 처음 접근한 트랜잭션이 완료된 후 현재 인원을 확인해야 한다. 따라서 배타적 락 을 사용해 동시성 문제를 해결하였다.

JPA에선 어노테이션을 통해 간편하게 배타적 락 을 사용할 수 있다.

// GroupRepository
@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT g FROM music_group g WHERE g.id = :id")
Optional<Group> findByIdWithLock(@Param("id") Long id);

그룹을 조회할 때 위 메소드를 사용하도록 변경했다.

   @Transactional
    public void joinGroup(GroupJoinRequestDto dto, Long groupId) {
        Group group = groupService.findGroupByIdWithLock(groupId);
        ...
    }

발생하는 쿼리를 확인해보자.

2024-06-13T00:06:58.984+09:00 DEBUG 15024 --- [group-service] [nio-8082-exec-1] org.hibernate.SQL                        : select g1_0.id,g1_0.created_date,g1_0.description,g1_0.group_scope,g1_0.group_size,g1_0.join_condition,g1_0.name,g1_0.owner_user_id,g1_0.profile_count,g1_0.state,g1_0.updated_date from music_group g1_0 where g1_0.id=? for update

for update 가 붙은 query가 발생함을 확인할 수 있다. 보다 늦게 실행된 두번째 요청은 정상적으로 실패함을 확인할 수 있었다.

왜?

1. 트랜잭션 격리 수준

이전 포스트에서 synchronized 키워드를 통해 문제를 해결할 때도 발생했던 문제가 있다. 바로 트랜잭션 격리 수준, 그 중 MySQL의 기본 수준인 Repeatable Read와 관련된 문제이다.

트랜잭션이 시작된 시점의 데이터만을 조회한다.

@Transactional 어노테이션을 동일하게 사용했기에 두번째 요청 의 트랜잭션은 여전히 첫번째 요청 커밋 전에 시작된다. 그렇다면 두번째 요청 이 조회해도 변경이 적용되지 않은 데이터가 조회되어야 하는게 아닐까?

다행히도 Real MySQL 5.7 책에 동일한 내용을 찾을 수 있었다.

REPEATABLE READ 수준의 동일 트랜잭션 내에서 SELECT 쿼리 결과는 항상 동일해야 한다.

SELECT .. FOR UPDATE 쿼리는 SELECT 하는 레코드에 쓰기 잠금을 걸어야 하는데, 언두 레코드에는 잠금을 걸 수 없다.

그래서 SELECT .. FOR UPDATE 나 SELECT .. LOCK IN SHARE MODE 로 조회되는 레코드는 언두 영역의 변경 전 데이터를 가져오는 것이 아니라 현재 레코드의 값을 가져오게 되는 것이다.

잡설

언두(UNDO) 영역은 트랜잭션의 롤백과 트랜잭션 격리 수준의 요구를 구현하기 위해 사용된다.

REPEATABLE READ는 언두 영역에 존재하는 데이터를 확인함으로써 트랜잭션 시작 시점의 데이터를 조회할 수 있다.

2. 성능 이슈

레코드 자체에 락을 건다는 건 해당 레코드에 접근하는 다른 요청들이 대기해야 한다는 의미다.

또한 두 요청이 각각의 레코드 락을 보유한 채로 서로의 레코드 락을 얻기 위해 대기한다면 데드락이 발생할 수도 있다.

3. 다른 방법은?

1. USER LOCK

user-level-lock, 혹은 Named Lock이라고도 불리는 방법이다. 이 락은 특이하게도 테이블, 레코드와 같은 데이터베이스 객체를 잠그지 않고, 특정 문자열(String)를 통해 락을 획득하고 해체하는 락킹 기법이다.

배타적 락 을 사용했을 때, 레코드 자체의 접근을 제한함으로써 다른 요청에서 동일한 레코드에 접근하기 위해 대기해야 하는 성능 문제가 발생한다고 했다.

유저 락을 지정한다면 특정 문자열, 즉 그룹 가입이라는 락을 따로 두어 다른 작업 시 대기하는 성능 문제와 데드락 문제를 해결할 수 있다.

2. 분산 락

동시성 문제를 해결하기 위해 가장 흔히 보이는 방법이다. 보통 Redis를 이용하며, 인메모리 캐시라는 특성 상 빠른 속도를 자랑한다.

마치면서

DB Level에서 동시성 문제를 해결할 수 있는 비관적 락, 그 중 배타적 락에 대해 알아보았다.

다음 포스트에선 위의 두가지 방법에 대해 구현하며 알아보겠다.

참고 자료

Real MySQL mysql docs flab - 분산 시스템 설계의 핵심: 분산 락의 이해와 적용 LJH - 동시성 문제 해결하기 V1 - 낙관적 락 hudi.blog - MySQL 8.0의 공유 락(Shared Lock)과 배타 락(Exclusive Lock) haon.blog - MySQL 네임드 락으로 분산 환경에서의 동시성 이슈를 해결해보자!

기존 그룹 인원 체크 로직은 아래와 같았다.

해당 그룹의 활성화된 프로필 개수를 조회

만약 특정 그룹에 가입한 사람이 10,000명이라고 가정해보자. 가입 프로세스를 진행하기 위해선 10,000개의 레코드를 읽어야 하며, 시간이 지날 수록 더욱 늘어날 것이다. 이에 group 테이블에 profile_count 라는 컬럼을 추가해 로직을 변경했다.

group 테이블의 profile_count를 조회

자연스럽게 서비스 로직 또한 GroupService 로 이관했고, 기존 로직에서 호출하는 메소드만 변경해주었다.

이러한 과정에서 발생한 문제와, 해결 과정에 대해 적어볼까 한다.

문제

1. 순환 의존 문제

로직 변경 전 의존 관계를 살펴보자. GroupService 는 가입 요청 의 존재 여부에 따라 중복 가입 요청에 대한 처리를 진행한다.

각 서비스는 ProfileService 의 인원 검사 로직을 호출하고 있다.

    @Transactional(readOnly = true)
    public void checkGroupSize(Group group) {
        if (profileRepository.countByGroupIdAndState(
            group.getId(), State.GENERAL) >= group.getGroupSize()) {
            throw new GroupFullException(
                "최대 인원인 그룹입니다. id : " + group.getId());
        }
    }

변경 후의 의존 관계를 살펴보자. ProfileService 가 사라지고, 그 자리를 GroupService 가 차지했다. 문제는 두 서비스가 서로 순환하는 의존 관계가 발생했다는 것이다.

순환 의존 문제 발생!!

The dependencies of some of the beans in the application context form a cycle:

   groupController defined in file 
┌─────┐
|  groupService defined in file 
↑     ↓
|  groupJoinRequestService defined in file 
└─────┘

2. 복잡한 의존 관계

위 다이어그램에선 최소한의 의존 관계만을 표시했지만, 보다 많은 의존 관계가 엮여있고, 어플리케이션 규모가 커진다면 더욱 복잡해질 것이다.

3. 분산된 관심

현재 그룹에 가입하기 위해선 GroupService 를 통해 즉시 가입하거나, GroupJoinRequestService 에서 그룹 가입 요청을 승낙해야 한다.

해결

Facade Pattern이란?

Facade, 퍼사드라고 읽는 이 패턴은 어떤 패턴일까? Wikipedia엔 다음과 같이 나와있다.

Facade (외관)는 "건물의 정면"을 의미한다.

퍼사드 패턴은 말 그대로 복잡한 시스템을 간단하게 사용하기 위해 제작되는 인터페이스이다.

도입으로 얻은 이득

1. 응집도 상승

분산된 관심이라는 말이 적절한지는 잘 모르겠다만, 그룹 가입이라는 하나의 관심이 GroupService 와 GroupJoinRequestService 두 서비스 클래스에 분산되어 존재한다는 의미로 작성하였다.

두 클래스에 나눠져 존재하는 그룹 가입이라는 기능을 추출하여 하나의 퍼사드 클래스로 작성함으로써 응집도를 높였다.

2. 의존 복잡도 감소

분산된 그룹 가입이라는 관심은 GroupService 와 GroupJoinRequestService 모두에게 불필요한 의존을 만들었다.

이를 하나의 퍼사드 클래스로 추출함으로써 기존 클래스들의 불필요한 의존 관계가 사라지고, 복잡도가 감소했다.

참고 자료

eungding - [클린 아키텍처] 의존성 순환 (cyclic dependency) 의 문제와 해결방안 Inpa Dev - 퍼사드(Facade) 패턴 - 완벽 마스터하기

들어가기에 앞서

프로젝트의 요구 사항에 그룹 인원 제한이 추가되었다. 그룹을 처음 만들면 기본적으로 10명의 제한이 걸리게되며, 추후 과금을 통해 인원을 늘리는 비즈니스 모델을 생각해보았다.

하지만 예상과 다르게 인원수 제한을 넘어 가입되는 문제가 발생했는데...

문제를 재현해보자

문제 해결의 시작은 문제를 만드는 것 부터라는 내용을 어디선가 본 것 같다. 혼자만의 생각일지도..? 동시성 문제가 항상 재현될 수 있도록 코드를 수정해보자.

    @Transactional
    public void joinGroup(GroupJoinRequestDto dto, Long groupId) {
        ...

        // 그룹 인원 확인
        profileService.checkGroupSize(group);

        // 가입 진행
        profileService
               .createNewProfile(dto.getNickname(), GroupRole.MEMBER, group);

        ...

        try {
            Thread.sleep(5000);
        } catch (InterruptedException ex) {
            // 동시성 이슈 발생용
        }
    }

메소드가 끝나기 전 5초의 sleep을 주었다. 이제 5초 안에 두번의 요청을 날릴 시 반드시 동시성 문제가 발생한다!

동시성 문제란?

동시성 문제를 한줄로 표현하자면 다음과 같다.

하나의 공유자원에 여러 스레드가 동시에 접근함으로써 발생하는 문제

현재 로직 상 문제가 발생하는 부분을 찾아보자.

1. 현재 1번 그룹에 9명이 존재한다.
2. 사용자 A가 가입을 요청한다.
3. 현재 그룹의 인원을 체크한다. 9명이다.
4. 사용자 B도 가입을 요청한다.
5. 현재 그룹의 인원을 체크한다. 사용자 A의 가입이 처리되지 않았기에 역시 9명이다.
6. 사용자 A의 가입이 처리된다. 그룹이 가득 찬다.
7. 사용자 B의 가입이 처리된다. 그룹은 이미 가득 찼지만, 사용자 A의 가입이 처리되기 전 인원 체크를 통과했기에 정상적으로 처리된다.
8. 결과적으로, 사용자 A, B 모두 가입되며 그룹은 11명이 존재하게 된다.

결국, 사용자 A의 가입 요청이 끝난 후에 사용자 B의 가입 요청이 시작되어야 한다. Java에선 이런 문제를 synchronized 키워드를 통해 간단히 해결할 수 있다.

동시성 문제와 synchronized

이제 synchronized 키워드로 문제를 해결해보자.

    @Transactional
    public synchronized void joinGroup(
        GroupJoinRequestDto dto, Long groupId) {
        ...
        try {
            Thread.sleep(5000);
        } catch (InterruptedException ex) {
            // 동시성 이슈 발생용
        }
    }

위와 같이 메소드 자체에 임계 영역을 설정하는 방법을 synchronized method라고 한다. 동일 인스턴스의 메소드에 하나의 스레드만의 접근을 허용함으로써 동시성 문제를 해결한다.

굉장히 간단히 동시성 문제를 해결하였다! 자, 다시 문제가 재현되는지 확인해보자.

예상과 다르게 여전히 문제가 발생한다.

문제 도출

1. 혹시 synchronized 메소드가 예상과 다르게 동작하는건 아닐까?

먼저 로그를 찍어 확인해봤다.

    @Transactional
    public synchronized void joinGroup(
        GroupJoinRequestDto dto, Long groupId) {

        LocalDateTime now = LocalDateTime.now();
        DateTimeFormatter formatter = 
            DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
        log.info("method called. time : {}", now.format(formatter));

        ...
        try {
            Thread.sleep(5000);
        } catch (InterruptedException ex) {
            // 동시성 이슈 발생용
        }
    }

...GroupService    : method called. time : 2024-06-08 01:39:56
...GroupService    : method called. time : 2024-06-08 01:40:02

메소드는 정상적으로 임계 영역이 지정되었으며, 5초 대기 후 다음 요청이 해당 메소드에 진입한다.

2. 트랜잭션이 커밋되기 전 다음 요청이 시작되었나?

이를 확인하기 위해 JPA와 스프링 트랜잭션의 로깅 레벨을 DEBUG로 설정하였다.

logging:
  level:
    org:
      hibernate:
        SQL: DEBUG
        transaction: DEBUG
      springframework:
        orm:
          jpa: DEBUG
        transaction: DEBUG

이후 발생한 로그를 확인해보니

2024-06-08T01:48:58.498+09:00 DEBUG 16620 --- [group-service] [nio-8082-exec-1] o.j.s.OpenEntityManagerInViewInterceptor : Opening JPA EntityManager in OpenEntityManagerInViewInterceptor
   ...
// 커밋 완료
2024-06-08T01:49:03.991+09:00 DEBUG 16620 --- [group-service] [nio-8082-exec-1] o.s.orm.jpa.JpaTransactionManager        : Committing JPA transaction on EntityManager [SessionImpl(112250976<open>)]

// 다음 요청 처리 시작
2024-06-08T01:49:03.991+09:00 DEBUG 16620 --- [group-service] [nio-8082-exec-4] org.hibernate.SQL                        : select g1_0.id,g1_0.created_date,g1_0.description,g1_0.group_scope,g1_0.group_size,g1_0.join_condition,g1_0.name,g1_0.owner_user_id,g1_0.state,g1_0.updated_date from music_group g1_0 where g1_0.id=?

역시 정상적으로 트랜잭션이 커밋된 후 다음 요청이 진행되는 것을 볼 수 있었다.

다만, 예상과는 다르게 진행된 부분이 한가지 있었는데 첫번째 요청의 트랜잭션이 커밋되기 한참 전부터 두번째 요청의 트랜잭션이 시작되었다는 것이다.

// 요청 1 트랜잭션 시작
2024-06-08T01:48:58.630+09:00 DEBUG 16620 --- [group-service] [nio-8082-exec-1] o.s.orm.jpa.JpaTransactionManager        : Creating new transaction with name [me.kong.groupservice.service.GroupService.joinGroup]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
   ...
// 요청 1이 synchronized method에 진입
2024-06-08T01:48:58.656+09:00  INFO 16620 --- [group-service] [nio-8082-exec-1] m.k.groupservice.service.GroupService    : method called. time : 2024-06-08 01:48:58
   ...
// 요청 1 처리중...
   ...
// 요청 2 트랜잭션 시작
2024-06-08T01:49:00.934+09:00 DEBUG 16620 --- [group-service] [nio-8082-exec-4] o.s.orm.jpa.JpaTransactionManager        : Creating new transaction with name [me.kong.groupservice.service.GroupService.joinGroup]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
   ...
// 요청 2가 synchronized method에 진입
2024-06-08T01:49:03.990+09:00  INFO 16620 --- [group-service] [nio-8082-exec-4] m.k.groupservice.service.GroupService    : method called. time : 2024-06-08 01:49:03
   ...
// 요청 1 트랜잭션 커밋
2024-06-08T01:49:03.991+09:00 DEBUG 16620 --- [group-service] [nio-8082-exec-1] o.s.orm.jpa.JpaTransactionManager        : Committing JPA transaction on EntityManager [SessionImpl(112250976<open>)]
   ...
// 요청 2 처리중...
   ...
// 요청 2 커밋
2024-06-08T01:49:09.069+09:00 DEBUG 16620 --- [group-service] [nio-8082-exec-4] o.s.orm.jpa.JpaTransactionManager        : Committing JPA transaction on EntityManager [SessionImpl(147937689<open>)]

데이터베이스의 트랜잭션 격리수준을 확인해보자.

REPEATABLE-READ로 설정되어 있다. 이를 간단히 말해보자면 트랜잭션이 시작한 시점의 데이터를 반환한다는 것이다.

JPA와 트랜잭션 로그를 봤을 때, 첫번째 요청이 커밋되기 전 두번째 요청의 트랜잭션은 이미 시작된 것을 볼 수 있었다. 이는 즉, 두번째 요청의 트랜잭션이 첫번째 요청 커밋 전에 시작되었기에 두번째 요청은 첫번째 요청의 변경 사항을 읽을 수 없다는 것이고, 메소드 호출은 정상적으로 이루어졌어도 두번째 요청은 첫번째 요청으로 인해 변경된 데이터를 읽지 못한다는 것이다.

그렇다면 임계 영역이 끝나기도 전에 두번째 요청의 트랜잭션이 시작됐을까? 의심가는건 단 하나밖에 없다!

3. 스프링의 선언적 트랜잭션 관리

스프링은 @Transactional 어노테이션을 통해 간편하게 트랜잭션을 관리할 수 있다. 위 어노테이션을 사용할 시 Spring AOP에 의해 Proxy 객체가 생성되고, 해당 메소드에서 트랜잭션을 시작, 원래의 로직을 실행한다.

생성된 프록시 객체를 확인해보자.

class GroupServiceProxy extends GroupService{

    private GroupService groupService;

    @Override
    public void joinGroup(GroupJoinRequestDto dto, Long groupId) {
         try{
             tx.start();
             groupService.joinGroup(dto, groupId);
         } catch (Exception e) {
             // ...
         } finally {
             tx.commit();
         }
    }
}

public class GroupService {
    ...
    @Transactional
    public synchronized void joinGroup(
        GroupJoinRequestDto dto, Long groupId) {

        LocalDateTime now = LocalDateTime.now();
        DateTimeFormatter formatter = 
            DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
        log.info("method called. time : {}", now.format(formatter));

        ...
        try {
            Thread.sleep(5000);
        } catch (InterruptedException ex) {
            // 동시성 이슈 발생용
        }
    }
    ...
}

트랜잭션을 시작하고 종료하는 부분엔 임계 영역이 지정되지 않았다. 이 때문에 작성한 메소드 자체에는 임계영역이 잘 지정되었어도 트랜잭션은 미리 시작하는 문제가 발생한 것이다.

해결

스프링의 선언적 트랜잭션이 문제라면 사용하지 않으면 그만이다.

    public synchronized void joinGroup(
        GroupJoinRequestDto dto, Long groupId) {

        // 트랜잭션 시작
        TransactionStatus status = transactionManager
            .getTransaction(new DefaultTransactionDefinition());

        try {

            LocalDateTime now = LocalDateTime.now();
            DateTimeFormatter formatter = 
                DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
            log.info("method called. time : {}", now.format(formatter));

            ...
            try {
                Thread.sleep(5000);
            } catch (InterruptedException ex) {
                // 동시성 이슈 발생용
            }
            transactionManager.commit(status); //성공시 커밋
        } catch (Exception e) {
            transactionManager.rollback(status);
        }
    }

이제 synchronized method를 통해 정상적으로 동시성 문제를 해결할 수 있게 되었다!

마치면서

synchronized 키워드를 통해 굉장히 간단하게 동시성 문제를 해결해보았다. 다만, 이 방법에는 치명적인 단점이 존재하는데 그건 바로

scale-out 시 무용지물이 된다.

하나의 서버에서 임계 영역을 지정하기에 여러 서버에서 동시에 실행되는 문제는 막을 수 없다는 것이다. 그렇다면 어떻게 해야 할까?

다음 포스트엔 데이터베이스에 락을 걸어 해결하는 낙관적 락, 비관적 락을 적용해보겠다.

참고 자료

망나니개발자 - 트랜잭션 격리 수준

이전 포스트에선 프로젝트에 netflix eureka와 reactive gateway를 적용했다.

적용하기 전엔 각각의 마이크로 서비스가 담당하는 기능을 테스트하기 위해선 Postman에 서비스 별 포트번호를 직접 적어줘야했다.

적용 후, 8080번에서 대기중인 api gateway을 통해 더이상 어떤 서비스가 어디에 열려있는지 알지 못해도 요청할 수 있게 되었다..!

문제점

기능 개발을 진행하면서 로컬 환경에서 어플리케이션을 실행하고, Postman을 통해 구현한 기능이 의도한대로 동작하는지 확인하는 과정이 있었다.

api gateway를 적용하기 전엔 테스트하기 참 단순했다.

테스트할 마이크로서비스 실행하고.. 열린 포트로 요청을 날리자!

api gateway를 적용한 후, 하나의 마이크로서비스를 실행하기 위해선 다음과 같은 과정이 추가되었다.

유레카 서버 실행하고.. api gateway 실행하고.. 테스트할 마이크로서비스 실행하고... api gateway로 요청을 날리자!

물론 프로필을 구분하여 로컬에선 단일로 실행되도록 할 수 있지만, 결국 클라우드에 올려 사용할 것이므로 이참에 Docker를 적용해보기로 했다.

Dockerfile 작성

도커 개념정리를 목적으로 하는 포스트가 아니기에 원리 및 구현은 생략하겠습니다..!

먼저, 도커 이미지를 생성하기 위해 Dockerfile을 작성했다.

# 빌드 환경 구성
FROM amazoncorretto:21
WORKDIR /workspace/app

# JAR 파일 복사
COPY ./build/libs/user-service-0.0.1-SNAPSHOT.jar /workspace/app/user-service.jar

ENTRYPOINT ["java", "-jar", "user-service.jar"]

Dockerfile은 간단하게 작성했다. 다른 분들이 작성한 예시를 보니 Dockerfile 내부에서 직접 빌드하는 경우도 있었지만, 빌드된 jar 파일을 복사하는것으로 간단하게 작성했다.

위와 같은 Dockerfile을 유레카 서버, api gateway, 마이크로서비스들 모두 작성해주었다.

docker compose

도커의 컨테이너는 내부적으로 각각의 IP와 Port를 배정받는다.

문제는 api gateway와 마이크로서비스들이 유레카 서버를 알고 있어야 한다는 것인데, 현재 하나의 NCP 서버 인스턴스를 사용중이며, 각 서비스마다 별도의 인스턴스를 할당할 것이 아니므로 docker compose를 이용해 관리하기로 했다.

version: '3'
services:
  eureka-discovery:
    build:
      context: ./eureka-discovery
      dockerfile: Dockerfile
    container_name: eureka-discovery
    ports:
      - "8761:8761"
    networks:
      - eureka-network

  api-gateway:
    build:
      context: ./api-gateway
      dockerfile: Dockerfile
    container_name: api-gateway
    ports:
      - "8080:8080"
    environment:
      - EUREKA_SERVER_URI=http://eureka-discovery:8761/eureka/
    depends_on:
      - eureka-discovery
    networks:
      - eureka-network

  user-service:
    build:
      context: ./user-service
      dockerfile: Dockerfile
    container_name: user-service
    ports:
      - "8081:8081"
    environment:
      - EUREKA_SERVER_URI=http://eureka-discovery:8761/eureka/
    depends_on:
      - eureka-discovery
    networks:
      - eureka-network

  group-service:
    build:
      context: ./group-service
      dockerfile: Dockerfile
    container_name: group-service
    ports:
      - "8082:8082"
    environment:
      - EUREKA_SERVER_URI=http://eureka-discovery:8761/eureka/
    depends_on:
      - eureka-discovery
    networks:
      - eureka-network

networks:
  eureka-network:
    driver: bridge

이제 브릿지 네트워크를 통해 모든 서비스가 유레카 서버에 접근할 수 있게 되었다..!

두번째 문제

docker-compose를 통해 서비스들을 실행시켰다. 명령어 한번으로 모든 서비스가 실행되고, 관리할 수 있다니...!

하지만 문제가 발생했다. 유레카 서버에 아무 서비스도 등록되지 않았다.

로그를 확인해보니 유레카 서버를 찾을 수 없다고 나와있었다.

stack overflow - there is not are not services registered in eureka server 와 완전히 동일한 문제가 발생했다.

다만 위에선 eureka의 defaultZone 설정을 localhost로 해놨지만, 필자의 경우 도커 네트워크의 유레카 서비스의 이름으로 정상적으로 등록되어 있었다. 그럼에도 불구하고 유레카 서버를 향한 요청이 localhost로 나갔다.

결론부터 말하자면 Dockerfile 생성의 문제였다. 기존의 Dockerfile을 다시 보자.

수정 전 Dockerfile

# 빌드 환경 구성
FROM amazoncorretto:21
WORKDIR /workspace/app

# JAR 파일 복사
COPY ./build/libs/user-service-0.0.1-SNAPSHOT.jar /workspace/app/user-service.jar

ENTRYPOINT ["java", "-jar", "user-service.jar"]

jar 파일을 실행하면서 설정 파일을 로드하는데, 컨테이너 내부에 application.yml 파일이 존재하지 않아 설정이 적용되지 않았던 것이었다.

유레카 뿐만 아니라 다른 모든게 안됐다는거니... 아찔하다.

이후 Dockerfile을 수정하고 실행했더니 잘 등록되었다..!

수정 후 Dockerfile

# 빌드 환경 구성
FROM amazoncorretto:21
WORKDIR /workspace/app

# JAR 파일 복사
COPY ./build/libs/api-gateway-0.0.1-SNAPSHOT.jar /workspace/app/api-gateway.jar
COPY ./src/main/resources/application.yml /workspace/app
COPY ./src/main/resources/application-route.yml /workspace/app

ENTRYPOINT ["java", "-jar", "api-gateway.jar", "--spring.config.location=file:/workspace/app/application.yml"]

마치며

Docker와 docker-compose를 적용해 컨테이너 기반의 배포 환경을 준비했다.

이를 기반으로 CI/CD 또한 적용해봐야지..!

참고자료

stack overflow - there is not are not services registered in eureka server 생활코딩 - 도커 입구수업 생활코딩 - 도커 Contributor9 - Docker 환경설정

클라우드가 대세가 되며 많은 서비스가 scale-out을 통해 증가하는 트래픽을 감당하고 있다. 이러한 변화는 개발 패러다임에도 큰 변화를 일으켰는데, 그 중 하나가 MSA(Microservices Architecture)라고 생각한다.

MSA는 보다 작은 단위로 서비스를 구분된 여러 마이크로서비스의 집합으로 구성된다. 이 때문에 하나의 큰 모놀리식한 어플리케이션보다 빠르게 배포되며, 한 기능의 장애가 모든 서비스의 장애로 이어지지 않는 등 다양한 장점이 있다.

단점 또한 있습니다..!

왜 필요할까?

여러 서비스가 아무 연관없이 존재한다고 생각해보자.

서비스 A의 기능은 ○○○ IP, ○○ 포트 서비스 B의 기능은 ◇◇◇ IP, ◇◇ 포트로 요청하면 돼

이제 요청하는 누군가가 정해진대로 요청만 하면 된다!

현실은 이렇게 간단하지 않다. 서비스가 A, B 두개뿐이라면 가능하겠지만 마이크로서비스가 늘어날 수록 관리가 매우 복잡해진다.

특히, scale-out이 빈번하게 발생하여 고정된 IP를 사용하지 못하는 클라우드 환경에선 절대 사용하지 못할 방법이다.

이러한 문제를 해결하기 위해 API 게이트웨이가 필요하다.

API 게이트웨이란?

간단하게 표현하자면, 모든 요청을 받아 각 서비스로 중개해주는 중개자이다. API 게이트웨이가 존재한다면 더이상 모든 서비스의 IP와 포트 번호를 알 필요 없으며 단순히 API 게이트웨이를 통해 요청하면 된다.

API 게이트웨이는 다음과 같은 기능을 제공한다.

중앙집중식 진입점

여러 마이크로서비스를 사용하는 경우, 클라이언트가 각각의 서비스에 직접 접근하는 것은 복잡하다. API 게이트웨이는 단일 진입점을 제공하여 이러한 복잡성을 줄인다.

로드 밸런싱

트래픽을 여러 서비스 인스턴스에 고르게 분배하여 시스템의 안정성을 높인다.

인증 및 인가

중앙에서 인증과 인가를 처리할 수 있다. 각 마이크로서비스는 인증과 인가에서 보다 자유로워질 수 있다.

서비스 통합

다양한 서비스 간의 통합을 쉽게 할 수 있으며, 서비스 디스커버리와 연동하여 동적으로 라우팅할 수 있다.

구현 방법

필자는 API 게이트웨이를 구현하기 위해 Spring cloud netflix eureka 와 Spring cloud reactive gateway 를 사용했다.

두 기술을 선택한 이유는 다음과 같다.

1. 정보가 많았다. 모든 스프링을 이용한 게이트웨이 예제는 두 기술을 이용한 예제라고 봐도 될 정도로 많은 비중을 차지했다.

2. reactive gateway를 선택한 이유는 Tomcat이 아닌 netty를 사용하며, 비동기 통신을 지원한다는 것이다.

   Spring mvc가 기본적으로 사용하는 Tomcat은 1개의 요청당 1개의 스레드가 할당된다. 앞단에서 많은 요청을 각 서비스로 릴레이하는 API 게이트웨이 특성상 보다 높은 성능이 필요할 것 같았고, 이에 비동기 방식의 netty를 사용하는 reactive gateway를 사용했다.

구현은 잘 설명된 블로그들이 많았다.

Spring Cloud Netflix Eureka & Spring Cloud Gateway [Spring Cloud] Eureka 개념 및 예제

위 두 블로그를 참고해 프로젝트에 적용했다.

gateway를 구현하는 방법은 크게 2가지로 구분되었다. 자바 코드로 작성하는 방법과 application.yml 등의 설정 파일로 작성하는 방법이다.

1. 자바 코드로 작성

• Type Safety 컴파일 타임에 타입 검사를 받을 수 있어 오타 등 오류를 사전에 찾아낼 수 있다.

• 유연성 조건부 로직, 동적 라우팅 등 복잡한 라우팅 로직을 구현하기 편하다.

2. 설정 파일 작성

• 간편함 설정 파일만으로 간단하고 직관적으로 gateway를 구성할 수 있다.

• 설정 변경에 강함 코드를 변경하지 않고 설정을 변경할 수 있다. 즉, 게이트웨이 설정이 변경되어도 다시 빌드 할 필요가 없다.

적용

이 중 설정 파일을 통해 구현하는 방법을 선택했다. 이유는 다음과 같다.

1. 복잡한 라우팅 로직이 필요 없는 수준이다.
2. 설정 변경 시 재빌드 할 필요가 없다.

마치면서

진행한 프로젝트는 이곳에서 볼 수 있습니다.

참고자료

Spring Cloud Netflix Eureka & Spring Cloud Gateway [Spring Cloud] Eureka 개념 및 예제