개발하는 북극곰

개요 이전에 토스 및 네이버(라인?) 아티클에서 API Gateway를 통해서 MSA 구조에서 API로 접근하는 인증 / 인가를 수행하고 있음을 읽었었다. 이는 각 API 서버에서 필요한 기능을 한 곳에서 수행하여 생산성을 높여 효율화를 한 작업으로 감탄했었다. 현 개인서버의 요구사항으로는 최대한 중복 개발을 줄여 생산성을 극대화하며, 귀찮음을 덜고자하는 것이 부합한다. 위 방식을 응용하여 전체적인 아키텍쳐를 설계하고자 한다. 서버 아키텍쳐 설계 현 개인서버의 전체적인 아키텍쳐이다. - Nginx에서 SSL을 수행하고 reverse proxy를 통해 내부 통신을 연결한다. - Gateway Server는 Nginx로 부터 모든 요청을 받아서 L7 switching의 역할을 할 생각이다. 기본적으로 Gat..

개요 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 시점에..

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

개요 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..

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

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