AWS Architecturing

본 과정에서는 Public Cloud의 강자인 Amazon Web Services에 대한 Component 분석에 대해 알아 보겠습니다.

다양한 CSP Cloud Platform 중 AWS는 2007년 Amazon 인터넷 쇼핑몰에 대한 유연한 장애 대응, Agility를 강조하는 다양한 배포 과정을 제공하기 위한 Cloud 서비스를 시작하게 되었습니다.

최초 AWS에서는 단순히 11월에 몰리는 블랙프라이데이를 대비하기 위한 유휴 장비를 인터넷 공간에 서비스하는 용도로 도입을 시작하였으나, 이는 점진적으로 발전되어 궁극적인 마이크로서비스 아키텍처를 제공하는 CSP 대표 서비스로 자리잡게 됩니다.

우리는 첫번째 과정에서 클라우드 서비스란 무엇인지? AWS는 무엇인지? 간단히 살펴보고 AWS 클라우드 서비스를 설계하기 위한 기본 지침들을 살펴보고자 합니다.

 

# 본 포스팅은 개인적으로 또는 회사 차원에서 진행한 TF의 다양한 학습 결과 그리고 Architecting On AWS 교육 등을 통해 습득한 지식을 리마인드하며 공유하는 것임을 알려드립니다.

 

먼저 클라우드 서비스의 등장 배경에 대해 살펴보겠습니다.

우리는 여전히 빅뱅 방식의 시스템 오픈에 많은 공을 기울이고 있습니다.

새로운 서비스를 오픈하기 위해서는 엄청난 노력을 기울여야 하며, 대체로 6개월에서 1년의 PI, POC, 이행, 오픈 과정을 거쳐 시스템을 고도화하거나 개발하는 과정을 거치게 됩니다.

다만 시스템의 변경 빈도가 높아지고, 새로운 고객의 요구사항을 즉각 반영해야 하는 현대 시스템들의 경우 이에 대한 문제점을 인지하였지만, 어떻게 해결해야 할지 여전히 고민만 하는 가운데 최근 3년 전까지 왔던것 같습니다.

물론 클라우드 서비스가 등장한지는 굉장히 오래 되었습니다.

하지만 우리에게 피부로 느껴질 정도로 다가온것은 최근 5년정도가 아닐까 싶네요.

클라우드 서비스의 등장

최초 클라우드 서비스는 단순히 오토스케일이 가능한 서비스를 제공하여 트래픽에 대한 유연한 대응에 초점이 맞추어졌습니다.

물론 그것만으로도 굉장히 대단한 기술이었고 너도나도 클라우드 서비스를 적용하기 시작합니다.

다만 클라우드 서비스는 여전히 시스템을 개발하고 적용하는데 걸리는 시간을 줄여주지 못했습니다. 최적화된 애플리케이션을 개발해야 했던 모놀로식 애플리케이션 보다는 보다 유연한 개발이 가능하다는 정도로 시작하였고 이는 보다 유연한 개발을 요구하게 되었습니다.

 

그래서 등장한 클라우드 서비스는 다음과 같이 정의할 수 있습니다.

---

1) 클라우드는 기존 인프라 자원을 대체하는 서비스로 단순히 제공되는 데이터를 사용하는 것에서 벗어난 프로그래밍 가능한 리소스를 제공한다.

2) 클라우드는 다양한 동적 기능을 제공한다. 그 첫번째가 바로 오케스트레이션 기능이며, 내가 원하는 인프라 종류와 그 수량을 손쉽게 선택하고 해제할 수 있다.

3) 이러한 자원 사용료를 종량 과금제라는 체계를 통해 지불하게 되어 사용한 만큼 비용을 지불하고 이후 고도화 되는 자원등을 다시 구매 할 필요 없이 손쉽게 업그레이드 할 수 있다.

---

클라우드 서비스는 위와 같이 정의가 가능하지만 조금 다른 부분을 포함하기도 합니다.

이는 AWS와 같은 CSP 3사에서 제공하는 시스템에 대한 정의이며, 클라우드는 CSP만 존재하는 것은 아니기 때문이죠.

먼저 CSP 3사의 서비스를 Public Cloud라고 일컷습니다. Public Cloud에 대한 다양한 정의는 이미 인터넷 공간에 정의되어 있기에 이를 좀 유하게 정의해 보자면 Public Cloud는 인터넷 환경에서 제공되는 인프라자원을 활용한 공개된 서비스이다. 라고 말할 수 있을 듯합니다. 별도의 자원을 구매할 필요 없이 앞서 설명한데로 종량 과금제를 통해 비용을 지불하고 임대하는 방식 정도로 볼 수 있습니다.

두번째로 Private Cloud가 있습니다. 이는 기존과 같이 인프라 자원은 각 사이트에서 구매를 하고 해당 인프라 자원 위에 오픈소스 또는 상용 제품을 적용하여 클라우드 서비스를 제공하는 것을 의미합니다.

둘다 장단점이 있지만, 앞으로의 포스팅에서는 Public Cloud에 초점이 맞춰 질 것이며, 부연 설명으로 Private Cloud 역시 자주 등장할 예정입니다.

Public Cloud 장점

Public Cloud의 장점으로는 여러가지가 있을 수 있지만, 그 중 하나를 꼽아보자면 바로 저는 용량 추정의 불필요를 꼽고 싶습니다.

이는 기존 차세대 방식의 가장 큰 난제라고 할 수 있는 인프라 자원, 네트워크 자원, SW 자원 등을 얼마나 구매를 해야 하며 어떻게 설계해야 하는가에 대한 관점에서 시작하는데 사실 이를 결정하는 것은 누구도 알수 없는 신의 영역이라고 합니다.

대체 사용자는 얼마나 자주 이곳에 접속하여 얼마나 많은 트래픽을 발생 시킬 것이고 어떠한 패턴과 시간에 트래픽이 몰릴 것이며, 갑작스런 부하에는 어떻게 대응하고, 장애 발생시 백업이나, 복구 정책을 어떻게 가져갈 것인지 등등..

수많은 고민거리들이 이러한 아키텍처 초반에 결정되고 이를 기반으로 개발하고 설계해야하는 기존 방식이 이제와서 보면 얼마나 잘못되었는가를 알수 있죠.

사실 이렇게 오픈한 경우가 저도 굉장히 많습니다.

그렇게 오픈하게 되면 오픈 초반 대략 6개월은 거의 매일 매주 튜닝에 튜닝을 거치게 되고, 그렇게 안정화 됐다 싶으면, 새로운 케이스의 등장과 이벤트성 트래픽을 증가에 대한 장애 대응으로 또다시 1~2년이 가게 되는데 그럼 다시 다음 차세대 프로젝트를 진행해야하는 시기가 다가와 분석 설계를 하게 되는 패턴.

굉장히 이러한 패턴에 대해 공감하시는 분들이 많을텐데, 바로 이러한 용량 추정이 불필요한 Public Cloud는 아키텍처를 고객의 수요과 트래픽에서 벗어난 성능/최적화/비용에만 포커싱을 맞출 수 있다는 굉장히 단순하지만 거대한 장점을 가져다 주었습니다.

물론 제가 아키텍처다 보니 이게 좋아졌다라고 생각할수도 있지만 사실 기존 모놀리식 아키텍처에 적용되면 다양한 기술들은 디폴트로 깔고 들어가야 하고 추가적인 클라우드 기술이 어펜드 되는 느낌이기에 아키텍처링이 쉬워졌다고 보기는 힘듭니다.

다만 보다 개발에 집중하고 보다 중요한 포커싱을 분석/설계에 투자할 수 있다는 장점 그리고 이후 발생될 문제에 대한 유연한 대응 체계등이 얼마나 거대한 장점인지는 프로젝트를 완료한 아키텍처나 운영자만이 알수 있죠.

 

자 지금부터 대략 20여개의 포스팅이 진행 될 예정이며, AWS를 기준으로 설명이 완료되면 GCP, Azure 등도 이어서 설명할 날이 얼릉 왔으면 좋겠네요.

그럼 본격적인 포스팅 바로 시작합니다.