24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
ProxySQL is a popular database proxy for MySQL/MariaDB servers. This focuses on the possible High availability options for ProxySQL and operations of inbuilt clustering feature in ProxySQL. This tech talk was presented at Mydbops Database Meetup on 27-04-2019 by Aakash M, Database Administrator with Mydbops and Vignesh Prabhu, Database Administrator with Mydbops.
Wars of MySQL Cluster ( InnoDB Cluster VS Galera ) Mydbops
MySQL Clustering over InnoDB engines has grown a lot over the last decade. Galera began working with InnoDB early and then Group Replication came to the environment later, where the features are now rich and robust. This presentation offers a technical comparison of both of them.
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법Ji-Woong Choi
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
배민찬(https://www.baeminchan.com) 서비스의 백엔드 시스템 중 일부가 지난 1년간 어떤 고민과 아이디어, 결과물을 만들어냈는지 공유하려고 합니다. 발표 중 언급되는 용어나 도구에 대해 일반적인 정의나 간단한 설명은 언급되나 자세히 다루지 않습니다. 사용된 도구들로 어떻게 이벤트 기반 분산 시스템을 만들었는지에 대한 이야기가 중심입니다.
마이크로서비스 스타일로 만들어진 시스템을 모노리틱 스타일로 이관한 사례와 함께 스프링을 이용해 모듈형 모노리스(modular monoliths)를 만든 경험을 바탕으로 모노리틱/마이크로서비스 보다 본질적인 문제를 제기하고, 문제 해결을 위한 아이디어와 코드를 공유합니다.
https://github.com/arawn/building-modular-monoliths-using-spring
이 자료는 2019년 KSUG 세미나에서 진행한 "잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다"를 기반으로 몇가지 내용을 추가하고, 전개 방식을 다듬어 조금 더 친절하게 만들어졌습니다.
The Proxy Wars - MySQL Router, ProxySQL, MariaDB MaxScaleColin Charles
As proxies (and database routers) go, the first one I ever used was the now deprecated MySQL Proxy. Since then, I've managed to use MariaDB MaxScale quite a bit (including its fork AirBnB MaxScale), played around with ProxySQL in recent time, and also started taking a look at MySQL Router. In this quick 20-minute overview, we'll discuss why these three exist, a feature comparison, and reasons when to use the right tool for the job.
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
ProxySQL is a popular database proxy for MySQL/MariaDB servers. This focuses on the possible High availability options for ProxySQL and operations of inbuilt clustering feature in ProxySQL. This tech talk was presented at Mydbops Database Meetup on 27-04-2019 by Aakash M, Database Administrator with Mydbops and Vignesh Prabhu, Database Administrator with Mydbops.
Wars of MySQL Cluster ( InnoDB Cluster VS Galera ) Mydbops
MySQL Clustering over InnoDB engines has grown a lot over the last decade. Galera began working with InnoDB early and then Group Replication came to the environment later, where the features are now rich and robust. This presentation offers a technical comparison of both of them.
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법Ji-Woong Choi
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
배민찬(https://www.baeminchan.com) 서비스의 백엔드 시스템 중 일부가 지난 1년간 어떤 고민과 아이디어, 결과물을 만들어냈는지 공유하려고 합니다. 발표 중 언급되는 용어나 도구에 대해 일반적인 정의나 간단한 설명은 언급되나 자세히 다루지 않습니다. 사용된 도구들로 어떻게 이벤트 기반 분산 시스템을 만들었는지에 대한 이야기가 중심입니다.
마이크로서비스 스타일로 만들어진 시스템을 모노리틱 스타일로 이관한 사례와 함께 스프링을 이용해 모듈형 모노리스(modular monoliths)를 만든 경험을 바탕으로 모노리틱/마이크로서비스 보다 본질적인 문제를 제기하고, 문제 해결을 위한 아이디어와 코드를 공유합니다.
https://github.com/arawn/building-modular-monoliths-using-spring
이 자료는 2019년 KSUG 세미나에서 진행한 "잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다"를 기반으로 몇가지 내용을 추가하고, 전개 방식을 다듬어 조금 더 친절하게 만들어졌습니다.
The Proxy Wars - MySQL Router, ProxySQL, MariaDB MaxScaleColin Charles
As proxies (and database routers) go, the first one I ever used was the now deprecated MySQL Proxy. Since then, I've managed to use MariaDB MaxScale quite a bit (including its fork AirBnB MaxScale), played around with ProxySQL in recent time, and also started taking a look at MySQL Router. In this quick 20-minute overview, we'll discuss why these three exist, a feature comparison, and reasons when to use the right tool for the job.
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
Aurora MySQL Backtrack을 이용한 빠른 복구 방법 - 진교선 :: AWS Database Modernization Day 온라인Amazon Web Services Korea
발표영상 다시보기: https://kr-resources.awscloud.com/data-databases-and-analytics/aurora-mysql-backtrack%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EB%B9%A0%EB%A5%B8-%EB%B3%B5%EA%B5%AC-%EB%B0%A9%EB%B2%95-%EC%A7%84%EA%B5%90%EC%84%A0-aws-database-modernization-day-%EC%98%A8%EB%9D%BC%EC%9D%B8-2
Aurora MySQL은 기존 MySQL의 운영에 추가한 많은 기능들을 제공해 드리고 있습니다. 이 중 복구에 관련된 기능인 Aurora MySQL PITR과 Backtrack에 대한 소개를 드리고자 합니다. 두 기능을 통해 운영 중 일어날 수 있는 rollback 상황에서, 어떠한 방식으로 복구를 할 수 있는지 실습해보실 수 있습니다.
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study (임현수 플랫폼인프라실 Technical Manager, 넥...Amazon Web Services Korea
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study
이 세션에서는 넥슨의 Case study를 통하여 글로벌플랫폼 구축을 위해 기존 플랫폼을 AWS로 Migration하는 과정 및 발생가능한 이슈를 공유합니다. 넥슨이 DB서버를 이전하는 과정 속에서 마주한 기술적 고민과 이슈를 통하여 AWS 활용 시 고려해야 할 부분들에 대해 소개하고 함께 이야기 나누고자 합니다.
Cloud-Native Architecture
MSA(Micro Service Architecture)
MDA(Micro Data Architecture)
MIA(MIcro Inference Architecture)
MSA-Service Mesh
MDA-Data Mesh
MIA-AI Inference Mesh
Kubernetes
Container
Kubeflow
Volcano
Apache Ynikorn
ChatGPT
AGI(Artificial General Intelligence)
ASI(Artificial Specialized Intelligence)
초-전환시대
초-연결시대
SQream GPU DBMS
Cloud와 Cloud Native의 목표는.. 왜? 어떻게? 뭐가 좋아지나...
1. (왜) 가속화된 초-전환, 초-연결 IT 환경변화에 대비하기 위해서
2. (어떻게-H/W) IT H/W 부분은 IaaS 서비스화하여
점유된, Over Subscription된 H/W(Server, Network, Storage)들 모아서 Pool화하고, 가상화기술을 통해 Tenant로 자원들을 분리해 서비스화해 제공하고
필요시 적시에 Pool의 가상H/W를 제공하고, 상황에 따라 확장・축소(Scale in/out, up/down)하면서, 축소된 자원을 다른 요청들을 위해 빠르게 재-할당하는 유연성을 제공하고
3. (어떻게-S/W) S/W 부문도
PaaS, SaaS 적극 활용으로 App.개발 시간을 단축하고
App.분야인 기존 MACRO Service Architecture형 Monolith Architecture(Web-WAS-DB)를 작게 쪼개서 변화에 빠르게 적응할 수 있는 MSA(Micro Service Architecture)로 변경하여 Service Mesh형으로 관리하고
Data분야도 Data Warehouse, DataLake(Bigdata), LakeHouse등 기존 MACRO Data Architecture를 MSA형식으로 MDA(Micro Data Architecture)로 전환 후 Data Mesh형태로 관리하고,
AI로 동적프로그램 생성하여 App.개발시간 단축하고, AI분야도 초-거대 AI구현(MACRO)보다는 작은|특화된 Deep Learning Network(Model)들로 작게 쪼개서 MIA(Micro Inference Architecture)로 비지니스 환경에 적용하고 Inference Mesh형태로 관리하는 시스템으로 전환하고
4. (어떻게-조직) 조직구조도 CI/CD형 DevOps환경, 데이타,트랜잭션중심업무중심, 기술중심 문제해결중심, 직능중심조직직무중심조직으로 전환하면
5. (좋아지는 것) 초-전환, 초-연결 환경에 빠르고, 지속적으로 적응할 수 IT as a Product 환경을 구현하는 것
[Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | Aurora로 게임 데이터베이스 레벨 업! - 김병수 AWS ...Amazon Web Services Korea
Amazon Aurora Database는 오픈소스의 개방성과 상용 데이터베이스의 성능과 안정성을 모두 제공하는 관리형 데이터베이스 서비스입니다. Amazon Aurora Database는 처음 소개된 이후로 계속 기능을 추가하며 진화해 왔습니다. Amazon Aurora의 성능과 새롭게 업데이트된 기능들을 게임사에 적용할 수 있는 사용 사례와 함께 소개합니다.
공유 스토리지를 이용한 H/A Cluster 뿐만 아니라
Replication을 이용한 Shared Nothing H/A Cluster 제공
내장된 Application 인지형의 고가용성 기능 제공
DB에 대하여 이중으로 Check 하는 Depth 모니터링 기능
30개의 주요한 Applications 지원
마이크로서비스는 큰 애플리케이션을 독립된 API와 데이터스토어를 가진 작은 단위의 서비스로 느슨하게 결합하여, 서비스를 책임지는 자율성 높은 팀의 자동화된 배포 및 운영 관리를 통해 민첩하게 비지니스 요구를 반영하는 아키텍처 구성 방식입니다. AWS 콘테이너(Container) 서비스 및 서버리스(Serverless) 아키텍처를 이용하여 마이크로 서비스를 구현하는 방법과 이를 위한 모범 사례를 소개합니다. 1) 개별 서비스 확장, 2) API 운영 및
Detailed Information: AWS 콘테이너(Container) 서비스 및 서버리스(Serverless) 아키텍처를 이용하여 마이크로 서비스를 구현하는 방법과 이를 위한 모범 사례를 소개합니다. 1) 개별 서비스 확장, 2) API 운영 및 관리, 3) 일관된 트랙잭션 유지, 4) 서비스 자동 배포, 5) 서비스 모니터링, 6) 서비스 보안 및 인증 그리고 7) 서비스 생태계 구성 등의 다양한 이슈에 AWS를 통한 해결 방법을 알아봅니다. 특히, AWS re:Invent에서 새로 출시한 AWS Step Functions, ECS 관리를 위한 Blox, Lambda@Edge 등의 서비스와 기능을 통해 마이크로서비스를 운영 관리하는 방법을 안내해 드립니다.
본 세션에서는 Amazon의 관리형 데이터베이스 서비스(RDS) 중 기존 상용데이터베이스의 5배 성능 및 1/10 가격으로도 확장성을 보장하는 Aurora에 대한 소개 및 사용법 그리고 기존의 DB에서의 마이그레이션 방법에 대해 소개해드립니다. 10월 리인벤트를 통해 동경 리전에 Aurora를 사용가능하게 되었습니다.
Similar to [135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다. (20)
2. About ME
우육빛깔 까칠행원
from kakaoBank
절대 깨지지 않는 견고한 서비스를 지향하는 국내 최초(아마도) 은행 오픈소스 데이터베이스 엔지니어
(KT하이텔 > 티몬 > 카카오 > 한국카카오은행)
http://gywn.net
https://www.facebook.com/dongchan.sung
3. CONTENTS
1. MySQL in Banking Service
2. Stability with MySQL
3. Scale-Out
4. As an open source dba
final..
9. Q. 트래픽은 어때요?
초당 트래픽
5,000 DML, 10,000
QUERIES
10,000 DML, 20,000
QUERIES
A. 엄청 들어와요. 화들짝 놀랐어요.
1. MySQL in Banking Service
10. Q. 그래서 써도 된다고요?
금융 서비스에 잘 쓰고 있고
중요 서비스에 잘 활용되고 있고
트래픽도 엄청 많이 들어옵니다
A. 네, 쓰세요. 대신 잘 쓰셔야 해요.
(지금부터 잘 쓰기 위해 우리가 고민했던 이야기 풀어보겠습니다.)
1. MySQL in Banking Service
23. 2. Stability with MySQL
MHA
30초 이내로 데이터 유실없이 복구한다.
(Master High Availability)
24. Q. MHA 헬스 체크 및 가용성 시나리오
2. Stability with MySQL
MASTER
MHA MANAGER
Fail!
Fail!
Fail!
3초마다 마스터 DB 헬스 체크
CONNECT / SELECT / INSERT
헬스 체크 3회 실패 시, 장애 인지
페일오버 시작
1
2
3
25. Q. MHA 헬스 체크 및 가용성 시나리오(async)
2. Stability with MySQL
dead master slave1 slave2
binary log
(commit된 데이터)
relay
log
relay
log
가장 최근 변경 로그
적용 중인 변경 로그
26. Q. MHA 헬스 체크 및 가용성 시나리오(lossless)
2. Stability with MySQL
dead master slave1 slave2
relay
log
relay
log
binary log
(commit된 데이터)
가장 최근 변경 로그
적용 중인 변경 로그
27. Q. 비동기 복제이지만, 유실은 없게..
2. Stability with MySQL
31+ =
lossless
replication
MH
A
한달
내내 데이터 유실
없음
lossless replication은 relay log를 보장하고,
MHA는 relay log로 데이터 일관성을 맞춘다면?
28. Q. 하나 더 얻은 값진 효과!
DISK
2. Stability with MySQL
디스크 의존성 탈피
리플리케이션에서는
데이터 유실 없다
29. Q. 더욱더 견고한 서비스 구성을 위한 고민
Domain Failover
VIP Failover
2. Stability with MySQL
30. Q. 더욱더 견고한 서비스 구성을 위한 고민
MAST
ER
SLA
VE
SLAVE(
DR)
192.168.10.12
192.198.10.11
읽기 전용
192.198.10.11
SVC01-
READONLY.SERVICE.
IO
SVC01-
ACTIVE.SERVICE.IO
192.168.10.11
서비스 전용
192.168.10.11
2. Stability with MySQL
31. Q. 더욱더 견고한 서비스 구성을 위한 고민
192.168.10.12
192.198.10.11
SLAVE(
DR)
MAST
ERSVC01-
ACTIVE.SERVICE.IO
192.168.10.12
서비스 전용
1차 장애 극복!
192.168.10.11
2. Stability with MySQL
32. Q. 더욱더 견고한 서비스 구성을 위한 고민
192.168.10.12
192.198.10.11
MASTER(D
R)
2차 장애 극복!
SVC01-
ACTIVE.SERVICE.IO
192.198.10.11
서비스 전용
192.168.10.11
2. Stability with MySQL
33. Q. 주의할 점!
하나. 서비스 도메인의 TTL은 0으로 설정합니다.
둘. DNS 캐싱을 하지않도록, 자바 구동 옵션을 줍니다.
-Dsun.net.inetaddr.ttl=0
http://gywn.net/2017/01/install_powerdns_with_mysql_backend/
(powerDNS를 내부 정책에 따라 도입을 못했으나, 초반에 이런 식의 활용도 고민했습니다)
셋. 서비스는 되도록이면 커넥션 풀로 동작해야 합니다.
2. Stability with MySQL
36. 3. Scale-Out
Q. 스케일아웃을 왜 해야해요?
M
S S
1-
SET
5000 dml/sec
M
S S
2-
SET
5000 dml/sec
A. 서비스가 커지니까요.
37. 3. Scale-Out
Q. 스케일아웃을 왜 해야해요?
M
S S
3-
SET
5000 dml/sec
M
S S
4-
SET
5000 dml/sec
M
S S
2-
SET
5000 dml/sec
M
S S
1-
SET
5000 dml/sec
A. 장애 여파도 줄일 수 있고요.
38. 3. Scale-Out
Q. 확장의 기준은 무엇인가요?
거의 변경 없
음
사용자가 생성하는
변경이 잦거나
로그 성격 데이터
STA
TIC
DYNA
MIC
HISTORI
CAL
39. 3. Scale-Out
Q. 확장의 기준은 무엇인가요?
STA
TIC
사용자가 생성하는
변경이 잦거나
로그 성격 데이터
DYNA
MIC
HISTORI
CAL
Cache Cache Cache
‣캐시가 느리면, DB가 대처
‣DB가 흔들리면, 캐시가 대응
42. 3. Scale-Out
스토리지 엔진을 혼용하여 서버 분리예
Range Partitioning Range Partitioning
SERVICE ARCHIVE
InnoDB TokuDB
43. 3. Scale-Out
스토리지 엔진을 혼용하여 서버 분리예
TokuDB?
( http://gywn.net/2014/05/fractal-index-in-tokudb/ )
Fractal Index
- 피벗에 버퍼를 두어서, IOPS를 줄이
자.
Percona MySQL에 포함됨
기존 대비 1/8 수준으로 데이터 감소
로그 적재에 적합함
44. 3. Scale-Out
Q. 확장의 기준은 무엇인가요?
A. 데이터 성격을 보고 결정합니다.
historic
al?
static?
dynami
c?
46. 4. As an open source dba
Q. 금융에서 오픈소스로 데이터 해보니 어때요?
우리는 금융 어벤져스
(진심으로 섞인 것이 “기적”인 다문화 가정)
47. Q. 금융에서 오픈소스로 데이터 해보니 어때요?
open source
initialize
기술의 어려움 보다는
금융 레퍼런스 부재로 인한 신뢰 확보와
상용 솔루션만 고집한 문화와
때로는 공감할 수 없는 환경들이 어려워요.
4. As an open source dba
48. MORE THAN 100
BANKING DATABASE
VS
Q. 금융에서 오픈소스로 데이터 해보니 어때요?
4. As an open source dba
49. 기계에게 95% 단순 운영 업무를..
Q. 금융에서 오픈소스로 데이터 해보니 어때요?
4. As an open source dba
50. Q. 금융에서 오픈소스로 데이터 해보니 어때요?
뿐만 아니라..
4. As an open source dba