안녕하세요. 여기어때컴퍼니 SRE팀에서 클라우드 엔지니어링 업무를 하고 있는 제이슨입니다. 저는 오늘 조금은 특이했던 경험을 공유드리려고 하는데요, Docker를 이용해서 서비스하는 인스턴스의 CodeDeploy 배포 실패를 Troubleshooting하는 과정에서 겪은 일입니다.회사마다 다르긴 하지만 일반적으로 AWS 환경에서 배포할 때는 아래와 같은 방법으로 하게 됩니다.AWS 환경에서의 일반적인 배포 프로세스1. 사건의 시작평화로웠던 어느 오전… 갑자기 TargetGroup의 인스턴스가 unhealthy 상태로 되었다고 슬랙 모니터링 채널에 알림이 올라왔습니다. 이제 어떤 문제가 있는지 인스턴스를 확인해 봐야겠네요.2. 문제 해결을 위한 체크 리스트 확인인스턴스 확인우선 인스턴스가 On-Demand 혹은 Auto Scaling으로 구성되었는지를 확인 합니다. 문제의 인스턴스는 Auto Scaling으로 구성되어 있었고 TargetGroup의 Health Check 실패로 인해 Auto Scaling 정책에 따라 인스턴스 교체가 반복되는 상황이었습니다.2. CodeDeploy 상태 확인1번 확인으로 CodeDeploy에서 이력을 확인해보니 배포 실패가 반복되고 있었습니다.CodeDeploy의 배포 과정 중 어떤 부분에서 문제가 있었는지 자세히 확인해 보니 ValidateService 단계에서 TimeOut으로 실패했네요.CodeDeploy의 ValidateService 단계에서 발생한 문제를 확인하기 위해서는 CodeDeploy 배포 프로세스를 알아야 할 필요가 있습니다.담당 개발자에게 문의할 수도 있지만 Jenkins에서 Build 후 업로드된 xxxx.tar.gz 파일을 S3 버킷에서 다운로드하여 압축을 풀게되면 아래 그림에서 보는 것처럼 CodeDeploy 배포 프로세스를 정의하는 appspec.yml 파일을 확인할 수 있습니다.CodeDeploy 배포 프로세스CodeDeploy에서 확인한 것과 같이 AfterInstall 단계까지 정상적으로 수행 되었지만 ValidateService 단계에서 문제가 발생한 것으로 보입니다. 그렇다면 이전 단계에서 문제가 발생했을 가능성이 큽니다. AfterInstall 단계를 점검해 보니 Docker를 사용해서 Application을 서비스한다는 것이 확인되네요.[root@ip-xx-x-xx-xxx ~]# cat appspec.ymlversion: 0.0os: linuxfiles: - source: / destination: /home/xxxx/deploy/xxxxxx-api/temppermissions: - object: /home/xxxx owner: xxxx group: xxxx mode: 775hooks: BeforeInstall: - location: BeforeInstall.sh timeout: 60 AfterInstall: - location: AfterInstall.sh timeout: 60 ApplicationStart

지속적 테스트에 빈번하게 등장하는 단어는 CI와 CD가 있습니다.CI 는 이름 그대로 지속적 통합 (Continuous Integratioin)으로 지속적으로 개발자의 작업물(코드)이 완성된 상태의 서비스가 되도록 merge되는 프로세스를 의미합니다.지속적 통합은 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하는 데브옵스 소프트웨어 개발 방식입니다.지속적 통합은 소프트웨어 릴리스 프로세스 중 빌드 또는 통합 단계를 주로 가리키며,자동화 구성 요소(예: CI 또는 빌드 서비스)와 문화적 구성 요소(예: 빈번하게 통합하도록 학습) 모두를 포함합니다.지속적 통합의 핵심 목표는 버그를 신속하게 찾아 해결하고, 소프트웨어 품질을 개선하고, 새로운 소프트웨어 업데이트를 검증 및 릴리스하는 데 걸리는 시간을 단축하는 것입니다.CD는 지속적 전달(Continuous Delivery)로 이 서비스가 사용자에게 배포되는 프로세스를 의미합니다.지속적 전달(Continuous Delivery)은 프로덕션에 릴리스하기 위한 코드 변경이 자동으로 준비되는 소프트웨어 개발 방식입니다.현대 애플리케이션 개발의 기반인 지속적 전달은 빌드 단계 이후의 모든 코드 변경을 테스트 환경 및/또는 프로덕션 환경에 배포함으로써 지속적 통합을 확장합니다.적절하게 구현할 경우, 개발자는 언제나 즉시 배포할 수 있고 표준화된 테스트 프로세스를 통과한 빌드 아티팩트를 보유할 수 있습니다.지속적 전달에서는 개발자가 단순한 유닛 테스트 외에도 다양한 테스트를 자동화할 수 있으므로,고객에게 배포하기 전에 여러 차원에서 애플리케이션 업데이트를 확인할 수 있습니다.이러한 테스트에는 UI 테스트, 로드 테스트, 통합 테스트, API 안정성 테스트 등이 포함될 수 있습니다.이를 통해 개발자는 업데이트를 좀 더 철저히 검증하고 문제를 사전에 발견할 수 있습니다.온프레미스에서는 힘들었지만, 클라우드에서는 테스트용으로 여러 개의 환경을 생성하고 복제하는 작업을 비용 효율적으로 손쉽게 자동화할 수 있습니다.Gitflow는 Vincent Driessen의 branching model을 적용해 고수준으로 저장소를 관리할 수 있게 해주는 확장 기능입니다.이를 통해 데브옵스를 수행합니다.이 모델은 feature - develop (dev) - release - hotfix - master 단계로 브랜치를 나눠 코드를 관리하는 전략입니다.• None master : 제품으로 출시될 수 있는 브랜치• None develop : 다음 출시 버전을 개발하는 브랜치• None release : 이번 출시 버전을 준비하는 브랜치• None hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치GitFlow 지침은 다음과 같습니다.• None develop을 지속적 통합 브랜치로 사용합니다.• None feature 브랜치를 사용하여 여러 기능에 대한 작업을 수행합니다.• None release 브랜치를 사용하여 특정 릴리스에 대한 작업을 수행합니다(다중 기능).

안녕하세요. 오토피디아의 서비스개발팀장을 맡고 있는 김승수입니다. 오토피디아 서비스개발팀에서는 기존 EC2 기반 인프라를 ECS를 이용한 컨테이너 기반 인프라로 전환을 진행하였습니다. 그 과정에서 ECS에서 새로 등장하는 개념들이 아주 많았는데요, AWS 문서는 중요한 개념과 중요하지 않은 개념들에 대한 설명이 섞여 있어 이해에 어려움을 겪었습니다. 따라서, ECS의 많은 개념들을 확실히 정리하여, ECS 기반 인프라를 구축하시려는 분들께 좋은 레퍼런스가 되었으면하는 마음으로 이 글을 작성합니다.1. ECS로의 전환 이유본격적인 글을 시작하기에 앞서, ECS로의 인프라 전환을 선택하게된 이유에 대해서 말씀 드리려고 합니다. 이미 컨테이너 기반 인프라의 장점에 대해 잘 아시는 분들은 다음 장으로 넘어가셔도 괜찮습니다.기존 인프라 구성오토피디아에서는 운전자 분들의 차량 문제를 해결해 드리는 닥터차 서비스를 운영중인데요, 이 닥터차 서비스 API 서버를 위한 인프라를 Terraform으로 관리하고 있었습니다. 닥터차 모놀리틱 API 서버는 EC2 오토스케일링 그룹에 속한 EC2 인스턴스들에 CodePipeline을 통해 배포되고 있었습니다.기존 인프라의 문제점이러한 상황에서 타이어 노면 사진을 통해 타이어 홈의 남은 깊이를 측정하고, 교체가 필요한 경우 타이어를 구매할 수 있는 타이어 커머스 서비스를 추가하려고 하였습니다. 그 과정에서,새로운 타이어 커머스 API 서버를 위한 서버 환경을 다시 구성해야했고,MVP인 타이어 커머스 API 서버의 자원 사용량이 크지 않음에도 인스턴스 하나를 통째로 사용해야했으며,Terraform으로는 EC2 오토스케일링 그룹에 대한 CodeDeploy 블루/그린 배포 방식을 관리할 수 없다는 문제에 부딪혔습니다.저희는 이 문제들이 빠른 시일 내에 다시 반복될 것이라고 생각했습니다. 그 이유는 크게 두가지였습니다. 첫번째로, 타이어 커머스 외에도 신규 MVP 서비스들을 런칭해야할 상황이 올 것이라고 생각했습니다.두번째로, 타이어 커머스는 기존 닥터차 서비스의 결제, 차종 기능 등을 활용해야했는데요, 그러면 타이어 커머스 API 서버로부터 모놀리틱 닥터차 API 서버로의 의존성이 발생하는 문제가 발생했습니다. 이를 해결하기 위해서는 결제, 차종, 인증 등 이후 신규 서비스들에서 공통적으로 사용하게 될 기능들을 마이크로서비스 형태로 분리해야한다는 결론을 내렸습니다. 이러한 마이크로서비스들을 런칭할 때도 신규 서비스 런칭 시와 동일한 문제가 발생할 것이라고 생각했습니다.ECS의 장점따라서, 저희는 ECS를 활용한 컨테이너 기반 인프라로의 전환을 결정하게 되었습니다.공개된 이미지들에 몇가지 설정만을 더하는 방식으로 쉽게 환경을 구성할 수 있고,0.25vCPU, 256MB 메모리 등, 작은 단위로 자원을 분배할 수 있며,Terraform으로 ECS에 대한 CodeDeploy 블루/그린 배포 방식을 관리할 수 있기 때문에기존의 문제를 모두 해결할 수 있습니다.2. ECS 기본 개념

안녕하세요, IT전략팀 김미란입니다. 지난 해 말 사람인에서 THE PL:LAB(더플랩)을 런칭하였습니다. THE PL:LAB은 ESG기반으로 인사담당자 관점에서 만든 새로운 HR 서비스입니다. 그 중 인사담당자들에게 정보와 지식을 공유하는 INSIGHT(인사이트) 프로젝트에 참여하여 개발하였습니다. 구직자는 비교적 쉽게 채용에 대한 다양한 정보를 찾아볼 수 있지만, 인사담당자들을 위한 정보는 쉽사리 찾을 수 없었습니다. 이러한 문제를 사람인에이치알에서 해소하고자 INSIGHT가 만들어졌습니다. 새로이 시작하는 인사담당자들과 이미 현업에 계신 분들께 필요한 콘텐츠를 제공하며, 서로 정보를 공유하는 신규 플랫폼입니다. 이번 프로젝트를 진행하면서 AWS를 사용했는데요. AWS 서비스 사용 경험을 공유드리고자 합니다. 프로젝트에 들어가기 앞서 Developing on AWS 교육을 수강하였습니다. AWS에 대한 기본적인 구조를 이해하는 상태에서 EC2를 사용해보았습니다. 아마존에서 주최하는 해당 교육은 AWS SDK를 사용하여 확장 가능한 클라우드 애플리케이션 개발 방법론이었습니다. 아쉽게도 해당 교육은 CI/CD와 관련된 배포 구성이나 콘솔 환경에서 사용하는 방식에 대한 건 담기지 않았습니다. AWS를 처음 사용한다면 누구든 시행착오를 겪을 과정이기에 정리해보았습니다. 프로젝트를 진행하면서 틈틈이 AWS document를 많이 참고하였어요. CodeDeploy와 S3를 이용해서 배포하기 CI툴을 이용해서 빌드를 마치면 S3와 CodeDeploy를 이용해서 EC2인스턴스로 배포합니다. 크게 아래 4가지 단계를 거친다고 보면 됩니다. Application 소스와 배포 설정 파일인 AppSpec.yml을 S3에 올린다. AWS CodeDeploy 서비스에 배포를 요청한다. CodeDeploy서비스는 EC2 Agent에 배포를 요청한다. Agent는 S3에서 소스를 받고 배포설정을 기반으로 배포를 수행한다. 참고 : https://docs.gitlab.com/ee/ci/cloud_deployment/#provision-and-deploy-to-your-aws-elastic-compute-cloud-ec2 위 과정으로 배포를 진행하기 위해 IAM Role 과 EC2 Instance를 만들어야 합니다. EC2에 Codedeploy-Agent 를 설치하고 나서 실행시켜 볼까요? CodeDeploy 실행 여부 확인 실행 중이면 The AWS CodeDeploy agent is running 메시지가 표시됩니다. 실행 중이 아니라면 start 명령어로 실행시켜줍니다. sudo service codedeploy-agent status # Status Check sudo service codedeploy-agent start # Start curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash sudo yum install g