ecsimsw

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

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

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

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

배경회사 레거시 서비스들의 배포, 인프라 관리가 많이 아쉬웠다. VM 여러 개에 Jar 파일을 직접 배포하는 식이었고, 로깅은 파일로 확인, 매트릭 모니터링, 배포 자동화는 전혀 안되어 있었다. 매트릭을 모니터링하기 시작했고, Loki와 CloudWatch로 로그를 수집, 검색할 수 있도록 하였다. 자잘한 개선들과 자동화를 꾸준히 만들어왔지만, 근본적인 문제들은 결국 개선되지 않고 있었다.// 기존 제약 사항1. 서비스가 다운되면 직접 확인하고, 배포해야 했다.2. 애플리케이션 리소스가 VM 타입에 제한적이었고, 서비스가 VM의 상태에 의존되었다.3. 헬스 체크와 이를 바탕으로한 라우팅 규칙 수정이 수동적이었다. 급한 프로젝트들을 어느 정도 정리하고 팀에 시간이 생겼다. 현재 운영 중인 인프라들을 개선하..

배경회사 서비스 중 하나로, IoT 기기를 코드로 조회/제어할 수 있는 API를 제공하고 있다. 서비스가 커지면서 해당 서비스에 과금 정책을 도입하여, 서버 비용을 충당하고, 과하게 리소스를 사용하는 사용자를 제한하고자 한다. 나는 포인트 결제, 차감, 보상 처리를 맡아, 잔여 포인트를 확인하고 처리를 제한하거나, 포인트를 차감하는 트랜잭션 처리를 개발하고 있다. 개발 요구 사항은 아래와 같다.1. 사용자의 잔여 포인트를 조회하고 사용량만큼 차감되어야 한다.2. 잔여 포인트 부족 시, 비즈니스 로직이 수행되어선 안된다.3. 서버 문제로 비정상 응답을 반환할 경우, 포인트는 차감되어선 안된다. 문제 시나리오, 차감과 보상 사이의 포인트 부족 현상서버 이상으로 비정상 응답이 반환될 때는 포인트가 차감되어선..

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

이벤트 파이프라인우리 회사 기기는 삼성의 Smartthings, LG의 ThinQ, KT, Genie, Kakao, Clova 등 여러 IoT 플랫폼에서 연동되어 사용된다. 서버는 기기의 이벤트를 외부 서버에 전달하여 해당 플랫폼에서 상태 변화나 알림을 반영될 수 있도록 한다. 이벤트 파이프라인은 기기의 연동 정보를 확인하여 이벤트를 전달하거나, 필터링하는 역할을 한다. 만약 이벤트에 지연이 생기거나 유실이 발생한다면, 단순히 기기의 상태 변화가 앱에 반영되지 않는 것을 넘어, 혼자 있는 집에서의 도어락 강제 문 열림 감지, 영업을 종료한 가게에서 발생한 동작 감지, 아기 방에서의 비정상 온도 경보 등, 사용자의 안전과 직결된 문제로 이어질 수 있다. 그래서 기기 이벤트 지연과 유실은 팀에서 가장 유심하..