Official-Dev. blog

이전에 Java Spring에서 샤딩을 처리하지 못하던 이슈를 해결한 경험이 있다. 해결 과정: https://jaehoney.tistory.com/180 그때 당시는 해당 기술이 샤딩(Sharding)인지도 몰랐다. 참고로 당시 0년차였다.. 추가로 당시는 대단한 일을 한 것처럼 느껴졌지만 지금은 샤딩을 처리하는 다양한 기술들을 알게 되었다. Naver D2, 우아한형제들 기술블로그, 카카오 뱅크 발표, 요기요 기술 블로그, ... 그래서 이전에 구현한 코드를 어떻게 개선할 수 있을 지 생각해보기 위해 포스팅을 하게 되었다. 샤딩을 처리하는 방법 DB 서버 1대로 트래픽이나 저장량이 감당이 안될 때, Local cache나 Global cache를 동원하기도 한다. 그리고 Master-slave 패턴을..

최근에 Spring-Kafka에서 기여하고, 사내에서 라이브러리를 많이 만들면서 공통 라이브러리에 대해 관심이 많아졌고, Spring-boot에 대해서 이해도가 많이 부족하다고 느꼈다. 해당 포스팅에서는 SpringBoot의 동작 원리에 대해 간략히 다룬다. 기존 방식 vs 스프링 부트 웹 애플리케이션을 개발하고 배포하려면 WAR 방식으로 배포를 했어야 했다. 톰캣을 별도로 설치하고 설정을 구성해야 한다. 애플리케이션 코드를 WAR로 빌드해야 한다. 빌드한 WAR 파일을 WAS에 배포해야 한다. 이러한 방식은 아래의 단점이 있었다. WAS를 별도로 설치해야 함 개발 환경이 복잡 배포 과정도 복잡 톰캣의 버전을 변경하려면 톰캣을 다시 설치하고 서버를 다시 구성해야 함 그래서 Spring Mvc 방식 + 내..

개발 중에 EmbeddedKafka를 적용하니 일부 테스트가 깨지는 현상이 발생했다. 딱히 잘못한 부분도 없는 데 깨진 것 같아서 의아했다. 아래는 해당 부분에 대해 해결하고 Spring-kafka에 기여하게 된 내용에 대해 다룬다! 최초 확인 확인해보니까 @Nested 어노테이션이 달린 클래스의 테스트들만 깨지고 있었다. 왜 그럴까..? WireMock 서버가 이미 떠 있다는 경고로 깨지고 있었다. WireMock을 제거하니 MockMvc에서 에러가 나고 있었다. 복잡한 원인을 확인하려니까 어려워서 새로운 Repository에서 재현을 해보기로 했다. Repository: https://github.com/violetbeach/embedded-kafka-nested 1. WireMock 문제 아래는 실..

현재 고객 서비스를 위해 도메인 별로 시스템을 만들어서 MSA 환경을 구축하고 있다. 각 클라이언가 직접 마이크로 서비스를 호출하는 것에는 문제점이 있다. 클라이언트와 마이크로 서비스 간의 강한 결합 개별 마이크로 서비스에 대해 많은 통신이 필요하다. 엣지 기능을 각각의 마이크로 서비스가 직접 구현해야 한다. 보안 및 권한 처리 장애 처리 로깅, 모니터링 요청 개수 제한 캐싱 ... API Gateway 패턴을 사용하면 단일 접점을 활용해서 각각의 마이크로 서비스의 내부에 대해 알 필요가 없다. 즉, API 내부 동작에 대한 캡슐화가 이뤄지고 강한 결합이 끊어진다. 그리고 API Gateway가 공통된 기능을 제공하게 되어 각 마이크로 서비스의 책임이 가벼워진다. 단일 진입점을 제공 각 엣지 기능을 한 ..

멀티 모듈 프로젝트에서 외부 라이브러리를 사용할 때 고민이 있었다. A 프로젝트와 B 프로젝트와 C 프로젝트에서 모두 동일한 버전의 라이브러리를 사용해야 하는 상황 각 프로젝트의 build.gradle에서 라이브러리 의존성 버전을 일일이 동기화해줘야 한다. 이러한 문제를 잘 해결할 수 없을까..? dependency-management-plugin Gradle의 의존성 관리 플러그인(Dependency-management-plugin)을 사용하면 이를 해결할 수 있다. 의존성 관리 플러그인은 Maven과 같은 의속성의 관리 및 제외를 제공하는 Gradle Plugin이다. Gradle 6.8 이상 Java 8 버전 이상에서 지원된다. 사용하기 전에 DependencyManagement는 Gradle 플러..

Controller - Service - Repository 패턴 아래는 전통적인 계층형 아키텍처(Layered Architecture)이다. DTO 형태로 요청을 받고 Controller, Service, Repository 등이 메시지를 주고받을 때도 DTO를 사용한다. 그러면 되는 걸까?! 아키텍처 Layered Architecture 관점으로 봤을 때 Controller는 Service를 알아야 하는 것이 맞다. 그렇지만 호출되는 Service가 Controller를 알아야 할 필요는 없다. 각 계층은 단지 하위의 있는 계층을 사용하면 된다. Controller에서 DTO를 자신의 Needs로 사용한다면 Service가 DTO를 통해 간접적으로 웹 계층에 의존하게 된다. 개념적 의존이 역류하게 ..

최근에 우아한형제들에서 코드 리뷰를 객체지향 생활 체조 원칙를 기반으로 한다는 얘기를 처음 접했다. 객체지향 생활 체조 원칙에 대해 관심을 가지고 찾아봤고, 객체지향의 사실과 오해라는 책과 DDD 관련 책에서도 많이 언급하던 내용에 대한 가이드와 다른 좋은 개념도 많았다. 이번 포스팅에서는 객체지향 생활 체조 원칙에 대해서 작성한다. 객체지향 생활 체조 원칙 객체지향 생활 체조 원칙은 소트웍스 앤솔러지(ThoughtWorks Anthology) 라는 책에 나오는 원칙이다. 소트웍스 앤솔로지에서는 9가지 원칙을 준수하면서 객체지향을 추구할 수 있다고 한다. 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다. else 예약어를 쓰지 않는다. 모든 원시 값과 문자열을 포장한다. 일급 컬렉션을 쓴다. ..

최근 TDD에 큰 관심이 생겨서 요즘 핫하다는 ATDD에 대해서와 TDD에 대해 더 깊게 이해하려고 했다. 강연을 찾던 중 NEXTSTEP에 ATDD, 클린 코드 with Spring이라는 좋은 강의 코스가 있는데, 가격이 80만원이다... ㄷㄷ https://edu.nextstep.camp/c/R89PYi5H/ 사실 조금 부담스러워서 우아한 ATDD라는 우아한 테크 세미나 발표가 있다. 아래는 해당 발표 내용을 공부하며 정리한 것이다..! 사실 메모에 가깝다. 인수 테스트 인수 테스트는 시나리오(사용자 스토리) 기반으로 기능을 테스트하는 것이다. 이러한 인수 테스트는 아래의 장점이 있다. 배포 없이 빠른 피드백을 받을 수 있다. 도메인과 서비스 파악에 큰 도움이 된다. QA 절차 없이 테스트 코드만으로..

배달의 민족의 주문, 포인트, 정산 시스템에서 향로님께서 적용하면서 얻은 팁을 아래 강연에서 발표했다. https://www.youtube.com/watch?v=_nkJkWVH-mo Web vs Batch Web 실시간 처리를 위주로 한다. 상대적인 처리 속도를 가진다. QA가 용이하다. Batch 후속 처리를 위주로 한다. 절대적인 처리 속도가 측정된다. QA가 복잡하다. (DB나 자바 코드를 까봐야, 문제를 찾을 수 있기 때문) 철저한 테스트 코드가 반드시 필요하다. 배치 애플리케이션이 필요한 근거 아래의 경우에는 필수적으로 배치 애플리케이션이 필요할 수 있다. 일정 주기로 실행되어야 할 때 실시간 처리가 어려운 대량의 데이터를 처리할 때 배민에서는 매출의 경우 5억건 정도가 있고, 매출 상세의 경우..

해당 포스팅에서는 아래 강연의 내용을 참고해서 작성합니다. 참고: https://www.youtube.com/watch?v=v9rcKpUZw4o&t=928s 채널계와 계정계 왜 은행에서는 1개월, 3개월, 6개월 등 기간에 따른 입금+출금 내역을 조회할 수는 있지만, 무한 스크롤 UI를 제공하지 않을까? 일반적으로 은행 시스템은 아래 구조로 분리되어 있다. 계정계 - 실제로 유저의 돈을 다루며, 원본 데이터가 저장됨 (아주 높은 신뢰도 요구) 채널계 - 유저의 요청을 직접 받아 계정계로 전달 예로 토스 뱅크에서는 채널계는 여러개의 서버와 여러개의 DB로 분리되어 있다. 서버의 Scaleout이 용이하고, DB 부하가 커지면 DB를 분리하기 쉽다. 트랜잭션 처리가 불편하다. 반면 계정계의 경우 아주 높은 ..