DataOps34 이벤트 기반 아키텍처(Event Driven Architecture, EDA) Event Driven Architecture시스템 구성 요소들이 이벤트와 이벤트 핸들러로 서로 소통하는 구조. 관심사를 분리해 전체적인 결합도를 낮추기 위해 사용.유연한 구조, 뛰어난 확장성이 특징추가적인 컨슈머 필요하면 구독만 추가하면 됨.구성 요소 4가지이벤트이벤트 발행자이벤트 리스너버스 (통로)Internal Event vs External EventInternal Event시스템 내 컴포넌트 간 통신목적내부 도메인 로직과 부가적인 정책을 분리하기 위해서long transaction 분리External Event시스템 간 통신카프카와 같은 이벤트 스트리밍 플랫폼, 혹은 메시지 브로커를 이용해서 처리관련 영상우아한형제들 EDA 예시(외부이벤트, 스프링)https://www.youtube.com/wa.. 2024. 5. 29. [Redis] 레디스를 메시지 브로커로 사용하기 메시지 브로커의 필요성- 여러 모듈이 서로 느슨하고 적절하게 연결시킨 구조를 선호하는데, 이떄 탄탄한 상호작용이 필요해 메시지 브로커를 필요로 한다.- 서비스 간 커넥션이 실패하는 상황은 언제나 발생할 수 있으며, 되도록 비동기 통신하는 것을 권장한다.- 메시지를 어딘가에 쌓아 둔 뒤 나중에 처리할 수 있는 채널을 만들어 주는 것, 이것이 메시지 브로커의 핵심 역할이다. 메시지 브로커 타입1. 메시징 큐- Producer: 데이터를 생성하는 쪽- Consumer: 데이터를 수신하는 쪽 2. 이벤트 스트림- Publisher: 데이터 생성- Subscriber: 데이터 조회 이벤트 큐 vs 이벤트 스트림1. 방향성- 메시지 큐는 생산자가 소비자 큐로 데이터를 직접 푸시. 2곳에서 필요하면 생산자는 2곳으.. 2024. 5. 27. [Redis] 5장. 레디스를 캐시, 세션으로 사용하기 TL;DR레디스는 캐시, 세션 용도로 사용되며 캐시는 데이터 저장소의 서브 셋, 세션은 정해진 시간동안 저장되는 정보라는 차이점이 있다.레디스는 평균 읽기 및 쓰기 작업 속도가 1ms이기 때문에 성능 개선이가능하며, 데이터베이스 커넥션 I/O 를 줄여 CPU, 메모리 리소스를 줄일 수 있다.장애 대응 기능을 갖춘 고가용성 솔루션이며, 스케일 아웃을 지원한다.캐시데이터의 원본보다 더 빠르고 효율적으로 액세스할 수 있는 임시 데이터 저장소효과적인 케이스원본 데이터 저장소에서 원하는 데이터를 찾기 위해 검색하는 시간이 오래 걸리거나, 매번 계산을 통해 데이터를 가져오는 것쓰기보다 읽기에 특화된 데이터인 경우캐시에 저장된 데이터가 잘 변하지 않는 데이터인 경우캐시에 저장되는 데이터가 자주 검색되는 데이터인 경우.. 2024. 5. 8. [Redis] 4장. 레디스 자료 구조 활용 사례 실시간 리더보드배경리더보드: 경쟁자들의 순위와 현재 점수를 보여주는 순위표절대적 리더보드모든 유저를 정렬시켜 상위권만 표시하는 것을 absolute leaderboard 라고 함상대적 리더보드사용자마다 다른 데이터를 보여줌구로 직장인 대상 순위필요상대적 리더보드의 경우 다양한 관점에서 데이터 계산하고 통계 내야하기 때문에 여러 가지 수학적 계산이 빠르게 수행되어야 함관계형 데이터베이스 사용할 경우 항상 정렬해서 가져와야 한다.해결Sorted set 은 항상 정렬해서 저장하기 때문에 매번 정렬할 필요가 없다.ZUIONSTORE로 스코어 합한할 수 있음특정 SET 에 가중치 줄 수 있음최근 검색 기록배경최근 검색 기록유저별로 다른 키워드 노출검색 내역은 중복 제거가장 최근 검색한 5개 키워드만 사용자에게 노.. 2024. 5. 5. [Redis] 3장. 레디스 기본 개념 TL;DRRedis는 range 검색할 때 end index 를 포함함String최대 512MBBinary-safe 하게 처리되어 이ㅁ지 같은 바이트 값 등 다양한 데이터 저잦ㅇ 가능key-아이템 1대1 연결되는 유일한 자료 구조 → 나머지 자료 구조를 보면 된다커맨드SETOptionsNX: 키 없는 경우XX: 키 이미 있는 경우GETINCR, INCRBY, DECR, DECRBY원자적으로 처리 가능Race condition 방지타이밍 순서에 따라 요청 무시됨SET hello wolrdGET helloList순서를 가지는 문자열 목록최대 12억개스택, 큐로 사용된다특징LPUSH, RPUSH, LPOP, RPOP 커맨드는 당연 O(1)인덱스 들어가면 O(n)커맨드추가LPUSH, RPUSHLINSERT데이터.. 2024. 5. 5. [Kafka] 컨슈머 그룹 - 토픽 컨슘 관계(?) 삭제 컨슈머 그룹과 특정 토픽의 구독 관계를 끊고 싶은 경우가 있을 수 있다.unsubscribe(구독 토픽 목록에서 제외) 한다고 컨슘 이력, 관계가 사라지는 것이 아니기 때문에 lag은 계속 쌓이게 된다. 만약 모니터링 도구에서 이를 구별하지 못한다면 lag 이 해소되지 않는 상황이라 판단할 것이고 지속적으로 alert 이 발생하게 된다.1. 컨슈머 그룹 삭제컨슈머 그룹에 속한 멤버를 모두 죽인 뒤 컨슈머 그룹 삭제하는 방법.토픽 메시지를 처리 중이던 컨슈머 그룹은 삭제할 경우 오프셋 날라가서 문제 생길 수 있음 → 되도록 지양하는 것이 좋아보임2. 컨슈머 그룹 토픽 오프셋 삭제컨슈머 그룹에 속한 멤버를 모두 죽이고, 특정 토픽에 대한 오프셋 날리는 방법kafka-consumer-groups \ --.. 2024. 5. 2. [MySQL] MySQL 성능 개선 - 압축 MySQL 압축 기능에 대해 알아본다. DB 성능 개선 방법DB 성능을 개선하는 방법은 여러가지가 있다. 이번에는 인덱스에 이어 압축에 대해 알아보자.인덱스파티셔닝비싼 장비압축기타아래는 압축 테이블 생성 SQL이다. InnoDB, ROW_FORMAT, KEY_BLOCK_SIZE 와 같은 옵션이 있는데 이 글이 끝나면 이해 될 것이다. CREATE TABLE `log` ( ...) ENGINE=InnoDB AUTO_INCREMENT=159282952 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC KEY_BLOCK_SIZE=8 COMMENT='로그' 복습https://mystudylab.tistory.com/162디스크는 매우 느리다.논리적 저장 단위. 배경지식 1: 압축압축이란?.. 2024. 4. 25. [Redis] 1장. 마이크로서비스 아키텍처, NoSQL, 레디스 개발자를 위한 레디스 책 공부NoSQL 등장개요소프트웨어의 핵심은 데이터이며, 데이터 저장소는 애플리케이션의 성능과 확장성, 가용성, 신뢰성과 직접적으로 연관을 갖는다.트렌드가 마이크로서비스 아키텍처로 변화하면서 데이터 저장소 특징 역시 다양하게 발전하고 있다.Monolith vs Microserivces모놀리틱 아키텍처단일 모듈로 구성된 아키텍처 (모든 기능이 하나의 서버에 몰려있다)작은 규모에 적합단점하나의 모듈 수정하면 전체 다시 빌드 및 배포 → 빌드 시간 늘어남트래픽, 트랜잭션 요구사항에 유연하게 대처 불가프레임워크, 언어 변경이 전체 애플리케이션에 영향 끼침작은 기능 변경하는 것도 민첩하게 대처하기 어렵다. 업데이트와 릴리즈가 느려짐마이크로서비스 아키텍처.. 2024. 4. 17. [MySQL] MySQL 성능 개선 - 인덱스, 실제 개선 사례 맥락 공유상황4월 인보이스 발행 과정에서 DB에 부하가 발생하고 있는 것을 확인함.AWS Performance Insight 라는 모니터링도구를 통해 문제되는 쿼리를 발견함. (과거 인보이스 조회하는 쿼리)인보이스에 인덱스 추가하여 부하 문제 해결하고 성능 개선하는 이슈를 진행함.결론 (인덱스 적용 후)DB 부하 문제 해결.13분 넘게 걸리던 인보이스 발행 성능을 1분 30초 정도로 개선. 1. 쿼리 성능 저하 원인쿼리 느린 이유 -> 디스크 I/O디스크에서 파일을 가져오는 건 매우 비효율적이고 느린 작업.병목으로 작용하는 디스크 I/O를 개선하기 위해 활용하는 것이 캐시나 인메모리 DB성능 저하 원인 -> 디스크 I/O 부하 증가Block(Page): 데이터.. 2024. 4. 10. [Elasticsearch] 8. 엘라스틱서치의 내부 동작 상세 개요 데이터 읽기와 쓰기 작업 요청 들어왔을 때 엘라스틱서치 내부가 어떤 단계를 거쳐 동작하는지 살펴본다. 어떻게 요청의 동시성 제어를 하는지? 샤드에 문제가 생겼을 때 어떻게 복구되는지 8.1 엘라스틱서치의 데이터 분산 처리 과정 8.1.1 쓰기 작업 시 엘라스틱서치 동작과 동시성 제어 쓰기 작업의 3단계 1. 조정 단계(coordination stage) 2. 주 샤드 단계(primary stage) 요청을 넘겨받은 이후 수행하는 작업들 in-sync 복제본 마스터 노드가 관리하는 작업을 복제받을 샤드 목록 주 샤드는 in-sync 복제본에 병렬적으로 요청을 넘긴다. 모든 복제본들이 작업을 성공적으로 수행하고 주 샤드에 응답을 돌려주면 주 샤드가 작업 완료 응답을 보낸다. 3. 복제 단계(replic.. 2024. 4. 3. 이전 1 2 3 4 다음
