안녕하세요 스푼라디오에서 SRE 팀에서 DevOps업무를 담당하고 있는 Paul(백영진)이라고 합니다. SRE팀은 지난 5년 동안 AWS Multi-Account Multi-Region에서 서비스의 안정성과 확장성을 위한 인프라 자동화, CI/CD 배포 시스템, 로그 및 모니터링 시스템 구성하고 자동화를 진행 하였습니다.
스푼라디오 시스템은 infra 1.0 이라는 버전으로 위의 표와 같이 오픈소스를 기반으로 AWS 인프라부터 배포, 모니터링 구성까지 대부분을 코드 기반으로 구현을 했습니다. 하지만 시간이 지날수록 문제가 발생을 하였습니다.
- 스푼라디오 서비스는 글로벌 서비스로, 각 서비스 지역마다 상이한 인프라 구성을 갖추고 있습니다. 운영 관련 서비스는 AWS Multi-Account Multi-Region으로 각각 구성되어야 했습니다.
- AWS Multi-Account Multi-Region 환경에서는 AWS 인프라부터 배포 및 모니터링 구성까지 자동화되었지만, AWS 리소스에 대한 유지 보수 및 Maintenance 작업을 처리할 인력에 한계가 있었습니다. (AWS RDS, AWS ElastiCache, AWS ElasticSearch, etc..)
- 인프라 자동화를 위해 도입한 오픈소스 도구 또한 Maintenance에 문제가 발생했습니다. (Terraform, Ansible, AWX, Jenkins, etc..)
그 외에도 조직 내의 팀이 새로운 서비스 런칭할 경우 타 팀과 SRE팀 간의 조정이 필요했습니다. 병목 현상이 발생을 하는 문제점이 발생을 하였습니다.
스푼라디오 Infra 2.0 시스템 구성
3년간 유지한 Infra 1.0 시스템에 대한 팀 내 회고를 거쳐, 기존 시스템을 고도화할지 아니면 완전히 새로운 시스템을 구축할지에 대한 팀 내 논의가 이뤄졌습니다. 결국 오랜 논의 끝에 우리는 새로운 시스템을 구축하기로 결정했습니다
Infra 2.0 시스템은 기존 Infra 1.0 시스템에서 문제점을 개선 및보안 Compliance 준수하며, 클라우드 네이티브 시대의 개발 조직을 위한 셀프 서비스 기능을 지원하는 시스템을 구축 한다는 목표를 가지고 진행을 하였습니다. 또한 스푼라디오의 아키텍처 팀과 협업하여 레거시 시스템의 일부 서비스를 Infra 2.0 시스템으로 원활하게 이관하는 작업을 수행하면서 다양한 의견과 피드백을 통해 시스템을 지속적으로 개선할 수 있었습니다
1. 보안과 규정 준수 위한 OKTA 및 AWS Config 도입
스푼라디오 서비스는 AWS Multi-Account Multi-Region으로 16개의 계정을 보유하고 있습니다. 그러나 SRE팀은 개발팀이 요청한 리소스를 직접 생성하고 관리하는 데 인력 및 시간적인 제약이 있어 업무 병목이 발생할 수 있다고 판단했습니다. 따라서 개발팀이 직접 보안 규정을 준수하면서 리소스를 생성하고 관리할 수 있는 시스템으로 Okta 및 AWS Config를 도입하기로 결정했습니다.
Okta를 통한 Single Sign-On (SSO) 및 Multi-Factor Authentication (MFA)를 활용하여 개발팀은 AWS 리소스에 안전하게 엑세스할 수 있습니다. 각 그룹은 AWS IAM 정책에 따라 적절한 권한을 부여받아 안전하고 효율적으로 업무를 수행하고 있습니다. 또한 AWS Config의 다양한 정책을 활용하여 보안Compliance를 준수하고, AWS 리소스를 생성할 때는 Tag 정책을 적용하여 리소스의 가시성을 확보하고 인프라 비용을 효과적으로 산출할 수 있었습니다.
DEV/STG/PRD 환경은 분기별 Cleansing Day 통하여 불필요한 리소스를 삭제 하고 있으며, AWS Multi-Account Multi-Region 환경에서의 리소스에 대한 검색을 용이하게 하기 위해 Steampipe 시스템을 도입하여 효과적으로 검색이 가능하도록 했습니다.
2. Amazon EKS(Amazon Elastic Kubernetes Service)도입
2019년부터 2021년까지 스푼라디오 서비스는 Terraform을 기반으로 한 IaC를 통해 인프라를 구성하도록 마이그레이션 작업을 완료 하였습니다. 하지만 서비스의 복잡성 증가 및 Terraform 모듈 버전 관리에 한계를 느끼게 되었습니다. (5개 국가를 동일한 환경을 프로비저닝 작업 반복..)
Infra 2.0에서는 인프라의 확장성 및 MSA(MircroService Architecture) 설계에 최적화된 시스템이 필요하다 판단하여 Amazon EKS를 도입하게 되었습니다.
EKS의 노드 그룹은 서비스 특성에 따라 CPU 및 메모리 최적화를 고려하여 구성되었으며, 서비스 안정성을 고려하여 Spot 및 On-Demand 인스턴스를 혼합하여 사용했습니다. 또한, EKS 클러스터의 비용을 효율적으로 관리하기 위해 Horizontal Pod Autoscaler(HPA) 및 Cluster Autoscaler(CA)를 도입하였습니다.
하지만 Cluster Autoscaler(CA)는 리소스 부족 상태를 감지하고 자원을 추가로 프로비저닝하는 데에 많은 시간이 필요 했습니다. 이로 인해 일시적으로 리소스 부족 현상이 발생할 수 있습니다. Horizontal Pod Autoscaler(HPA)는 경우도 스케일 기반에 대한 지표 설정이 한계가 있고, 애플리케이션의 특성을 이해하고 튜닝 및 테스트가 필요했습니다.
그래서 Node Autoscaler를 위한 AWS 오픈소스로 제공하는 Karpenter 와 Pod Autoscaler를 위해서 Kuberentes Event Drivent Autoscaler 인 KEDA 기술 검토를 진행하고 있습니다. Karpenter의 경우는 Data 분석 환경에 적용하여 현재 테스트 중에 있고, 문제가 없다면 점진적으로 적용 예정입니다.
3. GitOps 통한 CI(Continuous Integration) 환경 구성
Infra1.0 시스템에서는 Jenkins 기반의 CI 시스템을 구성했습니다. 그러나 Infra2.0 시스템에서는 Bitbucket Pipeline을 적극적으로 도입하여 코드 변경에 대한 자동 빌드 및 테스트로 높은 코드 품질과 안정성을 유지했습니다. Bitbucket Pipeline을 구성하는 데에는 간편한 YAML 파일을 활용하여 CI 파이프라인을 쉽게 구성하고 관리할 수 있었습니다. 또한, 컨테이너화된 애플리케이션을 지원하기 위해 도커 이미지는 안전하게 Harbor 시스템에 저장되었으며, Harbor Replication 기능을 통해 ECR로 복제하거나, Bitbucket OIDC(OpenID Connect) 기능을 활용하여 빌드 결과물을 직접 AWS S3에 업로드할 수 있었습니다.
Bitbucket Runners 활용하여 Multi Architecture 기반의 도커 이미지 빌드 환경을 구성해서 x86, ARM 다양한 환경에서 어플리케이션을 실행하거나 배포할 수 있도록 하였습니다.
4. Spinnaker 통한 CD(Continuous Delivery) 환경 구성
GitOps 를 통한 배포하는 방식이 아닌 Spinnaker 통해서 배포하는 방식을 채택하였습니다. Argo CD와 같은 다른 배포 시스템도 검토했지만, 기존의 레거시 시스템을 고려해야 했습니다. 또한 Spinnaker는 AWS 클라우드 환경에서 다양한 배포 방식(EC2, ECS, Lambda, EKS)을 지원하며, Blue/Green 배포, 롤링 업데이트, 카나리아 배포와 같은 다양한 배포 전략을 제공하기 있기 때문에 Spinnaker 도입을 결정했습니다.
Spinnaker를 활용하여 EKS로 배포할 때 Helm Chart를 기반으로 사용했습니다. 처음에는 다양한 배포 전략을 적용했지만, 결국 롤링 업데이트 전략만으로도 무중단 배포에 문제가 없다고 판단하여 모든 서비스를 이 방식으로 전환했습니다. 이와 함께 Helm Chart도 하나의 통합된 차트로 관리하게 되었습니다.
5. Observability 환경 구성
AWS Multi-Account Multi-Region 클라우드 네이티브 워크로드 및 마이크로서비스에 대한 Observability를 강화하기 위해 다양한 오픈소스 및 상용 솔루션을 검토했습니다. Infra 2.0 시스템 위에 구축된 어플리케이션 아키텍처는 Kafka 기반의 EDM(Event Driven Microservice) 서비스로 개발되어, 메트릭 수집 뿐만 아니라 분산 추적(Distributed tracing)과 로깅(Log)에서의 원활한 지원이 필요 했으며, 특히 누구나 쉽게 모니터링 대시보드를 구성하고, 알림 설정할 수 있는 시스템이 필요했습니다. 이에 상용 서비스인 Datadog를 도입하게 되었습니다.
Datadog의 Metric, Trace, Logs 정보를 수집하고, Datadog에서 제공하는 서비스를 활용하여 서비스의 Observability를 확보해 나갈 수 있었습니다. 아래 내용은 2023년 뉴욕에서 개최된 DASH 행사에서 ‘스푼라디오의 글로벌 스트리밍 서비스 모니터링 노하우’라는 주제로 DBA/DEV/SRE 관점에서 발표를 했습니다.
6. 로그 및 에러 수집 시스템
AWS Multi-Account Multi-Region의 EKS Cluster의 Pod 내 로그를 중앙화된 로그 수집을 통해 수집해야 했습니다. 처음에는 Datadog의 로그 수집을 통해 Observability를 확보하려 했으나, 로그 수집으로 인한 AWS 네트워크 아웃 비용 및 Datadog 저장 비용이 상당히 증가했습니다. Datadog에서 최적화를 시도했지만, APM 및 Trace 비용을 초과하는 높은 비용이 발생했습니다.
Pod 로그를 실시간으로 간편하게 확인하며 최소 2주 정도의 로그 데이터를 보관하고 쉽게 검색할 수 있다면 문제가 없다고 판단했습니다. 이에 EKS의 FluentBit을 DaemonSet으로 구성하고 해당 Pod의 로그를 Kinesis Firehose로 전송하여 Kinesis에서 OpenSearch 및 S3에 로그를 저장하도록 구성했습니다. AWS Multi-Account Multi-Region EKS Cluster를 효과적으로 관리하고 Pod 로그를 실시간으로 확인할 수 있는 Kubersphere를 도입했습니다.
7. 내부 교육
옛 속담처럼 ‘구슬이 서 말이라도 꿰어야 보배다’와 같이, 좋고 효율적인 시스템이라도 개발팀이 잘 사용하고 이해해야 그 가치가 발휘된다고 생각했습니다. 이에 따라 Infra 2.0 시스템을 구성하는 과정에서 개발팀과 여러 번 업무 협의를 진행했으며, 시스템이 완성된 후에도 내부 개발팀이 효율적으로 활용할 수 있도록 사용 가이드를 작성하고 교육(Offline, Online)을 진행했습니다. 교육과 실제 사용을 통해 다양한 피드백을 수렴하며 시스템을 더욱 개선할 수 있었습니다.
마무리하며
Infra 2.0 시스템의 도입으로, 개발팀은 주도적으로 개발부터 빌드, 테스트, 배포, 그리고 모니터링까지의 작업을 수행할 수 있는 셀프 서비스 환경을 구축했습니다. 이를 통해 개발팀은 업무를 효율적으로 수행할 수 있게 되었고, 동시에 SRE 팀도 기존의 업무 개선을 통해 다른 작업에 집중할 여유 시간을 확보할 수 있었습니다.
또한, Infra 2.0 시스템이 도입된 지 2년이 지났지만, 아직 개선해야 할 부분이 많습니다. 이러한 과정에서 개발팀의 협업이 없었다면 좋은 결과를 이뤄내지 못했을 것으로 생각합니다. Infra 2.0 시스템을 개발하고 도와주신 모든 분들께 감사의 말씀을 전하고 싶습니다.
