JangBaGeum.gif

최신 팀 내에서 EDA(Event Driven Architecture) 바람이 불면서 인프라 개선을 위한 마이그레이션 작업 중 이벤트 브로커로 Kafka를 도입하게 되었다. Kafka를 중앙에 두고 양측의 이벤트 발행자와 소비자의 관계는 느슨해졌으나, 데이터 인터페이스 정의와 공유에 있어 불필요한 커뮤니케이션과 관리의 모호함을 많이 느끼게 되었다. 그러하여 EDA 진영에서 마이크로 서비스 간의 스키마 정의와 관리를 도와주는 Schema Registry에 대해 알아보고 간단한 소개를 적어보려고 한다.  # Schema Registry? kafka는 이벤트를 발행하는 producer와 소비하는 consumer 사이의 직접적인 관계를 끊음으로써 구조적인 결합도를 낮추는 장점이 있다. 하지만 구조적 결합도가 낮..

여러 컨테이너를 구동 시 동일한 환경 변수를 이용할 때, 혹은 한 컨테이너에 대해 상황에 따라 다른 환경 변수를 동적으로 주입해 줘야 할 때 docker-compose에서는 환경 변수를 주입해 줄 수 있도록 여러 방법을 지원한다. 나의 경우 동일한 내용의 컨테이너를 병렬 적으로 여러 개 구동하나 동일한 환경 변수를 사용하기에 하나의 파일로 환경 변수를 사용하기 위해 알아보았다. 우선 환경 변수를 주입하는 방법을 간단하게 알아보자. docker compose를 사용하여 환경 변수 설정 방법크게는 docker-compose 파일을 이용하는 방법과 CLI를 사용하는 방법이 있다.파일로 작성.env 파일 작성키-값 쌍의 여러 환경 변수를 한 번에 주입하기 용이하다. 작성된 .env 파일은 프로젝트 폴더의 루트 ..

새로운 프로젝트를 시작하면서 구현만을 하던 API서비스를 직접 설계하게 되는 기회가 생겼다. 지속적으로 유지 관리가 되어야 하며 확장의 계획이 있는 프로젝트이기에 확실한 기반과 구조를 가져가야 했고, 이번 기회에 API설계에 대한 패턴을 탐색해 보았다. API 설계 패턴은 빠른 확장을 가능하게 하고 설계 및 구동에 있어 일반적인 문제를 해결하는데 청사진이 될 수 있다. 하기 내용에는 API 디자인 패턴의 사용 이점과 일반적인 패턴, 구현 모범 사례를 함께 다루어 보려고 한다. API 디자인 패턴을 사용하면 좋은 점 디자인 패턴을 사용하는 원초적인 이유는 협업의 용이성과 안정적인 서비스 운용 등 다양하게 있다. 이에 따라서 API 디자인 패턴을 사용하면 함께 협업하는 개발자와 API를 더 쉽게 이해하고 확..

DTO Data Transfer Object)는 애플리케이션 간에 테이터의 전달을 목적으로 하는 객체이다. 이는 프레젠테이션 계층과 비즈니스 계층, 혹은 비즈니스 계층과 데이터 액세스 계층, 더 나아가 애플리케이션 간에서 비즈니스 로직을 갖지 않고 순수하게 데이터 전송을 위해 사용된다.  클라이언트와 서버의 관계를 갖는 서비스를 설계/구축해 봤으면 누구나 DTO에 대한 개념을 알 것이다. 그러나 순수한 DTO의 의미와 의도를 정확히 파악하고 구현하는 것은 어려움이 있을 것이라 생각된다.  최근 서비스를 구현하면서 DTO/VO/Entity 등 데이터를 다루는 기본적인 객체에 대해 고민을 해보면서, 더 정확히 알고 쓰면 깔끔하면서 명확한 코드 작성이 가능할 것 같아 몇 가지 알아본 내용을 정리해보려고 한다...

현재 업무는 함수형 프로그래밍을 지향하다 보니 함수들만 주야장천 찍어냈습니다. 그러던 중 오랜만에 필요에 의해 클래스를 작성하게 되었고 싱글톤 패턴을 적용을 해보는 기회가 되었습니다. 이론으로만 보던 싱글톤 패턴을 보니 반갑기도 하고 해서 간단히 서칭 한 내용을 정리해보려고 합니다. 싱글톤 패턴 singleton pattern이란? 애플리케이션에서 하나의 인스턴스만을 생성하고, 이를 전역적으로 사용하는 디자인 패턴 싱글톤 패턴은 객체지향 디자인 패턴 중 하나로, 어떤 클래스의 인스턴스가 오직 하나만 만들어져야 하는 상황에서 사용됩니다. 이 패턴을 사용하면 인스턴스를 여러 개 만들어서 발생할 수 있는 문제를 방지할 수 있습니다. 인스턴스를 여러 개 만들면 발생할 수 있는 문제 인스턴스를 여러 개 만들어서 ..

회사 내의 코드베이스를 검토하다 보면 과도하게 분산되어 있는? 성향이 조금 있는 것 같아(사실은 그냥 정리가 안된 거일 수도,,,) 과연 옳은 방법으로 코드들이 관리되는 것인가 고민을 한 적이 있습니다. 회사 내 서비스 특성상 하나의 서비스지만 버전이 여러 개로 나뉠 수밖에 없는 구조이지만 분명 하나로 통일 할 수 있는 방법이 있을 것이고 각자 관리됨에 있어 항상 컨벤션 검토를 거쳐야 되는 번거로움도 해결이 가능할 것이라고 생각했습니다. 예전부터 MSA(Microservices Architecture)가 인기이면서 회사 내에서도 지향하는 듯한 느낌이긴 한데, 과도하게 늘어나는 관리 포인트와 가지각색의 컨벤션은 가장 먼저 해결해야 되지 않을까 싶습니다. 찾아보니 꼭 분산만 지향하는 쪽으로 개발 방법론만 있..