끝난지 한달이 넘어가는 시점에서 남기는 AWS 서밋 서울 2024 후기입니다. 하하..
유튜브에 영상이 올라오기 전에 얼른 적어보겠습니다!
서밋 2023에서는 알아듣지 못하고 듣고 흘렸다면 올해는 그래도 단어가 귀에 들어와서 몇개의 세션을 재미있게 듣고 왔습니다! 1일차에 코엑스를 다 돌아다니면서 2만보를 걷다보니 체력 부족으로 놓친 세션들이 많아 아쉬운데 어서 유튜브에 업로드 됐으면 좋겠습니다.😆
[L300] 채널톡 스타트업 기술 성장기: RDBMS에서 NoSQL로의 전환
MongoDB를 사용하면서 NoSQL을 경험했고 전환 과정에서 어떤 고민을 하셨을지, 왜 전환하셨는지 궁금해서 찾아갔습니다.
AWS의 NoSQL 서비스인 DynamoDB와 완전관리형 메시지큐 서비스인 SQS를 함께 사용하여 트래픽을 감당하는 NoSQL을 구현하기 위해 고민한 사항들과 과정/결과를 소개해주셨습니다.
DynamoDB
NoSQL과 서버리스의 특성을 가지는 DynamoDB의 특징은 다음과 같습니다.
1. 일정한 레이턴시와 무제한에 가까운 처리량 및 저장 공간으로 대규모 성능을 커버할 수 있습니다.
2. 데이터 암호화와 글로벌 복제를 통해 안정성과 탄력성이 높습니다.
3. 서버리스로 완전관리형고 무버전으로 관리가 용이합니다.
4. S3, Lambda 등 타 AWS 서비스와 통합이 용이합니다
5. Zero ETL을 지원합니다. (추출, 전환, 적재(ETL) pipeline 없이도 Opensearch cluster data 가공해서 삽입 가능)
6. OLTP workload(동시발생 트랜잭션 처리)는 Openshift로 분석 워크로드가 따로 필요합니다.
SQS
완전관리형 메시지 큐인 SQS는 사전 프로비저닝이 필요하지 않다는 특징을 가지며 두가지로 나눌 수 있습니다.
1. 표준 대기열 - 무제한 처리량, best effort ordering, 최소한 한 번 전달
2. FIFO 대기열 - 높은 처리량, 정확히 한 번 처리
AWS DynamoDB + SQS → Better Together
= 피크 트래픽을 SQS 비동기 처리로 해결!
세션에서 B2C 상담을 지원하는 '채널톡'이라는 서비스에서 이벤트 기반 추천 메시지와 일회성 메시지로 트래픽이 증가하면서 마이그레이션을 결정하게 되었고 기존 RDS Scale Up과 NoSQL로의 전환에서 다음은 고민하셨다고 말씀하셨습니다.
- RDS Scale UP?
1. 스파이크 트래픽 ⇒ 비용 비효율
2. 부하 전파 (FK - 특정 테이블의 부하가 다른 테이블로 전파)
→ 독립적으로 동작했으면 좋겠다 !- NoSQL?
1. 오퍼레이션 호환성
→ 채팅에서 신경쓸 부분들 - 알림 숫자 + 알림 숫자들의 합
2. 마이그레이션 비용
→ 다운타임 없이.. 가능...?- 추가 고려 사항 - 이벤트 소싱 & AWS와의 풍부한 연동
채널코퍼레이션의 Amazon DynamoDB와 함께한 아키텍처 현대화 여정 – 1부
AWS 기술블로그에 구현에 관한 사항들은 채널코퍼레이션의 상황과 목적에 맞게 자세히 설명해서 세션에서 인상적이었던 전환에서의 고민과 선택지만 적고 간단히 줄이겠습니다.
[L100] DX의 필수인 쿠버네티스를 안정적으로 운영하기 위한 옵저버빌리티 구축 여정
쿠버네티스와 옵저버빌리티에 궁금한 점이 많아 세션 주제에 끌렸고 이제 시작하는 단계여서 L100 세션에서 얻어갈 것이 많다고 생각해 찾아갔습니다. 주제가 주제인 만큼 입장 줄이 매우 길었습니다..
가장 먼저 쿠버네티스를 쓰게 되는 과정을 소개하셨습니다.
- New Tech → Business Innovation → Develop Faster → Deploy Faster
⇒ 자동화 CI/CD 필요- 앱 의존성이 높으면 CI/CD마다 문제 발생
⇒ MSA 고려- VM 활용 MSA - 자원 비효율적이고 느림
⇒ 컨테이너 활용 - OS 미포함으로 가볍고 빠르며 런타임 환경과 라이브러리로 높은 이식성
⇒ 컨테이너 오케스트레이션 → 쿠버네티스
쿠버네티스는 아래에서부터 Node 위에 K8s layer 위에 Pod 안에 애플리케이션과 소프트웨어가 구동되며 모니터링할 사항들을 리스트업하셨습니다.
- Node
- K8s layer - Control Plane (관리 컴포넌트)
- Pod - 최소 배포 단위
- 컨테이너화된 애플리케이션
- 지속적으로 생성되는 로그와 K8s 이벤트
그리고 쿠버네티스 옵저버빌리티를 위해 Metrics, Trace, Log에서 고려해야할 사항을 설명하셨습니다.
Metrics: 주요 리소스 지표 정보 확인 → 상태 확인 + 미래 예측
- k8s 내부 지표 정보 수집, 저장 툴 설치
- 과도한 데이터로 필요한 지표 선정이 필요
- 업데이트 주기가 빨라서 꾸준한 지표 관리가 필요
Trace: 내부 앱 상태 추적, 확인
- APM(application performance management) 설치
Log: 각 지점의 현재 상태 + 돌발 상황 대처
- 컨테이너/애플리케이션 로그 수집, 저장 → 조회, 검색 구축
추가 고려 사항: Integration & Add-on
- 단일 view, 대시보드 구축 + 알림 환경 구축 + 각종 보고서 리포팅 환경
- 서버 스토리지, 모니터링 데이터, 보안성 등 관리
이 이후로는 WhaTap의 K8s 모니터링 서비스 소개가 이어져서 가볍게 듣고 마무리했습니다.
[L300] GS리테일 Amazon EKS의 모든 것: 무중단 운영부터 배포 자동화까지
아직 쿠버네티스를 완벽하게 이해하지 못한 것 같아서 아쉬웠던 느낌이 있지만 L300인 만큼 쿠버네티스의 아키텍처부터 차근차근 자세하게 설명해주신 점이 아주아주 흥미로웠습니다..!!!
먼저 GS리테일 측에서 사용하는 도구 소개로 주로 볼 수 있는 CI/CD, IaC, 쿠버네티스를 활용하고 있음을 확인하고 발표가 시작되었습니다. GitOps 방식으로 ArgoCd를 통해 EKS로 배포하고 있었습니다.
EKS 클러스터를 구성할 때 다음과 같은 장단점을 고려해야하며 클러스터 수가 많아질수록 서비스별 클러스터 전략으로 확장성을 높여야한다고 말씀하셨습니다.
- 대규모 공유 클러스터 전략 - 워크로드를 Namespace별로 구분
장점: 관리가 쉽다.
단점: 단일 실패 지점 존재 - 서비스별 클러스터 전략 - 워크로드를 클러스터별로 구분
장점: 장애 영향도 감소
단점: 관리가 복잡함
EKS 클러스터 이중화
업그레이드 시, 로드밸런서 변경 관련 이슈
- CloudFront에 재등록
- ALB가 재생성됨에 따라 Route53 cname 변경 필요
- Ingress 재구성에 따라 새로운 ALB 생성
- Load Balancer의 생명 주기는 Ingress Controller에의해 관리됨
위와 같은 과정에 따라 "로드밸런서를 사용자가 관리하는 방식으로 변경"하여 클러스터 외부에서 로드밸런서를 생성, 유지 관리하고 ALB, Target Group, DNS 설정은 Terraform에 의해 관리한다고 하였습니다.
더하여 TargetGroupBinding을 이용하여 POD-Target Group을 직접 바인딩하고 Ingress의 라우팅 기능을 ALB에서만 처리합니다.
Active-Active 이중화를 위해 멀티 클러스터(v1, v2)를 구성하고 ALB 리스너의 가중치를 기반으로 Target Group을 설정하여 (50:50) EKS 클러스터 업그레이드 시. 트래픽을 진행합니다.
EKS 클러스터 이중화를 통해 서비스 영향 없이 무중단 업그레이드가 가능해졌습니다.
Active-Active 클러스터 구조 장점
= 업그레이드, 기술 테스트 용이
중단 시간 0 hour / 기술적 부채 감소 (최신 버전 유지 - 장기적인 관점에서 비용 효율)
더 나은 관리, 보다 효율적인 자원 사용, 더 나은 스케줄링
CI/CD
EKS 클러스터 이중화 뿐만 아니라 개발팀과 인프라팀의 협업에서 CI/CD의 개선도 설명하셨습니다.
과거에는 Jenkins, Bambee 등의 툴을 활용하여 Build와 Deploy가 합쳐져있고 kubectl set image를 이용하여 이미 존재하는 POD를 업데이트 하는 수준의 배포가 이루어졌고 여기서 등장한 팀별 어려움은 다음과 같습니다.
- 개발팀 - 쿠버네티스 기본 수준을 이해해야 함
- 인프라팀 - 매니패스트 형상관리가 안되고 빠른 롤백이 어려움
결국 개발팀과 인프라팀 사이의 Roles And Responsibilities가 모호해지고 팀별로 인프라와 CI/CD 도구가 달라 복잡성이 높아지며 개발팀의 배포 모니터링에 쿠버네티스 이해가 필요하게 되어 진입장벽이 생긴다는 문제가 생겼다고 소개하셨습니다.
이를 위해 "커스텀 배포 API"를 만들어 개발팀이 API 로 데이터를 전송하면 요청 정보를 쿠버네티스 매니패스트인 yaml 형식의 템플릿으로 변환하여 활용하면서 해결하였으며 개발팀에서 단순 API를 호출하는 것으로 배포를 관리할 수 있게 되었습니다.
이 방법의 장점으로 R&R이 정리되었고 기존의 문제였던 복잡성과 진입장벽이 해소되면서 개발팀이 개발에만 집중할 수 있게 되었다고 설명하셨습니다.
기존의 Helm과 Kustomize를 활용하여 정적 템플릿 설정 값을 동적으로 반영하여 K8s 리소스를 생성할 수도 있지만 구조가 변경되면 다수의 템플릿을 수작업으로 수정해야하는 문제가 있었고 이 문제는 위와 비슷하게 SQL query를 기반으로 일괄 변경하는 템플릿 변환 엔진을 자체 개발하여 해결하였다고 소개하셨습니다.
GS리테일의 배포 프로세스 변화 과정을 아키텍처로 보면서 개선을 체감하고 템플릿 변환 API와 엔진 자체 개발이라는 점이 세션을 들으면서 매우 흥미로웠습니다.
아직 많이 부족해서 이해하려고 노력하는 단계에 그치지만 K8s 클러스터 관리를 새로운 시각으로 볼 수 있었고 더하여 이중화의 필요성과 비용을 비교하는 중에 완전관리형 서비스가 이중화에 큰 강점이 될 수 있다는 점을 알게 되어 좋았던 세션이었습니다.
이번 서밋이 작년 서밋과 달리 코엑스 전체적으로 퍼져있어 체력 때문에 많은 세션을 듣지 못한 게 아쉬워서 유튜브에 올라오면 다시 들어보고 싶고 작년보다 재밌는 얘기가 더 들리기 시작한 점이 기뻤습니다. 그리고 아무래도.. K8s를 더 깊이 이해해서 대규모 서비스에서 활용해보고 싶다는 열망이 생기기 시작해서 좋았습니다...!
