![]()
이전글 [Kafka] 스키마 레지스트리 (Schema Registry)최신 팀 내에서 EDA(Event Driven Architecture) 바람이 불면서 인프라 개선을 위한 마이그레이션 작업 중 이벤트 브로커로 Kafka를 도입하게 되었다. Kafka를 중앙에 두고 양측의 이벤트 발행자와 소비자jangbageum.tistory.com 하나의 스키마는 여러 버전으로 관리가 가능하여 의존성이 있는 Producer와 Consumer에게는 스키마에 대한 호환성이 지켜줘야 되니다.이러한 점 때문에 스키마 레지스트리는 호환성 정책을 통해 스키마 버전 업데이트, 스키마 검증 등 스키마 변화에 대해서 대응이 가능하도록 되어있다. 호환성 관리스키마는 수정될 때마다 스키마 레지스트리에서는 새로운 ID를 발급한다.스키마가..
![]()
최신 팀 내에서 EDA(Event Driven Architecture) 바람이 불면서 인프라 개선을 위한 마이그레이션 작업 중 이벤트 브로커로 Kafka를 도입하게 되었다. Kafka를 중앙에 두고 양측의 이벤트 발행자와 소비자의 관계는 느슨해졌으나, 데이터 인터페이스 정의와 공유에 있어 불필요한 커뮤니케이션과 관리의 모호함을 많이 느끼게 되었다. 그러하여 EDA 진영에서 마이크로 서비스 간의 스키마 정의와 관리를 도와주는 Schema Registry에 대해 알아보고 간단한 소개를 적어보려고 한다. # Schema Registry? kafka는 이벤트를 발행하는 producer와 소비하는 consumer 사이의 직접적인 관계를 끊음으로써 구조적인 결합도를 낮추는 장점이 있다. 하지만 구조적 결합도가 낮..
![]()
진행 중 작업의 방향성이 수정되면서 이전 commit으로 돌아가야 되는 귀찮음이 생겼다.기존 작업물은 날려버리기 아까우니 잠시 다른 branch에 keep 하고 조금 멀리? 과거로 돌아가야 했다.과거 여행 중의 기록을 commit으로 남기기 위해서 revert를 열심히 이용하였고 이름 남겨두려고 한다.git revert 기본 사용법git revert 커멘드의 기본 시그니쳐는 아래와 같다.git revert [--[no-]edit] [-n] [-m ] [-s] [-S[]] …git revert (--continue | --skip | --abort | --quit) 위 시그니쳐를 바탕으로 아주 간단한 예시를 들어보자. 특정 commit 직전 상태로 돌아가기현재 HEAD의 바로 직전으로 돌아가기 위해서는 ..
![]()
여러 컨테이너를 구동 시 동일한 환경 변수를 이용할 때, 혹은 한 컨테이너에 대해 상황에 따라 다른 환경 변수를 동적으로 주입해 줘야 할 때 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 등 데이터를 다루는 기본적인 객체에 대해 고민을 해보면서, 더 정확히 알고 쓰면 깔끔하면서 명확한 코드 작성이 가능할 것 같아 몇 가지 알아본 내용을 정리해보려고 한다...
