천재태지의 세상 돌려보기

seoz.egloos.com

- About Me... - Enlightenment, EFL - 타이젠 Tizen



GDG(구글 개발자 그룹) Korea 2016년 9월 정기 모임 후기 - 구글 클라우드 서비스 컴퓨팅

며칠 전에 캠퍼스 서울에서 있었던 GDG(구글 개발자 그룹, Google Developer Group) Korea 2016년 9월 정기 모임에 참석했다.
* 참고
GDG[1]는 구글의 기술에 관심있는 개발자들의 모임이다. GDG는 국가별, 도시별, 학교별 모임이 있다. 한국에는 부산, 인천, 안드로이드, 고랭, 웹테크, 서울, 숭실대 GDG 모임이 있다. GDG Korea 모임에 대해서는 GDG Korea 페이스북 페이지[2]를 참고하자.

이번 모임의 주제는 구글 클라우드 서비스였다. 
1. 구글 클라우드 서비스 살펴보기 - 최명근 (슬라이드[3])
2. 대용량 로그분석, 빅쿼리로 간단히 사용하기 - 이재광
3. 취미 번역 - 장기효 (슬라이드[4])
< 그림 1. 구글 클라우드 플랫폼 >

여느때와 다름 없이 많은 분들이 참여해, 구글 기술에 대한 관심을 보여주셨다. 좋은 질문, 그리고 실전 경험이 뭍어나오는 질문을 많이 해주셔서 듣는 나도 도움이 많이 되는 자리였다. 그런데 나는 클라우드 플랫폼을 업무적으로도/개인적으로도 가볍게만 써봐서 못 알아듣는 말이 많았던 건 아쉽다. 하지만 오히려 선입견이 없어서 발표 내용을 있는 그대로 받아들일 수 있었던 것 같다.

< 그림 2. 행사장 전경 >

모임 때 들은 내용 및 코멘트 등을 정리해봤다. 가능한 있는 그대로 정리하려고 했으나 혹시 잘못된 내용이 있으면 코멘트로 제보 바란다.



1. 구글 클라우드 서비스 살펴보기 (발표: 최명근, 슬라이드[3])

구글 클라우드 세일즈 엔지니어이신 최명근 님께서 구글 클라우드 서비스에 대한 개략적인 내용을 이야기해주셨다. 그 중 일부를 요약해본다.

< 그림 3. 최명근 님 발표 >

<구글 클라우드 차별성>
  • 빅데이터 분석과 머신 러닝
  • 가격
  • 네트워크 성능
<구글의 서비스 스케일>
  • 유튜브: 분당 400시간
  • 지메일: 9억명
  • 검색 인덱스: 100PB+
  • 검색 쿼리 반응 시간: 0.025초

정말 엄청난 스케일/퀄리티다. 내가 일하고 있는 유튜브는 분당 400시간 분량의 동영상이 업로드 된다. 이런 스케일이 있는 서비스를 제공한 경험이 구글 클라우드 플랫폼에 녹아들어 있다. 구글 클라우드 플랫폼의 퀄리티가 좋을 수 밖에 없는 이유다. 검색 쿼리 반응 시간은 0.025초라고 했다. (슬라이드에는 0.25초라고 되어 있는데 최명근 님은 0.025초가 맞다고 했다.) 물론 검색어나 상황에 따라서 다르긴 하지만, 내 경험상 0.2 ~ 0.5초 정도 소요되는 것 같다.

<빅쿼리(BigQuery)[5] 예제>
- 위키피디아 페이지 인덱스 천억개가 있는 테이블 에서 제목에 ”G, o, o, g” 알파벳이 순서대로 있는 조건에서 언어 별 조회수 합 쿼리
- 결과
  • 소요시간: 35.1초
  • 사용 데이터: 4.06 TB
  • 사용 하드웨어: 8,800 코어, 3,600 하드 드라이브
  • 사용 비용: 20 달러

발표 도중에 간단한 빅쿼리 데모를 보여줬다. 위키피디아 페이지 인덱스를 천억여개(100B)가지고 있는 테이블에서 정규표현식을 이용해 제목에 ”G, o, o, g”라는 알파벳이 순서대로 있는 인덱스를 추출해 언어별 조회수(views) 합을 구하는 쿼리였다. 이 쿼리를 수행하는 35.1초 동안 총 4.06 테라바이트의 데이터를 사용했으며 8,800개의 코어를 사용했고, 3,600개의 하드드라이브를 사용했다. 이에 들어간 비용은 약 20달러 정도였다.

“그게 어느 정도 좋은건데?”
숫자만 보고 감이 잘 안 오는 나 같은 분을 위해 “MySQL에 이 데이터를 넣고 쿼리를 돌리면 하루 정도 걸린다.”라고 코멘트하셨다. 물론 때로는 쿼리를 돌려놓고 하루를 기다리는게 20 달러를 지불하는 것 보다 더 좋은 경우도 있겠지만 사업을 하는 입장에서 이만큼 시간을 절약할 수 있다는 건 엄청난 이득 아닐까?

<머신러닝>
- TensorFlow
- Cloud Machine Learning
  • Managed Infrastructure
  • Cloud Datalab Notebook experience
- Machine Learning APIs
  • Translate API
  • Speech API
  • Vision API
  • Natural Language API

구글 클라우드는 머신러닝 기술도 제공하는데, 강연 중에 비전(Vision) API를 사용하는 예[6]를 보여줬다. 이 데모는 여러번 봤는데도 볼 때 마다 신기하다. 특히 사진 속에 있는 개개인의 표정 및 시선을 분석해서 보여주는 정보는 놀랄만하다. 데모에서는 고양이 사진, 사람들이 여러명 모여 있는 사진을 보여줬는데, 내가 개인적으로 좋아하는 데모 사진은 야구장 사진이다. 이미지를 분석한 내용 및 정확도를 보여주고, 이미지 안에 있는 글자를 인식해서 보여준다. 더욱 재미있는 것은 이미지 안에 있는 사람 얼굴의 방향, 모자 유무, 감정 등을 수치화해서 보여준다는 것이다. 이런 데모가 코드 22줄 만으로 구현 가능하다고 했다.

< 그림 4. 비전 API 데모 >
< 그림 5. 22줄 짜리 비전 API 데모 코드 (발표 슬라이드 28 페이지) >

<구글 클라우드 가격 정책>
  • 분당 과금 (최소 10분 이상 사용)
  • 사용량에 따른 월별 자동 할인 (최대 30%)
  • 인스턴스 사용량 합산 과금
  • Customizable 인스턴스 제공
  • 자동할인으로 별도의 비용 최적화를 위한 비용 절약

구글 클라우드의 매력 포인트 중 하나는 바로 경쟁사 대비 저렴한 가격이다. 아마존 웹 서비스(AWS)[7]가 시간당 과금을 하는 반면 구글 클라우드 플랫폼은 분당 과금을 한다. 단, 최소한 10분은 사용해야 한다. 쉽게 예를 들면 62분을 사용한 경우 구글 클라우드 플랫폼은 62분에 대한 과금을 하는데 아마존 웹 서비스는 2시간에 대한 과금을 한다. 트래픽에 따라서 인스턴스가 오토 스케일링이 되는 경우 실제 서비스를 돌려보면 비용적인 측면에서 어마어마한 차이가 발생할 것 같다.

<네트워크>
  • 내부망은 페타비트
  • 리젼(region) 간 테라비트 (일본과 대만 사이 26 테라비트)
  • 33개국 100개 이상의 엣지(edge) 로케이션

구글은 대륙간 통신에 자체적으로 구축한 광통신망을 활용하기 때문에 일반 인터넷 회선을 사용하는 경쟁 제품 대비 속도가 빠르다. 확인해보니 타사의 경우도 자체 광통신망을 사용하긴 하는데, 전부는 아니고 부분적으로만 사용하는 것 같다.

현재는 한국에서 가장 가까운 데이터 센터가 대만에 있는데, 올해 4분기에 일본에도 데이터 센터가 추가된다고 하니 한국 사용자들은 속도가 더욱 빨라질 예정이다.

그 외에 몇 가지 질문이 있었다.

Q. CDN 서비스가 있는가?
A. Cloud CDN 서비스가 있음. 전문적으로 CDN 서비스를 제공하는 업체 보다는 부족.

Q. Region을 변경하는 것이 쉬운가?
A. 몇 번의 커맨드를 통해 작업 가능



2. 대용량 로그분석, 빅쿼리로 간단히 사용하기 (발표: 이재광)

이재광 님은 엔비티(NBT)[8]라는 회사 데브옵스(DevOps)팀에 계신 분으로 빅쿼리를 사용한 경험을 진솔하게 전달해주셨다.

* 참고
엔비티는 캐시슬라이드[8]라는 스마트폰 잠금 화면 앱을 만든 회사다. 캐시슬라이드는 스마트폰 잠금 화면에 광고를 삽입해서 잠금화면을 해제할 때 마다 광고를 보게 하고 이를 이용한 사용자에게 돈을 주는 앱이다. 지인 분도 이 앱을 사용하는 것을 본 적이 있다. 나는 귀찮아서...

< 그림 6. 이재광 님 발표 >


엔비티에서는 카프카(Kafka)[9] + ELK[10] + 스파크(Spark)[11] + 제플린(Zeppelin)[12] 조합을 사용했었는데, 무거운 쿼리의 경우 3시간이나 소요되는 문제로 주로 새벽에 배치를 진행했다. 그리고 개별 제품 별로 운영 엔지니어가 붙어야 했기에 엔지니어 리소스를 너무 많이 사용하는 문제가 있었다. 그러던 차에 구글 클라우드 세일즈 엔지니어 조대협님[13]이 엔비티에 오셔서 빅쿼리 강의를 해주셨고, 그 계기로 빅쿼리를 써보게 되었다고 한다.

“구글 클라우드 계정 생성이 제일 어려웠어요.”라고 말할 만큼 빅쿼리는 쉽게 구성이 가능했다. 물론 실제로 빅쿼리를 적용해서 사용한 후 여러가지 예상치 못한 상황을 겪게 되었는데 그 때 마다 어떻게 문제를 해결했는지 팁을 공유해주셨다. 문제는 내가 그 팁들을 부분적으로 밖에 이해하지 못했다는 것… 그래서 이해한 것 위주로 부분적으로 정리를 했다.

JSON[14] 로그 파일이 시간 당 7 ~ 35GB 정도 되는데 이를 업로드하는데 너무 많은 시간이 걸려 Jenkins[15]를 이용해 gz[16] 압축 파일을 구글 클라우드 스토리지로 전송한 후 빅쿼리 로딩 잡을 추가로 실행해서 효율을 향상시켰다. 결국 다음과 같은 변화를 겪었다.

그렇다면 빅쿼리의 속도는 빠른가?
한 달 치 1.34 테라바이트 데이터를 스캔해서 결과를 얻는데까지 걸린 시간이 6초였다. 7명이 동시에 쿼리를 수행해도 동일하게 빠른 성능을 보여준다고 한다. 그 전에는 시스템에 부하가 가는 문제 때문에 쿼리를 돌릴 때 슬랙[20]이 바빠졌을 지경이라고 한다. “누구 쿼리 돌리고 있어요?”라고 물어보려고...

그런데 한번 조회에 1.34 테라바이트면 얼마일까?
쿼리의 경우 처리되는 데이터 1 테라바이트 당 비용이 5 달러라고 한다. 그리고 10 메가바이트 단위로 청구가 되며 월 1 테라바이트 까지는 무료라고 한다. 자세한 내용은 빅쿼리 가격 책정 사이트[21]를 참고하자. 그런데 빅쿼리 영문 사이트 가격 책정 페이지[21]빅쿼리 한글 사이트 가격 책정 페이지[22]의 가격이 다른 것 같다. 왜 다른 건지 모르겠다.
아무튼, 기존에는 너무 느려서 아마존 웹 서비스 EMR[23]도 써봤었는데, 빅쿼리를 써보니 기존 보다 저렴했다고 한다.

그런데 엔비티의 경우는 데이터를 계속 축적해서 새로운 데이터를 기존의 데이터에 추가하는 식으로 운영을 하니까 한 테이블에 모든 내용이 담겨 쿼리를 잘못하면 불필요한 과금이 발생하는 문제에 직면했다. 그래서 기간별 테이블을 만들어서 사용했다고 한다. 빅쿼리에서는 이를 위해 테이블 데코레이터(table decorator)[24], 파티션 데코레이터(partition decorator)[25]를 지원한다.

1. 테이블 데코레이터(table decorator): 최대 7일 이전 데이터까지 조회 가능, milisecond 단위
  • 예) SELECT COUNT(*) FROM [cashslide:dataset.table@-3600000]
2. 파티션 데코레이터(partition decorator): $YYYYMMDD 데코레이터를 이용한 스냅숏(snapshot) 검색, 의사 칼럼(pseudo column)을 이용한 범위(range) 검색
  • 편리한 파티션 테이블(partitioned tables)
  • 데이터 적재 시점을 기준으로 TIMESTAMP(“2016-04-15”) 형식의 값을 지정함

나도 업무상 이와 유사한 테이블을 자주 사용하는데, 실제로 굉장히 편하다. 원하는 시점이나 범위를 지정해서 쿼리를 요청하면 쿼리 시간이 대폭 줄어들어 원하는 결과를 빨리 얻을 수 있다.

발표 마지막으로 팁을 몇 가지 공유해주셨다.
  • 반복 모드(repeated mode)가 존재하는지
  • 파티션 테이블(partitioned table) 사용 고려
  • GCS(구글 클라우드 스토리지)에서 BigQuery
  • 빅쿼리 컴포져(composer) 여러모로 편리함
  • 파일 익스포트(export)의 경우 파일 달 1 기가바이트, 일일 최대 10 테라바이트까지 가능. 이 문제를 회피하기 위해 테이블을 익스포트한 다음에 다운로드 하면 됨
  • 캐시(use cache) 옵션 사용. 이 경우 캐싱된 이전 쿼리 결과를 사용
  • 제플린 0.6.1 부터 ’%bigquery’ 인터프리터 지원
  • 스칼라(Scala) 코드는 SQL 형태로 변환해야 했음

아쉬운 점으로는 Kibana[26], 제플린과 같은 도구가 좀 더 다양하게 지원되었으면 하는 바람이 있다고 하셨다. 대신
Datastudio[27]가 나온다고 하셨는데, 나도 조대협님의 권유로 써본적이 있다. 오~ 데이터 리포팅 용으로 정말 딱이다. Datastudio는 현재 베타 서비스 중이다.

강의가 끝나고 수많은 질문이 이어졌다. 그 중 몇 가지를 정리했다.

Q. 파티션 테이블(partitioned table)은 뷰 테이블(view table)이라고 생각하면 되는가?
A. 일일 뷰 테이블(daily view table)이라고 생각하면 된다. Elastic search 보다 join이 더 나음. 제플린 보다는 부족.

Q. 캐시 설정(use cache) 같은 경우. 테이블 자체를 스캔해놓고 쿼리를 하면 과금이 안 되는가?
A. 데이터 캐시가 아니라 결과 셋 캐시(result cache) 임. 쿼리가 변경되서 결과가 바뀌면 과금 됨

Q. 온프레미스(on premise)로 자체 클러스터를 붙이는 것은 고려해보지 않았나?
A. 피키캐스트 데이터 팀은 IDC를 사용하고 있음. 온프레미스를 사용하는 것은 결국 클라우드보다 더 많은 운영이 필요함

Q. 팀이 몇 명 정도 되는가
A. 개발 문화 담당 포함 5명

Q. Zenkins는 스케쥴링을 위해서 사용하는가?
A. 그렇다.



3. 취미 번역 (발표: 장기효[28], 슬라이드[4])

구글 클라우드 서비스에 대한 두 발표가 끝나고 장기효 님이 라이트닝 토크로 ”취미 번역"이라는 발표를 하셨다.
웹 어플리케이션 최적화와 관련해서 번역을 주로 하시는데, 해외 사용자들이 쓰는 모바일 앱 장애를 해결하기 위해 ”web performance”로 검색했더니 구글 디벨로퍼 사이트 링크가 나왔는데, 영문으로 되어 있어서 아쉬움에 번역을 시작했다고 한다.

< 그림 7. 장기효 님 발표 >

자세한 내용은 발표 슬라이드[4]를 참고하자.

번역을 할 때 번역자 자신을 포함해 “나는 너의 번역을 믿을 수 없다”라는 불신이 생길 수 있는데, 번역을 검수하는 커뮤니티가 있다. HTML5Rocks[29] 사이트 같은 경우는 GDE(구글 개발자 전문가, Google Developer Expert[30])이신 도창욱님[31]이 검수를 해주신다고 한다. 와우, 이런 것도 있었구나. 번역 검수하는 것도 보통 일이 아닐 것 같다.

< 그림 8. 번역의 시작 & 번역 커뮤니티 (발표 슬라이드 32 페이지) >

발표 마지막에는 번역을 하면 뭐가 좋은지에 대한 이야기를 해주셨다.
  1. 콘텐츠 소화력 (최소 3번 정독)
  2. 원작자의 의도 이해
  3. 빠른 재학습
이 발표를 듣고 ”나도 다시 해볼까?”라는 생각이 문득 들었다. 90년대 말 미천한 실력으로 Phrack[32] 번역을 시작으로 이래저래 번역을 해봤었는데, 시간도 많이 들고 정말 쉽지 않은 일이었다. 번역하시는 분들 대단…
최근에는 번역하고 싶은 W3C 스펙이 있긴 한데, 분량이 방대해서 엄두가 나진 않는다.

아무튼, 이번 GDG 행사 내용을 간략하게 정리해봤는데, 나는 클라우드 분야 전문가가 아니라 혹시 잘못된 내용이 있으면 제보 바란다.


1 2 3 4 5 6 7 8 9 10 다음