Official-Dev. blog

다들 2024년 회고를 하나씩 블로그에 포스팅하기에 더 늦기 전에 올려야겠다라는 생각이 들어 작성하게 되었다.2024년은 가장 정신없게 보낸 한 해였다.1. 블로그 작성에 소홀해진 이유주변에서 블로그 작성에 너무 소홀해진 것 아니냐는 얘기를 종종 듣는다.사정을 이야기하자면 아래와 같다.업무가 너무 많고 바빠졌다.여가 시간이 많이 줄어들었다.회사에서 보통 근무했던 시간은 08:00 ~ 19:00 이다. 근무 시간도 그렇고, 근무 일수도 4.5일에서 늘어났다. 디테일하게 다른 이유도 있다.업무가 많은 편이고, 근무 시간도 많음B2C 서비스를 하고 있고, 외부 제휴사가 많은 부서라서 주말에도 장애에 민감실적 압박이 있는 편이고, 업무 관리가 굉장히 타이트한 편근무 시간이 많은 이유는 정말로 일이 많았다. 근무..

코루틴에서 트랜잭션을 적용하는 데 어려움을 겪는 케이스가 많다.코루틴 + JPA 환경에서 @Transactional 애노테이션이 미동작했고, 해당 부분으로 인해 알게된 내용을 공유한다.Spring I/O 2024에서 언급하는 내용도 참고했다.스프링 - 트랜잭션 관리 방식스프링에서 지원하는 트랜잭션 방식에 따라 크게 2가지로 방식이 있다.선언적 트랜잭션프로그래밍적 트랜잭션선언적 트랜잭션(Declarative Transaction)이란 @Transactional과 같은 애노테이션을 기반으로 트랜잭션을 처리하는 방식을 말한다.프로그래밍적 트랜잭션은(Programmatic Transaction)은 실제 로직에서 트랜잭션을 수행하는 방식을 말한다.선언적 트랜잭션 vs 프로그래밍 트랜잭션공식문서를 보면 아래와 같이..

Spring I/O 2024에서 DDD(Domain Driven Design) 관련된 강연을 했다.Implementing Domain Driven Design with Spring by Maciej Walkowiak @ Spring I/O 2024해당 강연은 DDD의 기본부터 Spring을 활용한 구현 방법을 설명한다. 아래는 해당 강연 내용을 해석한 내용이다.DDD마틴파울러는 DDD를 아래와 같이 설명한다.DDD(Domain-Driven-Design) is an approach to software development that centers the development on programming a domain model that has a rich understanding of the process..

서비스를 운영하다보면 Redis, MySQL, Mongo, ElasticSearch 등 다양한 DB를 사용해야 할 일이 생긴다.MySQL을 위한 MySQL-Workbench, MongoDB를 위한 MongoDB-Compass 등 다양한 도구를 익히면 중간에 컨텍스트 스위칭이 안되는 경험을 많이 했다.JetBrains DataGrip을 사용하면 대부분 종류의 DB를 동일한 도구에서 관리할 수 있어서 많이 사용한다.Redis 지원DataGrip 2022.3 이상 버전부터는 Redis 조회도 지원한다.해당 기능을 사용하면 아래와 같이 Redis 데이터도 편리하게 조회하거나 명령어를 수행할 수 있다.아래와 같이 코드 자동완성 기능도 있어서 Command를 사용할 때보다 확실히 편리한 것 같다.도구에 너무 익숙해..

파티션을 사용할 때 고려할 부분합류한 새로운 팀에서는 파티셔닝을 적극적으로 사용하고 있었다.Partitioning(파티셔닝)은 논리적으로 하나의 테이블이지만, 물리적으로는 여러 개의 파일 시스템에 분산하는 방법이다.파티셔닝은 테이블과 인덱스 모두 적용된다. 파티셔닝을 사용하는 이유는 다음과 같다.더 많은 데이터를 하나의 테이블에 저장할 수 있다.유용성을 잃은 데이터에 대해 특정 파티션을 제거하는 등 관리가 가능하다.검색에 대한 DB 부하를 감소하는 기능이다. (WHERE 절로 필요하지 않은 파티션은 자동으로 제외)아래 공식 문서를 기반으로 파티셔닝을 사용할 때 고려해야할 부분에 대해 알아보자.1. 인덱스(Index)파티셔닝을 사용할 때 고려해야 할 것이 있다. 바로 Index이다.파티셔닝을 사용할 때 인..

서비스의 모니터링이 점점 어려워지는 문제가 발생하고 있었다. 가장 큰 문제는 불필요한 에러 Alert이 너무 많다는 것이다.그 결과 신경이 더 많이 사용되고 정말 받아야 하는 Alert이 왔을 때 놓치거나 무신경하게 대응할 수 있게 된다.서비스의 중요도나 위험도, 트래픽 등을 고려했을 때 모니터링 개선이 반드시 필요해서 시간내서 학습하고 적용하게 되었다.SentrySentry는 에러 모니터링 및 성능 모니터링을 제공해주는 도구이다. 주로 에러 트래킹이나 Slack 등을 통한 Alert으로 많이 사용한다.예시를 위해 SpringBoot 3.1.9 버전과 아래 라이브러리를 사용했다.implementation 'io.sentry:sentry-spring-boot-starter-jakarta:7.5.0'yml은..

해당 포스팅에서는 테스트 시 Web 영역을 어떻게 Mocking 할 지에 대해 다룬다.통합테스트요즘은 단위 테스트를 넘어서 통합테스트 / 인수테스트 / E2E테스트를 많이 구성한다.외부 API를 호출하는 코드가 있다. 해당 로직을 Mocking할 때 어떻게 할 지 생각해보자.주문 시스템 (예시 코드)예시를 위해 제작한 주문 시스템의 코드를 보자.아래는 첫 주문 기능의 진입점인 주문 컨트롤러이다.@RestControllerclass OrderController( private val orderService: OrderService,) { @PostMapping("/order") fun order( @RequestBody orderRequest: OrderRequest, )..

runBlocking {} 제거해야 할까코틀린과 코루틴을 처음 접하는 경우가 많을 것이다.코틀린이 익숙하지 않은 프로젝트를 보면 대부분 Controller 메서드의 시작이 runBlocking()이 되어있고, 사실상 코루틴은 runBlocking(), runCatching() 밖에 존재하지 않는 경우가 있다.내가 투입된 프로젝트의 코드도 동일한 상황이었고 그랬고, '코루틴을 사용할 때의 이점을 하나도 못누리고 있는 것은 아닐까..?' 하는 의심을 가지게 되었다.runBlocking은 왜 문제이며, 어떻게 개선할 수 있는 지 알아보자.runBlocking아래는 runBlocking에 대한 docs의 일부이다.Runs a new coroutine and blocks the current thread inte..

Spring CloudSpring Cloud는 안정적인 Micro Service Architecture를 만들고 외부 환경에 대해 신경을 할애하지 않고 내부 로직에만 집중할 수 있게 도와주는 라이브러리이다.Spring Cloud에서 지원하는 기능 중 Curcuit breaker에 대해 다룬다.Circuit breakerCircuit breaker는 전기 회로의 차단기와 같은 역할을 하는 디자인 패턴을 말한다. 즉, CurcuitBreaker는 기술이 아닌 패턴을 말한다. 주요 목적은 다음과 같다.외부의 장애를 격리하고 시스템 안정성을 유지할 수 있다.장애 복구 시간을 확보할 수 있다.특정 서비스의 과부하나 장애가 발생했을 때 복구가 될 때까지 추가적인 요청을 차단해서 시스템의 안정성을 유지한다.그래서 R..

최근에 이직을 하고 업무를 하면서 가장 큰 고민이 있다. 코드 리뷰할 때 특히 고민되는 부분이다.개발을 하면서 아래의 선택 중 어떤 것을 선택할 지에 대한 문제이다.우선 기능이 돌아가게만 만들어서 빠르게 오픈하고 점진적으로 개선한다.초기에 프로젝트 설계나 테스트 코드 등에 자원을 할당한다.현재까지의 나의 업무로 보면은 2번을 선택해왔다.철저한 테스트와 코드 아키텍처가 추후 유지보수 작업 공수를 줄이고, 견고하고 유연한 서비스가 회사와 서비스에 대한 이미지나 사용자 경험을 증대시킨다고 생각했기 때문이다.요즘 핫하다는 회사나 일을 잘한다는 팀은 1번을 선호하는 것 같기도 하다. 실제로 충분히 합리적이라고 생각한다.사업 vs 서비스사업 담당자의 추구기능 추가기능 변경할인, 프로모션 등서비스 운영자의 추구리팩토..