티스토리 뷰

Log/.daily

구글 클라우드 데이를 다녀와서

가그린민트 2017. 9. 14. 00:56




경기창조혁신센터에서 열린 구글 클라우드 데이에 다녀왔다.

첫 번째 세션이 조대협 님이기도 했고, 경기창조혁신센터 9층의 coworking space도 구경하러 갔다.


우선, coworking space는 대만족이었다.


 (각 공간의 배치도 좋았고, 조명도 적절했으며, 의자도 좋아서 오래 앉아서 집중하기 좋은 환경이었다. 그리고 적당한 정도의 소음과 음악이 까페의 분위기를 자아냈고, 무엇보다 커피가 공짜라는 점이 매력적이었다. 구석에는 휴게 공간도 있었는데 밤에 내려다보는 판교의 거리는 여러 감상에 젖어들게 만들었다.)



AWS는 그 전 부터 간단하게나마 사용해왔었고, awsome day, summit 등의 행사나 awskrug, meetup 소모임 등의 커뮤니티를 통해 접해왔었다. (내 나름대로는) AWS가 public cloud의 기준으로 생각하고 있었기에, 이번 구글 클라우드 데이는 별다른 기대를 하지 않았다.

(도시락을 안주기도 했고 ㅡㅡ. 아, 그러고보니 후기에 쓴다는걸 깜박했는데.. 보통 노트북 들고 오는 사람들도 많고 현업 엔지니어들의 경우에 갑자기 업무를 봐야 하는 경우도 있는데, 현실적으로 모든 자리에 콘센트를 놓기가 힘들다. AWS도 처음에 charging station이 없었는데, 회사 선배가 후기 남기고나서 생긴 거 보고 신기했었는데.. 킁, 이 글을 관계자가 볼 리가 없겠지 ㅋㅋ)


이번 구글 클라우드 데이를 다녀와서 느낀 점은, "와. 이거 AWS와도 경쟁력이 있겠다."


물론, 영어를 못하고 비전공자인 나로서는 당분간 AWS의 친절한 한글 메뉴얼을 벗어나진 못할 것 같다. 하지만 레퍼런스나, AWS의 풍부한 기능들은 시간이 지나면 구글도 해결할 부분들이다. 최근 Google Cloud Platform(이하 GCP)가 평생 무료 정책을 냈다고 이슈인 모양이나, 나는 그보다  GCP의 기반되는 기술력에 경쟁력이 있다는 생각이 들었다.


기억에 남는 주제들은 빅데이타 분석 및 머신러닝 시스템 아키텍쳐(big query, 각종 API, 파이프라인), google network(SDN), firebase, App Engine 등 이다.


아는 만큼 보인다고, 아무것도 모르니 기억에 남는게 별로 없다. 애초에 기분전환할 목적으로 갔던 만큼 가볍게 기억나는 부분만 정리해보고자 한다. (모르는 것 투성이라, 무엇부터 질문해야 할지도 모르겠는..)



빅데이타 분석 및 머신러닝 시스템 아키텍쳐


오픈소스 가지고 예술하지 마세요 ... ㅠㅠ

1. 소프트웨어 기술 중심의 변화


 1) 개발자 리소스를 줄이기 위한 방법론(클라우드의 스케일과 메니지드 서비스를 이용하여 본질에 집중하자.)

 

 2) 데이터 분석 자체보다 인프라 구축 및 운영에 드는 리소스가 너무 많다.

     big query는 2만 4천개 가량의 CPU를 활용하여 1000억개의 like 검색을 하는데 24~30초 밖에 안 걸린다고 한다.        (hadoop, spark 기반으로 3시간 소요되던 작업을 7초에 해결)



그럼 big query란 무엇인가?


big query란, 페타바이트 단위의 데이터를 저장해놓고, 쿼리를 통해서 조회나 통계 작업 등을 할 수 있는 데이터베이스(?)를 말한다. 클라우드 서비스로 지원되므로, 설치/운영은 필요없으며(NoOps), SQL언어를 지원하고, 높은 퍼포먼스와 저렴한 가격정책이 특징인 것 같다.

즉, NoOps이고 SQL 언어를 지원하므로, 더이상 hadoop이나 spark를 세팅하고 분석하는데 리소스를 소모할 필요가 없으며, 구글의 인프라를 이용하니 개별 사용자가 구성한 환경보다 퍼포먼스가 높다는 것. (SE 영역은 갈수록..)

GCP는 big query의 성능과 스케일에 대한 를 제공한다.


특히 최재원 님께서 소개하신 NBT 적용 사례(ELK 스택을 big query로 migration)가 인상깊었는데, 평소에 여유가 생기면 ELK 스택을 학습하려 했었는데.. (Elasticsearch도 제대로 하려면 꽤 학습비용이 든다고 하던데.. big query를 써서 SQL문으로 대체한다는 점이 꽤 신선했다. 다만, 다른 아키텍처를 보아도 fluentd나 logstash가 있는 것으로 보아 데이터 수집부분에 대해서 아직 고민이 있는듯 보이고, Datastudio를 사용하는게 아직 어려운 부분이 많은 듯한 느낌이었다.)



2. 머신러닝에 대한 막연한 두려움 떨쳐내기

 

 1) hashmap, salt 사용할 때 수학 지식 알고 쓰는 거 아니지 않듯 머신러닝도 마찬가지다. 


조대협 님께서 머신러닝에 대한 각 종 주제들(지도학습, 비지도학습, 강화학습 등, 뉴럴 네트워크)에 대해 알려주셨으나, 결론은 만들어져 있는 API를 잘 쓰자고 하셨다. (머신러닝에 대한 알고리즘 다 나와있고, API도 다 나와있으나, 머신러닝이 어려운 것은 어디다 써야할지 모르며, 학습 데이터를 만들기가 어렵기 때문) 

Vision API(예. 야구장 사진으로 뽑을 수 있는 데이터들), Speech API (예. Azar), Transfer API (예. airbnb), video intelligence API 등 다양한 적용 사례들을 소개하셨다.(API 관련 레퍼런스)

 2) 머신러닝 및 딥러닝을 위한 강좌들 (http://mooc.org/, https://hunkim.github.io/ml/)


3. 머신러닝 파이프라인


실제 현업에선 데이터 사이언스와 인트라 엔지니어간의 갈등이 발생한다. (CSV로 달라 vs HBASE로 3일 걸린다)

데이터 수집부터 빅데이터 분석, 학습까지 전체를 하나의 파이프라인으로 통합하여 데이터를 실험하고 튜닝하는 사이클을 빠르게 하자.(http://bcho.tistory.com/1177)


나에겐 너무 어려운 주제였다. 다만 big query가 SQL 지원이 된다는 것과 그 퍼포먼스가 매우 인상적이었다.



구글 클라우드 네트워크를 이용한 네트워크 가속

GCP Network = Google Network


1. 네트워크가 모든 서비스의 기본



구글의 데이터센터들은 광케이블 기반 백본 네트워크로 묶여 있다. 데이터센터 외에 여러 개의 거점에 target proxy라는 중계서버가 배치되어 있는데, 클라이언트가 글로벌 IP(anycast기반)로 접근하면 해당 IP와 가장 가까운 target proxy서버로 라우팅해주며, target proxy서버와 데이터 센터간에도 광케이블로 연결되어 있다.




구글의 네트워크 요소를 살펴보면,

Espresso : Software Defined Edge Network

B4 : Globally-Deployed Software Defined WAN

Andromeda : Google Cloud Platform’s latest networking stack

Jupiter : Google’s Datacenter Network


직관적으로(내 마음대로 해석해보면,) Andromeda Controller가 SDN 기술의 핵심인 것 같고, Jupiter는 구글의 distributed-computing 노하우(borg 등)이 녹아든 DataCenter이며, 이러한 DataCenter들을 Andromeda기술을 기반으로 네트워킹하여 전세계적으로 가장 큰 WAN을 이룬 것이 B4인 것 같다. (GCP network에서는 Switch나 Router도 전부 VM이라고 한다.)

그리고 Espresso는 가장 최신 기술로, end-to-end 최적화를 위해 SDN 개념을 공용망으로 확장한 기술인듯 한데.. 기존의 PoP에 SDN개념을 입힌건가…

기존의 라우터 중심 토폴로지에서는 개별 라우터를 사용해서 packet Stream의 최적경로를 계산하는 방법론에 입각한데 반해, Espresso는 각 Espresso Metro(AS같은건가?) 혹은 global 단위에서 Application Signal을 실시간 최적화하기 위한 방법론인듯 싶다. (사용자 인식에 따라 각 flow들이 어떻게 수행되는지를 학습하고, 사용자를 IP기반으로 정적으로 연결하는게 아니라 서비스를 제공할 곳을 실제 성능 데이터를 기반으로 동적으로 선택한다고 하는데.. 어떻게 고가용성을 유지하면서 그게 가능한지 참 신기할 따름, 문서를 보면 먼저 BGP를 이용해서 peering fabric을 나눈 후 packet processor란 것이 label을 붙여서 판단하는 것 같은데..)

게다가 최근 BBR이란 TCP 혼잡 제어 알고리즘을 통해 최신 네트워크 전송율과 RTT(round-trip time)을 측정해 전송가능한 대역폭 및 지연 가능성을 판단해서 효과적으로 대역폭을 사용하고 네트워크 대기열을 짧게 유지해서 왕복 시간을 줄인다고 하는데.. 세상 참 머리 좋은 사람들 많다

2. 기억에 남는 부분들


인상적이었던 부분은, AWS와 달리 google network로 리전간 연결되어 있어, VPC 하나 만들면 전체 리전에 연결되므로 따로 peering 할 필요없다. 즉, 두 개 이상의 리전을 하나의 CIDR로 구성할 수 있으므로(XPN), Network Topology가 간소화된다.

그리고 GFEs(Global Front Ends) 란 것도 신기했다. 지금껏 부하란, 처리를 실행할 수 없어서 대기하고 있는 프로세스 수(즉, CPU 실행권한 부여를 기다리거나, 디스크 I/O가 완료하기를 기다리는 프로세스)정도로 생각했다. 그래서 부하분산이란 비즈니스 로직상에 병목이 발생하지 않도록 캐싱 혹은 다중화구조를 구성하는 것이라 생각하는데, GFEs 단에서 부하분산을 한다는 건..(보다 친절한 설명은 없는건지.. ㅠㅠ)

이렇게 GFE와 Google Network를 놓고보니 공용망의 개념은 지역화되고(user에서 google network까지의 구간만을 의미하고) 구글에 포섭되는 기분마저 든다.

킁..GFE와 PoP을 포함해서 Espresso라고 하는 것인지, 개념들이 너무 어렵고 이해가 안된다.


AWS와 GCP Network 비교 영상도 있고, GCP Networking 관련 Slideshare공식 문서도 있지만, 영어를 못하니 확연히 어떤 차이가 나는지도 잘 모르겠다(누가 정리해주셨으면.. GCP의 HTTPs Load Balancing과 AWS의 ALB는 무슨 차이인가?, AWS의 PoP은 CloudFront 용도로만 사용하고 GCP는 다용도로 활용된다는데 이건 Espresso덕분인가?)


추가적으로, 네트워크 성능도 우수하다고 한다. AWS ping vs GCP ping



singapore 리전을 비교한 것인데, 아무래도 올해 초 AWS singapore 리전의 latency가 안좋았기 때문인 것 같다. 

(전에 awskrug에 관련 글이 올라왔었는데, 당시에 우리 회사의 경우엔 첫번째 AZ로만 latency가 높았었다.(KT, Uplus, SKT 망 네트워크 테스트 결과 모두 지연현상 발생했었다. 당시에 특이했던 부분은 패킷이 북미쪽을 우회하는 것 같아 EC2의 elastic IP를 whois로 찾아보니 direct assignment는 북미인데 reallocated로 singapore로 세팅되어 있는 부분이 신기했다. 내부적으로 우회한다는 말인건가? ㅡ.ㅡ whois에서 nettype이란 무엇일까..)

그리고 AWS의 자랑인 CDN(CloudFront)도 퍼포먼스에서 밀리나보다.


예전에 공개되었던 테스트 지표인데, 다른 리전은 다른 업체(akamai 등)와 대동소이하나, 아시아 리전에서 latency가 적다고 홍보했었는데, Google은 실시간으로 성능지표를 공개한다. (성능부분은 확실히 자신이 있는듯) 

심지어 GCE도 EC2보다 좋은 점들이 있다.

 1) EC2가 시간당 과금인데 반해 GC2는 처음 10분을 제외하고는 분단위로 청구된다 ! 

     (9/19 추가) AWS는 이제 초당 과금 제도가 시행된다고 합니다. [관련 링크]

     (9/27 추가) GCP도 초당 과금제도가 시행된다고 하네요. [관련 링크]

 2) AWS ELB의 경우엔 급격한 부하 증가를 대비해서 auto-scaling을 붙였어야 하는데, 로드밸런서가 pre-warming이 필요하지 않다고 한다. (로드밸런싱 관련 포스팅)

 3) EBS의 경우엔 공용/EBS전용 네트워크가 분류되어 있어, instance type에 따라 대량의 트래픽이 발생하는 경우 EBS-Optimized를 추가로 세팅(과금)하는 경우도 있었는데, GCP는 모두 최적화되어 있다고 한다.


(추후에 AWS와 GCP 성능 비교 포스팅도 해봐야겠다. 지금은 AWS Technical Trainer이신 정도현님께서 2014년도에 작성하신 포스팅을 보면 GCE의 퍼포먼스가 좋았었다.)

3. 질문한 부분들

google은 자신들의 해저 광케이블이니 문제가 있을 경우 어떻게 되는지 궁금했다.(사실 AWS를 이용중에 해저 광케이블에 문제가 생겼을 경우에 SLA 적용대상인지 여부도 궁금하긴 하다.) google network는 구글의 광케이블 외에도 다른 업체들과 union이 맺어져 있어 문제가 있을시에 자동으로 연동된다고 한다.

google network로 연결되어 있으니 다른 리전간의 통신(같은 CIDR)에 과금이 되는지 궁금했다. (AWS의 경우에 같은 리전이라도 다른 AZ일 경우 약간의 과금이 되기에,) 구글 역시 물리적으로 다른 DataCenter에 위치하므로 과금이 된다고 한다.


Firebase


강의에서 인상적이었던 부분은 Analytics 부분에서 (사용자 속성에 따른) 스트림뷰, 디버그뷰, 유입 경로등 생각보다 쉽게 가공된 데이터들을 뽑아낼 수 있다는 것이었고,

세션이 끝나가면서 드는 생각은 ‘백엔드 개발자가 설 곳도 점점 없어지는구나.’

firebase는 한글 자막 영상이 많다. 간단히 영상만 봐도 어마무시한 것을 느낄 수 있다.

영상 링크 : 소개영상analytics원격 구성인증,  스팅 , 성능 모니터링



서버리스 환경에서의 서비스 개발


결국 GCP도 서버리스 아키텍처 주제를 다루고 있다. 여기서 핵심 주제는 App Engine, Firebase, Cloud Function(for firebase)이다.

우선, 공통적인 백엔드 기능은 firebase에서 지원하고, cloud function을 이용하여 각 종 이벤트에 대한 응답 트리거를 구성하는 것 같다.

AWS의 beanstalk의 대항마로서의 App Engine이 핵심인 것 같은데, App Engine은 컨테이너 기반이기 때문에 트래픽에 따른 민첩한 scale in/out이 가능하다. 또한 다양한 연동 모듈(task queue / LoadBalancing / caching / logging)을 제공하며, 모니터링 기능을 제공한다.(stack driver logging 및 trace API와의 통합을 통해 전 스택 넓은 검색 가능) 그리고 App Engine에서 처리되는 log들은 big query를 통해 디버깅이 가능하며, 빠른 배포 및 오류 대응이 가능하다. (A/B 테스팅)


결론은, big query가 데이터 사이언스에게 데이터 분석 자체에 집중하라고 했다면, 

app engine은 개발자에게 개발(비즈니스 로직)에 집중하라고 하는 것 같다.


IAM은 익숙한 주제이고, big query와 airflow를 이용한 분석 시스템 구축 세션은 어려웠다.


가볍게 들을 생각으로 들어갔다가, 이런저런 생각이 많이 들게하는 행사였다. 지금 나는 그저 프로그래밍하는 것이 좋을 뿐인데.. 업계에서 한달에 하나씩 앱 내놓고 하는 걸 보면 많이 위축된다. 이 쪽 생태계가 내 생각보다 역동적으로 변해가는 것만 같아 걱정이 들지만.. 또 한편으론, 그렇게 많이 늦지 않은 시점에 프로그래밍 공부를 시작하게 되었다는데에 다행이라는 생각도 든다. 좀 더 파이팅하자. 

그리고 최근에 DevOps가 화두가 되면서 AWS 자격증 취득에 사람들이 좀 몰리는 모양이던데, GCP 자격증을 취득한 사람이 아직 국내에 1명밖에 없다고 하던데, 이 쪽 시장도 꽤나 블루오션인 듯하다. 



참조 : 빠르게 훑어보는 구글 클라우드 플랫폼 (무료 ebook)



'Log > .daily' 카테고리의 다른 글

2018년도 계획  (0) 2018.01.02
HTTP 웹 구현 후 알게된 점  (0) 2017.10.24
코드스쿼드 화이트레벨을 마치면서  (1) 2017.09.09
hexo로 블로그를 해보다  (0) 2017.08.31
TIL 시작  (0) 2017.08.24
댓글
링크
최근에 달린 댓글
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Total
Today
Yesterday