프로젝트 구상하기

오늘은 프로젝트 구상을 위해 조사하는 날입니다.

오늘 학습

• 스프링 배치
• 프로젝트 구상

스프링 배치

스프링 배치를 학습하기 전에 배치 처리에 대해 의미를 알아보겠습니다.

배치 처리(Batch Processing)

컴퓨터 시스템에서 여러 작업이나 데이터를 한 번에 모아서 처리하는 방식을 의미합니다. 주로 대규모 데이터를 처리하거나 주기적으로 수행하는 작업에 사용됩니다.

배치 특징

• 일괄 처리: 데이터를 실시간으로 처리하는 것이 아니라, 일정량을 모아서 한꺼번에 처리한다.
• 자동화: 배치 처리는 주로 정해진 스케줄에 따라 자동으로 실행됩니다. 예를 들어 매일 밤 특정 시간에 실행되는 데이터베이스 테이블 정보를 다른 테이블로 프로세스 진행 후 재등록.
• 비상호작용: 배치 처리는 사용자와의 상호작용 없이 백그라운드에서 수행됩니다.
• 대규모 데이터 처리: 대용량의 데이터를 효율적으로 처리할 수 있다.

배치 처리와 실시간 처리의 비교

사용자가 물건을 구매하는 행동은 주문을 처리하는 실시간 트랜잭션이 발생합니다. 반면에, 하루가 마감되거나 월말 정산과 같은 작업은 실시간으로 할 필요가 없으며, 사람의 개입 없이 자동으로 진행됩니다.

배치 핵심 패턴

• Read: 데이터베이스, 파일, 큐에서 다량의 데이터를 조회한다.
• Process: 특정 방법으로 데이터를 가공한다.
• Write: 데이터를 수정된 양식으로 다시 저장한다.

배치의 Read, Process, Write는 ETL(DB 용어) 프로세스와 동일합니다.

• Extract: 데이터 소스로부터 데이터를 추출하는 단계입니다. (데이터베이스, 파일 시스템, 웹 서비스, 로그 파일 등)
• Transform: 추출된 데이터를 비즈니스 요구사항에 맞게 변환하는 단계입니다.
• Load: 변환된 데이터를 대상 시스템에 적재하는 단계입니다.

배치 프로그래밍은 Input과 Output을 결정하면 모든 작업을 스프링 배치화 할 수 있습니다.

• 파일 > DB
• 파일 > 파일
• DB > 파일
• DB > DB
• DB > 메일 발송
• API > DB

배치 상황

• 배치 프로세스를 주기적으로 COMMIT 할 때: 큰 데이터를 한번에 데이터베이스에 넣는 경우 위험부담과 리스크가 발생합니다. 이런 경우 일정한 단위로 데이터를 분류나 나누어서 commit을 하는 과정이 필요합니다. 이때 최소한의 자원으로 최대한의 성능을 낼 수 있도록 스프링 배치는 다양한 Commit 전략을 제공합니다.
• 대용량 병렬 처리와 다양한 Job의 배치 처리가 필요할 때: 여러 개의 동시다발적인 일을 처리하고, Job끼리 간섭이 없도록 하며 대용량일 경우 멀티쓰레드를 활용하여 병렬 처리로 성능을 높이고 시간을 단축시킬 수 있는 기능이 필요합니다.
• 작업 실패 후 수동이나 스케줄링에 의해 재시작이 필요할 때: 작업 도중 예외는 언제든지 발생할 수 있으므로 빠른 대처가 필요합니다. 스프링 배치는 수동이나 스케줄링에 의한 재시작 옵션을 제공합니다.
• Job의 의존 관계가 있는 여러 step들이 순차적으로 처리해야 될 때: step 1 > step 2 > step 3 … 순차적으로 단계를 밟아서 배치 처리되는 기능이 필요합니다.
• 조건에 따라 체계적이고 유연한 Flow 구성이 필요할 때: 특정 A 조건일 경우 step 1 > step 2 가 아닌 바로 step 3가 실행 가능한 유연성이 필요합니다.
• 특정 상황에 반복이나 재시도, Skip이 필요할 때: 네트워크 장애나 서버가 불안정하여 전체 실행 Job이 실패하는 것이 아니라, 예외 상황에서도 반복하거나 특정 구간을 skip하는 기능이 제공되어야 합니다.

스프링 배치와 자바 스프링 생태계

스프링 배치는 기존 스프링 생태계에서 사용하던 기능과 도구를 그대로 활용할 수 있다는 장점이 있습니다. 새로운 프레임워크를 학습하는 것보다 기존 지식을 최대한 활용할 수 있습니다.

스프링의 자동 설정(AutoConfiguration)과 의존성 주입 기능을 활용하여 배치 작업을 간편하게 할 수 있으므로 배치 작업 개발 속도를 높이고 설정 오류를 줄여줄 수 있습니다.

정리해보면, 기존 스프링 인프라를 사용하고 있다면 쉽게 통합할 수 있으므로, 아키텍처의 일관성과 효율을 높일 수 있습니다.

POJO 기반 개발

스프링 환경과 동일한 POJO를 기반으로 하기 때문에 복잡하지 않고 간단하고 직관적인 코드를 작성하도록 도와줍니다.

단위 테스트와 통합 테스트가 용이하여, 안정적인 애플리케이션 개발과 유지보수를 지원합니다.

결론

스프링 배치는 자바 개발자에게 다음과 같은 이유로 유용합니다:

1. 통합성 및 일관성: 기존 스프링 생태계와 통합되어 일관성 있는 아키텍처를 유지할 수 있다.
2. 자동 설정 및 의존성 관리: 설정 작업을 단순화하고, 의존성 주입을 통해 코드의 가독성과 유지보수성을 향상시킨다.
3. 강력한 배치 처리 기능: 대규모 데이터를 효율적으로 처리할 수 있는 강력한 기능을 제공한다.
4. 유연한 배치 구성: 다양한 조건에 따라 유연한 배치 작업 구성을 지원한다.
5. POJO 기반 개발: 간단하고 직관적인 코드를 작성할 수 있다.
6. 커뮤니티와 문서: 풍부한 문서와 활발한 커뮤니티 지원으로 문제 해결이 용이하다.
7. 검증된 솔루션: 오랜 시간 동안 검증된 안정적인 솔루션이다.
8. 유지보수 및 확장성: 모듈화된 구조와 설정 파일 기반 구성을 통해 유지보수와 확장이 용이하다.

이러한 이유들로 인해 자바 개발자가 배치 작업을 수행할 때 스프링 배치를 사용하는 것이 매우 유리합니다.

스프링 배치를 활용하면 대규모 데이터 처리 작업을 효율적이고 안정적으로 수행할 수 있으며, 개발 생산성을 높이고 유지보수 비용을 줄일 수 있습니다.

레디스

소프트웨어의 핵심은 데이터입니다. 프로젝트 규모와 관리하는 데이터 종류에 따라 올바른 데이터 저장소를 선택하는 것은 비즈니스 운영을 안전하게 하기 위해 중요합니다.

요구사항의 변화

소프트웨어에서 관리해야하는 데이터의 형태를 구조화 하기 어려워졌다.

NoSQL가 등장한 이유는 RDBMS가 특정 시나리오에서 가지는 한계를 보완하기 위해서 입니다.

특히 데이터 구조가 복잡하고 동적이며 대량의 비정형 데이터를 빠르게 처리 해야 하는 경우에는 NoSQL이 적합할 수 있습니다.

NoSQL

NoSQL이란 용어는 No SQL 혹은 Not Only SQL을 의미합니다. 말 그대로 관계형 데이터베이스에서 테이블의 데이터를 쿼리하기 위한 SQL을 사용하지 않는 데이터 저장소를 나타냅니다. 관계형 데이터 베이스와 다르게 관계가 정의돼 있지 않은 데이터를 저장한다는 공통적인 특징이 있으며 데이터 저장 방식에 따라 여러 타입이 존재합니다.

RDBMS 보완

1. 수평적 확장성
   RDBMS도 수평적 확작을 지원하는 기술이 있습니다, 샤딩을 통해서 구현할 수 있지만 NoSQL은 기본적으로 수평적 확장을 염두하고 설계되어 수평적 확장이 더 간편하고 효율적입니다.
2. 동적 데이터 구조
   RDBMS에서도 JSON 타입 데이터를 저장하고, 인덱스를 추가할 수 있는 기능이 추가되었습니다. 하지만 NoSQL 데이터베이스는 스키마가 없거나 매우 유연한 스키마를 제공하기에, 동적 데이터를 처리하기에는 더 자연스럽고 효율적입니다.
3. 조인과 성능저하
   데이터 정규화와 테이블 관계로 복잡한 조인의 경우 성능이 저하될 수 있지만, 인덱스 설계와 최적화를 통해 조인의 성능 문제를 완화할 수 있습니다. 하지만 NoSQL 데이터베이스는 조인을 피하고 데이터 중복을 허용하여 성능을 향상시킬 수 있다는 점이 있습니다.
4. 대용량 로그 데이터와 소셜 미디어 데이터 처리
   RDBMS에서도 대용량 데이터를 처리하는 기법중 파티셔닝이나 인덱스 최적화를 통해 개선할 수 있지만, 대량의 비정형 데이터를 처리하는데 특화되었고 분산 처리와 빠른 쓰기 성능을 제공하므로 실시간 데이터 처리는 NoSQL이 적합할 수 있습니다.
5. 읽기/쓰기 성능 병목
   RDBMS는 트랜잭션의 일관성을 보장하여 ACID 속성을 유지하기 위해 성능 저하가 발생할 수 있습니다. NoSQL은 일관성 보다 가용성과 분산성을 중시하여 성능을 최적화했습니다. 이는 CAP 이론에 기반한 설계 철학에 기인합니다.

CAP 이론

CAP 이론은 분산 컴퓨팅 시스템의 세 가지 기본 속성인 일관성(Consistency), 가용성(Availability), 네트워크 분할 허용성(Partition Tolerance) 간의 관계를 설명하는 이론입니다. CAP 이론은 모든 분산 시스템이 이 세 가지 속성을 동시에 완벽히 만족할 수 없다는 것을 의미합니다.

인메모리 DB

데이터를 디스크가 아닌 주로 메모리(RAM)에 저장하고 관리하는 데이터베이스 시스템입니다. 이 방식은 디스크 기반 데이터베이스 시스템보다 매우 빠른 데이터 접근 속도를 제공하여, 실시간 응답성과 성능이 중요한 애플리케이션에서 많이 사용됩니다.

레디스와 Memcached

웹 개발에서 가장 많이 사용되는 인메모리 데이터 스토리지로 강력한 캐싱 기능과 분산 아키텍처를 갖추고 있습니다.

그러면 어떤 차이가 있는지 학습해봣습니다.

Memcache

자주 액세스하는 데이터를 캐시하여 데이터베이스 부담을 줄여 응답 시간을 단축하는 것이 목적

Memcache의 원칙 중 하나는 단순함과 속도에 대한 강조입니다.

Redis

캐싱 기능을 넘어 다양한 데이터 유형과 트랜잭션을 지원하며 pub/sub 메세징을 허용합니다.

비교

특징	Memcached	Redis
데이터 구조 및 스토리지	간단한 키-값 저장소. 문자열 및 객체 지원	문자열, 해시, 리스트, 세트, 정렬된 세트, 비트맵 등 다양한 데이터 구조 지원
성능 및 확장성	수직적 확장. 캐싱 풀에 서버 추가 가능	수평적 확장. 클러스터 지원. 비동기 I/O 작업과 비차단 I/O 작업 가능
지속성 및 내구성	메모리 내 작동. 기본적으로 내장된 지속성 없음. 최근 버전은 DAX 파일 시스템 마운트를 통해 영구 메모리 지원	스냅샷과 추가 전용 파일(AOF) 방법을 통한 데이터 지속성 제공. 시스템 장애 시 데이터 복구 가능
기능 및 확장성	단순한 캐싱 기능 제공. 제한된 데이터 유형 지원	트랜잭션, 게시/구독 메시징, Lua 스크립팅 등 다양한 기능 제공. 고급 데이터 구조와 데이터 조작 기술 지원
주요 사용 사례	웹 애플리케이션 속도 향상, 단순 키-값 스토어, 기본 캐싱	고급 데이터 구조 지원, 실시간 분석, 메시지 중개, 데이터 지속성 요구 프로젝트
캐싱 기능	간단한 캐싱 기능으로 자주 액세스되는 데이터의 빠른 검색에 적합	고급 캐싱 기능으로 복잡한 데이터 모델 캐싱 가능. 실시간 분석 및 스트리밍 데이터 처리에 적합
데이터 지속성	시스템 장애 시 자동 데이터 저장 없음. 최근 버전에서 데이터 복구 지원	스냅샷 및 AOF 메커니즘을 통해 시스템 장애 시 데이터 복구 가능

• Memcached: 단순성과 고성능에 초점을 맞추고 있으므로 간단한 캐싱 요구사항이 있는 경우에 적합
• Redis: 캐싱 이외의 고급 기능이 필요한 경우 적합

성능 비교

Memcached는 Redis에 비해 안정적인 속도를 자랑합니다. 트래픽이 많아질 때 Redis는 응답 속도가 불안정하다는 이슈가 있습니다.

왜 일까?

메모리를 관리하는 방식의 차이가 있습니다.

• Redis : Jemalloc
• Memcached: Slab Allocator

Slab Allocator가 메모리 파편화를 줄일 수 있는 근본적인 이유는 고정된 크기의 메모리 블록을 사용하여 항상 동일한 크기의 블록을 할당하고 해제하기 때문입니다. 반면, Jemalloc은 다양한 크기의 블록을 동적으로 할당하고 해제하므로, 메모리 블록 사이에 빈 공간이 생겨 파편화가 발생할 수 있습니다. Slab Allocator의 고정 크기 블록 접근 방식은 메모리 사용의 효율성을 높이고, 파편화를 줄이는 데 도움이 됩니다.

레디스는 싱글 스레드다

멀티 쓰레드인 자바와 다르게 싱글 스레드로 동작합니다. 싱글 스레드의 장점은 동기화를 하지 않아도 되며 순서대로 처리를 할 수 잇다는 장점이 있지만, 멀티 쓰레드와 다르게 실행중인 작업이 오래 걸릴 경우 다른 작업에도 영향을 줄 수 있다는 점을 주의해야합니다.

활용할 수 있는 레디스 기능

1. 캐싱: 자주 조회되는 데이터( 세션, API 응답)을 캐싱하여 데이터베이스 부하 감소 및 응답 시간 단축
2. 실시간 분석: 실시간 로그 분석, 실시간 통계 계산 등 대용량 데이터를 빠르게 처리 및 분석
3. 메세지 브로커: Pub/sub 기능을 활용하여 채팅이나 실시간 알림 시스템 구현 가능
4. 순위표 관리: 정렬된 셋을 사용하여 사용자 점수와 순위를 관리하는 리더보드 구현가능
5. 지리 기반 서비스: 위치 기반 서비스등을 제공할 수있음