결제플랫폼 구축에 EKS on Fargate 적용하기
10편 - AWS에서 MSA 서비스 구축하기
AWS에서 MSA 서비스 구축하기
티맵모빌리티가 출범한 이후 새로운 서비스들이 속속 개발되고 있습니다. 새로 개발되는 서비스들은 AWS 상에서 운영되고 있고, 티맵결제 또한 AWS 상에 구축되어 운영되고 있습니다. 처음 티맵결제를 위한 결제플랫폼을 구축할 때 아래와 같은 고민을 가지고 있었습니다.
새로운 기술을 써보고 싶은데 어떤 것이 좋을까?
Devops가 없는데 인프라에 대한 관리는 어떻게 하지?
AWS는 처음인데 어떻게 이용해야 할까?
서버에 대한 관리는 최대한 줄이고 싶다.
여러 고민을 거듭한 끝에 AWS EKS on Fargate를 도입하게 되었는데요. 티맵결제에서는 어떻게 EKS on Fargate 환경을 구축하였는지 소개하도록 하겠습니다.
Chap 1. EKS on Fargate란?
1-1. EKS on Fargate란?
EKS(Elastic Kubernetes Service)는 AWS에서 제공하고 있는 관리형 쿠버네티스 서비스의 명칭입니다. 쿠버네티스의 어플리케이션 최소 단위는 Pod인데, EKS에서 Pod를 배포하는 방법은 3가지(EKS 관리형 노드 그룹, 자체관리형 노드, AWS Fargate)가 있고, 여러 방법을 혼용하여 사용할 수 있습니다. 각 방식의 차이점은 AWS 매뉴얼(Amazon EKS 노드)에서 확인할 수 있습니다.
AWS Fargate는 컨테이너에 적정 규모의 온디맨드 컴퓨팅 용량을 제공하는 기술입니다. AWS Fargate를 이용하면 별도 서버를 구축하지 않아도 되고 EC2 인스턴스 등을 관리할 필요가 없습니다. 쿠버네티스의 Pod를 실행시킬때, Pod의 CPU와 메모리를 설정하기만 하면 그 자체로 하나의 EC2 인스턴스가 만들어지게 됩니다.
위와 같이 설정하는 것만으로, CPU가 2vCPU이고 메모리가 4GB 인 노드가 생성되고, 그 안에 하나의 Pod 가 실행됩니다. 이렇게 생성된 노드는 Pod가 종료될 때, 함께 삭제됩니다. 이와 같이 Fargate를 이용하면 서비스를 구축하기 위해 EC2 인스턴스를 관리하지 않아도 되어 서버리스 환경을 만들 수 있습니다.
1-2. Fargate를 이용할때 얻을 수 있는 장점
Fargate를 이용함으로써 여러가지 이점을 얻을 수 있었습니다.
Pod를 배포하면 그대로 EC2가 생성되므로 EC2를 따로 생성해서 관리할 필요가 없습니다. 애플리케이션의 버전을 올려서 다시 배포할 때에도 하나의 VM이나 Node에 추가로 배포하는 것이 아니라 새로운 EC2가 생성됩니다. 그리고 이제 역할이 끝난 구 버전의 애플리케이션이 올라가 있던 Pod는 EC2와 함께 종료되고 삭제됩니다. 이런 특징은 EKS를 업그레이드할 때 이점으로 작용하는데, Node와 Pod가 동일한 lifecycle을 갖기 때문에 재배포를 수행하는 것만으로도 신규버전이 적용된 Node를 갖게 되는 이점이 생깁니다.
앞서 설명한 것과 같이 Fargate는 VM 안에 하나의 Pod만 구동 시킵니다. 그래서 컨테이너화 된 애플리케이션을 이용해 다른 Pod에서 사용하는 호스트기반 리소스에 액세스 하는 형태의 공격에 안전합니다.
또한 클러스터의 autoscaling을 cli를 통해 쉽게 설정할 수 있습니다. cli를 통해서 최소 Pod 수, 최대 Pod 수, 그리고 Pod가 늘어나는 조건을 설정할 수 있습니다. autoscaling에 대한 내용은 관련내용은 아래에 자세히 설명이 있습니다.
1-3. Fargate를 이용할 때 겪는 단점
AWS 매뉴얼(Fargate 포드 구성)에서 확인할 수 있듯이 Fargate에서 실행되는 Pod의 vCPU 및 메모리의 조합이 정해져 있습니다. 예를 들어, 최대 4vCPU에서 메모리는 8GB~30GB까지 사용할 수 있습니다. 위 사양으로 일반적인 애플리케이션을 구동하는데 큰 문제는 없지만 CPU를 많이 필요로 하는 애플리케이션에서는 다른 대안을 찾아야 합니다. CPU를 많이 사용하는 애플리케이션이라면 NodeGroup을 이용하거나 단일 EC2를 이용하여 구동시키는 것을 고려해 보는 것이 좋습니다.
Fargate는 데몬셋을 지원하지 않습니다. 데몬셋은 클러스터 전체에 Pod를 띄울 때 사용하는 컨트롤러입니다. 예를 들면 모니터링을 위한 로그 수집 Pod를 모든 Node에 구동시키려고 할 때 데몬셋을 이용할 수 있습니다. 하지만 Fargate에서는 데몬셋을 이용할 수 없기 때문에 사이드카 형태로 하나의 Pod에 2개의 컨테이너를 올려서 로그를 수집해야 합니다. 이렇게 되는 경우 2개의 컨테이너가 사용하는 vCPU, 메모리의 총 합은 위에 언급한 리소스 한계를 넘길 수 없습니다.
위에서 EKS on Fargate의 장점과 단점을 알아보았습니다. Fargate의 단점은 수용가능한 부분이고, 장점이 훨씬 크다고 판단하여 티맵결제에 EKS on Fargate를 도입하기로 결정했습니다.
Chap 2. EKS on Fargate 구축 과정
그러면 이제부터 티맵결제에서 EKS on Fargate에 서비스를 구축한 과정을 함께 살펴보겠습니다.
2-1. VPC 생성
VPC는 TMAP에서 사용하는 기본형태를 사용하였습니다.
2-2. EKS Fargate 클러스터 생성
아래와 같이 eksctl 명령어를 사용하고 --fargate 옵션을 추가하여 fargate cluster를 생성하였습니다. 채택한 버전은 1.18 이었습니다. AWS 매뉴얼(Amazon EKS Kubernetes 버전)에 따르면 새로운 쿠버네티스 마이너버전 (예: 1.21)을 약 3개월마다 릴리즈 하고 12개월 동안 지원이 됩니다. 그래서 신규로 설치할때는 최신버전을 계속 따라가는 것이 좋습니다.
추가적인 EKS 설정은 AWS 매뉴얼(Amazon EKS란 무엇입니까?)에서 설명서를 확인하여 설치하는 것을 권장합니다.
2-3. 클러스터에 대한 IAM OIDC 공급자 생성
서비스 계정에 IAM 역할을 사용하려면 클러스터에 IAM OIDC 공급자가 있어야합니다. IAM 역할은 Kubernates 서비스 계정에 연결할 수 있고 이 서비스 계정을 사용하는 모든 포드에 있는 컨테이너에 AWS 권한을 제공할 수 있습니다. 자세한 설명은 AWS 매뉴얼(서비스 계정에 대한 IAM 역할)을 참고하세요.
2-4. ALB IAM Policy 생성
AWS LoadBalancer Controller는 worker node에서 실행되므로 IAM 권한을 통해 AWS ALB리소스에 액세스합니다. IAM권한은 ServiceAccount에 대한 IAM 역할을 통해 설정하거나 worker node IAM역할에 직접 연결할 수 있습니다.
AWS LoadBalancer Controller IAM 정책을 다운로드 받아서 IAM 정책을 생성합니다. 이때 정책 버전이 쿠버네티스 버전과 적합한지 확인이 필요합니다. 구축 당시 하위 버전의 정책을 생성하고 상위 버전의 쿠버네티스 사용으로 ALB의 오류를 경험했던 기억이 있습니다.
쿠버네티스 버전 요구사항은 아래와 같습니다.
AWS LoadBalancer Controller v2.0.0 ~ v2.1.3 requires Kubernetes 1.15+
AWS LoadBalancer Controller v2.2.0+ requires Kubernetes 1.16+
2-5. AIM 역할 및 ServiceAccount 생성 및 정책 연결
AWS LoadBalancer Controller에 대한 IAM 역할 및 ServiceAccount를 생성하고 위에서 생성한 IAM 정책의 ARN을 사용합니다.
2-6. 생성된 IAM ServiceAccount 확인
아래와 같이 aws-load-balancer-controller가 확인된다면 문제없이 잘 생성된 것입니다.
2-7. AWS Load Balancer Controller 설치
이제 모든 준비가 되었으므로 ALB Controller를 helm chart를 이용해서 미리 생성한 클러스터에 설치해 보겠습니다.
결과 로그를 확인합니다. 오류가 발견되지 않았다면 AWS Load Balancer Controller의 설치는 모두 끝났습니다.
2-8. 서브넷 태그 설정의 중요성
EKS Cluster를 Fargate로 생성시 서브넷을 지정하지 않으면 자동으로 생성되며 태그가 설정됩니다. 그러나 미리 생성한 private 또는 public 서브넷을 사용하여 생성할 경우 수동으로 ALB 사용을 위한 태그를 설정해야 합니다.
아래와 같은 오류를 발견했다면 서브넷 태그를 설정하세요.
public subnet
private subnet
2-9. Fargate autoscale 설정하기
autoscale를 사용하려면 우선 메트릭 서버를 해당 클러스터에 설치해야 합니다. 메트릭 서버와 관련된 내용은 깃허브(metrics-server)를 참고하면 됩니다. 메트릭 서버는 클러스터 전역에서 CPU와 메모리 같은 리소스 사용량데이터를 집계합니다. 여기서 수집된 데이터를 기반으로 autoscale을 동작시키게 됩니다.
메트릭 서버를 설치했으면 다음 명령어로 autoscale을 설정할 수 있습니다.
이 명령어로 해당 deployment는 배포될때, 최소 Pod 3개에서 5개까지 배포가 되며, CPU 사용률이 50%가 넘을때마다 Pod가 하나씩 늘어납니다.
2-10. 배포테스트
테스트1
위 그림은 min 10, max 20, replicas는 8로 설정하고 부하를 주는 동안 배포테스트를 진행한 것입니다. 부하를 받아서 Pod의 replica가 14까지 늘어난 상태에서 배포를 진행하게 했습니다. 배포를 진행하는 순간 Pod는 8개로 줄어들고 배포가 진행되었습니다.
테스트2
그 다음에는 같은 설정에 Pod의 replicas를 설정하지 않고 부하를 받는 중에 배포를 진행했습니다. 배포가 시작되면서 Pod는 1개로 줄어들었습니다. 이렇게 설정해서 테스트를 한 이유는 replicas를 설정하지 않으면 기존에 생성되어 있던 Pod를 기준으로 배포가 진행되지 않을까 하는 기대감으로 테스트를 했습니다. 하지만 결과는 1로 설정된 것과 동일하게 동작을 하였습니다.
테스트3
마지막으로 min은 1, replicas는 10으로 설정하였습니다. 테스트3은 테스트1,2와 다르게 부하가 없을때 진행되었습니다. 배포가 진행되는 순간 replicas에 설정된 숫자만큼 Pod가 생성대기하다가 부하에 맞추어 모두 종료되고 최종적으로 필요한 수만큼 Pod가 남게 됩니다.
서비스를 운영하다보면 많은 트래픽을 받고 있는 중에 배포를 해야 하는 경우가 생깁니다. 그런 경우 Pod 수가 줄어들어 트래픽을 처리하지 못하는 상황을 방지하기 위하여 max와 replicas의 숫자를 맞추어 설정하는 것이 좋습니다. 그렇게 되면 부하상황에도 Pod가 갑자기 줄어들지 않고 안정적으로 배포를 진행할 수 있게 됩니다.
2-11. Datadog 연동하기
Datadog 매뉴얼(Amazon EKS on AWS Fargate)에 있는 문서를 기준으로 연동하였습니다. Fargate에서는 데이터를 수집하기 위해서 우선 RBAC 설정을 합니다. 그 후 Datadog Agent를 사이드카 형태로 Pod에 포함하여 배포를 해야 합니다. 그 형태는 아래에 있는 형태로 매니페스트를 작성할 수 있습니다.
위 매니페스트에서 볼 수 있듯이 컨테이너에 2개의 이미지를 읽어서 구동 시키도록 설정되어 있습니다. 그리고, 두 리소스의 CPU 자원의 총합이 4vCPU를 넘어가지 않도록 설정하였습니다. RBAC설정할때 생성했던 datadog-agent 계정을 이용할 수 있도록 Pod에도 설정을 하였습니다.
EKS on Fargate에 Datadog을 연동하여 로그를 확인하려면 다음과 같은 절차를 거쳐서 확인할 수 있습니다.
1.Pod의 로그를 CloudWatch로 전송한다.
2.Lambda를 이용하여 CloudWatch의 로그를 Datadog으로 전송한다.
Fargate에 배포된 Pod의 로그는 stdout으로만 내보낼 수 있습니다. 그렇게 출력되는 로그를 cloudwatch로 보내기 위하여 로그라우터를 구성하여 쿠버네티스에 적용합니다. 방법은 AWS 매뉴얼(Fargate 로깅)을 참고하여 진행하면됩니다. 그리고 CloudWatch의 로그를 Datadog으로 전송하는 법은 Datadog 매뉴얼(Datadog Forwarder)을 참고하여 CloudFormation을 이용하여 진행했습니다.
애플리케이션 로그를 CloudWatch에서 확인하면 기존에 파일로 쓰는 것과는 형식이 달라서 조회하기 어려울 것입니다. 그래서 다음 두가지 방법을 적용했습니다. 우선 애플리케이션에서 net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder 를 이용하여 로그를 json으로 출력했습니다. 다음으로 router에서 필요없는 항목을 조정하여 실제로 애플리케이션에서 출력한 로그만 사용할 수 있도록 했습니다.
아래와 같이 파서와 필터를 구성했습니다.
그 결과로 Datadog에서 다음과 같이 로그를 확인할 수 있습니다.
마치며
지금까지 티맵결제에서 EKS on Fargate 를 도입하게 된 배경과 구축 과정을 살펴보았습니다.
티맵결제는 2021년 오픈한 이후 티맵 여러 서비스의 결제 관련 부분을 담당하고 있습니다. 출시 한지 얼마 되지 않아 아직 개선해야할 점이 많이 있지만, 더욱 안전하고 편리한 결제 서비스를 만들기 위해 최선을 다하겠습니다. 앞으로도 티맵결제에 대한 많은 이용, 관심, 사랑을 부탁드립니다. 감사합니다.
