안녕하세요.
이번 주말에 코엑스 쪽에서 열린 AWS Community Day Korea 2025에 참석해서 좋은 시간을 보냈는데요.
세션에서 얻은 인사이트를 공유 드리고자 글을 남깁니다.
입장하자마자, 많은 기념품들을 나눠주셨는데요. 텀블러와 키캡, 간식이 들어있는 AI 개발자 전투식량은 아이디어가 재밌어 받자마자 웃음이 나왔습니다. 이 외에도 스폰서로 참석해 주신 메가존 클라우드, GS 네오텍, Splunk, Snowflake에서도 기념품을 나눠주셨습니다. 세션에서 많은 것을 배웠는데, 선물까지 주시니 감사할 따름이었습니다!
이번 행사는 '아키텍처', 'AI엔지니어링', '베이직' 이렇게 3개의 트랙으로 진행됐습니다.
각 트랙별 세션 내용은 아래의 이미지를 참고하시면 되겠습니다.
저는 시스템 엔지니어로 근무 중이라, 인프라와 자동화에 관심이 많습니다.
최근 진행하는 프로젝트에서 GPU 서버와 Kubernetes(이하 쿠버네티스)를 다루다 보니, 이와 관련된 세션을 참석했습니다.
인상 깊었던 세션과 인사이트를 공유 드리겠습니다.
1. Splunk를 통해 LLM/GPU 모니터링하기
observability for AI 가 필요한 이유
LLM 모델을 자체 개발하여 서비스에 심을 수 있으면 좋겠지만, 자체 LLM 모델을 개발 및 학습/추론시키기 위해서는 막대한 인력과 비용이 발생합니다. 그렇기에 현재 대부분의 서비스가 그러하듯이 Hyperscaler(이하 하이퍼스케일러)의 LLM Model(OpenAI GPT 등)에 의존하게 됩니다. 이 경우, 내부 Logic이 어떻게 되며, 정보는 어떻게 관리 및 처리되는지 알 수가 없는 'Black Box(이하 블랙박스)' 구간이 발생할 수밖에 없습니다. 하지만, 우리가 하이퍼 스케일러들의 LLM 모델들의 내부를 직접 볼 수는 없습니다. 이러한 문제를 해결하기 위해서는 서비스에 탑재된 AI가 어떤 상태인지, 성능은 어떤지를 모니터링하는 것이 중요합니다. 즉, Observability를 확보하는 것이 중요합니다. 이 과정에서 도움을 받을 수 있는 것이 Observability for AI입니다.
이를 솔루션으로 제공하는 것이 Splunk이며, 애플리케이션 수준의 모니터링이 아니라, 인프라 및 하드웨어 수준의 모니터링도 가능하다는 점이 인상 깊었습니다. 시스템 엔지니어로서 인프라는 물론, GPU 사용량/온도 등 하드웨어 수준의 모니터링이 가능하다는 점에 흥미가 갔으며, 실제로 현업에서도 서버내 특정 GPU 장애로 고생한 적이 한두 번이 아니라 모니터링에 대한 필요성을 느끼고 있었습니다. 연사님께서 해당 내용은 OpenTelemetry(이하 오픈 텔레메트리)를 활용한 것이라고 언급을 하셔서 이를 활용해서 하드웨어 수준의 모니터링을 학습해 봐야겠다는 목표가 생겼습니다.
2. EKS Karpenter, Graviton을 활용한 비용 최적화 여정
Graviton
AWS EC2 인스턴스 중 Graviton(이하 그라비톤) 패밀리는 x86/amd64 기반 아키텍처가 아닌, arm64 기반 아키텍처를 사용하는 인스턴스입니다. 그라비톤 인스턴스를 사용할 시, x86/amd64 인스턴스 대비 성능은 높이고 가격은 20% 낮출 수 있다고 AWS는 안내하고 있습니다. 연사님께서 운영 중인 x86/am64 아키텍처 인스턴스로 구성된 EKS 클러스터는 CPU 사용량 대비 비용이 높았다고 하셨습니다. 이에 따라, 비용 최적화를 위해 그라비톤 인스턴스로 Migration(이하 마이그레이션)을 진행했다고 말씀해 주셨습니다.
그라비톤으로 마이그레이션 시 단순히 CPU 아키텍처만 바꾸는 것이 아니었습니다. CI/CD 파이프라인과 EKS 상에서 사용 중인 Third-Party(이하 써드파티) 오픈소스 구성요소 등이 arm64을 지원하는지 검증하고, 보장하도록 하는 것이 중요했다고 하셨습니다. 특히, 운영 중인 애플리케이션이 Java 기반이라 jdk 버전에 따른 arm64 지원여부가 중요했었다고 말씀해 주셨습니다.
마이그레이션 시 Blue-Green(이하 블루-그린) 패턴으로 진행하셨습니다. 기존 EKS 클러스터를 운영 중인 상태에서, 그라비톤 인스턴스를 사용하는 EKS 클러스터를 생성하여 점짐적으로 트래픽을 이전함으로써 다운타임 및 장애 없이 마이그레이션을 성공할 수 있었다고 하셨습니다.
작년, 부트캠프에서 EKS 클러스터를 학습하고 프로젝트에서 운영했던 경험이 있습니다. 부트캠프 중 AWS 월 사용 예산을 초과했던 적이 있어, 비용 절감이 중요했었습니다. 이에 따라, 비용 최적화를 위해 스케일링을 활용했었는데, 그라비톤 패밀리를 사용하면 더욱 절감이 가능했을 것 같다는 생각이 들었습니다. 추후, AWS 인스턴스 생성 시 그라비톤 패밀리 사용을 기본으로 활용하는 것을 고려해 봐야겠습니다.
Karpenter
기존에는 Cluster Auto-Scale(이하 클러스터 오토스케일)을 사용했었다고 하셨습니다. 이 경우, 노드와 파드가 스케일-아웃된 후 사용하지 않는 파드들이 존재했고, 이 때문에 비용이 과다 발생하는 경우가 많았다고 하셨습니다. 이를 해결하기 위해 Karpenter(이하 카펜터)를 활용하셨습니다.
카펜터는 쿠버네티스 노드를 동적으로 관리하는 오픈소스 도구입니다. 카펜터의 distruption 설정을 적절히 정의하여, 트래픽 또는 Work-Load(워크로드)가 줄어드는 경우 여러 노드에 소수로 분산돼 있던 파드들을 하나의 노드로 통합하고 불필요한 노드(EC2 인스턴스)를 제거함으로써 비용 최적화를 이뤘다고 하셨습니다.
카펜터를 도입하고 비용 최적화는 이뤘지만, 카펜터가 동작하는 과정에서 문제가 발생한 경우도 있다고 말씀하셨습니다. 카펜터를 도입하고 난 뒤, 쿠버네티스의 노드 교체가 잦아졌고, 이 과정에서 주요 애플리케이션이 다운되는 것을 방지하기 위해서 PDB, PodAntiAffinity를 적절히 설정하는 것이 중요하다고 하셨습니다.
3. 아직도 서버관리, 수작업하세요? AWS 서비스로 딸깍
정영진 연사님을 패스트캠퍼스 오프라인 세미나에서 뵌 이후로, AWS KRUS DevOps 소모임 참석도 하며 자주 뵙고 있는데요. 물론, 혼자만 팔로잉하는 중이라 저를 아실지는 모르겠지만 이번 커뮤니티 데이에서도 정영진 님께서 발표를 하셔서 세션 참석을 했습니다. 다른 장소에서 들은 정영진 님의 발표들도 모두 유익했지만, 시스템 엔지니어로서 일하고 있는 저에게 이번 발표는 더욱 유익한 시간이었습니다.
세션의 대상을 수동 SSH 패치와 반복적인 서버 설정 작업에서 벗어나고 싶어 하는 '서버 운영의 고통을 직접 겪는 사람들', SSH 포트를 제거하고 패치/규정 준수 현황을 자동으로 리포팅하고 싶어하는 '안전하고 효율적인 운영을 원하는 사람들', 현대적인 클라우드 서버 운영과 자동화 기본 개념을 배우고 싶은 분들로 특정하셨습니다. 저는 클라우드 환경은 아니지만, 온프레미스 환경에서 물리적인 서버와 OS를 설치한 뒤, 필요한 설정을 하는 작업이 주 업무이기에 크게 공감되는 내용들이었습니다. 이러한 작업들이 소수의 서버일 때는 자동화 프로세스를 구축하는 시간에 직접 수동으로 하는 것이 빠르지만, 10대만 넘어가도 수동으로 하기엔 너무나도 힘든 작업들입니다. 더불어 Human Error(휴먼 에러)도 무시할 수 없고요.
AWS Systems Manager
서버관리를 AWS 상에서 자동화하기 위해 AWS Systems Manager(이하 시스템스 매니저)를 소개해주셨습니다. 시스템스 매니저는 SSH/RDP 없는 안전한 대규모 서버 운영 자동화가 가능한 서비스라고 하셨습니다. SSM Agent를 사용함으로써 SSH(22), RDP(3389) 포트를 외부에 열어둘 필요가 없어서 보안 향상도 가능하며, SSM Document 기반 선언형 자동화가 가능한 것이 가장 큰 장점이라고 하셨습니다.
시스템스 매니저에서 주로 사용하는 기능은 Session Manager(세션 매니저), Parameter Store(파라미터 스토어), Run Command(런 커맨드), State Manager(스테이트 매니저), Distributor(디스트리뷰터) 등이 있다고 하셨습니다.
Session Manager
- 제일 많이 사용하시는 기능이다.
- 로컬 환경에서 Shell(이하 셸)로 Bastion Host를 거치지 않고, 네트워크가 뚫려 있다면 접근 가능
- Bastion, SSH Key가 필요 없어지며, 인바운트 포트를 열어두지 않아 보안 향상 가능
- 모든 세션은 S3와 CloudTrail을 통해서 추적 가능
Parameter Store
- 설정값, DB 암호, API키 등을 저장하는 중앙 관리 저장소
- Config를 코드/인스턴스로부터 분리 가능
- 파라미터 스토어에 저장된 값을 ArgoCD 등에서 안전하게 참조 가능
- IAM을 통해 접근제어, 암호화, 변경 이력 추적 가능
Run Command
- 이름에서 알 수 있듯이, 복수의 인스턴스를 대상으로 동시에 명령 실행 가능
- 권한만 가지고 있다면, 하나의 계정에서 다른 계정으로도 명령 수행 가능
State Manager
- 주기적으로 Document에 정의된 동작을 수행함으로써, 인스턴스를 의도한 상태를 유지하도록 보장 가능
- SSM Document(이하 SSM 도큐먼트)를 통해 인스턴스 상태를 명세
- Systems Manager가 인스턴스에 대해 수행할 작업(Step)들을 JSON 또는 YAML 형식으로 정의한 문서
Distributor
- 소프트웨어 패키지를 중앙에서 안전하게 저장하고 버전을 관리 가능
- 디스트리뷰터 자체는 패키지만 저장하고, 패키지를 인스턴스에 설치하려면 SSM Document 내 AWS-ConfigureAWSPackage)를 사용
AWS Systems Manager는 EC2 환경에 기본 설치돼 있기 때문에 무료에 가까우니, 적극 사용을 권장하셨습니다.
4. Amazon EKS 장애, 이렇게 해결하세요.
해당 세션은 AWS에서 근무 중이신 Cloud Support Engineer 세 분이 함께 발표해 주셨습니다. IT 인프라 엔지니어라면 누구나 목표로 가지는 AWS에서 근무 중이신 분들께서 진행한 세션이라 집중해서 들었습니다. 발표는 EKS 관련된 내용이었는데요. 3가지 EKS 관련된 시나리오를 가정하고, 이를 클라우드 서포트 엔지니어로서 솔루션을 제공하며 EKS의 새로운 기능들을 소개하는 방식으로 진행됐습니다.
시나리오#1
상황 및 고객 Needs
- 고객 측 DevOps Engineer 측에서 Dev, Staging, Prod 3개의 EKS 클러스터를 운영 중
- 클러스터, 노드와 같은 인프라 수준의 모니터링 외 애플리케이션 수준의 모니터링도 원함
- 서비스 간 의존 관계 시각화를 원함
- 관리가 편하기를 원함
솔루션
- Appications Signals 활용하면 해결 가능
- 올해 5월에 EKS 통합 완료
- AWS Integration, Service Dashboard, Application Map 등을 통해서 모니터링 가능
- SideCar 컨테이너를 파드에 붙이는 등 애플리케이션 변경 없이 수행이 가능
시나리오#2
상황 및 고객 Needs
- EKS 노드 장애 시 이슈 분석에 시간이 오래 걸림. 단축 방법 탐색 중.
- 자동으로 이슈를 복구할 수 있는 솔루션을 원함.
- 복구 과정 모니터링을 원함.
솔루션
- Auto Repair를 활용하면 해결 가능
- EKS 클러스터에 Add-On 형태로 쉽게 설치 가능
- 노드 모니터링 에이전트를 통해서 애플리케이션 변경 없이 모니터링 수행 가능
- 노드 그룹 상태를 모니터링하고 자동 복구 가능
- 감지된 문제에 대한 복구 동작을 커스터마이징 가능
- 추가 비용 없이 사용 가능
시나리오#3
상황 및 고객 Needs
- 이슈 분석 시간이 오래 걸림
kubectl,aws-cli사용이 익숙하지 않음- AI를 활용해서 문제를 해결해보고 싶음
솔루션
- Amazon Q Developer + EKS MCP Server를 활용하면 해결 가능