반응형

전체 글 83

Clean Code in Reactive

개요 Reactive 모델은 익숙한 기존 Thread 모델보다 가독성이 떨어지는 이슈가 있다. 이러한 문제는 Reactive의 한계가 아닌, 코드를 작성할 때 가독성을 고려하지 않고 작성하면 발생한다. 이번 리뷰는 가독성 좋은 Reactive 코드를 위한 개념들에 대해 정리한다. 1. 비즈니스 로직은 Operator가 기준이 된다. userService.getFavorites(userId) .map(Favorite::toRequestModel) .flatMap(favoriteService::getDetails) Reactive 모델은 Data Flow가 곧 비즈니스이다. Data Flow는 결국 비즈니스의 “행위”가 되며, 행위는 operator의 묶음으로 표현하게 된다. 이는 결국 추후 Reactive..

개발 일지 2024.01.25

GraphQL Overview

GraphQL 이란 META에서 개발한 Query Language over HTTP. SQL이 Application → DB로 데이터를 쿼리하는 언어라면, GraphQL은 Application → Server로 데이터를 쿼리하는 언어 GraphQL is for… Client ↔︎ Server 간의 Data Provide Mismatch를 해결하기 위해 개발된 언어 No more Overfetching, Underfetching 데이터의 제공 주체는 서버이며, 서버는 다수의 client를 위한 서비스를 제공하기 때문에, 데이터에 기반하여, API를 제공한다. 이에 client는 필요한 Data 이외의 데이터를 함께 제공받거나(overfetching), 필요한 데이터를 모으기 위해 여러번 호출 (underf..

개발 일지 2024.01.15

Netflix OSS란 (feat. Service Mesh)

개요 1. Netflix OSS 및 Spring Cloud Netflic 구성 요소 소개 2. Spring with Netflix에서 제시한 MSA 구조 소개 3. 부록으로 MSA 서비스간의 통신을 infra로 풀어낸 side-car 패턴의 구성방안에 대해 소개 Service Mesh란? Service Mesh는 여러 서비스(MSA등)간의 의사소통을 책임지는 Layer를 말한다. Layer가 어떻게 구성되는지 장단점이 존재하며, 각 솔루션들이 존재한다. 방식 솔루션 설명 PaaS Azure fabric, lagom… 플랫폼 서비스로 mesh구조를 풀어낸 방안 개발자는 Mesh 구성 및 동작에 대해서 신경 쓰지 않는다. Framework 형태로 제공되며, 특화된 코드를 필요로 합니다. Side car Pr..

개발 일지 2024.01.05

Spring Properties from Lib Resources (PropertySourcesPlaceholderConfigurer, EnvironmentPostProcessor)

개요 Spring 프로젝트의 Properties를 구성하는 방법은 여러 가지가 있다. 그중 프로젝트 외부(external jar)의 resources에서 Load 하여 추가하는 방법에 대해 정리하고자 한다. 문제 상황 1. Github Project를 public으로 설정하면 일부 정보들은 노출되지 않도록 관리해야 한다. ex) db password.. etc 2. Multi Project 구조 같이 공통적으로 적용되어야 하는 Properties를 따로 관리해야 할 때 ex) Actuator 설정, 접속정보 등 Properties file을 Runtime에 외부에서 Load 하게 되면 위 문제상황을 해결할 수 있다. 일반적으로는 Server에 관리되는 Properties 파일을 두고 runtime 시점에..

AnnotationProcessor를 통한 project 내 ServerInfo Enum 생성

개요 중복되는 코드를 줄이기 위해 개인 서버 프로젝트를 gradle을 활용한 subproject 구조로 잡았었다. 새로 생성되는 subproject에서 중복 로직들을 모은 LIB project를 implementation 하여, 중복을 줄이고자 시도 중이다. 문제는, 프로젝트가 추가될 때마다 LIB project의 코드를 추가해 주는 방식은, 목표했던 편의성과는 거리가 있다. 이에 프로젝트 전체를 지속적으로 모니터링하여, 자동으로 최신화하는 방법을 모색했다. 목표는 수동으로 코드의 추가 없이, 신규 프로젝트의 설정 및 properties 등을 스크랩하여 추가할 수 있는 방안을 마련하는 것이다. AnnotationProcessor란 JAVA 5에서 신규 도입된 개념으로 Compile 시점에 JAVA의 소..

Gradle Docker build (feat. Jenkins CI/CD)

개요 Jenkins에 CI / CD를 구성하는 작업은 신규 프로젝트 생성시마다 해줘야하는 귀찮은 작업 중 하나다. 또한 개발 / 배포 환경 상 자주 바뀌는 부분도 없고, 대부분 비슷하게 동작한다. 이러한 공통부분을 묶어서, 하나의 CI / CD로 모든 project (gradle subproject)를 빌드 배포할 수 있도록 구성하려 한다. Gradle docker build 'com.bmuschko.docker-spring-boot-application'는 docker build를 지원하는 gradle plugin이다. 이를 활용하여, gradle의 task를 통해 docker image 생성까지 구성하고자 한다. docker image 생성을 gradle에서 하는 이유? 기본적으로 docker ima..

Multi-project 구조 설계 (Gradle)

개요 지난 시즌 개발 중 신규 프로젝트 시작할 때 큰 귀찮음이 있었다. 1. 프로젝트마다 중복되는 코드: log 설정, db설정, kafka 설정, 등등.. 2. 프로젝트마다 중복되는 작업: github, jenkins CI/CD, docker config 등등.. 이런 귀찮음은 결국 신규 프로젝트를 시작할 때 부담으로 작용하게 되었고 간단한 아이디어를 테스트 하기에 좋지 못했다. 이번 시즌에는 이러한 부분을 사전에 방지하고자 한다. 이 글은 Gradle의 Multi-Project 구조를 통해 이러한 문제상황을 해결해보려 한다. Multi-Project 구조 설계 Gradle은 Multi-Project 구조를 지원한다. 이번 프로젝트는 2-depth 이상으로 구성하려 한다. Root project 'pb..

Jenkins Docker Builder 연동 이슈 (connection refused)

개요 Jenkins는 CI / CD를 구성할 수 있는 강력한 툴이다. Docker는 환경을 포함해서 Application을 이미지화 할 수 있는 툴이며 Jenkins를 통해 docker로 배포하는 방법은 많이 활용되는 조합이다. 문제 발생 기존 배포 방식 일반적인 배포방식으로는 1. Jenkins에서 build 및 docker image 생성 2. docker image를 DockerHub로 업로드 3. 배포 받을 서버에 dockerHub에서 특정 이미지를 받아서 실행하도록 command 이 있다. 배포 방식 단순화 2023 개인서버에는 위 로직을 통해 배포를 진행했었다. 넥스트 계획의 핵심은, 중복되는 작업들을 최대한 자동화 시키고 요구사항에서 벗어나는 확장성을 줄이고자한다. 이에, 서버 한곳에서 빌드..

개발 일지 2023.12.20

Micrometer Log Tracing (feat. Spring Boot 3)

Micrometer란 Vendor-neutral application observability facade micrometer는 observability의 파사드(고수준 인터페이스)를 제공해주는 프로젝트이다. observability는 Application의 가시성을 제공해주는 것을 말하며, 이는 Application 내에서 발생하는 process를 외부로 제공해주는 것 이다. JVM -based Application라면 ventdor에 상관없이 적용할 수 있다. Project Develop History 2016 [Spring] Create tracing library(Spring Cloud Sleuth) from Spring Cloud team 2017 [Micrometer] Micrometer Pr..

개발 일지 2023.12.14

시즌2 기획

개요 연말을 준비하면서 개인 서버의 서비스들을 정리해보고자 한다. 한 동안 바쁜 일정도 있었지만, 최근 서비스 개발이 없었던 이유 중 가장 큰 것은 모노리틱 구조로 설계한 서버도 한몫을 하고 있다. 이전에 MSA 식으로 개발해 봤던 부분과, 올해 모노리틱으로 설계한 부분의 장단점을 분석하고 다음 시즌에는 보다 길고 탄탄한 서비스를 만드는 방향으로 기획하려 한다. 모노리틱 서비스 구조 문제 모노리틱 서비스를 개발할 때 발생하는 문제점에 대한 고찰 너무 많아지는 의존성 예를 들면, 한 프로젝트 내에서 여러 DataSource를 관리해야 되는 문제가 발생했다. 여러 서비스의 성격이 다르고, 적합한 DataSource가 다르다 보니, 서버에 지속적으로 Data Access Point가 늘어나게 되었다. 현시점 ..

반응형