퍼블릭 클라우드 MSA 운영 환경 구축: Web POS

리포지토리

소개

• 세일싱크는 클라우드 POS 서비스로, 사용자는 어느 기기에서든 웹에 접속해 사용할 수 있습니다.
• 마이크로 서비스 아키텍처를 적용해 기능 추가면에서 확장성이 뛰어납니다.
• AWS EKS 기반 Kubernetes 클러스터 운영으로, Auto Scalable한 시스템을 추구합니다.
• Terraform을 사용한 IaC 접근 방식으로 자동화를 구성해 인프라의 재현성을 극대화했습니다.
• 모니터링(Prometheus, Grafana)을 통해 AWS 리소스 구성을 최적화합니다.

Demo

기간

• 2023.12 ~ 2024.02

진행 인원

• 백엔드 개발, 퍼블릭 클라우드 설계-구축-운영: 2명
• 프론트엔드 개발: 2명
• 기획: 2명

진행 과정

• Docker 개발 환경 구축, 커뮤니케이션 채널, 개발 및 Git 컨벤션 정의
• DDD 기법 기반 마이크로 서비스 정의
• 백엔드 API 개발
• CI / CD 파이프라인 구축
• 개발 / 운영 퍼블릭 클라우드 구축 및 배포, 운영

담당 업무

• 팀 리더
• 마이크로 서비스 애플리케이션 설계 및 개발
  • Python Flask, SQLAlchemy ORM 기반 마이크로 서비스 API 개발
  • 단위 테스트 코드 작성
• 퍼블릭 클라우드 설계 및 구축
  • AWS EKS 인프라 설계 및 배포
  • Terraform: 인프라 배포 자동화 코드 작성
• Kubernetes 클러스터 운영
  • 메니페스트 파일 작성
  • 클러스터 운영
• CI / CD 자동화 파이프라인
  • GitHub Actions: 리포지토리에 변경 사항이 감지되면 애플리케이션 빌드 후 이미지 저장소에 푸시
  • Argo CD: AWS ECR에 새 버전 태그가 감지되면 EKS 클러스터로 배포
• 모니터링 구축, 리소스 최적화
  • Prometheus, Grafana 기반 EKS 클러스터 모니터링 대시보드 구축
  • 실제 메트릭 기반 리소스 최적화

AWS Architecture

인프라 관리 전략

1. 데이터 관리 전략

• 읽기 복제본을 사용한 데이터 복제

  • 부하 분산
  • 고가용성 달성
  • 프로모션을 통한 복구

• 스냅샷을 사용한 데이터 백업

  • 정기적인 백업
  • 시점 복구 (Point-in-Time Recovery, PITR)
  • 복구 프로세스의 단순화

2. 무정지 운영 (Zero Downtime Operations) 전략

• 다중 AZ(Multi-AZ)와 자동 장애 조치 매커니즘 (Automatic Failover Machanisms)
  • 로드 밸런싱을 통해 노드에 트래픽 분산 및 장애 분리
  • 노드 장애 발생 시 자동으로 컨테이너를 건강한 노드로 이동
  • Auto Scaling: 트래픽 증가에 따라 자동으로 노드를 추가해 처리 능력 확장
  • Multi-AZ Deployment
  • RDS Multi-AZ
  • Route 53 Health Checks

3. DR (Disaster Recovery) 전략

• RDS 스냅샷, S3 버전 관리 기능을 사용한 데이터 백업
• Terraform을 사용한 인프라 코드화(Infrastructure as Code)로 재난 시 인프라의 신속한 재배포
• CI/CD 파이프라인
• CloudFront CDN을 사용해 원본 서버에 문제가 생겨도 컨텐츠 제공

4. IAM 관리 전략

• 최소 권한 원칙 (Principle of Least Privilege)
• 강력한 패스워드 정책, MFA 적용
• 정기적인 권한 검토 및 조정
• 사용자와 그룹의 사용
• 역할 기반 액세스 제어 (Role-Based Access Control, RBAC)
• K8s 애드온에는 STS를 통해 임시 권한만을 부여

CI/CD Pipeline

Micro Service Architecture

MSA화 목적

1. 확장성
   • 서비스 간 낮은 의존도를 달성해 추가 기능 확장에 용이
2. 안정성
   • 서비스 별로 트래픽과 데이터를 분리해 장애 또한 분리

MSA 단계화

• MSA는 기술적으로 워낙 방대하기 때문에 네 단계로 나눠 접근
  • 단계 1: 코드 레벨에서 서비스 별로 모듈화를 하지만 단일 DB를 사용
  • 단계 2: 종속성이 적은 DB부터 분리
  • 단계 3: 모든 서비스 단위로 DB를 분리
  • 단계 4: MSA 패턴 적용 및 애드온 프로그램 적용

프로젝트에 MSA를 어떻게 적용했는가?

1. 설계

• Micro Teams
  • 교차 기능 팀 원칙
    • 크게 Backend, Frontend, 기획과 QA 인원을 묶어 한 서비스를 담당하도록 함
    • 스크럼, Sprint 단위 업무 정의로 애자일하게 팀을 구성하려고 노력함
• Micro Services
  • 각 서비스는 얼마나 마이크로한가?
  • Domain-Driven Development 기법을 사용해 서비스 경계 정의
  • Event Storming을 통해 초기에 3개의 서비스를 정의했고, 프로젝트 후반에는 확장되어 총 6개의 서비스 정의됨
    • Store, Item, Order, Sale, Dashboard, Consulting

2. 데이터

• 서비스 별로 DB를 분리하는 작업 이후에, 데이터의 일관성이 깨지는 문제가 발생

2.1. 동기적 트랜잭션 처리

• Kubernetes 내부 서비스 주소로 마이크로 서비스의 API를 호출해 실시간으로 데이터의 일관성을 유지

2.2. 비동기적 트랜잭션 처리

• 컨설팅과 대시보드 사이의 비동기적 트랜잭션은 Kafka를 사용해 이벤트 버스를 구축

3. DevOps

• 개발 환경을 도커로 통일해서 워크스페이스의 종속성을 제거
• 개발자가 Push하는 순간부터 클러스터에 배포되는 과정까지를 자동화

4. 모니터링

• 수십 개의 컨테이너의 로그를 일일히 파악하기 어려워 중앙 집중식 로그 파이프라인을 배포
• EFK 스택을 사용해서 로그를 수집하고, 웹으로 시각화
• 클러스터 리소스는 Prometheus와 Grafana를 사용해 모니터링