분류 전체보기

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

commit 메시지를 잘못 입력했거나, 혹은 디버깅용 코드를 포함하거나 간단한 실수를 코드에 포함하여 commit 하였을 때, 어떻게 대처를 해야 될까? git reset -soft를 통해 commit을 삭제 후 다시 commit을 하는 방법도 있지만 더 예측 가능하면서 안전하게 직전 commit을 수정하는 방법이 있다.바로 git commit의 옵션 중 --amend 옵션이다. commit 메시지 수정하기직전 commit의 메시지를 수정하려면 아래와 같이 git commit에 --amend 옵션을 사용하면 된다.$ git commit --amend 만약 아래와 같이 마지막 commit 메시지를 "4th commit"으로 작성하려고 했는데, 실수로 "5th commit"으로 작성했다고 가정해 보자.git..

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

진행 중 작업의 방향성이 수정되면서 이전 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의 바로 직전으로 돌아가기 위해서는 ..