5월16일, 5월17일에 열린 AWS Summit Seoul 2024 에 다녀왔습니다. 저는 5월 17일만 다녀왔는데 다녀온 후기입니다

메일로 받은 QR코드를 찍고 입장하면 네임택을 줍니다. SRE, 데브옵스 그리고 시스템엔지니어까지 하고있지만 저는 시스템엔지니어로 role을 적어서 그렇게 나왔습니다.

9:30 키노트 연설

9시 30분부터 키노트 연설이 시작됩니다. 3층의 오디토리움에서 진행되는데 영상과 AWS 수석테크 에반젤리스트, 인프랩 CTO 이동욱님, 센드버드 CTO 구정진님 그리고 AWS의 CTO Werner Vogels, Matt Wood의 연설을 들을 수 있었습니다. 키포인트로 잡은 것중 하나가 Frugal Architect(검소한 아키텍트) 였습니다. 온프레미스 환경에 존재했던 하드웨어 제약을 없애고 클라우드 환경에서 구축이 쉬워지고, 확장성과 유연성이 높은만큼 비용이 생각 보다 클 수 있는데 그러한 점을 모두 고려해 제약조건을 둔 아키텍쳐를 Frugal Architecture라고 합니다. 주니어 엔지니어로써 인지해야할 포인트라고 생각했습니다. (우리회사는 온프레미스환경이지만요)

또한, 지속적 아키텍쳐 변경을 통해 비용절감에 대한 부분도 얘기했습니다.

• Stop : 안 쓰는 리소스 중단
• Reduce : 불필요한 기능 줄이기
• Rightsize : 사용량에 딱 맞는 컴퓨팅 선택
• Shift : 가성비 높은 컴퓨팅 옵션 선택

11:10 플랫폼 엔지니어링 기반 개발자생산성 극대화

이후 11시10분부터는 원하는 강연을 찾아가서 들으면 됩니다. 저는 커뮤니티 섹션의 플랫폼 엔지니어링 기반 개발자 생산성 극대화 세션을 들었습니다.

플랫폼 엔지니어링 이란

생산성을 높여주는 IDP(Internal Developer Platform)를 구축하는 엔지니어를 말합니다. 예를들자면 Jenkins와 같은 내부 개발자 혹은 직원을 위한 플랫폼이 IDP의 예라고 할 수 있습니다.

키 포인트로는

• 셀프 서비스 : 처음부터 끝까지 혼자 할 수 있어야 함
• 카탈로그(문서화) : 쉽고 자세히 작성된 문서를 통해 오늘 입사한 개발자도 셀프서비스가 가능해야함
• 효율성, 비용 최적화

등이 있었습니다. 저도 사내에서 SRE업무를 하면서 똑같은 업무를 여러번 해야할 때가 있고, 개발자들에게 요청이 들어와 하나씩 처리하다보면 퇴근이 늦어질때가 있는데 이러한 부분을 개선하기 위한 플랫폼을 구축해 개발자가 셀프서비스가 가능하게 된다면 업무의 효율성이 높아질것 같다 생각해서 관심도가 높아졌습니다.

12:00 점심

입장할때 선착순으로 런치박스 티켓을 같이 주는데 저는 일찍도착해서 티켓이 있어서 런치박스를 먹었습니다. 펜네 파스타, 치킨샌드위치, 불고기랩등 꽤 맛있고 구성이 좋아서 맛있게 먹었습니다.

1:10 Karpenter로 쿠버네티스 클러스터 최적화: 비용 절감과 효율성 향상

점심을 먹고 오후 세션은 데브옵스 섹션의 Karpenter로 쿠버네티스 클러스터 최적화: 비용 절감과 효율성 향상세션을 들었습니다. 저는 굉장히 작은 규모의 쿠버네티스 클러스터를 다루고 있지만, 들어두면 좋을거 같아서 들었습니다.

Karperter란?

Karpenter는 AWS로 구축된 유연한 오픈 소스의 고성능 Kubernetes 클러스터 오토스케일러입니다. 애플리케이션 로드의 변화에 대응하여 적절한 크기의 컴퓨팅 리소스를 신속하게 실행함으로써 애플리케이션 가용성과 클러스터 효율성을 개선할 수 있습니다. 또한 Karpenter는 애플리케이션의 요구 사항을 충족하는 컴퓨팅 리소스를 적시에 제공하며, 앞으로 클러스터의 컴퓨팅 리소스 공간을 자동으로 최적화하여 비용을 절감하고 성능을 개하게 됩니다. 참고

요약하자면 쿠버네티스 클러스터 오토스케일러입니다. 리소스가 많아지면 그에 맞게 업스케일을 하고 적어지면 다운스케일을 하는 그러한 기능을 가지고 있습니다.

Karpenter의 동작 방식은 와 같습니다.

Karpenter의 노드 생성은

• Pod 생성에는 시간이 소요
• 확장 윈도우 알고리즘 : [1,10]초
• 유휴 시간 : 1초
• 최대 10초까지의 보류중인 Pod들을 단일 배치로 구성

확장을 할 때, 10초의 시간동안 기다리며 보류 Pod를 기다립니다. 만약 그 10초내에 다른 보류 Pod가 생기면 그 Pod들을 묶어 단일 배치로 구성합니다. 그리고 그 배치를 묶는 사이의 유휴 시간이 1초이며 이를 확장 윈도우 알고리즘이라고 합니다.

또한 빈 패킹 이라는 것이 있는데 빈패킹은 의 순서를 가지고 있습니다.

• 노드풀과 Pod 요구 사항의 교집합 정의
• 호스트 포트, 볼륨 토폴로지, 볼륨 사용량 고려
• 데몬셋 스케줄링 고려
• 더 적은 수의, 보다 큰 인스턴스 타입 선호
• 사용률 최적화가 아닌 비용 최적화

다음은 의사 결정입니다

• EC2 생성(가용 영역 + 용량타입 + 가격)
• 다양한 인스턴스 우형 정의를 통한 유연성 확보
• 온디맨드 할당 전략 : lowest-price
• 스팟 할당 전략 : price-capacity-optimized

또한 Drift기능이 있는데 Drift는

• EC2NodeClass 기본동작
  • 동일한 EKS 버전에 대한 신규 AMI 출시
• AWS는 해당 정보를 AWS System Manager에 업데이트
• Karpenter는 Parameter store를 지속적으로 감시
• Karpenter Drift 매커니즘에 의해 워커 노드의 AMI가 롤링 방식으로 업데이트

그리고 노드오버프로비저닝 전략을 통해 효율적인 스케일링이 가능합니다.

• Pod우선순의 (PriorityClass)
• 가용 영역 분산 (TopologySpreadConstraints)
• Pod 안티 어피니티 (PodAntiAffinity)
• KEDA를 활용한 Pod 스케일링 (CPU 코어 수)

예를들자면, 더미 Pod2개를 PodAntiAffinity를 통해 각 다른 노드에 배치 시켜놓습니다. 그 상태를 지속적으로 감시하다가 업스케일링이 될 시, 만약 4개의 Pod배치가 들어온다면 노드의 빈자리에 넣고 또 다른 노드 2개를 생성해 더미 Pod가 위치하게됩니다. 사실 말로만 들어선 무슨 말인지 잘 감이 안오는데 그림으로 함께 보면 조금 더 이해가 쉽습니다.

2:20 다양한 측면에서 보는 Observability

다음 세션은 DataDog의 데브옵스 컨설턴트 이노훈님이 진행한 옵저버빌리티 세션에 참여했습니다.

4가지의 골든 시그널 - LETS

• Latency : 요청을 처리하는데 얼마나 소요되었나요?
• Errors : 처리에 실패한 요청이 얼마나 되나요?
• Traffic : 얼마나 많은 요청이 들어오고 있나요?
• Saturation : 현재 서비스가 얼마나 처리하고 있나요?

현재 회사에서 SRE업무를 하면서 Zabbix, Prometheus, Grafana등을 사용해 모니터링과 알림을 구축했는데 현재 가장 많은 시간을 쏟고있는분야라 관심이 많이 갔습니다. 강연자체는 DataDog의 기능을 소개하는 부분이 많았지만 저에게도 적용할 수 있는 부분이 많아 보였습니다.

가장 공감? 이 갔던 부분은

“문제가 될 만한 부분은 전부 알람을 설정했는데, 근데 매번 자다가 알람 받고 일어나는 생활이 최선인건가…”

서버 엔지니어라면 모두 공감할 만한 것이라고 생각합니다. DataDog에선 Synthetic Test등의 기능으로 제공을 하지만, 만약 회사가 DataDog을 사용하지 않는다면 이러한 부분은 스크립트를 통해 자동화 하여 어느정도 부분은 해결이 가능하다고 생각합니다.

또한, 모니터링의 범위를 단순 시스템의 정보를 모니터링 하는것이아닌 좀 더 넓은 범위 예를들자면 APM(Application Performance Monitoring) 혹은 보안적인 부분도 모니터링을 해 Observability를 구현 할 수 있다면 좋다고 생각했습니다.

사진에서 볼 수 있듯이, DataDog 로고가 붙어있는 부분에 모니터링을 적용한다면 Observability구현에 한걸음 더 가까워 질 수 있을것 같습니다.

3:20 인텐트 기반 네트워크 인프라를향한 AWS의 여정

원래 Serverless 활용: 스타트업의 효율적 개발 환경 구축을 듣고 싶었는데, 커뮤니티 섹션이 장소가 작기도 하고, 자리가 다 차서 인텐트 기반 네트워크 인프라를향한 AWS의 여정을 들었습니다.

인텐트 네트워크란

인텐트 Intent는 한국어로 “의도"라는 뜻입니다. 즉, 네트워크에 기대하는 어떠한 행동을 의미합니다. 인텐트 네트워크의 이점으로는

• 일관성
• 가시성
• 민첩성
• 운영성

이 있습니다. CI/CD 파이프라인처럼 요청이 들어오면 인텐트 네트워크 파이프라인을 따라 가기 때문에 사람의 개입을 낮추고 운영 복잡성을 낮춰서 관리를 쉽게 합니다.

위 사진과 같은 사이클을 가지고 따라가게 됩니다.

또한 AWS의 네트워크 소프트/하드웨어 커스텀에 대한 이야기도 있었는데, 커스텀 스위치, 커스텀 광랜모듈, 커스텀 네트워크 OS까지 정말 대단하다는 생각이 들었습니다.

뒤로 갈 수록 AWS제품 홍보에 대한 느낌밖에 안들어서 5분정도 남기고 나왔습니다.

4:30 AWS Expo

4:30분 타임에는 관심있거나 듣고싶은 세션이 없어서 엑스포 구경을 했습니다. DataDog, Splunk, Aws Enterprise등 돌아다니며 스티커도 받고 에코백도 받고 명함홀더도 받고 했습니다 ㅎㅎ 문닫는 부스들이 많아서 조금 일찍 들릴껄 하는 생각도 들었습니다. 다음에 AWS컨퍼런스를 가게 된다면 좀 더 일찍 들리리라 다짐했습니다.

5:20 DevOps의 혁신: Amazon EKS를 활용한 플랫폼 엔지니어링 적용하기

마지막 세션은 DevOps의 혁신: Amazon EKS를 활용한 플랫폼 엔지니어링 적용하기 저에게 새로운 관심사가된 플랫폼엔지니어링에 대한 세션을 들었습니다.

플랫폼 엔지니어링이란?

• 내부고객 (개발자)
• 셀프서비스 API와 도구, 서비스, 지식 및 지원을 기반으로 정리된 매력적인 내부 제품
• 외부 서비스를 구축하듯이 내부 서비스를 구축한다
• 내부 플랫폼 구축의 장점
• 속도 : 고객에게 새로운 애플리케이션을 제공하는데 걸리는 시간 단축
• 거버넌스 : 애플리케이션 팀이 클라우드에서 안전하고 안전하게 운영하도록 지원
• 효율성: 효율적인 리소스 사용 및 전문화를 통한 비용 최적화

위의 4개의 방법중에서 어떤 방법이 맞고 틀리다는 없지만, 어느것이 효율적이다 라고 할 수는 있을것 같습니다.

내부 플랫폼 구축의 장점

• 속도 : 고객에게 새로운 애플리케이션을 제공하는데 걸리는 시간 단축
• 거버넌스 : 애플리케이션 팀이 클라우드에서 안전하고 안전하게 운영하도록 지원
• 효율성 : 효율적인 리소스 사용 및 전문화를 통한 비용 최적화

내부 플랫폼 구축 시 고려사항

• 소유권
• 추상화의 수준 (어느 기능, 수준까지 추상화를 할 것인지)
• 도입
• 문제 해결

구현 패턴

• 모든것에 적합한 만능 접근 방식은 없디.
• 제품으로 플랫폼을 다루기 (외부에 서비스하듯이 내부 플랫폼을 서비스)
• 셀프 서비스로 제공 (처음부터 끝까지 개발자 혼자 할 수 있을 수준으로 제공)
• 템플릿과 문서로 골든 패스를 제시
• 실행가능한 플랫폼으로 만들기
• 점진적으로 개선해가기

이중 문서를 만드는 이유는

• 업무를 처리하는 시간 < 업무에 필요한 정보를 찾는 시간 이 되면 안되기 때문입니다. 장점으로는
• 명확한 소유권 (책임), 정보접근성 향상 등이 있습니다.

플랫폼 엔지니어링이 제공하는 가치

• 셀프서비스 지향 : 인지 부하 감소
• 소프트웨어 카탈로그 : 정보 접근성 향상
• 가드레일 : 자율성과 거버넌스
  • 가드레일을 두어 사용자의 과도한 사용을 제한해 거버넌스를 준수합니다.
• FinOps : 비용 최적화
  • 측정되지 않은 시스템은 알 수 없는 비용을 만든다. 그렇기에 Frugal Architect를 적용해 비용최적화를 합니다.
  • 사용자가 비용적인 측면도 볼 수 있는 대쉬보드 구축으로 (가드레일) 비용 최적화

등 사진도 많지만 다 올리기엔 너무 많아서 이정도로만 정리하도록 하겠습니다.

마무리

처음가본 AWS컨퍼런스 입니다. 제 생각보다 더 재미있었고 새로운 방법론들을 많이 배웠습니다. 특히 Frugal Architect와 플랫폼 엔지니어링은 한동안 저의 큰 관심사가 될 것 같습니다. 읽어주셔서 감사합니다.