12. 데이터 시스템의 미래
·
Book/데이터 중심 애플리케이션 설계
❒ 개요이번 장에서는 미래에는 어떻게 돼야 하는지에 대해서 설명함.앞에서 배운 아이디어들을 함께 모아 그것을 기반으로 미래를 고찰하자. ❒ 1. 데이터 통합가장 적절한 소프트웨어 도구를 선택하는 것은 상황에 따라 다름.선택의 폭이 넓은 경우소프트웨어 제품과 그 제품고가 잘 어울리는 환경 사이의 대응 관계를 파악하는 것복잡한 환경에서는 데이터를 여러 가지 다른 방법으로 사용하기 때문에, 소프트웨어가 모든 상황에 대처할 가능성이 낮음. 🌀 1-1. 파생 데이터에 특화된 도구의 결합개요 OLTP용 데이터베이스(트랜잭션 처리 DB)만으로는 임의 키워드 검색(full-text search) 같은 걸 잘 처리하기 어려움.PostgreSQL 같은 DB도 풀텍스트 기능을 제공하지만복잡하고 정교한 검색을 ..
11. 스트림 처리
·
Book/데이터 중심 애플리케이션 설계
❐ 0. 개요현실 세계에서 데이터는 무한하고(unbounded) 시간이 지나면서 계속(gradually) 유입된다.이번 장에서는 데이터 관리 메커니즘으로 이벤트 스트림을 설명한다.이벤트 스트림은 일과 처리 데이터와는 반대로 한정되지 않고 점진적으로 처리된다.일반적으로 "스트림"은 시간에 흐름에 따라 점진적으로 생산된 데이터를 일컫는다. ❐ 1. 이벤트 스트림 전송Polling 방식의 한계 파일이나 데이터베이스만으로도 생산자와 소비자는 연결될 수 있다. 생산자는 자신이 생성한 모든 이벤트를 저장소에 기록 소비자는 주기적으로 저장소를 polling하여 마지막 실행 이후 새로 생긴 이벤트를 확인 이런 방식은 하루치 데이터를 하루가 끝날 때 처리하는 배치 처리와 유사 하지..
10장. 일괄 처리(Batch Processing)
·
Book/데이터 중심 애플리케이션 설계
❐ 0. 개요시스템 구축 방법의 세 가지 유형➔ 온라인 시스템이 유일한 시스템 구축 방법은 아니다.서비스 (온라인 시스템)응답 시간은 서비스 성능 측정의 중요한 지표일괄 처리 시스템 (오프라인 시스템)매우 큰 입력 데이터를 받아 데이터를 처리하는 작업을 수행그리고 결과 데이터를 생산스트림 처리 시스템 (준 실시간 시스템)온라인 서비스와 일관 처리 시스템 사이의 어딘가..입력 이벤트가 발생한 직후 바로 작동 ❐ 1. 유닉스 도구로 일괄 처리하기🌀 1-1. 단순 로그분석# 웹 사이트에서 가장 인기 높은 체이지 5개cat /var/log/nginx/access.log | awk '{print$7}' | sort | uniq -c | sort -r -n ..
Part3. 파생 데이터 (Derived Data)
·
Book/데이터 중심 애플리케이션 설계
❐ 정리1부와 2부에서는분산 데이터베이스로 가기 위해 고려해야 할 모든 주요 사항을 밑바닥 부터 다뤘음.하지만 1,2부에서는 애플리케이션이 단일 데이터베이스를 사용한다고 가정했음.3부에서는다양한 특징을 가지는 여러 데이터 시스템을 일관성 있는 하나의 애플리케이션 아키텍처로 통합하는 문제에 대해서 검토한다. ❐ 레코드 시스템과 파생 데이터 시스템➔ 데이터를 저장하고 처리하는 시스템은 크게 두 분류로 나눌수 있음. 레코드 시스템믿을 수 있는 데이터 버전을 저장한다.진실의 근원(source of truth)라고도 한다.각 사실은 일반적으로 정규화를 거쳐 정확하게 한 번 표현된다. 파생 데이터 시스템다른 시스템에 존재하는 데이터를 가져와 특정 방식으로 변환하고 처리한 결과파생 데이터를 잃게 되..
9장. 일관성과 합의 (Consistency and Consensus)
·
Book/데이터 중심 애플리케이션 설계
❐ 0. Description이번장 에서는..내결함성을 지닌 분산 시스템을 구축하는데 쓰이는 알고리즘과 프로토콜의 몇 가지 예를 얘기한다.그리고 8장에서 설명한 모든 문제가 발생할 수 있다고 가정한다.시간은 최선을 다하더라도 근사치 밖에 쓸 수 없다.노드는 멈출 수 있고, 언제라도 죽을 수 있다. 내결함성을 지닌 시스템을 구축하는 가장 좋은 방법은?유용한 보장을 해주는 범용 추상화를 찾아 이를 구현하고 애플리케이션에서 이 보장에 의존하는 것.그니깐 모든 애플리케이션에서 각자 장애 복구 로직을 구현하는 건 비효율 적임 대신 신뢰성 있는 공통 추상화 계층을 만들어서, 그 위에 애플리케이션을 올리면 각 앱은 그 보장(트랜잭션, exactly-once)에 의존해 더 안전하게 동작할 수 있음..
8장. 분산 시스템의 골칫거리(The Trouble with Distributed Systems)
·
Book/데이터 중심 애플리케이션 설계
분산 시스템을 다루는 것은 단일 컴퓨터에서 소프트웨어를 작성하는 것과 근본적으로 다르다.결국 엔지니어로서 우리의 과제는 모든 것이 잘못되는 와중에도 시스템이 자신의 일을 하도록 만드는 것9장에서 우리는 분산 시스템에서 그러한 보장을 제공할 수 있는 알고리즘의 예를 살펴보겠습니다. ❐ 1. 결함과 부분 장애(Faults and Partial Failures)부분장애란?분산 시스템에서는 시스템의 어떤 부분은 정상 동작하지만, 어떤 부분은 아닐 수도 있다는 것부분장애는 비결정적(nondeterministic) ➔ 같은 조건에서도 결과가 매번 달라질 수 있음.이런 비결정성과 부분 장애 가능성이 분산 시스템을 어렵게 만듬. 🌀 1-1. Cloud Computing and Supercomputing대규모 컴퓨팅 ..
Common Batch Patterns
·
Book/Spring Batch docs
일부 배치 작업은 Spring Batch에서 제공하는 기성(ready-made) 컴포넌트만으로도 구성할 수 있다.예를 들어, ItemReader와 ItemWriter 구현체들은 매우 다양한 시나리오를 커버할 수 있다.하지만 실무에서는 완벽히 일치하지 않는 요구사항이 많기 때문에, 일부 구간(특히 쓰기/처리)은 직접 구현해야 할 수도 있다.이 장에서는 커스텀 비즈니스 로직에서 자주 사용되는 몇 가지 공통 패턴의 예시를 제공한다.이러한 예시들은 주로 Listener 인터페이스를 활용한 것들이다. 또한, 필요하다면 ItemReader나 ItemWriter도 Listener 인터페이스를 직접 구현해야 할 수도 있다. ❐ 1. Logging Item Processing and Failures🧩 Step 내에..
Retry
·
Book/Spring Batch docs
❐ RetryRetryBatch 처리에서 일시적인 오류(transient error) 때문에 전체 작업이 실패하는 걸 방지하기 위해, 자동 재시도(retry) 메커니즘을 제공한다.예를 들어 이런 경우에 유용하다.네트워크 일시 장애로 API 호출 실패DB Deadlock 발생 (DeadlockLoserDataAccessException)외부 시스템 응답 지연실패 시 바로 중단하지 않고 일정 횟수까지 재시도 하는 방식으로 안정성을 높인다. Retry 기능의 분리Spring Batch 2.2.0 이후, Retry 기능은 별도의 라이브러리로 분리됐다.예전엔 RepeatTemplate 내부에서 Retry 로직을 직접 포함했지만지금은 Spring Retry가 RetryTemplate, BackOff, Po..