Final Project - Task Management 회고

프로젝트 일정

2023.6.19 - 2023.6.27 ( 9일 )

시나리오 선정 및 요구사항

시나리오 분석

협업툴 ( Github 칸반보드 )

업무 분배 구성과 순서

코드 생성 및 이미지 배포 자동화 (~6/19)

• 프론트엔드 코드 생성 및 github액션 이미지 생성 및 배포 자동화, 인증 DB 구축
• 백엔드 코드 생성 및 github액션 이미지 생성 및 배포 자동화, 백엔드 DB 구축

서비스 인프라 및 비즈니스 로직 구현 1 (6/19 ~ 6/21)

• ecs Task 관리 백엔드 인프라 구축 과 DB연결 확인
• API 게이트웨이 및 lambda 인증 시스템 구축과 DB연결 확인

서비스 인프라 및 비즈니스 로직 구현 2 (6/21 ~ 6/23)

• route https 접속 및 s3정적 프론트 페이지 구현과 API 게이트웨이 접속 확인
• EventBridge - SES 메일 전송 기능 구축과 API 게이트웨이 - ALB 접속 확인

IaC 코드 작성( 6/24 ~ 6/26 )

프로그램 개요 및 기능, 인프라 요구사항

시나리오

업무를 분배하고 진행상황을 확인, 수정해 작업의 진행상황을 체계적으로 관리하는 시스템을 구축하는 것에 목표를 둡니다.

• 구현 기능
  • 로그인
  • 현재 작업 조회 / 생성/ 수정 / 삭제
  • 변경사항에 따른 이메일 전송
• 필요한 리소스
  • 백엔드 개발: JavaScript (Node.js)
  • 데이터베이스 관리: Amazon RDS (MySQL), DynamoDB
  • 사용자 인증 및 권한 관리: JWT(JSON Web Tokens)
  • 알림 시스템: Amazon SNS, SMS
  • 컨테이너화: Docker
  • CI/CD 파이프라인: GitHub Actions
  • 모니터링: CloudWatch 경보

인프라 요구사항

기술스택

• OS : Ubuntu 22.04
• 백엔드 : JavaScript
• DB : RDS, DynamoDB
• 프레임워크 : Fastify
• CICD : Github Actions
• IaC : Terraform

아키텍처 - Task Management

이 프로그램은 다수의 인원이 한 작업에 대해 역할을 나누어 프로젝트를 진행해야 할 때 이용할 수 있습니다. 사용자는 어떠한 내용의 Task를 생성할 수 있고, 특정 작업에 대한 담당자(등록 된 사용자)를 지정합니다.담당자는 그 작업을 진행하고, 담당자는 진행 상황이 바뀔 시 Task의 진행도를 바꿀 수 있고 진행도 혹은 Task 의 내용이 수정될 때마다 사용자에게 메일로 특정 로그 내용을 전송하여 보다 쉽게 수정된 내용을 확인할 수 있도록 합니다.

1️⃣ 사용자는 Route53에서 배포된 도메인을 웹브라우저를 통해 접속합니다. Route53이 사용자로부터 요청을 받으면, Route53은 CloudFront에서 캐싱한 S3의 정적웹페이지를 사용자에게 보여줍니다.

2️⃣ API GateWay는 정적 웹페이지로부터 오는 트래픽을 메서드와 도메인 엔드 포인트 별로 분류해 로그인 요청 데이터는 인증 계층 Lambda로 보내고, 작업관리 요청 데이터는 VPC 경계의 ALB로 보냅니다. 이로써 ALB는 외부에 노출되지 않습니다. 반응 트래픽은 API Gateway를 통해 원래의 클라이언트로 반환됩니다.

3️⃣ ALB(Application Load Balancer)의 주소는 외부에 노출되지 않고, API Gateway로부터 들어오는 요청을 현재 가동중인 ECS 서비스에 속한 EC2 컨테이너들로 보냅니다. 응답 트래픽은 API Gateway를 통해 원래의 클라이언트로 반환됩니다.

4️⃣ 작업 관리를 위한 CRUD 트래픽은 ECS에 배포된 컨테이너의 EC2와 주고 받습니다. 사용자가 작업 관리 페이지에서 생성, 읽기, 업데이트, 삭제 (CRUD) 작업을 요청할 때, 이러한 요청은 ECS (Elastic Container Service)에서 실행되는 컨테이너로 전송됩니다.

5️⃣ Aurora와 통신하며, 저장된 작업 데이터를 사용해 작업 관리 페이지에서 들어오는 요청을 처리합니다. ECS의 각 인스턴스는 Amazon Aurora 데이터베이스와 연결되어 있으며, 사용자의 요청에 따라 데이터베이스에서 정보를 추출하거나 업데이트합니다.

6️⃣ ECS 인스턴스는 Amazon CloudWatch를 사용하여 ECS 인스턴스의 성능과 사용량을 실시간으로 모니터링 할 수 있습니다. 이를 통해 서비스의 건강 상태를 실시간으로 추적하고 필요한 경우 적절한 조치를 취할 수 있습니다.

7️⃣ Log DynamoDB는 사용자 요청에 따른 로그를 저장합니다, RDS에 로그가 쌓일 때마다, 사용자의 모든 요청에 대한 로그 데이터는 DynamoDB에 저장됩니다. 이를 통해 요청 처리의 성공 또는 실패, 그리고 서비스의 성능 문제 등에 대한 유용한 정보를 제공합니다.

8️⃣ EventBridge에서 설정한 규칙에 따라 로그가 필터링됩니다. Amazon EventBridge는 DynamoDB에 저장된 로그 데이터를 필터링하고 분석하는 역할을 합니다. 설정된 규칙에 따라 특정 이벤트에 대한 알림을 Lambda로 보냅니다.

9️⃣ Lambda를 통해 SES 자격증명 생성으로 보안 인증된 이메일에 로그 기록을 전송합니다. 필터링된 로그 데이터는 Lambda 함수를 사용하여 사용자의 이메일로 전송됩니다. 이를 통해 사용자는 중요한 이벤트에 대한 알림을 즉시 받을 수 있습니다.

리소스 선정 - EC2

Fargate가 있음에도 EC2를 선택한 이유

Fargate는 서버리스로 구동이 되고, 리소스 사용률이 높을수록 관리나 비용 방면에서 효율이 좋다. 하지만, ECS의 컨테이너를 구동할 때 사용하는 컴퓨팅 유닛으로 EC2를 사용하는 것이 리소스 사용률이 낮을 경우에는 Fargate가 EC2보다 평균적으로 비용이 13~18% 정도 비싸고, Cloudwatch를 통해서 리소스 예약률을 90% 이상 높게 유지하도록 auto scaling을 하도록 만들면 더 비용 절감을 할 수 있습니다. ASG(EC2)를 이용할 경우 인프라 관리가 어렵고 운영이 복잡할 수 있지만, 비용 방면을 고려하여 EC2를 사용하기로 결정하였습니다.

( 레퍼런스 : https://www.youtube.com/watch?v=-3YgdBpCN60 )

리소스 선정 - DynamoDB

• 선정 이유 : Event Log DB는 작업변경 로그 메시지를 저장하는 것이 목적, 로그 메시지는
  매번 형식과 내용이 바뀌기 때문에 자유로운 데이터 형식의 데이터 ( Task Status 변경을 로그로 저장 )

• Task Status 내용

Timestamp: 2023-06-23T07:34:16.948Z 
LogType: Update LogContent: Supervisor ocean1220@naver.com Done 
Task  CI/CD Test at 2023-06-23T07:34:16.948Z

이벤트 로그 저장소 DB는 작업 변경 로그 메시지를 저장하는 것이 목적이기 때문에 매번 상황에 따라 형식과 내용이 바뀝니다. DynamoDB는 데이터가 key-value 형태로 저장되기 때문에 속성의 변경과 추가가 자유롭고 로그 메시지를 NoSQL형식으로 유동적으로 저장하기 용이하며, read 속도도 빨라 접속이 많이 발생해도 견딜 수 있습니다. 구현한 아키텍처는 적은 양의 로그 데이터를 처리하기 때문에 처리 속도가 빠른 DynamoDB가 효과적일 것이라고 생각했습니다.
그리하여 DynamoDB는 AWS Lambda와 같은 이벤트 기반 처리 시스템과 잘 통합되어 실시간 로그 분석과 같은 복잡한 로그 처리 작업 또한 쉽게 구현할 수 있습니다.

리소스 선정 - Aurora

• 선정 이유 : Task DB는 지속적인 CRUD요청을 처리해야하고,
  정형데이터를 안정적으로 저장 및 처리가 가능한 DB가 필요 ( Task 내용 저장 )

• Task 내용

{
  "Task_id": 12,
  "Supervisor_email": "devops04@gmail.com",
  "PIC_email": “ocean1220@naver.com",
  "Task_name": "TIL",  
  "Task_contents": "TIL 123123today", 
  "Task_status": "Done", 
  "Deadline": "2023-06-22"
}

• RDS 대신 Aurora 를 채택한 이유
  • 클러스터의 Multi AZ 를 통해 가용성과 확장성을 확보하며 RDS와 연결 하려 했지만 RDS가 지원하는 Multi AZ는 비용은 각 AZ에 생성된 RDS 만큼 나가지만 AZ에 문제가 생기지 않는 이상은 휴지상태가 되어 작동하지 않고 비용만 청구 됩니다. 반면에 Aurora에서 지원하는 Multi AZ 서비스는 읽고 쓰기 가능한 Main DB서버와 별개로 Read가 가능한 Sub DB 서버를 다른 AZ에 두기 때문에 RDS 보다 Data 를 읽고 쓰는게 훨씬 빠르고 비용적인 면에서 역시 RDS Multi AZ 서비스와 크게 차이도 나지 않고 성능적인 부분에서도 유리하기에 Aurora 를 채택했습니다. 하지만 비용적인 부분(사실 이게 제일 큼)과 사용하는 Data의 양이 크지 않기에 실제 구현은 RDS 를 사용하였습니다. 현업에서 실제로 아키텍쳐를 구현한다면 Aurora를 사용할 것 같습니다.

리소스 선정 - EventBridge

• 선정 이유

  • EventBridge는 Event 필터링이 가능해 Lambda가 불필요하게 실행되는 것을 방지할 수 있다.
  • EventBridge는 AWS리소스로부터 직접 이벤트를 수신할 수 있어서 추가적인 구현작업을 줄일 수 있다.

• SNS + Lambda 조합이 있음에도 EventBridge를 선택한 이유

  • EventBridge는 분리되고 확장 가능한 이벤트 기반 시스템을 구축하는 데에 적합한 시스템 입니다. Rule을 적용해 필터링 기능을 사용할 수 있으며, 사용자 정의 코드 없이 직접 이벤트를 수신하여 다양한 서비스와 통합이 가능합니다. SNS, SQS 사용을 고려했을 때 가지는 장점인 엄격한 메세지 순서 보장, 높은 데이터 처리량 보다는 앞서 언급한 장점을 가진 EventBridge 사용이 서비스에 더 적합하다고 판단하여 EventBridge를 사용하기로 결정했습니다.

아키텍처 보안 강화

• ECS 인스턴스를 각 AZ의 private 서브넷에 할당 ( 각 AZ의 EC2로 트래픽을 보내줄 NAT Gateway 생성 )
  
• AZ 하나당 1개의 NAT Gateway를 사용하는 이유

  비용 : AZ간의 통신에 비용발생
  고가용성 : 1개 AZ에서 문제 발생시 시스템 영향 최소화

( 레퍼런스 : https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-nat-gateway.html )

ECS가 Public Subnet 에 위치하도록 구성이 되어 있는데, 이 부분이 보안 부분에 취약 할 수 있다는 우려가 있어 지금의 이미지처럼 아키텍처를 보완 하였습니다. ECS 와 DB서버를 Private Subnet에 위치하게 두고 NAT Gateway를 Public Subnet으로 분리하여 ALB를 통한 ECS와의 통신은 유지하면서 클러스터 내부의 IP주소 노출위험을 제거했습니다. 실제 많은 기업의 아키텍처가 이러한 방식으로 구성 되어 있다는 것을 알아보니 앞으로도 더욱 배워야 할 것이 많다는 것을 느꼈습니다.

IaC 코드 작성

Github Repository : https://github.com/Hoonology/devops-04-Final-Team5/tree/gittest/tf

회고

2주라는 시간 동안 느낀 나의 회고를 작성합니다. 짧지 않은 시간, 업무 분담 부터 주제 선정, 아키텍처 작성 그리고 마지막 IaC 작업 까지 Zerobase mk.2 팀이 없었으면 일사천리로 진행되지 않았을 것임에 확신합니다.

KPT 회고

Keep

• 칸반보드 작성을 통해 이슈관리를 꾸준히 잘 한것
  

  • 주제 선정 및 리소스 회의에서 구두로 말한 것을 즉시 코멘트
    
  • 문제 - 해결을 즉시 공유하여 팀 전체의 이해력 제고

• 각 섹터가 나뉘어 팀 in 팀으로 협업을 이끌어낸 점

• 서로가 모르는 부분이 있으면 채워주고 보완해주는 점

• 해결이 안 되면 될 때 까지 부딪혀보는 마인드셋

Problem

• 다른(백엔드) 팀원의 이슈를 깊게 파악하고 해결해주지 못한 점
  • 타 이슈 발생하고 확인하여 문제를 같이 고민할 수 있는 시간이 있었지만, 해결점을 찾아내는 역할 보다는 트러블슈팅 해결 과정을 이해하는 것에만 그침

Try

• 업무 외 시간에 모든 Issue를 체크
• 아키텍처의 구성과 리소스에 대한 공식문서를 면밀히 살펴보기

끝맺음

여러모로 바쁜 2주를 보낸 것 같습니다. 평일에는 일정 기획대로 이어가고 주말에는 코드 작업을 하면서 우리의 프로젝트를 지속적으로 살피고 애정을 담은 것에 정말 보람이 느껴졌습니다. 처음에 DDD와 다이어그램을 그리는 것을 시작으로 마지막에 유종의 미로 아키텍처를 그렸을 때까지의 기분은 다시 경험할 수 없는 희열로 다가왔습니다.
다른 프로젝트를 진행한다면 해당 프로젝트에서 느낀 긍정적인 요소( 특별히 협업 부분과 트러블 슈팅 ), 그리고 문제 해결 방식을 도입하겠다고 결심했습니다.

마지막 프로젝트를 하면서 AWS의 각 리소스에 대한 부족한 이해도도 더욱 끌어 올릴 수 있었고 바닥부터 시작한 아키텍처 구현에 성공하고 나니 뭔가 시원하기도 하고 뭐든 할 수 있을 것 같은 자신감도 생겼습니다.
같이 고생한 팀원분들께 다시 한번 감사 드립니다.