데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 SeoulSeungYong Oh
elastic{on} 2019 Seoul 에서 발표한 데브시스터즈(Devsisters Corp.) 의 Elastic Stack 기반 게임 서비스 통합 로깅 플랫폼 소개 발표 자료입니다.
발표 영상은 https://www.elastic.co/kr/elasticon/tour/2019/seoul/devsisters-game-service-integration-logging-platform-using-elastic-stack 에서 보실 수 있습니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 2부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장Dylan Ko
Gonnector(고넥터) 고영혁 대표가 주최한 스타트업 데이터 활용 세미나 '우리가 데이터를 쓰는 법' 의 세 번째 발표 자료
세미나 : 우리가 데이터를 쓰는 법 (How We Use Data)
일시 : 2016년 4월 12일 화요일 10:00 ~ 18:00
장소 : 마루180 (Maru180) B1 Think 홀
제목 : 모바일 게임 로그 데이터 분석 이야기
연사 : 엔터메이트 공신배 팀장
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 SeoulSeungYong Oh
elastic{on} 2019 Seoul 에서 발표한 데브시스터즈(Devsisters Corp.) 의 Elastic Stack 기반 게임 서비스 통합 로깅 플랫폼 소개 발표 자료입니다.
발표 영상은 https://www.elastic.co/kr/elasticon/tour/2019/seoul/devsisters-game-service-integration-logging-platform-using-elastic-stack 에서 보실 수 있습니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 2부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장Dylan Ko
Gonnector(고넥터) 고영혁 대표가 주최한 스타트업 데이터 활용 세미나 '우리가 데이터를 쓰는 법' 의 세 번째 발표 자료
세미나 : 우리가 데이터를 쓰는 법 (How We Use Data)
일시 : 2016년 4월 12일 화요일 10:00 ~ 18:00
장소 : 마루180 (Maru180) B1 Think 홀
제목 : 모바일 게임 로그 데이터 분석 이야기
연사 : 엔터메이트 공신배 팀장
한빛데브그라운드에서 발표했던 내용입니다.
발표 영상 : https://youtu.be/ohpfSLf0V3Y
--
스타트업 비즈니스에서 데이터를 활용한 전략 수립과 의사결정은 필수적인 요소입니다. 서비스 운영 데이터에서부터 다양한 고객의 행동 로그, 소셜 미디어 데이터까지 다양한 데이터를 모두 모아 분석 환경을 구축하기 위해서는 많은 준비와 고민이 필요합니다. 스타트업에서 빠른 속도와 최소한의 비용, 다양한 분석 Tool들과 연동되는 Data Pipeline, Data Lake, Data Warehouse 구축 경험기를 공유하고자 합니다. 이 과정을 통해 애널리틱스 파이프라인을 구축 과정과 S3, Glue, Athena,EMR, Quicksight와 같은 서버리스 애널리틱스 서비스에 대한 구축 사례를 확인하실 수 있습니다.
xgboost를 이해하기 위해서 찾아보다가 내가 궁금한 내용을 따로 정리하였으나, 역시 구체적인 수식은 아직 모르겠다.
요즘 Kaggle에서 유명한 Xgboost가 뭘까?
Ensemble중 하나인 Boosting기법?
Ensemble 유형인 Bagging과 Boosting 차이는?
왜 Ensemble이 low bias, high variance 모델인가?
Bias 와 Variance 관계는?
Boosting 기법은 어떤게 있나?
Xgboost에서 사용하는 CART 알고리즘은?
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
앱서비스에서 결제를 하고 싶어하는 팀을 위한 안내서.
개념 잡기용이며 상세한 것은 링크를 참조하셔서 공부하세요.
- 독자 : 결제, 정산을 구현하고 싶은 개발자 (입문자 이상)
- 내용 : 결제를 개발할 때 내 서버에 구현해야 할 것들
- 특이사항 : 요즘은 '아임포트' 같은 걸 이용해서 쉽게 연동이 가능합니다만...
발표 영상: https://www.youtube.com/watch?v=Se62pRpk9A0
PDF로 받아서 보시면 더 깨끗하게 보실 수 있습니다.
지난 6개월 간 Diffusion model로 MVP를 만들면서 했던 최적화에 대한 고민과 MLops 경험을 공유합니다. 어제 DEVIEW에서 발표한 내용을 좀 더 이해하기 쉽게 수정했고, Diffusion model에 익숙치 않은 분들을 위해 전반부에 간략한 소개와 발전 과정을 정리했습니다.
최근에 Generative AI로 멋진 제품을 만들고자 하는 분들이 많아진 것 같습니다. 모두가 같은 기술에 접근할 수 있는 상황인 만큼 어떻게 다른 가치를 세상에 설득할 것인가 고민을 더 하게 되네요.
저희가 해왔던 시행 착오가 누군가에겐 도움이 되길 바랍니다!
https://symbiote-ai.com/
Recurrent Neural Networks for Recommendations and Personalization with Nick P...Databricks
In the last few years, RNNs have achieved significant success in modeling time series and sequence data, in particular within the speech, language, and text domains. Recently, these techniques have been begun to be applied to session-based recommendation tasks, with very promising results.
This talk explores the latest research advances in this domain, as well as practical applications. I will provide an overview of RNNs, covering common architectures and applications, before diving deeper into RNNs for session-based recommendations. I will pay particular attention to the challenges inherent in common personalization tasks and the specific adjustments to models and optimization techniques required for success.
한빛데브그라운드에서 발표했던 내용입니다.
발표 영상 : https://youtu.be/ohpfSLf0V3Y
--
스타트업 비즈니스에서 데이터를 활용한 전략 수립과 의사결정은 필수적인 요소입니다. 서비스 운영 데이터에서부터 다양한 고객의 행동 로그, 소셜 미디어 데이터까지 다양한 데이터를 모두 모아 분석 환경을 구축하기 위해서는 많은 준비와 고민이 필요합니다. 스타트업에서 빠른 속도와 최소한의 비용, 다양한 분석 Tool들과 연동되는 Data Pipeline, Data Lake, Data Warehouse 구축 경험기를 공유하고자 합니다. 이 과정을 통해 애널리틱스 파이프라인을 구축 과정과 S3, Glue, Athena,EMR, Quicksight와 같은 서버리스 애널리틱스 서비스에 대한 구축 사례를 확인하실 수 있습니다.
xgboost를 이해하기 위해서 찾아보다가 내가 궁금한 내용을 따로 정리하였으나, 역시 구체적인 수식은 아직 모르겠다.
요즘 Kaggle에서 유명한 Xgboost가 뭘까?
Ensemble중 하나인 Boosting기법?
Ensemble 유형인 Bagging과 Boosting 차이는?
왜 Ensemble이 low bias, high variance 모델인가?
Bias 와 Variance 관계는?
Boosting 기법은 어떤게 있나?
Xgboost에서 사용하는 CART 알고리즘은?
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
앱서비스에서 결제를 하고 싶어하는 팀을 위한 안내서.
개념 잡기용이며 상세한 것은 링크를 참조하셔서 공부하세요.
- 독자 : 결제, 정산을 구현하고 싶은 개발자 (입문자 이상)
- 내용 : 결제를 개발할 때 내 서버에 구현해야 할 것들
- 특이사항 : 요즘은 '아임포트' 같은 걸 이용해서 쉽게 연동이 가능합니다만...
발표 영상: https://www.youtube.com/watch?v=Se62pRpk9A0
PDF로 받아서 보시면 더 깨끗하게 보실 수 있습니다.
지난 6개월 간 Diffusion model로 MVP를 만들면서 했던 최적화에 대한 고민과 MLops 경험을 공유합니다. 어제 DEVIEW에서 발표한 내용을 좀 더 이해하기 쉽게 수정했고, Diffusion model에 익숙치 않은 분들을 위해 전반부에 간략한 소개와 발전 과정을 정리했습니다.
최근에 Generative AI로 멋진 제품을 만들고자 하는 분들이 많아진 것 같습니다. 모두가 같은 기술에 접근할 수 있는 상황인 만큼 어떻게 다른 가치를 세상에 설득할 것인가 고민을 더 하게 되네요.
저희가 해왔던 시행 착오가 누군가에겐 도움이 되길 바랍니다!
https://symbiote-ai.com/
Recurrent Neural Networks for Recommendations and Personalization with Nick P...Databricks
In the last few years, RNNs have achieved significant success in modeling time series and sequence data, in particular within the speech, language, and text domains. Recently, these techniques have been begun to be applied to session-based recommendation tasks, with very promising results.
This talk explores the latest research advances in this domain, as well as practical applications. I will provide an overview of RNNs, covering common architectures and applications, before diving deeper into RNNs for session-based recommendations. I will pay particular attention to the challenges inherent in common personalization tasks and the specific adjustments to models and optimization techniques required for success.
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps...hoondong kim
[Tensorflow-KR Offline 세미나 발표자료]
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps Cycle 구성 방법론. (Azure Docker PaaS 위에서 1만 TPS Tensorflow Inference Serving 방법론 공유)
(GameTech2015) Live Operation by Adbrix의 Node.js와 MongoDB를 이용한 멀티테넌트 인프라 구축사례Jeongsang Baek
대부분의 중소 모바일 게임 업체는 앱을 잘 만들기에도 시간이 모자라 출시일을 잘 맞추기 급급한 상황이다. 그러다 보니 운영을 위한 툴은 소홀히 개발하는 경우가 대부분이고 운영 캠페인은 날림으로 개발하거나 그때 그때 개발자가 필요한 부분만 개발하기 일쑤다. 그러다보니 마케터는 결국 늘 개발자 눈치만 살피게 된다. 필자는 블루윈드에서 이러한 문제를 절감했고 '모바일 게임 개발사가 앱 개발에만 집중할 수 있게 해주고 싶다'는 IGAworks의 철학에 공감하여 라이브 오퍼레이션 프로젝트를 시작하게 되었다.
라이브 오퍼레이션의 개발 중점과제는 5가지였다. 첫번째, 다수의 개발사가 하나의 큰 클라우드 시스템을 사용하도록 multi-tenant 인프라를 구축해야 한다. 두번째, TCO(Total cost of ownership)를 최소화해야 한다. 세번째, 앱의 핵심유저를 실시간으로 그룹화하여 타게팅 캠페인을 할 수 있어야 한다. 네번째, 캠페인의 성과를 마케터에게 실시간으로 피드백해야 한다. 다섯째, 3개월 안에 정식 서비스가 되어야 한다는 점이었다. (왜 우리에게 주어지는 시간은 늘 3개월인가) 그리고 당연하지만 이 서비스를 혼자 개발해야 했다.
이 다섯가지 이슈를 해결하기 위하여 AWS 클라우드 상에 생산성과 성능이 검증된 node.js 와 mongodb를 이용하여 서비스 백엔드를 구성하였고, multi-tenant를 구성하기 위한 여러가지 고민과 그 해결책을 직접 구현하였다. 필자는 node.js와 mongodb를 사용해 본 경험이 충분하다 생각했지만 대규모 정식 서비스를 진행하며 많은 함정에 빠졌고 결국 해결했다.
이 발표를 통해 청강자는 node.js와 mongodb를 이용하여 multi-tenant 인프라를 구축해야 할 때 고려해야 할 설계 방식과 기술적인 고민, 그것에 대한 현실적인 해법을 얻을 수 있다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
AWS 클라우드를 활용하면 사용자의 트래픽에 따라 IT 인프라 아키텍처를 확장할 수 있습니다. 이번 강연에서는 서비스 초기의 작은 트래픽에 대응할 수 있는 단순한 아키텍처로 시작해 사업 성장 후의 수백만 사용자에 달하는 대규모 트래픽을 지탱할 수 있는 고확장성 아키텍처에 이르기까지의 단계별 아키텍처 구성 방법에 대해 소개해 드리고 컴퓨팅 및 데이터베이스 선택 및 사용자 증가에 따른 트래픽 경감 방법, 오토스케일링 및 모니터링과 자동화, DB 부하 분산, 고가용성 확보 등에 대한 다양한 모범사례를 알려드릴 예정입니다.
1. 백억 개의 로그를 모아
검색하고 분석하고 학습도 시켜보자: 로기스
현동석 / 김광림 / 양은숙
Naver Search
NAVER
LOGISS
Log gathering system for search, analysis, and machine learning.
2. 이런 얘기를 하겠습니다.
1. Problems and solutions
• 로그를 모을 수 없어 발생하는 문제
• 이를 해결하기 위해 LOGISS 설계하며 고민했던 내용
2. Lesson learned
• 빅데이터 로그 인덱싱을 위한 시스템 튜닝
• 점진적 규모 확장과 장애처리를 위한 관리 자동화
• 무중단 롤링 업그레이드 경험으로 얻은 노하우
3. Applications
• LogFlow 문제 추적을 위한 로그 트레이싱
• Query k-means Word2vec 임베딩을 사용한 질의어 클러스터링
• HawkSee 로그에서 추출한 시퀀스를 사용한 RNN 자동 완성
4. Closing
4. 매일 수십억 건의 로그가 수천 수만대의 장비에 만들어짐
로그 하나 보려면 수십 대의 장비에 수백 기가의 로그 파일을 뒤져야 함
문제1: A needle in a haystack
도커 컨테이너 재시작하면 로그는?
볼륨 디렉토리? 같은 장비에 컨테이너가 뜰까?
볼륨 컨테이너? 장비간 로그 전송 트래픽은?
문제2: Log is volatile
어떤 시스템의 어떤 서버가 어떤 요청을 처리하다 남긴 로그인가
IP has not enough information for trouble-shooting.
문제3: Originality problem
5. 해결1,2: 로그 검색 기능 제공
많은 문서(로그)에서 특정 조건에 맞는 문서(로그)를 찾는 문제
= 검색을 제공하여 해결. 어떤 검색 엔진을 써야할까?
해결3: 로그 헤더 포맷을 정의
언제 어떤 시스템의 Custom 어떤 서버가 어떤 시스템의 Custom 어떤 서버로 보낸 어떤 포맷의 로그 내용
Sender Logger
1 12341234
12.123
naver Custom front-end blog Custom search-application accesslog [2017/09/17 11:22:33.456
+0900] GET
1 12341234
12.123
naver hostname front-end blog Container-
hash,misc-
info
search-application accesslog [2017/09/17 11:22:33.456
+0900] GET
Log header
6. ES를 도입한 다른 사례를 살펴보니, 사용 시나리오에 맞는 시스템을 제공해야 함을 발견!
• Elastic search
• 로그 브라우저 제공 > 문제 추적, 데이터 가시화
• ES API 제공 > 사용자 대시보드, 알림 시스템 구현, 딥러닝 등의 프로토타이핑
• 사내 분산 저장시스템 Cuve[큐브]에 넣어 제공(HBase)
• Production level big data processing.
• Long running ML training with big data.
해결+: 사용 시나리오에 맞는 시스템을 제공하자
Multiplexer
(Kafka)
For search,
prototyping
For big data
processing
ELK
Cuve (Hbase)
Aggregator
KafCuve
11. Design: #4
Docker out.
Whole ELK stack
Monitoring tools
Dashboards
Beats
…
대량의 데이터를 물고 뜨는 서버에 대한 컨테이너라이징에 대한 고민은 충분히 하지 않음. 방법은 있을 것 같은
데 운영 비용까지 고려해서 사용할 만한지, 노드 리플리케이션에 비해 경쟁력이 있는 지는 충분한 고민이 필요.
(이 부분은 의견을 듣고 싶습니다 ^^)
13. Logs from the same system go to the same index
로그 헤더 적용은 쉽지 않았지만 해놓으니 이렇게 깔끔했습니다.
14. Users load their logs into HDFS using a single command
$ HADOOP_USER_NAME=<USERNAME> $HADOOP_COMMON_HOME/bin/hadoop --config $C3_CONF_DIR jar
target/CuveC3-1.0-SNAPSHOT.jar <SSUID> <ROLE> <FROM_TIME> <TO_TIME> <HDFS_OUTPUT_PATH>
TIP. 쌓아놓은 로그의 접근성을 좋게 하기 위해 MR 탬플릿을 만들어 제공했더니,
- 추천 등의 데이터 분석작업에서 활용하기 편해졌습니다.
- 동시에 ES에 무리한 질의를 던지지 않는 효과도 있습니다.
15. Loading logs into Jupyter as importing MNIST data set.
TIP. 로그 데이터를 쉽게 가져올
수 있도록 Python library 를 만
들어놓으면 활용도가 커집니다.
16. Security
로그의 접근 제한을 고민했습니다.
Searchguard 쓰려면,.
- (지금은 안쓰지만) x-pack과 충돌
- SSL 오버헤드 감수(로기스는 초당 5만건 이상이
라 오버헤드가 있습니다)
- Curator, ansible, haproxy, prometheus 등
에 ssl 설정 해주고 인증서 작업 진행
- 이 것 외에도 권한/인증 운영 부담
- 모든 걸 감수하고 운영까지 검증하신 분 있다면
공유 부탁드려요
그냥 개인 정보를 미리 삭제 했습니다.
OAuth2 사내 인증을 적용했습니다.
Hbase의 경우 Cuve의 티켓 권한 관
리 기능을 활용했습니다.
18. 배운점 하나 | docker가 만능은 아니다. (docker 탈출기)
배운점 둘 | 튜닝은 끝나지 않는다.
빅데이터 로그 인덱싱을 위한 시스템 튜닝
19. Docker 너만 믿었건만…
빅데이터 로그 인덱싱을 위한 시스템 튜닝
처음에는 (당연히)
Docker 사용
Docker Swarm 으로
관리도 편하게 해 볼까?
대용량 데이터 들어오면서 문제 발생!
Elasticsearch
롤링 업그레이드 시 data loss
컨테이너별 업데이트시
’아주’ 충분한 시간 두고 띄우자
: 비효율
색인을 컨테이너 바깥에 두면?
: 그러면 굳이 swarm을 쓸 필요가?
수동으로 컨테이너팜 관리… 잘 할 수 있겠니?
다시 Swarm을 걷어내고 container로만 쓴다면?
그럼 Docker를 쓸 필요가 있을까?
Ansible로 충분히 운영가능함.
우리가 주력으로 써야 하는
Elasticsearch, Kafka 는 이미
분산처리가 기본으로 잘 되어 있다.
서버 튜닝할 때 컨테이너라서 어려운 것도 많은데…
대규모 트래픽을 받지만 scale-out 이 빈번하게 일어나지는 않는다.
Docker… Swarm… 너 정말 필요하겠니?
색인 데이터 컨테이너 안에 두고
docker service update
: 데이터 유실 위험
21. 성능 튜닝 - 다들 하고 계시는 것, 그것입니다.
빅데이터 로그 인덱싱을 위한 시스템 튜닝
Elasticsearch
• JVM swap 방지 : memlock unlimited, vm.swappiness, vm.max_map_count,
bootstrap.memory_lock
• file descriptor 최대값: nofile, noproc
• elasticsearch thread pool 옵션 살펴보기: bulk, bulk_queue size 늘리기 등
• SSD 이용한다면 성능 올릴 수 있는 옵션 설정:
indices.store.throttle.max_bytes_per_sec
• 샤드, 인덱스 밸런스 맞추기 위해 계산 잘 하기
• 색인 크기가 너무 커서 성능이 떨어지지 않도록 하기(<10GB). 너무 크면 shard
allocation 에도 문제가 생긴다.
• index merge를 줄이기위한 노력 필요: index.refresh_interval
• OOM 방지를 위한 index 관련 설정: indices.fielddata.cache.size,
indices.breaker.total.limit, indices.breaker.fielddata.limit,
indices.breaker.request.limit, network.breaker.inflight_requests.limit
Logstash
• I/O 를 실제로 지켜보면서 튜닝하는 것이 필요: heap_size, pipeline.workers,
pipeline.output.workers, pipeline.batch.size, kafka_consumer_threads
• grok filter 성능 이슈: 아주 편리하지만 너무 많은 rule이 들어가면 병목이 될 수 있음.
현재진행중인 고민
• 대용량 데이터 유입 테스트 위해 dutchdrop filter 만들기
Kibana
• custom plugin 만들때 주의할 사항들 있음: upgrade, 다른 plugin과 충돌
Kafka
• 의도치않게 장비가 종종 죽는 문제: 커널업으로 해결
AS-IS: CentOS 7.2.1511 (Core) 3.10.0-327.36.2.el7.x86_64
TO-BE : CentOS 7.3.1611 (Core) 3.10.0-514.21.1.el7.x86_64
22. 성능 튜닝 - 우리 시스템 성능 개선만 하면 ok? 당연히 아닙니다.
연동되어 있는 곳이 많은데 큰 데이터를 다룬다면?
• 전송 횟수 줄이려 log aggregation 해서 데이터 저장소에 보냈더니
그곳에서는 폭탄. (결국 10M -> 512k 로 줄여서 전송)
• 혼자만 잘 살 수 없음. 우리도 전체 시스템의 일부일 뿐…
전체의 밸런스를 위해 우리 성능을 (어느정도) 희생할 필요도
한계 용량보다 더 많은 로그가 들어온다면?
• Logstash throttling 으로 버틸 수 있지만 worker thread 간 counter 동기화로 성능 저하
빅데이터 로그 인덱싱을 위한 시스템 튜닝
어디서나 중요한 것은 밸런스, 밸런스, 밸런스 !
23. 성능 튜닝 - 여전히 진행중입니다.
초기의 구성의 물리적 변화는 최소화하며 처리 용량 늘리고 있음.
마른 걸레 쥐어짜기
빅데이터 로그 인덱싱을 위한 시스템 튜닝
24. 첫번째 | 복잡한 시스템에서 Ansible 효과적으로 쓰기 위한 작업들
두번째 | Monitoring – 장애처리 + 성능튜닝을 동시에 하자.
점진적 규모 확장과 장애 처리를 위한 관리 자동화
25. Ansible https://www.ansible.com/
점진적 규모 확장과 장애 처리를 위한 관리 자동화
Role
Sub system 마다 Role 부여
• Role 하나에는 다음 파일들이 있음
- 작업 실행을 위한
ansible-playbook 파일 (yml)
- 변수 치환하여 사용가능한 설정파일
들 (conf, properfies 등)
• 손쉬운 구조화를 위해 Ansible의 표준
디렉토리 구성을 따름
• Tasks 디렉토리 안에는
제일 기본이 되는 main.yml외에도
필요한 작업을 설정해 둠
Inventory
Dev/Staging/Production 별
Inventory로 관리
• 동일한 작업을 inventory만 다르게 지
정하여 손쉽게 수행 가능
• Inventory별로 변수 지정을 다르게 하
여 테스트, 외부시스템 연동에 자유도
를 높일 수 있다.
• 주의점: variable 선언시 Ansible의
우선순위가 있음.
- inventory에서 재정의하여 쓸 수 없
는 것도 있음: roles/xxx/vars,
include_vars, registered vars
- inventory defined vars 는 우선순
위가 낮은 편이므로 yml 작성시 주의
Ansible 표준
Directory 구조
Role
Inventory 이름
26. 점진적 규모 확장과 장애 처리를 위한 관리 자동화
elasticse
arch
es-cluster
kibana
es-client
curator
manager
zookeep
er
zookeper
kafka
kafka
logstash
bel
logstash
fel
haproxy
haproxy
node-
exporter
all
prometh
eus
alerter
grafana
monitor
LOGISS ansible-playbook
Host
Role
Job: bel Job: fel
hosts.yml
main.yml
이 순서대로 진
행하면 전체 배
포
특정 Host/Role
지정하여
해당 모듈만 배
포
27. 점진적 규모 확장과 장애 처리를 위한 관리 자동화
elasticsearch role
Ansible-playbook 일부
Ansible-playbook
실행화면
28. 시스템이 복잡할수록 Ansible이 유용합니다.
내부 시스템/모듈과 다양한 opensources 모두 잘 엮어서
ansible-playbook 을 시나리오별로 만들어 사용
(ex: site.yml, es-rolling-upgrade.yml, es-full-restart.yml, kafka-partition.yml …)
ansible-vault : 파일 암호화가 필요한 경우 유용 (공개 github repo 에 올릴때)
처음 설정할때는 힘들지만, 이후 시스템 확장/변경 될 때는 대응하기 (아주) 편리합니다.
Dockerfile 만들때 느낌…?
점진적 규모 확장과 장애 처리를 위한 관리 자동화
30. 첫번째 | Elasticsearch Rolling upgrades
두번째 | Logiss는 이렇게 자주 버전을 올리나요?
세번째 | 롤링 업그레이드는 어떻게 하나요?
무중단 롤링 업그레이드 경험으로 얻은 노하우
31. Elasticsearch Rolling upgrades
롤링 업그레이드란?
Elasticsearch 클러스터에 { }버전 업그레이드를 하는 것입니다.
언제 하나요?
• 무중단 서비스 제공이 필요할 때 유용합니다.
• Elasticsearch 마이너 버전 업그레이드에만 가능합니다. (5.x => 5.y)
• 5.6.0 => 6.x 업그레이드는 가능!
무중단 롤링 업그레이드 경험으로 얻은 노하우
다운타임 없이
노드 하나씩
32. 로기스는 가능한 Elastic stack 최신 버전을 유지하려고 합니다.
(자주) 버전업하는 이유는,
bug fix, 최신 기능등을 빠르게 적용
시스템을 건전한 상태로 유지하기에 좋은 방법
기술 부채, 업그레이드 부채
(운영) 자신감도 조금씩 업그레이드
실제로 5.x 에서는 롤링 업그레이드가 수월합니다.
무중단 롤링 업그레이드 경험으로 얻은 노하우
2/6 3/14 3/31 4/26 5/1 5/10 6/9 6/23 7/7 7/29 8/26 9/16
5.0.1LOGISS
Upgrade
Timeline
Cases
• 5.6.0 적용: Logstash throughput 약 40% up
• 5.4.0 적용: Logstash persistent queues 사용하여 data 유실 최소화
• 5.3.0 적용:
- Elasticsearch 의 multi data path 버그 해결
- Logstash 에서 age filter 적용
• Lucene 버전이 꾸준히 올라가면서 Elasticsearch 색인 성능 조금씩 개선됨
{
9/23
33. 롤링 업그레이드는 어떻게 하나요? – 한번에 노드 하나씩!
무중단 롤링 업그레이드 경험으로 얻은 노하우
순차적으로 하나씩
업그레이드
샤드 할당 활성화
색인 재개
클러스터 상태확인
Elasticsearch Cluster
색인 중단
노드 재시작
Node 1
(master)
Node 2
(master)
Node 3
(Ingest)
Node 4
(Data)
Node 5
(Data)
Node K
(Data)
…
롤링 업그레이드
Timeline
synced flush
노드 하나에서
작업 시작
작업완료 후
다음 노드에
적용전까지 대기
Ver. 5.5.2 Ver. 5.6.0
Logstash
Logstash (BEL)
색인 중단시
유입 차단
샤드 할당 비활성
34. 롤링 업그레이드는 어떻게 하나요? – LOGISS에서 실제 작업과정
무중단 롤링 업그레이드 경험으로 얻은 노하우
동영상 예정
37. LogFlow: 문제 추적을 위한 로그 트레이싱
Distributed Tracing System
• Google – Dapper
• Facebook – The Mystery Machine
• Zipkin http://zipkin.io/
• Opentracing http://opentracing.io/
38. LogFlow: 문제 추적을 위한 로그 트레이싱
Logiss 로그 포맷 – sender, logger
trace_id
trace_id
trace_id
Logiss 로그 포맷 로그본문에
Trace ID 추가
Trace ID 로 특정 request 에 응답한 모든 서버 로그를 묶은다음,
sender, logger 정보 이용하여 부모/전후관계를 엮으면?
59. Distributed queue
- Traffic handling
- Data channeling
- Buffering for system recovery
Throttling / filtering
Parsing,securingpriv.dataParsing,securingpriv.data,aggregation
API
API
Cuve: Dist. Storage Platform
Group by time
Groupbyserviceandroles
Realtime indexing
Long term storage
.lib.lib
C3 DL
Deep Learning Pl
atform
Trouble-shooting Event visualization
Logiss
Unified log format
Timeline viewer
Machine learning
research & application
NAVER Search Logs & Content
s
60. References
• Elasticsearch in netflix
https://www.slideshare.net/g9yuayon/elasticsearch-in-netflix
• Deploying and scaling Logstash
https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html
• Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
https://research.google.com/pubs/pub36356.html
• The Mystery Machine: End-to-end Performance Analysis of Large-scale Internet Services
https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-chow.pdf
• Zipkin
http://zipkin.io/
• Opentracing
http://opentracing.io/