[reinvent 2024] 크게 생각하고, 작게 만들기: 확장해야 할 때와 단순화해야 할 때

들어가며

이번 칼럼에서는 효율적은 클라우드 아키텍처 구축을 주제로 한 세션을 듣고, 여러분께 신규 기술 및 업데이트 된 정보를 공유드리도록 하겠습니다. 이번 세션에서 주목할 내용은 ‘인프라구축의 단순화 및 효율화’ 입니다.

시작하기에 앞서 발표자분이 운영하는 비영리단체의 AWS 서비스 도입비용의 변화 그래프를 가져와 본인의 비용절감 성공사례를 언급하였습니다.

실제로 4주간 사용해보면서 핵심 인프라의 일부를 교체할 수 있었다는걸 발견했고 새로운 네트워크기능 덕분에 로드 밸런서가 더 이상 필요하지 않다는 걸 깨닫고 삭제를 통해 위와 같이 비용절감을 할 수 있었다고 합니다.

이어서 작은규모의 아키텍팅을 위해선 고려해야할 부분에 대해 설명을 이어갔습니다.

• 먼저 애플리케이션 아키텍처(Application architecture)의 관점에서 고려해야할 부분은 아래와 같습니다.
  • 시스템의 효율성을 위해 어떻게 구조화할 것인가?
  • 모놀리스 vs 마이크로서비스 구조중 선택
  • 일반적인 클라우드 아키텍처 패턴 적용유지
    
    
• 다음으로 조직 아키텍처(Organizational architecture)의 관점에서 고려해야할 부분은 아래와 같습니다.
  • 어떻게 경제성을 촉진하고 보상할 것인가?
  • 결과 측정(Measuring outcomes)을 통한 성과 관리
  • 인센티브 정렬(Aligning incentives)을 통한 동기부여
    
    
• 이는 다음과 같은 핵심 고려사항들을 다루고 있죠.
  • 시스템의 단순성과 안정성 추구
  • 비즈니스 가치와 민첩성 최적화
  • 인프라 투자에 대한 트레이드오프와 수익성 고려
  • 다양한 아키텍처 계층에 대한 AWS의 관점 제시

위 프레젠테이션 슬라이드는 결국 기술적측면뿐만 아니라 조직적측면에서도 클라우드 아키텍처를 고려해야 함을 강조하고 있습니다.

이러한 타협을 통해 우리는 시간이 지남에 따라 자전거가 이상적인 아키텍처로 등장했다는 것을 알고 있습니다. 타고 다니기에 충분히 넓고 상대적으로 저렴합니다. 외발자전거보다 움직이는 부품이 더 많지만 그만한 가치가 있습니다. 학습 곡선도 있죠. 또한 자전거 타는 법을 배우는 것이 외발자전거 타는 법을 배우는 것보다 훨씬 쉽습니다.

그리고 A에서 B로 이동하는데 매우 효율적입니다. 하지만 이 모든 것을 미리 추측할 수 있었다고 생각하지 않습니다. 그 모든 것은 반복을 통해, 자전거를 만들고, 사람들에게 주고, 그들이 사용하는 것을 지켜보고, 피드백을 얻고, 무엇이 작동하는지 보고 나서 모든 구성 요소에 같은 것을 적용하면서 배운거죠.

이어서 일반적인 클라우드 패턴을 만들기 위해서 위 4가지를 고려해야 비용절감효과를 얻을 수 있다고 합니다.

• 먼저  AWS의 고가용성(High-availability) 시스템의 주요 특징을 설명하였습니다.
  • 클라우드에서 가장 일반적인 워크로드 유형
  • 가장 보편적으로 사용되는 구성 방식임을 강조
  • 2개 이상의 가용성 영역(AZ)에 애플리케이션 배포
    
    
• 시스템의 안정성과 가용성을 높이기 위해 여러 가용영역에 분산 배치
  • 주요 적용 분야
  • 엔터프라이즈 시스템
  • 백오피스 업무
  • 소매(리테일) 서비스

가용성부분에서 비용절감을 위해선 2개의 가용영역보단 5개의 가용영역이 비용효율적이라고 설명을 이어갔습니다. 개인적으로 가용영역을 더 많이 쓰는건데 왜 비용이 더 절감되는지 이해되지 않았습니다. 하지만 이후 설명에서 납득이 갔습니다.

• 2개 가용영역 사용 시 (전통적 방식)
  • 모든 리소스를 100% 복제해야 함
  • 예: 워크로드가 100 유닛이라면, 각 AZ에 100 유닛씩 총 200 유닛 필요
  • 결과: 100% 초과비용 발생
    
    
• 5개 가용영역 사용 시 (AWS 권장)
  • 전체 용량의 25% 추가 리소스만 필요
  • 예: 워크로드가 100 유닛이라면, 총 125 유닛만 필요 (각 AZ에 25 유닛씩)
  • 한 AZ가 다운되어도 나머지 4개 AZ가 워크로드를 분산 처리
  • 결과: 25% 초과비용만 발생

즉, 더 많은 가용영역을 사용하면, 리소스를 더 효율적으로 분산할 수 있고 / 각 AZ별로 필요한 중복 용량이 줄어들며 / 결과적으로 전체 비용이 감소합니다는 것입니다.

 마치 계란을 한 바구니에 모두 담는 것보다 여러 바구니에 분산해서 담는 것이 더 안전하고 효율적인 것과 같은 원리라고 이해하시면 되겠네요.

다음 관점은 최고의 효율성을 뽑아낼 수 있는 시스템에 대한 구성방안에대해 설명하였습니다. 주요 내용을 설명하자면 아래와 같습니다.

• 적용가능한 시스템의 주요 특징
  • 중복성과 복원력이 거의 없거나 전혀 없는 시스템
  • 단일 또는 다중 가용영역 사용. but 여유 용량 없음
  • 지연시간에 민감하지 않은 비핵심 시스템
  • 장시간 실행되는 머신러닝 트레이닝에 주로 사용
    
    
• 해당 시스템들의 비용 절감 방안
  • 가장 효율적인 하드웨어와 네트워크 사용으로 절감
  • 트레이닝 프로세스 최적화를 통한 절감 가능
  • AWS 서비스 활용:
    • Amazon EKS
    • Amazon SageMaker
    • AWS Batch
    • AWS Glue

이러한 시스템은 주로 실패해도 큰 문제가 없는 비핵심 작업이나, 머신러닝 모델 학습과 같이 시간에 덜 민감한 작업에 적합합니다. 고가용성이 필요없는 대신 비용 효율성에 초점을 맞춘 구성이라고 볼 수 있죠.

다음은 Highly isolated systems(고격리 시스템)에 대한 비용절감 방안입니다.

• 적용가능한 시스템의 주요 특징
  • 격리된 단일 테넌트 환경에서 운영
  • 엄격한 규제와 긴 테스트 주기가 필요한 중요 워크로드
    
    
• 주요 사용 사례
  • 거래소 시스템
  • 중요 정부 시스템
  • AWS Local Zones와 AWS Outposts 활용
    
    
• 비용 및 효율성 관리
  • 적절한 규모 산정이 비용 관리의 핵심
  • 기본 클라우드 비용 구조로 규모의 경제 실현
    
    
• 클라우드 이점
  • 세분화된 보안
  • 모니터링
  • 위협 방지
  • 빠른 애플리케이션 복구

이러한 시스템은 높은 수준의 보안과 규제가 필요한 금융이나 정부 시스템에 적합하며, 격리된 환경에서 안전하게 운영되면서도 클라우드의 이점을 활용할 수 있습니다. 해당 내용은 저 또한 금융고객 MSP업무를 맡고 있기에 크게 다가온 부분입니다.

마지막으로 글로벌 분산 시스템(Globally distributed)에 대한 비용절감 방안입니다.

• 적용가능한 시스템의 주요 특징
  • 멀티 리전과 엣지 애플리케이션 지원
  • 통신사급(Carrier-grade) 수준의 애플리케이션
  • 미디어, 엔터테인먼트, 게임 서비스에 적합
    
    
• 주요 기술 요구사항
  • “최소 거리” 장애 조치(failover) 요구사항을 충족하는 규정 준수
  • “Active-active”(다중 활성) 아키텍처
  • “Failover-site”(장애 조치 사이트) 아키텍처
    
    
• 이런 시스템이 필요한 경우
  • 글로벌 사용자를 대상으로 하는 서비스
  • 지연 시간에 민감한 애플리케이션
  • 높은 가용성이 요구되는 서비스
  • 지역별 규제 준수가 필요한 경우

예를 들어, 넷플릭스나 게임 서비스처럼 전 세계 사용자에게 빠른 응답 시간을 제공해야 하는 서비스들이 이러한 아키텍처를 채택해야 하죠.

결론

결국, 고가용성 시스템부터 베스트 에포트, 고격리 시스템, 글로벌 분산 시스템에 이르기까지, 각각의 워크로드 특성에 맞는 최적화된 인프라 구성이 비용 효율성과 시스템 안정성의 핵심임을 깨닫게 되는 세션이었습니다.

특히 주목할 만한 점은 더 많은 가용영역을 활용할수록 오히려 오버헤드가 줄어드는 역설적인 현상으로, 이는 AWS의 혁신적인 인프라 설계 철학을 잘 보여주는 것 같아 좋았습니다.

AWS가 제공하는 다양한 서비스 옵션들은 마치 레고 블록과 같아서, 각 기업의 특성과 요구사항에 맞춰 최적의 아키텍처를 구성할 수 있으며, 이러한 유연성이야말로 현대 클라우드 인프라의 가장 큰 강점인 것 같습니다.

모든 시스템 구성에 있어 ‘하나의 정답’은 없으며, 각 워크로드의 특성을 깊이 이해하고 적절한 아키텍처를 선택하는 것이 AWS 인프라 설계의 핵심임을 다시 한 번 확인할 수 있었던 시간이었습니다.