티스토리

will.log
검색하기

블로그 홈

will.log

willseungh0.tistory.com/m

seungh0 님의 블로그입니다.

구독자
28
방명록 방문하기

주요 글 목록

  • Spring Data Cassandra save vs insert 동작 차이 Spring Data Cassandra의 save vs insert 동작 차이에 대해서, 간단히 정리해 본 내용입니다. 1. save vs insert 실행 결과 비교테이블 및 코드 설정테스트 할 sample 테이블과 코드는 다음과 같습니다create table sample( id text primary key , value1 text, value2 text);@Table(value = "sample")data class Sample( @PrimaryKey val id: String, var value1: String?, var value2: String?,)interface SampleRepository : CassandraRepository 1-1. Save 테스.. 공감수 0 댓글수 0 2024. 7. 11.
  • Cassandra DB Collection Type 사용시 주의 사항 (v4.0 미만 한정) 테이블 구조create table `test`( partition_key text, target text, subscriber text, extra map, primary key (partition_key, target, subscriber)); 쿼리select partition_key, target, subscriber, extra from test where partition_key = '1158' and target = '1' and subscriber in ('1', '2');Collection Type이 있는 경우 IN QUERY 시 위와 같은 에러가 발생함.Cassandra DB 4.0 부터 .. 공감수 0 댓글수 0 2024. 5. 15.
  • Cassandra DB LWT 동작 방식 (+동시성 이슈 해결기) 푸시 쪽 개선을 위해서, 푸시 플랫폼에서 푸시 발송 시 특정 데이터 정보가 필요했습니다.그 특정 데이터는 다른 플랫폼에 있는 데이터로 데이터 특성상 푸시 발송시 해당 플랫폼으로부터 실시간으로 데이터를 조회하는 경우, 너무 많은 요청이 해당 플랫폼으로 가게 되었습니다.이러한 이유로 해당 데이터를 푸시 플랫폼으로 이벤트 파이프라인을 구성해서 사본 데이터를 저장하는 식으로 방향을 정했고, Cassandra DB의 특정 테이블에 저장해 두는 식으로 정하였습니다.별도의 저장소에 사본 데이터를 저장하는 경우, 추가적인 저장소가 필요 & 푸시 발송시 추가적인 랜덤 액세스 형태의 읽기 비용이 필요해서, 발송 속도에 영향을 줄 수 있음 상황 설명 (각색)실제 상황으로 상황을 설명하기 문제가 있을 수 있어, 전혀 다른 내.. 공감수 1 댓글수 0 2024. 5. 15.
  • Cassandra DB 성능 개선기 (1) - Read ahead와 Disk I/O 회사에서 플랫폼을 운영하면서 겪은 장애와 개선한 점들을 공유해보려고 합니다.Cassandra DB를 운영하면서 발생한 이슈이지만, 내용이 Cassandra DB에만 국한되지 않는 내용인 점 먼저 말씀드립니다.장애 발생플랫폼을 운영하던 중, 급격하게 증가하는 데이터로 인해 요청이 밀리는 장애가 발생하였습니다.평소 한자리 ms의 Latency로 API를 제공하던 중, 갑자기 요청을 처리하기 위한 Latency가 100ms 이상으로 밀려버리는 장애가 발생하였습니다.빠르게 데이터를 서빙해야하는 데이터 플랫폼 특성상, 낮은 Latency로 데이터를 제공해야 합니다.장애 원인장애 원인은 Disk I/O 사용량 (Disk Usages이 아닌, Disk I/O Usages입니다) 급증으로 인해서 Disk IO이 병목이.. 공감수 3 댓글수 2 2024. 4. 22.
  • [CassandraDB] 무중단 CassandraDB 클러스터 이전 방법 (멀티 데이터센터 구성) 회사에서 직접 운영하고 있는 Cassandra DB 클러스터 이관 등의 작업을 진행하였는데, 관련 방법들에 대해서 정리한 내용입니다.참고로, 팀 내에서 운영하고 있는 여러 플랫폼의 메인 저장소로 CassandraDB를 운영하고 있으며, CassandraDB의 경우 별도의 DBA가 없어 팀 내에서 직접 운영하고 있습니다.카산드라 클러스터 이관을 위해서 멀티 데이터센터를 구축해서 이전하는 방법으로 클러스터를 이전하였습니다.- 아래 예시들은 기존 데이터 센터를 dc1, 신규 데이터 센터를 dc2로 가정하고 작성되어 있는 점 참고 바랍니다.이관 전 사전 체크 사항Cassandra DB 설정 SnitchSimpleSnitch인 경우 단일 DataCenter를 위한 Snitch로, 멀티 데이터 센터 사용을 위해선 .. 공감수 0 댓글수 0 2024. 4. 12.
  • 가슴속 3천원 사이드 프로젝트 운영기 안녕하세요. 가슴속 3천원 백엔드 개발자 강승호입니다.가슴속 3천원은 본업과 별도로 개인 공부 목적으로 진행하고 있는 사이드 프로젝트입니다.가슴속 3천원 같은 초기/소규모 서비스를 지속적으로 운영하기 위해서 해온 것들을 공유하고, 초기부터 서비스를 운영하면서 발생했던 문제점들을 해결해 온 내용들을 몇가지 공유드려보고자 합니다. 1. 가슴속 3천원 소개가슴속 3천원은 주변의 붕어빵 등 길거리 음식/푸드트럭 파는 곳을 알려주는 서비스로, 겨울철만 되면, 생각나는 “붕어빵”을 파는 곳이 어딘지 알고 싶어서 만든 앱 서비스입니다.(앱 다운로드는 아래 링크에서 하실 수 있습니다~)AppStore (ios)PlayStore (android) 가슴속 3천원은 팀원 전체가 본업과 별도로 진행하는 사이드 프로젝트라 프로.. 공감수 17 댓글수 4 2024. 2. 25.
  • CassandraDB 버전 별 G1GC 기본 설정 정리 Cassandra 버전별 JDK 지원 범위 (JDK 8 ~ 17) Cassandra 3.1: JDK 8 Cassandra 4.0: JDK 8, 11 Cassandra 4.1: JDK 8, 11 Cassandra 5.0: JDK 11, 17 G1GC Settings 현황 Cassandra 3.1: CMS(default), G1GC Cassandra 4.0: CMS(default), G1GC Cassandra 4.1: CMS, G1GC (default) 제공되는 G1GC 설정 값들 강화되었음 Cassandra 5.0: G1GC (default) Cassandra G1GC 세팅값 정리 JDK 11 1. Cassandra 4.0 ### G1 Settings ## Use the Hotspot garbage-fir.. 공감수 0 댓글수 0 2024. 2. 19.
  • CassandraDB Snapshot Cassandra SnasphotCassandra DB에서 기본 설정 상 truncate or Drop 전에 Snapshot을 만든다. (cassandra.yml의 auto_snapshot 설정으로 default: true이다) 그래서, Truncate 및 Drop을 했는데, 실제 디스크 사용량이 줄어들지 않아서, 해당 데이터를 디스크에서 완전히 삭제하려면, Snapshot도 제거해야 한다.cf) 위의 케이스 이외에도 설정에 따라서 compaction, increment_backup 등에 의해서도 snapshot이 생성될 수 있음. 스냅샷 제거 방법./nodetool clearsnapshot --all--all: 모든 키스페이스에 속한 모든 스냅샷 제거./nodetool clearsnapshot --al.. 공감수 0 댓글수 0 2024. 2. 19.
  • 리액티브 시스템 & Reactive Streams 정리 reactive: 어떤 이벤트나 상황이 발생했을 때, 반응을 해서 그에 따라 적절하게 행동하는 것. 리액티브 선언문 방법 메시지 구동: 리액티브 시스템에서 주요 통신 수단으로 비동기 메시지 기반의 통신을 통해 구성 요소들의 느슨한 결합, 격리성, 위치 투명성을 보장. 형태: 탄력성 시스템의 작업량이 변화하더라도 일정한 응답을 유지하는 것. 시스템으로 유입되는 입력이 많든 적든 간에 시스템에서 요구하는 응답성을 일정하게 유지하는 것. 회복성 시스템에 장애가 발생하더라도 응답성을 유지하는 것 이러한 회복성을 확보하기 위해, 리액티브 시스템의 구성요소들은 비동기 메시지 기반 통신을 통해 느슨한 결합과 격리성을 보장. 값 응답성 비동기 메시지 기반 통신을 바탕으로 한 회복성과 탄력성을 확보함으로써 즉각적으로 응.. 공감수 1 댓글수 1 2024. 2. 3.
  • RedHat 계열 리눅스에서 default jdk 버전 변경 방법 JDK 8 -> JDK 11 변경 방법 (RedHat) 1. Install JDK 11 sudo dnf install java-11-openjdk-dev 2. 현재 환경 변수가 JDK 8을 바라보고 있음 java -version openjdk version "1.8.0_332" OpenJDK Runtime Environment (build 1.8.0_332-b09) OpenJDK 64-Bit Server VM (build 25.332-b09, mixed mode) 3. JDK 11 -> JDK8 버전 변경 (default java version 변경) sudo /usr/sbin/alternatives --config java ---- There are 2 programs which provide 'jav.. 공감수 0 댓글수 0 2024. 2. 2.
  • Cassandra Column이 마지막으로 쓰인 시간 보는 방법 select writetime({{VALUE}}) from {{TABLE} where key1 = {{KEY1} and key2 = {{KEY_2}}; primary key는 조회할 수 없고, value 만 가능함. writetime()으로 해당 컬럼이 마지막으로 쓰인 시간을 조회합니다. (컬럼 단위임) 데이터 변경되면 변경된 시간으로 변경됨 (정확히는 변경이 아니라, Cassandra 구조인 LSM Tree 동작 방식 상, append only형태로 구성되니 변경이 아니고, 신규 컬럼이 써지는 형태임 공감수 0 댓글수 0 2024. 2. 2.
  • [Cassandra] 테이블 단위 tombstone 최소 유지 시간 설정 변경 방법 alter table {{TABLE}} with gc_grace_seconds = 864000; # 10일 (default) 공감수 0 댓글수 0 2023. 9. 23.
  • [Cassandra] 노드 임시 중지/영구 제거/재 추가 방법 노드 임시 중지 (서버 점검 및 재시작 등) nodetool drain 이 명령어는 노드를 일시적으로 비활성 상태로 만들어 클러스터에서 안전하게 제거하지 않고도 유지하는 데 사용됩니다. 일반적으로 노드의 유지 보수 작업이나 장애 복구 작업 중에 사용됩니다 노드가 클러스터에서 쿼리 요청을 받지 않도록 하기 위해 읽기 및 쓰기 요청을 중지합니다. 노드가 다른 노드로부터 데이터를 받거나 복제하지 않도록 하기 위해 데이터 전송을 중지합니다. 노드가 클러스터와의 연결을 끊기 전에 남아 있는 쓰기 작업을 완료합니다. nodetool drain 명령어를 실행한 노드는 클러스터에서 제거되지 않고 유지됩니다. 이후 다시 활성화되거나 유지 보수 작업 완료 후 정상적으로 작동할 수 있습니다. 노드를 클러스터에서 영구 제거 .. 공감수 0 댓글수 0 2023. 9. 23.
  • [Cassandra] 언제 Minor Compaction이 일어날까? Compaction에 대한 내용은 다루지 않음. Cassandra Compaction 종류 Minor Compaction: 카산드라에서 자동으로 트리거링 해주는 컴팩션. Major Compaction: 수동으로 노드 내의 모든 SSTable을 대상으로 컴팩션을 실행 User Defined Compaction: 특정 SSTable 들을 대상으로 수동으로 컴팩션을 실행. UpgradeSSTables: SSTable들을 최신 버전으로 업데이트함. CleanUp: 해당 노드가 소유한 범위에 더이상 포함되지 않는 대상들을 제거. 노드을 증설하면, 리밸런싱이 일어나는데, 증설 이후, 기존 노드들에서 cleanup을 때려줘야 불필요한 데이터들이 삭제됨 등이 있다. Minor Compaction 트리거링 시점 이중 카.. 공감수 0 댓글수 0 2023. 9. 23.
  • [Cassanrda] tombstone 수동 제거 방법 Cassandra Tombstone(이 마킹된 데이터)들을 수동으로 제거해야하는 일이 있었음.수동 처리 방법 nodetool garbagecollect GC를 통해서 삭제된 데이터를 수동으로 삭제하는 기능 테스트 해보니, CPU 및 Disk IO 부하가 꽤 있는 것으로 보임.클러스터내에서 해당 명령을 실행한 노드에서만 garbagecollect가 일어남.안전하게 처리하기 위해서, garbagecollect를 실행할 노드를 서비스에서 제외하고, 처리하기로 함.주의 사항Tombstone의 최소 유지시간인 gc_grace_seconds 만큼 Tombstone(데이터)을 최소한 유지해서, 수동으로 톰스톤을 지우더라도 해당 시간만큼 지나지 않은 톰스톤(데이터)들은 제거되지 않는다. 공감수 0 댓글수 0 2023. 9. 23.
  • Cassandra DB에서 COUNT 쿼리가 위험한 이유.. 내부적으로 N개씩 (Paging 설정으로 변경 가능하며, default 100) 커서 조회로 파티션을 풀 스캔함..) 파티션 키로 필터링 조건으로 조회한다면, 파티션 기준으로 풀 스캔하고, 파티션 필터링 조건조차 없다면, 모든 파티션을 풀 스캔한다… 동작방식에서 알 수 있다시피, 파티션 크기가 점점 커질수록, 카산드라에 많은 부하를 유발하니 사용하지 말자.. 만약 테이블 기준 전체 카운트를 알아야 한다면, nodetool tablestat (Number of keys, estimate)에 나오는 로우 추정 갯수를 통해 확인할 수 있다. https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/tools/toolsTablestats.html nodetool ta.. 공감수 0 댓글수 1 2023. 5. 24.
  • k8s HPA 동작 방식 및 이슈들 정리 HPA (Horizontal Pod AutoScaling) 도입 배경운영하는 플랫폼이 버스트성으로 들어오는 트래픽들이 많고, 점점 많아질 예정이어서 이러한 버스트성 트래픽을 k8s 환경에서 효율적으로 대응하기 위해서 HPA을 검토하였음. HPA (Horizontal Pod AutoScaling) 이란?Workload Resource를 자동으로 업데이트 하며, 워크로드의 크기를 수요에 맞게 자동으로 스케일링하는 것을 목표로 함.즉 k8s에서 AutoScaling의 역할을 수행. HPA 동작 방식 k8s는 HPA을 간헐적으로 실행되는 컨트롤 루프 형태로 구현했다. 이 말은 지속적으로 모니터링해서 워크로드를 변경하지 않고, 주기(default 15초)별로 체크하는 형태. 각 주기마다, Controller Ma.. 공감수 0 댓글수 0 2023. 5. 16.
  • Thread/Heap dump 뜨는 법 jps -v java PID 확인 후 Thread Dump jstack {{PID}} > {{경로}}/thread-dump.txt heap dump jmap -dump:live,format=b,file={{경로}}/{{파일명}}.hprof {{PID}} 공감수 0 댓글수 0 2023. 4. 19.
  • 카프카 컨슈머와 그룹 코디네이터 컨슈머 오프셋 관리 컨슈머의 동작 중 가장 핵심은 오프셋 관리. 오프셋이란 메시지의 위치를 나타내는 위치 컨슈머는 카프카에 저장된 메시지를 꺼내오는 역할을 하기 때문에 컨슈머가 메시지를 어디까지 가져왔는지를 표시하는 것은 매우 중요. 컨슈머 그룹은 자신의 오프셋 정보를 카프카에서 가장 안전한 저장소인 토픽에 저장. __consumer_offsets 토픽에 각 컨슈머 그룹별로 오프셋 위치 정보가 기록됨. 모든 컨슈머 그룹의 정보가 저장되는 __consumer_offsets 토픽은 파티션 수와 리플리케이션 팩터 수를 갖고 있으며, 내부 토픽이지만 파티션 수와 리플리케이션 팩터수는 브로커의 설정 파일인 server.properties에서 변경 가능. offsets.topic.num.partitions (기본값.. 공감수 0 댓글수 0 2023. 4. 5.
  • 카프카 프로듀서 파티셔너 카프카의 토픽은 성능 향상을 위한 병렬 처리가 가능하도록 하기 위해 파티션으로 나뉩니다. (최소 하나 또는 둘 이상의 파티션) 그리고 프로듀서가 파티션으로 전송한 메시지는 해당 토픽 내 각 파티션의 로그 세그먼트에 저장된다. 따라서 프로듀서는 토픽으로 메시지를 보낼 때 해당 토픽의 어느 파티션으로 메시지를 보내야 할지를 결정해야 하는데 이때 사용하는 것이 파티셔너. 프로듀서가 파티션을 결정하는 알고리즘은 기본적으로 메시지(레코드)의 키를 해시처리해 파티션을 구하는 방식을 사용해서 메시지의 키 값이 동일하면 해당 메시지들은 모두 같은 파티션으로 전송된다. 주의할 점은 프로듀서가 동일한 메시지의 키를 이용해 메시지를 전송하더라도 파티션의 수를 늘린 후에는 다른 파티션으로 전송될 수 있다. 따라서 메.. 공감수 0 댓글수 0 2023. 4. 4.
  • Kafka Log Segment 로그 세그먼트 카프카의 토픽으로 들어오는 레코드는 세그먼트라는 파일에 저장된다. 메시지는 정해진 형식에 맞추어 순차적으로 로그 세그먼트 파일에 저장된다. 로그 세그먼트에는 메시지의 내용만 저장되는 것이 아니라 메시지의 키, 밸류, 오프셋, 메시지 크기와 같은 정보가 함께 저장됨, 로그 세그먼트 파일들은 브로커의 로컬 디스크에 보관된다. 하나의 로그 세그먼트 크기가 너무 커져버리면 파일을 관리하기 어렵기 때문에, 로그 세그먼트의 최대 크기는 1GB가 기본값으로 설정되어 있음. 로그 세그먼트가 1GB보다 커지는 경우 기본적으로 롤링 전략을 사용 하나의 로그 세그먼트에 카프카로 인입되는 메시지들을 계속 덧붙이다가 로그 세그먼트의 크기가 1GB에 도달하면 해당 세그먼트 파일을 클로즈하고, 새로운 로그 세그먼트를.. 공감수 0 댓글수 0 2023. 4. 1.
  • 카프카 리플레이션 동작 방식 카프카 리플리케이션 일시적인 하드웨어 이슈 등으로 브로커 한두 대에서 장애가 발생하더라도 안정성을 확보하기 위해 카프카 내부에서는 리플리케이션이라는 동작을 하게 된다. 리더와 팔로워 카프카는 내부적으로 모두 동일한 리플리케이션들을 리더와 팔로워로 구분하고, 리플리케이션 중 하나가 리더로 선정되며, 모든 읽기와 쓰기는 그 리더를 통해서만 가능. 프로듀서에서는 모든 리플리케이션에 메시지를 보내는 것이 아니라, 리더에게만 메시지를 전송한다. 또한 컨슈머도 오직 리더로부터 메시지를 가져온다 팔로워는 컨슈머와 비슷하게 지속적으로 파티션의 리더가 새로운 메시지를 받았는지 확인하고, 새로운 메시지가 있다면 해당 메시지를 리더로부터 복제한다. 복제 유지와 커밋 리더와 팔로워는 ISR(InsyncReplica)라는 논리.. 공감수 0 댓글수 0 2023. 4. 1.
  • Cassandra JMX 지표 https://cassandra.apache.org/doc/latest/cassandra/operating/metrics.html Cache Hit Rate NameTypeDescription RowCacheHit Counter Number of table row cache hits. KeyCacheHitRate Gauge Key cache hit rate for this table. Memtable & SSTable Size NameTypeDescription MemtableOnHeapSize Gauge Total amount of data stored in the memtable that resides on-heap, including column related overhead and partitio.. 공감수 0 댓글수 0 2023. 3. 27.
  • 자바 병렬성과 동시성 정리 병렬성: 한 테스크를 여러 하위 테스크로 나눠서 CPU의 다른 코어 또는 다른 머신에서 이들 하위 테스크를 병렬로 실행한다. 동시성: 조금씩 연관된 작업을 같은 CPU에서 동작하는 것 또는 애플리케이션의 생산성을 극대화할 수 있도록 코어를 바쁘게 유지하는 것이 목표라면, 원격 서비스나 데이터베이스 결과를 기다리는 스레드를 블록함으로써 연산 자원을 낭비하는 일을 피해야 한다. 자바는 이런 환경에서 사용할 수 있는 두 가지 주요 도구를 제공한다. Future 인터페이스로 자바 8의 CompletableFuture 구현은 간단하고 효율적인 문제 해결사. 자바9에 추가된 발행 구독 프로토콜에 기반한 리액티브 프로그래밍 개념을 따르는 Flow API는 조금 더 정교한 프로그래밍 접근 방법을 제공한다. 동시성은 단.. 공감수 0 댓글수 0 2023. 3. 13.
  • Cassandra, how is data updated? How is data updated? Cassandra treats each new row as an upsert During a write, Cassandra adds each new row to the database without checking on where a duplicate record exists. This policy makes it possible that many versions of the same row many exist in the database. Periodically, the rows stored in memory are streamed to disk into structures called SSTables. At certain intervals, Cassandra co.. 공감수 0 댓글수 0 2023. 3. 8.
  • Cassandra compression Compression Compression maximizes the storage capacity of Cassandra nodes by reducing the volume of data on disk and disk I/O, particularly for read-domainated workloads. Cassandra quickly finds the location of rows in the SSTable index and decompresses the relevant row chunks. New Storage engine (Cassandra 3.0+) Compression is important for Cassandra 2.2, but Cassandra 3.0 and later uses a new .. 공감수 0 댓글수 0 2023. 3. 8.
  • Cassandra, how is data maintained? How is data maintained? The Cassandra write process stores data in files called SSTables. SSTables are immutable. Instead of overwriting existing rows with inserts or updates, Cassandra writes new timestamped versions of the inserted or updated data in new SSTables. Cassandra does not perform delete by removing the deleted data; instead, Cassandra marks it with tombstones. Over time, Cassandra m.. 공감수 0 댓글수 0 2023. 3. 4.
  • Cassandra, how it data written? How is data written? Cassandra processes data at several stages on the write path, starting with the immediate logging of a write and ending in with a write of data to disk. Logging data in the commit log Writing data to the memtable. Flushing data from the memtable. Storing data on disk in SSTables Logging writes and memtable storage When a write occurs, Cassandra stores the data in a memory st.. 공감수 0 댓글수 0 2023. 3. 4.
  • Cassandra Storage Engine Storage Engine Cassandra uses a storage strucutre similar to a Log-Structure Merge Tree. Cassandra avoids reading before writing. Read-before-write, especially in a large distributed system, can result in large latencies in read performance and other problems. For example, two clients read at the same time; one overwirtes the row to make update A, and the other overwrites the row to make update .. 공감수 0 댓글수 0 2023. 3. 4.
  • Cassandra Snitch determines which datacenters and racks nodes belong to. they inform Cassandra about the network topology so that requests are routed efficiently and allows Cassandra to distribute replicas by grouping machines into datacenters and racks. Strategy Dynamic snitching by default, all snitches also use a dynamic snitch layer that monitors read latency and where possible routes requests away from poor.. 공감수 0 댓글수 0 2023. 3. 3.
    문의안내
    • 티스토리
    • 로그인
    • 고객센터

    티스토리는 카카오에서 사랑을 담아 만듭니다.

    © Kakao Corp.