전체 글

최근 진행하고 있는 쿠버네티스 기반의 서비스 플랫폼 프로젝트에서 각 서비스들의 빌드 과정을 자동화하기 위한 과정이 있었다.현재 관리하는 서비스들은 4개로, 각각 별도로 고유한 컨테이너 이미지가 존재한다.여기에서 Github Actions를 이용해 각 서비스 별로 변경점의 push가 발생하면, 그에 맞는 서비스 이미지를 새로 빌드해서 허브에 push하도록 구성하고자 했었다. 여기서 들었던 의문점은 '이 4개의 서비스를 어떻게 워크플로우로 빌드 과정을 작성할 수 있을까' 라는 것이였다.물론 각 서비스별로 빌드 Job을 생성해서 코드로 작성하면 구현은 되는 것인데, 그러면 중복이 생기게 되고 워크플로우 코드와 추후의 유지보수가 복잡해진다는 점이 다가오게 되었다.name: CI - Build & Push to ..

앞서 Github Actions를 통한 Application CI/CD와 ArgoCD를 통한 클러스터 CD 파이프라인에 대한 글을 작성했다.다만, Github Actions CI/CD에서 CD 부분은 CI에서 빌드한 내용을 Artifact로써 CD Job에서 사용하고, SSH 연결을 통해서 직접 운영 서버에 Deploy해주는 방식으로 구성했기에 아래와 같은 문제점이 거론될 수 있었다. 기존 Github Actions CI/CD의 이슈특정 서버에 강하게 의존이 배포는 SCP로 파일을 전송하고 SSH 연결을 거쳐 배포 스크립트를 실행하는 방식으로 되어있음따라서 특정 원격 서버와 배포 스크립트에 강하게 의존하고 있어서 확장성과 서버 장애나 IP 변경에 배포 실패 가능성을 가짐상태 관리 불가Workflow가 동..

ArgoCD쿠버네티스 환경에 친화적인 선언적 GitOps CD 도구GitOps?Git 저장소에 정의된 상태와 실제 환경의 상태를 지속적으로 비교하고 동기화하는 방식Git 저장소만이 오직 유일한 진실된 원천(Single Source of Truth)임을 원칙으로 삼는다⇒ “선언형” 방식에 초점을 두고, “원하는 상태”를 정의하고 이를 실제환경에 반영하려는 철학 Syncrepository의 코드 상태(Desired State)와 클러스터의 Application의 상태(Live State)를 비교해서 일치시키려는 작업두 상태의 비교 결과에 따라 Synced / OutOfSync로 나뉘는 것을 볼 수 있다. argoCD에서는 Application과 Project라는 단위로 리소스를 정의한다.Application..

CQRSCommand Query Responsibility Segregation, 명령-조회 책임 분리로 명령(Command)과 조회(Query)의 책임을 분리하는 아키텍처 패턴이다. 이전의 전통적인 CRUD(Create/Read/Update/Delete) 모델에서는 모든 작업이 동일한 하나의 데이터 모델/저장소를 이용했다.CQRS에서는 쓰기와 읽기 작업을 분리해서 각 작업만을 수행하는 DB를 이용해 성능과 확장성을 챙긴 아키텍처를 구축하게 된다. CQRS 구성읽기와 쓰기 작업을 모델별로 분리했기에 아래와 같이 구성된다.Command 모델데이터를 변경(Create, Update, Delete)하는 작업을 수행하는 모델Query 모델데이터를 조회(Query)하기 위한 모델, 오직 조회 작업만 수행한다.이벤..

Application 서비스를 운영하면 버그 패치나 기능 추가, 성능 개선 등으로 새 버전으로 업데이트하는 경우가 빈번하게 발생한다. 특히나 MSA 같은 환경에서는 개별 서비스들의 독립적인 배포가 잦기에 수많은 업데이트와 배포를 거치게 되며 좀 더 효율적인 배포 전략을 세워야한다.이러한 업데이트에서는 '사용자 경험의 연속성'이 중요한 요소가 되는데, 업데이트 과정에 있어서 사용자가 백엔드 단에서 업데이트가 벌어지고 있다는 등의 사실을 인지하지 못한 채로 서비스를 끊임없이 이용할 수 있어야하기 때문이다.이러한 요구를 충족시키기 위해 이른바 '무중단' 업데이트가 중요시 되는데, 이번에는 대표적인 Application 무중단 배포 전략 3가지를 간단한 실습과 함께 알아보도록 한다. Rolling Update기..

Lease공유 리소스를 lock하고, 연결된 노드들 간의 활동을 조정하기 위한, 특정 pod가 일정 기간 동안 리더임을 선언하는 객체여러개의 pod 중에서 하나의 pod만 주어진 시간 동안 대표가 되어서 활동할 수 있도록 하는 객체이다.lease API는 `coordination.k8s.io` API 그룹에 존재하며, 대표적으로 아래와 같은 feature를 갖는다.holderIdentity : 현재 lease의 대표 idleaseDurationSeconds : lease의 지속시간renewTime : 마지막 lease 갱신 시각 쿠버네티스 클러스터에는 기본적으로 `kube-node-lease`라는 네임스페이스가 기본적으로 존재하는데, 이 네임스페이스에는 클러스터에 연결된 모든 노드들의 상태(`.statu..

서비스나 파이프라인을 구성하면 Lambda나 SQS 등등 클라우드 서비스를 여러개 사용해서 워크플로우를 구성하게 된다.하지만, 구성이 커지면 이러한 워크플로우의 구성요소들 간의 로직이 복잡해지게 된다.AWS 서비스들을 통해 워크플로우를 간단하게 구성하고 시각화시켜 흐름을 파악할 수 있는 Step function에 대해 알아보도록 한다.  Step FunctionAWS 서비스들을 한데 묶어 일련의 작업 파이프라인을 생성할 수 있는 서비스Workflow Studio를 통해 작업들을 직접 배치하고 시각적으로 확인할 수 있다는 특징이 있다.  Step function은 '상태 머신[State Machine]'이라는 개념으로 워크플로우를 구성한다. [상태 머신 == 워크플로우]그리고 상태 머신의 각 단계는 ASL..

kubernetes에서 파드는 일반적으로 Deployment나 ReplicaSet과 함께 지속적으로 수행되도록하는 목적을 가지고 있다.하지만, 단순히 일회성을 가지고 수행되는 작업들도 존재한다.예를 들면, 로그 데이터 처리나 데이터 백업같은 데이터 처리 작업이나 외부 API를 통해 데이터 수집이나 동기화 작업과 같은 배치 작업들이 있을 수 있다. 이러한 작업들도 Kubernetes 클러스터 내에서 실행될 수 있다. 바로 이번에 알아볼 Job과 CronJob이 여기에 해당된다. Job일회성 작업을 수행하는 리소스Job은 파드를 통해서 작업을 수행하고, 지정된 작업이 성공적으로 종료될때까지 수행을 반복한다. 아래와 같이 Job은 실행할 내용을 Pod template에 담아서 생성하게 된다.apiVersion..