ecsimsw

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

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

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

처리량 개선이 필요하다.회사가 성장하며 기기 이벤트가 크게 늘었다. 8개월 전까지만 해도 초당 1500건이었던 기기 이벤트가, 이제는 3500건을 넘는다. 한 달 동안의 이벤트 수 변화량만 보더라도, 그 수위가 점점 높아지는 것을 볼 수 있다. 기존 인프라와 로직으로는 늘어난 유입량을 못 따라가고, 곧 지연과 유실로 이어진다. 이벤트 컨슘부터 Ack까지의 흐름 안에는 다양한 로직들이 있다. 그래서 '어떤 구간이 문제다!'라기보다는, 주변 영향을 최소화하면서도 효과적인 개선 방향을 고민한다. 물론 어떤 경우에는 단순히 인프라만 늘리면 해결되는 경우도 많다. 프로세스를 더 띄우고, 스레드 수를 늘리는 게 제일 빠를 수도 있겠지만, 최대한 주어진 자원 안에서 개선하는 방법을 고민하는 게 요즘 우리 팀의 방향..

미들웨어미들웨어는 애플리케이션 사이에서 데이터 흐름을 중계하거나 처리하기 위한 소프트웨어를 말한다. 사실 단순히 큐나 메시지 브로커만을 말하는 줄 알았는데, 정의에 따르면 WAS, GW, MQ, DBMS 등 내가 기존에 생각하고 있던 것보다 더 넓은 범위의 키워드로 생각된다. 요즘 이벤트 서버 성능 개선에 머리를 쓰고 있고, 서버를 구성하는 각 요소들의 성능 개선을 위해선 지금 어떻게 통신하고 있는지부터 알아야겠다는 생각이었다. 특히 톰캣에 요청이 너무 많이 유입이 돼서 에러가 날 때, 에러를 읽고 튜닝할 수 있는 눈이 필요했다. 자주 사용하고 있는 미들웨어들의 기본 설정이나 통신 방식들을 정리한다. # 메시지 브로커와 큐1. Kafka2. RabbitMQ3. Redis pub/sub4. AWS SQS5..

미들웨어미들웨어는 애플리케이션 사이에서 데이터 흐름을 중계하거나 처리하기 위한 소프트웨어를 말한다. 사실 단순히 큐나 메시지 브로커만을 말하는 줄 알았는데, 정의에 따르면 WAS, GW, MQ, DBMS 등 내가 기존에 생각하고 있던 것보다 더 넓은 범위의 키워드로 생각된다. 요즘 이벤트 서버 성능 개선에 머리를 쓰고 있고, 서버를 구성하는 각 요소들의 성능 개선을 위해선 지금 어떻게 통신하고 있는지부터 알아야겠다는 생각이었다. 자주 사용하고 있는 미들웨어들의 기본 설정이나 통신 방식들을 정리한다.# 메시지 브로커와 큐1. Kafka2. RabbitMQ3. Redis pub/sub4. AWS SQS5. Mosquitto와 MQTT# 웹 서버6. Tomcat7. Nginx8. ALB# DBMS9. Mysq..

배경 소개 팀에서 새로 인프라 구조, 아키텍처를 구성해야 하는 일이 있었다. 우리 팀은 Container 기반으로 서버를 운영하여, AWS ECS + Fargate를 사용하여 배포하기로 결정했다. 이때 VPC, ECR, ECS의 배포 정책이나 오토 스케일링을 모두 Terraform으로 관리하여 인프라 구성을 코드로 작성할 수 있도록 작업하였다. 이 글에선 이런 구조를 선택한 근거와 함께, 테라폼을 사용해서 얻을 수 있었던 팀 시점의 이점을 소개하려고 한다. 테라폼과 IaC선정한 ECS의 구축을 위한 AWS 리소스들은 모두 테라폼으로 작성, 코드로 관리하였다. 처음에는 다소 러닝 커브가 있었지만, 기반 코드를 만들어 소개하고 직접 한, 두 개 애플리케이션을 배포해 보면서 다들 금방 손에 익어하셨다. 낯선..

애플리케이션은 Vault의 존재를 몰라야 하지 않을까?개발자 친구를 만나고 팀에서 Vault를 사용한다는 이야기를 들으면 항상 하는 질문이, 'Vault에 대한 인증은 어떻게 해?' 였다. 그리고 다들 본인의 역할이 아니다보니 명확한 관리 방법이나 안전한 방식의 대답을 듣지 못했다. 비밀 키를 관리하는 금고를 여는 비밀 키 관리는 정말 중요해보인다. 아무리 안전한 금고할지라도 열쇠를 그 금고에 보관할 순 없는 노릇이고, 그렇다고 열쇠가 제대로 관리되지 못하면 말짱 도루묵일테니 말이다. 내가 그간 경험했던 환경에선 애플리케이션에서 Vault 인증을 위한 키를 갖고 있었고, 그 키로 Vault를 직접 호출해 필요한 비밀 값을 조회했다. 이런 방식은 애플리케이션에서 Vault에서 사용할 Secret 정보나 V..