빅데이터를 공부해야할 일이 생겨서, 하둡을 먼저 공부했다. 쌩으로 클러스터를 만들고, 설정값을 변경해보고… 그렇게 클러스터를 만드는 일부터 맵리듀스 어플리케이션을 만드는 일까지 공부하는게 쉽지만은 않았다. 여기서 약간 빅데이터의 벽(?)같은걸 1차로 느꼈다.

그러다가 스파크를 만났다. 공부하다 보니 스파크가 그렇게 어렵지도 않고, 그런데 활용성은 굉장히 좋고, 성능도 좋다는 생각이 든다. 여기서 포인트는 그닥 어렵지 않다는 점이다. 자료들이 주로 scala라는 생소한 언어로 설명이 되어있지만, scala가 별로 어렵지 않다. 언어자체가 직관적이면서 간결하다. 그리고 scala로 배우는 스파크도 그닥 어렵지가 않다. 많은 기능을 제공하고 좋은 성능을 제공하지만, 기능들의 추상화가 잘 되어있어서 단순히 api만 호출하면 된다.

이거 사긴데? 쉽고 빠른 빅데이터 처리 엔진이라니…

그 동안 하둡을 공부하면서 느낀 어떤 답답함 같은게 해소되는 느낌이랄까. 맵리듀스를 짜면서 뭔가 병렬처리로 성능이 향상된다는건 알겠는데 코드 작성이 상당히 번거로웠다.(책에는 간단하다고 나와있는데 원리야 간단하지만 코드짜는건 안간단함 ㅇㅇ) 물론 하둡에는 맵리듀스 외에도 빠르게 분석할 수 있는 엔진들이 있지만, 그 중에 스파크가 가장 매력적으로 보인다.

블로그 개편했어요!
전에는 Jekyll 을 썼었는데 계속 테마는 마음에 안들었었거든요.
그래서 예쁜 테마를 찾아보니… 예쁜 테마는 모두 hexo에 있더군요. 그래서 갈아탔습니다.

Lambda가 진정한 cloud native인걸까!

300원에 200만뷰 소화하기라는 포스팅을 읽은 적이 있습니다.

그리고
AWS와 함께 천만 사용자 웹서비스 만들기라는 슬라이드도 본 적이 있습니다.

저 슬라이드를 처음 봤던 때에는 Lambda에 대해서 많이 사용을 안해봐서 그런지 저 자료들만 보면 왠지 엄청난 트래픽을 아주 적은 비용으로 큰 문제 없이 수용할 수 있을 것만 같았습니다. 그러면서 언젠가 full-serverless 로 구성된 서비스를 한번 만들어 봐야겠다는 생각을 했었습니다. 생각만요.

생각해보면 단순히 REST API에 대한 요청만 받아주는 서비스라면 API GATEWAY + Lambda 로만 구성하는게 충분히 메리트 있을것 같았습니다. 그러면 정말 진정한 의미에 Pay-as-you-go 를 구현하는 클라우드 네이티브를 구현해볼 수 있지 않을까요…?

들어가기 전에…

최근에 AWS Datascience 소그룹 모임의 자료를 쭉 보던 중 아주 정리가 잘 되어있는 자료를 보았습니다. AWS 기반 지속 가능한 데이터 분석하기 라는 자료인데 SK 빅데이터 허브에서 제공하는 배달 업종 통화 기록을 베이스로 spark로 데이터를 변환하고 athena, Presto, tableau 를 이용해서 시각화 하는 내용을 담고 있습니다. ETL 부터 시각화까지의 내용을 아주 재밌는 데이터와 함께 잘 정리한 글입니다. (AWS 데이터사이언스 모임은 가보지 않았지만 언젠간 한번 꼭 참석하리라 마음을 먹은지 벌써 몇달째… )

AWS Athena, Cloudfront Log 분석을 위한 쿼리 예시

Cloudfront는 고맙게도 Edge단에서 발생하는 처리 로그들을 모아서 제공해 줍니다. CF Log는 기본적으로 S3에 gz 형태로 압축되엇 제공이 되고
다음과 같은 DDL을 통해 테이블을 정의하면 Athena에서 조회할 수 있습니다.

Amazon Elasticsearch Dedicated Master의 스토리지 비용은?

Amazon Elasticsearch 에는 Dedicated Master를 설정해줄 수 있습니다. 마스터노드의 기능만 하는 노드를 따로 빼서 클러스터의 안정성을 높이는 방안입니다. Elastic의 문서에도 클러스터의 사이즈가 큰 경우 마스터 노드를 분리하는 것을 권장하고 있네요. (참고: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html)

오늘 내용은 Dedicated Master에 대한 디테일한 내용이 아니라 비용에 관한 간단한 얘기입니다.

Athena, 심플하고 강력하지만 아쉬운 인터페이스

이번 포스팅에서는 Athena 와 Zeppelin을 엮어서 사용하는 방법에 대해서 정리하려고 합니다. Athena는 써보면 써볼수록 요물이라는 생각이 드는 제품입니다. S3에 데이터만 잘 저장해 놓으면 그걸 SQL문으로 빠르게 쿼리할 수 있다는 컨셉이 간단하지만 강력하네요. 다른 분산처리 플랫폼도 많지만, 일단 간단하게 시작하기에는 Athena가 최적인것 같아요.

다만, Athena가 워낙 심플한 구조를 갖고 있고 제공해주는 기능도 심플하다 보니 조금 아쉬운점도 있는데요, 일단 제 생각에 가장 아쉬운 점은 인터페이스 입니다. ‘대화형 쿼리’ 라는 컨셉으로 단순한 쿼리창만 갖고 있지만, 사실 ‘대화형’ 이라는 말처럼 채팅기록이 남진 않는게 제 생각엔 커다란 단점인 것 같아요. 우리나라 정서가 워낙 UI에 이것저것 많은 기능을 좋아해서 상대적으로 AWS의 UI가 좀 빈약하다는 느낌을 많이 받는데 Athena의 인터페이스도 그 중 하나인 것 같습니다. 그래도 ‘대화형’이라는 컨셉을 완성하기 위해서는 조금 더 인터페이스가 발전해야 할 것 같다고 생각합니다.

Lightsail 이라는 서비스가 나온지는 좀 되었다. 간단하게 소개하면 아마존에서 제공하는 웹 호스팅 서비스 이다. 기본적인 컨셉 자체는 AWS라는 복잡하고 어려운 클라우드 어쩌구를 몰라도 웹호스팅을 다른 업체만큼 싸게 제공해주는 데 목적이 있는 듯하다. 영세한 웹호스팅업계에 AWS라는 공룡이 침입한 게 아닌가 싶다. Digital Oceans 같은 호스팅업체와 제공하는 서비스와 심지어 UI까지 비슷하다. Digital Oceans는 점점 클라우드 업체처럼 되어가고 있고 아마존은 호스팅 업계의 영역까지 군침을 흘리고 있는 모양새다.

어쨌든 Lightsail은 그저 ‘아마존의 웹호스팅 서비스’라는 것이 중요하다.

그런데, AWS를 사용하고 있는 사람 입장에서는 그럼 AWS에서 EC2를 사용하는것과 Lightsail에서 사용하는 것과 뭐가 다른지가 궁금하다. 간단하게 그 차이점을 정리해보려고 한다.

다른 리전에 읽기복제본을 생성해야 될 때가 있다. 대충 추려보면 다음과 같은 경우.

1. 다른 리전에 데이터를 읽기만 하는 워크로드가 있는 경우
2. 다른 리전에 DR 용으로 데이터를 보관하는 경우

그럴때 RDS의 읽기복제본 생성 기능은 매우 간편하고 효과적이다. 파라미터 그룹을 만진다든지 하는 설정을 해줄 필요 없이 대상 리전에 서브넷 그룹만 잘 설정 되어 있으면 콘솔에서 클릭 몇번으로 복제본을 생성할 수 있다.

이번 편에선 DigitalOcean 에서 AWS로 서버들을 옮기는 과정을 적어본다.

전에도 말했지만 리뷰리퍼블릭의 어플리케이션은 meteor.js 라는 프레임워크 (조금 더 정확하게는 meteor.js + react.js) 위에서 돌아간다. 이 프레임워크 덕분에 마이그레이션이 두배는 더 어려워졌다. 일단 익숙한 방식 (어디 한 express.js 나 스프링 MVC 정도 사용할 줄 알았는데…)이 아니기에 이 프레임워크의 전체적인 개념부터 어떤식으로 배포가 되는지를 파악해야 했다.