• Elasticsearch
  • 데이터 저장소 및 검색/분석 엔진
• Logstash
  • 데이터 수집 및 처리
  • 데이터를 가공(필터링, 변환, 형식화)하여 Elasticsearch에 전송
• Kibana
  • 데이터 시각화 및 대시보드
  • Elasticsearch에 저장된 데이터를 시각화해서 사용자에게 제공

• Prometheus

  • 모니터링 및 경고 시스템으로, 주로 시계열 데이터(시간에 따라 변하는 값)를 수집하고 저장하는 데 사용
  • Polling 방식으로 동작
    • Prometheus는 설정된 타겟(Endpoints)으로 주기적으로 요청을 보내 데이터를 가져옴
    • 장점 : Prometheus가 데이터를 제어하므로 장애 관리 용이.
    • 단점 : 타겟 엔드포인트가 반드시 데이터를 노출해야 함

• Grafana

  • 데이터 시각화 및 대시보드 도구로, 다양한 데이터 소스에서 정보를 가져와 시각적으로 표현하는 역할

• Loki

  • 로그 데이터 저장 및 검색 엔진

• Promtail

  • Loki와 함께 사용되는 로그 수집기
  • Pushing 방식으로 동작
    • Promtail은 서버의 로그 파일을 읽고, 필터링 및 파싱한 후 데이터를 Loki로 전송
    • 장점: 로그 데이터를 실시간으로 전송 가능하며, Loki와의 통합에 최적화됨
    • 단점: Push 모델이므로 Promtail 설정 및 Loki 연동이 필요

• 지금 당장 몰라도 됨

RoR에서 Vue를 사용하는 방법?

템플릿 엔진은 서버에서 HTML을 생성해 클라이언트로 전달하지만, Vue는 클라이언트에서 DOM을 동적으로 렌더링합니다. ROR의 V는 서버 측 View를 의미하므로 Vue와 역할이 충돌합니다.

• HTML (HyperText Markup Language)

  • HTML은 웹 페이지의 구조와 내용을 정의하는 마크업 언어입니다.
  • 웹 페이지의 텍스트, 이미지, 링크, 폼 등 다양한 요소를 배치하고 구성합니다.
  • 정적 문서입니다.

• DOM (Document Object Model)

  • DOM은 HTML 문서를 프로그래밍적으로 조작할 수 있게 해주는 트리 구조의 객체 모델입니다.
  • 자바스크립트와 같은 프로그래밍 언어를 사용하여 웹 페이지의 구조, 스타일, 내용을 동적으로 변경할 수 있습니다.
  • 동적 문서 모델입니다.

• 꼬리 질문 답

임베디드 템플릿(erb, ejs, php, ...)으로 마크업 짜놓고, 마크업 짜놓은거 기반으로 vuejs로 동적인 UI 제공하는게 의외로 해볼만한 트릭이에요.

• 동시성 문제를 겪을 때 Lock을 사용하면 반드시 느려질 수 밖에 없음
  • 이 때 동시성 문제를 해결하면서도 좀 더 빠르게 동작하게 하기 위해서 사용하는게 Lock Free와 Wait Free임
  • Lock을 사용하지 않고 CAS 연산을 통해서 동시성을 보장하는데, 이 때 Java에서는 Atomic을 활용해서 CAS 연산을 한다.
    • 예시 👇

AtomicInteger atomic = new AtomicInteger(0);
while(!atomic.compareAndSet(value, update)) {
  doSomethig();
}

• Lock Free
  • 적어도 하나의 스레드가 진행됨을 보장
  • 일부 스레드는 무한정 대기할 수 있음
  • Wait Free보다 구현이 상대적으로 단순
  • 여러 스레드가 경쟁하지 않는 상황이라면 CAS 연산은 항상 성공하고, 여러 스레드가 경쟁을 한다고 해도 최소한 하나의 스레드는 반드시 성공하기 때문에 성공한 스레드는 작업을 진행되기 때문
• Wait Free
  • 모든 스레드가 정해진 시간 내에 작업을 완료할 수 있음을 보장
  • 다른 스레드의 진행 상태와 관계없이 작업 완료 가능
• Wait-Free는 Lock-Free의 상위 집합으로 볼 수 있음
  • 모든 Wait-Free 알고리즘은 Lock-Free이지만, 모든 Lock-Free 알고리즘이 Wait-Free인 것은 아님

• Redis Sentinel

목적: 단일 마스터-복제본 구조에서 고가용성(High Availability) 제공

주요 특징:

• 마스터 노드 장애 감지 및 자동 복제본 승격
• 클라이언트 서비스 디스커버리 제공
• 모니터링 및 알림 기능
• 데이터 샤딩 없음 - 모든 데이터가 마스터 한 곳에 저장

장점 ✅:

• 설정과 관리가 간단함
• 자동 장애 조치로 다운타임 최소화
• 기존 단일 Redis 인스턴스에서 쉽게 마이그레이션 가능
• 클라이언트 투명성 (failover 시 자동 재연결)

단점 ❌:

• 단일 마스터 병목: 모든 쓰기가 하나의 마스터로 집중
• 수평 확장 불가능 - 데이터가 한 노드 메모리 용량에 제한
• 대용량 데이터셋 처리 한계
• 높은 처리량(high throughput) 시나리오에 부적합

• Redis Cluster

목적: 수평 확장(Horizontal Scaling)과 데이터 분산을 통한 성능 향상

주요 특징:

• 자동 데이터 샤딩 (16,384개 해시 슬롯 사용)
• 다중 마스터 노드로 쓰기 분산
• 각 마스터마다 복제본 운영으로 고가용성도 제공
• 온라인 리샤딩 지원

장점 ✅:

• 무제한 수평 확장: 노드 추가로 용량과 처리량 증가
• 대용량 데이터셋 처리 가능
• 높은 처리량과 성능
• 단일 실패 지점(SPOF) 없음
• 온라인으로 노드 추가/제거 가능

단점 ❌:

• 설정과 관리가 복잡함
• 트랜잭션이 여러 노드에 걸치면 제한적
• 클라이언트에서 클러스터 인식 로직 필요
• 작은 데이터셋에는 오버헤드

• 언제 사용해야 할까?

Redis Sentinel을 선택하는 경우:

• 📊 중소규모 애플리케이션에서 고가용성이 필요할 때
• 🔒 단일 노드 메모리 용량으로 충분한 데이터량
• 💾 캐싱 용도로 주로 사용할 때
• 🛠️ 단순한 설정과 관리를 원할 때
• 🔄 기존 단일 Redis에서 점진적 마이그레이션이 필요할 때

# 적합한 시나리오 예시
- 웹 애플리케이션 세션 저장소
- 소규모 캐싱 시스템
- 실시간 리더보드 (데이터량이 적은 경우)

Redis Cluster를 선택하는 경우:

• 🚀 대용량 데이터셋을 처리해야 할 때
• ⚡ **높은 처리량(high throughput)**이 필요할 때
• 📈 수평 확장이 필요한 성장하는 서비스
• 🌐 글로벌 서비스에서 지역별 데이터 분산이 필요할 때
• 💪 고성능과 가용성을 모두 요구할 때

# 적합한 시나리오 예시
- 대규모 전자상거래 상품 카탈로그
- 실시간 분석 데이터 처리
- IoT 데이터 수집 및 처리
- 대규모 게임 서버 데이터

• 요약 비교표

• Split Brain 현상

네트워크 파티션으로 클러스터가 분할되어 여러 개의 독립적인 제어 중심이 동시에 존재하면서 데이터 일관성이 깨지는 현상입니다.

• Redis Cluster 동작 원리

• 16,384개 해시 슬롯을 마스터 노드들이 분할 관리

• 쿼럼 기반 의사결정: 과반수 마스터가 통신 가능해야 정상 동작

• Gossip 프로토콜로 노드 상태와 슬롯 정보 실시간 동기화

• Configuration Epoch로 클러스터 설정 버전 관리

• Split Brain 발생 시나리오

1. 짝수 개 노드의 2분할 (최악의 경우)

• 6개 마스터 → 3:3 분할
• 양쪽 모두 과반수 미달이지만 각자 "정당한 클러스터"로 착각
• 동일한 키에 서로 다른 값 저장 → 데이터 일관성 파괴

2. 홀수 개 노드의 3분할

• 7개 마스터 → 3:2:2 분할

• 모든 그룹이 과반수 미달 → 전체 클러스터 쓰기 불가

• Redis Cluster의 방지 메커니즘

1. 쿼럼 기반 상태 관리

• 과반수 미만 시 자동으로 읽기 전용 모드 전환
• CLUSTERDOWN 상태로 쓰기 작업 거부

2. Write Safety 보장

• 비동기 복제로 인한 데이터 손실 가능성 인정
• Last Failover Wins 정책으로 최종 선출된 마스터 데이터 우선

3. Replica Election 과정

• 마스터 장애 시 과반수 마스터의 동의로만 복제본 승격

• Configuration Epoch 증가로 새로운 클러스터 설정 전파

• 방지를 위한 모범 사례

1. 노드 구성

• 홀수 개 마스터 (최소 3개, 권장 5~7개)
• 마스터당 최소 1개 복제본 구성

2. 지리적 분산

• 주 데이터센터에 과반수 노드 배치
• 부 데이터센터들에 나머지 노드 분산

3. 타임아웃 설정

• cluster-node-timeout: 15초 (기본값)

• cluster-replica-validity-factor: 10

• CAP 정리 관점

Redis Cluster는 CP(Consistency + Partition Tolerance) 선택:

• 일관성 우선: 과반수 미달 시 가용성 희생

• 분산 허용: 파티션 감지 후 안전 모드 전환

• 실무 대응 방안

1. 모니터링

• CLUSTER NODES, CLUSTER INFO로 상태 감시
• Node Timeout 및 Fail State 알림 설정

2. 애플리케이션 레벨

• CLUSTERDOWN 예외 처리
• Fallback 저장소 (DB, 다른 캐시) 준비

3. 복구 절차

• 네트워크 복구 후 데이터 일관성 검증

• 필요시 수동 슬롯 재할당 및 복제본 재동기화

• 한계점과 대안

1. Redis Cluster 한계

• 복잡한 파티션에서는 완전한 해결 불가
• 수동 개입 필요한 상황 발생 가능

2. 대안적 해결책

• Redis Sentinel: 단순한 HA 구조에서 더 나은 가용성
• Strong Consistency 시스템: Zookeeper, etcd 활용
• 애플리케이션 샤딩: 클라이언트 레벨 데이터 분산 제어

출처: Redis Cluster Specification (opens in a new tab)