우리가 이름만 들어도 아는 유명 IT 서비스들의 화려한 웹페이지도, 예쁜 모바일 앱도 그 뒤에는 탄탄하고 강력한 분산 시스템을 기반으로 합니다. 이러한 백엔드 시스템이 부실할 경우 서비스나 앱은 그야말로 사상누각입니다. 본 세미나에서는 이러한 시스템들을 만들때 풀어야 할, 가장 기본이 되는 문제와 이슈들 12가지에 도전해봅니다.
Apache kafka performance(throughput) - without data loss and guaranteeing dat...SANG WON PARK
Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
2015. 09. 05 도커 서울 밋업 4번째(Open Container Korea 주최).
elasticsearch에 은전한닢 한국어 형태소 분석기를 적용하고 운영한 사례 발표.
- 사용자 사전별로 이미지를 만들기
- nginx를 이용해 http basic auth 적용하기
- Docker is an open-source engine that automates deployment of applications inside lightweight containers that can run on any machine with Docker installed.
- The document discusses how Docker simplifies development environments by allowing applications and dependencies to be packaged into containers that can run anywhere without dependency or compatibility issues.
- It provides instructions for installing Docker and using common Docker commands to build, run, commit, and manage containers running applications like Apache and PHP.
우리가 이름만 들어도 아는 유명 IT 서비스들의 화려한 웹페이지도, 예쁜 모바일 앱도 그 뒤에는 탄탄하고 강력한 분산 시스템을 기반으로 합니다. 이러한 백엔드 시스템이 부실할 경우 서비스나 앱은 그야말로 사상누각입니다. 본 세미나에서는 이러한 시스템들을 만들때 풀어야 할, 가장 기본이 되는 문제와 이슈들 12가지에 도전해봅니다.
Apache kafka performance(throughput) - without data loss and guaranteeing dat...SANG WON PARK
Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
2015. 09. 05 도커 서울 밋업 4번째(Open Container Korea 주최).
elasticsearch에 은전한닢 한국어 형태소 분석기를 적용하고 운영한 사례 발표.
- 사용자 사전별로 이미지를 만들기
- nginx를 이용해 http basic auth 적용하기
- Docker is an open-source engine that automates deployment of applications inside lightweight containers that can run on any machine with Docker installed.
- The document discusses how Docker simplifies development environments by allowing applications and dependencies to be packaged into containers that can run anywhere without dependency or compatibility issues.
- It provides instructions for installing Docker and using common Docker commands to build, run, commit, and manage containers running applications like Apache and PHP.
The document is a table of contents that outlines topics related to advanced querying and expressions in MongoDB. It includes sections on installation and operation, installing and checking data in RoboMongo, comparison operations like greater than/less than, string comparisons, searching with regular expressions, array searches, and searching within subdocuments. The document provides structure and overview but no detailed explanations of the topics.
The document discusses creating object types and objects in JavaScript. It introduces the concept of a DartFrog type and shows how to define it as a function that accepts name, color, and poisonous properties. It demonstrates adding jump and sing methods to the DartFrog type and then creating individual DartFrog objects, passing values to initialize their properties. Finally, it calls the sing method on each DartFrog object to make them croak.
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
[ http://infiniflux.com/download ]
The world's fastest time series DBMS.
What is InfiniFlux?
1) InfiniFlux is a time-series database which performs real-time data processing, i.e., data are inserted at high speed, retrieved and analyzed without elapsed time.
2) InfiniFlux also compresses and stores data in real-time. Its query language and syntax complies with the SQL standard. The extended SQL syntax provides additional features such as the text search tool.
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...Amazon Web Services Korea
고객사 A는 하루 30억 트랜잭션과 연 750TB의 데이터베이스를 온프레미스 환경에서 상용 데이터베이스를 이용하여 운영 중입니다. 또한 매일 대용량의 배치가 발생하고 실시간으로 대량의 조회가 발생하는 미션 크리티컬 시스템입니다. 고객사 A와 함께 클라우드 환경에서 동일한 워크로드의 수행이 가능한지 여부를 검증하는 Feasiblity Pilot 프로젝트를 진행하였고 여기서의 레슨런을 공유합니다. 마이그레이션 도중 고객 IT팀은 On-premise 운영 모델에서 클라우드 운영 모델로 전환되어야 합니다. 전환 도중에 ITIL을 클라우드, 애자일, DevOps 기반 역량과 프로세스에 매핑해야 합니다. 해당 세션에서는 클라우드 운영 모델로 원활한 전환을 도와주는 CEE (Cloud Enablement Engine)의 작동 원리 및 적용 방식을 살펴보고자 합니다.
효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: ...Amazon Web Services Korea
대량의 트랜잭션을 빠르고 유연하게 처리하기 위해서는, 데이터 처리 및 저장 방식에 대한 변화를 고려해야 합니다. 본 세션에서는 어플리케이션이 요구하는 다양한 사용 패턴 및 성능 요구사항을 살펴보고, NoSQL(Elasticache Redis, DynamoDB)을 기반으로 이를 효율적으로 처리하기 위한 디자인 및 쿼리 패턴을 포함한 기술적 고려사항을 알아봅니다.
5. Goal of BigQuery in Google I/O 2012
• Perform a 1TB table scan in 1 second
Parallelize Parallelize Parallelize!
• Reading 1 TB / second from disk - 10k+ disks
• Processing 1TB / sec - 5k processors
6. Goal of BigQuery in Google I/O 2012
• Perform a 1TB table scan in 1 second
Parallelize Parallelize Parallelize!
• Reading 1 TB / second from disk - 10k+ disks
• Processing 1TB / sec - 5k processors
7. Goal of BigQuery in Google I/O 2012
• Perform a 1TB table scan in 1 second
Parallelize Parallelize Parallelize!
• Reading 1 TB / second from disk - 10k+ disks
• Processing 1TB / sec - 5k processors
8. Goal of BigQuery in Google I/O 2012
• Perform a 1TB table scan in 1 second
Parallelize Parallelize Parallelize!
• Reading 1 TB / second from disk - 10k+ disks
• Processing 1TB / sec - 5k processors
9. BigQuery from Dremel
• BigQuery as a publicly available service for any business
or developer to use
• REST API
• CLI ( command line interface )
• Web UI
• ACL ( access control )
• Data schema management and the integration with Google
Cloud Storage.
10. Dremel
• Analysis of crawled web documents
• Tracking install data for applications in the Android Market
• Crash reporting for Google products
• OCR results from Google Books
• Spam analysis
• Debugging of map tiles on Google Maps
• Tablet migrations in managed Bigtable instances
• Results of tests run on Google’s distributed build system
• Disk I/O statistics for hundreds of thousands of disks
• Resource monitoring for jobs run in Google’s data centers
• Symbols and dependencies in Google’s codebase
14. Differences
• Dremel( BigQuery ) is designed as an interactive data
analysis tool for large datasets ( not only programmer )
• MapReduce is designed as a programming framework
to batch process large datasets ( only programmer )
15. Differences
Key Differences BigQuery MapReduce
What is it? Query service for large datasets
Programming model for processing large
datasets
Common use
cases
Ad hoc and trial-and-error
interactive query of large dataset for
quick analysis and troubleshooting
Batch processing of large dataset for time-
consuming data conversion or aggregation
Very fast
response
Yes ( ~ 10 secs ) No ( takes minutes - days )
Easy to use Yes No ( requires Hive / Tenzing )
Programming
complex data
processing logic
No Yes
Updating
exsiting data
No Yes
16. BigQuery vs MapReduce
• BigQuery - 구조화된 데이터를 SQL을 사용해서 실시간으
로 다루기 위해 디자인되었으며, CSV나 JSON을 통해 데이
터를 import할 수 있으며, 등록된 데이터를 수정할 수 없다.
• MapReduce - 구조화되지 않은 데이터를 프로그램적으로
처리하는데 더 적합하며, 어떠한 데이터나 복잡한 로직도 적
용 가능. 비실시간 데이터를 배치 작업을 통해서 결과를 얻어
오는데 적합하다.
17. BigQuery 용어
• Project - BigQuery 데이터의 컨테이너로 결제가 Project단
위로 이루어짐. ACL 로 Project에서 제어합니다.
• Dataset - Dataset은 하나 이상의 Table 모음 ( like
Database )
• Table - 일반적인 2차원 데이터 저장 묶음
• Job - Job은 데이터 쿼리, import, export, Table간 데이터
복사와 같은 장기 실행 Job을 관리하는데 사용
18. BigQuery 특징
• 오직 CR( Create and Read ) 만 가능
( 데이터의 입력 및 읽기만 가능 )
• 삭제 단위는 최소 Table 단위
• 제한된 Join 지원
• 스키마
• Nested 테이블 구조 지원 ( Only JSON schema )
• No index
19. BigQuery 특징
• PaaS 의 장점을 그대로 계승
• 초기 투자 비용 없음
• 사용한 만큼 비용 지불
• 고급 시스템 운영 인력이 별도로 필요하지 않음
• 이만큼 더 빠르게 만들기 쉽지 않음 ( 몇십억 rows - 수초 이내 )
• 조단위의 레코드 지원 및 테라바이트 크기의 데이터 지원
• SQL 지원으로 편리하며 익숙함
25. 가격정책
• 저장
• $0.12 ( GB / 월 )
• 최대 2TB
• 쿼리
• $0.035( 처리되는 GB당 ) - 최소 1MB
• 일일 20K 쿼리 ( QPD )
• 일일 20TB 데이터 처리
26. 쿼리 비용 계산방법
• 샘플 Table - Wikipedia
• Table Size : 35.7GB
• Rows : 313,797,035
27. 쿼리 비용 계산방법
title id language revision_id contributor_username timstamp
Size
(GB)
6.79 2.34 0.599 2.34 2.49 2.34
Type string integer string integer integer integer
Query 1
SELECT id FROM [publicdata:samples.wikipedia];
28. 쿼리 비용 계산방법
title id language revision_id contributor_username timstamp
Size
(GB)
6.79 2.34 0.599 2.34 2.49 2.34
Type string integer string integer integer integer
Query 1
SELECT id FROM [publicdata:samples.wikipedia];
29. 쿼리 비용 계산방법
title id language revision_id contributor_username timstamp
Size
(GB)
6.79 2.34 0.599 2.34 2.49 2.34
Type string integer string integer integer integer
Query 1
SELECT id FROM [publicdata:samples.wikipedia];
30. 쿼리 비용 계산방법
title id language revision_id contributor_username timstamp
Size
(GB)
6.79 2.34 0.599 2.34 2.49 2.34
Type string integer string integer integer integer
Query 2
SELECT id FROM [publicdata:samples.wikipedia] LIMIT 100;
Query 3
SELECT id FROM [publicdata:samples.wikipedia] WHERE contributor_username LIKE ‘K%’ LIMIT 100;
31. 쿼리 비용 계산방법
title id language revision_id contributor_username timstamp
Size
(GB)
6.79 2.34 0.599 2.34 2.49 2.34
Type string integer string integer integer integer
Query 2
SELECT id FROM [publicdata:samples.wikipedia] LIMIT 100;
Query 3
SELECT id FROM [publicdata:samples.wikipedia] WHERE contributor_username LIKE ‘K%’ LIMIT 100;
32. 쿼리 비용 계산방법
title id language revision_id contributor_username timstamp
Size
(GB)
6.79 2.34 0.599 2.34 2.49 2.34
Type string integer string integer integer integer
Query 2
SELECT id FROM [publicdata:samples.wikipedia] LIMIT 100;
Query 3
SELECT id FROM [publicdata:samples.wikipedia] WHERE contributor_username LIKE ‘K%’ LIMIT 100;
33. 쿼리 비용 계산방법
title id language revision_id contributor_username timstamp
Size
(GB)
6.79 2.34 0.599 2.34 2.49 2.34
Type string integer string integer integer integer
Query 2
SELECT id FROM [publicdata:samples.wikipedia] LIMIT 100;
Query 3
SELECT id FROM [publicdata:samples.wikipedia] WHERE contributor_username LIKE ‘K%’ LIMIT 100;
34. 쿼리 비용 계산방법
title id language revision_id contributor_username timstamp
Size
(GB)
6.79 2.34 0.599 2.34 2.49 2.34
Type string integer string integer integer integer
Query 4
SELECT contributor_username, count(*) FROM [publicdata:samples.wikipedia] WHERE
contributor_username LIKE 'K%' GROUP BY contributor_username;
35. 쿼리 비용 계산방법
title id language revision_id contributor_username timstamp
Size
(GB)
6.79 2.34 0.599 2.34 2.49 2.34
Type string integer string integer integer integer
Query 4
SELECT contributor_username, count(*) FROM [publicdata:samples.wikipedia] WHERE
contributor_username LIKE 'K%' GROUP BY contributor_username;
36. 쿼리 비용 계산방법
Query 4
SELECT contributor_username, count(*) FROM [publicdata:samples.wikipedia] WHERE
contributor_username LIKE 'K%' GROUP BY contributor_username;
37. 쿼리 비용 계산방법
Query 4
SELECT contributor_username, count(*) FROM [publicdata:samples.wikipedia] WHERE
contributor_username LIKE 'K%' GROUP BY contributor_username;
38. 쿼리 비용 계산방법
Query 4
SELECT contributor_username, count(*) FROM [publicdata:samples.wikipedia] WHERE
contributor_username LIKE 'K%' GROUP BY contributor_username;
위의 내용을 토대로 정리하면,
컬럼기반의 스토리지 특성상 컬럼의 사이즈를 기준으로 사용하는 컬럼의 용량만큼 과금된다.
( 다만, order by 시 사용되는 컬럼은 과금되지 않는 것으로 확인됩니다.
아마도 구조상 정렬없이 진행되는 건에 대한 데이터 일관성을 유지시켜줄 수 없는
구조상의 한계에 의한 것이 아닌가 조심스레 예상해봅니다. )
* 질의를 신경써서 구성해야 하며, 데이터 구성에 기존의 데이터에서 인덱스화 시켜야
하는 것들은 마찬가지로 데이터 용량을 최소하는 방향
( 인덱스를 가볍게 만들 수 있는 )으로 설계
39. 예상비용
* 가정
- 용량 변화 없음
* 비용 - 지금까지 질의한 4번의 쿼리
A. 저장비용
=> 35.7GB * 0.12 = $4.284 ( 약 4,700원 )
B. 질의 비용
=> 2.49 * 0.035 + 2.34 * 0.035 + 4.82 + 2.49 * 0.035 = $0.4249 ( 약 460원 )
비용합계( A + B ) => 4700 + 460 = 5,160원
41. 목적 및 제약사항
• AppEngine의 로그를 조회하는 것이 한계가 있어 고객응대나 간헐적인 오
류에 대한 패턴을 분석하기에는 부족
(This application stores up to 1000 GBytes of logs storage or 90 days of logs.)
• 계획되지 않은 통계 데이터 요청하는 경우가 발생
• 카운터 API를 생성하는 것과 같은 별도의 작업은 여러가지 정황상 불가능
• 서비스가 활성화됨에 따라 로그 로테이션 주기가 지속적으로 짧아짐
• 별도의 시스템을 운영하는 경우는 최소화
(AppEngine의 선택한 장점이 퇴색됨)
• 서비스에 영향 최소화
43. 로그 정의
• 언제(A) 사용자(B)들이 무슨 플랫폼(C)을 사용하여 무슨 종류의 요
청(D)을 하는지?
• 요청후 받아가는 결과(E)는 무엇이며, 내부 처리시간(F)을 얼마인가?
• A - date
• B - user_id, ip_address
• C - os, browser
• D - method, query, path
• E - response_code, response body
• F - duration
48. CloudStorage Bucket 생성
• bucket ( 일종의 folder 개념 ) 을 생성
• 구성상 다른 AppEngine 모듈 및 ComputeEngine에서 접근
할 수 있도록 권한 수정
• [project-id]@appspot.gserviceaccount.com
49. CloudStorage Bucket 생성
• bucket ( 일종의 folder 개념 ) 을 생성
• 구성상 다른 AppEngine 모듈 및 ComputeEngine에서 접근
할 수 있도록 권한 수정
• [project-id]@appspot.gserviceaccount.com
50. CloudStorage Bucket 생성
• bucket ( 일종의 folder 개념 ) 을 생성
• 구성상 다른 AppEngine 모듈 및 ComputeEngine에서 접근
할 수 있도록 권한 수정
• [project-id]@appspot.gserviceaccount.com
51. BigQuery Dataset 생성
• dataset ( RDBMS의 Database ) 를 생성
• 권한은 BigQuery를 접근하는 google compute engine이
동일한 project 이어서 별다른 설정이 필요하지 않음
52. BigQuery Dataset 생성
• dataset ( RDBMS의 Database ) 를 생성
• 권한은 BigQuery를 접근하는 google compute engine이
동일한 project 이어서 별다른 설정이 필요하지 않음
53. 로그 입력 테스트
• Google Cloud SDK를 설치 및 project 설정 진행
https://cloud.google.com/sdk/
• import 시에는 반드시 gz 압축은 필수, —nosync 옵션도 필수
# bq 명령어 : https://developers.google.com/bigquery/docs/cli_tool?hl=ko
54. Log 데이터 생성 script
• https://gist.github.com/judeKim/2abc98d05ecc5c2a9d17
PHP
64. BigQuery에 질의하기 - Join
• 소규모 조인을 지원 - 테이블이 압축했을때 8MB이하일때 가능
( 8MB 제한은 향후 개선될 수 있음 )
• INNER 및 LEFT OUTER JOIN 을 지원
65. BigQuery에 질의하기
• SELECT
• FROM
• JOIN
• WHERE
• HAVING
• GROUP BY
• ORDER BY
• LIMIT
• 집계 함수
• 산술 및 수학 함수
• 비트함수
• 캐스팅 함수
• 비교 함수
• IP 함수
• 논리 연산자 함수
• 정규 표현식 함수
• 문자열 함수
• 타임스탬프 함수
• 기타 함수
66. Data 내보내기
A. 질의한 결과의 행이 16,000개 이하일 경우 CSV로 저장
B. 결과를 또 하나의 BigQuery 테이블로 저장
C. Google Cloud Storage로 분할 파일 저장
https://cloud.google.com/bigquery/exporting-data-from-bigquery?hl=ko
68. BigQuery는?
• 저장 인프라의 제약 사항에 대해서 신경쓰지 않고 마구 집어 넣
어놓고 질의해보기는 괜찮다.
• 비용을 생각한다면 몇가지 최적화 및 코드화 처리는 필수적이다.
• 구글 클라우드 플랫폼을 사용하고 있지 않다면, 다소 불편할 수
있다.
• 통계화 진행하기 위한 중간 데이터 저장소로 사용하는 것도 나쁘
지 않다.
• 하둡 운영할 자신이 없다면 BigQuery를 선택해보는 것도 좋다.
69. BigQuery는?
• 저장 인프라의 제약 사항에 대해서 신경쓰지 않고 마구 집어 넣
어놓고 질의해보기는 괜찮다.
• 비용을 생각한다면 몇가지 최적화 및 코드화 처리는 필수적이다.
• 구글 클라우드 플랫폼을 사용하고 있지 않다면, 다소 불편할 수
있다.
• 통계화 진행하기 위한 중간 데이터 저장소로 사용하는 것도 나쁘
지 않다.
• 하둡 운영할 자신이 없다면 BigQuery를 선택해보는 것도 좋다.