책 추천 할 거 운영체제, 대규모 시스템 설계 기초, 데이터 중심 애플리케이션 설계, 자바의 정석
홍보: 카카오톡 방, 슬랙, 인스타
스타트업에서 데이터를 허투로 버리지 않고 모시는 방법 - 김정우 rokag3-gb.github.io
애플리케이션은 목표가 있어야 한다.
데이터의 중요성
데이터는 종류와 출처가 다양하다.
출처에 맞게 데이터를 사용해야 한다.
사람들 행동도 다 데이터로 가져간다.
이 데이터로 고객의 니즈를 파악해 상품을 제작한다.
ERP 프로그램 요청처리 현황 차트를 제작함
조직이 제대로 운영되고 있는가?
기준을 정해 데이터를 처리한다.
데이터 엔지니어링 기술
결국은 데이터를 가지고 가공해서 이를 이쁘게 보여줘야 함
어떤 기술이 중요하고 써야 하느냐
제가 좋아하는 장표: 구글 클라우드 데이터 플랫폼 생태계
data ingestion - data processing - machine learning - insights & activation
금융권 정보계 시스템
금융 & SI 도 --계 라는 말을 많이 쓴다.
사용자 행동 예측 -> 반응
OnLine Transaction Processing, 네이버에서 쇼핑
많은 양의 손님이 조회
빠르게 응답을 위해서 정규화를 빡세게
적당히 최적화해서 처리
간단한 CRUD
현재 데이터가 중요
OnLine Analytical Processing, 데이터 수집 및 분석을 목적함
소수의 몇 명으로 집계 연산을 함
적절히 사용하기 위해 그냥 반정규화
빠르게 최적화해서 보여줘야 함
복잡한 조회와 집계
과거 데이터가 중요
Data ingestion 또는 ETL(추출 -> 적재 -> 불러오기)
해당 서버 장비에 많은 cpu와 메모리를 사용함
데이터를 잘 가져올 수 있는 방법을 얘기함
빅데이터 처리 기술
데이터 정제
변환
필터링
통합
축소
데이터 분석을 위해 개발언어, 라이브러리, 데이터 웨어하우스
데이터 시각화
시각화를 위해서 태블러우, 클릭, 파워 비, 그라파나
로깅 시스템 구축이야기
고객에게 데이터를 보여줄 수 있는 사이트를 만들어라
계정만 보면 적당히 애플리케이션을 만들었음
여러명이 하다 보니 로깅이 안됨.
인증이 안됨
파이어베이스에도 로깅시스템이 있음.
관측성은 시스템 또는 애플리케이션의 출력, 로그, 성능 메트릭을 검사하여 상태를 모니텅링, 측정 파악할 수 있는 정도, 가능성을 의미한다.
현대화된 소프트웨어 시스템과 클라우드 컴퓨팅에서 관측성은 애플리케이션과 인프라의 ㅅ니뢰성, 성능, 보안을 보장하는 데 있어 역할이 매우 중요하다.
마이크로 소프트아키텍쳐
여러 호스트의 성능 메트릭은 클라우드 콘솔에서 확인한다.
각 애플리케이션 마다 로깅 데이터를 어딘가로 퍼올리는 추가 개발이 필요한 상황이다.
(하나 하나 다 짜줘야 해!)
모든 클라이언트의 요청이 모이는 api 게이트웨이 서버에서 로그를 수집하는 것이 효율적이라 판단한다.
고랭 게이트웨이 서버(살려줘...)
fluentd는 데이터 쉽핑을 제공하는 일종의 로그 스템시
고랭 게이트웨이 서버 -> 블롭 스토리지 로그 파일을 업로드 -> 마소 sql 서버로 이동
JSON 처리
질문
DB에서 개인정보가 다른 곳으로 가능성이 있는 데 이를 막기 위해 어떤 일을 하는 지
데이터 해외 반출 금지에 대한 조항이 있는 것으로 아는 데 해외 리전에 저장하는 방식에 불이익은 없는지
대용량 트래픽에도 견고한 데이터베이스 구축하기 - 강성욱
인프라 관련 내용
아키텍처 관점에서 설명입니다.
기본 개념을 위주로 설명한다.
DB 튜닝과 관련된 내용은 다루지 않는다.
특정 환경에서 작동한 사례임
Monolithic architecture 단단히 짜여 하나로 된 아키텍쳐
MSA
뭐가 더 좋은 지 때에 따라 다르다.
죽으면 문제가 되는 건 확실
단일 장애 지점 Single Point of Failure
시스템 아키텍처에 따라 단일 장애지점은 모두 다름
단일 지점의 문제점을 보완하여 내구성을 강화
비용과 시간에서 최적화
방법 1. scale up (vertical 업그레이드)
방법 2. scale out (horizon 옆그레이드)
클라우드라면 이런 설계가 가능하지 않을까?
subnet은 오토 스케일링은 가능하지만? DB는?
부하를 분산하고 부하를 해결해도 크기는 정해져있다.
물리적 데이터 저장
디스크 사이즈가 크고 데이터 재배치 작업 오버헤드를 해야 되고 트랜잭션 보장하고 커넥션 요청 관리를 해야 한다.
가용성 확보를 하는 법
replication: primary secondary model (데이터 복제)
sharding: distribute model (데이터 분산 저장)
복제의 장단점
장점: db 장애가 발생해도 데이터 유실 없음
마스터와 스탠바이 역할 교체러 중단없는 서비스 가능
읽기 부하분산으로 처리량 향상
단점: 데이터 정합성 문제
시스템 구성을 위한 예산 비용 증가
애플리케이션에서 분기 기능이 필요
샤딩의 장단점
장점: 스케일 아웃이 가능
스캔 범위를 줄여서 쿼리 반응속도를 빠르게 함
장애가 샤드 단위로 발생함
단점: 프로그램 복잡도가 증가
데이터가 한쪽 샤드로 몰릴 경우 샤딩이 불리해짐
잘못 사용할 경우 리스크가 큼 (샤딩 키 주의)
한 번 샤딩 구성시 샤딩 이전의 구조로 돌아가기 힘들다.
일반적이 ㄴ복제 환경에서 대용량 트래필 요청 대응하기
부하를 잘 받기 위해 커넥션!
connection pool을 사용하지 않는다.
사용자 요청시마다 db에 커넥션을 시도하기 때문에 드라이버에서 커네션을 할당 받기 위한 시간 오래 걸린다.
db에서 커넥션을 할당하기 위한 리소스 오버헤드 발생
한 배를 타냐 여러 배로 나누어서 타냐
단순히 시간만 걸리지 않고 cpu 할당이 높음
connection pool을 사용한 연결
일정 개수의 커넥션을 만들어 놓고 풀에서 가져다 사용하면서 드라이버에서 커넥션을 할당받기 위한 시간 단축
db에서 커넥션을 할당/회수 인한 리소스 오버헤드 감소
pool에 대한 적정량을 선택해야 한다.
주기적으로 확인을함 막상 죽으면 에러남
JDBC에서 부하를 분산하기 위한 코드 작성이 필요하다.
어플리케이션에서도 write와 read를 잘 분리해야 한다.
그렇지 않으면 트래픽이 하나로 뭉쳐진다.
그런 줄도 모르고 db를 스케일을 늘려도 똑같은 경우가 있음.
요청수에 따른 커넥션 개수 문제가 있다.
무작정 api 서버만 늘리면 안된다.
컨테이너당 사용하는 리소스에 따라서 달라짐.
그냥 커넥션 자체가 많아지면 힘들어짐.
세션 관리를 하는 데 커넥션을 꺼도 반환하는 리소스도 만만치 않음.
미친 회선이 죽었어.
디비가 죽어버리면?
디비에 크래시가 발생함.
db는 무중단임.
무조건 서비스 중단이 발생함. 잠깐 그럼
만약 db가 추가 되면?
인식을 못하면 새로 추가된 db에 데이터를 가져올 수 없음.
프록시를 도입하여 커넥션 처리를 대신한다.
커넥션 멀티플레싱
쿼리 룰
어디서나 배포
네이티브 패스워드가 있는 경우도 없는 경우도 있는 계정으로 오류가 있는 경우가 있음
db 같은 경우 한 번 털리면 ㅈ됨. -> 개발 서버 털리면 ㅈ됨.
id pw 알려주기 싫음 그래서 프록시 서버를 제공함.
db 분산을 한다.
부하 분산을 해서 모니터링을 할 수 있다.
프록시sql도 핑 테스트를해서 살아잇는 상태에 따라서 디비를 연결할지 말지 결정함.
proxysql 서버가 장애나면 어떻게 되나요?
mysql 서버에서 장애가 발생하면 장애 조치가 자동으로 되나요?
- proxysql을 클러스터로 구성한다. (멀티 플렉싱을 사용한다.)
- orchestrator를 사용하여 자동 페일 오버 구성을 한다.
- mysql galera clust + proxysql rnc
proxysql을 활용한 다양한 구성 방법
사례
one proxysql instance / application server
multiple proxysql hosts
silos approach (너무 잘게 쪼게 놓은 것 같아)
silos + multi-layers (db 오기 전에 부하가 찬거임.)
keepalived + VIP
multi-layer + keepalived + VIP + LVS
요약
가용성을 위한 데이터 복제는 mysql 기본 복제 기능을 사용
커넥션 관리 및 부하 분산을 위해 proxysql을 함께 사용
mysql자애시 자동 페일 오버를 위해 오케스트레이터 조합 가능
proxyslq장애 및 부하 방지를 위해 다양한 구성을 사용.
정리
아키텍처에는 정답이 없다.
문제르 ㄹ제한된 리소스에서 해결할 수 있는 것이 가장 좋으 ㄴ아키텍처이다.
아키텍처 설계를 위한 각 파트의 솔루션에 대한 특징을 이해 해야 한다.
비슷한 것 같지만 한 끝 차이로 전혀 다른 목적을 가지는 솔루션이 될 수 있다.
질문
1. DDoS와 같이 분산 공격을 이용하여 requests를 하여 DB에 무리를 줄 때 어떻게 고가용성으로 처리할 수 있을까요?
1. 앞 단에서 막아함. idc에서 회선사용하는거 흘려주세요 요청 -> 계속 떠돌아. 대책이 없음.
급의 트래픽이다? 배민에서 치dos 치킨 트래픽이 올라가 블로그에 써놨음 예측할 때는 올려놓고
read 쪽은 읽기만 write도 복잡하면? read를 성능을 높이고 write는 scale up read는 리플리카. 디도스는 고속도로를 막는 거임.
2. Connection create 방식과 Connection Pool 방식은 구체적으로 어떻게 다른 건가요?
1. 요청이 올 때 마다 하는 게 create
2. 기다려봐 만들어 줄게 pool
3. 데이터 수집에 관련된 사항이 개인정보 처리 방침에 자세히 적혀있을 건데, 이를 모두 숙지한 상태로 작업 하시나요?
1. 안 그럼 회사 문 닫아요. 그래서 법무팀이랑 같이 법을 공부함.
기타
DB의 구조를 살펴봐야 한다.
주로 유저의 행동을 통해 예측을 한다. (백트래킹)
여담
저희 전공동아리 부원들도 같이 데려와서 참여하고 남는 시간 동안 재미있게 놀아 왔습니다.
맨 아래가 저입니다.
