본 온라인 세미나에서는 AWS 서비스를 활용하시는데 있어, 총 소유비용(TCO) 관점에서 클라우드 사용시 장점에 대해 이해하고, AWS서비스 사용시 어떻게 하면 비용최적화를 잘 할 수 있을지를 예약인스턴스, 스팟인스턴스, S3의 라이프사이클 정책 활용 방법 등을 통해 학습합니다. 특별히, 예약인스턴스 구매, 비용 알람 설정, AWS 서비스 월별 사용 계산기 사용법 등에 대한 핸즈온을 통해 좀 더 저희 서비스에 쉽게 접근하실 수 있도록 도와드립니다.
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...Amazon Web Services Korea
기존 온프레미스 환경에서는 비즈니스 성장에 따른 유연한 확장에 어려움 있어 AWS를 이용하여 더욱 탄력적인 환경을 구축하는 프로젝트를 수행하였습니다. 이 세션을 통해 카카오게임즈가 AWS와 함께 수행한 데이터레이크 마이그레이션의 여정과, 그 과정에서 Amazon S3, EMR, Athena, Redshift 등의 다양한 기술 요소들을 활용한 경험과 팁을 전달해 드립니다.
2025년도 까지의 데이터 시장의 전망을 살펴보고, 클라우드 상에서 데이터를 효율적으로 다루기 위한 서비스들을 소개합니다 | Explore the prospects for the data market by 2025 and introduce services to efficiently address data in the cloud
발표영상 다시보기: https://youtu.be/eQjkwhyOOmI
대규모 데이터 레이크 구성 및 관리는 복잡하고 시간이 많이 걸리는 작업입니다. AWS Lake Formation은 수일만에 안전한 데이터 레이크를 구성할 수 있는 완전 관리 서비스입니다. 본 세션에서는 데이터 수집, 분류, 정리, 변환 및 보안을 위해 AWS Lake Formation을 통해 Amazon S3, EMR, Redshift 및 Athena와 같은 분석 도구를 쉽게 구성하는 방법을 알아봅니다. (2019년 11월 서울 리전 출시)
본 온라인 세미나에서는 AWS 서비스를 활용하시는데 있어, 총 소유비용(TCO) 관점에서 클라우드 사용시 장점에 대해 이해하고, AWS서비스 사용시 어떻게 하면 비용최적화를 잘 할 수 있을지를 예약인스턴스, 스팟인스턴스, S3의 라이프사이클 정책 활용 방법 등을 통해 학습합니다. 특별히, 예약인스턴스 구매, 비용 알람 설정, AWS 서비스 월별 사용 계산기 사용법 등에 대한 핸즈온을 통해 좀 더 저희 서비스에 쉽게 접근하실 수 있도록 도와드립니다.
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...Amazon Web Services Korea
기존 온프레미스 환경에서는 비즈니스 성장에 따른 유연한 확장에 어려움 있어 AWS를 이용하여 더욱 탄력적인 환경을 구축하는 프로젝트를 수행하였습니다. 이 세션을 통해 카카오게임즈가 AWS와 함께 수행한 데이터레이크 마이그레이션의 여정과, 그 과정에서 Amazon S3, EMR, Athena, Redshift 등의 다양한 기술 요소들을 활용한 경험과 팁을 전달해 드립니다.
2025년도 까지의 데이터 시장의 전망을 살펴보고, 클라우드 상에서 데이터를 효율적으로 다루기 위한 서비스들을 소개합니다 | Explore the prospects for the data market by 2025 and introduce services to efficiently address data in the cloud
발표영상 다시보기: https://youtu.be/eQjkwhyOOmI
대규모 데이터 레이크 구성 및 관리는 복잡하고 시간이 많이 걸리는 작업입니다. AWS Lake Formation은 수일만에 안전한 데이터 레이크를 구성할 수 있는 완전 관리 서비스입니다. 본 세션에서는 데이터 수집, 분류, 정리, 변환 및 보안을 위해 AWS Lake Formation을 통해 Amazon S3, EMR, Redshift 및 Athena와 같은 분석 도구를 쉽게 구성하는 방법을 알아봅니다. (2019년 11월 서울 리전 출시)
AWS Glue는 고객이 분석을 위해 손쉽게 데이터를 준비하고 로드할 수 있게 지원하는 완전관리형 ETL(추출, 변환 및 로드) 서비스입니다. AWS 관리 콘솔에서 클릭 몇 번으로 ETL 작업을 생성하고 실행할 수 있습니다. 빅데이터 분석 시 다양한 데이터 소스에 대한 전처리 작업을 할 때, 별도의 데이터 처리용 서버나 인프라를 관리할 필요가 없습니다. 본 세션에서는 지난 5월 서울 리전에 출시한 Glue 서비스에 대한 자세한 소개와 함께 다양한 활용 팁을 데모와 함께 소개해 드립니다.
- 동영상 보기: https://www.youtube.com/watch?v=Rq4I57eqIp4
Amazon RDS 프록시는 Amazon Relational Database Service (RDS)를 위한 완전 관리형 고가용성 데이터베이스 프록시로, 애플리케이션의 확장 성, 데이터베이스 장애에 대한 탄력성 및 보안 성을 향상시킬 수 있습니다. (2020년 6월 서울 리전 출시)
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
Today, most any application can be “Dockerized.” However, there are special challenges when deploying a distributed application such as Spark on containers. This session will describe how to overcome these challenges in deploying Spark on Docker containers, with many practical tips and techniques for running Spark in a container environment.
Containers are typically used to run stateless applications on a single host. There are significant real-world enterprise requirements that need to be addressed when running a stateful, distributed application in a secure multi-host container environment.
There are decisions that need to be made concerning which tools and infrastructure to use. There are many choices with respect to container managers, orchestration frameworks, and resource schedulers that are readily available today and some that may be available tomorrow including:]
• Mesos
• Kubernetes
• Docker Swarm
Each has its own strengths and weaknesses; each has unique characteristics that may make it suitable, or unsuitable, for Spark. Understanding these differences is critical to the successful deployment of Spark on Docker containers.
This session will describe the work done by the BlueData engineering team to run Spark inside containers, on a distributed platform, including the evaluation of various orchestration frameworks and lessons learned. You will learn how to apply practical networking and storage techniques to achieve high performance and agility in a distributed, container environment.
Speaker
Thomas Phelan, Chief Architect, Blue Data, Inc
BespinGlobal 컨설팅 본부
최정식 위원(js.choi@bespinglobal.com)
데이터 마이그레이션 세미나 - 데이터로 날자
Helping You Adopt Cloud | 가트너 선정 아시아 No.1 클라우드 MSP, 성공적인 클라우드 도입을 위한 전략, 구축, 운영 및 관리 서비스 제공
AWS Summit Seoul 2023 | AWS에서 OpenTelemetry 기반의 애플리케이션 Observability 구축/활용하기Amazon Web Services Korea
CNCF의 오픈소스 기반 애플리케이션 Observability 프레임워크인 OpenTelemetry를 기반으로 AWS에서 텔레메트리 데이터를 수집, 추적 및 시각화하는 방법을 살펴봅니다. 또한 이를 통해 서비스의 문제점을 발견하고 그 원인을 분석하는 방법을 이야기합니다.
Introduction to Amazon EMR design patterns such as using Amazon S3 instead of HDFS, taking advantage of Spot EC2 instances to reduce costs, and other Amazon EMR architectural best practices.
최근 국내와 글로벌 서비스에서 MongoDB를 사용하는 사례가 급증하고 있습니다. 다만 전통적인 RDBMS에 비해, 아직 지식과 경험의 축적이 적게 되어 있어 손쉬운 접근과 트러블 슈팅등에 문제가 있는 것도 사실입니다. 이 세션에서는 MongoDB 와 AWS의 DocumentDB의 Architecure를 간단히 살펴보고 MongoDB 및 DocumentDB의 비교를 진행하며 특히 MongoDB와 DocumentDB를 사용할때 주의해야할 중요 포인트에 대해서 알아봅니다.
발표자: 이정훈 솔루션즈 아키텍트, AWS / 이상규 솔루션즈 아키텍트, AWS / 현륜식 솔루션즈 아키텍트, AWS / 강동환 솔루션즈 아키텍트, AWS
Part 1 : Cloud 로의 전환
Cloud로 전환하는 과정에서 검토되는 Windows 서버 운영 및 Cloud Endure에 대한 기본 개념 등을 소개합니다.
Part 2 : SAP 에 대한 고민
본 세션에서는 기업들이 가지고 있는 SAP 가치를 극대화하고 비용절감 및 업무자동화를 실천하는 방법에 대해 소개합니다
Part 3 : 백업 및 복구
기업들이 가지고 있는 데이터 통합관리 및 재해복구 방안, 그리고 데이터 내구성을 확보하고 비용절감하는 방안에 대해 소개합니다.
Part 4 : 하이브리드 클라우드 아키텍처
하이브리드 클라우드 아키텍처를 제시하고, VMware Cloud on AWS, Outposts와 같은 고객의 On-Premise 환경과 밀접한 관련이 있는 제품 및 서비스를 알아봅니다.
This session will cover performance-related developments in Red Hat Gluster Storage 3 and share best practices for testing, sizing, configuration, and tuning.
Join us to learn about:
Current features in Red Hat Gluster Storage, including 3-way replication, JBOD support, and thin-provisioning.
Features that are in development, including network file system (NFS) support with Ganesha, erasure coding, and cache tiering.
New performance enhancements related to the area of remote directory memory access (RDMA), small-file performance, FUSE caching, and solid state disks (SSD) readiness.
롯데이커머스의 마이크로 서비스 아키텍처 진화와 비용 관점의 운영 노하우-나현길, 롯데이커머스 클라우드플랫폼 팀장::AWS 마이그레이션 A ...Amazon Web Services Korea
2015 년부터 진행한 실험적 퍼블릭클라우드 운영에 대한 최근 결과를 공유하며 그간 경험한 MSA Architecture 환경, Cost optimization, Operation 관련 내용을 공유합니다. 특히 대규모 운영 환경에서 경험한 다양한 관점의 경험과 비용절감에 대해 인사이트를 제공 예정입니다.
AWS Glue는 고객이 분석을 위해 손쉽게 데이터를 준비하고 로드할 수 있게 지원하는 완전관리형 ETL(추출, 변환 및 로드) 서비스입니다. AWS 관리 콘솔에서 클릭 몇 번으로 ETL 작업을 생성하고 실행할 수 있습니다. 빅데이터 분석 시 다양한 데이터 소스에 대한 전처리 작업을 할 때, 별도의 데이터 처리용 서버나 인프라를 관리할 필요가 없습니다. 본 세션에서는 지난 5월 서울 리전에 출시한 Glue 서비스에 대한 자세한 소개와 함께 다양한 활용 팁을 데모와 함께 소개해 드립니다.
- 동영상 보기: https://www.youtube.com/watch?v=Rq4I57eqIp4
Amazon RDS 프록시는 Amazon Relational Database Service (RDS)를 위한 완전 관리형 고가용성 데이터베이스 프록시로, 애플리케이션의 확장 성, 데이터베이스 장애에 대한 탄력성 및 보안 성을 향상시킬 수 있습니다. (2020년 6월 서울 리전 출시)
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
Today, most any application can be “Dockerized.” However, there are special challenges when deploying a distributed application such as Spark on containers. This session will describe how to overcome these challenges in deploying Spark on Docker containers, with many practical tips and techniques for running Spark in a container environment.
Containers are typically used to run stateless applications on a single host. There are significant real-world enterprise requirements that need to be addressed when running a stateful, distributed application in a secure multi-host container environment.
There are decisions that need to be made concerning which tools and infrastructure to use. There are many choices with respect to container managers, orchestration frameworks, and resource schedulers that are readily available today and some that may be available tomorrow including:]
• Mesos
• Kubernetes
• Docker Swarm
Each has its own strengths and weaknesses; each has unique characteristics that may make it suitable, or unsuitable, for Spark. Understanding these differences is critical to the successful deployment of Spark on Docker containers.
This session will describe the work done by the BlueData engineering team to run Spark inside containers, on a distributed platform, including the evaluation of various orchestration frameworks and lessons learned. You will learn how to apply practical networking and storage techniques to achieve high performance and agility in a distributed, container environment.
Speaker
Thomas Phelan, Chief Architect, Blue Data, Inc
BespinGlobal 컨설팅 본부
최정식 위원(js.choi@bespinglobal.com)
데이터 마이그레이션 세미나 - 데이터로 날자
Helping You Adopt Cloud | 가트너 선정 아시아 No.1 클라우드 MSP, 성공적인 클라우드 도입을 위한 전략, 구축, 운영 및 관리 서비스 제공
AWS Summit Seoul 2023 | AWS에서 OpenTelemetry 기반의 애플리케이션 Observability 구축/활용하기Amazon Web Services Korea
CNCF의 오픈소스 기반 애플리케이션 Observability 프레임워크인 OpenTelemetry를 기반으로 AWS에서 텔레메트리 데이터를 수집, 추적 및 시각화하는 방법을 살펴봅니다. 또한 이를 통해 서비스의 문제점을 발견하고 그 원인을 분석하는 방법을 이야기합니다.
Introduction to Amazon EMR design patterns such as using Amazon S3 instead of HDFS, taking advantage of Spot EC2 instances to reduce costs, and other Amazon EMR architectural best practices.
최근 국내와 글로벌 서비스에서 MongoDB를 사용하는 사례가 급증하고 있습니다. 다만 전통적인 RDBMS에 비해, 아직 지식과 경험의 축적이 적게 되어 있어 손쉬운 접근과 트러블 슈팅등에 문제가 있는 것도 사실입니다. 이 세션에서는 MongoDB 와 AWS의 DocumentDB의 Architecure를 간단히 살펴보고 MongoDB 및 DocumentDB의 비교를 진행하며 특히 MongoDB와 DocumentDB를 사용할때 주의해야할 중요 포인트에 대해서 알아봅니다.
발표자: 이정훈 솔루션즈 아키텍트, AWS / 이상규 솔루션즈 아키텍트, AWS / 현륜식 솔루션즈 아키텍트, AWS / 강동환 솔루션즈 아키텍트, AWS
Part 1 : Cloud 로의 전환
Cloud로 전환하는 과정에서 검토되는 Windows 서버 운영 및 Cloud Endure에 대한 기본 개념 등을 소개합니다.
Part 2 : SAP 에 대한 고민
본 세션에서는 기업들이 가지고 있는 SAP 가치를 극대화하고 비용절감 및 업무자동화를 실천하는 방법에 대해 소개합니다
Part 3 : 백업 및 복구
기업들이 가지고 있는 데이터 통합관리 및 재해복구 방안, 그리고 데이터 내구성을 확보하고 비용절감하는 방안에 대해 소개합니다.
Part 4 : 하이브리드 클라우드 아키텍처
하이브리드 클라우드 아키텍처를 제시하고, VMware Cloud on AWS, Outposts와 같은 고객의 On-Premise 환경과 밀접한 관련이 있는 제품 및 서비스를 알아봅니다.
This session will cover performance-related developments in Red Hat Gluster Storage 3 and share best practices for testing, sizing, configuration, and tuning.
Join us to learn about:
Current features in Red Hat Gluster Storage, including 3-way replication, JBOD support, and thin-provisioning.
Features that are in development, including network file system (NFS) support with Ganesha, erasure coding, and cache tiering.
New performance enhancements related to the area of remote directory memory access (RDMA), small-file performance, FUSE caching, and solid state disks (SSD) readiness.
롯데이커머스의 마이크로 서비스 아키텍처 진화와 비용 관점의 운영 노하우-나현길, 롯데이커머스 클라우드플랫폼 팀장::AWS 마이그레이션 A ...Amazon Web Services Korea
2015 년부터 진행한 실험적 퍼블릭클라우드 운영에 대한 최근 결과를 공유하며 그간 경험한 MSA Architecture 환경, Cost optimization, Operation 관련 내용을 공유합니다. 특히 대규모 운영 환경에서 경험한 다양한 관점의 경험과 비용절감에 대해 인사이트를 제공 예정입니다.
우리가 이름만 들어도 아는 유명 IT 서비스들의 화려한 웹페이지도, 예쁜 모바일 앱도 그 뒤에는 탄탄하고 강력한 분산 시스템을 기반으로 합니다. 이러한 백엔드 시스템이 부실할 경우 서비스나 앱은 그야말로 사상누각입니다. 본 세미나에서는 이러한 시스템들을 만들때 풀어야 할, 가장 기본이 되는 문제와 이슈들 12가지에 도전해봅니다.
1일 수천대의 서버에서 발생하는 30~50억건의 Log와 Metric을 처리하는 Planet Mon 을 지탱하는 기술인 Collection(Collectd, NXlog), Transport(Kakfa, Logstash), Log Stream Analytics, Storage(Elasticsearch), Visualization을 구성하는 Architecture에 대해 설명드리고 제가 개발한 Log Stream Analytics 서버들의 구현 기술에 대해 좀더 상세히 설명합니다.
[2016 데이터 그랜드 컨퍼런스] 2 1(빅데이터). 티맥스 빅데이터시대,더욱중요해진dw를위한어플라이언스전략K data
빅데이터 환경에서 기업의 의사결정에 필요한 DW 시스템은 더욱 중요해졌고, 대용량 데이터 분석은 필수가 되었다. 전통적인 DBMS의 확장성, 성능 한계를 해결하기 위해서 소프트웨어 뿐만 아니라 최신의 하드웨어 디바이스와 결합하여 어플라이언스 형태의 DW 구축이 대세가 되고 있는 환경에서, 국산 DBMS의 선두주자 티맥스소프트는 외산 DB 어플라이언스와 경쟁할 수 있는 데이터베이스 어플라이언스를 출시하였다. 최근 HP 하드웨어와 어플라이언스 협력 모델을 내놓았으며, 기존의 DBMS가 해결하지 못한 초대용량과 고성능, 그리고 데이터의 확장성이 특징이다. ZetaData는 고성능 데이터베이스 서버와 지능형 스토리지 서버, 초고속 네트워크를 통해 대용량 데이터의 빠른 처리와 시스템 안정성을 제공하는 통합(Consolidated) 데이터 솔루션이다.
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 방법론 공유)
Similar to SK ICT Tech Summit 2019_BIG DATA-11번가_DP_v1.2.pdf (20)
5. ‘18.8월 DI TF 결성
• Mission - 11번가 Data Infra를 구축하라!
• Full Time 3명 / Part Time 3명
• 10월 SK Planet 판교 사옥, DIC팀과 동거 시작
신속 & 효율적
SKP DIC
Clone
11st DIC
6. Mission
• SKP DIC 현황 파악 및 Data Infra 구축 계획 수립
:: 첨부자료 - 우주왕복선 Endeavour 호 (’노력’). 1992년 5월 ~. 2011년 6월.
7. Mission
• 구성원들이 구비한 경력과 기술에 따라 3가
지 업무로 분할
• 인프라 구축
• 데이터 입수 파이프라인 구축
• 대용량 데이터 마이그레이션
데이터
마이그레이션
(F/T 1)
•Hive Table / HDFS
•RDBMS Table / Hive Meta
•NoSQL DB
데이터 입수
(P/T 3)
•User Log
•System Log
•DB Data
인프라
(F/T 1)
•Hardware
•Software
- Hadoop eco system
(F/T 1)
8. 데이터 인프라 구축
• DI TF 결성 : 2018년 8월. Full Time 3명, Part Time 3명
• DIC 구축 : 12월~2019년 2월. 하둡 인프라 + 데이터 수집 인프라 + 데이터 분석/관리 SW (In-House 개발 S/W)
• 데이터 마이그레이션 : 3월. 10 PB
• 서비스 마이그레이션 : 4월. 추천 플랫폼, BI 시스템, Log2.0, Ad Platform, Search Platform, Web Scouter, …
• Yarn 클러스터 메모리 증설 : 5월
• SKP DIC 사용계약 2개월 조기 종료 : 6월 à 4월
9월 10월 11월 12월 ’19년 1월 2월 3월 4월 5월
DI TF 결성 -
DIC 구축 계획, 규모산정,
설계
DIC 구축
(인프라 + 입수 파이프
라인)
데이터 마이그레이션
서비스 마이그레이션
Yarn 메모리 증설
: 4월 13(증설 요청)
5/14~5/28 (증설 완료)
SKP DIC 사용계약 조기
종료 : 2개월. 6월 à 4월
추천, BI, Ad, Log2.0
SKP DIC 사용계약
메모리 증설
SKP DIC 분석, 규모산정, 설계, Pilot 구성
하둡Infra + 데이터 SW + 데이터 수집 인프라
Full Mig.
계약
조기종료
메모리 구매
Incremental Mig.
9. Sources 수집 가공 (분석)
저장
User
Server
DB
Sentinel
Rake
Mirrormaker
Kafka
Collector
Oggre
제공
DW
Hive
OLAP
Druid
NoSQL
HBase
Data
Service
BI System
Reco
Seller
Analytics
ICT Family
Yarn-RT
Yarn-DI
Yarn-mini
Query / ML / DL
HDFS-DIC
HDFS-DSC
Batch RealTime
Cache
Redis
Search
Query
Engine
Ad
A/B Test
ICT Family
Logagent
Hardware
• Architecture
10. Hardware
• Total 1K 노드
• HDFS : 3 cluster
• DI : 공용 저장소 35 PB
• MSM (Hbase) : 추천 전용 저장소
• PIE : 실험 클러스터
• Yarn : 4 cluster 21K vcore / 125 TB vmem
• DI : 공용 연산노드
• RT : 실시간 스트림 수집 노드
• ETL : 배치 잡 노드 수행
• mini : DB Import 용 Sqoop 수행 노드
• PIE : 실험 클러스터
SKP
• Total 400 노드
• HDFS : 3 cluster
• DI : 공용 저장소 15 PB
• DSC (Hbase) : 추천 전용 저장소
• Yarn : 4 cluster 11K vcore / 85 TB vmem
• DI : 공용 연산 노드
• RT : 실시간 + 배치 잡 수행 노드
• mini : DB Import 용 Sqoop 수행 노드
11st
Ingestion Processing
Storage
Sentinel
Rake
Kafka
Mirrormaker
Kafka
Collector
Oggre
Serving
DW
Hive
OLAP
Druid
NoSQL
HBase
Yarn-RT
Yarn-DI
Yarn-mini
Query / ML / DL
HDFS-DIC
HDFS-DSC
Batch RealTime
Cache
Redis
Query
/Storage
Engine
Logagent
Diet. Diet.
노드 = 1000 ea : 400 ea
가용량 = 35PB : 15PB
사용량 = 18PB : 9PB
11. Hardware
Yarn Cluster 메모리 증설
• Yarn Cluster 메모리 부족 이슈 : 4월 중순 (issue-rasing). ’19. 5월 말 (증설 완료)
• 현상 : Batch Job 및 Spark ML Job 들이 실패함
• 원인 분석
• 워크로드 대비 부족한 자원
• SKP에서 11번가 BM이 리소스의 70% 소비하였으나, 실제 구성된 리소스는 20%, 50% 이하
• 분사에 따른 전기간 소급 적용 배치 증가 + Data 량 증가에 따른 쿼리 워크로드 + 신규 Machine Learning Job 추가
Yarn Cluster SKP 11st (as-was) 11st (as-is)
DI 89 TB 16 TB 58.5 TB
RT 35 TB 16 TB 24.8 TB
mini 1.2 TB 1.75 TB 1.75 TB
Yarn Queue Calibration (allocation)
• Fair Scheduler
14. 데이터 입수 파이프라인 구축
• Overview
Server
DB
LogAgent
Oracle
Golden Gate
보라매 IDC
일산 IDC
OMDB OMDB Relay
MirrorMaker
Collector
Oggre
Sqoop
BIDB
rake
web/was
rake
client
Data Infra
Cluster
User
15. 데이터 입수 파이프라인 구축
• Log / DB 데이터 수집 현황
데이터유형 수집데이터 수집대상 수집도구 일 수집량
User Log - log2.0 - pc web
- modile web
- app (ios, android)
rake client (in-house)
- android, ios, javascript
Rake WEB/WAS : 40ea (26/14)
1.4 T
Server Log - access log
- service log
- web server
- application server
Logagent (in-house) : 450ea
kafka : 13ea(보라매 3/ Alp3 / 일산7)
Collector : 6ea
29 T
DB Data - 업무 데이터 - Main DB
- BI DB
- AD DB
Oggre (in-house) : 2ea
Oozie : 2ea
Yarn-mini : 5ea
7 T
Oggre:209건
Sqoop:245건
16. 데이터 입수 파이프라인 구축 - User Log
• App에서 로그 수집 서버 양측에 전송하는 방법 (X)
• 로그 수집 서버 한 곳에서 트래픽을 복제하여 전송하는 방법 (O)
• Nginx :: post_action : Traffic mirroring
• Origin : SKP
1. 11st 로그 입수 파이프라인을 구축
2. 신규 앱 배포 : 사용자 로그를 전송하는 End Point을 변경 (SKP à 11st)
• 로그를 양사 DIC로 송출 (Origin : SKP)
• 로그입수량을 대조
3. 로그를 양사 DIC로 송출 (Origin : SKP)
• 로그입수량을 대조
• 11st 내 로그입수 후 처리 로직을 완성 (마트생성 Workflow)
17. 데이터 입수 파이프라인 구축 - User Log
• 구버전 앱 : SKP로 송출
• 신버전 앱 : 11st로 송출
• post_action
• Origin : SKP (11st로 트래픽 복제)
• Issue : 1% 트래픽 유실
User Log
1%
SKP (커머스 IDC)
Data Infra
Cluster
Collector
rake was
11st (일산 IDC)
Data Infra
Cluster
Collector
rake
web/was
post_action
(1% 유실)
old
rake client 데이터 복제
new
rake client
User Log
99%
18. 데이터 입수 파이프라인 구축 - User Log
• post_action
• Origin : 11st (SKP로 트래픽 복제)
User Log
99%
SKP (커머스 IDC)
Data Infra
Cluster
Collector
rake was
11st (일산 IDC)
Data Infra
Cluster
Collector
rake
web/was
post_action
old
rake client 데이터 복제
new
rake client
User Log
1%
19. 데이터 입수 파이프라인 구축 - User Log
• 구버전 앱 트래픽 1% : 강제 업데이트
• post_action
• Traffic mirroring 제거
• SKP로 로그 송출 중단
User Log
99.9%
SKP (커머스 IDC)
Data Infra
Cluster
Collector
rake was
11st (일산 IDC)
Data Infra
Cluster
Collector
rake
web/was
old
rake client 데이터 복제
new
rake client
User Log
0.1%
post_action 제거
20. 데이터 입수 파이프라인 구축 - System Log
• Logagent
• 보라매IDC, 일산IDC 양분
• Mirrormaker
• 보라매 Kafka à MirrorMaker à 일산 Kafka à Collector à HDFS
Server LogAgent
보라매 IDC
일산 IDC
Data
Platform
MirrorMaker
Collector
21. Migration Plan
마이그레이션 대상 선별
- 이관 대상 : 계정/Hive DB/HDFS 목록
효율화 대상 선정
- Hive DB별 삭제 대상/ 보관주기 대상/ 유지 대상 목록
재암호화 대상 점검
마이그레이션 시나리오 수립
- 마이그레이션 프로세스 공지 및 설명회
마이그레이션 수행
24. Migration
• 마이그레이션 대상 식별 : 전체 33PB
• 데이터 Owner 대상 설명회 수행 => 전수 조사 / 사용 여부 조사
• 적극적인 참여로
• 11st 데이터만 16PB --> 10PB (40% 효율화 성공)
30PB
16PB 10PB
25. Migration
• 마이그레이션 대상별 진행방식 :
• HDFS + Hive : inter cluster distcp
• Druid
• Mysql : dump & import
• MongoDB : dump & import
• Hbase : raw data 기반으로 재 적재
• Redis : Hbase 기반으로 재 적재
• HDFS만 10PB : cluster간 Network Bandwidth = 40G
• 이론적 복제 시간 : 432TB(1day) * 80%(buffer) = 350TB
• 주요 업무시간 제외한 나머지 12시간 복제 시 소요 기간
3333TB(Usable) / 175TB(12시간) = 19일 + 5일(buffer)
• 실제 복제 기간 : 240TB(1day) = 약 14일 소요
전용선 연결 구조
SKP 11st
26. Migration
• 재 암호화 : SKP decrypt : flat data à distcp : 11st encrypt
• 고려사항 및 어려웠던 점
• One mapper per file : 하나의 파일에 쓰기 작업 매퍼가 두개 이상 접근하면 오류 발생
• distcp process중 source file이나 destination의 file 변경 일어나면 fail 발생할 수 있음
• 복제 시 block size 보존을 권장, version이 다른 경우 목적지에서 distcp를 수행함
• 11st 클러스터에서 복사하는 경우SKP의 workload를 제거할 수 있으나 (pull방식)
audit 로그를 남기기 위하여 SKP 클러스터에서 distcp를 수행함 (push방식)
• Incremental distcp X : 너무 많은 tiny job overhead à 디렉토리 단위별 단순 distcp 수행
• 네트웍 대역폭을 고려한 설정 : bandwidth 10MB/s per mapper : 전체 mapper 500
• 수십만개 파일변환으로 인한 distcp 재 작업 : non orc à orc
• Permission Error (during Query Execution)
• 모든 파티션 파일에 Owner (UID) / Group (GID) 를 일치
1 복호화
2 테이블 단위
파티션 복사
3 암호화
SKP 11st
27. Migration
• 데이터 거버넌스 - Thanos Project (저장소 효율화)
• ‘19년 9월 사용률 - 12.8/14.83 PB : 86%, 3월 9.6PB 시작 : 64%
• 월 0.3PB 증가 à 2달 후 90% 도달
“When I’m done, half of DATA will still exist.
Perfectly balanced, as all things should be.”
28. Migration
• 데이터 거버넌스 - Thanos Project (저장소 효율화)
• 데이터 압축 / 보관주기 관리 / 중단 서비스 데이터 폐기
• ‘19년 9월 사용률 (12.8/14.83 PB : 86%, 3월 9.6PB : 64% 시작)
As-Was (9월초)
→
DLM 적용 (10월)
→
DLM Frozen 적용 (11월 예정)
12.8 PB 사용률 85.62% 9 PB 사용률 60% : 삭제 용량 3.8 PB
이상 (9/26 기준)
8 PB 사용률 54% : 삭제용량 1PB
(추정)
2020년도 저장소 증설 0
= 약 6억 절약 (30대)
•2020년 10월 예상 사이즈 (월 증가량 0.3 PB)
DLM 적용 후 : 9 + 3.6 = 12.6 PB (85%)
DLM Frozen 적용 후 : 8 + 3.6 = 11.6 PB (78.2%)
Compression
Retention
Cycle
(purge)
Freezing