운영되는게 기적적인 블로그

• Kafka Streams
  • 실시간 데이터 처리를 위한 클라이언트 라이브러리
  • 분산 환경에서 고성능 유지
  • 상태 저장 및 비저장 처리 지원
  • 정확히 한 번 처리 보장
  • Stateful processing : 윈도우 연산, 조인 연산, 집계 가능
  • KTable, KStream
    • KTable : 단순한 데이터 스트림 흐름
    • KStream : 상태 기반의 데이터 구조, 최신 상태만 유지하며 업데이터가 일어날 때마다 데이터가 덮어 쓰여짐
• Kafka Connect
  • 데이터 통합을 위한 분산 프레임워크
  • 데이터 데이터 소스/싱크 연결
  • 확장 가능한 플러그인 아키텍쳐
  • 내장 및 커스텀 커넥터 지원
  • 활용 사례
    • 데이터베이스CDC (Change Data Capture)
    • 로그 파일 스트리밍
    • 클라우드 스토리지 연동
• Broker 설정 및 튜닝
  • 리텐션 정책 설정
    • 리텐션 기간 설정 
    • 세그먼트 크기 최적화
    • 고려사항 : 스토리지 용량 vs 데이터 보존 기간
  • 리더와 팔로워 관리
    • Replication Factor 설정
    • ISR(In-Sync Replicas) 관리
    • 리더 선출 전략
• Producer 설정
  • Idempotent Producer
    • 중복 메시지 방지
  • Transactional Producer : 원자적 메시지 전송
  • 압축 설정
• Consumer 리밸런싱 전략
  • 컨슈머 그룹 관리 : 파티션 재배치 최적화
  • 리밸런싱 정략 : 
    • Sticky Assignor
    • Cooperative Sticky Assignor
    • 커스텀 파티션 할당 전략
    • 정적 멤버십
    • 증분식 리밸런싱
• Consumer Offset 관리
  • 자동 offset 커밋
    • 주기적 자동 커밋
    • 장점 : 간단한 구현과 관리
    • 단점 : 중복 처리 가능성
  • 수동 Offset 관리
    • 관리자가 직접 커밋
    • 장점 : 정확한 처리 보장
    • 단점 : 복잡한 구현
• Replication Factor 및 파티셔닝 전략
  • Replication Factor 조정 : 데이터 내구성과 장애 복구 능력 향상
  • 커스터 파티셔닝 전략 : 데이터 로컬리티 향상
• SSL/TLS 구성
  • SSL 구성 : 데이터 암호화 및 보안 통신
  • SASL을 통한 인증 : 다양한 인증 매커니즘 지원, Kerberos, SCRAM
• ACL 보안 관리
  • 세밀한 접근 제어 : 특정 사용자나 애플리케이션이 특정 토픽에 접근할 수 있도록 설정
  • 보안 정책 적용 및 모니터링 : 보안 로그를 통해 모든 보안 이벤트를 기록, 이상행동 탐지, 칩입 방지
   

• 카프카 : 메시징 시스템 개념
  • 분산 메시징 시스템
  • 실시간 데이터 스트리밍
  • 로그 처리
• 핵심 특징
  • 확장성 : 분산 시스템 설계, 수평 확장 용이
  • 내구성 : Replication 기능
  • 높은 처리량 : 배치 처리와 압축 통한 성능 최적화
• 아키텍쳐 : Producer, Consumer
  • Producer
    • 데이터 생성 및 카프카 클러스터로 전송
    • 메시지 전송 과정
      • 특정 토픽의 파티션으로 데이터 전송
      • 파티션 선택 전략: 라운드 로빈, 키 기반 해시
    • Ack 설정
      • acks = all: 높은 내구성 보장
  • Consumer
    • 카프카에서 데이터 읽기
    • Consumer Group
      • 병렬 처리 가능
      • 하나의 파티션은 하나의 컨슈머에만 할당
    • 데이터 중복 및 누락 방지
      • offset 관리
  • Producer-Consumer 흐름
    • 데이터 흐름
      • 프로듀서 -> 토픽 (파티션) -> 컨슈머
      • 높은 처리량과 확장성
  • 브로커
    • 카프카 클러스터의 서버 노드
    • 브로커 클러스터
      • 여러 브로커로 구성
      • 데이터 저장 및 관리
    • 리더와 팔로워 구조
      • 리더 : 주 데이터 처리
      • 팔로워 : 데이터 복제 및 장애 복구 준비
  • 토픽
    • 메시지 카테고리
    • 토픽의 구조
      • 여러 파티션으로 구성
      • 병렬 처리 가능
    • 데이터 처리 전략 : 발행/구독 모델
  • 브로커 - 토픽 관계
    • 데이터 분산 저장
      • 토픽의 파티션이 여러 브로커에 분산
      • 고가용성과 성능 보장
  • 파티션
    • 카프카의 핵심 처리 단위
    • 토픽을 구성하는 단위
    • 특징
      • 고유 번호 부여
      • 물리적으로 다른 브로커에 분산 저장
    • 병렬 처리 : 고성능 데이터 처리 가능
    • 데이터 저장 구조 : 로그 파일 형식
  • Replication
    • 데이터 복제를 통한 내구성과 고가용성 보장
    • 리더-팔로워 구조
      • 리더 : 주 데이터 처리
      • 팔로워 : 데이터 복제 및 백업
    • Replication Factor
      • 일반적으로 2~3개의 복제본 유지
      • 장애 내성 vs 리소스 사용량 trade-off
  • 파티션-Replication
    • 내구성 보장 : 데이터 손실 방지, 고가용
  • Offest
    • 컨슈머의 메시지 읽기 위치 기억
    • 메시지 일관성 유지
      • 중복 처리 방지
      • 처리 일관성 유지
    • 관리 방식
      • 자동 커밋 : 카프카가 자동으로 offset 저장
      • 수동 커밋 : 컨슈머가 명시적으로 Offset 저장, 안정한 메시지 처리 보장
    • offset과 메시지 처리 일관성
      • 정확히 한번 처리 가능
      • 데이터의 일관성 유지
      • 중복 메시지 처리 방지

///////

• 카프카의 역할
  • 중앙 집줍형 로그 관리 시스템 구축
  • 대규모 시스템에서 로그 데이터 효율적 처리
  • 장애 및 성능 문제 신속 파악
• 활용 사례
  • 웹 애플리케이션: 오류 로그, 성능 메트릭 수집
  • 장애 탐지 및 대응 시간 단축
  • 데브옵스 환경 : 인프라 상태 모니터링 및 자동화 대응
• 대규모 데이터 스트리밍 시스템
  • 여러 데이터 소스에서 실시간 데이터 수집
  • 스트리밍 분석 시스템으로 데이터 전송
• 적용 사례
  • IOT 장치
  • 실시간 데이터 파이프라인 구축
  • 비즈니스 인텔리전스 : 실시간 보고서 생성 및 분석
• 사용 사례
  • 중앙 로그 관리
    • 여러 서버의 로그 데이터 중앙화
    • 효율적인 로그 처리 및 문제 원인 추적
  • ELK 스택 연동
    •  Elasticsearch, Logstash, Kibana와 통합
    • 실시간 로그 분석 및 검색 시스템 구축
    • 활용 : 실시간 로그 모니터링, 즉각적인 문제 해결
  • 기술 스택 연동
    • 카프카 스트림스 : 실시간 데이터 변환 및 이벤트 처리
    • Apache Flink, Spark Streaming : 고급 실시간 데이터 처리
  • 마이크로 서비스 아키텍쳐
    • 서비스 간 비동기 통신
      • 마이크로서비스 간 이벤트 기반 아키텍쳐 지원
      • 확장성과 유연성 제공
    • 확장 가능한 이벤트 드레이븐 시스템
      • 대규모 서비스에서 고성능 비동기 통신 지원 (전자상거래, 결제, 배송)
  • 데이터 파이프라인
    • 데이터 수집 및 변환
      • 여러 소스에서 실시간 데이터 수집 및 중앙 집계
      • 다양한 분석 시스템으로 데이터 전당
    • Kafka Connect 활용
      • 다양한 데이터 소스와 연동 (실시간 데이터 파이프라인 구축
  • 금융 거래 처리
    • 실시간 금융 거래 처리
      • 대규모 트랜잭션 데이터 실시간 처리
      • 빠른 거래 처리 및 정확한 데이터 분석
    • Fraud Detection 시스템
      • 실시간 거래 데이터 분석을 통한 분석 처리
  • 미디어 스트리밍 서비스
    • 실시간 미지어 데이터 처리
      • 스트리밍 데이터 처리 및 빠른 콘텐츠 전송
      • 맞춤형 추천 및 미디어 품질 최적화
    • 실시간 분석을 통한 품질 최적화
      • 사용자 행동 추적 및 서비스 문제 모니터링
  • 실시간 광고 배포 시스템
  • 클릭 스트림 분석

Redis란

• Remote Dictionary Server으로 메모리 기반의 고성능 데이터 저장소
• 주로 캐시, 메시지 브로커, 세션 저장소로 사용
• Key-Value 구조와 다양한 데이터 타입 지원

• 사용사례
  • 캐시
    • 자주 조회되는 데이터를 메모리에 저장해 빠르게 응답
    • 대형 쇼핑몰에서 상품 목록을 캐시하여, 데이터베이스 조회를 줄이고 사용자에게 즉시 응답 제공
  • 세션 저장소
    • 세션 관리에 적합
    • 로그인 상태 유지 및 쇼핑 카트 정보 저장
    • 전자상거래 사이트에서 사용자의 로그인 세션과 장바구니 정보를 Redis에 저장하여 빠른 액세스 제공
• Redis의 주요 특징
  • 메모리 기반 
    • Redis는 메모리 기반으로 동작
    • 디스크 I/O에 비해 빠른 속도로 데이터 읽기쓰기 가능
    • Redis가 주로 실시간 데이터 처리 및 고속 캐싱 솔루션으로 사용되는 주요 이유 중 하나
  • 영속성 옵션
    • Redis는 데이터를 메모리에 저장하면서도 영속성을 보장하기 위한 옵션 제공
    • RDB (Redis Database) 스냅샷 : 주기적으로 전체 데이터를 디스크에 저장
    • AOF : 데이터 변경 로그를 저장해 시스템 재시간 시 복구 가능
    • 데이터 손실을 최소화하고 복구함
  • 다양한 데이터 타입
    • String, List, Set ,Sorted Set(ZSet), Hash, Bitmaps, HyperLog 
  • 복제
    • Master-Slave 복제 구조를 지원하여 데이터 가용성을 높이고, 읽기 부하를 분산
    • Master는 데이터를 쓰고, Slave는 데이터를 읽는 구조로, 읽기 성능 향상 및 데이터 백업 제공
  • 고가용성
    • Sentinel라는 기능을 통해 자동 복구 및 장애조치 지원
    • Sentinel은 Redis 인스턴스를 모니터링하고 Master 노드에 장애가 발생하면 자동으로 Slave 노드를 승격하여 서비스의 중단 없이 운영
  • 클러스터링
    • Cluster 기능을 통해 데이터를 여러 노드에 분산 저장, 수평적 확장
    • 대규모 데이터를 성능 저하없이 확장 가능
    • 자동으로 데이터를 노드 간 분산시키며, 각 노드는 해시 슬롯을 통해 데이터를 관리
• Redis 아키텍쳐
  • 싱글 스레드 모델
    • 싱글 스레드로 동작, 하나의 요청 한번에 처리
    • I/O성능을 극대화 하는 구조, 여러 요청 빠르게 처리
    • 락경합 없고 프로세스가 경량화되어 성능 저하 없음
  • 비동기 I/O
    • 비동기 I/O모델을 채택하여, 네트워크 요청이나 파일쓰기와 같은 I/O작업을 논 블로킹으로 처리
    • 네트워크 대기 시간을 줄이고, 많은 요청을 동시에 처리
  • 데이터 영속성
    • RDB 스냅샷 : 일정 간격으로 데이터베이스 상태를 스냅샷으로 저장 (dump.rdb)
      • 주기적인 저장을 통해 데이터복구
    • AOF 로그
      • 데이터 변경사항을 지속적으로 기록, 재시작시 모든 변경사항 복구

Redis 고급 기능, 성능 최정화

• Redis Cluster
  • 수평적 확장성 제공 
    • 여러 노드에 데이터를 분산 저장
    • 대규모 데이터를 처리하는데 매우 유용, 클로스터의 각 노드가 일부 데이터를 관리
    • 노드 추가로 시스템의 성능과 용량 쉽게 확장
  • 데이터 파티셔닝
    • 여러 노드에 분산 저장
    • 데이터를 해시 슬롯이라는 개념을 분배하여 각 노드는 해시 슬롯의 일부를 관리
    • 16384개의 해시 슬록 사용
    • 키를 해시함수로 계간하고 그 값을 기반으로 적절한 노드에 데이터를 저장
• Redis Sentinel
  • 자동 장애 복구 및 모니터링
    • 고가용성 보장 : Maste 노드가 장애를 일으키면 자동으로 Failover를 실행하여 slave를 master로 승격
• Pub/Sub
  • 실시간 데이터 스트리밍, 이벤트 처리, 알림 시스템에 적함
  • 메시지 브로커 역할
• Lua 스크립트
  • 원자적 트랜잭션 및 복잡한 로직 처리
    • 복잡한 로직을 클라이언트가 아니라 서버 측에서 직접 처리해서 성능을 최적화하고 데이터 일관성 보장
  • 성능 향상
    • 클라와 서버간의 불필요한 왕복을 줄이고 복잡한 작업을 서버에서 실행함으로서 전체 성능을 향상
    • 여러 명령을 하나의 트랜잭션으로 묶어 처리
• Pipelining
  • 네트워크 왕복 횟수 감소
    • 여러 명령어를 한번에 서버로 전송
  • 성능 최적화
    • 네트워크 오버헤드 줄임, 클라 서버 간의 통신이 빈번할때 활용

성능 최적화 전략

• 메모리 최적화
  • 데이터 압축 사용 및 메모리 정리 (ziplist, intset)
  • LRU/LFU 정책

• 파티셔닝 활용
  • 데이터를 여러 노드에 분산 저장
  • 데이터를 해시 슬롯을 기반으로 분산시켜 대규모 데이터 처리
  • 시스템 부하를 분산시켜 각 노드가 처리해야할 데이터량 줄임
• TTL 설정
  • 자동 데이터 제거
    • 각 키에 대해 TTL을 설정하여 일정시간이 지나면 자동으로 데이터를 삭제하는 기능
    • 불필요한 데이터관리
  • 메모리 관리 최적화
    • 오래된 데이터가 메모리에서 자동으로 제거
• Pipelining
  • 네트워크 왕복 횟수 감소, 명령어 처리 속도 향상

Redis 잠재적인 문제와 해결방법 

• 메모리 부족
  • 원인
    • Redis는 메모리에 데이터를 저장하므로, 저장되는 데이터의 양이 많아질수록 메모리 사용량이 증가
    • 일정 메모리 한도에 도달하면 더 이상 새로운 데이터를 저장할 수 없게 되어 문제가 발생
    • 메모리 부족은 주로 캐시 데이터나 대규모 키 저장소를 운영할 때 자주 발생
  • 해결 방법
    • maxmemory 설정
    • LRU/LFU
    • 데이터 압축 및 데이터 타입 최적화
• 복제 지연
  • 원인
    
    • 네트워크 지연 : Master에서 Slave로 데이터가 전송되는 동안 네트워크 지연 발생, 네트워크 대역폭이 낮거나, 여러 노드 간의 거리가 먼 경우 지연 심화
    • Slave 성능 저하 : Slave 노드가 처리해야할 작업이 많거나, CPU, 메모리 등 자원 부족으로 지연 발생
    • 대규모 쓰기 작업 : Master에서 대량의 쓰기 작업이 발생할때 Slave 노드가 그 작업을 처리하는데 시간이 오래 걸려 지연
  • 해결방법
    
    • 복제 압축 활성화
    • 비동기 복제 사용
    • Slave의 성능 최적화
• 데이터 영속성 및 복구 시간
  • 원인
    • AOF 파일 크기 증가 : 데이터를 변경할때 마다 AOF 파일에 기록하므로 시간이 지남에 따라 AOF 파일이 커림
    • AOF 파일이 커질수록 Redis가 재시작 시 해당 로그를 모두 재생하는데 시간이 오래 걸림
    • 주기적인 AOF 파일 압축 미실행 : Redis는 주기적으로 AOF 파일을 압축 재작성하여 파일 크기를 줄일 수 있지만 이 작업이 제대로 실행안되면 파일 크기 계속 증가
  • 해결 방법
    • AOF 파일 압축, 재작성
    • AOF와 RDB 병행 사용
     

필요성

• 성능 저하와 사용자 증가
• 가용성과 신뢰성
• 비즈니스 성장과 확장성

수직 확장

• 기존 서버 성능을 업그레이드하여 처리 능력 향상
  • 장점
    • 간단한 적용 : 기존 시스템을 크게 변경하지 않고, 서버의 하드웨어 성능만 업그레이드하면 성능 향상
    • 적은 복잡성 : 시스템 아키텍쳐 변경하지않고 관리 간단
  • 단점
    • 물리적 한계 : 수직 확장은 하드웨어의 물리적 한계에 도달하면 더 이상 확장할 수 없음
    • 단일 장애 지점 : 한 서버에 모든 것을 집중시키면, 그 서버에 장애가 발생하면 전체 시스템이 멈출 수 있음

수평 확장

• 여러 대의 서버를 추가하여 처리 능력을 분산시키는 방식
• 각 서버가 동일한 작업을 수행하며, 로드 밸런서를 통해 요청을 여러 서버에 분산하여 처리
  • 장점
    • 무한한 확장성 : 트래픽 증가에 유연하게 대응
    • 고가용성 : 한 서버에 문제 생겨서 나머지 서버가 계속 운영가능
  • 단점 
    • 복잡한 아키텍쳐 : 서버 간 데이터 동기화나 일관성 문제를 해결해야함
    • 데이터 일관성 문제 : 여러 서버에서 동시에 데이터를 처리할 때 일관성 문제가 발생할 수 있음

결국

데이터 일관성, 복잡성 증가, 비용문제를 해결해야함

소규모에서 대형으로 발전하기

1. 소규모는 Monolithic 구조로 시작 (사용자가 증가할수록 시스템 성능이 떨어짐)
2. 수직 확장 적용 : cpu, 메모리, 디스크 용량 등을 업그레이드 (트래픽 증가계속하면 서버 성능을 더이상 업그레이드할수없음 (물리적한계)
3. 수평 확장 적용 : 여러대 서버로 트래픽 분산, 로드 밸런서를 사용해 사용자 요청을 여러 대의 서버로 분산 (고가용성, 서버 유연하게 확장)
4. 데이터베이스 분산 및 샤딩 : 데이터베이스 병목현상 해결, 각 샤드가 독립적으로 데이터 처리
5. 캐싱 적용 : 자주 사용되는 데이터 최적화 (Redis, Memcached같은 시스템 사용) : 사용자 응답시간 빠르고 데이터베이스 요청 줄어듬
6. 마이크로 서비스 도입 : 각 기능을 독립적인 서비스로 분리 운영, 각 서비스가 독립적으로 배포, 확장가능, 유연성 증가
7. 비동기 이벤트 처리 : 실시간으로 처리하지 않고 비동기적으로 처리, 주요 트랜잭션이 완료된 후 시간이 오래 걸리는 작업은 메시지 큐로 전달, 응답성을 높이고 시스템을 효율적으로 운영

• 여러 대의 컴퓨터가 네트워크를 통해 하나의 시스템처럼 동작하는 시스템
• 각 노드는 독립적으로 동작하면서도, 시스템 전체적으로는 하나의 일관된 서비스처럼 보이도록 협력
  • 확장성 : 트래픽이 증가해도 여러 서버를 추가하여 부하를 분산
  • 성능 향상 : 작업을 여러 노드에 분산 처리하여 시스템의 성능을 극대화
  • 가용성 : 여러 노드에 걸쳐 시스템이 구성되어 있어 일부 노드가 장애를 겪더라도 시스템은 계속 운영될 수 있음

구성 요소

• 노드
  • 분산 시스템의 기본 단위
  • 각 노드는 독립적인 컴퓨터로서, 역할에 따라 데이터 저장, 처리, 요청 관리 담당
• 네트워크
  • 분산 시스템 내의 노드 간 통신을 담당
  • 노드 간 데이터 전송과 상호작용을 관리, 네트워크의 성능이 분산 시스템의 성능에 큰 영향을 미침
• 데이터 복제 및 분산
  • 데이터를 여러 노드에 복제하여 저장함으로써 가용성과 내결함성을 보장
  • 데이터가 분산되어 저장되면, 하나의 노드에 문제가 발생해도 다른 노드에서 데이터를 제공

주요 원리

• 데이터 일관성
  • 모든 노드가 동일한 데이터 상태를 유지하는 능력
  • 하나의 노드에서 데이터가 업데이트되면, 다른 노드도 동일한 데이터를 가지게 됨
  • 금융 거래, 주문 시스템
    • 네트워크 지연이나 장애가 발생하면 데이터가 비동기적으로 처리되면서 동기화 문제가 생길 수 있음
• 가용성
  • 시스템이 항상 사용자 요청에 응답할 수 있는 능력
  • 하나 이상의 노드가 다운되더라도, 분산 시스템은 여전히 정상적으로 운영 될 수 있어야함
  • 소셜 미디어, 스트리밍같은 빠른 피드백 요구
• 내결함성
  • 시스템이 일부 노드의 장애에도 불구하고 서비스를 지속할 수 있는 능력
  • 데이터 복제 및 분산, 장애 발생 시 자동 복구를 통해 내결함성을 확보
  • 그냥 필수

CAP 이론

• 일관성C, 가용성 Availability, 파티션 내성 Parti 이 세가지를 동시에 만족시킬 수 없다는 이론, 3개 중 2개만이라도 만족해라
  
  • 설계
    • 일관성 중시 시스템 : 금융 거래 시스템
      • 모든 거래가 일관성을 보장해야하므로 가용성보단 일관성
      • 네트워크 분할 발새앻도 데이터의 정확성이 우선시
    • 가용성 중시 시스템 : 소셜미디어, 스트리밍 서비스
      • 빠른 응답이 필수적이므로 일관성을 희생하더라도 가용성과 네트워크 파티션 내성 유지 우선
      • 사용자는 약간의 일관성 문제를 느끼지 못하지만 빠른 서비스가 중요하게 작용

장애 대응

• 분산 시스템에서는 노드가 장애를 겪더라도 전체 시스템이 무중단 운영을 유지하는 것이 중요 (하나 장애인데 전체 시스템 중단될 수 있음)
• 노드 장애나 네트워크 장애가 발생했을때 데이터 손실이나 서비스 중단을 방지할 수 있어야함
  • 고려사항
    • 데이터 복제 : 여러 노드에 데이터 복제
    • Failover : 장애 발생시 백업 노드로 트래픽 전환
    • 재해 복구 : 치명적인 장애가 발생해도 복구할수있는 계획 수립

네트워크 대역폭

• 분산 시스템에서 노드 간의 데이터 전송 속도는 시스템 성능에 중요한 영향을 미침
• 데이터가 자주 전송되거나 동기화되어야하는 시스템에서 네트워크 대역폭이 부족하면 성능저하
• 네트웤 성능이 느리면, 분산 시스템에서 데이터 일관성 유지나 장애 복구에 문제가 생길수 있음
  • 고려 사항
    • 네트워크 최적화 : 데이터 전송량 최소화 (압축)
    • 지연 : 저장시 지역성 고려
    • 캐싱 : 트래픽 줄이기위한 캐싱 전략

대규모 트래픽 발생의 주요 원인

• 마케팅 이벤트 : 대규모 할인 행사, 쿠폰 발급, 타임 세일, 새로운 상품 출기 등 이벤트로 인해 트래픽이 급증
• 바이럴 콘텐츠 : SNS, 뉴스 또는 인터넷에서 급속도로 퍼지는 콘텐츠로 인해 갑자기 트래픽 증가
• 인기 서비스 : 갑작스럽게 주목받은 애플리케이션
• 리소스 집중 : 특정 시간대 많은 사용자가 몰림

대규모 트래픽 처리 실패 시의 문제점

• 성능 저하
• 시스템 다운타임
• 데이터 일관성 문제
• 서버 자원 낭비

트래픽 급증 대비를 위한 주요 처리 전략

• 수평적 확장
  • 트래픽이 증가할 때 여러 서버를 추가하여 처리능력을 확장
  • 각각의 서버는 동일한 역할을 수행하며, 트래픽을 분산처리
    • 특징 
      • 서버를 쉽게 추가하거나 제거할 수 있어 유연한 확장가능
      • 장애가 발생한 서버를 제외하고도 다른 서버가 계속 요청을 처리할 수 있어 고가용성 유지
    • 실제 적용
      • EC2 Auto Scaling
      • Kubernetes
• 부하 분산
  • Load Balancer는 다수의 서버가 있는 환경에서 트래픽을 균등하게 분배
  • 특정 서버에 부하가 집중되는 것을 방지
    • 특징
      • 트래픽이 많을 때도 각 서버가 안정적으로 작동하도록 보장
      • 다양한 알고리즘 (라운드 로빈, 최소 연결, IP 해시 등)을 사용하여 트래픽을 분배
      • 서버 장애 시 다른 서버로 트래픽을 자동으로 전환하여 서비스 중단을 방지할 수 있음
    • 실제 적용
    • L4를 통한 하드웨어 로드 밸런서
    • NGINX, HAProxy 같은 소프트웨어 로드 밸런서
    • ELB같은 클라우드 기반 로드
• 캐싱
  • 자주 조회되는 데이터를 미리 저장하여 사용자 요청 시 즉시 제공
  • 데이터 베이스나 API 요청대신 캐시된 데이터를 사용해서 응답 시간줄이고 트래픽 부하 감소
    
    • 특징
      
      • 반복 요청에 대해 빠른 응답 제공
      • 데이터베이스나 원본 서버의 부하를 줄임
      • TTL 설정을 통해 캐시 데이터의 유효 기간을 관리
    • 실제 적용
      • Redis, Memcached -> 인메모리 캐시
      • CDN
• 비동기처리
  • 즉시 응답할 필요가 없는 작업은 비동기 처리하고 사용자 요청에 대한 응답ㅂ은 빠르게 처리
    • 특징
      • 실시간으로 즉시 처리할 필요가 없는 작업을 비동기적으로 처리하여 메인 시스템 부담 감소
      • 큐를 통해 작업을 저장하고 필요한 시점에 처리
    • 실제 적용
      • RabbitMQ, Kafka, SQS 같은 메시지 ㅠㅌ
• 데이터베이스 샤딩
  • 데이터베이스의 데이터를 여러 개의 샤드로 나누어 분산 저장
  • 한번에 처리할 수 있는 데이터의 양 줄이고 부하 분산
    • 특징
      • 데이터가 샤드 단위로 분산되어, 각 샤드는 독립적으로 데이터를 처리
      • 데이터베이스 성능 병목 해소 및 확장성 향상
    • 실제 적용
      • MySQL, MongeDB, Cassandra
• CDN
  • 지리적으로 분산된 서버 네트워크, 사용자가 서버와 가까운 위치에서 콘텐츠를 다운로드
  • 트래픽을 분산시키고 사용자에게 더 빠른 콘텐츠 제공을 가능하게 함
    • 특징
      • 사용자가 가까운 노드에서 컨텐츠를 다운로드하여 응답시간 최소화
      • 원본 서버의 부하를 줄여, 대규모 트래픽을 효과적으로 처리
    • 적용
      • Akamai, Cloudflare, Amazon CloudFront같은 CDN 서비스를 통해 정적파일을 빠르게 제공

비동기 처리 아키텍처

단일 프로세스에서 비동기 처리

• 작은 시스템에서는 자원의 효율적 사용이 중요함
• I/O 작업 (파일 읽기, 네트워크 요청 등)은 처리 시간이 길어질 수 있음
• 비동기 처리를 통해 그 대기 시간을 활용하여 다른 작업을 진행함으로써 전체 성능을 향상시킬 수 있음
• CPU 자원이 놀지 않고 계속 작업을 처리하도록 돕는 것이 비동기 처리의 핵심 장점

자바에서 비동기 처리의 기본 구성

• 스레드 풀
• 이벤트 루프를 활용한 비동기 처리

대규모 시스템에서의 비동기 처리

• 대규모 시스템에서는 많은 요청이 동시에 들어오고, 이러한 요청을 효율적으로 처리하기 위해서는 비동기 처리가 필수적
• 트래픽이 많은 환경에서 비동기 처리를 통해 시스템의 확장성과 안정성을 보장할 수 있음
• 이때 비동기 메시징 시스템 사용하여 아키텍처를 확장

비동기 메시징 시스템 이해

• 비동기 메시징 시스템은 시스템 간 또는 애플리케이션 내부의 여러 구성 요소 간 통신을 비동기적으로 처리하는 방식
• 작업이 비동기적으로 처리되기 때문에 각 구성 요소가 독립적으로 작업을 수행할 수 있어, 시스템의 확장성과 서능을 크게 향상시킬 수 있음 (독립성, 확장성, 성능햣아)
• 메시지 큐와 메시지 브로커가 이러한 비동기 메시징 시스템의 핵심 요소
  • 메시지 큐 : 메시지를 큐에 저장해 두고, 소비자가 준비되면 메시지를 비동기적으로 처리하는 역할
  • 메시지 브로커 : 이벤트 브로커는 발행-구독 패턴을 기반으로 여러 서비스가 이벤트를 구독하고, 특정 이벤트가 발생할 때 이 이벤트를 비동적으로 구독자에게 전달

메시징 시스템을 통한 비동기 처리

• 한 서비스가 작업을 완료하기 전에 메시지를 큐에 넣고, 다른 서비스가 비동기적으로 이를 처리함으로써 시스템의 부하를 줄일 수 있음

Message Queue

• 비동기 처리에서 자주 사용되는 작업 큐는 요청을 처리하기 위해 순차적으로 저장된 작업을 관리
• Producer가 메시지를 큐에 넣고, Consumers는 큐에서 메시지를 꺼내 비동기적으로 처리
• 큐는 작업을 병렬로 분산 처리하는데 중요한 역할
• 서비스 간 느슨한 결합을 가능하게 하고, 확장성을 높이는데 유용함
  • 동작 원리
    • 프로듀서 : 메시지를 생성하여 큐에 넣는 주체
    • 큐 : 메시지가 일시적으로 저장되는 공간
    • 컨슈머 : 큐에서 메시지를 가져가 처리하는 주체

Event-Driven Architecture

• 서비스 간 느슨한 결합과 실시간 반응성을 제공하는 또 다른 비동기 메시징 시스템
• 이벤트 기반 아키텍처는 시스템 내에서 발생하는 상태 변화를 이벤트로 처리하고, 각 서비스는 이 이벤트에 비동기적으로 반응하는 구조

• 이벤트 기반 아키텍쳐는 시스템의 각 구성요소들이 특정 이벤트에 반응하여 작업을 처리하는 방식
• 이벤트가 발생하면 이를 다른 서비스나 모듈이 구독하고, 이벤트가 도착하면 해당 작업을 비동기적으로 처리하는 구조
  • 구성 요소
    • 프로듀서 : 발생
    • 컨슈머 : 구독, 처리
    • 브로커 : 전달

비동기 메시징 시스템의 확장성과 안정성 보장

• 확장성 : 메시지 큐나 이벤트 버스는 필요에 따라 소비자 또는 서비스 인스턴스를 동적으로 추가할 수 있어, 대규모 트래픽을 처리하기 위한 확장성을 보장
• 안정성 : 각 서비스가 독립적으로 동작할 수 있어 시스템의 한 부분에 문제가 생기더라도 전체 시스템이 중단되지 않고 작동

--> 즉 비동기 메시징 시스템은 프로듀서와 컨슈머가 독립적으로 동작하며, 서로 직접적으로 데이터를 주고받지않고 메시지 큐나 이벤트 버스와 같은 중간 매체를 통해 통신

이벤트 버스

• 이벤트 버스는 시스템 내에서 발생하는 이벤트를 전달하는 비동기 메시징 시스템
• 이벤트는 시스템 내의 상태 변화나 사용자 액션에 의해 발생하며, 이를 처리하기 위해 비동기적으로 여러 서비스 간에 전달
  • 동작 원리
    • 이벤트 프로듀서 : 이벤트를 발생시키는 주체
    • 이벤트 버스 : 이벤트를 구독하고 있는 여러 서비스로 전달하는 역할
    • 이벤트 컨슈머 : 이벤트를 구독하고 있는 서비스

메시지 브로커

• 메시지 브로커는 메시지 큐나 이벤트 버스와 비슷한 개념이지만, 더 큰 범위에서 시스템 간 통신을 중개하는 역할
• 메시지 브로커는 서로 다른 애플리케이션이나 시스템 간에 비동기 메시지를 전달
• 레빗mq, kafka와 같은 도구
  • 주요 역할
    • 메시지 저장 : 메시지를 큐에 저장하여, 시스템이 메시지를 손실하지 않고 안정적으로 전달
    • 트래픽 분산 : 브로커는 트래픽을 효율적으로 분산시켜 시스템에 과부하가 발생하지 않도록 도와줌
    • 서비스 간 중재 : 서로 다른 시스템 간의 메시지를 중대하여, 각 시스템이 독립적으로 동작할 수 있도록 함
     

Apache Kafka

• 분산 처리 : Kafka는 클러스터로 구성되어 대규모 데이터를 분산 처리하며, 수평적으로 확장 가능
• 높은 처리량과 지연 시간 최소화 : Kafka는 고속의 데이터 처리량을 제공하며, 실시간 데이터 스트리밍 처리에서 매우 적합
• 토픽 기반 구조 : Kafka는 데이터를 토픽으로 관리, 프로듀서가 메시지를 특정 토픽에 게시하면, 이를 구독한 여러 소비자가 동시에 데이터를 처리할 수 있음
• 순서 보장 : Kafka는 각 파티션 내에서 메시지의 순서를 보장하며, 메시지의 손실없이 내구성을 보장하는 로그 저장 방식을 채택
• 내구성 보장 : 카프카는 데이터를 디스크에 저아하며 메시지의 손실을 방지하기 위해 복제 지원
•  

RabbitMQ

• 큐 기반 구조 : 프로듀서가 메시지를 큐에 넣고, 컨슈머가 그 큐에서 메시지를 가져가 처리하는 방식. 이는 메시지를 비동기적으로 처리하는데 적합
• 메시지 라우팅 : RabbitMQ는 메시지 라우팅 옵션을 제공하여, Direct Exchange, Fanout Exchange, Topic Exchange 등을 통해 특정 조건에 맞는 메시지를 큐로 전달
• 스케줄링 및 우선 순위 메시징 : 메시지에 우선순위를 설정할 수 있으며, 메시지의 스케줄링도 지원
• 내구성 있는 메시지 저장 : 메시지를 디스크에 저장하여 시스템 장애 발생 시에도 메시지 손실 방지
• 확장성 : 클러스터링을 통해 확장할 수 있으며, 분산처리 환경에서도 높은 가용성 제공

Amazon SQS (Simple Queue Serive)

• 완전 관리형 서비스 : AWS가 시스템을 관리, 사용자는 인프라를 신경쓰지 않고 서비스 구축
• 자동 확장 : 트래픽 변화에 따라 자동으로 확장. 대규모 메시지 트래픽을 처리할때 추가적인 설정 없이 시스템이 자동으로 대응
• 메시지 전달 보장 : 최소 한번 메시지를 전달하는 At leas once 방식이 기본으로 제공, FIFO선택하면 순서를 보장
• 지연 큐 : 메시지를 일정시간동안 대기시킨 후 처리할 수 있는 지연 큐 기능을 제공. 특정 조건에서 메시지를 지연 처리해야 할 때유용
• 비용 효율성 : 클라우드 기반 서비스로. 사용한 만큼만 지불

메시징 시스템 선택시 고려사항

• 처리속도
  • 메시징 시스템의 처리 속도는 시스템의성능을 결정짓는 중요한 요소
  • 높은 처리량을 필요로 하는 시스템에는 Kafka가 적합 (로그 기반의 메시징 처리에 최적화)
  • 높은 신뢰성과 정밀한 메시지 전달이 중요하다면 RabbitMQ가 유리 (메시지 라우팅에 유리)
• 메시지 전달 보장
  
  • 메시지가 반드시 한번 정달되는지 (Exactly Once)
  • 최소 한번 전달되는지 (At least once)
  • 적어도 한 번 이상 전달될 수 있는지 (At most once)
• 확장성
  • 시스템이 부하가 늘어났을때 대응할 수 있는 능력

CQRS (Command Query Responsibility Segregation)

• 명령(Command)과 조회(Query)를 분리하여 각각 독립저긍로 처리하는 아키텍쳐
• 명력은 데이터를 변경하는 작업, 조회는 데이터를 읽는 작업
  • 구성요소
    • Command Handler : 데이터를 변경하는 작업을 처리, 이때 메시지 큐를 사용해 명령이 큐에 저장되고, 비동기적으로 처리
    • Query Handler : 데이터를 조회하는 작업을 처리. 데이터 조회는 즉각적으로 처리될 수 있지만, 명령은 비동기적으로 처리되어 데이터 일관성을 유지
    • Event Soucing : 모든 상태 변경을 이벤트로 기록하고, 이벤트를 통해 시스템의 상태를 재구성하는 방식

사가 패턴

• 분산 트랜잭션을 처리할 때 사용되는 아키텍쳐 패턴, 각 서비스가 독립적으로 트랜잭션을 처리하지만, 전체 프로세스는 논리적으로 하나의 트랜잭션처럼 보이게 함
• 사가 패턴은 각 서비스에서 처리된 결과를 비동기적으로 전달받아 트랜잭션을 완성하거나 실패했을 경우 보상 작업을 수행
  • 구성 요소
    • Saga Coordinator : 트랜잭션의 시작과 종료를 관리하며, 중간에 트랜잭션이 실패할 경우 보상 작업을 실행
    • Local Transactions : 각 서비스에서 실행되는 독립적인 트랜잭션으로 각 서비스는 메시지 큐를 통해 비동기적으로 트랜잭셔 결과를 전달

백프레셔 패턴

• 시스템이 과부하 상태일때 요청을 거부하거나 처리 속도를 늦추는 방식으로 트래픽을 조절하는 아키텍쳐 패턴
• 비동기 메시징 시스템과 함께 사용되며, 대규모 트래픽 상황에서 시스템의 안정성을 보장하는데 도움
  • 구성 요소
    • 프로큐 셔 : ㅋ큐가 가득차면 백프레셔를 통해 메시지 생산을 중단하거나 늦춤
    • 컨슈머 : 큐에서 처리할 수 있는 메시지ㅡ이 양을 제어, 과부하 방지

Durable Message Pattern

• 메시지를 손실없이 처리할 수 있도록 보장하는 패턴
• 메시지가 중간에 손실되거나 누락되지 않도록 메시지를 저정하고, 시스템 장애 시에도 복구가 가능한 상태로 유지
  • 구성 요소
  • Persistent Queue :메시지가 시스템에 도착하면 큐에 영구적으로 저장, 메시지는 실패 시 재시도 될 수 있으며, 시스템이 복구된 후에도 메시지가 손실도지ㅣ 않음
  • Retry Mechanism : 실패한 메시지를 재처리, 메시지가 손실않도록 보장 

예시

푸시 알림 시스템에서의 비동기 처리

쿠폰 발급 시스템에서의 비동기 처리

채팅 시스템에서의 비동기 처리

실시간 주문 처리 시스템에서의 비동기 처리

이메일 발송 시스템에서의 비동기 처리

동시성

• 여러 작업이 동시에 진행되는 것처럼 보이도록 설계된 시스템
• 실제로는 대부분의 경우 단일 코어에서 여러 작업이 분할되어 교차로 처리
• 사용자는 각 작업이 동시에 실행되는 것처럼 느낌
• 멀티스레딩을 통해 각 작업을 독립적으로 실행 가능

웹 서버가 여러 클라이언트의 요청을 처리할때, 각 요청에 대해 별도의 스레드를 생성하거나 작업을 교차적으로 처리하여 병렬성을 제공

멀티스레딩 : 동시성 구현 방법

• 멀티스레딩은 하나의 프로세스 내에서 여러 스레드를 사용하여 동시성 처리를 구현
• 각 스레드는 독립적으로 실행되며, 자원을 효율적으로 사용하여 응답시간을 단축

• 병렬성 Parallelism
  • 병렬성은 물리적인 개념으로, 멀티 코어에서 여러 작업이 동시에 처리되ㅡㄴ것
  • 여러 코어가 동시에 각각 작업을 처리하기 때문에 실제로 작업이 동시에 수행
• 동시성
  • 동시성은 논리적인 개념으로, 싱글 코어에서 여러 스레드를 번갈아가며 빠르게 실행하여 마치 동시에 여러 작업이 수행되는 것처럼 보이게 만드는 방식

• 동시성 장점
  • 자원 효율성 : 시스템 자원을 최대한 활동하여 작업을 빠르게 처리
  • 응답성 : 여러 작업을 동시에 처리하여 대기 시간을 줄이고, 특히 사용자 인터페이스 UI에서 중요한 역할
• 동시성 단점
  • 스레드 관리 문제 : 여러 스레드를 생성하고 관리하는 것은 복잡하며, 교착상태, Race Condition 문제 발생
  • 동기화 문제 : 스레드가 공유 자원을 동시에 접근할 때, 적절한 동기화 메커니즘이 없다면 데이터 손상이 발생
   비동기 처리

비동기 처리는 특정 작업이 완료될 때까지 기다리지 않고 다른 작업을 계속 진행할 수 있는 처리 방식

이는 작업이 완료될때 까지 대기하지 않기 때문에, 시스템은 그동안 CPU자원을 다른 작업에 할당할 수 있음

작업이 완료되면 콜백이나 이벤트를 통해 결과를 알리고, 그 결과에 대한 추가 작업 수행

- 네트워크 요청 작업

- 파일 다운로드, 사용자 인터페이스

• 비동기 장점
  • 병목 현상 완화 : 비동기 처리는 긴 시간이 소요되는 작업이 진행되는 동안 시스템 자원을 더 효율적으로 사용할 수 있게함
  • 성능 개선 : 특히 네트워크 요청이나 파일 입출력같은 작업에서 유용
• 비동기 단점
  • 코드 복잡성
  • 오류 처리의 어려움

동기와 비동기 차이

- 동기는 작업이 순차적으로 실행, 하나의 작업이 완료되기 전까지 다른 작업을 시작하지 않으며, 작업 완료를 기다린 후 다음 작업을 수행

- 비동기 처리 방식은 작업을 요청한 후 기다리지 않고 다른 작업을 처리할 수 있음. 작업이 완료되면 그 결과를 나중에 처리할 수 잇으며, 작업이 완료 될때 콜백 또는 이벤트를 통해 알림

스레드 풀

• 미리 생성된 스레드의 집합으로, 작업이 들어올 때마다 새로운 스레드를 생성하는 대신, 이미 생성된 스레드를 재사용하여 작업을 처리
• 스레드 풀을 사용하면 스레드 생성 및 소멸에 대한 오버헤드를 줄일 수 있어, 동시성 처리에서 자원을 효율적으로 관리

• 스레드 풀은 여러 작업을 동시에 처리하기 위해 미리 생성된 스레드의 집합을 유지
• 스레드 풀에 작업을 제출하면, 해당 작업이 스레드 풀의 사용 가능한 스레드에 할당
• 스레드가 작업을 마치면, 그 스레드는 다른 작업에 할당되기 전까지 대기 상태

스레드 풀 고려 요소

• 스레드 풀의 크기
• 작업의 종류 (CPU 집약적(CPU 코어에 맞게), I/O 집약적 (많은 스레드))
• 스레드 생성과 파괴 비용
• 메모리 사용량
• 동기화 문제
• 응답 시간과 처리량

• 이벤트 루프는 비동기 처리를 위한 구조로, 하나의 스레드가 여러 작업을 순차적으로 처리하는 방식
• 입출력 작업에서 매우 효율적 I/O
• 이벤트 루프는 단일 스레드 기반으로 동작하며, 비동기 작업이 완료될때마다 이벤트 큐에 있는 작업을 처리

이벤트 루프가 입출력 작업에 적합한 이유

• 논블로킹 I/O 모델
• 효율적인 자원 사용
• 반응성 유지

비동기 작업의 오류 처리 및 콜백 패턴

• 콜백 패턴
  • 콜백 함수는 비동기 작업이 완료된 후 실행될 작업을 미리 등록해 두는 방식
  • 단순하고 효율적이지만 콜백 지옥이라 불리는 복잡한 구조가 될 수 있음

• CompletableFuture
  • 비동기 작업의 결과를 비동기적으로 처리할수있는 API
  • JavaScript의 Promise와 유사하며, 비동기 작업이 완료되면 그 결과를 사용해 후속 작업을 정의 가능

비동기 처리시 유의사항

- 스레드 안전성 : 스레드가 공유 자원에 접근할 때, 적절한 동기화 메커니즘 (ex. synchronized)

- 예외 처리 필요 : CompletableFutre에서 exceptionally()를 사용하여 비동기 작업에서 발생한 예외 처리