Nasir

We, are our choices.

2 minute read

Cloud Native Application을 위한 자동화 Platform 및 Dashboard 구축

프로젝트 목표

  • 클라우드 기반의 Modernized App 배포환경이 없는 고객사를 가정하여,
    • EKS 및 Kubernetes ECO-system 구축 및 배포 자동화 서비스
    • System & Management Metric 제공 Monitoring Dashboard 개발 및 배포

본 프로젝트의 서비스 흐름도와 각 구성요소별 아키텍쳐는 아래와 같습니다

Service workflow

service

저희 프로젝트의 서비스 흐름도 입니다.

  1. Platform Service를 사용하여 필요에 따라 개발, 테스트, 배포 환경을 생성 및 변경합니다.
  2. Application Service를 통해 회사의 기존 서비스나, 저희팀의 Monitoring 서비스가 배포됩니다.
  3. 각 컨테이너 환경의 System metric(CPU, Mem, Disk, etc.)을 Prometheus가 수집합니다.
  4. Backend(Flask)에서 AWS API로 필요데이터 요청 및 수신 정보를 가공합니다.
  5. Frontend(React)에서 가공된 Management metric(비용, 사용량, 가동률, 등)을 Dashboard로 제공합니다.

Pipeline architecture

pipeline

각 파이프라인에 대한 상세 설명입니다.

  • Platform Service (IaC Pipeline)
    • Jenkins, Terraform, Ansible, Helm 사용
    • IaC code commit to Git repository
    • Jenkins trigger
      • Terraform) EKS Cluster Provisioning
      • Ansible) Kubernetes environment configuration using Helm
  • Application Service (CI/CD Pipeline)
    • Jenkins, React, Flask, ArgoCD 사용
    • App code commit to each Git repository (React/Flask)
    • Jenkins trigger
      • Dockerizing: App code > Docker Image
      • Image upload: Push image to AWS ECR
      • Tag Update: Apply new image tag to k8s manifest repository
    • ArgoCD Watch & Sync as each k8s manifest repository

AWS architecture

AWS

AWS 아키텍처에 대한 상세 설명입니다.

  1. 기존의 고객사의 VPC 환경이 있다고 가정한 뒤, (수동 생성)
  2. 해당 VPC에 시스템 운영 목적 VM을 생성하고,
  3. 자동화 Script를 통해 Jenkins, Keycloak, 필요 CLI들을 설치합니다.

이후 IaC Pipeline을 통한 빠르고 자동화된 Platform 구축 및 삭제가 가능합니다.

Kubernetes architecture

k8s

Kubernetes 내부 환경에 대한 상세 설명입니다.

  • 크게 4개의 논리적으로 구분된 Namespace를 사용합니다.
    1. Kube-system
      • Cluster Autoscaler > 클러스터 오토스케일링 목적
      • AWS ALB Ingress CNTLR > DNS NAME 기반 Redirecting 역할의 Ingress 생성 및 관리
      • ExternalDNS CNTLR > 배포된 서비스를 Route 53의 A 레코드 등록
    2. Monitioring
      • Prometheus > CPU,Memory,Disk 등의 시스템 지표 수집
      • Grafana > 수집된 지표를 Dashboard로 시각화
      • AWS EBS > 모니터링 컨테이너 장애시에도 데이터 영속성 확보
    3. Argo
      • ArgoCD > EKS 내부의 App 배포 관리
      • GitOps > 외부의 Git repository를 ssot로 사용. 관리자의 수동조작 가능성 배제
    4. Application
      • Frontend와 Backend가 각각의 manifest로 배포 및 관리
      • 클러스터 외부의 RDS에 필요한 데이터 읽기 및 쓰기

Application architecture

app

Application 구조에 대한 상세 설명입니다.

먼저 크게 Dashboard 서비스 와 Batch 작업으로 나뉘고,
Dashboard는 Frontend와 Backend로 나눌 수 있습니다.

사용자가 Dashboard로 접근하기 위해 DNS주소로 접속한다면,

  1. User Authentication & Authorization이 되지않아 조회 불가능
  2. ID/PWD 입력을 통해 User token 생성 (Keycloak 활용)
  3. Flask가 MariaDB의 저장된 데이터 활용, Dashboard 표출

저장된 데이터는 Flask에 의한 반복적 Batch 작업을 통해 생성됩니다.

  1. Flask에 내장된 Scheduler를 이용해 일정 주기로 작업 시작
  2. AWS API로의 HTTP Request/Response
  3. Promethus DB로의 PromQL
  4. 필요한 값 추출 및 필요한 형식으로 가공하여 RDS에 저장

Alert feature

alert

프로젝트에 적용된 알림 메시지 기능입니다.
파이프라인 작동 결과를 Slack/KakaoTalk 메세지로 수신할 수 있습니다.

Tech stack

techstack

프로젝트에서 사용된 기술 목록입니다.
계획, 코드, 빌드, 배포, 운영, 모니터 단계로 나누어 각각의 도구들을 사용하였습니다.

Presentation

발표시 사용하였던 프리젠테이션 Show 파일의 링크입니다.

ppsx 링크

Demo Video

발표시 재생하였던 시연 영상의 Youtube 링크입니다.

Youtube 링크

Categories:

Updated:

Leave a comment