ecsimsw

배경회사에서 레거시 Api 서비스의 유료화 프로젝트를 진행하고 있다.기존에는 부족했던 사용량 제한과 집계, 서버 가용성, 응답 속도 등 개선해야 할 것이 많았다.나는 그중 전면의 게이트웨이를 구성하고, 인증 흐름, 요청/응답 로깅, 사용량 제한을 처리하는 역할을 맡았다.게이트웨이로는 다양한 플러그인과 활발한 커뮤니티, NginX 기반의 빠른 성능을 갖고 있는 ApiSix를 선정했다. 사용 내역 조회, 사용량 제한을 위한 구조가 가장 재밌었다.액세스 로그를 Kafka로 전달하고, 이를 OLAP(Starrocks)가 수신, 집계 처리하는 구성이었는데, 사용자별 사용량, API 별 요청량, 사용 패턴이나 응답 속도 등, 수억건의 데이터에 대한 집계가 수 초 안에 처리되는 것에 놀랐다.그리고 그렇게 집계한 데이..

배경나는 IoT 서비스 회사의 백엔드 개발자이다.약 260만 개의 기기에서 초당 6천 개에 달하는 기기 상태 이벤트가 발생하고 있다.나는 이를 수신하여 가공하고, 적재 또는 다음 서비스로 전달하는 파이프라인을 개발한다. 수많은 기기 상태 이벤트를 가공 없이 날것 그대로 저장하는 것은 매우 중요하다.적재된 데이터는 기기가 과거 특정 시점에 어떤 상태였는지 확인하는 히스토리가 되고,고객의 기기 동작 문의를 확인하거나 외부 플랫폼의 이벤트 처리 여부를 증명하는 중요한 증적이 된다. 데이터 저장소 비교1차 시도: CloudWatch처음에는 단순 로그로 취급하여 CloudWatch Logs에 모든 이벤트를 기록했고, 비용 문제를 만났다.CloudWatch Logs는 수집, 저장, 분석 세 가지 영역에서 비용이 발..

배경최근 국내 서비스들에 보안 이슈가 많았다.우리 회사도 보안 점검을 진행했고, 내가 맡고 있는 서비스의 인증 서버 역시 주요 대상이 되었다.요청 수 제한, 애플리케이션 키 관리, 로그 마스킹, 개인정보 보관 방법 등을 점검하고 개선했다.기능적으로는 '구글 연동 로그인'과 '2FA 강제'를 위한 추가 개발이 필요했다. 추가 기능을 개발하고 보안을 점검하기 위해선, OAuth 2.0으로 구현된 인증 서버를 먼저 이해해야 했다.아래는 그 과정에서 재밌었던 부분을 정리한다. OAuth 2.0 가 필요했던 이유지금까지의 경우와는 달리, 이번엔 내가 OAuth 서버를 운영하는 입장이 되었다.연동 서비스에서 OAuth 서버를 운영하는 이유부터 이해해야 했다. 우리 회사의 연동 서비스는 삼성, LG와 같은 외부 Io..

배경나는 IoT 서비스 회사의 백엔드 개발자이다.회사 기기는 삼성 Smartthings, LG ThinQ, Naver, KT, Kakao 등 국내 IoT 플랫폼과의 연동을 지원한다. 서버는 플랫폼의 기기 제어 요청을 처리하고, 반대로 기기의 상태를 플랫폼으로 전달하는 중간 다리의 역할을 한다. 그 중 이벤트 파이프라인은 기기의 이벤트를 수신하고, 이를 연동된 플랫폼으로 전달하는 서비스이다. 전달된 이벤트는 화재 감지, 강제 문 열림 알림, 동작 감지 등 앱 상 UI 변경만이 아닌, 사용자 안전 문제와 직결된 알림을 처리한다.그렇기에 지연 시간과 유실률은 서비스 신뢰도 문제이며, 안정적인 리소스 관리, 꼼꼼한 처리 증적 관리가 특히 더 중요했다. 처리량 증가서비스가 성장하며 이벤트가 크게 늘었다. 2년 ..

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

배경IoT 서비스 회사에서 백엔드 개발자로 일하고 있다.기기 사용 환경을 넓히기 위해, 자체 플랫폼 외 LG, 삼성, 네이버, 카카오, KT 등 다른 국내 IoT 플랫폼과의 연동 서비스를 지원한다.브라우저용 웹 대시보드도 그중 하나이다.나는 대시보드에서 발생한 제어 요청을 기기에 전달하고, 반대로 기기의 이벤트를 대시보드에 전달하는 중간 다리 역할을 맡는다.이 글에선 웹 소켓 서버의 관리 어려움과 이를 개선하기 위한 구조 변경 경험을 소개한다. 전통적인 웹 소켓 서버 아키텍처웹 소켓, SSE 같은 연결 유지가 필요한 서비스는 관리가 어렵다.클라이언트와 서버가 한번 연결되면, 해당 연결은 최초 수립된 인스턴스에 종속된다. 이로 인해 메시지 전달을 위해선 클라이언트가 연결된 서버를 찾아야 하는 복잡함이 있다..

배경요즘 여러 서비스들에서 보안 문제가 많이 터진다.우리 팀도 경각심을 느껴 점검했고 많은 개선 사항을 발견했다.급하게 달리는 회사들은 놓치는 부분이 있을 수밖에 없는 것 같다.그중 가장 큰 작업은 플랫폼 키 관리 방법 개선과 접근 통로 제한이었다.그 방향에 대한 내 아이디어가 잘 먹혔고, 리딩할 수 있는 기회를 얻었다. 위험 요소 우리 팀은 IoT 서비스를 운영한다. 기기 제어와 상태 처리를 플랫폼에 맡겨 서비스 개발에 집중하는 것이다. 그 플랫폼에 인증할 수 있는 키와 접근 경로 관리를 위험 요소로 판단하였다. 1. 키 분산플랫폼 접근 키가 여러 환경에 분산되어 있었던 것을 큰 문제로 삼았다.단순히 클라우드 제공사나 가상머신이 분산된 경우도 있고, 키를 저장하는 방법도 다양했다.환경 중 하나라도 문..

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