DevYGwan

IoT 시계열 데이터를 과거부터 지금까지 조회하는 화면에서 어느 순간부터 데이터가 많아지니 조회 기간이 길어질수록(수백만 ~ 천만 행) 로딩이 급격히 느려졌고, 1년 데이터 조회 기준으로 JSON API는 요청부터 차트 렌더링까지 짧게는 47초, 길게는 1분 이상 걸리는 경우 발생했습니다. 이러다보니 한번에 조회하는 데이터가 많아질 수록 다음과 같은 추가적인 문제가 발생했습니다.사용자가 해당 화면에서 너무 오랜 시간을 기다려야 되는 문제 발생조회 기간이 길어질수록 AWS ALB의 기본 idle timeout(60초)에 근접하게 돼, 1분 이상 조회해야 할 경우 타임아웃으로 요청이 실패하는 케이스가 존재많은 데이터를 한번에 메모리에 저장해 서버 내에서 OOM 에러가 발생라는 단점이 존재했습니다. 물론 AW..

저희는 관리형 K8s(EKS/NKS) 없이 인스턴스 기반 K8s 노드 3개를 직접 운영하고 있습니다. 관리형 k8s을 사용하지 않는 이유는관리형 서비스의 업데이트 주기에 맞춰 저희도 관리해야한다.AWS 뿐만아니라 NCP, Azure 등 여러 cloud 서비스에서 운영해야 되는데 그때마다 관리형 서비스를 각각 개별적으로 관리해야한다. (현재는 AWS, NCP만 사용)Onprem 서비스로 직접 k8s 노드 3개로 직접 서비스를 운영해야한다.등이 있습니다. 물론 비용적인 측면에서도 관리형 서비스를 사용하는 것보다 직접 운영하는게 더 저렴하기 때문에도 있습니다. 따라서 이렇게 여러 환경에서 직접 K8s 노드로 운영하다보니 동일한 구성을 AWS와 NCP(네이버 클라우드) 등 여러 클라우드 서비스에서| 반복해야 한..

사내 B2B 플랫폼에 "여러 사용자를 한 번에 추가하는 API"를 만들면서 마주친 분산 데이터 정합성 문제와, 이를 경량 보상 트랜잭션으로 푼 의사결정 과정을 정리하려고 합니다. 저희는 사용자를 관리할 때 크게 2곳에서 관리합니다. 인증만을 관리하는 keycloak 서버 & 유저의 개인 정보를 갖고 있는 DB(Postgres)에서 관리합니다. 사용자 생성은 Keycloak(인증 서버) 과 우리 서비스 DB(Postgres) 두 곳에 일어납니다. 두개의 서버는 하나의 트랜잭션을 공유할 수 없어 특정 과정에서 문제가 생기면, 데이터 정합성에 문제가 생기는 경우가 발생합니다. 예를 들어, Keycloak 생성은 성공했는데 DB에 생성이 안되게 되면, 인증 서버에 고아(orphan) 계정이 남게 되는 경우가 생..

온프렘 서버 환경에서 k8s을 운영할 때는 pod 별로 디스크를 동적으로 관리하기 위해 OpenEBS LVM을 사용했습니다. 그래서 pod을 만들 때 매번 pv & pvc를 만들고 관리해야 되는 불편함을 해소했습니다. 따라서 이번에 AWS에서 k8s을 운영할 때도 이런식으로 운영하면 좋을 것 같아 찾아보던 중, AWS는 EBS(Elastic Block Store)를 CSI Driver를 통해 직접 제어하는 방식도 존재한다는 것을 알게 되었습니다. 따라서 이 2개의 방식을 비교해 최종적으로 AWS CSI Driver 방식을 사용하기로 결정했습니다. 그래서 이번기회에 2가지 방식을 비교하고 왜 이 방식을 사용했는지 정리하려고 합니다. 온프렘 관리 방식 vs AWS 관리 방식구분온프렘 (OpenEBS LVM)..

MSP(Managed Service Provider)나 SaaS 플랫폼을 운영할 때, 여러 고객의 온프레미스 또는 클라우드 인프라를 관리해야 하는 경우가 많습니다. 특히 각 고객이 독립적으로 구축한 Kubernetes 클러스터를 중앙에서 관리하려면 원격 접근이 필수적입니다. (물론 원격 접근이 불가능 한 고객들도 있습니다.) 저희는 3대의 서버와 이를 연결하는 라우터를 1세트로 구성해 온프레미스 환경을 구축합니다. 이후 Kubernetes 클러스터에 원격으로 안정적으로 접근하기 위해 라우터에 Tailscale을 설치하고, 라우터가 연결된 내부 IP 대역을 광고(advertise)하는 Tailscale subnet router로 설정합니다. 이를 통해 운영자는 Tailscale을 통해 각 노드와 Kuber..