Photo by Mukuko Studio on Unsplash안녕하세요 스푼라디오에서 SRE 팀에서 DevOps업무를 담당하고 있는 Paul(백영진)이라고 합니다. SRE팀은 지난 5년 동안 AWS Multi-Account Multi-Region에서 서비스의 안정성과 확장성을 위한 인프라 자동화, CI/CD 배포 시스템, 로그 및 모니터링 시스템 구성하고 자동화를 진행 하였습니다.SpoonRadio Infra 1.0 Version스푼라디오 시스템은 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를 도입하기로 결정했습니다.Okt

안녕하세요. 스푼라디오 SRE 팀의 Ash입니다. 스푼라디오는 MSA 구조 속에 빠르고 안정적인 서비스를 제공하고자 노력하고 있습니다. 하지만 과거부터 자리 잡은 모놀리식 서비스는 MSA 구조의 CI/CD 환경이 다르게 구성되어있습니다. 파편화된 CI/CD 환경 때문에 유지 보수 비용이 계속 증가하게 되어 이를 해결하기 위해 통합된 환경을 구성하기로 하였습니다.ALB TargetGroup에 Auto Scaling으로 구성된 서버들이 달려있는 모습기존 인프라 환경 분석DJ분들이 방송 시작을 할 때 시작을 알리기 위한 Psuh를 팔로워에게 발송합니다. Push로 인해 잠자기 상태로 되어있던 클라이언트들이 깨어나고 접속을 위한 트래픽을 발생시킵니다. 이 패턴은 매시간 정각마다 과도하게 발생하였고 이를 대응하기 위해 오버 프로비저닝된 자원을 항시 준비해야만 했습니다.정각마다 발생하는 스파이크성 트래픽서비스의 트래픽이 점차 커지면서 서버의 대수 또한 증가하였습니다. Rolling Upgrade를 채택한 배포 방식에 늘어만 가는 서버 대수는 배포 시간만 증가하게 되었습니다. 배포하는 과정 중 이상 유무 체크위한 모니터링은 완전히 끝날 때까지 지켜봐야 합니다. 문제는 1시간이 넘어가는 배포로 작업자의 시간을 소모하게 되고 피로도까지 쌓이게 됩니다.이벤트 트래픽을 감당하기 위한 일회용 서버의 증설과 감축은 단순 작업만 일으켰습니다. Infrastructure as Code(IaC)는 자원을 구성하기 위한 설정이 전부 명시되어있어 누가 만들더라도 동일한 자원을 구성할 수 있습니다. 하지만 IaC를 사용하기 위해 템플릿에 대한 이해와 전개 할 수 있는 작업환경까지 고려해야 합니다. 숙련된 작업자 입장에서는 손쉬운 일이지만 도구에 대한 의존성 때문에 숙련자에게만 작업이 몰리는 경향이 있었습니다.Infrastructure as CodeCI/CD 도구 선정AWS에서는 Metric과 시간 기반으로 서버 대수를 조절하는 Auto Scaling 서비스를 제공하고 있습니다. 이 서비스를 활용하기 위해 Jenkins pipeline으로 Packer와 Ansible을 검토하였습니다. 하지만 pipeline에 대한 예외 처리와 관련 인터페이스를 직접 개발해야 했고 한정된 인력으로는 작업 대비 결과물이 높게 측정되지 않았습니다.AWS의 SaaS 서비스로 Elastic Beanstalk, CodeDeploy 도입을 검토하였지만, 정형화를 기반으로 둔 서비스입니다. 배포에 있어 필요로 하는 요구사항(Rollback, Canary, 배포 시간 등)을 제공해 주지 않거나 예외 처리 과정 중 휴먼에러가 발생할 요소가 있어 도입할만한 기술은 아니었습니다.Spinnaker를 통한 CD 환경 구성이미 스푼라디오에서는 MSA 자원을 효율적으로 관리하기 위해 Kubernetes를 도입하였고 CD 도구로 Spinnaker를 사용하고 있습니다. 오케스트레이션 파이프라인 구조로 다수의 스테이지를 구성하여 실행할 수가 있습니다.빌드를 통해 나온 바이너리의 안전성 검증을 위해 카나리 방식으로 테스트를

하이퍼커넥트에는 마이크로서비스를 몇 번의 클릭만으로 배포할 수 있는, Spinnaker 기반의 배포 파이프라인이 구축되어 있습니다. (관련 글: Kubernetes에 Microservice 배포하기 1편 - 클릭 몇 번으로 배포 시스템 만들기, 2편 - Pipeline 복제하기) 다만 개발팀마다 원하는 배포 전략이 다르기 때문에, 배포를 트리거하는 부분은 개발팀에서 정할 수 있게 되어 있습니다. 저희 팀에서는 개발자가 수동으로 Spinnaker로 접속해서 배포를 진행하고 있었습니다. 코드 Merge: master 브랜치에서 새로운 브랜치를 만들어 작업합니다. 작업이 완료되면 Pull Requests를 생성합니다. CI Test가 모두 통과하고, 동료의 Approve를 받으면 master 브랜치로 Merge 합니다. GitHub Release & Git Tag 생성: 배포 이력을 관리하기 위해 배포하기 전 Git Tag를 설정합니다. Semantic Versioning으로 GitHub 저장소에서 Release를 생성하여 Git Tag를 만듭니다. 배포 시작: Spinnaker에 접속하여 개발 서버 배포 파이프라인 실행 버튼을 누르고, 빌드 파라미터로는 위에서 추가한 태그를 입력한 후 확인 버튼을 누릅니다. 프로덕션 서버 배포 파이프라인에도 이를 반복합니다. 배포 파이프라인 작동: 배포 파이프라인에 따라 Docker Image를 생성하고, Kubernates Deployment가 업데이트되며, 곧 새로운 코드가 배포됩니다. 기존 배포 프로세스의 문제점 배포 프로세스를 운영하면서 사람의 실수로부터 오는 몇 가지 이슈가 있었습니다. 잘못된 Git Tag 생성: Release 버전을 입력할 때 수동으로 올린 버전을 입력해야 합니다. 이때 5.2.0 버전의 다음 버전을 5.33.0 버전으로 입력하는 실수를 합니다. 오타를 내서 지키기로 약속한 Git Tag 네이밍 규칙을 깨트리기도 합니다. 실수로 이전 버전 배포: Spinnaker 파이프라인에서 배포할 때 입력하는 버전 파라미터에 잘못된 Git Tag 버전을 입력합니다. 개발자가 의도한 배포 버전은 5.33.0 버전인데, 실수로 숫자 하나를 빠트려 한참 이전 버전인 5.3.0 버전을 배포하는 실수를 합니다. 서버 간 버전의 불일치: 개발 서버와 프로덕션 서버 모두 최신 버전을 바라보고 있어야 하나, 배포하는 개발자가 실수로 한 곳의 서버에만 배포를 진행합니다. 다음에 배포하는 개발자는 서버 간의 버전이 다른 것을 보고, 해당 스택에 배포하기를 주저하게 됩니다. QA 팀 등 유관부서에서 테스트를 진행할 때, 특정 서버에서만 기능이 다르게 동작하여 혼란을 줍니다. Git 저장소와 서버 배포 버전의 불일치: Merge만 해 놓고 배포를 잊어버려서 배포하지 않는 경우가 생깁니다. 다음에 배포를 진행하는 개발자는 한 번에 두 개의 변경 사항을 배포하게 됩니다. 많은 변경 사항을 포함한 배포는 장애 발생 시 원인 파악이 어렵습니다. 이러한 문제점들은 현재의 배포 프로세스가 사람의 수작업에 의존하기 때문에

안녕하세요 메쉬코리아 플랫폼실 최제필입니다 :) 이번 글에서는 Kubernetes(이하 k8s)에 배포되어 운영하는 여러 MSA를 위해 도입한 CI/CD 도구 및 방법론에 대해 공유하고자 합니다! CI (Continuous Integration)란? 지속적인 통합이란 의미로, 애플리케이션의 새로운 코드 변경 사항이 정기적으로 build 및 test 되어 공유 repository에 통합되는 것. CD(Continuous Delivery or Continuous Deploy) 란? 지속적인 배포란 의미로, 개발자들이 애플리케이션에 적용한 변경 사항이 bug test를 거쳐 repository에 자동으로 업로드되는 것. 즉 CI/CD란 개발 단계를 자동화하여 보다 짧은 주기로 배포하는 전략을 말하는데요. CI/CD 방법론을 적용하면 개발의 편의성이 증가하고, 소스코드 변경부터 배포까지의 작업을 자동화할 수 있기 때문에 수작업으로 할 때의 불편함을 줄일 수 있습니다. 기존 CI/CD Pipeline에는 어떤 문제점들이 있었을까? Mesh Korea의 대부분의 MSA는 JAVA 기반의 기술 스택으로 구성되어 있으며, CI/CD Pipeline을 위해 Bamboo, Spinnaker를 사용하고 있습니다. CI/CD 적용을 위해 개발자가 Bamboo Job / Spinnaker application을 설정해야 하며, 특히 CI <-> CD tool이 연동되어 있지 않아 Bamboo CI에서 빌드 된 Docker image tag를 복사하여 Spinnaker에 손으로 입력해야 하는 등 불편한 점이 많았습니다 Spinnaker는 멀티 클러스터 / 클라우드 배포 등 강력한 기능을 지닌 CD Workflow platform이지만 Mesh Korea의 Kubernetes 숙련도, 단일 Cloud 환경 사용 등 저희가 원하는 기능보다 훨씬 복잡하고 많은 기능을 사용하기 힘든 오버 엔지니어링이라고 판단하였고, 새로운 도구들을 도입하기로 했습니다. 그럼 지금부터 본격적인 CI/CD 도구 및 방법론 도입기, 시작하겠습니다! 다음과 같은 순서로 진행되니 참고 부탁드립니다. Jenkins CI Argo CD CI/CD 도입 및 이전을 위한 자동화 방식 Jenkins CI Mesh Korea의 DevOps를 위한 여러 플랫폼들은 Jenkins CI와 연동되며 k8s cluster에서 실행됩니다. IaC(Infrastructure as Code)를 위한 Terraform, Ansible, Packer 등 Pipeline 실행 시 Pod 내 바이너리가 설치된 컨테이너에서 실행됩니다. 실행되는 모든 CI Pipeline은 Jenkinsfile에 스크립트를 작성하여 실행합니다. CI에 필요한 모든 바이너리는 Jenkins에 설치하는 것이 아닌, 필요한 Container를 지정하여 Pod로 구성하여 독립적으로 실행합니다. 해당 내용을 MSA의 CI Pipeline으로 적용하기 위해 아래와 같은 내용을 진행하였습니다. 공용 CI Pipeline 개발 및 적용 기존 Bamboo에 적