EMR 에 올라간 Zeppelin 활용하여 Athena 이용하기.

들어가기 전에…

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

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

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

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

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

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

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

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

AWS Athena, Zeppelin과 함께 사용하기 (feat. ALB 로그분석)

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

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

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

AWS Lightsail VS EC2

그림0

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

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

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

AWS RDS mysql - 다른 리전에 읽기복제본 생성: 버전이슈

그림0

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

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

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

reviewrepublic 심폐소생술 - (2)DigitalOcean -> AWS

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

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

reviewrepublic 심폐소생술 - (1)프로젝트 수락

서론

페이스북에 리뷰왕 김리뷰라는 페이지가 있다. 갖가지 리뷰들이 올라오고 요새 올라오는 카드뉴스식의 리뷰를 선도한(…?) 페이지이다. 그 김리뷰가 리뷰리퍼블릭이라는 서비스를 만들었다. 사용자들이 리뷰를 작성해서 올리고 양질의 리뷰를 올릴수록 그 보상이 작성자에게 돌아가게끔 하겠다는 취지로 만들었다고 한다. 어쨋든 겉으로 보이는 형태는 조그만한 커뮤니티 앱이다. 어떻게 보면 sns같기도 하고. 어쨋든 그런 조그마한 커뮤니티 앱이 월 100만원 가량의 유지비가 나온다는 소식을 들었다. 서비스 유지비용이 월 100만원씩 나온다면 도저히 수지타산이 안나온다. 곧 망할 것 같았다.

새로운 테마 적용 - jekyll-swiss

새로운 테마를 적용했다.

원래의 계획은 minima 테마를 커스터마이징 하는 것이었지만,

  1. 디자인에는 재능이 없고
  2. 커스터마이징이 너무 귀찮고
  3. 만들어진 테마 중에 딱 필요한게 구현되어있고 디자인도 마음에 드는걸 발견해서

그냥 테마를 적용하기로 했다.

역시 세상은 넓고 이미 만들어 놓은 좋은 것도 많다. 공부하는 차원에서 만들어보려고 했는데, 굳이 jekyll을 깊게 파면서까지 이걸 커스터마이징할 이유가 없었다. 그래도 꾸역꾸역 기능하나정도 추가하는건 어렵지 않을것 같아서, 다른 jekyll 활용 예를 참고하려고 했고 참고하려고 하니 마음에 드는 테마 하나를 발견했다.

이번에 적용한 테마는 Swiss

이 테마를 적용한 이유는 간단하다.

  1. 예쁘다
  2. 필요한 기능(카테고리별로 묶어주는 기능)이 깔끔하게 구현되어 있다.
  3. 그 외에 잡다한 기능들이 없다.

한 마디로 minima 테마에서 카테고리 별로 정리해주는 기능만 딱 하나 추가되고, 디자인이 예쁘게 정리된 내가 찾던 바로 그 테마인 것이다. 그리고 무엇보다도 다른 기능이 없는 게 중요했다. 다른 다양한 기능이 있다고 해도 내가 쓸 생각이 없기 때문에 기능은 최소의 기능만 있는게 좋다. 그래야 관리도 되고 나중에 커스터마이징 할 때도 코드를 보기가 편하다. 블로그 테마가 계속 마음에 걸렸는데 이걸로 일단 한 동안은 유지할 수 있을 것 같다.

테마 적용방법은 지킬 홈페이지스위스 테마 깃헙 참고. 적용이 매우 간단하다.

[EC2 - T3] T3 인스턴스 출시!!!!!!!

대박사건. EC2 인스턴스 타입 중 작은타입을 지원하고, 테스트용, 혹은 작은규모의 로직을 돌리기에 적합하던 t타입의 인스턴스 중 3세대가 나왔다. 이전 세대인 t2 타입은 2014년에 처음 나왔고 2016년에 다양한 사이즈들이 추가됐다.

그러니깐, 4년만에 t타입의 새로운 세대가 나온 것.

당연히 t2 타입보다 성능은 올라가고, 가격은 떨어졌다. 버지니아 기준으로 가격은 10%정도 저렴하다.
그림1

아쉽게도 서울리전은 아직 지원이 안됨.


**사실 cpu 성능보다 더 기대가 되는것은 네트워크 성능.** m4에서 m5로 업그레이드가 됐을 때 cpu 성능도 증가했지만, 기본 네트워크성능이 많이 향상되었다.(관련글: [EC2 인스턴스의 타입별 대역폭을 살펴보자](https://blog.wisen.co.kr/?p=7751))

마찬가지로 t2에서 t3로 업그레이드 되면서 기본 네트워크 성능이 향상될 것으로 보인다.

그림2
(low to moderate -> up to 5 Gigabit)


이전 t2 인스턴스의 한계라면 cpu 성능이나 불안정성도 한 몫했지만 단순 웹서버로 사용하기에 아쉬웠던 점은 아무래도 네트워크 성능. 작은규모의 웹사이트의 경우 m5.large 정도의 스펙이 불필요하지만 네트워크 성능 때문에 어쩔 수 없이 m5를 선택하기도 했다. 만약 t3에서 네트워크 성능이 일정 기준치 이상으로 향상되었다면 t3 타입은 꽤 매력적인 인스턴스 타입이 될 것 같다.

정확한 사양은 더 테스트해봐야 알겠지만, 어쨌든 좋은소식임에는 분명하다.

참고: https://aws.amazon.com/ko/blogs/aws/new-t3-instances-burstable-cost-effective-performance/

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×