22. AWS-리테일, 커머스-카카오스타일-컨테이너
ECS-> EKS로 마이그레이션 한 경험 공유
ECS와 EKS의 특징을 잘 알려준다.
사이트신뢰성엔지니어, 카카오스타일
우선 AWS의 이커머스 요구사항 설명
<1> 이커머스 요구사항
<2> 이커머스 현대화
<3> 마이크로 서비스 컨테이너 알아보기
<4> 컨테이너 오케스트레이션 ECS, EKS
<5> 카카오 스타일 ECS-> EKS로 마이그레이션 한 경험 공유
<6> EKS 아키텍처
<7> ECS에서 EKS로 마이그레이션 과정
<8> 트러블 슈팅
<9> 실습
<10> 개인 정리
<1> 이커머스 요구사항
1
민첩성?
ux와 비즈니스 로직 분리
더 빠른 빌드-테스트-배포
2
융합?
채널 전반에 걸친 데이터의 가시성
공유 비즈니스 로직이 있어야 한다.
3
경험?
빠르고, 확장 가능하고, 가용성과 보안성
추천 부분 중요
<2> 이커머스 현대화 4가지
클라우드 네이티브
마이크로 서비스 컨테이너
서버리스
목적에 맞는 데이터 베이스
<3> 마이크로 서비스 컨테이너 알아보기
1
컨테이너란?
런타임 + 애플리케이션 코드 + 정적 파일 + 코드 패키지 + OS패키지 -------- 컨테이너 빌드--컨테이너 레지스트리, 컨테이너 이미지----컨테이너 실행
2
애플리케이션 네트워킹 = 서비스 검색 및 서비스 매시?
AWS Cloud Map, AWS App Mesh
3
매니지먼트 = 컨테이너화 된 애플리케이션 배포, 스케줄링, 확장 및 관리?
ECS , EKS
4
호스팅 = 컨테이너가 실행되는 곳?
EC2, Fatgate
5
이미지 레지스트리 = 컨테이너 이미지 저장소?
ECR
<4> 컨테이너 오케스트레이션 ECS, EKS
1
ECS
용량 제공자 사용
AWS Copilot로 빠르게 시작하기
AWS Copilot 명령줄 인터페이스(CLI)는 로컬 개발 환경에서 Amazon ECS를 기반으로 프로덕션 지원 컨테이너화 애플리케이션을 간단하게 구축, 릴리스, 운영할 수 있는 명령을 제공합니다.
https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/AWS_Copilot.html
Fatgate로 관리 줄이기
2
EKS
EKS 관리형 노드 그룹으로 걱정 덜기
3
ECS or EKS or K8s on EC2 중 선택?
자유도 낮음 , 효율성 높음 = ECS
자유도 보통, 효율성 보통 = EKS
자유도 높음 , 효율성 낮은 = K8s on EC2
<5> 카카오 스타일 ECS-> EKS로 마이그레이션 한 경험 공유
1
회사 소개?
크로키 닷컴
여성 쇼핑몰 지그재그
2021 카카오 합류
2
SRE팀?
인프라, 개발, DBA, 화이트 해커로 팀구성
AWS를 기반으로 배포, 로깅, 모니터링, 데이터베이스, 시큐리티를 담당함.
3
빠른 스케일링 대응 필요
ECS 사용 중
다음과 같은 이유로 EKS로 전환.
오픈 소스 사용가능 - Argo, Helm , Lstio 사용가능
확장성 - 빠른 확장성, Karpener 오토스케일로 사용.
서비스 유연성 - 멀티 클라우드 사용 시. AWS 디펜던시가 적다.
인재 채용 - 쿠버네티스에 관심이 있는 인재가 많다.
4
변경 전 ECS?
80개의 마이크로 서비스
cloudwatch logs , opensearch, datadog
ecr, jenkins, github
변경 후 EKS?
EKS기반으로 변경
오토스케일링은 카펜터 사용.
로깅은 fluentbit , kinesis firehose, opensearch, datadog
CI/CD는 ecr , argo CD , github actions
// 젠킨스 대신 argo 롤 아웃과 argo cd를 사용 중
<6> EKS 아키텍처
1
CI/CD?
argoCD
argo Rollouts
CA(cluster auto scaler) 제거
Karpenter 사용
2
Network?
VPC CNI(기본 제공)
CoreDNS (기본 제공)
Cert Manager
istio 제거
ALB ingress controller 사용
3
Logging?
fluentbit 사용
cloudwatch logs 제거
kinesis data firehose
opensearch
4
monitoring?
datadog
마이그레이션 10개월 소요됨
카펜터는 auto sacling group에 대한 디펜던시가 없다.
istio 제거 - 네트워크 관련된 이슈를 찾는데 시간이 걸림. 숙련도가 필요해 우선 제거.
firehose가 20배 정도 저렴. 클라우드 와치 로그는 리밋이 있어 제거.
<7> ECS에서 EKS로 마이그레이션 과정
1
1단계 ?
EKS 서비스 타깃 그룹 생성
서비스별 EKS 구성함
ECS ALB에서 weighted routing으로 트래픽 전환
EKS Network lb에 트래픽 발생 하지 않음
2
2단계
모든 서비스가 구성된 새로운 EKS 클러스터 구성
route53으로 DNS A레코더를 변경
DNS Cache를 처리하여 전환- DNS캐시가 있는 애플리케이션이 많다. DNS캐시 만료시켜야 한다. 애플리케이션 재시작.
<8> 트러블 슈팅
1
bin packing?
pod는 정상 증가, node 증가 잘됨.
node 잘 줄어들지 않음.
카펜터의 인스턴스 타입 변경, ttl 설정이 효과적
2
하드 리밋 이슈(AWS Quota)?
변경되지 않는 하드리밋으로 문제 되어 cloudwatch logs 대신 키네시스로 변경
Cloudwatch logs - putlogsevents API (스트림당 4 트랜젝션으로 오류)
3
보안그룹 룰 제한
보안그룹 수 * 룰 = 1000개가 하드 리밋이다.
디폴트 보안그룹이 5개이고 룰이 200개이다.
룰을 250으로 변경하려면 보안그룹은 4개로 해야 한다.
이경우 모든 계정의 서비스에 적용되므로 주의해야 한다.
4
네트워크 로드밸런서 리스너 률은 50개로 제한이 있다.
로드밸랜렌서 1개로 묶고자 할 때 주의.
5
다양한 튜닝?
dns lookup 에러 이슈?
Conntrack(iptables 상태 추적) 이슈 - 네트워크
클러스터 전환 후 잦은 dns lookup 에러
인스턴스마다 conntrack limit 이 다름 (패킷 드롭됨)
인스턴스 타입을 네트워크 타임으로 변경함 ( c6gn.2 large)로 변경해서 해결.
ethtool -S eth0 | grep exceed
conntrack_allowance_exceeded : 3234735
6
Use_kubelet 모드 활성화 - fluent -bit 사용 시
core dns request가 매우 높아 core dns 개선 필요.
fluent -bit 사용 시 발생 = srv 레코드로 질의를 많이 함.
use_kublet mode 활성화 kube-api 대신 kublet 사용하여 core dns 거치지 않도록 변경.
core dns request 감소함.
fluent -bit은 데몬 셋으로 떠있는 리소스라 node와만 통신하고 output으로 소스를 보내 주기만 하면 됨.
내부 통신을 할 필요가 없음.
7
타깃 그룹 바인딩의 속도 개선? aws-load-balaner-controller
lb pod가 target group에 binding 되는데 시간이 오래 걸림.
targetgroupbindingMaxexponentialBackoffDelay 옵션을 1000-> 30으로 조정.
8
access-log중요성?
dns A 레코더 변경 시
애플리케이션에 dns cache가 있는 경우 access-log 확인 요망
inblund 트래픽 확인하고 완료 필요.
istio는 envoy proxy 로그로 확인.
alb ingress는 k8s에서 확인
alb로그 활성화 하고 s3에 있는 로그를 아테나로 쿼리 하여 확인
<9> 실습
https://brunch.co.kr/@topasvga/1769
<10> 개인 정리
ECS로 서비스 만들어 보자.
ECS를 EKS로 전환해 보자.
<8> 트러블 슈팅 부분 모두 확인하자.
스터디용으로 좋을 거 같다.
https://brunch.co.kr/@topasvga/2882
감사합니다.
