Landbay, Amazon Elastic Kubernetes Service와 함께 GitOps를 사용

진화하는 디지털 대출 환경에서 영국 Buy-To-Let 시장에서 수상 경력에 빛나는 주택 담보 대출 기관인 Landbay는 디지털 인프라를 혁신하고 있습니다. 대출 심사 업무를 지원하는 업계 최고의 브로커 플랫폼을 갖춘 Landbay의 플랫폼은 AWS 서비스를 기반으로 구축되었으며, 3계층 아키텍처에 따라 웹 서버, Amazon Elastic Kubernetes Service(Amazon EKS), 다중 계층 데이터 계층을 결합한 약 60개의 마이크로서비스로 구성됩니다. Landbay는 AWS 클라우드 서비스의 강력한 기능을 오픈 소스 프로젝트와 결합함으로써 이 새로운 접근 방식을 활용하여 Amazon Elastic Kubernetes Service를 기반으로 동급 최고의 아키텍처를 구축할 수 있었습니다.

GitOps의 장점

마이크로서비스 아키텍처가 주목을 받으면서 GitOps는 이 배포 메커니즘의 새로운 표준으로 떠올랐습니다. Cloud Native Computing Foundation(CNCF)에서 주목할 만한 두 가지 제품이 등장했습니다. 바로 Flux와 ArgoCD입니다. Landbay는 배포, Helm 릴리스, Kustomization 등을 정의하기 위한 사용자 지정 리소스 정의(CRD)를 제공함으로써 Kubernetes와 기본적으로 통합할 수 있는 솔루션으로 Flux를 선택했습니다. 결과적으로 소프트웨어 엔지니어는 Kubernetes를 마스터할 수 있게 되었고, 이를 통해 Flux가 에코시스템 내에서 어떻게 적용되는지 더 원활하게 이해할 수 있게 되었습니다.

솔루션 개요

Landbay의 GitOps 구현을 포괄적으로 이해하기 위해 주요 아키텍처 구성 요소와 AWS 에코시스템 내에서의 관계를 살펴보겠습니다.

• Amazon Elastic Container Registry(ECR): Landbay는 Amazon ECR을 활용하여 헬름 차트와 Docker 이미지를 저장합니다.
• 외부 DNS 및 AWS Elastic Load Balancing 컨트롤러: 이들 컨트롤러는 Route53 및 로드 밸런서를 구성하여 Kubernetes 수신에 대한 외부 액세스를 보장하는 데 사용됩니다.
  
• AWS Secrets Manage 통합: 아키텍처 및 보안상의 이유로 Landbay는 외부 시크릿 컨트롤러와 같은 외부 도구를 사용하는 대신 AWS Secrets Manager와 직접 통합하는 방법을 선택했습니다. 이는 AWS의 공동 책임 모델에 부합하고 솔루션의 전반적인 보안 상태를 개선합니다.
  
• Terraform 구성 관리: Terraform은 ConfigMap을 제공하고 주요 구성 항목(엔드포인트, 서브넷 CIDR 등)을 요약하여 격차를 해소하는 데 사용할 수 있습니다. 그러면 Flux가 빌드 후 기능을 통해 ConfigMap을 사용할 수 있습니다(그림 2 참조).
  

Landbay의 Kubernetes 환경 및 데이터 아키텍처

Landbay는 Terraform을 적극적으로 채택하고 있으며 모든 인프라는 코드형 인프라(IAC)로 코드화되어 있습니다. 이 접근 방식은 테스트 및 프로덕션 환경 전반의 동기화를 보장하고 모든 인프라 변경이 표준 소프트웨어 개발 수명 주기 프로세스를 거치도록 합니다.

Amazon EKS 업그레이드 중에 가동 중지 시간을 없애기 위해 Landbay는 각각 특정 가용 영역을 대상으로 하는 관리형 노드 그룹 3개가 포함된 EKS 관리형 노드 그룹을 사용합니다. 이러한 구성을 통해 Amazon Elastic Block Store(EBS) CSI 드라이버가 지원하는 영구 볼륨을 사용할 수 있습니다. 또한 Landbay는 topologySpreadConstraints(DoNotSchedule)를 사용하여 스테이트풀 세트가 가용 영역 전체에 분산되도록 합니다.

중요 서비스의 경우 사용자 지정 우선 순위 클래스를 사용하여 우선 순위가 낮은 배포를 제거합니다.

테스트 환경에서 비용을 절감하기 위해 Landbay는 Terraform 및 Amazon EKS 관리형 노드 그룹을 통해 Amazon EC2 스팟 인스턴스의 이점을 활용합니다.

마지막으로 Landbay는 공격 표면을 크게 줄임으로써 Bottlerocket을 도입했습니다. 이 운영 체제의 Kubernetes 연산자는 웨이브 개념을 사용하여 클러스터의 노드를 점진적으로 업그레이드하는 데 사용됩니다. 루트 파일 시스템에 대한 액세스는 제한되어 있지만 IAM 및 Systems Manager(SSM)와의 통합은 Landbay의 기본 요구 사항을 충족합니다.

Amazon EKS 추가 기능

Landbay는 Amazon Virtual Private Cloud(Amazon VPC) CNI 플러그인 외에도 다음과 같은 추가 기능을 실행합니다.

1. CoreDNS: 클러스터 내에서 DNS 서비스 확인을 보장합니다.
2. KubeProxy: Kubernetes 내에서의 서비스 검색 및 네트워킹을 뒷받침합니다.
   
3. enableNetworkPolicy가 포함된 Amazon VPC CNI: Landbay가 네임스페이스 및 포드에 대한 다양한 액세스를 보호하는 데 도움이 되는 네트워크 정책을 적용할 수 있습니다.
   
4. Amazon EBS CSI 드라이버: 영구 볼륨을 사용할 수 있습니다.
   

액세스 관리 구성

Landbay는 AWS IAM Identity Center를 사용하여 AWS API에 대한 모든 액세스를 제어합니다. Amazon EKS를 사용하면 SSO 역할을 Kubernetes 그룹에 매핑할 수 있으므로 IT 관리자 팀을 통해 Azure Entra ID 그룹에 간접 매핑할 수 있습니다. 이러한 접근 방식을 통해 IT 관리 팀과 나머지 조직 구성원 간에 우려 사항을 분리할 수 있습니다.

그런 다음 위의 조각을 사용하여 kubernetes_config_map_v1-data aws_auth 리소스를 설정할 수 있다.

역할의 확산을 방지하기 위해 Kubernetes는 'aggregate-to-admin'을 사용하여 다른 Helm 릴리스의 권한을 기존 그룹으로 롤업하는 메커니즘을 제공합니다.

AWS Load Balancer Controller

Landbay는 서비스 간 통합을 강화하기 위해 AWS Load Balancer Controller(LBC)와 외부 DNS 컨트롤러를 활용했습니다.

AWS Load Balancer Controller를 사용하면 수신에서 직접 로드 밸런서를 프로비저닝할 수 있을 뿐만 아니라 외부에서 관리되는 로드 밸런서를 재사용하고 대상 포드를 할당할 수 있습니다. 로드 밸런서 프로비저닝을 별도의 프로젝트로 분리함으로써 DevOps 팀은 하나의 소스 코드 리포지토리에 대해 더 많은 권한을 가지면서도 대상을 관리하는 엔지니어에게 작업에 필요한 도구를 제공할 수 있습니다.

컨트롤러는 필요에 따라 로드 밸런서와 대상 사이의 백엔드에서 보안 그룹도 관리합니다. 또한 group.name 주석을 사용하면 백그라운드에서 동일한 로드 밸런서를 여러 대상 그룹과 공유할 수 있습니다.

Landbay는 AWS Load Balancer Controller를 사용하여 VPC 내에서 실행되는 AWS Lambda 함수를 EKS 인프라로 수신할 수 있도록 Network Load Balancer도 프로비저닝합니다.

이를 보완하는 외부 DNS 컨트롤러는 Kubernetes 포드에 Route53에 대한 제한된 쓰기 액세스를 허용합니다. 이 기능을 사용하면 친숙한 DNS 이름을 가진 외부 서비스가 자동으로 노출되므로 전반적인 사용자 경험이 향상됩니다.

보안 관점에서 볼 때 Application Load Balancer(ALB) 컨트롤러와 외부 DNS 컨트롤러에는 제한된 IAM 권한 집합이 필요하며, 이를 엄격하게 잠글 수 있습니다. 예를 들어 DNS 컨트롤러에는 특정 Route 53 영역(route53:ChangeResourceRecordSets)에 대한 쓰기 권한과 몇 가지 List 권한만 있으면 됩니다.

Kubernetes 내 시크릿 관리

대부분의 솔루션이 시크릿 교체 및 통합과 같은 시크릿 관리 관련 문제를 해결하지만, Kubernetes 시크릿 스토리지를 사용하거나 외부 시크릿을 Kubernetes에 동기화하면 시크릿이 Kubernetes의 기본 etcd에 일반 텍스트로 저장됩니다. EKS에서 '암호화된 시크릿’을 사용하면 물리적 공격 벡터를 완화하는 데 도움이 되지만, AWS의 공동 책임 모델에 따라 Kubernetes API를 통한 액세스는 시크릿의 원시 값을 노출할 수 있습니다.

AWS에서 제공하는 Container Storage Interface(CSI) 드라이버를 사용하면 이점을 얻을 수 있을 뿐만 아니라 아키텍처가 네이티브 Kubernetes 관리에서 벗어날 수 있습니다. CSI 드라이버와 외부 공급자 솔루션 모두 외부 시크릿 공급자와 직접 통합해야 한다는 점을 고려하여 Landbay는 마이크로서비스를 AWS Secret Manager에 직접 통합하기로 결정했습니다.

직접 통합 옵션을 사용하면 환경에 복잡성이 가중되어 유지 관리 및 지원 비용이 높아지는 것을 방지할 수 있습니다. 또한 컨테이너 볼륨에 일반 텍스트 암호가 존재하지 않도록 하여 보안이 더욱 강화됩니다.

AWS 환경에서 Flux 프로비저닝

Landbay가 선택한 GitOps 솔루션인 Flux는 EKS 클러스터를 부트스트랩할 수 있는 Terraform 공급자를 제공합니다. Flux는 구성 가능한 정기 간격으로 Git 리포지토리에 정의된 모든 Kubernetes 매니페스트가 Kubernetes에 배포된 기존 리소스와 조화를 이루도록 하여 감지된 드리프트를 되돌립니다. Flux가 부트스트랩되면 아래 그림과 같이 구성된 서비스, 포드, 스테이트풀 세트 등을 Kubernetes 클러스터에 설치하여 첫 번째 조정 작업을 수행할 수 있습니다.

ECR이 OCI 아티팩트에 대한 최고 수준의 지원을 제공하므로 Flux는 AWS Elastic Container Registry(ECR)를 Helm 리포지토리로 활용할 수 있습니다. 이를 통해 Flux가 Kustomization을 사용하여 환경별 구성을 적용하여 ECR과 EKS 사이의 접착제 역할을 할 수 있습니다.

이 접근 방식의 주요 이점 중 하나는 배포 파이프라인의 지속적 통합(CI) 부분(빌드, 테스트 및 패키지)과 지속적 배포(CD) 부분(환경으로 전달)을 논리적으로 분리한다는 것입니다. 보안 측면에서 Flux는 변경 사항을 가져오므로 일일 배포를 위해 액세스 권한을 상당히 제한할 수 있습니다. 배포 지연을 방지하기 위해 필요한 유일한 권한은 빌드 도구가 Flux에 조기 조정 '알림’을 제공하는 것뿐입니다. 이 작업은 제한된 사용자와 잠긴 kubeconfig를 통해 수행할 수 있습니다.

따라서 YAML 파일의 시맨틱 버전 관리(semver) 조각을 업데이트하거나 커밋을 되돌리는 것만큼 간단하게 새 마이크로서비스를 배포하거나, 되돌리거나, 승격할 수 있습니다. Flux는 Git 변경을 관찰하면 Kubernetes와의 조정을 트리거하고 관련 서비스를 적절히 업데이트합니다.

Flux 리포지토리 구조 및 공유 구성 요소

Flux는 권장 리포지토리 구조에 대한 포괄적인 문서를 제공합니다. Landbay의 접근 방식은 비교적 간단하며 이러한 모범 사례를 따릅니다.

클러스터 구성은 각각의 전용 폴더에 정의되며, 각 폴더는 공유 구성 요소를 참조합니다. 이러한 클러스터 폴더 내에서 Kustomization을 광범위하게 사용하면 클러스터 간의 격리가 보장됩니다. 이를 통해 버전 관리 및 메모리와 같은 환경별 구성이 가능합니다.

위에서 설명한 구조는 GitOps 패러다임의 선언적, 명시적 특성 유지와 코드 공유 사이의 균형을 유지하므로 엔지니어는 Git 리포지토리를 읽고 클러스터에 설치된 구성 요소, 버전 또는 패키지를 확인할 수 있습니다.

Landbay는 구성 요소를 격리하여 새 클러스터를 구축하는 프로세스를 간소화할 수 있습니다. 여기서부터 클러스터 구성은 ‘레고 블록’을 선택하여 환경별 구성으로 조립하는 문제가 됩니다.

또한 일부 클러스터는 클라우드에서 작동하고 추가 구성 요소가 필요하지만, 다른 클러스터는 로컬에서 작업하는 DevOps 엔지니어를 대상으로 할 수 있습니다. 이 로컬 개발 접근 방식은 더 빠른 피드백 루프를 제공하며 AWS 서비스와 직접 관련된 구성 요소를 포함하지 않습니다.

디딤돌로서의 로컬 개발

이 로컬 개발 접근 방식은 클라우드 기반 임시 개발 환경을 빠르게 배포하기 위한 디딤돌이기도 합니다. Landbay는 Kubernetes 네임스페이스를 사용하고 AWS 관리형 서비스에 대한 종속성을 제거함으로써 Flux를 사용하여 새로운 독립형 환경을 신속하게 부트스트랩할 수 있습니다.

이 경우 Landbay의 개발 환경은 Amazon Relational Database Service(RDS)를 단순한 MariaDB 컨테이너로 대체하고, Amazon OpenSearch Service를 동등한 OpenSearch 컨테이너로 대체할 수 있습니다. 이 접근 방식은 개발 환경을 아키텍처상 ‘단계’ 상태로 유지하지만(예: 유사한 네임스페이스, 서비스 검색, 네트워킹), 운영 복원력이 부족하다는 단점이 있습니다. 일부 개발 환경에서는 이를 수용할 수 있습니다.

EKS, GitOps 및 AWS 서비스 통합

Landbay에서 AWS 인프라는 전적으로 Terraform에 의해 관리됩니다. 따라서 Terraform에서 프로비저닝하는 요소(RDS, OpenSearch 등)와 클러스터 내에서 실행되는 다른 포드 간의 격차를 해소하는 것이 필수적입니다. 마이크로서비스에서 Kubernetes의 구성에 액세스하는 기본 방법은 ConfigMap을 사용하는 것입니다.

다음 다이어그램은 Terraform 프로젝트와 Flux 프로젝트의 상호 관계를 보여줍니다.

첫 번째 Terraform 프로젝트는 모든 기본 네트워킹, 인터넷 기반 로드 밸런서, AWS 관리 서비스를 설정하는 역할을 합니다. 두 번째 프로젝트는 EKS 클러스터를 구축하고, Flux를 클러스터로 부트스트랩하고, EKS 클러스터를 보호하고, 모든 IAM 역할을 설정하고, Bottlerocket을 실행하는 관리형 노드 그룹과 같은 하위 수준 문제를 관리합니다. 이 프로젝트는 AWS에 모든 환경 변수를 쿼리하고 이를 Kubernetes에 주입하는 environment ConfigMap을 생성합니다.

최종 프로젝트는 전용 Flux 프로젝트입니다. 이는 환경의 클러스터 구성을 정의하고, 공유 구성 요소 집합에 연결한 다음, 관련 환경에 맞게 Helm 릴리스 및 Kubernetes 매니페스트를 사용자 지정(kustomize)합니다. 그러면 environment ConfigMap을 Flux 리포지토리 내에서 Kustomization의 일부로 사용할 수 있습니다. 또한 Flux는 빌드 후 변수 대체 기능을 제공하므로 잘 정의된 다양한 bash 문자열 대체 함수와 함께 변수 대체를 사용할 수 있습니다.

예를 들어, 헬름 차트 내에서 값은 빌드 후 변수 대체를 사용할 수 있습니다. 아래 그림에서 볼 수 있듯이 이 접근 방식은 공유 구성 요소가 환경에 구애받지 않도록 GitOps 리포지토리를 개선합니다.

결론

Amazon EKS 및 더 광범위한 AWS 에코시스템과 긴밀하게 통합된 Flux를 통해 GitOps를 채택하기로 한 Landbay의 결정은 판도를 바꿀 수 있는 것으로 입증되었습니다. Landbay는 이러한 최첨단 접근 방식을 채택함으로써 운영을 간소화하고 보안 태세를 강화하는 수많은 이점을 얻었습니다. 아마도 가장 중요한 이점 중 하나는 전반적으로 엔지니어링 효율성을 실현할 수 있다는 점일 것입니다. 빠른 배포, 대기 시간 단축부터 서드 파티 솔루션의 원활한 활용에 이르기까지 GitOps와 EKS 및 AWS 서비스의 통합은 Landbay의 개발 프로세스를 혁신했습니다.

또한 Landbay의 보안 환경이 강화되어 보안이 한층 강력해지고 비용 효율적인 유지 관리가 가능해졌습니다. Landbay는 Bottlerocket을 활용하여 SCM/Git 권한을 통해 업무를 분장하고 Helm을 통해 손쉬운 업그레이드를 가능하게 함으로써 운영 비용을 최적화하는 동시에 보안에 대한 약속을 확고히 했습니다.

이 혁신적인 여정의 가장 큰 영향은 EKS 워크로드 상태 및 변경 사항의 가시성과 투명성이 향상되었다는 것입니다. GitOps에서는 구성이 YAML을 사용하여 선언되고 모든 수정 사항이 Git 커밋으로 저장됩니다. 이러한 패러다임 변화는 Landbay의 지원, 위험, 규정 준수 및 감사 팀에 상당한 이점을 가져다 주었고, 이로 인해 업무상 중요한 시스템에 대한 전례 없는 통찰력과 통제력을 확보할 수 있게 되었습니다.

Landbay와 같이 스타트업을 혁신할 준비가 되었다면 AWS Activate에 참여하여 배포 가능한 템플릿, AWS 크레딧 및 학습 기회를 활용하세요.