AWS re:Invent 2023, 관심 세션을 중심으로 (2편): Cost Optimization, Observability

AWS re:Invent 2023, 관심 세션을 중심으로 (2편): Cost Optimization, Observability

요약: 이 블로그는 빌리와 댄이 AWS re:Invent 2023에 참석한 경험을 나눕니다. 이번 AWS re:Invent 2023 주요 키워드는 Generative AI로, Amazon Q와 Amazon Bedrock 같은 새로운 제품과 기능들이 소개됩니다. 빌리는 AWS re:Invent에서 경험한 비용 최적화 세션을 통해 클라우드 환경의 비용 효율화에 대한 중요성과 다양한 전략들을 깊이 이해하게 되었다고 느꼈습니다. 댄은 Observability 세션에서 시스템의 안정성과 신뢰성을 유지하는 데 필수적인 옵저버빌리티의 개념과 적용 방법에 대한 중요한 통찰을 얻었다고 말합니다.

시작하며

안녕하세요. 카카오페이 자산플랫폼파티 셜록, 허브FE유닛 클로이, 인프라플랫폼팀 빌리, 기술전략팀 댄입니다. 저희는 카카오페이 기술 직군을 대표하여 2023년 11월 26일부터 12월 1일까지 5일 동안 개최된 AWS re:Invent 2023에 참석하게 되었습니다. 저희는 각자 다른 팀에서 일하고 있는데요, 이 글에서는 공동 저자 각자의 지극히 개인적인 관심 주제를 기준으로 Aurora DB, Amplify, Cost Optimization과 Observability에 대해 정리하고 느낀 점을 공유해보고자 합니다.

AWS re:Invent 2023
AWS re:Invent 2023

이 글의 내용은 1편과 2편으로 나누어져서 게재하며, 본편은 2편으로 Cost Optimization, Observability에 대해서 이야기하겠습니다. 1편 글은 아래 바로가기를 확인해 주세요!
👉🏻 AWS re:Invent 2023, 관심 세션을 중심으로 (1편): Aurora DB, Amplify 바로가기

본격적으로 후기를 공유하기에 앞서 AWS re:Invent 2023 키워드를 살펴보겠습니다. 이번 AWS re:Invent 키노트와 여러 세션들을 살펴보면, 주인공은 Generative AI임이 분명합니다. 이에 더해 기존 제품들에 새로운 기능을 추가하거나, 새로운 제품의 베타 버전을 공개했어요. 기존의 다양한 엔드투엔드(end-to-end) 라인업 솔루션에서 새로운 기능이나 업그레이드된 기능들을 소개하면서, AWS의 Generative AI 솔루션들을 특히 강조하고 있는데요. 이러한 다양한 AWS 솔루션들은 생성형 AI 기반 어시스턴트인 Amazon Q에 연결되어 더욱 강력한 사용자 경험을 제공하고 있습니다. (참고)

또한, Amazon Q를 위한 머신러닝 엔진을 제공하는 도구로 Amazon Bedrock을 소개하고 있는데 이 제품은 머신러닝 모델을 선택하여 원하는 형태로 커스터마이징 할 수 있다는 점을 강조하고 있습니다. 즉, Amazon Bedrock을 통해 이 제품에서 제공하는 다양한 머신러닝 모델 중 내가 원하는 서비스에 적합한 모델을 선택하여 서비스에 적용할 수 있게 됩니다. 그럼 AWS re:Invent 2023 키워드 소개는 이것으로 마치고, Cost Optimization 관련 세션 후기부터 공유드리겠습니다.

Cost Optimization

카카오페이에서 클라우드와 오픈소스 소프트웨어를 담당하고 있는 빌리입니다. 클라우드 환경은 대부분 귀찮거나 어려울 수 있는 운영 및 구축에 대해서 손쉽게 만들어줄 수 있도록 최대한 사용자에 맞춰 서비스를 출시합니다. 그러한 서비스들 중 대표적인 형태가 serverless 형태의 서비스들을 예로 들 수 있겠는데요. 이번 AWS re:Invent 2023에서도 elasticache serverless 형태를 발표함으로써, 사용자가 리소스 타입, Cluster Mode 등에 대한 고민 없이, 콘솔에서 몇 번의 클릭만으로 서비스를 생성할 수 있게 되었습니다.

ElastiSearch Ondemand & Serverless
ElastiSearch Ondemand & Serverless

사용자에게 고민거리를 줄여줌으로써 더욱 개발에 집중할 수 있게끔 서비스를 제공하고 있는데요. 이렇게 사용자에게 쉽게 제공에 대한 장점은 또 다른 단점을 야기할 수 있습니다. 그 단점 중 하나가 예상치 못한 비용이 발생할 수 있다는 점입니다.

그렇다면 비용이 많이 발생하는 것이 마냥 단점이라고만 할 수 있을까요? 비즈니스에 필요한 서비스 이용 비용이라면 당연히 비용을 지불해야 함은 누구나 이견이 없을 것입니다. 하지만 지불하고 있는 서비스 비용이 알맞은 비용인지에 대한 판단은 별개의 이야기일 것입니다. 저희 카카오페이에서도 클라우드 비용 효율화를 위해 고민하고 있었고 이러한 고민에 대해 AWS re:Invent 2023를 통해 도움을 받을 수 있었던 세션 및 키노트에 대해서 설명드리도록 하겠습니다.

Amazon CTO Dr.Werner Vogels Keynote: The Frugal Architect

Amazon CTO Dr.Werner Vogels Keynote에서는 탄력적이고 비용을 인식하는 아키텍처를 설계하기 위한 모범사례를 다루었는데요. 모범사례에 대해 The Frugal Architect라는 명칭으로 7가지 법칙에 대해 소개를 했습니다. 해당 법칙은 세 가지 큰 주제로 나눠서 이야기할 수 있는데요. 아래와 같이 확인해 볼 수 있습니다.

  • Design
    • 비용을 비기능적 요구사항으로 만들 것
    • 비즈니스에 맞게 비용을 지속적으로 조정하는 시스템
    • Architect 는 일련의 절충안
  • Measure
    • 확인되지 않은 시스템으로 인한 불필요 비용 발생
    • 비용 인식 아키텍처로 비용 제어 구현
  • Optimize
    • 점진적인 비용 최적화
    • 도전받지 않은 성공은 가설로 이끌어진다.

요약하면, 성공적인 비즈니스는 비용을 빼고 이야기할 수 없다로 정리할 수 있습니다. 첫 아키텍처 구성부터 비기능적 요구사항으로 비용을 비즈니스 로직에 포함하고, 모든 리소스를 관찰해서 불필요 여부를 확인할 수 있어야 한다고 하면서, 지속적으로 비용 최적화를 위해 노력하고 관리하는 것이 얼마나 중요한지를 설명하고 있습니다.

AWS는 myApplications, Cost Optimization Hub와 같은 서비스를 제공하면서 이러한 검소한 Architect를 위한 일련의 과정들을 관리하게끔 도와주고 있는데요, 먼저 myApplications부터 살펴보겠습니다.

myApplications

해당 서비스는 AWS에서 애플리케이션의 비용, 상태, 보안 상태 및 성능을 보다 쉽게 관리 및 모니터링할 수 있도록 도와줍니다. 이를 위해 Applications 위젯을 생성하고 리소스를 추가하면 되는데요, 리소스를 추가하면 awsApplication 태그가 적용되어 myApplications 대시보드가 자동으로 생성됩니다. 대시보드가 생성되고 나면 몇 가지 유용한 위젯을 제공하게 됩니다.

비용 및 사용 위젯은 설정한 태그에 맞춰 현재 및 예상 월말 비용, 상위 5개 청구 서비스, 월별 애플리케이션 리소스 비용 추세 차트를 포함하여 AWS Cost Explorer의 AWS 리소스 비용 및 사용량을 시각화합니다. 지출을 모니터링하고 이상 현상을 찾아내며 필요한 경우 클릭하여 조치를 취할 수 있습니다.

Billing and Usage Widget
Billing and Usage Widget

컴퓨팅 위젯은 애플리케이션 컴퓨팅 리소스 정보 및 Cloudwatch의 추세 차트를 요약합니다.

Computing Widget
Computing Widget

모니터링 및 운영 위젯은 애플리케이션과 관련된 리소스, SLO 등의 경보 및 알람을 표시합니다. 보안 위젯은 AWS Security Hub에서 가장 우선순위가 높게 보안을 식별한 결과를 제공합니다. 그리고 Devops 위젯은 상태관리, 패치관리, 구성 관리 상태를 보여주어 사용자가 규정 준수를 평가하고 조치를 취할 수 있도록 도움을 줍니다.

Monitoring and Operations Widget
Monitoring and Operations Widget

위와 같은 서비스를 이용하여 비즈니스에 대한 시각화를 진행하여 비용 및 서비스 지표를 콘솔 로그인할 때마다 대시보드에서 확인할 수 있습니다. 해당 대시보드의 지표를 통해 현 상황을 보다 명확히 파악하는 데 도움을 받을 수 있을 것으로 예상됩니다.

Graviton

위와 같이 서비스적인 측면으로 비용 최적화를 이뤄내는 방법도 있겠지만 전략을 통한 비용 효율화 방법들도 많은데요. 카카오페이증권에서는 이번 AWS re:Invent 2023에서 클라우드 비용 효율화에 대한 발표를 진행했습니다. 카카오페이 증권에서는 서비스가 계속 늘어남에 따라 비용이 계속해서 상승했고 해당 비용을 관리해야 할 프로세스가 필요했는데요, 그에 맞춰 클라우드 비용 효율화를 위해 리소스 식별 및 가시화를 진행했고 해당 데이터를 통해 비용을 관리했다고 합니다. 또한 Workload 들을 Graviton으로 전환하여 유의미한 비용 및 성능 향상을 확인할 수 있었다고 합니다.

자세한 Graviton 이전 계획 및 비용 관리 방법에 대해서는 How to scale at speed on AWS while addressing security and compliance (GBL205)에서 자세히 확인해 보실 수 있습니다. AWS 사용에 대한 금융사의 security, compliance에 대해서도 인사이트를 얻으실 수 있으리라 생각됩니다.

Cost Optimization Hub

What’s new with AWS cost optimization (COP204) 세션에서는 비용 효율화에 대해 심도 깊은 내용을 소개하였는데요, 세션 발표자는 비용 최적화의 기회를 아래 4가지에서 찾고 있습니다.

The optimization opportunity
The optimization opportunity

위의 그림은 최적화하기 전의 전체 비용을 100%로 두고 할인(Discounts)을 통해 30%, 스케일링(Scaling) 20%, 사용하지 않을 때에 대한 제어(Hibernate) 20%, 리소스 삭제(Deleting) 5%로 총비용의 75%를 절감하여 운영할 수 있음을 제안하고 있습니다.

RI/SP purchase guidance
RI/SP purchase guidance

또한 할인 혜택을 점진적으로 구매하여 갑작스러운 워크로드 변화에도 유연하게 대처할 수 있게끔 설정하는 것이 중요하다고 전달하고 있는데요, 이러한 비용 효율화를 위한 서비스인 Cost Optimization Hub를 소개하고 있습니다. Cost Optimization Hub는 조직 내 AWS 리전 및 AWS 계정 전반에 걸쳐 비용 최적화 권장 사항에 대한 포괄적인 보기를 제공하고 예상 절감액 및 구현 노력을 기반으로 비용 최적화 권장 사항의 우선순위를 지정할 수 있는 AWS Billing and Cost Management 기능입니다.

Cost Optimization Hub
Cost Optimization Hub

Cost Optimization HubAWS Compute Optimizer서비스와 Savings Plans Recommendations, Reserved Instance Recommendations를 하나로 합쳐 비용 최적화를 위한 정보를 하나의 대시보드에서 확인할 수 있게끔 제공해 주는 서비스인데요, 이를 통해 사용자들은 검소한 Architect의 법칙 중 확인되지 않은 시스템으로 인한 불필요 비용 발생을 감지하여 비용 최적화를 진행할 수 있게 됩니다.

이 서비스는 4가지 정도의 이점을 가집니다.

  1. 표준화된 데이터 형식으로 AWS 비용 최적화 기회를 자동으로 식별하고 중앙 집중화
  2. AWS 가격 및 할인을 통합하여 예상 절감액 수량화
  3. 관련 비용 최적화 기회 전반에 걸쳐 절감액을 집계하고 중복을 제거
  4. 필터링, 정렬, 그룹화를 통해 비용 최적화 권장 사항의 우선순위 지정

이렇게 가시화 및 추천된 정보를 통해서 실제 운영자의 판단 하에 비용 최적화를 진행할 수 있습니다.

여러 키노트와 세션들에 참석하면서 AWS에서도 현재 비용에 대해 민감하게 움직이고 있음을 느꼈습니다. 새로운 서비스에 대한 제공도 중요하지만 많은 고객들이 비용에 민감하다는 점을 캐치하여 발 빠르게 움직이고 있음을 알 수 있었습니다. 가장 중요한 것은 현 운영 상황에 대해서 AWS 비용과 리소스 사용에 대해 가시적이고 직관적으로 확인할 수 있으면 편하겠다는 점인데요, AWS는 이미 확인, 절감, 계획에 대해 데이터 시각화를 제공하고 있습니다.

AWS 클라우드 재무 관리 프레임워크
AWS 클라우드 재무 관리 프레임워크

결국 이러한 데이터를 기반으로 어떻게 실행할지는 사용자의 몫인데요, Cost Optimization Hub 대시보드를 활용하면 비용에 대한 단순한 계획 수립에 그치지 않고, 계획에 따라 실제 행동을 취할 때 성공 여부를 판단할 수 있습니다. 비용 최적화를 위해 공부하고 계획한 후, 실행 단계를 통해 모두가 성공적인 비즈니스를 이루시길 바랍니다.

Observability

카카오페이에서 사내 개발 문화를 담당하고 있는 기술전략팀 댄입니다. 서비스의 안정성과 신뢰성을 확보하기 위해선 Observability(이하 옵저버빌리티) 가 중요하다고 생각됩니다. 그래서 저는 해당 주제로 발표된 AWS re:Invent 세션들을 주로 찾아보았고 이 중 몇 가지를 공유드리고자 합니다.

옵저버빌리티란?

먼저 간단히 옵저버빌리티(observability, 관찰 가능성)가 무엇인지 살펴보고, 이와 유사하게 혼용되고 있는 모니터링(monitoring)과는 어떤 차이점이 있는지 간단히 말씀드리겠습니다.

옵저버빌리티란 용어는 1960년에 헝가리계 미국인 전기공학자인 루돌프 칼만(Rudolf E. Kálmán)이 만들었습니다. 제어 이론에서 옵저버빌리티는 외부 출력의 지식을 가지고 내부 상태를 얼마나 잘 추론할 수 있는지를 측정하는 것으로 정의되었습니다.

칼만의 옵저버빌리티에 대한 정의는 최신 소프트웨어 시스템에도 적용되었는데요. 소프트웨어 애플리케이션이 옵저버빌리티라는 특성을 가지려면 다음을 할 수 있어야 합니다.

  • 애플리케이션의 내부 동작 이해
  • 애플리케이션에서 자체적으로 발생했을 수 있는 모든 시스템 상태를 이해
  • 외부 도구를 가지고 관찰하고 깊이 질문하여 내부 작동과 시스템 상태를 이해
  • 맞춤 코드를 집어넣지 않고도 내부 상태를 이해

(참고: Observability Engineering p.4, https://info.honeycomb.io/observability-engineering-oreilly-book-2022)

옵저버빌리티 vs. 모니터링

옵저버빌리티는 소프트웨어의 수명주기 전반에서 시스템 운영에 대한 포괄적인 이해를 돕기 위해 메트릭, 이벤트, 로그 및 트레이스를 수집, 시각화 및 분석하는 것을 아우릅니다. 무엇이 잘못되었는지를 보여주는 모니터링과 비교해 옵저버빌리티는 무엇이 ‘왜’ 잘못되었는지를 보여줍니다. Uber Technologies의 소프트웨어 엔지니어이자 작가인 유리 슈쿠로(Yuri Shkuro)는 이러한 방식의 차이를 “모니터링은 사전에 결정된 중요한 사항을 측정하지만, 옵저버빌리티는 시스템에 대해 미리 알지 못하는 부분에 대한 질문을 할 수 있는 역량”이라고 설명합니다.

Building observability to increase resiliency

옵저버빌리티 주제에서 먼저 소개해 드리고 싶은 세션은 AWS Monitoring and Observability의 Principal Engineer인 David Yanacek가 발표한 세션으로, 그는 복원력(resiliency) 있는 시스템이 계획한 대로 작동하는지 입증하려면 옵저버빌리티를 효과적으로 사용하는 것이 필수적이라고 말하고 있습니다. 참석한 옵저버빌리티 세션 중 이 강의가 가장 재미있고 이해가 잘 되었는데 찾아보니 AWS의 Amazon Monitoring & Observability 조직의 수석 엔지니어이시고 관련하여 많은 책을 쓰신 저자이시네요. 이 분이 회사에서 가장 즐겨하는 활동 중 하나는, 로그를 분석하고 운영 지표를 면밀히 조사하며 시간에 따라 시스템을 보다 더 원활하게 실행시키는 방법을 찾는 것이라고 합니다.

David Yanacek는 이 세션에서 선장으로 분장하여 옵저버빌리티의 바다를 항해합니다. 로그, 메트릭, 트레이스의 일반적인 옵저버빌리티 원칙에 대한 것이 아닌 서비스에서 무엇이 잘못될 수 있는지, 그리고 어떻게 할 것인지에 대해 이야기합니다. 이런 상황을 피하기 위해 옵저버빌리티를 사용하여 문제를 진단하고 옵저버빌리티 데이터가 표시하지 않은 것을 찾아낸 후 향후 문제를 예방하는 것을 말합니다.

Building Observability to increse resiliency: David Yanacek
Building Observability to increse resiliency: David Yanacek

이 세션은 다음의 내용들을 포함하고 있습니다.

  • 이슈 진단하기
    • 올바른 메트릭을 계산하기 위해 차원을 이용: 데이터를 분할 (slice & dice)
    • 하이-카디널리티(high-cardinality, 어떤 한 속성이 가지는 값이 중복되는 경우가 적을수록 하이-카디널리티임) 메트릭인 패턴 찾기
    • 추적(tracing)을 사용하여 분산 시스템을 항해
  • 숨겨진 이슈 드러내기
    • 모든 곳에서 측정하기
    • 고객 기반의 방법으로 메트릭을 집계하기
  • 미래의 이슈를 방지하기
    • 오토스케일(자동으로 자원을 증가/감소)하고 모든 것의 사용률을 추적하기
    • 게임데이를 마치 운영 제품(production)처럼 모니터 하기

이슈 진단을 위해 무엇에 대해 어떤 지표를 살펴봐야 하는지를 판단할 때 적용하는 하나의 포맷이 있는데요. 바로 다음과 같습니다.

Show me [metric] per [dimension]

[metric]은 측정 기준(measurements)이고 [dimension]은 속성(attributes)입니다.

Dimensions with high cardinality
Dimensions with high cardinality

이 부분에서는 각각의 차원(dimension)에 대해 측정 지표(metric)를 어떻게 관찰하는지를 설명하고 있습니다. 이렇게 다양한 차원에서 측정 지표를 관찰하면 보다 안정적인 시스템을 유지하는데 분명 도움이 될 것이라 생각됩니다.

해당 세션에서 인상 깊었던 한 부분을 소개해 드리자면, 우리가 관찰의 대상으로 관심 가지는 것은 모든 고객이 아니라 요청을 가장 많이 하는 고객이라는 것입니다.

Top-N metrics with CloudWatch Contributor Insights
Top-N metrics with CloudWatch Contributor Insights

따라서 모든 측정 지표에 비용을 들일 필요가 없고, 한 화면에 한꺼번에 렌더링 할 필요도 없다는 것이죠. 그런데 다양한 차원에서 원하는 측정 지표를 선택할 수 있으려면, 데이터가 풍부한 로그를 내보내야 한다는 점이 중요합니다.

Diagnose issues; Traffic spike
Diagnose issues; Traffic spike

Implementing application observability

다음으로 소개드리고 싶은 세션은 CloudWatch 서비스의 프로덕트 관리 리더인 Surbhi Dangi와 솔루션 아키텍트인 Rodrigue Koffi가 함께 발표한 세션입니다. 이 세션에서는 Amazon CloudWatch와 AWS X-Ray에 대해 이야기하고 이 도구를 이용하여 옵저버빌리티를 강화하는 방법에 대해 이야기하고 있는데요. 해당 도구의 사용을 고려하시는 분들은 이 세션을 살펴보시면 도움이 될 것 같습니다.

해당 세션에서는 AWS는 옵저버빌리티 비용을 효율적으로 사용하기 위한 전략을 찾으려고 노력하고 있으며, 이에 따라 최근 AWS 옵저버빌리티의 성숙도 모델을 출시했다는 것을 이야기하고 있습니다.

AWS observability maturity model
AWS observability maturity model

모든 사람들은 stage 4에 있기를 바라지만, stage 1이 매우 중요하다는 점을 인식해야 합니다.

Building an effective observability strategy

AWS Observability 팀의 Toshal, Ania, Helen이 공동 발표한 이 세션에서는 앞의 세션에서 언급한 옵저버빌리티 성숙도 모델에 대해서 상세히 설명하고 있습니다. 이 세션은 다음을 다루고 있습니다.

  • Where?: 옵저버빌리티 성숙도 모델
  • Why?: 옵저버빌리티의 가치. 무엇이 문제인지 관찰하기
  • What?: 신호들 수집하기. 데이터 추출하기
  • How?: 경고와 대시보드 디자인하기. 올바른 도구 선택하기

성숙도 모델에서 단계별 상태와 실행 계획은 다음과 같이 설명하고 있습니다.

Stage 1: Foundational monitoring (원격 측정 데이터 수집)

현재 상태실행 계획
- 이종의 모니터링 솔루션들
- 고립된(siloed) 도구들
- 현재 상태의 이해를 수립
- 향상을 위한 실질적인 목표를 설정

Stage 2: Intermediate monitoring (원격 측정 분석 및 통찰)

현재 상태실행 계획
- 신호들을 수집하기 위한 잘 정의된 프로세스
- 고립된(siloed) 도구들
- 정책과 실사례를 배포
- 실행 가능한 KPI 정의

Stage 3: Advanced observability (상호 관계 및 이상 탐지)

현재 상태실행 계획
- 조직 전체 전략
- 엔드 투 엔드 옵저버빌리티
- 다른 중요 시스템과 통합
- AI/ML 도구를 사용하여 수행 자동화

Stage 4: Proactive observability (자동화 및 주도적인 근본 원인 식별)

현재 상태실행 계획
- 근본 원인 식별을 위한 잘 훈련된 AI/ML 모델
- 주도적인 복원
- 지속적인 향상

이 세션의 마지막에는 다음 4가지의 문서를 공유하고 있습니다.

Dr. Werner Vogels의 키노트 - 검소한 아키텍트

옵저빌리티 주제에서 마지막으로 소개드리고 싶은 세션은 Dr. Werner Vogels의 키노트입니다. Amazon.com VP(부사장)이자 CTO인 Dr. Werner Vogels는 그의 키노트 발표에서 검소한 아키텍트(the frugal architect) 에 대해 이야기했습니다. 검소한 아키텍트가 되기 위한 총 7가지 법칙 중 4번째 법칙은 관찰되지 않은 시스템은 알 수 없는 비용을 초래한다(Unobserved Systems Lead to Unknown Costs) 입니다.

검소한 아키텍트(the frugal architect) 키노트
검소한 아키텍트(the frugal architect) 키노트

이 키노트 발표에서 Werner Vogels는 재밌는 사례를 보여주는데요, 1970년대 석유파동이 있었던 본인의 고향인 네덜란드 암스테르담에서 일어난 일입니다. 동일한 모양의 주택인데도 에너지를 훨씬 더 적게 쓰는 경우가 있어 이를 조사해 보니, 계량기가 1층 보이는 곳에 있는 집이 보이지 않는 지하실에 있는 집보다 1/3이나 더 적은 에너지를 쓰고 있었다고 합니다.

이렇게 측정이 행동을 어떻게 바꾸는지를 보여주는 재밌는 사례였습니다. 이 키노트 전반부에는 검소한 아키텍트에 대한 7가지 법칙을 다루고, 후반부에는 좋은 일을 위해 AI를 사용한 사례, 그리고 AI 기반 구축 전문가가 아니더라도 AI 도구를 쉽게 구축할 수 있게 도와주는 Amazon Q에 대한 내용도 다루고 있으니 AI 기술의 활용 현황이 궁금하신 분들은 꼭 살펴보시기 바랍니다.

마치며

AWS re:Invent 2023은 5개의 호텔에서 진행되었는데요. 라스베가스에서 위치한 각 호텔들의 규모가 굉장히 커서 많은 세션들이 동시에 진행될 수 있었어요. 이러한 큰 규모의 행사에 전 세계의 다양한 사람들과 함께하며 같이 호흡한다는 것만으로도 좋은 경험이 아니었나 생각됩니다. 추후 해당 행사에 참여하실 분들은 호텔 간의 거리와 이동 시간을 잘 체크하시고 세션 참여 계획을 잘 세우시길 바랍니다. Expo(업체 부스)에 참석하면 트렌드 파악에도 도움이 되니 참석하셔서 각 회사들의 이야기를 듣는 것도 추천드려요!

이상으로 공동 저자 빌리, 댄의 지극히 AWS re:Invent 2023 관심주제인 Cost Optimization과 Observability에 대해 살펴보았습니다. 저희가 정리한 내용들이 해당 주제들에 관심 있으신 분들께 조금이나마 도움이 되었으면 좋겠어요!

1편의 내용이 궁금하신 분들께서는 아래 바로가기를 확인해 주세요!
👉🏻 AWS re:Invent 2023, 관심 세션을 중심으로 (1편): Aurora DB, Amplify 바로가기

개인별 경험 공유

billy.j (Cost Optimization)

클라우드 엔지니어로서 일하면서 꼭 한 번 참가해보고 싶었던 행사였는데, 좋은 기회로 참석할 수 있었습니다. 해당 행사를 약 65,000명의 인원들이 참석했다고 하는데요. 65,000명의 인원들이 적어도 AWS는 사용해 봤을 거고, 이렇게 AWS 관심을 갖고 있는 인원들이 re:Invent 행사를 위해 라스베가스에 모여있다는 것에 우선 깜짝 놀라기도 하고, 설레기도 했습니다. 다들 아시겠지만, 키노트는 무조건 들어야 합니다! youtube로 봤을 때에 느끼지 못했던 현장감에 전율을 느꼈고요. Expo를 통해서 여러 기업들의 기술 트렌드를 읽을 수 있는 점이 최대 장점으로 느껴졌습니다.

dan.dy (Observability)

개인적으로는 (세션 진행하는 호텔에서 제공하는) 아침, 점심 식사 시간에 옆에 앉은 외국인과 스몰 톡을 하자고 한 것과, Amazon re:Invent가 준비한 5K 마라톤에 새벽 6시 반에 참여한 것이 즐거운 경험으로 남았습니다. 스몰 톡 하면서 알게 된 한 캐나다 분은 몇 개월 전에 한국에 방문한 적이 있다며 서울과 부산 방문한 사진을 보여주었는데, 부산 국제 드레곤 보트 대회에 참여하신 것 같더군요. 최근에 한국 방문한 외국인과 대화할 기회가 생기다니, 뭔가 신기했습니다. 스몰 톡 한 분들은 대부분 링크드인 1촌을 맺어주셨습니다 :)

billy.j
billy.j

인프라플랫폼실 클라우드 & OSS 엔지니어 빌리입니다.

dan.dy
dan.dy

카카오페이 개발 문화를 담당하고 있는 댄입니다. 카카오페이의 개발 문화가 IT 개발 문화를 선도해 나가는 게 저의 바람입니다.

태그