K8s 도입하면서 겪은 일들

쿠버네티스, 도입배경과 배포

사용한 리소스

• Pod
• Service
• Node
• Ingress Controller (ALB)
• Deployment

왜 사용?

• 기존 VM에 유지했다가 → K8s로 운영을 하기위해서

도입 후 장단점

장점

• 설치없음
• 배포 편리 함
• 롤백에 대한 스트레스 ( IaC )
• Self Healing (OOM이 진짜 자주 발생함)

단점 : Pod / Deployment

• 마스터노드 / 워커노드 여러군데에 배포를 하니 → 결국 마스터노드에 CPU / MEM이 부족해져서 클러스터가중단되었음 → 워커노드에만 배포할 수 있도록 구성함 (taint)
• 노드가 먹통이 됨
  • 주황색이 리소스를 너무 먹어서 → Node 가다 죽음
  • 각 파드에 리소스 Limit을 넣어주면 됨

• 변경사항이 적용되지 않음 (배포)
  • watch로 보고있었는데 → 배포가 안됨 → 요지부동…
  • 자바 코드를 변경하지 않고 propery만 변경해서 → Docker Image가 변경되지 않았다고 판단했음
    • kubectl rollout restart deployment mynginx

• 심각 : 내 Pod가 다른 배치작업에 영향을 받았음 
  • 새벽에 배치작업을 하는 노드들이 장애가 발생함 (CPU, Memory) → 그 과정에서 다른 노드에서 문제가 됨…
  • operation = true 라는 레이블을 설정하면서, 노드중에 operation=true에만 배포하면 됨

• 내 pod가 한 노드에서만 구성이 되는경우가 발생…
  • K8s는 어차피 계속 운영할 수 있도록 옮겨줌 → 다만 1~2분간의 순단이 발생함
  • 노드에 배치를 잘 해주면 됨
  • podAntiAffinity
• 재배포가 안되는 상황
  • 파드가 2분동안 배포가 안되는 상황….
  • 새로운 파드가 배포될 곳이 없어서 기다리는 상태임 → 노드를 하나더 사용하면 됨…

단점 : Ingress

• ACL 문제
  • MSA구성하다보면 → 포트로 서비스를 분류한다
  • 주로 밤에 ACL문제가 발생한다.

• 포트가 기억이 안나는 문제
  • mynginx : 30010
  • yournginx: 30020
  • 기억이 안남 몇개월후면 → …
  • Ingress 기반의 Path 기반 라우팅을 사용한다면 해결됨 (Cluster IP)
    • FQDN (Fully Qualifeid Domain Name)

단점 : Liveness Probe / Readiness Probe

• 어플리케이션은 살아있는데 (Pod) 서비스가 비정상인 경우
  • Liveness Probe를 활용해서 → Pod를 HealthCheck를 해서 자동 재시작을 하게끔 해야함
• K8s는 배포하면 순단이 발생한다
  • Readiness Probe를 사용 → 컨테이너 준비 상태인지 확인을 하고 → 그 전까지는 트래픽을 보내지 않는다..
  • 준비가 되어야 트래픽을 보낸다

K8s 운영 팁

• Pod를 좀더 자세히보자
• 로그를 편하게 보자 - stern

AWS Lambda in GO

ASIS

• Slack Webhook을 받는 파이선 메인 서비스 존재
• Slack Webhook 서비스가 늘어남에 따라, 다른 요청들도 밀림 → 장애전파

• 분당 20,000건

• Slack 메시지가 밀리면서 장애 발생 → DB 부하 → 모놀리틱서버였음…
• Scale-up을 해서 해결했으나 → 굉장히 별로였음…

어떻게 고쳐야할까?

• 서버리스로 구성하자…
• Queue를 사용하자…
  • 요청을 받는 그대로 사용하면 DB가 죽으니 → 천천히 Consume 하자
  • 실패의 대한 모니터링 + 재처리를 구성해야 함

TOBE

AWS Resource

• API Gateway → 가장 먼저 요청을 받고
• AWS Lambda → MSK로 전달
• Amazon MSK → 큐로 핸들링
  • 메시지를 처리해도 → 왠만하면 남아있음…

어떻게 개발했나?

• golang으로 구성된 람다를 사용할때는 Kafka Producer를 사용하게 되는데
  • IBM/sarama를 사용 → 가능한 C Binding을 사용하지 않는 Pure Go를 선택
  • Confluenct는 Go를 사용하는데 → 인터페이스 과정에서 성능병목이 존재 + 크로스플랫폼 빌드가 존재…
• 람다 핸들러를 쉽게 구현하기 위해 → aws/aws-lambda-go를 활용
• …

결론

• Golang 람다 최종용량은 6.8MB
  • 코드크기가 50MB를 초과하면 S3를 이용해야 하는데 → Go Build는 용량이 작아 편리 → Docker로 배포가 더 편함
  • 평균 실행시간 500ms ~ 3000ms (카프카 플러쉬로 인해서 큼)
• Refactoring 해야할 부분
  • 실행시간을 줄이기 위해 → ARM 프로세서를 고려 (AWS Gravition 2)
  • 처리시간 줄이기 위해 → Lambda SIGTERM → Kafka flush 고민 중

Amazon EKS 아키텍처 구성하기 (심리스)

개발 & 운영을 하면서 겪는 문제

• 운영 배포가 실패했습니다.
  • 내 컴퓨터에서는 되는데?
  • Test / QA에서는 되는데?
  • 왜 운영에서는 장애가 나지?
  • 개발팀과 운영팀 내에서 책임과 회피가 발생한다
    • “너가 코드 바꿈”
    • “Devop가 배포 잘못한거 아님?”
    • 점점 풀수없는 문제들이 심화됨
• 배포 작업자의 실수로 서버가 날라감 (Terraform destory)
  • 통제불능이 되버림…

그렇다면 운영환경의 실수를 줄이기 위해서는 → GitOps

• Git Repository를 활용한 방법론
• Git Repository에서는 어떤 원하는상태의 근거로 사용한다
• Pull Request로 코드로 관리한다
• 의도한 상태 + 관찰된 상태 모두 자동화된 형태로 운영한다
• Git Repository를 활용해서 배포 / 관리를 진행한다
• Infrastructure as a Code
  • Terraform
  • Cloud Formation
  • CDK

왜 git 이어야 하는가?

• Git 자체는 기록이 모두 남기 때문에 모든 배포 과정이 graph로 그려진다.
• PR 자체를 사용하여 배포를 하기때문에 명확하다
• 배포 장애에 굉장히 신속하고 정확하게 대응이 가능한

GitOps 도구

• FluxCD
  • EKS Anywhere
  • MSA Operator
  • EventTrigger + Polling
  • Slack 외부 기타 시스템 Alert + Webhook
  • ECR을 쳐다보게 할 수 있음..
  • 개발자가 PR의 대한 자동화를 해줌

Progressive Delivery

• 지속적인 배포 → CI / CD의 속도를 기반으로 하는 배포 프로세스
• 정합성을 지속적으로 검사

Argo Rollouts

• 트래픽 형성기능 활용하여 업데이트 중에 트래픽을 점진적으로 제공
• 다양한 메트릭을 쿼리를 사용하여 + 롤백유도할수 있는 기능제공
• Kubernetes CRD를 통하여 A/B 테스트 가능
• 배포작업이 자동화 → Progressive Delivery

• 최고의 조합은
  • Istio + Argo Rollouts

정리

• Giops
  • Git을 활용하여 Operation Practice를 통칭
  • Continouse Deployment를 형상화하는 운영방법론
• Progressive Delivery
  • Continouse Deployment 진화된 형태
  • 기존 CD + Canary + BlueGreen 등 고급배포 방법론을 제공
  • Flagger
  • Argo Rollouts

EKS + Kinesis = CQRS (강남언니) 2024.6.6

EKS를 이용한 SAAS 서비스 아키텍쳐

해결해야 했던 문제

• Saas 효율화를 위한 → Multi Tenancy 환경을 구축해야 한다
  • Multi Tenancy → 단일 인스턴스가 여러 고객에게 서비스를 제공하는…
• 복잡한 도메인 서비스를 빠르게 개발 → 운영할 수 있어야 한다
• 각 제품의 대한 분리된 인프라 제공
  • 데이터 분리

Architecture

• IRSA
  • 서비스 권한 분리
  • https://somaz.tistory.com/238
• Secrets Store CSI Driver
  • 비밀키 관리

어떻게 시스템 분리를 하였는가? → Namespace 분리

EventSourcing + CQRS

• 강남언니는 어떤 요구때문에 CQRS를 적용했는가?
• 병원의 요구사항
  • 누가, 언제, 어떤 작업을 했는지 → 감사로그 → 필요
  • 매출 통계, 결제 내역 등 과거의 기반한 통계 → Zent에서도 필요
• 제품적 요구사항
  • 발생한 이벤트의 따라 달라지는 프로세스
  • 이벤트별로 제공되어야 하는 푸쉬알림이나 문자 메시지 → Zent랑 얼추 비슷함?

EventSourcing

• 일반적인 DB는 상태를 저장하고 → 상태를 계속 변경함 (Update…)
• EventSourcing 상태를 발생하기위한 모든 이벤트를 저장 → 상태 자체를 이벤트기반으로…
  • 이 이벤트를 차례대로 재생하면 현재의 상태를 알수있다
  • 계속 남긴다 그냥

디테일한 예시 (예약변경)

• 가장 최신의 이벤트로 만들어 낸다.
• 스케쥴이란 → 고객이 점유한 데이터를 그냥 스케쥴이라고 명명

• Kinesis를 Message Broker로 사용함

그런데, 허들이 있었다.

• 예를들어서 2월 13일의 스케쥴을 알고싶어
• 그럼 2월 13일에 모든 데이터를 읽어서 → 스트림 재생과정을 거쳐서 → 필터링 → 부하

허들을 극복 → CQRS (효율적인 조회모델)

• 명령과 조회를 각각의 모델을 사용함
• EventSourcing → EventSourcing 모델
• 조회 → 조회모델
• Kinesis DataStream을 구독하기 위해서 → Spring Cloud + Kinesis Client Library

왜 Kinesis Data Stream을 Message Broker로 사용했을까?

• MSK, Kafka, SQS 많은 서비스가 있는데 왜? KDS일까?
• 원래는 Apache Kafka를 고민했지만 → Kafka Cluster를 관리하는 리소스가 너무 큼
• 그리고 Kineiss가 더 쌈
• 메시지 처리량
  • SNS + SQS 기준은 선입선출 (초당 처리량의 한계가 존재함)
  • Kinesis는 충분한 Shard가 존재한다면 → 무제한임

Reference

• https://blog.gangnamunni.com/post/saas-enterprise-multi-tenancy

대규모 마이그레이션을 위한 전략 / Tool

개요

• 업무시스템을 Cloud로 옮기고 싶은경우
• Cloud 서비스가 제공하는 규정준수 / Scaling을 요구하는 경우
• 하드웨어 / 소프트웨어 교체
• 비용적인 측면

업무시스템을 Cloud로 전환하기 전 준비

• 현재 상태를 진단한다
  • 조직은 준비되어있는가?
  • 어떤 부분을 Cloud로 옮길것인가?
  • Cloud로 옮기면서 우리가 얻는것은 무엇인가?
• 계획을 수립한다
  • 포트폴리오 정리
  • 어떤 부분을 Cloud로 옮길 것인가? 마이그레이션 할 것인가?
  • Cloud 기초환경을 구성해야 한다(Network, Account, Service …)
• 마이그레이션 작업
  • 다수의 시스템을 동시에 진행 → 자동화 툴을 사용해야 한다

마이그레이션에 도움을 주는 AWS Service

1. 포트폴리오 정리

• AWS Application Discovery Service
  • 자료수집 서비스
  • Agent를 사용하여, IDC내의 서버의 정보를 수집한다
  • 수집한 정보를 기반으로 계획을 수립…
• AWS Migraiton Hub
  • 정보를 모이면 → 해당 Hub에 모인다
  • 해당 Hub에서 전략을 수립해준다.
  • 어떻게 마이그레이션을 할것인가?

2. 기초 플랫폼 구성

• 각각 VPC로 나누는 것보단, 계정을 나눠서 관리하는 것이 더 효율적임
• AWS Control Tower를 사용하는것이 좋음 (다중 계정 관리 + SSO + 작업추적 관리)

3. Relocate: VMware 마이그레이션

• VMWare를 사용하여, AWS로 Migration을 진행할 수 있음

4. Rehost: onPremise 서버를 AWS로 Migration (MGN 사용)

1. Source 에 AWS Agent를 설치
2. Source Disk에서 Staging AWS Cloud EBS에 실시간 복제 ( 압축 및 암호화 )
3. Staging EBS에서 Cut Over를 진행하면 → Migraiont Service가 실제 소스 서버로 자동변환
4. 시작된 인스턴스가 잘 동작하는지 확인
5. 소스 서버를 모두 마이그레이션하면 → Staging EBS및 Migation Service를 삭제 가능

5. 운영체제 및 미들웨어 변경

• AmazonLinux 및 ECS, EKS 컨테이너 기반으로 옮길수 있음
• Chef, Puppet을 사용한다면 → AWS Opswork를 사용하여 구성관리 가능

6. Database Migration

• AWS Migraiton Service
  • 동종 DB도 옮길수 있고 → 이종 마이그레이션으로 옮길수도 있음
• AWS Schema Conversion Tool
  • 자동으로 변환하여 → 예측가능한 방식으로 이기종 데이터베이스로 변환가능

7. 데이터 마이그레이션

• AWS SnowBall
  • 오프라인 데이터 전송 서비스
  • Onpremise 데이터 복사 → AWS 데이터센터로 데이터 이동
• AWS DataSync (실시간 데이터 Sync를 맞출 수 있다)
  • 네트워크 대역폭을 최적화하며 → Onpremise → AWS로 온라인 데이터 전송

Reference

대규모 마이그레이션을 위한 전략과 AWS의 도구들 - 이경원, 박기흥 솔루션즈 아키텍트, AWS :: AWS Summit Korea 2022

글로벌 채팅 서비스 (AWS Native)

Desc

• 천만 사용자를 위한 카카오의 AWS Native 글로벌 채팅 서비스

글로벌 채팅 서비스의 요구사항과 전략

• 글로벌 서비스 출시
• 빠른 개발을 위해서 적은인원으로도 Buildup이 가능해야했음 → 중요한것에 집중해라
• “정말 이게 될까?” 의 대한 빠르고 정확한 해답을 원했음

전략

• AWS 글로벌 Infrastructure
• Serverless (적은 인원으로도 빠르게)
• Prototyping (빠른 의견의 수용)

AWS Global Infrastructure

• AWS는 여러리전과 AZ를 제공한다.
• 이러한 Region들을 사용해서 각 지역의 사용자에게 빠르게 Serving 한다
• 100GbE 급의 네트워크 통신가능 (Direct Connect)
• 좋은 AWS 네트워크 설계 (어느한곳에 서비스가 끊겨도 → 다른곳을 이용해서 통신한다)
  • 고 가용성 확보 (Availaiblity zone) x ≥ 2

Serverless

• 소수정예 인원으로 빠르게 인프라를 구축해야 한다.
• 그렇다면 Management는 AWS에게 맡기고 구축 & 운영을 해보자

• AWS Lambda
  • 현재는 Lambda 자체가 비동기적인 EDA를 구축할수 있다.
  • API 기반의 HTTP, HTTPS 기반의 Serverless도 구축가능

• DynamoDB (채팅 데이터 및 메시지를 어떻게 관리할까?)
  • RDS도 고민했지만 그 수많은 채팅 메시지에 관계형을 쓴다는것은 좋은 선택이 아님
  • 오히려 빠르게 Update 되는 성격을 띄는 채팅 특성상 NoSQL이 적합했음
  • 인덱스만 안다면 데이터를 바로 뽑을 수 있음 O(1)

• AWS IoT (Client 들의 App의 대한 연결을 어떻게 진행하지?)
  • 결국 Mobile App은 여러가지 변수가 발생함
  • 출근길에 터널을 지난다든지 (네트워크 불량)
  • 집에서 사무실에서 다시 접속할때 (네트워크 변경)
  • 클라이언트 연결관리를 진행 함 → AWS IoT

정말 이게 될까?

• AWS에는 Prototype Team이 이미 존재
• 빠르고 바른 의사결정을 위한 AWS 내부 Team
  • 실제 상황과 아주 유사한 환경을 Test 함
  • 성능 검증까지 진행

실제 AWS Native 사례 (Global Chatting)

• 실시간의 성격이 뚜렷한 채팅서비스를 Serverless로 구축할 수 있을까?
• 1.5명의 인원으로 글로벌 채팅 서비스를 구축해야 했음

첫번째 시도 2018) API Gateway

• Amazon API Gateway가 Websocket을 지원함
• 기본적인 XMPP Server의 문제점은 Scale-out되는 구조가 되야하는데, 이러면 메시지 공유가능한 Broker와 Load Balancer가 필요함

구현 Lambda + API Gateway + DynamoDB

• AWS 서비스를 활용하여 관리포인트 감소
• 추가적인 요구사항
  • 접속 상태 확인 (과거)
  • 메시지 즉시 전달 (과거)
  • 메시지 보관 (현재)
  • 답글 달기 (현재)
  • 공지 (현재)
  • “좋아요” 달기 (현재)

• API Gateway + Lambda + DynamoDB를 사용해서, Scale-out을 빠르게 보장할수 있었음 (최고)
• 안티패턴 극복
  • RDBMS에서는 id라는 primary key를 사용해서 auto_increment로 사용
  • NoSQL에서는 pk개념이 없기 때문에, uuid를 사용해야 함

성공적인 결과 → 글로벌 서비스 구현 지원

• 서울, 도쿄, 북미 여러 리전에 접속한 유저들의 채팅에 있어서 분석결과
  • 주로 같은 리전에서 트래픽이 발생함 (언어가 통해야되기 때문에)
  • 간혹 다른리전에서 발생도 하긴 함
• Region을 넘어선 통신의 대해서는 아키텍처를 고려해볼만 함
  • Region 간의 API 호출 시 낮은 지연시간 ⇒ Amazon API Gateway ****
    • Region 과 Region 간의 통신이 가능함
    • 즉, A Regino에 Lamba가 B Region에 API Gateway 통신이 가능함
  • 다른 Region에 대한 정보는
    • AWS Lambda → API Gateway 를 통해서 가져옴
  • Region 간의 데이터 동기화
    • Amazon DynamoDB Global Table을 사용해서 진행
    • Region 간의 각각 테이블이 존재하면 동기화 하는 방식임

중국 → 중국은 AWS 내의 서비스를 대부분 지원을 하지 않음

• 중국은 CloudFront를 사용해서 Proxy 역할을 지원

동남아는 성공 ⇒ 글로벌 서비스를 위한 지원

• 요구사항
  • DAU 10,000,000
  • MAU 1,000,000
  • 서버리스를 사용하되, Quota안에서 동작가능하도록 설계해야 함 (기획 + 사업)
  • 유저의 수용 수가 커진만큼, 급격한 트래픽의 대해서 Stream Pipeline (Kinesis) 구축
• 아키텍처 설계

• 실시간 Pipeline
  • Amazon API Gateway + AWS Lambda + DynamoDB
• 대용량 트래픽 + Client Side의 대한 신뢰성 검증
  • AWS IoT Core (Client의 신뢰성)
  • Amazon Kinesis Data Stream
• 인증과 관련된 도구들
  • Amazon Cognito
  • AWS WAF

Reference

천만 사용자를 위한 카카오의 AWS Native 글로벌 채팅 서비스 - 김영욱 SA, AWS / Walter Kim 실장, Kakao :: AWS Summit Seoul 2023

EKS + 당근페이 Case + BNX Case

Kuberentes

• 컨테이너화된 워크로드와 서비스를 자동적으로 배포, 스케일링 및 관리 ⇒ 오케스트레이션 도구
• 자동화된 롤아웃과 롤백
• Self Healing ⇒ Replicaset
• Service Discovery + Load Balancing
• Bin Packing ⇒ K8s가 알아서 CPU, Memory, 공간 알아서 해줌
• Secret 관리 및 구성 관리

EKS

• 인증된 k8s 버전
• 관리형 쿠버네티스 환경 구축/

Problems

• K8s 업그레이드를 자주 해야 한다 ⇒ 업그레이드 이슈
• Amazon EKS 업글은 3~4개월마다 업그레이드 할때마다 이슈

Amazon EKS 업그레이드 순서

• Master Node
  • EKS master Upgrade
  • CoreDNS Upgrade
  • KubeProxy Upgrade
  • Amazon VPC CNI Plugin Upgrade
• Worker Node
  • 새 버전의 노드 그룹을 생성 → Pod를 이사시켜야 함…

Amazon EKS 업그레이드방법

• Single Cluter
  • 기존 클러스터내에서, 한 version씩 업그레이드 (계단식)
  • 1.15 → 1.16 → 1.17 → 1.18 각 버전당 40분씩 걸림 (Master Node) ⇒ 시간을 상당히 소요
  • 잘 동작하고 있는 기존 시스템을 크게 변경하지 않음
  • cordon, drain으로 무중단 업그레이드 가능 ⇒ 롤백은 불가능
  • 새로운 클러스터를 만들고, Traffic을 이전하는 방법
  • Traffic을 새롭게 이전해야 하는데, 굉장히 어려움
    • ALB를 Terraform으로 수정해서 쉽게 바꿈 ⇒ ALB + Terraform
    • NLB는 HA Proxy를 앞단에 두어 세밀한 설정을 가능하게 함 ⇒ NLB + HA Proxy
    • 결국 트래픽전환이 잘 되었는지는, Prometheus, grafana를 사용해서 모니터링 해야 함…
  • 업그레이드를 한번에 하니까 빠름 ⇒ 내부 시스템도 한번에 업그레이드 가능
  • 트래픽 조절만 잘하면 무중단 업그레이드 가능
  • 트래픽 조절만 잘하면 멀티 클러스터 운영도 가능
  • 트래픽 조절 ⇒ Terraform + HA Proxy
  • 언제든 이전상태로 롤백가능Multi Cluster

당근마켓 인프라 구축 Case

Desc

• 당근페이 === FinTech
• FinTech Infra ⇒ 어려움
• 금융 서비스 라이센스 문서 작업 + 감독 규정 + Compliance
• 보안성과 업무 효율성의 기반한 망분리
• 100% 클라우드 환경에 구축

1. 로그인 시스템 구성

• 계정별로 환경이 분리
  • 개발 계정
  • 운영 계정
• 로그인 할 수 있는 창구가 최소화
  • 로그인은 대표 계정 하나에서만…
  • Security 계정은 대표계정 ⇒ IAM만 존재
  • 로그인을 할려면 무조건 Security 계정으로 들어와야 함
  • 개발 / 운영 계정으로 Assume Role을 사용하여 넘어감
• 계정 탈취 시, 여파를 최소화
  • 탈취 되어도 볼수 있는 정보가 없도록..

AWS Login Use Zero Trust Concept

• Security 계정
  • EC2, RDS 이런 AWS Resource 아무것도 없음 ⇒ 무조건 IAM ⇒ 탈취해도 아무것도 못함
  • Assume role을 사용해서 들어가야 함…
  • { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::DEVAWSACCOUNTID:role/RoleNameInDevAccount", "arn:aws:iam::PRODAWSACCOUNTID:role/RoleNameInProdAccount" ] } ] }
• Dev / Prod 계정
  • IAM 사용자가 없음
  • 로그인 하는 경우는, Root 계정, Security → Assuming 형태로 들어갈 수 있음

2. 서버 접근

• 기본적인 서버 접근 방법은
  • SSH
  • Bastion Host + SSH 접근
• 약간 보완된 서버 접근방법
  • AWS Session Manager
  • Teleport
    • Kubernetes 방식으로 운용 할 수 있음…
  • Hashicorp Boundary
• Teleport (약간 Cloud Trail과 비슷함)
  • 유료도 있으나, opensource로도 존재…
  • RBAC 지원
  • github.com 인증 연동
  • 세션 레코딩 기능 ⇒ DataDog RUM과 같음
    • 로그인 한 사용자가, 어떤 행위를 했는지 다 보임 (지림)
    • 물론, 기본적인 linux history나 그런게 있지만 시각적으로 볼수있다는게 장점…

3. 애플리케이션 접근

• Kubernetes vs EC2
  • Kubernetes 너무 어려움… ⇒ hot한 이유가 있지 않을까?
  • EC2 너무 쉬움…
• EKS Architecture in 당근페이
  • ALB는 모두 Kubernetes Ingress
  • 마이크로 서비스 간 호출은 ALB를 통해 호출
  • 더욱 더 많은 Pod 내의 통신을 위해서 Istio를 고려를 하고있음

4. 배포 파이프라인

• Jenkins, TeamCity, Github Action 너무 좋은게 많지만,
• EKS는 왠만하면 ArgoCD, Github Action, ArgoWorkflow ⇒ Github 과의 연동이 쉽고 간단함
• 배포 파이프라인
  1. 소스 코드 업로드 및 PR 생성 (Github On-Premise사용)
     • EC2 자체의 대한 비용 (m5.4xlarge로 하였음)
     • EC2 Disk의 종속이 있음
  2. Github Action WorkFlow 동작 (Github Action)
  3. Github Action) ECR 업로드
  4. Kubernetes 매니패스트 Tag 업데이트
  5. Kubernetes 매티패스트 Tag 업데이트가 된걸 ArgoCD가 Check
  6. ArgoCD가 변경된 매니페스트를 EKS에 적용
• 해당 배포 파이프라인에서 사람손을 타는건 1~2 밖에 없음
• Github Action WorkFlow도 나쁘지는 않음 → 근데… Jenkins랑 별반다를거 없지만
  • Github / Gitlab + Jenkins (EC2 2EA)
  • Github (github Action) (EC2 1EA)

5. 관측 시스템

• DataDog (SASS)
• Elastic Stack (직접 설치)
• New Relic (SASS)
• Elastic APM (직접 설치)
• Prometheus (직접 설치)
• 원래라면 DataDog, New Relic을 사용하는것이 좋다 ⇒ 물론 비쌈
• 당근페이같은 경우에는, Compliance로 인하여 직접구축을 함

로그 시스템

• Elastic Stack (로그 수집 및 시각화)
• Prometheus ( 시스템 로그 수집)
• WorkNode에는 DeamonSet (FileBeat + Node Exporter)로 구축
• Node Exporter 외에 여러가지가 존재…
• FileBeat + LogStash + ElasticSearch + Kibana
• 여기서 중요한 건, Elastic Search를 제외하곤 모두 EKS로 구현
• Prometheus를 EKS로 구성하기 위해선?
  • prometheus-operator
  • 어떤 버전으로, 볼륨 구성의 관한것을 yaml 파일로 정의

APM 시스템

• Pod들 별로 APM Agent 별로 설치
• Elastic Uptime을 사용하여, 각 서비스들의 Endpoint들의 대한 모니터링

AWS Resource Monitoring

• 원래라면 CloudWatch + SNS + Lambda + Slack를 사용하여 구축
• CloudWatch + SNS + AWS Chatbot + Slack설정
• AWS Chatbot을 사용하면 좀더 편리하게 관리가 가능… Metric 이미지까지도 쉽게 전송이 가능함…

6. 성능 테스트

• 당근페이에서는 성능테스트를 굉장히 중요하게 생각함…. ⇒ 사실 중요하긴 함
• 성능테스트 도구
  • apache benchmark (HTTP / HTTPS 단의 부하테스트)
  • klocust (kubernetes 기반에 동작하는 오픈소스)
• 10분동안의 테스트를 통해 99 Percentile 응답시간이 100ms 이내일때의 최대 TPS
  • pod가 받아낼수 있는 최대 TPS
  • 즉 100ms 가 넘어가는 TPS를 측정한다
  • 우리는 얼마일까… 해볼껄…
  • 100ms 넘어가는 시점에서 ⇒ “우리의 pod는 N TPS이구나. 이시점에 알람을 걸어놓자…”

BNX Case (Traffic 대응)

• 갑작스럽게 발생하는 트래픽을 어떻게 대응할 것인가?
• Weverse의 ALB Request Count가 22:30 ~ 23:00 까지 2.72M 까지 올라감 ⇒ 평상시 100배
• 평균 거의 없는 수준임…
• 서버운영 어떻게 해야하지?
  • 한 순간을 위해 서버를 여러개 놔야 하나? ⇒ 비용 문제
  • Auto Scaling? ⇒ Auto Scaling을 쓰면 한 템포 느림 (5~10분 정도의 시간이 걸림) ⇒ 앱 버벅 및 느려짐 ⇒ 터짐

사전에 증설되는 순간을 감지할 수는 없을까? ⇒ Event Driven AutoScaling

• 이벤트에 의해 동작하는 오토 스케일링

Predefined Event : 미리 정의되어 있는 이벤트 ( MD 판매 이벤트 )

• 특정 아티스트의 MD 판매 이벤트는 언제 팔지 알기때문에 → 사전대응가능
• 스케일링의 업무 수작업은 → 업무 효율이 떨어짐 → Lamba로 구성
• 이벤트 등록을 하고, Lambda는 몇분, 몇시간동안 계속 이벤트를 조회
• 조건에 맞는 이벤트를 찾는다면, AutoScaling의 값들을 수정해준다…
  • Desired Count
  • Max
  • Min
• AutoScaling 한 결과를 Slack 채널에 결과를 전송

Undefined Event : 미리 정의되어 있지 않은 이벤트 ( 아티스트의 글 작성 )

• 아티스트가 글 작성은 사실 언제 작성이 될지 아무도 모름 ⇒ 사전 대응이 불가능
• Push는 GCP Cloud 같은 걸로 보낸다
• API Gateway를 호출한다 → Lambda 호출 물론, CloudWatch Cron을 사용해서 주기적으로 호출한다.
• Undefined의 종료조건은
  • 글 작성 후 30분후에 Auto Scaling을 원상복구

해결해야 할 과제… (아직 해결해야할 과제들이 많이 남아있음)

1. AutoScaling에 소요되는 시간의 최소화

• • ansible을 사용하여 Linux → 공통 설정 → FileBeat 설정 → API Server 구동 (전체 과정이 5분 소요)
  • 이게 AutoScaling을 하게되면 이러한 과정이 5분동안 진행된다는 관점이라면,
    • ECS + Step Scaling을 하는게 더 빠르겠네 (1~2분 이내의 증설) (METAPIXEL)
    • AMI를 미리 만들자.. (Golden Image)
  • 개선된 배포시스템
    • 이렇게 해서 전체과정이 3분정도 소요… → 하지만 목표는 1분안에 증설 완료
  • 배포 과정을 최적화

2. 증설되는 동안 최대한 버텨주기 (제발…) ***

• 인스턴스 성능 최적화
• 잘 튜닝된 t3.medium, 10개 c5.xlarge 안 부럽다.
• 성능최적화의 핵심은 모든 리소스를 최대한 활용하는 것
• 성능 튜닝 전 EC2 (장애상황)
  • 리소스가 펑펑 남아돔에도 불구하고 CPU 1% 차지않고도 에러가 남…
  •  
   
• OS와 애플리케이션 디폴트 설정으로 애플리케이션 설정에 영향을 받지 않아야 한다.
  • Too many open files
  • Too many connections
• 성능 튜닝 1
  • Application 에서 더욱 많은 리소스를 요구할때, OS Limit을 Full로 쓰게 만든다.

• 성능 튜닝 2
  • https://meetup.toast.com/posts/53
   
• Nginx 성능 튜닝
  • https://www.nginx.com/blog/tuning-nginx/
  • nginx 성능 중 가장 중요한 지표
  • c5.12xlarge를 데려와도 장애 납니다.
  • worker_processes도 실제 cpu core수만큼으로 돌려야 한다.
  • worker_connection도 늘려줘야한다.
  • worker_connections는 결국 client 와 server간의 역할을 담당하기 때문에 양을 늘려줘야 한다.

굿닥 AWS 전환사례

굿닥의 Pain Point

• 사내 서버 운영 관점에서 → 장애 상황에 대한 대응이 어려움
• 비즈니스 요구사항에 맞춰서 개발하다보니 → 언어 5개, 서버 1000+a, db 30+a
• 5000여개의 병원 클라이언트에게 보장가능한 신뢰성이 떨어질 염려가 있음
• 예측할 수 없는 트래픽 급등의 대해서 대처가 좀 힘들었음
  • 월 200(MAU)
  • 코로나로인한 비정기적인 트래픽급증의 준비가 미흡했음

어떻게 수정했어야 했나?

• Container
  • 언어 및 Framework에 종속적이지 않음
  • Runtime 시점에만 Container가 구동됨
• 만약? Container가 아주 많아지게 된다면?

- 규모가 커질수록 Container Cluster 환경을 구성하기에는 어렵다.
- Container 자체를 어떤 인스턴스에? 어떤 전략으로? 배치하는 방법이 필요하다.
- 시스템의 모든 상태를 알아야 한다.

AWS Container Orchestration

• 두 서비스의 공통점
  • Control plane을 AWS에서 직접 관리한다
  • Data Plane 모두 AWS에서 관리하기 때문에, 편하게 인프라를 관리한다
  • image Registry는 Docker hub / ECR을 사용한다.
• ECS
  • control-plane : ecs-agent
• EKS (굿닥은 이걸 사용함)
  • control-plane : kubelet
  • open source의 kubernets를 관리하지않는다 → 직접 구성 X
  • aws는 4개의 kubernetes minor 버전을 지원 → upgrade 버전까지 시간을 충분히 줌
  • control-plane의 보안, 확장성을 제공 → 가장 어려움

굿닥 + EKS 여정

• 배포, 모니터링, Convention 등 여러 언어와 프레임워크를 대응하기에는 어려웠음
• Service Oriendted Architecture (2022) ⇒ 개별 서비스에 집중하는 아키텍처 스타일
  • 재사용 가능한 모듈을 서비스 별로 만들어서 → 비즈니스에 맞게 → 서비스 모듈을 키워나감
  • 1개의 DB, 1개의 언어, 1개의 Framework로 통일을 진행
  • 동작방식
    1. ALB Ingress에서 트래픽 분산
    2. Auto Scaling을 통해서 Container 수 조절 → 처리
    3. EKS Cluster → Container Orchestraion을 처리
    4. 각각의 Endpoint에서 해당 로직을 처리
    5. Database (Amazon Aurora MYSQL) 복구 기능 추가
  • 이를 통해 얻은점
    • 관리 리소스 절감 → 파편화 되었던 리소스를 줄였음
    • 모니터링이 더 수월함
    • Convention 통일을 통해서 복잡성 감소
  • 한계점
    • 배포 주기가 길어짐
    • 하나의 DB에서 모든 서버가 의존

• Micro Service Architecture (2023) → 마이크로 서비스 도입
  • 하나의 Context안에 Service + DB를 묶어준 후 → Gateway로 통신
  • 각각의 서비스는 독립적으로 운용 + 배포 ⇒ Agility를 높일 수 있음
  • 각각의 서버와 DB를 운영하기 때문에 → 각각의 팀이 존재
  • endpoint 와 ec2 안에 gateway만 생김

AWS Data Lake 구축하기

어떻게 적재할 것인가?

1. 각각의 데이터가 Bronze Data로 Ingestion 되기 위해선 format이 다 다르다.
2. 각각원하는 형태가 있고 로그형태가 다르다..

• S3로 적재한다
• AWS내의 Data Engineering은 S3에서 시작해서 S3에서 끝난다고 할 수 있다.
• Athena를 통해서 SQL 질의도 가능하다
• QuickSight를 통해서 의사결정의 대한 BI를 구축할 수 있다.

Easy DataLake Architecture

• 고객행동로그 → WebServer
• Transaction Data → Database
• 유저 행동로그 → GA
• 외부 데이터 → Google Spread Sheet

S3 + Glue Cralwer + Athena

• S3 → Glue → Athena
• S3 서비스를 통해서 만든 저장소 ( Data Lake )
• Athena는 Serverless Query Service
• S3 데이터가 많기때문에 Partitioning이 되야한다.

Webserver Pipeline

• WebServer는 Kinesis Firehoes를 사용하여 Data Pipeline을 구축할 수 있다.
• 대용량의 트래픽이 발생할 경우 Kiensis Firehoes 만으로는 힘듬 (Buffer가 있으나 대용량은 벅참 + Kinesis Data Stream 함께 써야 함)
• Kinesis Firehoes를 사용해서, Data Format도 가능하다.
• Webserver에서는 Kinesis Agent를 설치할 수 있음
• Kinesis 에이전트를 사용하여 Kinesis Data Firehose에 쓰기 - Amazon Kinesis Data Firehose
• Kinesis DataStream Shard 2개면 왠만한 양은 버틸 수 있음
  • 하루 25,000,000 양의 데이터
  • Kinesis DataStream shard * 2
  • Kinesis Firehoes
  • 200$ 남짓

Database Pipeline

• 고객의 OLTP 데이터를 수집하는 방법
• DB Data Pipeline Architecture는 여러가지 방법이 존재
  • (실시간) DML 관련된 데이터를 수집하기 위해서는 → AWS DMS + Hudi or Iceberg
  • (배치) AWS Glue Job을 사용해서 하루 1회 Batch 할 수 있음
  • 실시간에 가까워질수록 운영이 어려움
• 빠르게 분석환경을 도입하기 위해선 Lambda Connector를 사용한다면, Direct로 DB데이터를 조회 가능
• 만약, DB 데이터가 대용량이라면 부하가 발생할 여지가 존재 → 대용량이면 이러한 architecture는 별로임..
• Lambda Connector는 Athena 서비스를 통해서 만들 수 있음

GA Pipeline

• GA는 행동기반 로그에 가깝다
• 실질적인 데이터를 얻기 위해서는 OLTP 데이터랑 합쳐서 봐야한다.
• AWS Glue Connect는 다양한 소스와 연결이 가능하다.
• Bigquery에서에 데이터를 S3 데이터로 옮겨올수 있다.

BI (데이터 시각화)

• QuickSight
• Personalize