2024 스프링 캠프 다녀온 후기

지난 5월 25일 토요일 2024 스프링 캠프에 다녀왔다. 인프런에서 참여자를 모집했는데 1분만에 마감될 정도로 치열했다. 치열했지만.. 나는 성공해서 다녀오고 이렇게 후기까지 작성하고 있다😁

 

올해 1월에 개발자 컨퍼런스를 다녀온 이후로 두 번째 컨퍼런스이다. 같이 듣는 데브코스 사람들과 근처에서 간단하게 점심을 먹고 컨퍼런스장으로 향했다. 들어서자마자 등록을 한 뒤 키트를 나눠주셨는데, 손 선풍기, 키캡, 리무버 스티커였다. 부모님이 손 선풍기를 사용해보시더니 바람이 세다고 좋아하셨다.

2024 스프링 캠프

 

컨퍼런스에서 들은 세션은 총 다섯 개로 동시성의 미래 - 코루틴의 버츄얼 스레드, Spring AI : LLM에도 봄이 찾아오다, 왜 나는 테스트를 작성하기 싫을까?, 실전! MSA 개발 가이드, AutoParams를 사용한 Spring Boot 응용 프로그램 테스트이다. 

 

동시성의 미래 - 코루틴의 버츄얼 스레드

전통적인 웹은 Thread Per Request 방식으로 동작한다. 즉, Spring Web MVC는 요청 처리를 위해 하나의 스레드를 사용하는 방식이다.  JVM이 운영 체제의 기능을 활용하여 생성하는 플랫폼 스레드와 커널 스레드가 1 : 1 매핑되어 무한히 스레드를 늘릴 수 없다. 플랫폼 스레드의 수는 시스템의 리소스의 의해 제한됙 때문이다. 그래서 비동기이며 논블러킹 I/O 방식의 리엑티브 프로그래밍이 등장했다. Spring Webflux가 리엑티브 프로그래밍을 지원한다. 하지만 러닝커브가 높다는 단점이 있다.

 

이제 많은 회사가 자바보다 코틀린을 많이 사용한다고 들었다. 코틀린은 코틀린에서 비동기 프로그램을 손쉽게 사용할 수 있는 확장 라이브러리인 코틀린 코루틴을 지원한다. 경량 스레드인 코루틴은 적은 리소스로 대규모 동시성 작업을 효율적으로 지원한다.

 

최근 발표된 자바 21에서 버츄얼 스레드가 크게 주목받았다. 버츄얼 스레드는 경량 스레드로 JVM 위에서 생성 및 실행된다. 버츄얼 스레드는 캐리어 스레드 위에서 관리 및 실행되며 1 : N 관계이다.

 

발표는 코틀린 코루틴과 버츄얼 스레드의 개념을 넘어 코루틴과 버츄얼 스레드의 통합으로 이어졌다. 이름만 들어봤을 뿐 정확히 무엇인지 몰라 개인적으로 내용이 어려웠다😅 이 글을 쓰면서도 내가 적어둔 필기만으로 이해가 어려워 자료를 더 찾아봤다. 하지만 차후 대규모 트래픽을 처리에서 성능을 높이기 위해 고려할 기술이라고 생각했다.

 

Spring AI : LLM에도 봄이 찾아오다

트랙 1 컨퍼런스장

 

최근 뉴스에서 엔디비아의 1분기 영업이익이 엄청나게 증가했다는 뉴스를 보았다. OpenAI의 ChatGPT 성공으로 AI 열풍이 대단함을 알 수 있었다. 이번 세션은 ChatGPT처럼 생성형(generation) AI를 소개하는 것으로 발표가 시작되었다. 그리고 생성형 AI의 9가지 주요 컨셉 중 모델, 프롬프트, 프롬프트 엔지니어링, tokenizer, 임베딩에 대한 간략한 설명이 이어졌다.

 

 Spring AI는 생성형 AI를 발전시키는 LLM을 스프링에 통합하기 위해 추상화한 것이다. 들으면서 나같은 취준생이 고려할 기술은 아니라고 생각했다. AI 서비스를 운영하는 입장에서 모델을 트래이닝 시켜야할 때 고려할 기술이었다. 그리고 발표를 들어보니 아직 1.0.0 버전이 출시되지 않아 불안정한 상태라고 생각했다.

 

왜 나는 테스트를 작성하기 싫을까? & AutoParams를 사용한 Spring Boot 응용 프로그램 테스트

두 세션은 각각 Fixture Monkey와 AutoParams 두 라이브러리에 대한 발표였다. 두 라이브러리 모두 테스트 객체를 생성해주는 라이브러리이다. Fixture Monkey의 개발자는 테스트 작성과 유지보수 비용이 너무 커서 이 비용을 줄이기 위해 Fixture Monkey를 개발하게 되었다고 말씀해주셨다. 

 

앞 세션은 테스트 비용을 줄이기 위해 두 가지 지침을 소개했다.

1. 테스트를 복잡하게 작성하지 않아야 한다(given). 예를 들어, 필요하지 않음에도 리스트에 2개 이상 요소를 추가하는 것은 불필요한 비용이다.
2. 테스트에서 많은 검증을 하지 않는다(when). 

두 라이브러리는 테스트에 대해 많은 고민이 생겼을 때 도입해보면 좋은 기술이라고 생각했다.

 

실전! MSA 개발 가이드

실전! MSA 개발 가이드 세션의 전체 내용

가장 인기가 많았던 세션으로 마이크로서비스 아키텍처 구축 가이드를 발표했다. 마이크로 서비스는 데이터베이스를 각각 가지고 있다. 따라서 다른 서비스의 데이터가 필요하다면 API를 통해 조회해야 한다. 이때 API로 데이터를 많이 조회하거나 조합할 때 성능이 느려진다. 

 

이어 성능을 높이는 다양한 방법을 말씀해주셨다. 

1. n + 1 문제가 발생하지 않도록 일괄 조회한다(SELECT IN).
2. 병렬 조회는 순간적으로 서비스에 큰 부하가 가므로 DDos 공격과 동일하다.

 

데이터는 자주 참조되는지 혹은 자주 변경되는지에 따라 구분할 수 있다. 자주 참조되지만 자주 변경되지 않는 데이터를 매번 읽는 것은 낭비이다. 따라서 이런 데이터는 복제하거나 모델링 변경, 캐싱을 고려해야 한다. 만약 캐시로 로컬 캐시를 사용할 때 동기화는 안티패턴이다. Java Heap에 올라가므로 메모리 부족 현상이 나타날 수 있다. 결과적으로 MSA에서 API 조회 시 일괄 조회와 캐시를 통해 퍼포먼스를 올릴 수 있다.

 

마이크로서비스에서 트랜잭션을 보장할 수 없어 정확성을 맞추기 어렵다. 즉, 트랜잭션 특징 중 원자성(db rollback)과 독립성(read commited)이 보장되지 않는다.

 

먼저 원자성을 보장하기 위한 방법으로 첫 번째, 이벤트를 재시도가 있다. 이벤트는 무조건 전달된다. 실패하더라도 결국에 안전하게 전달되며 간혹 타임아웃 혹은 서킷 브레이커 때문에 여러 번 전달될 때 있다. 두 번째, 긴 트랜잭션을 나눈다. 실패해도 전체를 취소하지 않는 경우, 취소할 수 없는 쓰기일 경우 이벤트로 분리한다. 그 외에 모델링을 변경하거나 서비스 경계(바운디드 컨텍스트)의 경계를 변경하여 원자성을 보장할 수 있다.

 

마지막으로 독립성을 보완하기 위한 방법은 Application Lock만 사용하는 것이다. 데이터베이스의 동기화 매커니즘을 사용할 수 없으므로 Application Lock을 사용한다. 

 

마무리로 MSA에 국한된 기술이 아니고 이종 기기에서 사용될 수 있는 기술이라고 말씀하셨다. 소개해주신 기술에서 실제 시스템에서 마주한 문제를 해결할 수 있는 적절한 기술을 찾아봐야겠다.

 

맺음

최신 개발 동향과 프로젝트에 적용해볼만한 기술에 대한 지식을 얻을 수 있는 좋은 시간이었다🌱. 주말에도 많은 사람들이 컨퍼런스에 참여한 것을 보고 역시 안보이는 곳에서 많은 사람들이 치열하게 살고 있음을 느꼈다. 지식도 얻고 자극도 받고 일석이조인 하루였다.