ecsimsw

배경알림 서비스 이야기이다.카프카로부터 메시지를 수신하고 이를 사용자에게 전달하는 서비스를 운영하고 있다.네트워크 통신 비용 절감을 위해 카프카에서 메시지를 배치 수신, 그룹 단위로 처리한다.그룹 단위 처리 중 예외가 발생하면 이미 처리한 내용을 잊기에 복구 시 메시지를 중복 수신하게 된다.이에 수신한 메시지 ID를 레디스에 기록하고, 처리 전 비교하는 것으로 이전에 수신했던 메시지 여부를 검증한다.간단한 메시지 ID 저장 구조 변경으로, 레디스 메모리 사용률을 33% 개선한 경험을 소개한다. String vs Hash 기존 구조는 수신한 각 메시지 ID를 레디스 String 타입으로 저장했다.양이 많고, 짧은 보관 기간의 데이터이기에, 각 메시지 ID를 레디스 Key로 하여 TTL을 명확하게 지정했다...

배경나는 아래의 상황에서 카프카를 생각한다.- 처리에 시간이 걸려서 메인 흐름 부에서 분리하고 싶을 때- 서비스 간 안전하고 순서가 보장된 이벤트 전달이 필요할 때 물론 비동기 처리와 이벤트 전달 방법은 많지만 방법마다 다른 제약이 존재한다.- Http : 이벤트를 전달받는 쪽의 상태에 의존적- Redis PS : Fire and Forget. 쏘기만 하고 잘 받았는지는 검증 않음- RabbitMQ : 여러 수신처에서 동일하게 수신하려면 여러 개 큐가 필요. 꼼꼼한 순서 보장을 위해선 단일 컨슈머 필요 카프카를 다루면서 고민해야 하는 포인트가 있다면 다음과 같다.- 브로커 측면 : 파티션 크기, 브로커 성능과 수 - 프로듀서 측면 : 메시지 키, 배치 크기, 배치 간격, 직렬화 방법- 컨슈머 측면 : ..

배경최근 프로젝트로 서버에서 클라이언트로 데이터를 전달해야 하는 요구사항이 생겼다. 좀 더 자세히는 한 B2B 서비스에 우리 회사 카메라 기기의 스트리밍을 제공해야 하는데, 이때 사용자 페이지와 기기 사이의 중개 서버 개발을 맡았고, 서버에서 클라이언트로 네트워크 경로 후보지 전달이 필요했다. 그간 고질이었던 기존 WebSocket 서버 관리 방법을 다시 한번 고민할 수 있는 기회가 되었다. 그 과정에서 AWS의 API Gateway WebSocket을 사용하면 웹 소켓 서버를 직접 관리하지 않아도 됨을 찾을 수 있었다. 생각보다 저렴한 비용과 편한 모니터링, 무엇보다 거의 없다시피 한 관리 포인트에도 안정적인 확장이 가능했다. 이 글에서는 내가 느낀 기존 전통적 방식의 웹 소켓 서비스 운영의 제약을 소..

배경재밌는 일이 들어왔다. 회사의 카메라 기기를 외부 플랫폼에서 스트리밍 될 수 있도록 만들어야 했다. 회사에 DevOps가 따로 없다 보니 클라우드를 직접 만지고 비용을 관리한다. 특히나 우리 회사는 홈 카메라도 판매하기에 스트리밍을 위한 데이터 통신비가 얼마나 큰지 안다. WebRTC를 위한 모든 데이터가 서버를 거친다면, 그 속도도 문제지만 통신 비용도 클 것이다. 그래서 노드 간 직접 연결이 중요하다. 나는 여기가 재밌었다. 이 글 자체도 사실 이걸 얘기하고 싶었다.배포되지 않은 로컬 네트워크의 기기끼리 어떻게 서로를 찾아 직접 통신하는지 궁금했다. NAT 동작 과정P2P 통신의 원리를 이해하기 위해선, NAT의 동작 과정을 이해해야 한다.NAT 내부에서 외부에 요청을 보내면, NAT는 연결 정..

배경지난 글에서 논 블록킹을 구현하는 두 가지 방법을 확인했다.Netty는 커널의 I/O 멀티플렉싱 연산을 사용하고, DelayQueue는 커널 단의 스레드 제어 연산을 사용했다. 이번에는 CAS와 CountDownLatch가 궁금했다.사실 CAS와 CountDownLatch도 앞선 두 경우와 비슷할 것 같다는 생각에 파본 것인데, 그렇지 않았다.CAS는 전혀 다른 방법으로 동작했고, CountDownLatch는 짬뽕이었다. 나는 컴퓨터공학을 전공했다. 부끄럽지만 컴퓨터구조와 운영체제 수업을 가장 재밌게 수강했다.앞선 멀티 플렉싱이라는 키워드도, 앞으로 얘기할 커널 모드와 시스템 콜도, 다 공부한 개념인데 참 낯설다.오랜만에 복습할 겸, 운영체제와 자바 개발을 스르륵 녹일 수 있는 글이 되었으면 좋겠다..

배경우리 회사는 IoT 기기를 다루고 있다. 보다 더 넓은 서비스를 제공하기 위해, 회사의 제품을 더 큰 국내 IoT 플랫폼에 연동이 가능하게 만드는 게 내 일이다. 외부 플랫폼에서 우리 회사 기기를 제어할 수 있는 Api를 개발하고, 반대로 외부 플랫폼으로 기기 이벤트를 전달해야 한다. 이번에 신규 기기를 연동시키면서 재밌는 요구 사항이 있었다. 특정 이벤트가 들어오면 외부 플랫폼 측으로 A를 전달하고, 1분 후에 B를 전달해야 했다. 이벤트 파이프라인은 바쁘기에 1분을 블록킹 대기할 수 없다. 옆자리 형이 Mono.delay를 사용한 논 블록킹으로 딜레이 로직을 구현하였고, 이를 리뷰하다가 Mono.delay의 동작 방식을 파보게 되었다. 이를 정리해보려고 한다. I/O Multiplexing을 사용..

요구 사항 우리 팀은 IoT 기기를 다룬다. 도어락의 문 열림 기록이나, 온습도계의 일간, 월간 온습도 변화 기록 조회 등, 기기의 상태 기록을 조회할 수 있는 기능을 제공한다. 이런 기능을 위해 ‘히스토리’ 서비스는 기기의 상태 이벤트를 수신하고, 기록해야 할 테이터를 필터링하여 DB에 적재하는 역할을 수행한다. 현재 히스토리 서비스에서 저장해야 하는 이벤트 양은 초당 초당 2600 ~ 2800건이다. 그리고 아래는 현재 히스토리 서비스 초당 처리량이다. 이벤트 유입량과 처리량이 크게 차이가 나지 않음을 알 수 있다. 지금까진 가까스로 처리되었지만, 지금보다 유입량이 조금만 더 많아지면, 유입량이 처리량보다 많아져 이벤트 유실이나 OOM이 발생하기 좋다. 우리 팀의 목표 요구치는 초당 7천 건의 저..

OOM 발생최근 서비스 하나가 말썽이었다. 대략 이벤트를 HTTP로 수신해서, DB와 API를 호출하여 처리 여부를 결정하고 RabbitMQ로 전달하는 중간 파이프라인 역할의 서비스였다. 부끄럽지만 예전에 개발되고 더 이상 건들지 않고 운영되던 히스토리가 없는 코드였다. 갑자기 메모리 사이즈 사용률이 비정상적임을 알리는 경고 메시지를 수신했고, '올게 왔구나' 했다. 가장 먼저 그라파나 대시보드를 살폈다. Heap 메모리와 GC 의 동작을 확인했다. GC 동작 이후에도 Old Gen의 최저 수위가 점점 높아지는 것을 볼 수 있다. Major GC의 처리 대상이 되지 못하는 메모리 영역이 계속 쌓이고 있고, 긴 Stop the world 시간과 함께, Major GC 수행만 반복되는 것을 확인할 수 있다..