AWS Summit 2016 참관 후기

어제 삼성 코엑스에서 열린 AWS Summit 2016에 구경하러 갔다. 2년 전에 한번 왔었는데 그때에 비해 사람이 눈에띄가 많아졌다. 사전 등록만 6000명이라고 하니 AWS에 대한 관심이 상당한 것 같다.

관심뿐만은 아닐것 같다. 다양한 성공사례가 나오고 스타트업에서부터 대기업까지 다양한 유저층에서 아마존을 도입하고 기존시스템을 변경하는 사례들이 많다. 좀더 최적화된 AWS 사용법을 알기 위해 그리고 자신이 구축한 클라우드 환경이 맞는지 확인하기 위해 참석하는 이들도 많을 것이라 생각한다.

참석한 순서는 이렇다.

13:00~13:40 / 트랙1 / 나에게 맞는 데이터베이스 선택하기
13:50~14:30 / 트랙2 / 람다를 활용한 서버없는 아키텍쳐 구현하기
14:40~15:10 / 트랙1 / AWS를 이용해서 나만의 글로벌 인터넷 방송국 만들기
15:40~16:10 / 트랙1 / AWS 천재가된 황대리 - 10가지 팁
16:20~17:00 / 트랙4 / 개발자가 알아야 할 DynamoDB 활용법
17:10~17:50 / 트랙4 / 관계형 디비 Aurora

나에게 맞는 데이터베이스 선택하기

AWS에서 주로 사용하는 것이 RDS다. 웬만하면 MySQL엔진으로 설정해서 사용한다. 처음엔 비용 좀 아껴보자고 EC2에 어플리케이션 코드와 데이터베이스를 함께 구동시켰다.

하지만 설치하는데 적지않은 시간이 걸린다. 게다가 백업도 해야하고 이유없이 죽은 데몬도 처리해 줘야한다. 디비를 운영하는 수고로움보다는 차라리 비용을 좀 더 지불하고 AWS가 알아서 관리해 주는것이 편하다. 대신 난 어플리케이션 개발에 집중할 수 있어서 훨씬 효율적이다. 이제는 RDS만 사용한다.

"안티패턴" 이라고 했다. 디비에 검색을 포함한 다양한 기능들을 넣은 것이라고 하는데 디비를 분산해야 한다는 얘기가 포인트였다. 디비를 구성할 때 웬만하면 캐쉬, NoSQL, RDB, Search 등으로 분산해서 구성하라고 했다. 각각에 대응하는 것이 ElasticCache, DynamoDB, RDS, ElasticSearch 이다.

RDS는 JobPlanet (Jeff Chan, CTO)의 사례를 소개했다.

DynamoDB는 리퀘스트에 상관없이 응답속도 9ms 이하를 보장하는 것이 큰 장점인것 같다.

RedShift는 페타 단위 데이터웨어하우스 용도라고 한다.

람다를 활용한 서버없는 아키텍쳐 구현하기

우연찮게 아침에 람다 관련한 포스팅을 하나 작성하고 나와서 설명은 쉽게 이해되었다.

과거의 서버환경은 모놀리틱(Monolithic)하다. 하나의 거대한 덩어리다. 서로 끈끈하게 엮여있기 때문에 조그마한 부분이라도 개선하기가 쉽지 않았다.

그래서 나오는 것이 마이크로서비스 아키텍쳐. 매우 작은 서버들이 서로 엮여있고 REST Api로 서로 통신한다. 이런한 것중 하나가 컨테이너 서비스일 것이다.

람다도 그러한 개념에서 나온 것이다. 아주 작은 서버. 항상 구동 중이지는 않지만 어떤 이벤트가 발생하면 실행하고 종료되는 것.

어찌보면 내 컴퓨터의 프로세스 같은 것일 수 있다. 평소에는 디스크에 있다가 필요할 때 메모리로 올리고 사용한 뒤 다시 메모리에서 내리는 것. 람다도 그러한 구조이기 때문에 효율적인 컴퓨팅 자원 관리가 가능하다고 생각한다.

이클립스로 실습을 진행했는데 람다용 플러그인을 사용했다. 람다 함수를 설정하고 배포하는 것을 아주 쉽게 만들어 놓았다. 사실 웹페이지에서 하나하나 클릭하면서 설정하는 것이 개발자에겐 좀 어색할 수 있다. 웹스톰에도 람다 플러그인을 찾아봐야겠다.

람다에 대해 몰랐던 점.

버져닝 기능 있음
EC2는 시간당단위로 과금하는데 비해 람다는 100ms 단위로 과금한다. 좀더 합리적인 가격이 나오겠다.

개발자가 알아야 할 DynamoDB 활용법

다이나모디비는 몽고디비랑 비교하면서 사용하기가 좀 망설여졌다. 망설인 포인트는 관리할 필요가 적다는 장점과 몽고디비에 비해 기능이 부족하다는 점. 이번 설명을 들어도 여전히 그러한 의문은 풀리지 않았다.

대부분의 활용사례가 로그 수집과 이것을 다른 서비스를 이용해 분석하는 것이다.

당장 서비스의 메인 디비로 활용하기에는 무리가 있을 것 같다.

인덱싱 기능에 대한 설명이 주였다. 세컨더리 인덱스, 검색 인덱스, 조합 인덱스 등을 잘 활용하면 RDB 사용자도 웬만큼 사용할 수 있다고 했다.

관계형 디비 Aurora

RDS 유저로서 가장 관심이 많은 세션이었다.

새로나온 디비인데 속도도 좋고 가격도 십분의 일이라고 하던데...

리멤버의 사례를 들으니 이젠 써봐야겠다는 확신이 들었다. 무엇보다 그들이 직접 벤치마킹한 결과를 보여줬다. 그들은 장사꾼의 마케팅을 그대로 믿지 않았다. 다른 두 가지 디비 엔지과 비교했는데 Read 성능은 큰 차이가 없었다. 하지만 Write와 Read/Write 속도는 월등했다. Aurora는 최대 5배 이상 좋은 성능을 보여줬다.

Aurora의 장점은 엔진과 저장소를 분리한다는 것이다. 그리고 이 저장소는 S3 같은 용량이 자유로운 저장소를 사용하기 때문에 과금이 합리적이다. 64TB까지 자동으로 확장되는 특징이 있다.

Sequelize가 Aurora를 지원할지 모르겠다.