New infrastructure Design doc

디자인 독(Design doc)이란?

---

• Design docs는 Google의 소프트웨어 엔지니어링 문화의 핵심 요소 중 하나로, 소프트웨어 시스템이나 애플리케이션의 주요 저자가 코딩 프로젝트를 시작하기 전에 작성하는 비교적 비공식적인 문서입니다.
  • 고수준의 구현 전략과 주요 설계 결정을 문서화하며, 특히 그러한 결정 시 고려되었던 트레이드오프에 중점을 둡니다.
  • 소프트웨어 엔지니어의 직무는 코드를 작성하는 것이 아니라 문제를 해결하는 것이며, Design doc과 같은 비정형 텍스트가 프로젝트 초기 단계에서는 코드보다 더 간결하고 이해하기 쉬운 문제 해결 도구가 될 수 있습니다.

Design doc의 소프트웨어 개발 라이프사이클에서의 역할

• 원래의 소프트웨어 설계 문서화 외에도 다음과 같은 기능을 수행합니다.
  • 변경이 아직 저렴할 때 설계 이슈를 조기에 식별
  • 조직 내에서 설계에 대한 합의 도출
  • 횡단 관심사(cross-cutting concern) 고려 보장
  • 시니어 엔지니어의 지식을 조직으로 전파
  • 설계 결정에 대한 조직적 기억의 기반 형성
  • 소프트웨어 설계자의 기술 포트폴리오에서 요약 아티팩트 역할

Design doc의 라이프사이클

1. Creation and rapid iteration: 문서 작성 및 동료와의 신속한 반복을 통해 안정적인 버전 도출 (진행 중)
2. Review: 더 넓은 청중과 공유되어 리뷰됨
3. Implementation and iteration: 구현 중 설계 변경 사항 발생 시 문서 업데이트
4. Maintenance and learning: 시스템을 이해하기 위한 가장 접근성 좋은 진입점 역할

Overview

---

Context and scope:

새로운 시스템이 구축되는 배경과 실제로 구축되는 내용에 대한 개요

성능 문제

• 리소스 경쟁
  • 애플리케이션, 데이터베이스, CI/CD 파이프라인이 동일한 서버에서 실행되면 하나의 머신에 리소스를 CPU, 메모리, 디스크 I/O 등의 리소스를 두고 경쟁하게 되는데, 이로 인해 성능 저하가 발생할 수 있습니다.
• 스케일링 한계
  • 단일 인스턴스에서 모든 작업을 처리하려면 특정 시점에서 리소스가 한계에 도달할 수 있으며, 필요에 따라 스케일링(scale-in, out, up, down)이 어렵습니다.
• [solution]
  • 리소스 경쟁 & 스케일링 한계
    • 애플리케이션, DB, CI/CD 파이프라인 컨테이너화
      • 각각의 서비스가 독립적인 컨테이너에서 실행되므로, 리소스 경쟁을 줄일 수 있습니다.
    • EKS (Elastic Kubernetes Service) 도입
      • 복구 자동화: 장애 발생 시 자동으로 복구하고, 잘못된 상태의 컨테이너를 자동으로 재시작합니다.
      • 애플리케이션과 CI/CD 파이프라인을 EKS에 분산 배포하여 리소스 사용을 분리합니다.
      • 스케일링의 경우, pod의 인스턴스 수, 메모리, cpu 양 등을 helm chart를 통해 관리합니다.
      • 사용자는 helm chart에 값을 반영하고 gocd등의 CI/CD 파이프라인을 실행하여 스케일링을 적용합니다.

가용성 문제

• 단일 장애점
  • 모든 서비스가 하나의 EC2 인스턴스에 집중되어 있으므로, 인스턴스에 장애가 발생하면 모든 서비스가 동시에 중단될 수 있습니다.
• 백업 및 복구
  • 데이터베이스와 애플리케이션을 동일한 인스턴스에서 호스팅할 경우, 백업 및 복구 전략이 복잡해지고 복구 시 애플리케이션 다운타임이 길어질 수 있습니다.
• [solution]
  • 단일 장애지점
    • Multi Availability Zone으로 배포합니다. 애플리케이션과 데이터베이스를 여러 가용 영역에 배포하여 하나의 가용 영역에서 장애가 발생하더라도 서비스가 중단되지 않습니다.
    • 로드 밸런서 (ALB/NLB/HAProxy): 로드 밸런서를 활용하여 여러 가용 영역에 분산된 인스턴스로 트래픽을 분배합니다.
  • 백업 및 복구
    • RDS를 사용하여 자동 백업, 스냅샷 및 멀티 AZ 배포 기능을 사용합니다.
    • Datalake, Olap 등을 사용하여 장기적인 데이터 보관과 복구 기능을 제공합니다.(too much 느낌)

유지보수 문제

• 운영 체제 및 소프트웨어 업데이트
  • 인스턴스에서 애플리케이션, 데이터베이스, CI/CD 도구 모두에 대해 패치와 업데이트를 해야 합니다. 이는 현재 구조에서 다운타임이 필연적이며, 업데이트가 서로 충돌할 위험이 있습니다.
• 로그 관리
  • 모든 서비스의 로그가 같은 인스턴스에 저장되므로 로그 관리가 복잡해지고, 디스크 공간을 빠르게 소모할 수 있습니다.
• [solution]
  • 운영 체제 및 소프트웨어 업데이트
    • 위와 같이 여러 AZ를 활용하며 로드밸런서를 이용하여 해결할 수 있습니다.
  • 로그 관리
    • Filebeat(or Kafka) + Logstash(or Vector) + ElasticSearch + Kibana로 모든 서비스의 로그를 중앙 집중식으로 관리하고 분석합니다.(모든 로그는 es에서 검색/관리)

네트워크 및 접근성 문제

• 네트워크 혼잡
  • 애플리케이션, 데이터베이스, CI/CD 도구 간의 네트워크 트래픽이 증가하면 네트워크 혼잡이 발생할 수 있습니다.
• 외부 접근 위험
  • 애플리케이션과 데이터베이스가 외부에 노출될 경우 보안 위협이 증가하며, 필요 없는 서비스가 외부에 노출될 위험이 있습니다.
• [solution]
  • 네트워크 혼잡
    • VPC 내에서 트래픽을 관리하도록 합니다. VPC 내에서 서비스 간의 통신을 최소화하고, 필요한 경우 전용 네트워크 링크로 설정하여 네트워크 복잡성을 줄입니다.
  • 외부 접근 위험
    • 보안 그룹과 네트워크 ACL을 적절히 설정하여 외부 접근을 제어하고 필요한 포트만 열어둡니다.

CI/CD 문제

• 빌드/배포 시간 증가
  • CI/CD 파이프라인이 동일한 리소스를 사용하는 경우, 빌드와 배포 시간이 증가할 수 있으며 이는 개발 효율성을 저하시킬 수 있습니다.
• 젠킨스 유지 보수의 어려움
  • 현재 젠킨스로 CI/CD를 모두 관리하고 있는데 이 경우, 젠킨스 서버가 다운되면 자체적인 빌드/배포가 어려워질 수 있습니다.
  • 또한 개발자가 직접 빌드/배포 스크립트를 작성하여 파이프라인을 구성하는 경우 유지보수와 휴먼 에러의 가능성이 높아집니다.
• [solution]
  • 빌드/배포 시간 증가
    • 위와 같이 eks를 활용하여 파드 간 리소스를 격리하여 문제를 해결할 수 있습니다.
  • 젠킨스 유지 보수의 어려움
    • GOCD(UI기반 배포 툴)를 도입하여 helm chart로 빌드/배포/롤백을 관리합니다.

모니터링 및 장애 감지 문제

• 모니터링 복잡성
  • 여러 서비스가 같은 인스턴스에서 실행될 경우 각 서비스의 상태를 독립적으로 모니터링하는 것이 어려울 수 있습니다.
• 장애 감지 및 대응 지연
  • 한 서비스의 장애가 다른 서비스에 영향을 미칠 때, 문제를 정확히 파악하고 대응하는 데 시간이 오래 걸릴 수 있습니다.
• [solution]
  • 모니터링 복잡성
    • Prometheus와 Grafana를 사용하여 애플리케이션 성능을 모니터링하고 시각화합니다. 또한 장애, 이상 메트릭 발견 시 슬랙으로 메트릭을 전송합니다.
    • EKS의 헬스 체크 기능을 활용하여 애플리케이션의 상태를 지속적으로 확인하고, 문제가 발생하면 auto hilling을 진행합니다.

Goals and non-goals: 시스템의 목표와 목표가 아닌 것

---

주요 목표(Goals)

1. 리소스 경쟁 및 스케일링 문제 해결
   • EKS 도입: 애플리케이션과 CI/CD 파이프라인을 EKS에 분산 배포하여 리소스 경쟁을 줄이고 스케일링 문제를 해결.
2. 가용성 문제 해결
   • Multi-AZ 배포: 애플리케이션과 데이터베이스를 여러 가용 영역에 배포해 단일 장애 지점을 제거.
   • 자동 백업 및 복구: RDS를 활용해 데이터베이스의 자동 백업 및 복구 전략을 구현.
3. 유지보수 문제 개선
   • 중앙 집중식 로그 관리: Vector, ElasticSearch, Kibana를 통해 모든 서비스의 로그를 효율적으로 관리.
   • 운영 체제 및 소프트웨어 업데이트 관리: 여러 AZ와 로드밸런서를 활용해 다운타임 없이 업데이트 관리.
4. 네트워크 및 접근성 문제 해결
   • 네트워크 혼잡 완화: VPC 내 트래픽 관리 및 서비스 간 통신 최적화.
   • 보안 강화: 보안 그룹과 네트워크 ACL을 설정하여 외부 접근을 제어.
5. CI/CD 문제 해결
   • 빌드/배포 최적화: EKS를 활용해 파드 간 리소스를 격리하여 빌드/배포 시간을 단축.
   • GOCD 도입: Helm chart를 활용한 UI 기반의 빌드/배포 관리로 젠킨스 유지보수 어려움을 해결.
6. 모니터링 및 장애 감지 문제 해결
   • 모니터링 단순화: Prometheus와 Grafana로 성능 모니터링 및 시각화.
   • 자동 복구 기능: EKS의 헬스 체크 및 auto healing 기능으로 장애 발생 시 자동 복구.

목표가 아닌 것(non-goals)

1. 복잡한 데이터 보관 및 복구 전략 (e.g., Datalake, OLAP 도입)
   • Datalake나 OLAP와 같은 장기적인 데이터 보관 및 복구 기능을 도입하는 것은 이번 설계의 목표가 아닙니다.
   • 데이터 보관 및 복구는 RDS의 기본 백업 및 스냅샷 기능을 사용하는 수준에서 처리합니다.
2. 모든 애플리케이션 및 서비스의 완전한 서버리스 전환
   • 서버리스 아키텍처(예: AWS Lambda)로의 완전한 전환은 고려 대상이 아닙니다. 대신 EKS 및 컨테이너 기반 아키텍처를 활용하여 문제를 해결합니다.
3. 모든 로그와 데이터를 외부 클라우드 서비스에 의존
   • 로그 관리 및 모니터링을 위해 ElasticSearch와 Kibana를 활용하지만, 모든 데이터를 외부 클라우드 서비스에 의존하지는 않습니다. 데이터와 로그는 필요한 범위에서만 클라우드에 저장합니다.

System-Context Diagram

---

이 시스템은 클라우드 기반의 마이크로서비스 아키텍처를 사용하여 애플리케이션, 데이터베이스, CI/CD 파이프라인을 관리합니다. 전체 시스템은 AWS 인프라에서 동작하며, 주요 구성 요소로는 EKS(Elastic Kubernetes Service), RDS(Relational Database Service), CI/CD 파이프라인, 로드 밸런서, VPC 등이 있습니다.

구성 요소

1. 클라이언트: 사용자는 인터넷을 통해 애플리케이션에 접근합니다.
2. 로드 밸런서(ALB/NLB): 클라이언트 요청을 EKS 클러스터의 다양한 서비스로 분배합니다.
3. EKS 클러스터: 애플리케이션과 CI/CD 파이프라인이 컨테이너 형태로 분리되어 실행됩니다.
4. RDS: 데이터베이스가 관리되며, Multi-AZ 배포로 높은 가용성을 보장합니다.
5. VPC: 보안 및 네트워크 트래픽 관리를 위해 모든 컴포넌트가 VPC 내에서 운영됩니다.
6. 모니터링 및 로그 관리: Prometheus, Grafana, ElasticSearch, Kibana를 통해 성능 모니터링 및 로그 관리가 이루어집니다.

비용 계산

---

Cluster Spec

• EKS 클러스터: 2개
• 각 클러스터당 노드 수: 3대
• 노드 타입: 가장 저렴한 EC2 인스턴스 유형 (t3.micro를 사용)
• 지역: 서울 리전, ap-northeast-2
• 각 노드당 EBS 스토리지: 20GB gp2

1. EKS 클러스터 관리 비용

• 클러스터 관리 비용: 클러스터당 $0.10/시간
• 두 클러스터를 운영하므로:
  • $0.10 x 24시간 x 30일 x 2 클러스터 = $144/월

2. EC2 인스턴스 비용 (변경된 인스턴스 비용 적용)

• t3.micro 인스턴스는 $0.0104/시간
• 각 클러스터에 3대의 노드를 사용하며, 총 2개의 클러스터 운영
• EC2 인스턴스 비용:
  • $0.0104 x 3대 x 24시간 x 30일 x 2 클러스터 = $44.928/월

3. EBS 스토리지 비용

• gp2 스토리지는 $0.114/GB(월)
• 각 노드에 20GB의 EBS 스토리지를 할당
• EBS 스토리지 비용:
  • $0.114 x 20GB x 3대 x 2 클러스터 = $13.68(월)

4. 총 월간 비용

위의 계산을 종합하면 다음과 같습니다:

• EKS 클러스터 관리 비용: $144/월
• EC2 인스턴스 비용: $44.928/월
• EBS 스토리지 비용: $13.68/월

총 예상 비용: $202.608/월

5. EKS를 사용하지 않고 직접 Kubernetes 클러스터 구축 시 비용 (2개의 클러스터)

EKS를 사용하지 않고 EC2 인스턴스에 직접 Kubernetes 클러스터를 구축하는 경우:

• EC2 인스턴스 비용: $0.0104/시간
  • 3대의 t3.micro 인스턴스를 사용, 2개의 클러스터 운영
  • $0.0104 x 3대 x 24시간 x 30일 x 2 클러스터 = $44.928/월
• EBS 스토리지 비용: $0.114/GB/월 (20GB EBS 볼륨 사용)
  • $0.114 x 20GB x 3대 x 2 클러스터 = $13.68/월

총 비용: $58.608/월

6. 비용 비교 (최종 정리)

• EKS 사용 시 (2개의 클러스터) 총 비용: $202.608/월 (약 27만원)
• EKS 사용 시 (1개의 클러스터) 총 비용: $101.304/월 (약 13.5만원)
• EKS 사용하지 않고 직접 구축 시 (2개의 클러스터) 총 비용: $58.608/월 (약 8만원)
• EKS 사용하지 않고 직접 구축 시 (1개의 클러스터) 총 비용: $29.304/월 (약 4만원)

추가적인 고려 사항

• 데이터 전송 비용: 같은 리전 내에서의 데이터 전송은 무료이지만, 인터넷으로 데이터를 전송하는 경우 추가 비용이 발생할 수 있습니다.
• ELB 비용: ELB를 사용하는 경우 추가 비용이 발생할 수 있습니다.