AWS re:Invent 2021 세션 리뷰 : 아마존 사례로 보는 안정적인 확장 운영 방법 by Dino

요약 정보

카카오엔터테인먼트 카카오웹툰 백엔드 개발팀 디노(Dino)입니다.

미국 라스베이거스에서 열린 AWS re:Invent 2021에서 참여하면서 인상 깊었던 세션을 소개하고자 합니다.

참여한 세션의 주요 내용을 요약해서 설명드리고, 카카오웹툰에서 활용할 방안도 함께 공유합니다.

 

세션 기본 정보

• Title : Reliable scalability: How Amazon.com scales in the cloud
• Location : CAESARS FORUM Summit 218
• Speaker :
  • Kieran Kavanagh
  • Seth Eliot
• Related AWS Services
  • Amazon Cloud Watch
  • Amazon SQS
  • AWS CloudFormation

• Level : 200 - Intermediate
• Track : Architecture

 

세션 요약

• 아마존의 히스토리와 아마존이 왜 확장성이 필요했는지를 설명합니다.
• 안정적인 확장성을 갖춘 서비스를 유지하기 위한 아마존의 메커니즘을 공유합니다.

 

Details

amazon의 초기 모습

• 아마존의 초창기 모델은 굉장히 단순했습니다.
• 유저는 Obidos라는 웹서버를 통해 아마존 책을 주문합니다.
• 주문한 내역은 ACB라고 하는 아마존닷컴의 책 관리 Storage 에 저장되었습니다.
• 주문 내역을 바탕으로 유통센터에서 책을 준비하고 결제를 처리합니다.
• 그리고 책을 배송하면 됩니다, 간단한 모델입니다.

 

첫번째 확장 모델

• 아마존닷컴은 급격하게 커졌고 확장성을 고려하기 시작했습니다.
• DB를 확장하기 시작했습니다.
• 유통센터에서 사용하는 DB를 별도로 구성했습니다.
• 웹에서 사용하는 Order DB를 ACB와 분리 복사해서 사용했습니다.
  
  

 

두 번째 확장 모델

• Distribution Center 서비스를 별도로 분리해 ACB로 데이터를 전송하도록 변경했습니다.
• SOA 모델이었습니다.
• ACB를 공통 모델로 쓰고 WEB, 유통센터 등을 쪼개서 공유하면서 사용한 방식이었습니다.
• 그럼 현재의 모델은 어떨까요?

 

최신 아키텍처

• 마치, 스타워즈의 데스 스타와 같은 MSA 네트워크를 이루고 있습니다.
  
  

 

아키텍처는 다음과 같이 진화해 왔습니다.

• SOA는 각 레이어의 통신방법을 중시하며, 재사용을 위해 공통 레이어를 공유합니다.
• MSA는 배포와 업무 조직단위부터 서비스 Repository 자체가 분리됩니다.
  서비스 내에 동일 로직이 생길 수 있으며, 각 서비스가 책임집니다.
• MSA에서는 서비스 오케스트레이션 영역에 투자하기보다는, 유지보수와 빠른 배포에 포커싱을 합니다.
• SOA는 “서비스는 여러가지 중 어떤 것을 수행하고 작은 단위의 변화와 영향을 끼치는 기준”이라면
• MSA는 “한 가지 서비스만 수행하면 최소한의 효과 최소한의 변화를 추구” 합니다.
  
  

 

그럼 현재 아마존은 어떻게 움직이고 있을까?

• 1년간 약 1억 5천만 건의 배포가 일어나고 있습니다.
• 하나의 디테일 페이지를 표현하기 위해서 약 100개의 마이크로 서비스 AP를 Call 하고 있습니다.
• 하나의 예시를 추가로 살펴볼까요?
  • 구독 박스 모델이 있다고 해봤을 때, 이 모델은 3명의 엔지니어가 개발하는 마이크로 서비스입니다.
  • 일별로 약 100만 건의 이벤트를 처리하고 있습니다.

 

이런 서비스를 유지하기 위해서 어떤 과정이 필요할까요?

Review And Test

• 아마존은 리뷰와 테스트를 하는 과정에 있어서 메커니즘을 중시합니다.
• 멤버의 좋은 의도보다는 시스템을 만들고 시스템을 이용한 진행을 중시합니다.
• 툴을 기반으로 리뷰와 테스트를 진행하고 점검하고 이 사이클을 통해 아웃풋을 도출합니다.

 

아마존의 4가지 테스트 타입

• 아마존은 4가지 종류의 테스트를 진행합니다.
• Load Testing
  • 서비스가 현실적으로 예상되는 부하를 감당할 수 있는지 테스트합니다.
  • 주로 긍정적인 지표를 기반으로 테스트합니다.
  • Production에서 이루어지는 실질적인 행동 기반으로 테스트합니다.
    
    

 

• Performance Testing
  • 부하가 성능에 어떤 영향을 미치는지 테스트합니다.
  • Latency, Errors, Throughput 지표를 기반으로 테스트합니다.
    
    

 

• Stress Testing
  • 서비스의 한계점을 찾는 테스트입니다.
  • 시스템이 멈추는 포인트를 찾습니다.
  • Production에서 흔히 하지 않는 행동들을 찾습니다.
    
    

 

• Chaos Testing
  • 서비스가 장애를 어떻게 처리하는지 테스트합니다.
  • 네트워크 지연 상황
  • CPU 또는 Memory 가 풀 찬 상황에서의 대응이 가능한지 테스트
  • 종속성이 있는 서비스의 이슈 발생 시 대응 테스트
    
    

 

테스트 원칙

• 각 테스트를 진행하는 데 있어서 서비스에서 진행하는 QA나 다른 테스트가 영향을 받지 않아야 합니다.
• 각 테스트를 진행할 때는 그 테스트에 맞는 환경을 구성하는 게 중요합니다.

 

Test Summary

• 리뷰와 테스트를 통해 배포를 진행하는 과정을 설명합니다.
  • 일반적인 부하 테스트를 진행합니다. (Unit Test와 리뷰도 같이 진행합니다)
  • 엔지니어링 브런치로 따로 분리합니다.
  • 4가지 종류의 주요 테스트를 수행합니다.
  • 토론을 하고, 최종 배포합니다.
    
    

 

Understanding services in production

• 서비스의 이해가 필요합니다.
• 서비스를 이해하고 어떻게 확장을 할지 결정을 해야 합니다.
• 예를 들어, 특정 서비스가 패턴을 유지하다가 확 늘어나는 포인트가 있다면 그 포인트를 대비해야 합니다.

 

Example for service in Production

• Ring 서비스의 오토 스케일링 구조입니다
• S3 → SQS로 이벤트가 들어오면 큐 메트릭을 CloudWatch로 모니터링합니다.
• Step Function에서 판단 후 Scale up / down을 결정합니다.
  
  

 

참고 사항

• Global Architecture도 공유해줬습니다. 참고하면 좋을 것 같습니다.
  
  

Region과 Global Architecture with Amazon Resources

 

Result

• 확장성을 위해서는 SOA 또는 MSA로 설계하는 것을 추천합니다.
• 시스템을 구성하고 리뷰와 테스트를 통해 안정적인 확장성을 추구합니다.
• 서비스를 이해하고 서비스에 맞는 확장 계획을 세웁니다.
• 카카오웹툰 서비스를 개발하고 운영하는 관점에서 가장 인상 깊은 내용은 테스트 부분입니다. 그리고 이 테스트와 리뷰를 사람에게 의존하기보다 시스템을 만들고 메커니즘을 기반으로 동작하는 형태가 가장 배울 부분이 많다고 생각합니다.
• 차츰 체계적인 테스트 시스템을 도입하고 좀 더 안정적인 MSA를 구성할 가이드 또는 컨벤션을 만들어 볼 예정입니다.
• MSA를 운영하고 설계하는 데 있어 좋은 레퍼런스용 세션이었습니다.

 

Reference

• 촬영한 추가 세션 사진들 공유합니다.