ecsimsw

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

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

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

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

배경회사 서비스 중 하나로, IoT 기기를 코드로 조회, 제어할 수 있는 API를 제공하고 있다.최근 과금 정책을 도입하고 과하게 리소스를 사용하는 사용자를 제한하려는 시도를 하고 있다.나는 잔여 포인트를 확인하여 요청을 제한하거나, 포인트를 차감하는 트랜잭션 처리를 개발한다.개발 요구 사항은 아래와 같다. 1. API 호출 시 지정 크레딧 차감- 크레딧 부족 시 요청을 제한한다.- 서버 에러 시 차감하지 않는다. 2. 요청 처리 결과 내역 저장- 트랜잭션, 응답 시간, 응답 결과, 요청 정보, 소모 크레딧를 기록한다.- 이를 검색할 수 있는 API가 필요하다. 언제 차감하는 게 좋을까크레딧은 요청 처리 전에는 단순 잔액 확인만 하고, 요청 처리 후에 차감하기로 결정했다.선 차감 시에는 꼼꼼한 요청 제한..

대규모 업데이트IoT 서비스를 운영하는 우리 회사는 외부 IoT 플랫폼 위에서 애플리케이션단을 개발해 왔다.재작년부터 플랫폼을 독자적으로 운영하기 위한 준비를 해왔고, 최근에 배포를 마쳤다.아예 플랫폼을 사 와 직접 운영하기로 한 것이다.신규 플랫폼 서버 로직에 문제가 있어 기기 순서가 뒤섞였던 상황그 문제를 수정, 배포하는 과정에서 서버 리소스 부족이 고객들에게 노출되었던 상황특정 앱에서 신규 플랫폼의 특정 기기 사용에 제한이 되는 상황 생각만큼 문제가 많았다.특히 회사 간 엮인 급한 이슈 거리들이 많아 밤도 많이 새웠다. 배포 후 2주일 정도 지난 지금, 여전히 바쁜 나날을 보내고 있다.그래도 커다란 이슈들은 어느 정도 잡히고 작은 이슈들만 남아 있는 상태이다. 지금까지의 업무 경험 중 가장 체력적..