AWS 이용 후기

요즘이 4차 산업혁명의 시대라고 한다. 4차 산업혁명의 요소들은 사물인터넷, 빅데이터, 인공지능, 모바일, 클라우드 등이 있다. 그중에서 클라우드에 대해 알아보겠다. 클라우드의 장점은 무엇이 있을까.

1. 사용한 만큼의 리소스에 대해서만 비용을 지불한다.
2. 인프라의 확장, 축소가 용이하다.
3. 인프라 구축이 쉽다.
4. 데이터 센터 운영 및 유지 관리를 하지 않아도 된다.
5. 전 세계에 배포할 수 있다.

이 정도가 있을 것이다. 그러면 어떤 서비스에서 클라우드를 사용하면 좋을까. 스타트업, 글로벌 서비스에 적합하다고 생각한다. 스타트업 회사는 인력, 자본이 부족하기 때문에 클라우드를 사용하면 많은 장점을 가질 수 있다. 그리고 글로벌 서비스를 하는 경우에도 해외에 서버를 구축하는 거보다 클라우드를 사용하는 것이 낫다. 서비스 지역과 서버의 거리가 먼 경우 네트워크 지연이 발생한다. 그래서 서비스하려는 지역과 서버가 같은곳에 있는 것이 지연을 최대한 줄이는 방법이고 클라우드가 이에 적합하다고 할 수 있겠다. 현업에서는 게임회사에서 많이 쓰는 모습을 보이고 있다.

클라우드의 종류는 AWS, Azure, 구글 클라우드 등이 있다. 그중에서 AWS를 추천하는데, AWS의 장점은 UI가 편하고, 서울 리전이 존재, 인스턴스 생성이 빠름, 많은 레퍼런스 등이 있다. 단점으로는 다른 서비스들에 비해 가격이 비싸다. 아무래도 AWS의 시장 점유율이 높아서 다른 기업에서는 가격 경쟁력으로 승부하려는 것 같다. 필자가 1년반 동안 실무에서 AWS를 사용하면서 느낀 점을 적어보려고 한다.

 

먼저 주요 AWS의 제품들에 대해서 알아보자.

- EC2(Elastic Compute Cloud)
서버 용도로 사용하는 제품이다. 클라우드의 최고 장점은 Auto Scaling이라고 생각한다. EC2 오토스케일링 방식은 공식 사이트에 아래와 같이 나와있다.

오토스케일링 예시 구성을 살펴보면 기존의 ec2 인스턴스(서버)가 운영 중 갑자기 트래픽이 상승하여 서버의 CPU 사용량이 높아진다면 Amazon CloudWatch(리소스 모니터링 서비스)가 CPU 사용량을 측정하고 오토스케일링에 설정한 규칙에 따라 인스턴스(서버)가 새로 추가됩니다. 인스턴스가 추가 되면 트래픽의 자동 분산(로드밸런서)이 필요한데 이는 Amazon Elastic Load Balancer(ELB)가 처리하게 됩니다. ec2 인스턴스, Amazon CloudWatch, Amazon Elastic Load Balancer, 오토스케일링의 결합을 통하여 서버를 유연하게 자동으로 확장하고 축소할 수 있습니다.

즉 CloudWatch로 모니터링을 하고 해당 조건에 걸리면 EC2(서버)가 자동으로 늘어나고 로드밸런서에 늘어난 서버가 자동으로 연결된다. 이 모든걸 AWS가 자동으로 해주니 얼마나 편한가. 오토스케일링은 원하는 시간에 작동하도록 스케줄링으로도 할 수 있다. 스케줄링 명령문도 크론탭과 동일해서 작성하기에 어렵지 않다.

- S3(Simple Storage Service)
파일 저장소로 사용하는 제품이다. 정적인 콘텐츠(이미지, 영상, css, js) 같은 파일을 업로드하고 서비스에서 사용한다. CDN처럼 빠르게 사용하려면 CloudFront 라는 제품을 같이 사용하는 것이 좋다. 아래는 S3에 대한 공식 설명이다. Amazon S3는 객체 기반의 무제한 파일 스토리지 서비스입니다. s3는 무제한 저장이 가능하지만 단일 파일일 경우 최대 5TB까지 저장이 가능하며 GB 단위로 사용한 만큼만 과금이 됩니다. s3에 파일을 업로드 되면 자동으로 해당 리전에 3개 이상의 복제가 생성되어 99.999999999%의 높은 내구성을 지원하고 있습니다. 또 s3에 업로드된 파일은 웹 URL을 통해 쉽게 공유가 가능하며 단순한 정적의 웹사이트를 운영하고 싶을 경우 웹서버 없이 s3에서 정적 웹사이트 호스팅 기능을 활성하여 쉽게 정적 웹사이트를 운영할 수도 있습니다.

AWS를 보면 높은 내구성을 강조하는 것이 보인다. 이건 AZ(Availability Zone)와 관련이 있다. AWS도 실제 물리장비가 있을 텐데 그 지역을 AZ로 구분해서 나눠놓았다. 그래서 자연재해 등으로 물리장비에 타격이 있을 경우를 대비해서 최소 2개 이상으로 AZ를 설정할 것을 권장하고 있다.

- RDS, DynamoDB, ElastiCache
DB로 사용하는 제품이다. RDS는 관계형 DB, DynamoDB는 NoSQL, ElastiCache는 Cache이다. RDS는 기본적으로 많이 쓰는 Mysql, Oracle, PostgreSQL 등을 지원하고 아마존에서 자체적으로 만든 Aurora도 있다. Aurora는 MySQL과 완벽 호환이 되고 사용법도 거의 똑같다. AWS 피셜에 따르면 MySQL에 비해 5배 빠르다고 한다.

NoSQL도 있는데 DynamoDB라는 것이 있다. NoSQL은 간단한 데이터를 주고받을 때 속도가 매우 빠르다. 그리고 RDB는 확장을 하려면 샤딩을 해야 되는데 NoSQL은 확장이 쉽다. AWS에서는 오토스케일링도 된다. 그래서 결제 등은 RDB로 구축하고 단순 데이터들은 NoSQL로 구축하면 좋다.

Cache는 Redis와 Memcached를 지원한다. 간단하게 데이터를 키-밸류 형태로 저장하는 용도라면 멤캐시를 써도 무방하다. 레디스는 저장할 수 있는 값이 멤캐시보다 크고, 데이터 정렬등의 기능을 함수로 제공한다. 그리고 디비처럼 스냅샷을 떠서 복제, 복구가 가능하다.

- CloudWatch, SNS, Kinesis, Route53, ELB
그 외에 이런 제품들을 사용했다. CloudWatch는 모니터링 용도, SNS는 문자, 메일, 푸시 용도. Kinesis는 스트리밍 데이터 분석, Route53은 DNS, ELB는 로드밸런서이다.

CloudWatch로 여러 장비들의 상태를 한눈에 볼 수 있고, 모니터링 페이지도 자기 입맛에 맞게 편집이 가능하다. SNS로 git, slack 등을 웹훅으로 연결해서 커밋을 한 경우 슬랙방에 메시지가 오도록 할 수도 있다. Kinesis는 로그 수집용으로 Route53, ELB는 네트워크 구성을 위해 사용했다.

좀 새로웠던게 ELB인데 내가 알고 있던 L4 스위치 말고 L7 스위치도 제공하고 있었다.
L4 스위치: Network Load Balancer는 개방형 시스템 간 상호 연결(OSI) 모델의 네 번째 계층에서 작동합니다.
L7 스위치: Application Load Balancer는 개방형 시스템 간 상호 연결(OSI) 모델의 일곱 번째 계층인 애플리케이션 계층에서 작동합니다.
L7이 L4에 비해 더 많은 기능을 제공하므로 AWS에서는 L7으로 로드밸런서를 만드는 것을 권장하고 있다.

이외에 AI에 대한 서비스도 많아지는 추세이다. 이미지/영상 분석, 챗봇, 음성인식, 번역, 텍스트 처리 등이 있다. AWS도 사업을 키워야 하는 만큼 다양한 서비스로 고객을 만족시키기 위해 노력중인 것 같다. 가이드도 잘 되어 있고 AWS 코리아에서 강의도 많이 하는 편이다.

AWS 실습 가이드는 아래 사이트를 참조하면 좋을거 같다.

kr-id-general.workshop.aws/ko

이제 사담을 좀 풀어볼까 하는데, 기억에 남는 작업으로는 awscli를 이용해서 다이나모 오토스케일링 조건을 일괄 업데이트한 작업이 있다. 운영을 하다보면 디비가 많이 늘어나는데 웹 페이지를 하나하나 찾아서 하는 것이 아니라 CLI를 이용해서 한 번에 업데이트하는 스크립트를 만들었다.

그리고 캐시를 모니터링하는 시스템도 만들었다. 크론에 스케줄을 등록해서 실시간으로 캐시데이터를 체크하고 데이터에 이상이 있으면 슬랙으로 메시지를 보내도록 했다. 처음엔 내가 만든 서비스에서만 쓰다가 테스트를 거치고 전사에 배포하였다.

그리고 소소한 추억들도 몇개 있다. AWS는 행사를 많이 한다. AWS Summit Seoul 2019를 코엑스에서 했는데 재밌는 경험이었다. AWS 기업적용 사례, 제품 홍보, 회사 홍보 등을 하였다. 당시 회사 사람이 발표를 하는 자리가 있어서 다 같이 참여를 하였다. 그리고 re:Invent라는 큰 행사를 미국 라스베가스에서 한다. 선임 개발자들이 라스베가스 다녀온 썰을 들려줬는데 좀 부러웠다.

AWS를 이용하다 보면 AWS 담당자와 연락을 종종 하게되고 친해지게 된다. 그래서 같이 술을 마신적이 있는데, 데낄라+토닉을 넣고 코스터에 탁 쳐서 거품이 있을 때 한 번에 마셨는데 굉장히 맛있었다. 낮에는 AWS 교육받았고, 밤에는 데낄라를 같이 마셨는데 즐거운 시간이었다.

그리고 혼자 AWS를 사용하다가 RDS를 삭제하지 않아서 요금이 나온적도 있었다. EC2만 삭제하면 되는 줄 알았는데 RDS를 가지고 있는 것만으로도 요금이 나올 수 있으니 주의해야 한다.

AWS 장애가 나서 서비스가 안 됐던 적도 있었다. 2018년 11월쯤인데 슬랙이 계속 울려서 확인을 했는데 AWS 장애였다.
네이버 검색순위에 AWS가 있었고 쿠팡, 배민, 넥슨등도 서비스에 지장이 있었다고 한다. 84분 동안 장애가 있었는데 장애 보상은 AWS 크레딧으로 줬었다. 번외로 github 사이트가 에러가 나서 커밋이 안된적도 있었다.

친구는 어플을 만들고 AWS를 사용했으나 어플 수익이 AWS 비용을 감당하지 못한 적도 있었다. 서버 운영을 하면서 참 많은 일이 있었다.

올해도 AWS 서밋을 참가하고 싶었으나 코로나가 터지는 바람에 참가를 하지 못하였다. 회사 사람들과 개발얘기 하는것을 즐기는 사람으로서 재택근무를 하며 그러지 못하는 점도 아쉽다. 내년에는 코로나 상황이 좀 나아지길 바라면서 글을 마쳐야겠다.