배치 작업을 VM 서버에서 실행해 동시 실행에 어려움을 겪은 적이 있나요?이 글에서는 Kubernetes Job을 활용해, 기존에는 VM 서버에서 실행되던 배치 작업이 클러스터에서 실행되도록 아키텍처를 변경해 작업의 효율성을 높이고, Kubernetes 커스텀 컨트롤러로 Job 스케줄러를 구현해 Job 실행을 더 유연하게 관리한 방법을 공유하고자 합니다.동시에 실행하고 싶은 배치가 너무 많다프로젝트 초기에는 실행해야 하는 배치 수가 적기 때문에 간편하게 VM 서버 한 대에서 모든 작업을 처리할 수 있습니다. 하지만 프로젝트를 운영해 갈수록 실행해야 하는 배치 수는 점점 늘어나고 VM 서버 한 대로는 해결하기 힘든 상황이 옵니다.예를 들어보겠습니다. VM 서버 한 대로 특정 시간에 사용자에게 다양한 알림을 보내고 싶다면 어떻게 해야 할까요?일반적인 운영 환경에서는 VM 장비 한 대로는 CPU, 메모리 등 자원 할당의 문제로 여러 배치 작업을 동시에 실행하기 힘들기 때문에 서로 연관이 없는 독립적인 배치 작업이라도 동시에 실행하지 못하고 하나의 작업이 끝날 때까지 기다렸다가 다른 작업을 시작해야 합니다.만약 동시에 여러 작업을 실행하고 싶다면 서버를 추가해서 각각 실행해야 합니다. 하지만 서버를 추가하면 비용이 증가할 뿐 아니라 관리 포인트가 늘어나고, 이 경우 특정 시간에만 작업을 실행하기 때문에 대부분의 시간에 서버가 사용되지 않아서 자원을 효율적으로 사용할 수 없습니다. 그렇다고 해서 이 작업을 위해 특정 시간에만 새로운 서버를 설정하는 방법은 확장성이 떨어집니다.그래서 이런 문제점을 해결하기 위해 Kubernetes Job을 활용해 배치 작업을 클러스터에서 실행할 수 있게 했습니다.클러스터에서 일회성 작업을 실행할 수 있는 Kubernetes Job 오브젝트Kubernetes Job은 Kubernetes 클러스터에서 일회성 작업을 실행하기 위한 오브젝트입니다.의존성 없는 다수의 배치 작업을 각각 Job으로 실행하면 하나 이상의 컨테이너에서 배치 작업을 독립적으로 수행할 수 있어 전체 배치 작업의 실행 시간이 단축되고 시스템 전체의 효율이 향상됩니다.뿐만 아니라 Kubernetes의 자동 확장 및 복구 기능은 시스템의 안정성을 높이고 유지 보수 부담을 줄여줍니다. 또한 한 번 Job을 구성해두면 클러스터만 변경해 실행이 가능하기 때문에 이중화에도 효과적입니다.그럼 Kubernetes Job이 어떤 식으로 동작을 하는지 간단하게 알아보고, Job 템플릿을 생성 후 실제로 실행하고 모니터링해 보겠습니다.Kubernetes Job 동작 방식Kubernetes Job은 클러스터 내에서 자원을 조정하고 작업을 스케줄링하는 컨트롤 플레인을 통해 파드에 스케줄링받아 실행됩니다.출처: Kubernetes Components사용자가 Job 생성을 요청하면 Kubernetes API 서버가 요청을 받아서, 클러스터의 모든 상태 정보를 저장하는 etcd에 리소스를 저장합니다.etcd에 리소스가 저장되면, 해당 리소스의 이벤트를 감시하는 컨트롤러 매니저가

안녕하세요. 저는 검색서비스팀의 유성규입니다. 저희 팀은 에이닷 내 다양한 서비스에 사용되는 검색 및 추천 기능 개발과 운영에 주력하고 있습니다.이번 블로그에서는 저희가 어떻게 쿠버네티스를 이용해 컨테이너 기반 검색추천 시스템을 구축했는지,그리고 이 시스템이 에이닷 3.0 및 B tv 셋탑에서 출시된 미디어 에이전트 서비스에 어떻게 도입되었는지를 소개하고자 합니다.쿠버네티스를 사용하여 검색추천 시스템을 컨테이너화함으로써 여러 가지 중요한 이점을 얻을 수 있었습니다. 주요 이점은 다음과 같습니다.• None 개발 및 운영 효율성 향상: 반복적인 작업들을 자동화하며 개발과 운영 과정을 간편하고 효과적으로 관리할 수 있었습니다.• None 빠른 서비스 배포: 필요한 컴포넌트를 쉽게 배치하여 검색추천 서비스를 빠르게 제공했습니다.• None 중앙 집중화된 모니터링 도입: 모든 서비스 상태를 중앙에서 통합적으로 모니터링하고 관리할 수 있어 문제 해결과 운영 관리를 더욱 쉬웠습니다.쿠버네티스를 통해 효율성 및 자동화를 실현하기 위해, 저희가 세운 주요 목표는 다음과 같습니다.• None 상용화 가능한 쿠버네티스 클러스터 구축: 안정적이고 확장 가능한 쿠버네티스 클러스터를 구축하여, 다양한 서비스가 원활하게 운영될 수 있도록 합니다.• None 검색추천 시스템을 컨테이너로 배포: 기존의 검색추천 시스템을 컨테이너 기반으로 전환하여, 서비스의 유연성과 확장성을 확보합니다.• None 컨테이너 기반의 애플리케이션 모니터링 시스템 구축: 컨테이너 환경에서 효율적인 모니터링 시스템을 구축하여, 서비스 운영 상태를 실시간으로 확인하고 관리할 수 있도록 합니다.본 글에서는 목표를 달성하기 위한 진행한 작업들에 대해서 전체적으로 공유하고자 합니다.쿠버네티스(Kubernetes)는 API 서버, 스케줄러, 컨트롤러 매니저 등으로 구성된 컨트롤 플레인과 각 노드에 설치되는 Kubelet 데몬을 포함하고 있습니다.이 시스템은 컨테이너 런타임과 네트워킹 기반 위에서 작동하며, 대부분의 컴포넌트는 리눅스 커널 기능에 크게 의존합니다.따라서 리눅스 커널 설정 및 파라미터 관리가 매우 중요합니다.쿠버네티스 클러스터를 초기화하는 작업은 도구로 지원되지만, 컨테이너 런타임 구성, 네트워킹 설정, 리눅스 커널 파라미터 조정 등 다양한 세부 사항의 관리는 여전히 클러스터 관리자의 책임입니다.이는 여러 공식 문서를 따르면서 진행할 수도 있지만, 이 방법은 복잡하고 시간이 많이 소요될 수 있습니다.이를 해결하기 위해 오픈소스 도구인 Kubespray를 사용하였습니다.Kubespray는 쿠버네티스 구성 요소의 설치뿐만 아니라 리눅스 커널 설정과 다양한 옵션들을 자동화하며,오랜 시간 동안 개선되고 활발한 커뮤니티 지원 덕분에 상용화 가능한 수준의 쿠버네티스 클러스터를 쉽게 구축할 수 있습니다.저희는 Kubespray 2.23 버전을 사용하여 쿠버네티스 클러스터를 설정하였습니다.클러스터를 구성한 후에는, 클러스터 환경을 더욱 컨테이너 중심 방식으로 운영하기 위해 추가적인 오픈소스 도구들을

저희 팀에서는 메타데이터성의 경량의 PostgreSQL을 쿠버네티스 클러스터 위에 배포하여 운영하고 있습니다. 기존의 VM과 같은 고정된 인프라 위에서 RDB를 운영하는 전통적인 방식과 달리 컨테이너 형태로 데이터베이스를 운영하는 방식에는 장단점이 있습니다. 이번 포스팅에서는 제가 PostgreSQL을 쿠버네티스로 배포 및 운영하면서 겪은 해당 방식의 장단점에 대해서 말씀드리려고 합니다.DB를 Kubernetes Pod로 관리하게된 계기저희 팀에서 데이터베이스를 구축해야하기 전에 충족해야하는 요구조건이 몇가지 있었습니다. 설치 및 배포가 용이하고 검증되어있어야 했으며, 구축할 데이터베이스의 스키마가 복잡하지는 않으나 HA를 충족시켜야 했습니다. 또한 메타데이터성의 데이터였기 때문에 읽고 쓰는 양 자체가 많지 않지만 차후 확장성을 고려하여 스케일링 방식이 유연해야 했습니다.  이러한 요구사항을 기반으로 컨테이너 방식으로 데이터베이스를 구축하자는 의견이 나왔습니다. 저희 팀 구성원들은 VM 인프라에서만 데이터베이스 운영 경험이 있었기 때문에 처음에는 걱정이 된것도 사실이었지만 결국은 매우 효율적으로 PostgreSQL을 운영할 수 있었습니다.컨테이너 형태의 PostgreSQL운영의 장단점결론부터 말씀드리면 상황에 따라서 장단점이 다르게 적용되는 것 같습니다. 제가 운영을 하면서 느꼈던 장점과 단점을 아래 표에 정리해보았습니다.장점단점설치 및 버전 업그레이드가 쉽다직접적인 운영이 어렵다초기 구축이 쉽다client 접속이 번거롭다환경 설정이 쉽다트러블슈팅이 어렵다구축과 업그레이드가 손쉽게 된다는 것은 컨테이너화된 데이터베이스의 가장 큰 장점이라고 할 수 있을 것 같습니다. 제한된 시간 안에 고가용성 postgres를 구축해야 한다면 쿠버네티스 위에서 운영하는 것이 더 적절할 것입니다. 반면에 컨테이너화 되어 있다보니 접속하는 CLI가 사용자 친화적이지 않고 환경 설정에 대한 볼륨도 직접적으로 하기 번거로워서 세부적인 운영에 어려움이 있었습니다. 실제로 VM 보다 장애가 발생했을 때 트러블슈팅 하는데에 시간과 노력이 더 많이 필요했던 것 같습니다. 또한 호스트 운영체제를 공유하는 컨테이너 기반의 데이터베이스 형식이다보니 VM에 직접 서비스를 운영할 때보다 성능적인 측면에서 이슈가 있을 수 있을 것 같습니다. 따라서 저희 팀의 요구조건처럼 데이터 쓰기 양이 많지 않고 비용과 자원이 제약되어 있는 상황에서는 컨테이너 방식의 데이터베이스 운영이 장점일 수 있으나 대규모 서비스를 운영 한다거나 성능에 중요한 이슈가 있는 환경에서는 적절하지 않을 수 있을 것 같습니다.설치 과정저희가 선택한 방식은 bitnami에서 제공한 postgres-ha helm 차트를 이용한 배포 방식이었습니다. bitnami helm 차트는 공식 차트에 비해 좀 더 사용자 친화적이고 간편한 설치 방법을 제공합니다. 설정 또한 유연하게 조정할 수 있어서 원하는 요구사항에 맞춘 배포가 가능하다는 장점이 있습니다. postgres-ha는 postgresql 클러스터에서 replicat

많은 회사에서 캐시 용도로 널리 사용하는 Redis! 빠른 데이터 처리 속도 덕분에 세션 관리, 메시지 브로커 시스템, 실시간 분석 등 다양한 분야에서 활약하고 있습니다.하지만 Redis를 직접 사용하려면 서버 구축부터 설치, 운영까지 꽤 복잡한 과정을 거쳐야 합니다. 이는 서비스 출시를 지연시키는 요인이 될 수 있습니다.저희 팀 역시 대용량 데이터를 실시간으로 처리하기 위해 다양한 프로젝트에서 Redis를 활용하고 있습니다.기존 방식대로 서버를 구축하고 운영하는 데에는 시간과 비용이 많이 들었고, 데이터 증가에 따른 확장성 문제도 발생했습니다.이러한 문제를 해결하기 위해 필요할 때 바로 사용할 수 있는 SaaS형 Redis 서비스를 고민하게 되었고, Kubernetes Operator를 활용한 Redis Cluster 구축 방안을 모색하게 되었습니다.SaaS(Software as a Service)는 인터넷을 통해 소프트웨어를 사용할 수 있는 서비스를 의미합니다.대표적으로 Gmail이나 네이버 메일 같은 이메일 서비스를 들 수 있습니다.과거에는 이메일 서비스를 사용하려면 직접 서버를 구축하고 소프트웨어를 설치해야 했지만, SaaS형 서비스 덕분에 복잡한 과정 없이 편리하게 이메일을 사용할 수 있게 되었습니다.SaaS형 Redis Cluster 서비스 역시 사용자들에게 다음과 같은 장점을 제공합니다.• None 시간 및 비용 절감: 서버 구축과 유지보수에 드는 시간과 비용을 크게 절약할 수 있습니다.• None 빠른 서비스 개발: 인프라 걱정 없이 바로 Redis를 사용하여 서비스 개발 속도를 높일 수 있습니다.• None 안정성 및 성능 향상: SaaS 제공자가 Redis Cluster를 관리하고 최적화하여 안정성과 성능을 보장합니다.• None 장애 대응: 장애 발생 시 신속한 대응이 가능하여 서비스 중단을 최소화합니다.Redis는 단일 인스턴스 모드, Sentinel 모드, Cluster 모드를 지원합니다.각 모드마다 특징이 있지만, 저희 팀은 대용량 메모리 지원과 고가용성이 필요했기 때문에 Redis Cluster를 선택했습니다.Redis Cluster는 데이터를 여러 노드에 분산 저장하여 더 큰 데이터 용량을 지원하고, 고가용성과 성능을 동시에 보장합니다.Redis Cluster를 직접 설치하고 운영하려면 다음과 같은 어려움이 따릅니다.• None 복잡한 설치 및 설정: 수동으로 설치하고 설정하는 과정이 복잡하고, 여러 노드 간의 정확한 구성이 필요합니다.• None 스케일링의 어려움: 데이터 증가에 따라 Redis Cluster를 확장해야 하는데, 새로운 노드 추가와 데이터 재분배 과정이 복잡합니다.• None 장애 대응 및 복구: 노드 장애 발생 시 신속한 대응과 복구가 필요한데, 이는 운영팀에 큰 부담이 됩니다.Kubernetes Operator는 Redis Cluster의 생성, 운영, 관리를 자동화하여 위에서 언급한 어려움을 해결해 줍니다.• None 자동화된 설치 및 설정: 복잡한 과정을 자동화하여 시간을 절약하고 오류 가능성을 줄입니다.• None 간편한 스케일링: 자동으로 노드를 추가하고 데이터를 재분배하여 확장성 문제를 해결합니다.• None 자동화된 장애 대응: 장애를 자동으로 감지하고 복구 절차를 수행하여 시스템 안정성을 높입니다.Kubernetes Operator는 특정 애플리케이션의 관리를 자동화하는 소프트웨어입니다.단순히 애플리케이션을 배포하고 실행하는 것을 넘어서, 원하는 상태를 지속적으로 유지하고 문제 발생 시 자동으로 복구하는 등 고급 기능을 수행합니다.이러한 기능을 이해하기 위해서는 Kubernetes 시스템의 핵심 개념인 Desired state를 먼저 알아야 합니다.Desired state는 말 그대로 "원하는 상태"를 의미합니다.Kubernetes에게 우리가 원하는 시스템의 상태를 선언하는 것이죠. 예를 들어, 특정 서비스가 항상 3개의 Pod로 실행되기를 원한다면, 이것이 Desired state가 됩니다.Kubernetes는 Desired state를 달성하고 유지하기 위해 Kubernetes Resource와 Controller라는 두 가지 중요한 요소를 사용합니다.• None Kubernetes Resource: Kubernetes API를 통해 관리되는 엔티티로, Pod, Deployment, Service, Volume 등 다양한 종류가 있습니다. 각 Resource는 고유한 이름을 가지고 있으며, 클러스터의 현재 상태를 나타냅니다. 또한, Desired state를 정의하는데 사용합니다. 예를 들어, Deployment Resource는 원하는 Pod의 개수, 이미지, 환경 변수 등을 정의하여 Desired state를 표현합니다.• None Controller: Kubernetes의 핵심 컨트롤 루프로, 현재 클러스터 상태를 Desired state에 가깝게 만드는 역할을 합니다. Controller는 특정 Resource 유형을 감시하고, 현재 상태와 Desired state를 비교합니다. 만약 차이가 있다면, Pod 생성/삭제, 설정 변경 등 필요한 조치를 취하여 Desired state를 달성합니다. 이 과정은 지속적으로 반복되어 시스템 상태가 항상 Desired state를 유지하도록 합니다.Operator는 이러한 Kubernetes Resource와 Controller 개념을 확장하여 특정 애플리케이션의 Desired state를 보다 효과적으로 관리합니다.Operator는 Custom Resource와 Custom Controller를 통해 작동합니다.• None Custom Resource: 사용자가 정의한 새로운 Resource 유형입니다. 예를 들어, RC Operator는 RC(RedisCluster)라는 Custom Resource를 정의하여 Redis Cluster의 Desired state를 표현합니다.• None Custom Controller: Custom Resource를 감시하고 관리하는 Controller입니다. RC Operator의 Custom Controller는 RC