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


Archive»


 
 


Data Preprocessing in ML Pipeline


본글은 구글 클라우드 블로그에 포스팅한 글을, 재 포스팅 허가를 받은 후 포스팅한 글입니다.

다른 좋은 글들도 많으니 아래 출처 링크를 참고해 주새요

출처 링크


머신러닝 파이프라인에서, 데이터는 모델 학습 및 서빙의 입력에 알맞게 가공되어야 한다. 이를 전처리라고 하는데, 이번 글에서는 전처리에 대한 개념과 이에 대한 구현 옵션등에 대해서 알아보도록 한다.

처리 단계별 데이터 분류

머신러닝에서 데이터 전처리는 모델 학습에 사용되는 데이터 형태로 데이터를 가공하는 과정을 이야기한다.

데이터 전처리는 여러 단계로 이루어지는데, 단계별로 처리된 데이터에 대해서 다음과 같이 명명한다. 

Raw data

초기에 수집된 원본 데이터로 분석이나, 머신러닝 학습 용도로 전혀 전처리가 되지 않은 데이터를 의미한다.

하둡과 같은 데이터 레이크에 저장된 데이터나, 기본적인 처리를 통해서 테이블 구조로 데이터 레이크에 저장된 데이터가 Raw 데이터에 해당한다.

Prepared data

Prepared data는 Data engineering 전처리에 의해서, 학습을 위한 데이터만 추출한 서브셋 데이터를 의미한다. 예를 들어 서울 20대 사용자의 구매 패턴을 머신러닝 모델로 만들고자 할때, 서울 20대 사용자 데이터만 추출한 경우 이 데이터를 Prepared data라고 한다. 단순하게 서브셋만을 추출하는 것이 아니라, 깨끗한 상태의 데이터로 정재된 데이터인데, 정재의 의미는 비어 있는 행이나 열을 삭제한 데이터를 의미한다. 

Engineered feature

이렇게 정제된 데이터는 머신러닝 학습과 서빙에 적절한 형태로 재가공 되어야 하는데 이를 Feature Engineering 이라고 한다. 예를 들어 숫자와 같은 값을 0~1 사이로 맵핑 시키거나 , 카테고리 밸류 예를 들어 남자/여자를 0,1과 같은 값으로 맵핑 시키고, 전체 데이터를 학습,평가용으로 7:3 분할하여 저장하는 것이 이에 해당 한다. 



<그림. 데이터 전처리 단계 및 단계별 생성된 데이터 >

데이터 전처리 기법

그러면, 이 데이터 전처리 과정에서 구체적으로 어떤 기법으로 데이터를 처리할까? 몇가지 대표적인 기법을 정리해보면 다음과 같다. 

  • Data cleansing : 데이터에서 값이 잘못되거나 타입이 맞지 않는 행이나 열을 제거하는 작업을 한다. 

  • Instance selection & partitioning : 데이터를 학습,평가,테스트용 데이터로 나누는 작업을 한다. 단순히 나누는 작업 뿐만 아니라, 데이터를 샘플링 할때, 그 분포를 맞추는 작업을 병행한다. 예를 들어 서울/대구/부산의 선거 투표 데이타가 있을때, 인구 비율이 9:2:3이라고 할때, 전체 인구를 랜덤하게 샘플링해서 데이타를 추출하는 것이 아니라, 서울/대구/부산의 인구 비율에 따라서 서울에서 9, 대구에서 2, 부산에서 3의 비율로 샘플링을 할 수 있다. 이를 stratified partitioning 이라고 한다. 또는 데이터 분포상에서 특정 카테고리의 데이터 비율이 적을때, 이 카테고리에 대해서 샘플의 비율을 높이는 minority classed oversampling 등의 기법을 이 과정에서 사용한다. 

  • Feature tuning : 머신러닝 피처의 품질을 높이기 위해서 0~1값으로 값을 normalization 시키거나, missing value를 제거 하거나, 아웃라이어등을 제거하는 등의 과정을 수행한다.

  • Representation transformation : 피처를 숫자로 맵핑 시키는 작업을 한다. 카레고리컬 피처를 one hot encoding 등을 통해서 숫자로 맵핑하거나, 텍스트를 embedding 을 통해서 숫자로 변환하는 작업등을 수행한다. 

  • Feature extraction : PCA와 같은 차원 감소 기법을 이용하여, 전체 피처의 수를 줄이는 작업을 수행하거나, 피처를 해시값으로 변환하여, 더 효율적인 피쳐를 사용하는 작업을 한다. . 

  • Feature selection : 여러개의 피처(컬럼)중에 머신러닝에 사용할 피처만을 선별한다. 

  • Feature construction : 기존의 피처를 기반으로 polynomial expansion 이나,  feature crossing 등의 기법을 이용하여 새로운 피처를 만들어낸다. 

데이터 전처리 단위

Instance level transformation & Full pass transformation

데이터 전처리를 할때 어떤 단위로 데이터를 전처리 할지에 대한 정의이다. 예를 들어 숫자 데이터의 값을 0~1 사이로 맵핑하고자 하면, 그 데이터의 최소/최대 값을 알아야 0~1사이로 맵핑할 수가 있는데, 최소/최대값을 추출하려면, 전체 데이터에 대한 스캔이 필요하다. 반대로 NULL 값을 0으로 변환하는 작업은 전체 데이터에 대한 스캔이 필요없고 개별 데이터만 변환하면 된다. 앞에 설명한 전체 데이터에 대한 스캔이 필요한 방식을 full pass transformation 이라고 하고, 전체 데이터를 볼 필요 없이 개별 데이터에 대해 변환하는 작업을 instance level transformation이라고 한다. 


Window aggregation

전체 데이터의 볼륨이 클 경우 이를 윈도우 단위로 잘라서 처리할 수 있는 방법이 있는데, 예를 들어 10분 단위로 데이터를 처리해서, 10분 단위로 최소/최대 값을 구하거나 또는 10분 단위로 어떤 값의 평균값을 대표값으로 사용하는 것들이 이에 해당한다. 

일반적으로 입력값은 (entity, timestamp, value) 형태가 되며, 전처리된 출력 값은 다음과 같이. (entity, time_index, aggregated_value_over_time_window) 엔터티(피쳐)에 대해서 윈도우별로 처리된 값을 저장하는 형태가 된다.  보통 이런 window aggregation 방식은 리얼 타임 스트리밍 데이터에서 시간 윈도우 단위로 데이터를 처리하는 경우에 많이 사용이 되며, Apache Beam과 같은 스트리밍 프레임워크를 이용하여 구현한다. 

구글 클라우드에서 데이터 전처리 방식

이러한 데이터 전처리는 다양한 컴포넌트를 이용해서 처리할 수 있는데, 어떤 방식이 있는지 살펴보기 전에 먼저 구글 클라우드 기반의 머신러닝 학습 파이프라인 아키텍처를 살펴보자.  아래는 일반적인 구글 클라우드 기반의 머신러닝 파이프라인 아키텍처이다. 


<그림. 구글 클라우드 플랫폼 기반의 일반적인 머신러닝 학습 파이프라인 아키텍처 >


  1. 원본 데이터는 빅쿼리에 저장된다. (테이블 형태의 데이터가 아닌 이미지나 텍스트등은 클라우드 스토리지(GCS)에 저장된다.)

  2. 저장된 원본 데이터는 Dataflow를 이용해서 머신러닝 학습에 알맞은 형태로 전처리 된다. 학습/평가/테스트 셋으로 나누는 것을 포함해서, 가능하면 텐서플로우 파일형태인 *.tfrecord 형태로 인코딩 된후에, GCS 에 저장된다. 

  3. 텐서플로우등으로 모델을 개발한 후에, trainer-package로 패키징을 하고, AI Platform 트레이닝에 이 모델을 업로드 한다. 업로드된 모델을 앞서 전처리된 데이터를 이용해서 학습이되고, 학습이 된 모델은 GCS에 저장된다. (텐서플로우에서 SavedModel로 저장한다.)

  4. GCS 에 저장된 모델은 AI Plaform 서빙 엔진에 배포되고 REST API를 이용하여 서빙된다.

  5. 클라이언트에서는 이 REST API를 이용하여 학습된 모델에 대한 서빙을 이용한다.

  6. 전체 워크플로우에 대한 파이프라인 관리는 Apache Airflow 매니지드 서비스인 Composer 를 이용한다. 또는 머신러닝에 특화된 파이프라인이기 때문에, AI Platform pipeline을 사용하는 것이 좋다.

Option A: 빅쿼리에서 데이터 전처리

일반적으로 빅쿼리를 이용한 전처리는 다음과 같은 시나리오에 유용하다.

  • Sampling : 데이터에서 랜덤하게 일부 데이터셋만 가지고 오는 용도

  • Filtering : 학습에 필요한 데이터만 WHERE 문을 이용해서 가지고 오는 용도

  • Partitioning : 데이터를 학습/평가/테스트 용도로 나누는 용도

주로 빅쿼리는 Dataflow로 데이터를 인입하기 전체 최초 전처리 용도로 사용이 되는데, 주의할점은 빅쿼리에 전처리 로직이 많을 경우 향후 서빙에서 재 구현이 필요할 수 있다. 무슨 이야기인가 하면, 서빙시에도 입력 데이터에 대한 동일한 전처리가 필요한데, 빅쿼리에서 SQL로 작성한 전처리 로직은 서빙시에는 사용할 수 없기 때문에, 자바나 파이썬으로 전처리 로직을 다시 구현해야 하는 이중작업이 될 수 있다. 물론 서빙이 빅쿼리에 있는 데이터를 사용하는 배치 서빙일 경우 문제가 없지만, 리얼타임으로 단건의 데이터에 대해서 서빙을 하는 경우에는 빅쿼리에서 서빙용 데이터를 전처리할 수 없다. 


그럼에도 불구하고 배치 서빙용인 경우 전처리를 빅쿼리를 이용할 경우 편리하고 특히 Dataflow 에 데이터를 입력하기전에 Full pass transformation 이 필요한 전체 통계 데이터 (예를 들어 평균,분산,최소/최대값)은 SQL을 통해서 쉽게 뽑아낼 수 있는 장점이 있다. 

Option B: Dataflow 에서 데이터 전처리

복잡한 데이터 변환 로직이 있는 경우등에 효율적으로 사용할 수 있는 방식인데, Instance level transformation 뿐만 아니라, full pass transformation, 그리고 window aggregation 타입 모두를 지원할 수 있다.

Dataflow는 Apache Beam 오픈소스 기반의 런타임이지만, 다양한 구현 방식을 지원하고 있다.

  • Apache Beam을 사용하는 방법 : 가장 일반적인 방식으로 Apache Beam Java/Python SDK 을 이용하여 데이터 변환 로직을 구현할 수 있다.  

  • Tensorflow Transformation 을 사용하는 방법 : 텐서플로우의 경우 Tensorflow Transformation (이하 TFT) 이라는 이름으로 데이터 변환 프레임워크를 제공한다. TFT는 Apache Beam 기반으로 동작하는데, 텐서플로우 코드를 기반으로 하기 때문에, 머신러닝 개발자 입장에서는 접근이 상대적으로 쉬운 장점이 있다. 

  • Dataflow SQL을 사용하는 방법 : 앞의 두 방식의 경우에는 Java나 Python 기반의 코딩이 필요한데, 이런 코딩 없이 Window aggregation이나, 기타 복잡한 로직을 구현하고자 할때 사용할 수 있는 방식이 Dataflow SQL이다.SQL을 사용하여 구현하지만, Dataflow의 함수등을 사용할 수 있는 장점이 있다. 

  • Dataflow Template + UDF를 사용 하는 방법 : 복잡한 변환이 아니라 단순한 맵핑이나 문자열 변환들을 어렵지 않게 구현하는 방식으로 Dataflow는 Pre-built in 된 Template을 제공한다. 이 템플릿 중에는 비즈니스 로직을 자바스크립트로 넣을 수 있는 UDF 라는 방식을 지원하는데, Apache Beam 형태로 구현할 필요 없이 단순한 변환 로직을 자바스크립트로 구현하여 GCS에 파일을 저장하고, 설정 정보에서 자바 스크립트 파일만 지정하면되기 때문에, 쉽게 사용할 수 있다. 


서빙시에도 다양한 아키텍처 구현이 가능한데, Pub/Sub 큐를 통해서 데이터를 실시간으로 인입한 데이터를 머신러닝 모델로 서빙한후에, Pub/Sub으로 내보내는 near realtime 서빙이 가능하고 또는 bigtable에 서빙 결과를 저장하여 마치 serving 결과에 대한 캐쉬식으로 사용하는 구조도 가능하다.




<그림. 스트림 데이터를 이용하여 서빙을 제공하는 아키텍처>

Option C: Tensorflow 모델 내에서 데이터 전처리

아니면 데이터 전처리를 Tensorflow 모델 코드내에서 하는 방식이 있다.

  • feature_column 를 이용하여 피처를 임베딩하거나, 버킷화 하는 방식이 있고

  • 아니면 데이터를 피딩하는  input functions(train_input_fn, eval_input_fn, and serving_input_fn) 안에 데이터 전처리 로직을 구현하는 방법이 있다. 

  • Custom estimator를 사용하는 경우에는 model_fn 자체에 데이터 전처리 로직을 넣을 수 있다. 

이렇게 텐서 플로우 코드단에 전처리 기능을 넣는 경우는 Instance level transformation은 가능하지만 다른 방식에 대해서는 불가능하다. 그렇지만 이미지 데이터를 학습전에 rotation하거나 flip 하는 argumentation 등은 텐서플로우 코드에서 하게 되면 동적으로 데이터를 학습 단계에 argumentation할 수 있기 때문에 효율이 좋은 장점이 있다. 

Option D: DataPrep을 이용한 데이터  전처리

구글 클라우드 플랫폼에서는 데이터의 특성을 분석하고 간단한 변환을 지원하기 위한 wrangling 도구로 DataPrep을 제공한다. Engineered feature 단계까지 데이터를 가공하는 것은 어려울 수 있겠지만, Raw data를 Prepared data 형태로 cleansing 하는 용도로는 충분히 사용할 수 있으며, 특히 시각화를 통한 데이터 분포나 아웃라이어 분석이나 단순 변환등에는 효과적으로 사용할 수 있다.


<그림 DataPrep 을 이용한 Wrangling 과정 예시> 

Option E: DataProc을 이용한 데이터 전처리

DataProc은 Hadoop/Spark 에 대한 구글 매니지드 서비스이다. Apache Beam을 사용하는 Dataflow와 같이 코딩을 기반으로 한다는 점은 같지만, 기존에 Hadoop/Spark 에코 시스템에 익숙한 사용자들의 경우에는 기존의 에코 시스템과 개발 코드를 재활용할 수 있다는 장점을 가지고 있다. 

데이터 전처리시 고려할점

그러면 이러한 기술을 이용해서 데이터를 전처리할때, 고려해야하는 점은 무엇이 있을까?

학습/서빙 데이터에 대한 스큐(skew)

모델을 학습하여, 서비스에 배포한후에, 향후 들어오는 데이터로 서빙을 하게 되는데, 이때 학습에서 사용한 데이터와 서빙시 사용한 데이터의 특성이 다를때 이를 training-serving skew 라고 한다. 

예를 들어 피처 A가 학습시에 범위가 1~255 였는데, 서빙시에 1~500 사이로 들어오게 되면 이 모델의 서빙 결과는 정확하지 못하게 된다.

(참고 : 이런 문제를 해결하기 위해서 데이터의 분포나, 수학적 통계값을 저장해 놓은 후에, 서빙전에 검증하는 방식을 사용할 수 있으며 이는 Tensorflow data validation으로 구현이 가능하다. )

Full pass transformation

Option C의 텐서플로우 모델내의 데이터 변환 로직은 Full pass transformation을 지원하지 않기 때문에, feature scaling이나, normalization 적용이 불가능하다. 이러한 전처리 기법은 최소/최대값등의 통계 데이터가 필요한데, 이러한 데이터는 모델 학습전에 계산되어야 하고, 계산된 데이터는 어디에든 저장되어 있어야 하며, 학습과/서빙 단계에 모두 일관되게 사용될 수 있어야 한다. 

성능 향상을 위한 Up front data loading 

Option C 텐서플로우 모델내에 데이터 변환 로직을 구현할때, 고려해야 하는 사항이다.

모델 코드 상에 데이터 전처리 로직이 있을 경우, 아래 그림과 같이 데이터 변환 작업이 끝나면, 그 데이터로 모델을 학습 시키는 구조가 된다. 


<그림. 데이터 전처리가 모델 학습전에 발생하여, 대기하는 현상>


이 경우에 데이터가 전처리되고 있는 동안에는 학습이 이루어지지 않기 때문에 자원이 낭비되는 문제가 발생하고, 모델의 학습 시간에 전처리 시간까지 포함되기 때문에 전체 학습시간이 상대적으로 오래걸린다. 


Option B의 데이터 플로우를 사용하는 것처럼 미리 여러 학습에 사용될 데이터를 전처리를 해놓거나 아니면 아래 그림과 같이 병렬적으로 데이터 플로우에서 데이터를 전처리하면서 모델은 학습에만 전념하도록 하면, 모델의 전체학습 시간을 줄일 수 있다. 


<그림. 병렬로 데이타 전처리를 해서 모델 학습을 최적화 하는 방식>

이를 up front data loading 이라고 하는데, 텐서플로우에서는 Prefetching, Interleave, Parallel mapping 등을 tf.data.DataSet에서 다양한 방식으로 이를 지원하고 있다. 


Tensorflow Transform

텐서플로우 프레임웍은 이러한 데이터 변환을 위해서 Tensorflow Transform (이하 TFT) 라는 프레임웍을 데이터 전처리 기능을 제공한다. 이 TFT를 구글 클라우드에서 실행하게 되면, Dataflow를 기반으로 실행할 수 있다. (Option B) 

tf.Transform 이라는 패키지로 제공된다. TFT는 instant level transformation 뿐만 아니라, full pass transformation, window aggregation 을 지원하는데, 특히 full pass transformation을 지원하기 위해서 데이터를 변환하기 전에 Analyze 라는 단계를 거치게 된다. 

아래 그림이 TFT가 작동하는 전반적인 구조를 기술한것인데,



Analyze 단계에서는 데이터의 통계적인 특성 (최소,최대,평균 값등)을 추출하고, Transform 단계에서는 이 값을 이용하여, 데이터 변환을 수행한다. 각 단계는 tft_beam.AnalyzeDataset , tft_beam.TransformDataset 로 실행될 수 있으며, 이 두 단계를 tft_beam.AnalyzeAndTransformDataset 로 합쳐서 한번에 실행하는 것도 가능하다. 


  • Analyze 단계 : Analyze 단계에서는 통계적인 값을 Full pass operation 을 통해서 계산해내는 것이외에도, transform_fn을 생성해내는 작업을 한다. transform_fn은 텐서플로우 그래프로, 데이터 변환에 대한 instance level operation 을 계산해낸 통계값을 사용해서 수행한다. 

  • Transform 단계 : 데이터 변환 단계에서는 transform fn을 인입 데이터에 적용하여, instance level로 데이터를 변환하는 작업을 수행한다. 


모델 학습시 데이터에 대한 전처리는 학습 데이터뿐만 아니라, 평가 (Eval) 데이터에도 동일하게 적용이 되어야 하는데, Analyze는 학습데이터에만 적용되서 데이터의 특성을 추출하고, 평가 데이터에는 별도로 Analyze를 수행하지 않고, 학습 데이터에서 추출된 데이터 특성을 그대로 사용한다

TFT pipeline export  

transform_fn으로 구성된 데이터 변환 파이프라인은 내부적으로 텐서 플로우 그래프로 변환이 되는데, 학습된 텐서플로우 모델을 export 하여 SavedModel로 저장할때, 이 transform_fn 그래프가  서빙용 데이터 입력함수인 serving_input_fn에 붙어서 같이 export 된다. 이 말은, 학습에서 사용한 데이터 전처리 로직인 transform_fn이 그대로 서빙단에도 같이 적용된다는 이야기이다. 물론 full-pass transformation에서 계산한 통계값도 상수형태로 저장하게 된다. 그래서 입력값에 대해서 학습과 서빙시 같은 변환 로직을 사용할 수 있게 된다.

데이터 전처리 옵션 정리

앞서 설명한 데이터 변환 전처리 옵션을 Instance level transformation, full pass level transformation, window aggregation 에 따라 정리해보면 다음과 같다. 


Disclaimer

본 글의 작성자는 Google 직원입니다. 그러나 본 글의 내용은 개인의 입장에서 작성된 글이며, Google의 입장을 대변하지 않으며, Google이 본 컨텐츠를 보장하지 않습니다.


References






Instance-level transformation

(stateless transformation)

Full pass during training

instance -level during serving

(stateful transformation)

Real-time (window) aggregations

during training and serving 

(streaming transformation)

배치 서빙

온라인 서빙

배치 서빙

온라인 서빙

배치 서빙

온라인 서빙

BigQuery (SQL)

OK

같은 데이터 변환 로직을 학습과 서빙 단계에 적용 가능

가능은 하지만 권장하지 않음


서빙시에는 BigQuery가 아니라 다른 방식으로 데이터 변환 로직을 구현해야 하기 때문에 결과적으로 학습/서빙 Skew를 유발할 수 있음

가능


BigQuery에서 수학적 통계값(최소/최대)를 계산하여, 이 값을 이용하면 가능하다.

그러나 계산된 값을 별도로 저장해서 학습/서빙시에 사용해야 하기 때문에 구현이 번거롭다.

N/A

가능은 하지만 권장하지 않음


BigQuery의 윈도우 함수등을 이용하여 구현은 가능하지만, 서빙시에는 BigQuery가 아닌 다른 툴로 구현을 해야 하기 때문에 학습/서빙 Skew가 발생할 수 있음

Dataflow (Apache Beam)

OK

서빙시 데이터가 Pub/sub을 통해서 데이터 블로우로 들어오면 가능하지만, 그렇지 않은 경우 학습/서빙 데이터간 Skew가 발생할 수 있음

가능


Dataflow에서 수학적 통계값(최소/최대)를 계산하여, 이 값을 이용하면 가능하다.

그러나 계산된 값을 별도로 저장해서 학습/서빙시에 사용해야 하기 때문에 구현이 번거롭다.

OK


동일한 Apache Beam 기반의 데이터 변환 로직이 학습을 서빙시 적용이 가능함

Dataflow (Apache Beam + TFT)

권장함


학습과 서빙의 Skew를 방지할 수 있고, 학습/서빙전 데이터를 미리 준비할 수 있음

권장함


데이터 변환 로직과, 모델 학습시에 계산된 통계 결과 텐서플로우 그래프 형태로 저장되서, 서빙 모델을 export할시에 같이 저장됨

Tensorflow
(input_fn & serving_input_fn)

가능은 하지만 권장하지 않음


학습과 서빙 효율성을 생각하면, 학습전에 데이터를 변환하는게 좋음

가능은 하지만 권장하지 않음


학습과 서빙 효율성을 생각하면, 학습전에 데이터를 변환하는게 좋음

불가능

불가능


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. pexavec 2021.04.24 17:14  댓글주소  수정/삭제  댓글쓰기

    관리자의 승인을 기다리고 있는 댓글입니다


빅쿼리 대쉬 보드를 위한 오픈소스 메타 베이스


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


빅쿼리 분석 결과를 시각화 하는 도구로 구글에서 제공되는 툴은 일반 비지니스 사용자나, 초보자를 위한 데이타 스튜디오, 그리고 데이타 사이언티스트를 위한 DataLab 등이 있다.


그러다 보니, 데이타 사이언티스트는 아니면서 고급 사용자를 위한 데이타 분석툴 영역에 다른 툴이 필요하게 되는데, 상용 도구로는 타블루와 같은 설치형 도구나 Looker 등의 클라우드 서비스를 사용할 수 있는데, 유료이기 때문에, 대안적인 툴을 찾는 경우가 많다.


오픈 소스 도구로는 Redash가 있는데, 이 외에, Metabase(메타 베이스) 라는 도구가 있어서 소개한다.


쿼리 및 분석 기능

분석을 위해서 기본적인 화면상에서 쿼리가 가능하고, 쿼리 결과는 아래 그림과 같이 테이블이나 그래프 형태로 출력이 가능하기 때문에, AdHoc  분석이 손쉽게 가능하다. 




대쉬 보드 기능

이렇게 쿼리하고 분석한 내용을 바로 아래 그림과 같이 대쉬 보드에 추가할 수 있다. 



사용자 관리 기능

메타 베이스의 장점 중 하나가, 어느정도 규모가 되는 조직에서 사용이 가능하도록, 사용자 계정 관리 기능을 가지고 있다.  사용자 그룹을 통한 권한 관리 등이 가능하다.


관리자 기능

사용자 권한 관리를 하기 때문에 당연히 관리자 기능이 있는데, 재미있는 것은 필터나 매트릭등을 관리자가 정해놓고, 사용자가 이 매트릭을 불러다가 분석이나 리포팅에 사용할 수 있다.





<그림. 관리자 패널에서 필터를 정의하는 화면 >



빅쿼리와 메타 베이스를 연결하는 방법은 다음과 같다.

https://www.metabase.com/docs/latest/administration-guide/databases/bigquery.html


설치는 metabase.com 문서를 참고해야 하는데 mysql이나 postgres와 같은 외부 데이타 베이스를 설정해야 한다. 

https://www.metabase.com/docs/latest/operations-guide/running-the-metabase-jar-file.html



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 2018.02.06 11:22  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  2. query 2018.05.08 17:38  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 질문 좀 드리겠습니다...
    올려주신 게시물 보고 대쉬보드까지 만들었는데요....
    기본 주소가 http://localhost:3000/ 이렇게 되어있는데요
    팀원들을 초대해서 같이 이용하려면 어떻게 해야 하나요?

  3. 꿈나무 2019.07.26 23:15  댓글주소  수정/삭제  댓글쓰기

    형님 복받으십쇼


피닉스 패턴의 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가 된다.



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. heepoman 2017.09.06 14:12  댓글주소  수정/삭제  댓글쓰기

    내용이 너무 잘 정리되어있어서 쉽게 이해할수 있었습니다 감사합니다.^^


구글 데이타 스트리밍 데이타 분석 플랫폼 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을 선택한 후, 상단 메뉴에서 [정지] 또는 [삭제] 메뉴를 선택하면 된다.




참고 자료



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 이건 2016.08.26 21:55  댓글주소  수정/삭제  댓글쓰기

    지금 이거는 서버호스팅인가요?

  2. PeterCha 2016.10.24 12:17  댓글주소  수정/삭제  댓글쓰기

    감사합니다 :)
    google cloud platform 시작이 덕분에 순조롭네요

  3. ee32320 2017.06.04 16:21 신고  댓글주소  수정/삭제  댓글쓰기

    클라우드 사용하려고 하고 있습니다. 관련 포스팅, 잘 보고 가네요~. 감사합니다.

  4. 2017.06.10 17:10  댓글주소  수정/삭제  댓글쓰기

    관리자의 승인을 기다리고 있는 댓글입니다

  5. yeom9876 2017.08.10 20:09  댓글주소  수정/삭제  댓글쓰기

    이거.. sudo apt-get install 을 통해 설치를하려하는데 root 설정이 안되거든요 sudo passwd 같이 그런거하면 root 권한 설정해야하고 막그래서 혹시 해결방법아시나요 ㅠㅠ

  6. ah 2018.06.09 22:14  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 과제를 하다 이 글을 읽게 되었는데 정말 많은 도움이 되었습니다...하지만 한 가지가 문제인데요, 마지막 단계인 외부 아이피로 접속하는 게 되지 않습니다..도저히 어떻게 해야할 지 모르겠습니다ㅠㅠ

  7. woo59 2020.04.19 14:09  댓글주소  수정/삭제  댓글쓰기

    감사합니다. 도커 연습을 하려고 구글 클라우드 플랫폼을 찾았는데.. 덕분에 잘 시작했습니다 ^^

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

조대협 (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 키 파일] 계정@호스트명



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. ee32320 2017.06.12 05:37 신고  댓글주소  수정/삭제  댓글쓰기

    구글 클라우드 공부하고 있습니다. ssh설정 하는 방법.. 검색해서, 들어왔네요. 관련 포스팅, 잘 보고 갑니다.

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등을 통해서 거의 무료로 제공이 되고 있다. (코드 몇줄이면 앱에 추가도 가능하다.)

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







본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 고래사과 2016.03.04 23:18  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 봤습니다.
    고맙습니다.

    그런데 아래 광고라는건 어떤걸 말하는건가요?

  2. 정존 2016.04.07 10:54 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 자료 감사합니다.^^

  3. 이민우 2017.04.11 18:47  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. Google Cloud Vision API를 통해서 특정 사용자 그룹을 만들어서 해당 그룹 내에서 사람을 찾는 기능도 제공을 하는지 궁금합니다. 감사합니다.

  4. 2017.10.17 20:17  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다