IoT 원격제어를 위한 웹 기반 애플리케이션 프로젝트(CI/CD, AWS)

저는 해당 프로젝트에서 Terraform 모듈화, CI/CD, 승인 시스템을 메인으로 맡았습니다.

구분	프로젝트 상세내용
프로젝트 명칭	IoT 원격제어를 위한 어플리케이션 프로젝트
프로젝트 목표	고객들이 스마트폰을 통해 집안의 기기들을 원격으로 제어할 수 있는 웹 기반 애플리케이션을 제공. 사용자가 자신의 계정을 통해 가전기기 상태를 확인하고, 원격으로 온도나 조명 등을 조정할 수 있는 기능을 제공.
개발환경	AWS, Terraform, GitHub
구현과정	1. 요구사항 분석: 요구사항을 분석하고 담당한 영역에 따라 알맞은 환경을 구성. 사용자 수가 증가할 때 자동으로 서버 인프라를 확장할 수 있어야 하고 24시간 중단 없는 서비스를 제공해야 하며, 문제가 생길 경우 자동으로 복구되는 것을 요청. 2. 설계: 인프라 관리 효율성을 위한 CI/CD 구축 필요 -> AWS CodePipeline, CodeBuild, CodeDeploy 등의 서비스를 활용한 자동화된 빌드 및 파이프라인을 구성 3. 구축: 설계한 내용을 바탕으로 Terraform을 이용해 모듈화를 진행, Web, Was환경을 CodePipeline, ECS, ECR을 이용하여 자동화된 CI/CD환경 구축 및 HumanError 방지를 위한 Slack 알림, 승인 시스템 구축 4. 테스트: 파이프라인 자동화 테스트 및 승인, 알림 시스템 테스트, 고의적으로 컨테이너 종료 후 자동 복구 확인으로 안정성 검증 5. 배포: 최종 검증이 완료된 후, Web, Was 배포.
수행기간	2024.11.01 ~ 2024.12.12 (1개월 12일)
참여인원	5명
담당업무	Git과 AWS CodePipeline활용한 CI/CD 파이프라인 설계 및 구축 ECR을 사용하여 지속적인 컨테이너 버전 관리 ECS를 사용하여 컨테이너 자동 배포 및 관리 무중단 배포를 위해 Blue/Green 배포 시스템을 설계 및 구현 S3를 통하여 빌트 아티팩트 관리 Terraform 모듈화를 통해 CI/CD 코드의 관리 효율성과 재사용성을 개선 및 자동화된 배포 환경 설정 안정적인 코드 배포를 위해 지속적인 통합 및 테스트 프로세스를 관리 Human Error를 방지하기 위해 Lambda, AWS SNS, API Gateway 를 사용하여 CI/CD Slack 승인시스템 설계 및 구축 상황전파를 위해 Lambda, EventBridge를 사용하여 CI/CD 알림, 승인 시스템을 설계 및 구축 CICD 알림 및 승인 시스템 가이드 작성 CICD 정의서 작성
프로젝트 결과	AWS 기반으로 안정적이고 확장 가능한 웹 애플리케이션 설계 및 배포 완료. S3로 정적 콘텐츠를 제공하고 EC2에서 동적 API 서버를 구성해 스마트 홈 기기 제어를 구현. 데이터베이스와의 보안 통신을 설정해 데이터베이스를 안전하게 관리하며, Auto Scaling을 통해 트래픽 변화에 따라 EC2 인프라를 자동으로 확장 및 축소. CloudWatch와 CloudTrail을 활용해 비용 최적화와 모니터링을 수행하고, VPC로 네트워크를 분리하며 최소 권한 원칙을 적용해 보안을 강화. ECS의 Blue/Green배포를 이용하여 24시간 무중단 배포를 구현, 자동화된 CI/CD환경을 구성하고 알림, 승인시스템을 구축하여 HumanError발생 가능성 낮춤. 도메인으로 접속하여 배포된 Web, Was를 통해 기기 동작 확인

고객 24시간 중단 없는 서비스를 제공해야 하며, 문제가 생길 경우 자동으로 복구를 요청했습니다.
저는 AWS ECS의 무중단 배포를 통한 업데이트를 선택하여 요구사항을 만족시키는 환경을 구성하였습니다.

CICD의 전체적인 흐름

GitHub에서 main브랜치의 변경이 감지되면 CodeBuild에서 GitHub의 소스코드를 기반으로 이미지 빌드를 시작합니다.

빌드에서 생성된 아티팩트는 S3로 저장되고 빌드된 이미지는 ECR로 저장됩니다.

이미지 업로드가 완료되면 배포 전 승인권자에게 Slack으로 배포 승인을 요청하고
승인이 완료되면 AWS Codepipeline으로 블루/그린 배포를 시작하게 됩니다.

CodePipeline을 사용한 이유
가장 큰 이유는 AWS를 기반으로 제작하라는 요구사항이 있었기 때문이었습니다. 또한 다른 AWS 서비스와의 긴밀한 통합, CodePipeline은 자동으로 배포를 수행하며, 문제가 발생할 경우 손쉽게 롤백할 수 있는 점(안정성을 높이고 서비스 중단 시간을 최소화할 수 있다고 생각했습니다), AWS의 IAM과 통합되어, 세밀한 권한 관리가 가능, 배포 상태를 실시간으로 파악하고, 문제 발생 시 즉각적인 대응이 가능하기에 Codepipeline을 사용했습니다.
- Jenkins와 비교 했을 때는 오픈소스로 유연성과 확장성이 뛰어나지만, 보안 및 유지 관리 측면에서 추가적인 관리가 필요합니다. 젠킨스가 유연성과 확장성도 더 좋지만 한정된 시간 + 안정성 을 챙겨야하므로 추가적인 공부가 필요하고 관리가 필요한 젠킨스를 포기하고 AWS CodePipeline으로 결정했습니다.

ECS는 완전 관리형 서비스로 운영 부담을 크게 줄여주며 서비스 자체에 대한 비용이 없어 사용 하였습니다.

배포 타입을 EC2로 선택한 이유는 장기 사용시 Fargate에 비해 더 저렴할 뿐만 아니라,
사용자가 EC2 인스턴스를 커스터마이징 하여 리소스 최적화를 유연하게 할 수 있어
EC2를 선택했습니다.

ECS와 EC2배포방식을 사용하여 인프라의 관리효율성을 높이고 운영과 확장이 용이하도록 하였습니다.

ECR에서는 이미지 업로드 시 자동으로 취약성 스캔을 통해 보안 취약점을 사전에 탐지하여 보안성을 강화하였고

ECS에서는 Container Insight를 사용하여 컨테이너에 문제가 발생했을 때 신속하게 로그를 확인 후 문제를파악하고 대응할 수 있도록 하였습니다.

왜 블루/그린 배포방식을 선택했는가?

무중단 배포에는 대표적으로 블루/그린, 롤링, 카나리 배포가 있습니다.

비용 최적화에 초점을 둘 경우 상대적으로 더 적은 리소스를 사용하여 새로운 버전으로 변경하는 롤링 배포가 더 적합할 것 같다고 생각하였고

안정적인 서비스에 초점을 둘 경우에는 리소스 사용이 증가하더라도 구버전을 재활용하거나 롤백이 용이한 블루/그린 배포가 더 적합할 것 같다고 생각했습니다.

카나리 방식은 현재의 소규모 환경에서는 사용자 수가 적어 배포를 통해 얻는 데이터가 제한적이기에 제외 하였습니다.
카나리 배포를 제외한 자세한 이유
소규모 환경에서는 트래픽이나 사용자 수가 적어 카나리 배포를 통해 얻는 데이터가 제한적이기에 대규모 환경처럼 유의미한

피드백을 빠르게 얻기 어려워, 카나리 배포의 장점이 충분히 발휘되지 않을 수 있다고 생각하여 제외하였습니다.
만약 대규모의 환경이었다면 카나리 배포를 충분히 고려했을 것입니다.

저는 비용 최적화도 중요하지만 안정적인 서비스가 운영 관점에서 제일 중요하다고 생각하였습니다.

블루/그린 배포는 환경 분리를 통해 버전 충돌을 방지하고, 문제가 발생하면 즉시 롤백이
가능해 빠르게 복구할 수 있어 안정성 측면에서 더 적합하다고 판단했기에 블루/그린
배포를 선택했습니다.

AWS CodePipeline 알림 및 승인 구성도

파이프 라인은 총 4단계로 구성되어 있으며

각 단계가 진행될 때 마다 성공, 실패 알림이 Slack으로 발송 되어 관련 인원에게 진행 상황을 일관되게 전파할 수 있도록 하였습니다.

Approve 단계에서 배포 전 승인권자의 최종 확인을 통해 잠재적인 휴먼 에러 발생을 줄일 수 있도록 하였습니다.

실시간 알림과 승인 프로세스를 통해 협업 효율성을 향상 시키고 휴먼 에러를 줄일 수 있습니다.

파이프라인은 각 단계가 진행될 때 마다 성공, 실패 알림이 Slack으로 발송됩니다.

알림에는 파이프파인 이름, 스테이지, 성공 실패 여부가 기재되고 한눈에 알 수 있게 이모티콘이 변경됩니다.

Approve단계에서는 타인이 승인하는 것을 방지하기 위해
승인권자만 초대된 채널에 승인 메시지가 발송되고, 필요하다면 단계별로 여러 승인권자를 지정할 수 있습니다.

메시지에는 파이프파인 이름, 풀 리퀘스트 메시지, 파이프라인 바로가기 링크가
함께 첨부되어 배포 정보를 즉시 확인할 수 있도록 하였습니다.
배포 버튼을 클릭하면 즉시 배포가 진행되며, 만약 이미 종료된 메시지의 버튼을 클릭하게 될 경우 자동으로 “이미 처리된 승인”이라고 메시지가 편집됩니다.

Slack알림 및 승인의 구조

알림 과정 설명
CodePipeline에서 Stage가 진행될 때마다 EventBridge에 이벤트를 게시합니다.

이벤트가 게시되면 Lambda의 트리거가 작동하게 되고 이벤트 내용이 담긴 메시지를 Slack으로 발송합니다.

승인과정

CodePipeline의 Approve스테이지에서 SNS로 승인 요청 이벤트를 게시합니다.
이벤트가 게시되면 Lambda의 트리거가 작동하게 되고 승인 요청 정보를 담은 메시지를 Slack에 발송합니다.

Slack에서 배포 또는 거부 버튼을 누르게 되면 API gateway로 승인 결과가 전송되고 Lambda의 트리거가 작동하여
CodePipeline에 승인 결과를 반영합니다.

다음은 WEB 페이지의 로그인 로고를 변경하는 과정을 담은 동영상입니다.

처음 보이는 로고는 변경 전 로고입니다.

Git에서 수정
GitHub의 edit브랜치에서 해당 이미지 코드를 변경해 줍니다.
메시지를 적고 풀 리퀘스트로 main브랜치에 적용시킵니다.
main브랜치의 코드가 변경되면 자동으로 파이프라인이 실행되게 됩니다.

파이프라인
소스 코드 가져오기가 완료되면 알림이 발생하고 빌드 스테이지가 시작됩니다.빌드 스테이지가 완료되고 마찬가지로 알림이 온 뒤 승인 스테이지가 시작되고 승인 요청 메시지가 수신 됩니다.
승인 요청 메시지에는 풀 리퀘스트시 적은 메시지도 포함되어 있습니다.
배포를 승인하면 Deploy 스테이지로 진행되어 배포가 진행됩니다.
이전에 받은 승인 요청 메시지에 응답을 할 경우에는 이미 처리된 승인이라고 메시지가 편집됩니다.
승인 스테이지 완료 알림이 발생했고 배포가 진행됩니다.
배포 진행 후 업데이트 된 컨테이너로 트래픽을 전환한 뒤 기존에 있던 컨테이너를 종료해 배포를 성공적으로 마칩니다.

이제 로고가 귀여운 팬더로 변경된 것을 확인할 수 있습니다.