개요
최근 사내에서 엄청난 격변의 시기가 지속되고 있습니다. 인프라 개선부터 기술 스택, 보안, 추후 방향성에 대한 수많은 고민들이 눈앞에 다가오게 되었습니다. 그러던 중 사내 슬랙에서 AWS 컨퍼런스가 있다는 것을 알게 되었고, 현재 겪고 있는 문제에 대한 인사이트를 얻을 수 있을 것이라고 판단하였습니다.
그렇게, AWS Unicorn Day 2024에 방문하여 세션을 경험하며 어떤 인사이트를 얻었는지에 대해 이야기해볼까 합니다.
AWS Unicorn Day 2024
AWS Unicorn Day 2024는 다른 넥슨의 NDC나 네이버의 DEVIEW와 달리 모든 세션을 시간마다 선택하는 것이 아니라, 한개의 Track에 있는 모든 세션을 계속 듣도록 구성되었습니다.
저는 여러 트랙 중에서 현재 가장 많은 시간을 투자하고 있는 Container, EKS 환경에 대해서 많은 인사이트를 얻고 싶었기 때문에 “AWS에서 컨테이너를 운영한다면? + 파트너와 함께 성장하기” 트랙을 선택하였습니다.
Key Note
Keynote 트랙은 AWS와 이번 컨퍼런스의 스폰서로 참여한 각 회사들의 사례를 발표하는 것으로 시작하였습니다. 기술적인 인사이트 뿐만 아니라, 전략, 성장 이야기와 같은 다양한 내용에 대한 세션을 진행하는 것으로 컨퍼런스의 시작을 알렸습니다.
컨퍼런스장에 도착한 후 처음에는 여러 스폰서 부스들을 돌아다니느라 몇개의 세션을 듣지 못하였고, 가장 먼저 트레블월렛의 세션을 듣게 되었습니다.
AWS와 클라우드 여정을 함께하고 있는 '트레블월렛' 사례를 통한 기술 혁신 인사이트
해당 세션은 비즈니스적인 측면에서 발생한 문제점과 해당 문제점을 AWS를 통해 어떻게 개선하였는지에 대한 내용을 바탕으로 진행되었습니다.
사내의 모든 인프라를 On-Premise에서 Cloud 환경으로 마이그레이션한 것과 함께 Infra Architecture에 대한 개선 사항을 어떻게 진행하였는지 정리했던 것이 가장 기억에 남았습니다.
Infra Architecture 개선 사항
- Compute: EKS → Multi Cluster 환경으로 구성
- Monitoring: ELK 기반 모니터링
- Cloud Watch Alaram → Slack Bot으로 이슈 연결
- Network: AWS DX(Direct Connect), VPN을 이용한 B2B 연결
- Network: Multi VPC 환경으로 구성 → 국제 표준 인증인 PCICC 를 위해
- Integragion: Visa Cloud Connect(VCC) 기반 Processing 사업 확장
- Ochestration: AWS Support Plan으로 관리적 측면 향상
- Security: AWS DDoS 대응 Best Practices 적용
- Network: VCC 와 Third Party, Private Link를 이용하여 해결
- Dependency: 서비스 운영 의존성 해결 및 B2B 사업 의존성 해결
아임웹의 고도화된 트래픽 관리: AWS를 이용한 70만 고객 사이트 지원 전략
해당 세션은 아임웹이라는 서비스가 어떤 과정을 통해 발전되었으며, 아키텍처가 어떻게 변화하게 되었는지에 대한 세션이었습니다. 주로, 트래픽이 많이 발생하게 되었을 때 어떤 인프라에서 문제가 발생하게 되었는지, 그리고 그 문제점을 어떻게 개선했는지에 대한 내용이 많았습니다.
개인적으로, KeyNote 세션 중에서 가장 많은 기술적 인사이트를 얻었던 세션인 것 같습니다. 고객들이 동일한 아임웹 서비스 내에서 서로 DDoS를 주고받는다는 어처구니 없는 상황이 발생할 수 있다는 것을 알게 되기도 했습니다. 😅
인프라 아키텍처 개선 순서도
- WAF 추가
- DDoS는 줄일 수 있었음. → 하지만, 실제 트래픽이 차단되는 문제가 발생
- Cloud Front의 비 로그인 유저 캐싱
- 비로그인 유저 Cashing으로 50% Origin 트래픽이 감소하게 됨 → 하지만, 주문 폭증 시 장애가 발생
- ECS + Fargate로 Compute 개선
- 느린 Autoscaling → 빠른 Autoscaling (Container) → 하지만, DB의 문제가 발생
- Aurora 3 + Serverless + Mixed Cluster
- Aurora 3로 Serverless, DB도 빠른 Autoscaling으로 해결 → 하지만, 빅 이벤트에는 장애가 전파
- 자동 트래픽 격리 시스템 추가
- 자체 개발 트래픽 격리 시스템 (Tenancy 분리) 추가 → 하지만, ECS 만으로는 격리가 너무 불편
- EKS 환경으로 마이그레이션이 필수적이었다.
Track 2
점심을 먹은 후 오후 시간에는 이번 컨퍼런스에서 가장 중요한 기술적인 인사이트를 얻을 수 있는 Track 시간입니다. Track 2 세션들을 컨테이너에 대한 내용이 주를 이루고 있었으며, MSP 회사들의 사례를 기반으로 파트너사와 어떻게 성장하는지에 대한 세션이 준비되어 있었습니다.
이번 Track 2 세션을 모두 들었지만 개인적으로 가장 인상깊었던 몇가지의 세션만 아래의 정리하도록 하겠습니다.
AWS 보안 서비스를 이용하여 안전한 컨테이너 운영환경 만들기
AWS의 솔루션 아키텍트 분들이 진행하였으며, 현재 사내에서 가장 중점적으로 고민하고 있는 보안적인 측면에 대해 상세한 원칙과 해결 방안에 대해 중점적으로 진행한 세션입니다.
🔥컨테이너 보안 원칙
- 최소 권한 원칙
- 데이터 전송 및 저장 시 데이터 보호(암호화) 원칙
- 모든 계층(Layer)에서 효율적인 보안 체계 적용
- Multi Account Architecture 수립
- 하나의 Workload의 문제가 다른 Workload에 피해가 전달되지 않도록 구성
- 중앙 집중식 Log Archive Account 수립
- 시간 절약 및 위험 감소화를 위한 자동화
- 패턴화된 문제점을 해결하기 위한 자동화를 구성
- 하지만, 자동화는 처음이 아닌 해당 문제점의 시간 대비 효율이 발생한 시점에 도입 고려
🔥컨테이너 호스트 보안
- 컨테이너에 실행된 최적화 OS 사용
- ECS/EKS에 최적화된 AMI, Bottlerocket AMI 도입
- K8S CIS benchmark 준수 여부를 주기적으로 확인
- Private Subnet에 Work Node 배포
- Work Node의 주기적인 교체 자동화
- Host 접근 최소화 및 감사
- SSM의 Session Manager 사용 고려
- SSH 접근과 Keypair 필요성 제거
- Worker Nodes 를 immutable(불변) 처리
ECR Image
- ECR의 Scan on Push를 하면, 컨테이너 이미지의 취약점을 검사할 수 있다.
- ECR의 Basic은 추가 비용이 존재하지 않으므로, 검토 필요
- inspector - 고급 스캔은 취약점 스캔까지 가능 (유료)
- 지속적으로 CV가 된 상황을 가정하여 스캔을 진행함
- 이미지 Push 시
--image-tag-mutability IMMUTABLE속성을 사용하는 것을 권장 - Container Image Life Cycle 관리
트래블월렛의 EKS 전환 여정
이번 컨퍼런스에서 가장 많은 인사이트를 얻은 세션이었습니다. 현재 Legacy 환경의 사내 인프라를 EKS 마이그레이션하는 과정 중에 있는데, 해당 세션에서는 과거에 겪었던 문제점을 EKS로 마이그레이션하면서 겪었던 문제점들을 순차적으로 발표하였습니다.
🔥트레블 월렛 서비스의 초기 EKS 구축
- EKS를 NodeGroup으로 분류하여,
Dev및ProdVPC로 구성함 - Namespace 마다 NLB(IP 고정 목적), ALB(Ingress Controller) 구성
- → ALB(WAF, Ingress Controller)
- 서비스별 Namespace 격리 → 파트너사 별 Namespace 격리
🔥Multi Cluster 확장의 문제점 (1)
Management Tool의 증가
- EKS 추가 구축 시 Management Tool 들도 같이 늘어나는 문제점
- Grafana, ArgoCD 관리의 어려움이 발생
- 해결하기 위해, Management EKS 별도 구축
- 나중에 EKS가 늘어나도 Grafana, ArgoCD는 늘어나지 않음
🔥Multi Cluster 확장의 문제점 (2)
- ELB 운영 이슈
- EKS, Namespace 추가 시 NLB, ALB가 같이 추가됨
- NLB, ALB 자원 및 운영 비용 증가
- Security Group 운영 이슈
- 너무 많은 보안 정책들
/24,/32 - 버전 관리가 안됨 (IaC 사용 안함)
- 너무 많은 보안 정책들
- 트래픽 제어의 어려움 (Canary 배포)
- Canary Pod가 원하는 비율만큼 트래픽을 받기 어려움
- 그렇다고 Pod 수를 늘리는 것은 리소스 낭비 (현재 4개로 운영 중)
- istio 도입
- 어플리케이션 네트워크 기능을 유연하고 쉽게 자동화할 수 있는 서비스 메시 플랫폼
- ELB & Securithy Group 관리 해결
- ALB 통합
- Security Group
/24,/32→any /24,/32보안 정책 관리 및 GitOps를 통합 버전 관리
- 트래픽 제어 해결 (Canary 배포)
- Pod 수를 늘리지 않고 해결
🔥Multi Cluster 확장의 문제점 (3)
EKS 버전 이슈
- 평균 4개월 한 번씩, 새로운 Kuberenetes 마이너 버전이 릴리즈됨
- EKS 는 최초 릴리즈 이후 총 26개월까지 지원한다.
- 강제 업그레이드 전에 무중단 버전 업그레이드가 필요함.
- 정식 지원 기간(12개월)마다 업데이트하는 정책 구현
- EKS 이중화
- 신규 버전의 EKS 구축
- 기존 EKS와 동일 환경 구축 (GitOps)
- 해결 방안
- ALB를 통해 EKS 트래픽 조절
- 신규버전 EKS Role 트래픽 변경 → (구버전 EKS의 트래픽 제거)
- 트래픽 제거가 확인된 이후에 신규 버전으로 업그레이드
- 트래픽 50%, 50%로 변경 및 Resource (EC2, Pod 등)도 균등하게 나눔
- Prod 환경에서 작업시 트래픽을 완전 제거하여 안전한 작업이 가능하게 구성함
에필로그
이번 컨퍼런스에 참가하면서 백엔드 개발자로 커리어를 변화하기 위한 시기에 컨퍼런스를 듣고 정리하던 여러 게시글들이 떠올랐습니다. 그당시에는 컨퍼런스에서 발표하는 내용들에 대해 명확하게 이해를 하는 것 보단, 알지못하던 지식을 하나씩 정리하는 것에 가까웠습니다. 하지만, 이번 컨퍼런스에서는 “이미 알고 있는 지식을 어떻게 더욱 향상시킬 수 있을까?”에 가까웠습니다.
과거에 비해 시간이 많이 지나기도 했고, 백엔드 개발자로써 커리어를 쌓아나간지 2년이 지났다는 것을 느끼게 되었습니다. 하지만, 아직까지 부족한 점도 많은 것을 깨달았고, 여러 회사에서 맞닿은 문제점을 어떻게 헤쳐나갔는지에 대해 알 수 있었던 것이 너무 좋은 경험이었습니다.
다음에도 컨퍼런스를 방문할 수 있는 기회가 있다면, 적극적으로 참여하고 싶습니다.
