DevYGwan

저희는 관리형 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..

저희는 실시간으로 공장에 있는 기기들의 데이터를 수집하고 있습니다. 그러다보니 실시간으로 들어오는 데이터들을 유실 없이 저장해야 합니다. 그래서 저희는 실시간 데이터를 효율적으로 처리하기 위해 아래와 같은 아키텍처를 구현하고 있습니다.간단하게 순서를 설명드리자면,1. 공장 기기 → MQTT Broker공장의 각 기기에서 MQTT 프로토콜로 메시지를 발행하며, 이 메시지들은 모두 MQTT Broker로 전달됩니다. 2. MQTT Broker → Kafka Connect → KafkaMQTT Broker에 들어온 메시지 중 Kafka에서 처리해야 하는 특정 토픽들은 Kafka Connect의 MQTT Source Connector를 통해 Kafka로 전달됩니다. 3. Kafka → Spark Streamin..

저희는 talos OS 위에 K8s을 이용하여 온프렘 서버를 개발하고 있습니다. talos OS가 생소하신 분들도 있을 것 같은데, 간단하게 말해서 컨테이너 오케스트레이션(Kubernetes)에 최적화된 초경량 리눅스 운영체제입니다. 나중에 기회가 된다면 talos OS에 대해서 좀 더 자세히 설명하는 글을 만들도록 하겠습니다. 메인은 k8s 환경에서 서비스들을 관리하고 있다는 것입니다. 본론으로 돌아가서, 저는 이 k8s 환경에서 pod들을 관리하는 도중 디스크 관리 & PV(Persistent Volume)관리에 불편함을 느꼈습니다. 제가 불편함을 느낀 사항은 다음과 같습니다.talos의 Immutable 특성 때문에 디스크 추가 & 변경 시 talos machineconfig 파일을 매번 수정해줘야..

공장 같은 곳에 Onprem 서버를 구축할 때 보면 상당히 고려해야 할 점이 많습니다. 대부분 고객들이 Onprem 환경을 원하는 이유는 기기 데이터를 외부에 노출시키고 싶지 않기 때문입니다. 따라서 대부분 환경이 인터넷 연결이 안되어있는 내부망을 사용합니다. 그러다보니 인터넷이 안돼 인터넷이 필요한 작업들은 할 수가 없습니다. 또한, 공장 기기들 때문인지 LTE 라우터를 통해 인터넷 연결을 잠시 하려고 해도 인터넷이 생각보다 잘 되지 않았습니다. 실제로 k8s내의 clickhouse 이미지를 pull 받아 파드 하나를 띄우려했는데... 이미지 pull만 30분이 넘게 걸렸습니다. 그 뒤로는 limit이 걸렸는지 그 이후에 인터넷 연결이 매우 느려진 현상을 확인할 수 있었습니다. ※ 그때 당시 문제 ..