Backend

얼마 전에 관리하는 애플리케이션에서 RabbitMQ와 Connection을 유지하고 관리하는 로직이 잘못되어 MQ의 Connection Port를 과도하게 점유하는 이슈와 부딪히게 되었다. 이러한 현상은 의도한 것이 아니었고 Connection 관리는 RabbitMQ 동작 흐름과는 큰 관계가 있는 것은 아니었지만 기본적인 해상도를 높이기 위해 복습 차원에서 RabbitMQ에 대한 기본 지식을 정리하려고 한다.  오늘의 주제는 RabbitMQ에서 메시지를 라우팅 하기 위한 논리적인 개념인 Exchange이다. 이전에 RabbitMQ에 대한 소개를 간단하게 짚고 가려고 한다.  RabbitMQ란? RabbitMQ는 메시지 브로커으로, 애플리케이션 간에 비동기 메시지를 전달해 주는 역할을 한다. 오픈 소스이며..

개발을 하다 보면 외부 API를 수없이 사용하게 되고 고려하지 않으면 요청한 API 서버로부터 `429 Too Many Request`라는 곤란한 응답을 받게 된다. Rate Limting은 API Client만 고민하는 것이 아닌 요청을 받고 응답을 내려주는 API Server로부터 고려된 것이고 API Server는 DoS 공격과 같은 공격에 대해 대비하고 서버의 응답 처리량을 관리하기 위해서는 Rate Limiting은 필수로 고려되어야 하는 부분이다. 나는 얼마 전에 429 응답을 마주하게 되었고 요청을 받는 입장이 아닌 요청을 하는 입장에서 어떻게 요청량을 관리해야 될지에 대한 방법론을 몇 가지 알아보려고 한다. (Server와 Client의 방법론은 크게 다를 것 없다.) 429 Too Man..

이전글 [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 사이의 직접적인 관계를 끊음으로써 구조적인 결합도를 낮추는 장점이 있다. 하지만 구조적 결합도가 낮아지..

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

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