블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 


피닉스 패턴의 VM 이미지 타입


조대협 (http://bcho.tistory.com)


피닉스 서버 패턴을 이용해서 이미지를 만들때, 그러면 이미지에 어디까지 패키징이 되어야할지 결정할 필요가 있다. 정답은 없지만 몇가지 정형화된 패턴을 찾을 수 는 있다


OS Image

가상화 환경이나 클라우드를 사용하면 디폴트로 사용하는 패턴으로 이미지가 OS 단위로 되어 있는 패턴이다. 우분투 이미지, 윈도우 이미지와 같이 OS 단위로 이미지가 되어 있다.




피닉스 패턴을 사용할 경우 애플리케이션 배포시, 이미지를 이용해서 VM 을 생성하고 VM 이 기동될때, Configuration management 도구를 이용하여 소프트웨어 스택 (미들웨어, 라이브러리등)과 애플리케이션 코드를 배포하는 방식이다.

Foundation Image

Foundation Image는 이미지를 OS단위가 아니라 서비스 플랫폼, 예를 들어 Ruby on rails 환경, PHP환경과 같은 환경 별로 관리하는 방법이다.



일종의 PaaS와 같은 개념의 이미지로 생각되는데, 가장 적절한 절충안이 아닌가 싶다.


Immutable Image

마지막으로는 Immutable Image (불변) 이미지인데, 이 이미지 타입은 배포마다 매번 새롭게 이미지를 만드는 패턴이다.


항상 OS 부터 애플리케이션 까지 전체 스택이 같이 이미지화 되어 배포되기 때문에, 최신 업데이트를 유지하기가 좋지만, 빌드 시간이 많이 걸리고 관리해야 하는 이미지 양이 많아진다.

이 패턴으로 갈거면 도커를 쓰는게 오히려 정답이 아닐까 싶다.


 OS 이미지 패턴의 경우 VM이 올라오면서 소프트웨어들이 설치되고 애플리케이션이 설치되는 모델인데, 소프트웨어 특히 npm이나 pip들을 이용해서 라이브러리를 설치할때 외부 저장소를 이용하는 경우, 외부 저장소가 장애가 날 경우 소프트웨어 설치가 안되기 때문에 외부 시스템 장애에 대한 의존성을 가지고 있고 설치 시간이 길기 때문에 그다지 좋은 패턴으로는 판단이 안되고, immutable 패턴은 위에서도 언급했듯이 빌드 시간이 길고, 여러 이미지를 관리해야하기 때문에 그다지 권장하고 싶지 않지만, 전체를 매번 묶어서 배포함으로써 일관성 유지가 가능한 장점이 있기 때문에 만약에 해야 한다면 도커를 이용해서 구현하는 것이 어떨까 한다. Foundation Image 패턴이 가장적절한 패턴으로 판단되는데, 다음글에서는 Packer를 이용하여, Foundation Image 타입을 만드는 방법을 알아보도록 하겠다.


구글 클라우드 서버의 HTTP 포트를 SSH 로 터널링해서 로컬에서 접속하기


조대협 (http://bcho.tistory.com)


구글 클라우드 VM에 서버를 설치한 후 웹을 접근하고자 할때, 설치한 애플리케이션이 ACL (접근 제어) 처리가 안되어 있는 애플리케이션이 있을 수 있다. 특히 관리자 콘솔 같은 경우에 이런 경우가 많은데, 아파치 에어플로우 역시도 설치 후에 웹 서버를 띄우면 포트가 모두 퍼블릭으로 오픈되기 때문에 관리자만 액세스가 가능하도록 ACL 처리를 할 필요가 있다.


이를 위한 방법으로는 몇가지가 있는데


  1. 방화벽으로 특정 포트만 허용 하는 방법
  2. 앞에 nginx나 apache를 넣어서 HTTP BASIC AUTH등 인증 방식을 추가하는 방법
  3. Google Cloud Identity Aware Proxy를 이용하여, 구글 클라우드 계정 사용자에게 접근 권한을 부여 하는 방법
  4. 해당 HTTP 포트를 SSH로 터널링 하는 방법

1번 방법은 IP 가 바뀌면 접근 제어 하기가 번거로우니 패스, 2번은 웹서버 깔아야 하니 패스, 3번은 제일 좋은 방법인데, 로드밸런서등 구체적인 설정을 해야 해서 패스. 그래서 오늘은 가장 간단한 4번 방법을 설명한다.

4번 방법은 로컬에서 localhost:2222를 접속하면 구글 클라우드 상의 인스턴스:8080 으로 포워딩을 해준다. 이때 프로토콜을 SSH를 통해서 터널링이 된다.

매우 간단하게 할 수 있는데, 로컬에 gcloud SDK가 깔려 있을때

gcloud compute ssh {인스턴스명} --project {내프로젝트ID} --zone {인스턴스가 있는 존 이름} --ssh-flag="-L" --ssh-flag="{랩탑에서 접속할 포트번호}:localhost:{인스턴스의 포트 번호}"

로 기입해주면 된다.

예를 들어 terrycho-ml 프로젝트의 us-central1-f 존에 있는 hello-airflow 인스턴스의 8080 포트를 로컬에서  localhost:2222로 접근하도록 포워딩 설정을 할 경우 다음과 같이 하면 된다.


gcloud compute ssh hello-airflow --project terrycho-ml --zone us-central1-f --ssh-flag="-L" --ssh-flag="2222:localhost:8080"

데이타 스트리밍 분석 플랫폼 Dataflow 개념 잡기 #1/2


조대협 (http://bcho.tistory.com)


실시간 데이타 처리에서는 들어오는 데이타를 바로 읽어서 처리 하는 스트리밍 프레임웍이 대세인데, 대표적인 프레임웍으로는 Aapche Spark등을 들 수 있다. 구글의 DataFlow는 구글 내부의 스트리밍 프레임웍을 Apache Beam이라는 형태의 오픈소스로 공개하고 이를 실행하기 위한 런타임을 구글 클라우드의 DataFlow라는 이름으로 제공하고 있는 서비스이다.


스트리밍 프레임웍 중에서 Apache Spark 보다 한 단계 앞선 개념을 가지고 있는 다음 세대의 스트리밍 프레임웍으로 생각할 수 있다. Apache Flink 역시 유사한 개념을 가지면서 Apache Spark의 다음 세대로 소개 되는데, 이번글에서는 이 DataFlow에 대한 전체적인 개념과 프로그래밍 모델등에 대해서 설명하고자 한다. 스트리밍 데이타 처리에 대한 개념은 http://bcho.tistory.com/1119 글을 참고하기 바란다.

개념 소개

dataflow에 대해서 이해하기 위해서 프로그래밍 모델을 먼저 이해해야 하는데, dataflow의 프로그래밍 모델은 얼마전에 Apache에 Beam이라는 오픈 소스 프로젝트로 기증 되었다. Apache Spark이나, Apache Flink와 유사한 스트리밍 처리 프레임웍이라고 생각하면 된다. dataflow는 이 Apache beam의 프로그래밍 모델을 실행할 수 있는 런타임 엔진이라고 생각하면 된다. 예를 들어 Apache beam으로 짠 코드를 Servlet이나 Spring 코드라고 생각하면, dataflow는 이를 실행하기 위한 Tomcat,Jetty,JBoss와 같은 런타임의 개념이다.


먼저 dataflow의 개념을 이해해보도록 하자. 아래 그림은 dataflow에 대한 컨셉이다.


데이타가 들어오면, Pipeline IO에서 데이타를 읽어드린다. 읽어드린 데이타는 PCollection이라는 데이타 형으로 생성이 되고, 이 PCollection 데이타는 여러개의 중첩된 PTransform을 통해서 변환 및 가공이 된다. 가공이 끝난 결과는 마지막으로 Pipeline IO의 Output을 통해서 데이타 저장소 (빅쿼리나 파일등)에 저장이 된다.  이 Pipeline IO에서 부터 PTransform을 걸친 일련의 프로세싱 과정을 Pipeline이라고 한다.


예를 들어 설명해보자, 문자열을 입력 받은 후에, 문자열에서 단어를 추출하여, 각 단어의 개수를 세어 주는 파이프라인이 있다고 하자.


첫번째 실행에서 “Hello my daddy”라는 문자열이 입력되었다. 첫번째 Transform인 Extract words Transform을 거치면서, “Hello my daddy” 라는 문자열은 “Hello”, “my”, “daddy” 라는 각각의 단어로 쪼게진다. 다음으로 Count Element 라는 Transform에 의해서, 각 단어의 수를 세어서 저장한다. “Hello”는 1번, “my”는 1번, “daddy”는 1번 의 값이 저장된다.


두번째 실행에서 “Hello my bro” 라는 문자열이 들어오면, Extract words 에 의해서 “Hello”, “my”, “bro”라는 각각의 단어로 쪼게지고, Count Element Transform에서 이전에 세어놓은 단어의 수와 합산하여 계산이 된 결과가 저장이 된다. “Hello”는 이전에 한번 카운트가 되었고 이번에도 들어왔기 때문에, 2가 되고, 같은 원리로 “my”라는 단어의 카운트도 2가된다. “bro” 라는 단어는 이번에 처음 들어왔기 때문에 새 값으로 1로 저장된다.




세번째 “Hello my mom” 이라는 문자열이 들어오면 앞의 두개의 문자열과 마찬가지로 간 단어로 쪼게진 다음 Count Element에 의해서 각 단어의 수가 카운트되어 기존의 값과 누적 합산된다. 모든 데이타를 다 읽어서 처리가 끝나면, 저장된 결과를 Pipeline IO를 통해서 파일에 그 결과를 쓰게 된다.

배치와 스트리밍 처리

dataflow는 위에서 설명한 파이프라인의 개념을 배치와 스트리밍 처리 두가지 개념 모두로 지원해서 처리가 가능하다. 데이타가 파일과 같이 이미 쓰여지고 더 이상 증가나 수정이 되지 않은 데이타에 대해서는 일괄로 데이타를 읽어서 결과를 내는 배치 처리가 가능하고, 계속해서 들어오고 있는 데이타 (트위터 피드, 로그 데이타)는 스트리밍으로 처리가 가능하다.

윈도우의 개념

배치 처리야, 데이타 처리가 모두 끝난 후에 결과를 내보낸다고 하지만, 그렇다면 스트리밍 데이타는 계속해서 데이타가 들어오고 있는데, 언제 결과를 내보내야 할까?

개별 데이타를 변환해서 저장하는 경우에야, 개별 데이타 처리가 끝난후에 각각 하나씩 저장한다고 하지만, 위와 같이 들어오는 데이타에서 특정데이타 들에 대한 합이나 평균과 같은 처리를 하는 경우 어느 기간 단위로 해야 할까? 스트리밍 처리에서는 이러한 개념을 다루기 위해서 윈도우라는 개념을 사용한다.


예를 들어, “1시~1시10분까지 들어온 문자열에 대해서 문자열에 들어 있는 각 단어의 수를 카운트해서 출력해주는 기능" 이나, 또는 “매 5분 단위로 현재 시간에서 10분전까지 들어온 문자열에 대해서 각 단어의 수를 카운트 해서 출력 해주는 기능" 과 같이 작은 시간 기간의 단위를 가지고 그 기간 단위로 계산 하는 방법이며, 이 시간 단위를 윈도우(Window)라고 한다.


Fixed Window (고정 크기 윈도우)

앞의 예에서 1시~1시10분, 1시10분~1시20분 과 같이 고정된 크기를 가지는 윈도우의 개념을 Fixed Window라고 한다.


Sliding Window (슬라이딩 윈도우)

앞의 예에서와 같이 윈도우가 상대적인 시간 (이전 10분까지)의 개념을 가지면서, 다른 윈도우와 중첩되는 윈도우를 슬라이딩 윈도우라고 한다.


그림과 같이 1시10분의 윈도우는 1시 10분의 10분전인 1시에서 부터, 현재 시간 까지인 1시10분까지 값을 읽어서 처리하고 윈도우가 끝나는 시점인 1:10분에 그 값을 저장한다. 윈도우의 간격은 5분 단위로, 1시 15분에는 1시 15분의 10분전인 1시05분 부터 현재 시간인 1시15분까지 들어온 데이타에 대해서 처리를 하고 그 결과 값을 1시15분에 저장한다.

Session window (세션 윈도우)

다음은 세션 윈도우라는 개념을 가지고 있는데, 이를 이해하기 위해서는 먼저 세션의 개념을 먼저 이해해야 한다.

세션이랑 사용자가 한번 시스템을 사용한 후, 사용이 끝날때 까지의 기간을 정의한다. 스트리밍 시스템에서는 사용자 로그인이나 로그 아웃을 별도의 이벤트로 잡는 것이 아니기 때문에, 데이타가 들어온 후에, 일정 시간 이후에 그 사용자에 대한 데이타가 들어오지 않으면, 세션이 종료 된것으로 판단한다.

일반 적인 웹 프로그램에서 HttpSession과 같은 원리인데, 웹 사이트에 접속한 후, Session time out 시간이 지날때 까지 사용자가 별도의 request를 보내지 않으면 세션을 끊는 것과 같은 원리이다.

아래 그림은 세션 윈도우의 개념을 설명하기 위한 윈도우인데, User A와 User B의 데이타가 들어오고 있다고 하자.


그리고 세션 타임 아웃이 10분으로 정의했다. 즉 같은 사용자에 대해서 데이타가 들어온 후, 10분 내에 추가 데이타가 들어오지 않으면 세션이 종료 된것으로 판단한다.


User A는 1:00 에 첫 데이타가 들어와서1:00~1:10 사이에 두번째 데이타가 들어왔고, 1:10~1:20 사이에 세번째 데이타가 들어온 후, 네번째 데이타는 10분이 지난 후에 들어왔다. 그래서 1:00~1:20 까지가 하나의 세션이 되고, 이것이 User A에 대한 1:00~1:20의 세션 윈도우가 된다. 네번째 데이타 부터는 새로운 윈도우로 처리가 되는데, 1:40~1:50 사이에 다섯번째 데이타가 도착한후, 그 이후로 도착하지 않았기 때문에 이게 두번째 윈도우가 되고, 1:30~1:50의 시간 간격을 가지는 User A의 두번째 윈도우가 된다.

각 윈도우의 값은 User A의 1:00~1:20 윈도우의 값은 (1+1+1)로 3이 되고, 두번째 윈도우인 1:30~1:50 윈도우는 (2.5+1)로 3.5가 된다.


User B는 1:10에 데이타가 들어오고, 10분 후인 1:20까지 데이타가 들어오지 않고 그 이후 1:30 분에 두번째 데이타가 들어왔기 때문에, 1:10~1:10 길이의 첫번째 세션 윈도우가 생성된다. 다음 으로 1:30분에 데이타가 들어왔기 때문에 두번째 세션 윈도우를 생성하고, 2:00까지 계속 데이타가 들어오다가 멈추고 2:10까지 새로운 데이타가 들어오지 않았기 때문에 1:30~2:00 까지 두번째 윈도우로 취급한다.


이 Session Window는 앞서 언급한 Fixed Window나, Sliding Window와는 다르게, User A, User B와 사용자 단위와 같이 어떤 키에 따라서 개별적으로 윈도우를 처리 한다.  즉 Session Window는 User A나 USer B처럼 특정 키에 종속된 윈도우만을 갖는다.


반대로 Fixed Window나 Sliding Window는 키단위의 윈도우가 아니라 그 시간 범위내에 들어 있는 모든 키에 대한 값을 처리한다..

Fixed Window의 경우에는 30분 사이즈를 갖는 윈도우라고 하면 아래 그림과 같이


1:00~1:30 윈도우는 User A의 값 = (1+1+1) 과 User B의 값 1을 합쳐서 총 4가 되고

1:30~2:00 윈도우는 User A값 = (2.5+1)과 User B의 값 = (2+2+2) 를 합쳐서 9.5가 된다.


Sliding Window의 경우에는 길이가 30분이고, 주기가 20분인 Sliding 윈도우라고 할때,


1:00~1:30, 1:20~1:50, 1:40~2:00 3개의 Sliding 윈도우가 생성된다.

1:00~1:30 윈도우는 User A의 값=(1+1+1)과 User B의 값 1을 합산하여 4가 되고

1:20~1:50 윈도우는 User A의 값 = (2.5+1)과 User B의 값 =(2+2)를 합산하여 7.5가 된다.

1:40~2:00 윈도우는 User A의 값 = (2.5+1)과 User B의 값 (2+2)를 합산하여 7.5가 된다.




구글 데이타 스트리밍 데이타 분석 플랫폼 dataflow - #1 소개


조대협 (http://bcho.tistory.com)


실시간 데이타 처리에서는 들어오는 데이타를 바로 읽어서 처리 하는 스트리밍 프레임웍이 대세인데, 대표적인 프레임웍으로는 Aapche Spark등을 들 수 있다. 구글의 DataFlow는 구글 내부의 스트리밍 프레임웍을 Apache Beam이라는 형태의 오픈소스로 공개하고 이를 실행하기 위한 런타임을 구글 클라우드의 DataFlow라는 이름으로 제공하고 있는 서비스이다.


스트리밍 프레임웍 중에서 Apache Spark 보다 한 단계 앞선 개념을 가지고 있는 다음 세대의 스트리밍 프레임웍으로 생각할 수 있다. Apache Flink 역시 유사한 개념을 가지면서 Apache Spark의 다음 세대로 소개 되는데, 이번글에서는 이 DataFlow에 대한 전체적인 개념과 프로그래밍 모델등에 대해서 설명하고자 한다.  스트리밍 데이타 처리에 대한 개념은 http://bcho.tistory.com/1119 글을 참고하기 바란다.

소개

dataflow에 대해서 이해하기 위해서 프로그래밍 모델을 먼저 이해해야 하는데, dataflow의 프로그래밍 모델은 얼마전에 Apache에 Beam이라는 오픈 소스 프로젝트로 기증 되었다. Apache Spark이나, Apache Flink와 유사한 스트리밍 처리 프레임웍이라고 생각하면 된다. dataflow는 이 Apache beam의 프로그래밍 모델을 실행할 수 있는 런타임 엔진이라고 생각하면 된다. 예를 들어 Apache beam으로 짠 코드를 Servlet이나 Spring 코드라고 생각하면, dataflow는 이를 실행하기 위한 Tomcat,Jetty,JBoss와 같은 런타임의 개념이다.


런타임

Apache Beam으로 작성된 코드는 여러개의 런타임에서 동작할 수 있다. 구글 클라우드의 Dataflow 서비스에서 돌릴 수 도 있고, Apache Flink나 Apache Spark 클러스터 위에서도 그 코드를 실행할 수 있으며, 로컬에서는 Direct Pipeline이라는 Runner를 이용해서 실행이 가능하다.


여러 런타임이 있지만 구글 클라우드의 Dataflow 런타임을 사용하면 다음과 같은 장점이 있다.


매니지드 서비스로 설정과 운영이 필요 없다.

스트리밍 처리는 하나의 노드에서 수행되는 것이 아니라, 여러개의 노드에서 동시에 수행이 되기 때문에, 이 환경을 설치하고 유지 보수 하는 것만 해도 많은 노력이 들지만, Dataflow는 클라우드 서비스이기 때문에 별도의 설치나 운영이 필요없고, 작성한 코드를 올려서 실행 하기만 하면 된다.

Apache Spark등을 운영해본 사람들은 알겠지만, Spark 코드를 만드는 것 이외에도, Spark 클러스터를 설치하고 운영 하는 것 자체가 일이기 때문에, 개발에 집중할 시간이 줄어든다.

오토 스케일링을 지원하기 때문에, 필요한 만큼 컴퓨팅 자원을 끌어다가 빠르게 연산을 끝낼 수 있다.

클라우드 컴퓨팅의 장점은 무한한 자원을 이용하여, 워크로드에 따라서 자원을 탄력적으로 배치가 가능한 것인데, Dataflow 역시, 이러한 클라우드의 장점을 이용하여, 들어오는 데이타량이나 처리 부하에 따라서 자동을 오토 스케일링이 가능하다.


그림처럼 오전에 800 QPS (Query per second)의 처리를 하다가 12시경에 부하가 5000 QPS로 늘어나면 그만한 양의 리소스 (컴퓨팅)를 더 투여해서 늘어나는 부하에 따라서 탄력적으로 대응이 가능하다.

리밸런싱(Rebalancing)기능을 이용하여 작업을 골고루 분배가 가능하다.

Spark이나 Hadoop Map & Reduce와 같은 대용량 분산 처리 시스템의 경우 문제가 특정 노드의 연산이 늦게 끝나서 전체 연산이 늦게 끝나는 경우가 많다. 예를 들어 1000개의 데이타를 10개씩 100개의 노드에서 분산하여 처리를 한후 그 결과를 모두 모아서 합치는 연산이 있다고 할때, 1~2개의 노드가 연산이 늦게 끝나더라도 그 결과가 있어야 전체 값을 합칠 수 있기 때문에, 다른 노드의 연산이 끝나도 다른 노드들은 기다려야 하고 전체 연산 시간이 느려 진다.


Dataflow의 경우는 이런 문제를 해결 하기 위해서, 리밸런싱(rebalancing)이라는 메카니즘을 발생하는데, 위의 그림(좌측의 그래프는 각 노드의 연산 시간이다.) 과 같이 특정 노드의 연산이 느려진 경우, 느려진 노드의 데이타를 다른 연산이 끝난 노드로 나눠서 재 배치하여 아래와 같이 전체 연산 시간을 줄일 수 있다.




구글 클라우드 제품 소개





구글 클라우드 시작하기

계정 생성과 VM 생성하기

조대협 (http://bcho.tistory.com)


구글 클라우드 플랫폼에서 가상머신 VM을 생성해주는 GCE (Google Compute Engine)을 통해서 간단하게 VM을 생성하고 웹서버를 띄우는 방법에 대해서 알아보자.

계정 가입

먼저 GCP 클라우드를 사용하기 위해서는 구글 계정에 가입한다. 기존에 gmail 계정이 있으면 gmail 계정을 사용하면 된다. http://www.google.com/cloud 로 가서, 좌측 상당에 Try it Free 버튼을 눌러서 구글 클라우드에 가입한다.




다음 콘솔에서 상단의 Google Cloud Platform 을 누르면 좌측에 메뉴가 나타나는데, 메뉴 중에서 “결제" 메뉴를 선택한후 결제 계정 추가를 통해서 개인 신용 카드 정보를 등록한다.


개인 신용 카드 정보를 등록해야 모든 서비스를 제한 없이 사용할 수 있다.  단 Trial의 경우 자동으로 한달간 300$의 비용을 사용할 수 있는 크레딧이 자동으로 등록되니, 이 범위를 넘지 않으면 자동으로 결제가 되는 일이 없으니 크게 걱정할 필요는 없다.


프로젝트 생성

계정 생성 및 결제 계정 세팅이 끝났으면 프로젝트를 생성한다.

프로젝트는 VM이나 네트워크 자원, SQL등 클라우드 내의 자원을 묶어서 관리하는 하나의 집합이다. 여러 사람이 하나의 클라우드를 사용할때 이렇게 프로젝트를 별도로 만들어서 별도로 과금을 하거나 각 시스템이나 팀별로 프로젝트를 나눠서 정의하면 관리하기가 용이하다.


화면 우측 상단에서 프로젝트 생성 메뉴를  선택하여 프로젝트를 생성한다.



프로젝트 생성 버튼을 누르면 아래와 같이 프로젝트 명을 입력 받는 창이 나온다. 여기에 프로젝트명을 넣으면 된다.


VM 생성


프로젝트가 생성되었으면, 이제 VM을 만들어 보자

좌측 메뉴에서 Compute Engine을 선택한다.


다음으로 바뀐 메뉴에서 좌측 VM 인스턴스를 선택한 후에, “인스턴스 만들기"를 통해서 인스턴스를 생성한다.

VM 인스턴스는 다음과 같은 조건으로 생성할것이다.


  • 인스턴스 이름은 ubuntu-instance

  • 가장 작은 사이즈의 인스턴스 (초소형 인스턴스 vCPU *1, 0.6G 메모리)

  • 10 GB의 로컬 디스크

  • Ubuntu 14.04LTS

  • 유동 외부 IP

  • HTTP 트래픽 허용


VM 생성창에서 위의 조건에 따라 아래 화면과 같이 설정값을 세팅 한후 VM을 생성한다. 나머지 값들은 디폴트로 놔두면 된다.





몇가지 주의할점은 “ID 및 API 액세스" 부분에서 “액세스 범위"를 “모든 Cloud API에 대한 전체 액세스 허용" 으로 세팅해줘야 한다. 이부분은 구글 클라우드에서 제공하는 API나 CloudSQL,BigQuery,Vision API 등 다른 서비스를 이 VM이 호출 할 수 있는 권한을 주는 것이다. 이 설정은 VM 생성 초기에 하지 않으면 차후에 변경이 불가능하니 반드시 설정 초기에 하기 바란다.


다음으로 “네트워크 부분”에 “외부 IP” 부분을 “임시”로 설정한다.


외부 IP 는

  • 지정하지 않음

  • 임시

  • 고정 주소


3가지를 선택할 수 있는데, 지정하지 않을 경우 이 VM은 외부 IP (Public IP)를 가지지 않기 때문에 인터넷에서 직접적으로 이 VM에 접근할 수 없다. HTTP 요청의 경우 별도의 프록시나 로드밸러서를 앞에 놓고 접근을 하거나 SSH와 같은 쉘 접근도 같은 내부 네트워크 (Private IP) 대역에 있는 다른 VM을 통해서만 접근이 가능하다. ( 이미 잘 알고 있겠지만 ) 외부 IP 주소를 가지지 않는 VM은 외부로 부터 접근을 차단하여 보안성을 높이기 위한 의도이다.


그리고 VM 생성시에 영역 (Zone)을 설정하는데, Zone은 클라우드 VM이 생성되는 장소라고 생각하면 된다.

리젼이 가장 큰 개념으로 대륙을 정의 한다. 미국 중부,서부,아시아,유럽 등이 리전에 해당하고, 각 리전안에는 여러개의 데이타 센타가 있는데, 이 데이타 센타를 영역 (Zone)으로 생각하면 된다. 이 예제에서는 asia-east1-a에 인스턴스를 생성한다.


인스턴스가 생성되면 아래 화면과 같이 생성된 인스턴스가 기동됨을 확인할 수 있다.



브라우져를 통한 SSH 접속

인스턴스가 생성되었으면 이제 생성된 인스턴스로 SSH로 접속해보자 PC의 Putty와 같은 SSH 터미널을 이용해서 접근하는 방법은 http://bcho.tistory.com/1103 링크를 참고하기 바란다.

이러한 방법이 복잡할 경우 화면에서 VM 우측에 SSH 버튼을 누른다.


그러면 별도의 SSH 터미널이 없이도 아래 그림과 같이 웹 브라우져 상에서 SSH 터미널을 오픈해준다.

아파치 웹서버 설치


SSH로 접속을 했으면, 이제 아파치 웹서버를 설치하고 기동해보자 설치는 우분투의 apt-get 유틸리티를 사용할것이다.

먼저 apt-get 저장소를 최신으로 업데이트 하기 위해서 다음 명령어를 실행한다.

%sudo apt-get update

다음으로 apache2 웹 서버를 설치해보자

%sudo apt-get install apache2


설치가 끝나면 자동으로 apache 웹서버가 기동이 된다. 혹시 기동이 되고 있지 않다면 다음 명령어를 이용해서 기동하자

%sudo apachectl start


기동이 되었는지를 확인하려면 이 VM의 외부 IP(public ip)로 브라우져를 통해서 접속해보자.

접속이 성공하면 다음과 같은 페이지가 브라우져에 뜨는 것을 확인할 수 있다.




VM 삭제


만약에 서비스를 계속해서 하지 않을 것이면 VM 을 정지하거나 삭제하면된다.

정지와 삭제의 차이는  정지된 VM은 나중에 재 시작이 가능하다. 단 스토리지 비용은 계속 과금 된다. 삭제는 VM을 없애 버리는 것으로 다시 재시작이 불가능하고 당연히 아무 비용도 과금되지 않는다.


VM의 정지나 삭제는 아래 그림과 같이 인스턴스 목록에서 정지 또는 삭제하고자 하는 VM을 선택한 후, 상단 메뉴에서 [정지] 또는 [삭제] 메뉴를 선택하면 된다.




참고 자료



알아서 깍아주는 구글 클라우드의 가격 정책

조대협 (http://bcho.tistory.com)


구글 클라우드에 대해서 공부를 하다보니, 가격 정책을 살펴보게 되었는데, 흥미로운 가격 정책이 있어서 정리를 해본다.


구글 클라우드의 가격정책은 다른 클라우드에 비해서 크게 다음과 같은 특징을 가지고 있다.

  • 분단위 과금

  • 장기 계약 없이 알아서 깎아 주는 정책

  • VM 사용량을 자동으로 합산해서 깎아 주는 정책

  • 커스텀 인스턴스

분단위 과금

구글 클라우드의 인스턴스에 대한 과금 정책은 분단위 과금이다. 최소 10분은 과금이 되고 그 이후의 사용량에 대해서는 분단위로 과금이 된다. 타 클라우드의 경우에는 시간단위 과금이 많은데, 그렇다 보니 1시간 1분을 사용하더라도 고스란히 2시간이 과금된다. 하둡이나 배치 작업 처럼 일정 시간에만 과금이 되는 연산의 경우, 연산 시간을 시간 단위로 끊을 수 가 없어서 타 클라우드의 경우에는 올림으로 계산이 되서 과금이 되지만, 구글 클라우드는 분단위로 계산이 되기 때문에 단기적으로 사용하는 배치나 분산 연산 작업등에 효율적으로 사용될 수 있다.

장기 계약 없이 알아서 깎아 주는 정책

재미있는 기능중에 하나가 인스턴스를 일정 시간 이상 사용을 하면 자동으로 디스카운트가 된다. 한달 내내 인스턴스를 사용하면 30%가 디스카운트가 되고, 한달에 25% 이상 사용하면 단계적으로 디스카운트가 된다. 자동으로!!


이게 왜 중요한가 하면, 보통 클라우드에서 인스턴스 가격을 할일 받기 위해서는 미리 사용할 인스턴스의 타입과 기간을 명시해야 한다. 이 경우에 문제는

첫번째 장기 계약시 구세대 인스턴스를 계속 사용해야 한다는 것이다. 3년 계약으로 인스턴스에 대한 가격 할인을 받으면 3년동안 계속 구세대 인스턴스를 사용한다는 이야기인데, 클라우드의 인스턴스 성능이 빠르게 나날이 발전하기 때문에, 비용은 계약당시 싸다고 느낄 수 있지만 시간이 지날 수 록 저성능 인스턴스를 사용하기 때문에, 과연 혜택이 있는지 고민해봐야 한다.


두번째로 장기 계약을 하면 무조건 그 인스턴스를 계속해서 사용해야 하기 때문에, 비지니스 상황에 따라서 다른 인스턴스로 바꾸거나 또는 인스턴스 수를 줄일 수 없다.


구글 클라우드의 경우에는 이런 고민을 할필요가 없이 최신이나 구형이나 인스턴스를 그냥 쓰면 사용한 양에 따라서 알아서 할인이 된다.

VM 사용량을 자동으로 합산해서 깍아 주는 정책

요것도 재미있는 할인 정책중에 하나인데, 위의 할인 정책을 쓰려면 월 사용량이 30% 이상이 되어야 한다. 30% 할인을 받으려면 한달을 다 써야 하는데, 만약에 인스턴스 A를 30%, 인스턴스 B를 30% 인스턴스 C를 20%, 인스턴스 D를 20% 쓴다면 어떻게 될까? 위의 할인 정책에 의하면 할인이 안될거 같은데? 답은 된다.


구글 클라우드의 가격 정책은 총 사용량을 모아서 할인을 할 수 있게 해준다. 즉 A,B,C,D의 총 사용량이 월 100%가 되기 때문에, A,B,C,D의 금액중 전체를 30% 할인해준다.




만약에 인스턴스 타입이 달라도 할인이 가능할까?

답은 역시 Yes이다. 원리는 작은 인스턴스 스펙으로 잘라서 이 사용량을 묶은 후에, 할인을 하는 방식인데, 아래 그림 처럼 2CPU 4G 인스턴스 50%, 4 CPU, 8G 인스턴스 50%를 사용하면, 4GB 8G 인스턴스의 사용량을 앞의 2 CPU 4G에 맞춰서 합산해서 100%로 계산하고 남은 2 CPU, 4G로 50% 사용한량은 별도로 과금하는 방식이다.


커스텀 인스턴스

인스턴스 가격 정책과 함께 재미있는 것중의 하나는 미리 정해진 인스턴스 타입뿐 아니라 필요한 인스턴스 타입을 직접 정할 수 있다. 필요한 수의 CPU와 메모리를 지정해서 사용할 수 있기 때문에, 많은 CPU가 필요하고 적은 메모리가 필요할때(혹은 반데로) 불필요하게 큰 인스턴스를 사용할 필요 없이 딱 필요한 싸이즈로 적용하고 그에 해당하는 금액만 지불하면 된다.


정리를 하자면, 구글 클라우드의 과금 정책은 쉽게 이해하면 돈을 뜯어내는게 아니라 되도록이면 할인을 해주는 방식으로 이거저거 생각할 필요 없이 쓰면 알아서 최적화된 과금 방법 찾아서 알아서 할인해준다.


과금에 대한 자세한 내용을 https://cloud.google.com/compute/pricing#sustained_use

를 참고하기 바란다.



구글 클라우드 MySQL서비스의 흥미로운 가격 정책

조대협 (http://bcho.tistory.com)


구글 클라우드의 MySQL 서비스인 CloudSQL을 보다보니, 신기한 가격 정책이 있어서 정리해놓고자 한다.

1세대와 2세대의 가격 정책이 다른데, 1세대의 가격 정책이 재미있는점이 있다.


기본 가격 정책


1,2세대 모두 기본 적인 가격 정책은 다음과 같다


저장량 + 인스턴스 기동 비용 + 네트워크 비용

  • 저장량은 말 그대로 저장된 데이타의 양에 따라 과금이 된다
  • 네트워크 비용은 outbound로 나가는 트래픽만 과금이 되는데, 이것도 같은 리전 안의 구글 클라우드에서 호출하는 경우에는 과금이 되지 않는다. 과금이 되는 경우는 구글 클라우드를 쓰더라도 다른 대륙의 인스턴스가 호출을 하거나 또는 다른 클라우드 서비스에서 호출을 하는 경우에만 과금이 되기 때문에, 일반적인 상황에서는 거의 네트워크 트래픽 비용이 과금이 되지 않는다.
  • 인스턴스 기동 비용은 인스턴스가 떠있는 동안데 받는 비용인데 이 부분이 흥미롭다.
인스턴스 가동 비용

1세대 CloudSQL 경우 Package plan 과 Pay per use plan 두가지가 있다.
Package Plan은 일단위 과금이며, 인스턴스가 기동이 되어 있는 일 기준으로 과금이 된다. 이건 모 일반적인 것이고
흥미로운 가격 정책이라고 하는것은 Pay per use plan이다. Pay per use plan은 인스턴스가 떠 있는 시간동안 분당 과금을 하는 것이다. 일반적인 분당 과금 처럼 보일 수 있지만 재미 있는 것은 Cloud SQL 인스턴스 생성시 activation policy (활성화 정책) 이라는 것을 설정할 수 있는데, 이 활성화 정책을 ALWAYS(항상) 으로 해놓으면, 인스턴스를 수동으로 내리지 않는 이상은 항상 떠 있는 케이스이다. 여기까지가 일반적인것이고
활성화 정책중 ON DEMAND(요청시)로 해놓으면, MySQL이 15분 동안 아무 Request가 없으면 해당 MySQL 인스턴스는 자동으로 비활성화 되고 인스턴스 비용이 과금되지 않는다. 비활성화 상태에서 요청이 들어오면 자동으로 활성화 상태가 된다. ON DEMAND는 활성화 상태에서 사용량을 분당으로 과금한다.

아래 그림은 CloudSQL 인스턴스를 생성할때, ON DEMAND 활성화 정책 + 사용량에 따른 청구 방식으로 설정하는 화면이다.




쉽게 설명하면, 서버에 요청이 없으면 자동으로 대기 상태로 들어가면서 데이타 저장 비용만 과금이 되고, 인스턴스 비용은 과금이 되지 않는다는 이야기이다.

이는 항상 서버가 돌아도 되지 않는 일 배치나 또는 개발 환경등에 유용하게 사용될 수 있다. 
물론 이렇게 인스턴스가 될때만 과금하게 하는 것은 수동으로 데이타를 백업 받고 인스턴스를 내렸다가 사용할때 인스턴스를 새로 올리고 데이타를 부어도 되고 또는 수동으로 일일이 인스턴스를 껐다 켰다 해도 유사한 효과를 볼 수 는 있지만, AWS의 경우 시간당 과금이기 때문에, 개발 환경처럼 수분을 쓰고 마는 환경에서는 분당 과금인 CloudSQL에 비해서 금액 절약효과를 보기가 어렵고, 무엇보다 귀찮다.

아래는 20GB 용량을 하루에 4시간 정도 D32 인스턴스로(32GB 메모리 머신) , 300만 IO가 발생하는 일배치를 돌리는 시나리오에서 추가 IO가 없다고 가정할때 가격 시뮬레이션 한 케이스인데 Package plan을 이용할 경우 약 한달에 1116$, Pay per use plan을 사용할 경우 약 338$ 로 약 3.4배 정도의 가격 차이가 있는 것을 확인할 수 있다. 
(참고, Package Plan의 D32 인스턴스는 300만 IO까지는 무료이며, Pay Per Plan의 경우 무조건 100만건당 0.1$가 과금된다. 아래 계산 결과는 Pay per use는 모든 IO 가 과금이 되기 때문에 # of IO를 300만으로 입력하였고, Package Plan은 무료 IO를 넘는 부분에 대해서만 입력하기 때문에, 현재 계산에서 300만 IO는 D32 인스턴스 크기에서는 무료이기 때문에 별도 입력하지 않았다.)




1세대의  Pay per use plan을 사용하면 딱 트렌젝션을 돌릴때만 분당 과금을 할 수 있기 때문에 가격이 저렴해진다.
단 주의 할점은 오랜 시간 서버를 돌리는 경우에는 Pay per use plan 보다는 당연히 Package plan이 저렴하기 때문에 일정 시간 이상 인스턴스를 사용하는 경우는 Pay per use 보다는 package plan을 사용하기 바란다.

가격 정책에 대한 자세한 내용은 https://cloud.google.com/sql/pricing 에 있다. 
어떤 정책이 유리한지는 가격 시뮬레이션을 해보면 되는데 시뮬레이션용 계산기는 https://cloud.google.com/products/calculator/ 를 사용하기 바란다.



구글 클라우드 VM으로 SSH  접속하기


조대협 (http://bcho.tistory.com)


클라우드에서 VM을 생성하면, 이 VM에 접속하기 위해서 리눅스 VM의 경우 일반적으로 SSH 연결을 사용한다.

구글 클라우드에서 SSH를 이용하여 VM에 접속하는 방법을 알아본다.


1. SSH 키페어 생성

ssh-keygen 명령어를 이용하여 다음과 같이 RSA 키페어를 생성한다.

%ssh-keygen -t rsa -C "구글계정명"



2. 키페어가 생성이 되었으면 *.pub으로 끝나는 이름의 퍼블릭키의 내용(텍스트)를 복사한후, 콘솔창에서 "Compute Engine > Metadata > SSH Keys"  부분에 복사한 텍스트를 붙여 넣어서 키를 등록한다.




3. 키 등록이 끝났으면, 이 키를 이용하여 SSH로 접속한다.

% ssh -i [Private 키 파일] 계정@호스트명



Google Cloud Vision API 사용하기


구글 클라우드 비젼 API 사용하기

조대협 (http://bcho.tistory.com)






빅데이타와 머신러닝과 같은 기술이 요즘 인터넷을 매우고 있는 시대에, 구글이 얼마전 이미지 디텍션 (Image detection)이 가능한, Cloud Vision API라는 오픈 API를 발표하였다. 현재는 베타버전 상태인데, 호기심에 빠르게 한번 테스트를 해봤다.


node.js를 이용하여, 간단한 테스트 프로그램을 만들어서 테스트를 해봤는데, 구현에 걸리는 시간은 불과 10분이 안된듯... (node.js는 역시 프로토타이핑용으로는 정말 좋은듯)


Cloud Vision API 억세스 권한 얻기


Cloud Vision API는 현재 베타 상태이다. 접근을 하려면 별도로 요청을 해야 접근 권한을 받을 수 있다. https://cloud.google.com/vision/ 에서 권한을 신청하면 심사를 하고 권한을 준다. 



Cloud Vision API 활성화 하기

권한을 얻은 후에는 Google Cloud Platform API 관리자 콘솔에 접속해서 Cloud Vision API 사용을 활성화해야 한다. 



다음으로 API를 외부에서 호출하기 위한 API 키를 발급받아야 하는데, Google Cloud Platform API에서는 API 키에 대한 다양한 접근 방식을 제공한다. OAuth 방식의 접근, 서버를 위한 API 키 발급 방식등 여러 방식을 지원하는데, 이 예제에서는 서비스 계정키를 JSON 형태로 다운 받아서 사용하도록 한다.


계정키를 생성 하는 방법은 Google Cloud Platform 콘솔에서 “사용자 인증 정보” 메뉴에서 “서비스 계정 키 만들기” 메뉴를 통해서 키를 생성하고 JSON 파일을 다운로드 받을 수 있다.





Cloud Vision API 호출 하기

https://cloud.google.com/vision/docs/getting-started?utm_source=product-announcement&utm_medium=email&utm_campaign=2016-02-Vision-API&utm_content=NoFT 


를 보면 Cloud Vision API를 호출하는 방법이 자세하게 설명되어 있다. 제공하는 기능에 비해서 API 사용법은 무지 간단한데, JSON으로 REST 방식으로 API를 호출하면 분석 결과를 JSON으로 리턴해준다. 이때 이미지 파일은 이 JSON에 base64 인코딩으로 첨부를 하면 된다. 어렵지 않으니 문서를 한번 쭈욱 보면서 흐름을 따라가보기를 권장한다. 


node.js 모듈 준비하기

base64 인코딩 모듈을 넣어서 샘플 요청을 만드는 것 조차 귀찮아서 node.js의 npm모듈이 이미 있는지 찾아보기로 하였다. 역시나 있다. 테스트를 위해서 사용한 모듈은 google-vision-api-client 라는 모듈이다.https://www.npmjs.com/package/google-vision-api-client


%npm install google-vision-api-client


명령을 사용해서 모듈을 설치한다. 설치가 끝난후에, 모듈이 설치된 디렉토리 (내 경우에는 “/Users/terry/node_modules/google-visionapi-client” - Mac OS)에 들어가서 index.js 파일을 열어보자. 이 모듈은 Cloud Vision API가 예전 알파버전이었을때 개발된 후 업데이트가 되지 않아서 현재 베타 버전의 Cloud Vision API호출이 안된다. Cloud Vision API의 End point가 변경되었기 때문인데.

index.js 파일에서 baseurl의 값을 다음과 같이 바꿔주자. (Cloud vision API의 베타 버전 URL로 변경)


var baseurl = ‘https://vision.googleapis.com/v1/images:annotate';


이제 Cloud Vision API를 호출하기 위한 준비가 끝났다.


node.js로 Cloud Vision API 호출 하기

이제 google-vision-api-client를 이용하여 API를 호출해보자.다음은 google-vision-api-client에서 제공하는 예제이다.


var vision = require('google-vision-api-client');

var requtil = vision.requtil;

 

//Prepare your service account from trust preview certificated project

var jsonfile = '/Users/terry/dev/ws/nodejs/GoogleVisionAPISample/My Project-eee0a2d4532a.json';

 

//Initialize the api

vision.init(jsonfile);

 

//Build the request payloads

var d = requtil.createRequests().addRequest(

requtil.createRequest('/Users/terry/images/dale2.jpg')

.withFeature('FACE_DETECTION', 3)

.withFeature('LABEL_DETECTION', 2)

.build());

 

//Do query to the api server

vision.query(d, function(e, r, d){

if(e) console.log('ERROR:', e);

  console.log(JSON.stringify(d));

});



<예제. visionAPI.js >

코드를 작성하고, jsonfile 경로에 앞에서 다운받은 서비스 계정키 JSON 파일의 경로를 적어주면 된다.


그리고, createRequest 부분에, Google Cloud Vision API로 분석하고자 하는 이미지 파일명을 적고, withFeature라는 메서드를 이용해서 어떤 분석을 할것인지를 명시한다. (이 부분은 뒤에서 다시 설명한다.)


그러면 다음 명령을 통해서 실행을 해보자


%node visionAPI.js


실행을 하면 실행 결과를 json 형태로 리턴을 해주는데, 

테스트에서 사용한 이미지와 결과는 다음과 같다.



<그림. 테스트에서 사용한 이미지 >



{  

   "responses":[  

      {  

         "faceAnnotations":[  

            {  

               "boundingPoly":{  

                  "vertices":[  

                     {  

                        "x":122,

                        "y":52

                     },

                     {  

                        "x":674,

                        "y":52

                     },

                     {  

                        "x":674,

                        "y":693

                     },

                     {  

                        "x":122,

                        "y":693

                     }

                  ]

               },

               "fdBoundingPoly":{  

                  "vertices":[  

                     {  

                        "x":176,

                        "y":208

                     },

                             중략...

                     }

                  ]

               },

               "landmarks":[  

                  {  

                     "type":"LEFT_EYE",

                     "position":{  

                        "x":282.99844,

                        "y":351.67017,

                        "z":-0.0033840234

                     }

                  },

                  {  

                     "type":"RIGHT_EYE",

                     "position":{  

                        "x":443.8624,

                        "y":336.31445,

                        "z":-35.029751

                     }

                  },

               중략...

                  }

               ],

               "rollAngle":-3.8402841,

               "panAngle":-12.196975,

               "tiltAngle":-0.68598062,

               "detectionConfidence":0.8096019,

               "landmarkingConfidence":0.64295566,

               "joyLikelihood":"LIKELY",

               "sorrowLikelihood":"VERY_UNLIKELY",

               "angerLikelihood":"VERY_UNLIKELY",

               "surpriseLikelihood":"VERY_UNLIKELY",

               "underExposedLikelihood":"VERY_UNLIKELY",

               "blurredLikelihood":"VERY_UNLIKELY",

               "headwearLikelihood":"VERY_UNLIKELY"

            }

         ],

         "labelAnnotations":[  

            {  

               "mid":"/m/068jd",

               "description":"photograph",

               "score":0.92346138

            },

            {  

               "mid":"/m/09jwl",

               "description":"musician",

               "score":0.86925673

            }

         ]

      }

   ]

}

<그림. 결과 JSON>


결과를 살펴보면, 눈코입의 위치와, 감정상태등을 상세하게 리턴해주는 것을 볼 수 있다.

joyLikeihood 는 기쁨 감정, sorrowLikeihood는 슬픈 감정들을 나타내는데, 

Cloud Vision API는 여러개의 Feature를 동시에 분석이 가능하다.


예를 들어 얼굴 인식과 로고 인식을 같이 활용하여, 특정 브랜드를 보고 있을때 사람들의 얼굴 표정이 어떤지를 분석함으로써 대략적인 브랜드에 대한 반응을 인식한다던지. 특정 랜드마크와 표정 분석을 통해서 장소에 대한 분석 (재미있는 곳인지? 슬픈 곳인지.) 등으로 활용이 가능하다.


Cloud Vision API의 이미지 분석 기능


Cloud Vision API는 여러가지 형태의 이미지 분석 기능을 제공하는데, 대략적인 내용을 훝어보면 다음과 같다.


  • Label Detection - 사진속에 있는 사물을 찾아준다. 가구, 동물 , 음식등을 인지해서 리턴해준다.
  • Logo Detection - 사진속에서 회사 로고와 같은 로고를 찾아준다.
  • Landmark Detection - 사진속에서 유명한 랜드 마크 (남산 타워, 경복궁등과 같은 건축물이나 자연 경관 이름)를 찾아준다.
  • Face Detection - 사진속에서 사람 얼굴을 찾아준다. 이게 좀 재미있는데 눈코입의 위치등을 리턴하는 것을 물론 표정을 분석하여 감정 상태를 분석하여 리턴해준다. 화가 났는지 기쁜 상태인지 슬픈 상태인지
  • Safe Search Detection - 사진 컨텐츠의 위험도(? 또는 건전성)을 검출해주는데, 성인 컨텐츠, 의학 컨텐츠, 폭력 컨텐츠등의 정도를 검출해준다.
  • Optical Character Recognition - 문자 인식


그외에도 몇가지 추가적인 Feature를 제공하고 있으니 https://cloud.google.com/vision/ 문서를 참고하기 바란다.


Cloud Vision API는 무슨 의미를 제공하는가?


사실 Cloud Vision API 자체로만으로도 대단히 흥미로운 기능을 가지고 있지만, Cloud Vision API는 또 다른 의미를 가지고 있다고 본다.

머신러닝이나 빅데이타, 그리고 인공 지능은 데이타 과학자와 대규모 하드웨어 자원을 가지고 있는 업체의 전유물이었지만, 근래에는 이러한 빅데이타 관련 기술들이 클라우드를 기반으로 하여 API로 제공됨으로써, 누구나 쉽게 빅데이타 기반의 분석 기술을 쉽게 활용할 수 있는 시대가 되어가고 있다.

이미 구글이나 Microsoft의 경우 머신러닝 알고리즘을 클라우드 API로 제공하고 있고, 대규모 데이타 분석의 경우에도 Google Analytics나 Yahoo Flurry등을 통해서 거의 무료로 제공이 되고 있다. (코드 몇줄이면 앱에 추가도 가능하다.)

이러한 접근성을 통해서 많은 서비스와 앱들이 고급 데이타 분석 알고리즘과 인공지능 기능들을 사용할 수 있는 보편화의 시대에 들어 선것이 아닐까?