대용량 로그분석 bigquery로 간단히...

대용량로그분석,BigQuery로간단히사용하기

㈜엔비티 /�Devops / 이재광

2016년 09월

facebook.com/openstakcs

© NBT All Rights Reserved.

Contents

Part�1.

1. NBT�Lumberjack�Log�Analysis�Architecture

2. ISSUE

Part�2.

1. BigQuery실전구현시나리오

2. BigQuery구축시고민들

3. 변경된시나리오

Part�3.

1. BigQuery활용TIP


왜BigQuery사용을고민하게되었나


Kafka�+�ELK�+�Spark�+�Zeppelin

NBTLumberjack�logAnalysis�Architecture

client

L4

Kafka�proxy

Kafka & Zookeeper�Cluster

Logstash

Elasticsearch

Spark

Kibana

ZeppelinS3

Lumbercamp

Jenkins


Kafka�+�ELK�+�Spark�+�Zeppelin

Issues

client

L4

Kafka�proxy

Kafka�&�Zookeeper�Cluster

Logstash

Elasticsearch

Spark

Kibana

ZeppelinS3

Lumbercamp

성능저하 고민

Disk�증설 고민

Elasticsearch

성능 고민

Long�Query�2시간

이상 수행되면다른 작업 불가능

Jenkins


오랜시간개선에힘을쏟기보다는

관리포인트를Google�Platform으로전환시켜보자


Google�Cloud�Account�생성이제일어려웠을만큼쉽게구성가능했던BigQuery

우리가경험했던BigQuery


대략몇군데만손보면금방구현될듯

손이갈만한것들을추려보자면

1. 현재의 logstash 서버를 활용하고

2. BigQuery API만 잘 뚫어주면

3. 우리의 log�format에 맞게잘 정의된 스키마로 데이터를집어 넣고

4. 잘 사용하는 것 만이 할 일이다.


이런작업은하루면됩니다.

proto-type구현

1. 현재의 json log 일부를 test 전송

2. Google�App�Key를 발급하여API 권한 획득

3. 최소한의 schema를 넣고test 진행

4. 빠른 것 같긴한데..이제 실데이터를 가지고 조회해 볼까


기존logstash서버에저장된json log�file을BigQuery로전송후조회

실전구현시나리오작성

Logstash

Elasticsearch

Spark

Kibana

ZeppelinS3

BigQuery

고려사항

• 서버의자원부담최소화

(현재도부담되는중)

• 전송처리실패에대한보장

• 전송처리작업시간개선

• 전송작업이력관리

• 네트워크구간전송효율개선

DataStudio

etc

Jenkins


BigQuerySchema생성시ES의Nested�tpye에서문제발생

BigQuery구축시고민1

고려사항

• Nested와유사한 Repeated

Mode

• 'info' column을 Record�type의

Repeated�Mode로생성

• Repeated�Mode의 column 안에

또한번의 Repeated�Mode는지원

안됨. ES도마찬가지.

• 이경우는 String 처리에대한고민

• 일단제외

{�

"name":�"info",�"type":�"RECORD",�

"mode":�"REPEATED",�"fields":�[�

{�"mode":�"NULLABLE",�

"name":�"step_i",�"type":�"INTEGER"�

},�{�

"mode":�"NULLABLE",�"name":�"recommended",�

"type":�"STRING"�},�

{�"name":�“app_config”,

"type":�“RECORD","mode":�“REPEATED”,

“fields”�:�[{�

“mode”:�NULLABLE“name":�“adison_enables”

“type”:�“STRING”�},

{�“mode”:�NULLABLE

“name":�“abusing_devices”“type”:�“STRING”�

},


json file�size :7~35Gper�hour,7.5G�json file loading작업이약1시간정도소요

Embulk를이용한BigQueryData적재

Logstash

Elasticsearch

Spark

Kibana

ZeppelinS3

BigQuery

고려사항

• 서버의자원부담최소화

(현재도부담되는중)

• 전송처리실패에대한보장

• 전송처리작업시간개선

• 전송작업이력관리

• 네트워크구간전송효율개선

DataStudio

etc

Jenkins


embulk를도입했어도Jsonfile을BigQuery로적재하기에는너무느림


Logstash

Elasticsearch

Spark

Kibana

ZeppelinS3

BigQuery

고려사항

• 1시간이상걸리는 BigQuery Data

적재작업

• Parsing 처리비용이너무높다.

• 시간당 30G이상의파일을전송하

는경우발생하는네트워크전송량도

너무많다.

• 바이너리압축전송을하면

BigQuery Loading은?

DataStudio

etc

Jenkins


Jenkins를이용해서gzfile을GCS로전송후BigQueryLoading Job을추가실행

GCS�to�BigQuery

해결

• Transport�Tool을 embulk에서

gsutil로 교체

• gsutil을 이용한바이너리파일병렬

전송으로작업속도향상

• Gzip으로GCS 전송후 BigQuery로

Data 적재작업을수행하는경우

Job 형태로 async 수행및관리가능

Logstash

BigQuery

DataStudio

Cloud�Storage

gsutil

Jenkins


BigQuery의Computing�Resource비용은무료

BigQuery의Extract�&�Loading

무료

• 비용은 Storage와 Streaming�

Inserts,�Queries 요금만존재

• 속도도빠르고관리도용이한

BigQuery Loading이무료

(GCS�pricing)

BigQuery pricing


기존S3로전송하던gzfile을GCS로전송후BigQuery로적재

실전구현시나리오변경

Logstash

Elasticsearch

Spark

Kibana

ZeppelinS3

BigQuery

변경된시나리오

• json file�->�gzip file

• embulk ->�gsutil

• to�BigQuery -> to�GCS

• sync�->�async

DataStudio

Cloud�Storage

gsutil

Jenkins

gsutil

Json 7.5G약 1�hour

GZ�350M약 14�sec

BigQuery

Cloud�Storage

json

gzip


기존S3의gzfile을GCS로마이그레이션수행

데이터마이그레이션

고려사항

• BigQuery Console�Web 화면

에서한달치데이터를적재한

table을만들때 sub-directory의

file들은적재가안됨

• 이경우별도의 BigQuery 적재

스크립트필요

• 필요한기간에따라디렉토리구

조를적절히가져가는것이필요

S3

Cashslide/prd/lumberjack/2016/06/01/01/timestamp.gz

Cashslide/prd/lumberjack/2016/06/01/02/timestamp.gz

Cashslide/prd/lumberjack/2016/06/01/03/timestamp.gzCashslide/prd/lumberjack/2016/06/01/04/timestamp.gz

:

:

Cloud�Storage

Cashslide/prd/lumberjack/2016/06/timestamp.gzCashslide/prd/lumberjack/2016/06/timestamp.gzCashslide/prd/lumberjack/2016/06/timestamp.gzCashslide/prd/lumberjack/2016/06/timestamp.gz

::


BigQuery속도는빠른가

BigQuery조회해보기

고려사항

• 한달치 1.34TB data를스캔해서

result 까지걸린시간 6초

• 7명이동시에쿼리를수행해도

동일하게빠른성능을보여줌

• 그런데한번조회에 1.34TB면

얼마지?


How�much�BigQuery


비용요소

• GCS 비용 + BigQuery Storage 비용

+ Query�비용

• BigQuery는 10MB 단위로청구

(월 1TB 무료)

1.34TB는약 $6.7

고려사항

• 사용자가 range query를제대로수

행하지않으면많은비용이발생할수

도있다.

• 대안으로테이블을사용자용도에맞

게복제해주거나구글의 cost�control

을 통한Quota 제한고민


기간별table을쉽게생성하는방법?


Table�Decorator,�Partition�Decorator

BigQuery가제공하는Decorator

장점

• 날짜별 table이존재하듯이사용

• 손쉬운 range 검색

• 기간별, 일자별 table 생성이용이

고려사항

• Table 생성시 Partitioned�Table로

생성되어야함

SELECT�COUNT(*)�FROM�cashslide:dataset.table$20160830

2016년 8월 30일데이터조회

SELECT�COUNT(*)�FROM�[cashslide:dataset.table@-3600000]

1시간이전까지의과거데이터조회


나중에이걸확인한다면BigQuery적재작업의처음으로돌아가시오.

편리한Partitioned�tables

고려사항

• Dataset�table 생성시Date-

Partitioned�tables로생성가능

• 생성시 Expiration�time은

second 기준

• _PARTITIONTIME 이름의

pseudo�column�을포함하며,

data�적재시점을기준으로

TIMESTAMP(“2016-04-15”)

형식의값을저장함. UTC 기준

$bq mk --time_partitioning_type=DAY�\--time_partitioning_expiration=259200 \mydataset.table

Partitioned�tables 생성예제

$bq show�--format=prettyjson mydataset.table

생성된테이블정보확인

{�...�"tableReference":�{�"datasetId":�"mydataset",�"projectId":�"myproject",�"tableId":�"table2"�

},�"timePartitioning":�{�"expirationMs":�"2592000000",�"type":�"DAY"�},�"type":�"TABLE"�

}


Table�Decorator

유용한Decorator�2가지(1/2)

고려사항

• 최대 7일이전데이터까지조회

가능

• Milliseconds 단위

#�Snapshot�decorators@<time>

#�Range�decorators@<time1>-<time2>

Syntax

#�Snapshot�exampleSELECT�COUNT(*)�FROM�[cashslide:dataset.table@-3600000]

#�Range�exampleSELECT�COUNT(*)�

FROM�[cashslide:dataset.table@-3600000--1800000]

Example


Partition�Decorator

유용한Decorator�2가지(2/2)

고려사항

• $YYYYMMDD decorator를이

용한 snapshot 검색

• Pseudo�column을이용한

range�검색

[TABLE_NAME]$YYYYMMDD

Syntax

#�Snapshot�exampleSELECT�COUNT(*)�FROM�cashslide:dataset.table$20160505

#�Range�exampleSELECTfield

FROMtable

WHERE_PARTITIONTIME�BETWEEN�TIMESTAMP('2016-01-01')AND�TIMESTAMP('2016-01-21');

Example


그런데BigQuery는

어떤종류의분석이가능한가요?


이렇게구축한BigQuery를잘활용하는데

도움되는TIP몇가지


최고의TIP은요약

BigQueryTip�1

• ES의 Nested와유사한 Repeated type 형태가존재하는지여부검토

• BigQuery에서 Table 생성시 Partitioned�Table�고려

• GCS�to�BigQuery 구조로 Parsing은 Google의자원을무료로사용하자

• GCS까지는 ‘gsutil -m’을이용한 gz file 병렬전송

• GCS�to�BigQuery 구조로 Job�현황및이력관리가능

• 운영비용절감은Decorator를활용한용도별 table 생성또는 cost�control로

사용자별Quota 할당


BigQueryComposer여러모로편리합니다.

BigQueryTip�2

TIP

• Query�box 안의 Color를보면

현재 syntax, dataset�name,�

table�name,�column�name,�

function�name 의오류를쉽게

확인가능

• Results�Tab 옆의 Explanation

을보면Query 수행과정이알기

쉽게표기되어Query 성능개선

가능


File�export�는file당1G,일일최대10TB가능

BigQueryTip�3

TIP

• 쿼리결과의 export는파일당최

대 1G가능

• 그이상의결과를 export 하려는

경우쿼리결과에서 ‘Save�as�

Table’로 저장후 export 항목에

‘*.json’ 형태로기입


BigQuery비용절감을위한Use�Cache�사용

BigQueryTip�4

TIP

• 'Use�Cached�Results'를 사용하

여캐싱된이전쿼리결과를사용

하면중복되는쿼리들의비용을

절감가능

Query�Composer에서 'Show�Options'를눌러보면


Zeppelin�0.6.1부터‘%bigquery’인터프리터지원

BigQueryTip�5

TIP

• Zeppelin�0.6.1 버전부터

BigQuery Interpreter를제공

• Data뿐만아니라 BigQuery

Computing�resource를활용하

여작업수행가능 (AWS�EMR,�

Google�Dataproc의비용불필

요)

• 기존Notebook의이전작업이

필요


아쉬운부분:

이를활용할수있는Kibana,�Zeppelin과같은도구가

좀더다양하게지원되었으면하는바램


Q&A

THANK�YOU

주소 :�서울시 서초구 서초동 1341-7�조이빌딩

대용량 로그분석 bigquery로 간단히...

Data & Analytics