선택지 ▶ Beats - Elasticsearch - Kibana ▶ Logstash - Elasticsearch - Kibana ▶ Beats - Logstash - Elasticsearch - Kibana | Beats - Elasticsearch - Kibana - 경량화된 로그 파일 수집 에이전트 사용

• 데이터 처리 불가 (변환은 필요 시 Elasticsearch의 Ingest Pipeline 사용)
• 경량화, 자원 사용 적음
• 간단한 설정
• 단순 로그 파일 수집, 경량 환경

Logstash - Elasticsearch - Kibana - 다양한 소스에서 직접 수집, 변환 및 전송 가능

• 복잡한 필터링 및 변환 작업 가능
• 자원 사용이 많음
• 복잡한 설정
• 복잡한 로그 처리 및 다양한 소스 수집

Beats - Logstash - Elasticsearch - Kibana - Beats로 수집하고 Logstash로 변환 후 전송

• Logstash로 복잡한 데이터 처리 및 변환 가능
• 자원 사용은 중간 정도 (Beats 경량, Logstash 자원 소모)
• 중간 (Beats와 Logstash 모두 설정 필요)
• 경량 수집 및 복잡한 처리 모두 필요한 경우

| 본 프로젝트는 로그의 변환 과정이 필요하지 않기 때문에, 자원을 거의 소모하지 않는 경량화된 에이전트인 Beats를 사용하여 로그를 수집하기로 결정하였습니다. | | 실시간 데이터 유저에게 전달 | 선택한 기술 ▶ Apache Kafka - Redis(Pub/Sub)

선택지 ▶ Apache kafka - RabbitMQ | Kafka-Redis

• 빠른 실시간 데이터 전송을 위해 Kafka로 데이터를 수집하고 Redis Pub/Sub을 통해 빠르게 다수의 구독자에게 동일한 메시지를 전달하는 데 적합.

~~Kafka-RabbitMQ~~

• Kafka로 데이터를 수집하고 RabbitMQ의 다양한 라우팅 및 메시지 제어 기능을 활용하여 구독자별 맞춤 메시지를 조건에 따라 효율적으로 전달하는 데 적합. | Redis Pub/Sub을 선택한 이유는 빠른 속도, 단순한 구조, 낮은 리소스 사용, 그리고 쉬운 운영이라는 장점이 있기 때문입니다. RabbitMQ에 비해 복잡한 메시지 라우팅이 필요하지 않고, 실시간 데이터 처리에서 Redis의 성능을 더 잘 활용할 수 있습니다. 하지만 복잡한 메시지 라우팅이나 **조건부 전달 기능을 지원하지는 않습니다.

현재 실시간 데이터의 처리를 우선시하며 그 후 유저에게 전달하는 과정을 userId 별 websocket 으로 전달하는 방식으로 구현하고자 하였다.** | | 성능 테스트 | 선택한 기술 ▶ Apache Jmeter

선택지 ▶ PinPoint | Apache JMeter - 다양한 프로토콜을 지원하여 대규모 트래픽 모방 가능

• 자원 사용이 적으며, 서버의 부하 테스트에 적합
• 오픈소스 툴로 비용이 발생하지 않음
• 직관적인 GUI로 사용하기 쉬워 빠른 테스트 환경 구축 가능
• 다양한 참조 자료와 커뮤니티 지원이 풍부함

PinPoint

• 애플리케이션 코드 수준의 성능 추적 가능
• 많은 트래픽이 발생할 경우 데이터 양이 폭발적으로 증가함
• 분산 트랜잭션 모니터링에 강점
• 서버 자원 소모가 많아 대규모 부하 테스트에는 부적합
• 성능 병목 지점을 세부적으로 파악할 수 있음 | 대규모 트래픽 생성 시에도 안정적으로 테스트를 수행할 수 있는 점을 중요시 하였고 오랜 기간 사용되어온 툴이기 때문에 참고 자료와 커뮤니티 지원을 통해 문제 해결이 용이하다고 판단하였습니다. | | 검색 성능 개선 | 선택한 기술 ▶ Elastic Search

선택지 ▶ QueryDSL | Elasticsearch Elasticsearch는 분산형 검색 엔진으로, 대용량 데이터를 빠르게 처리하고 텍스트 기반 검색에서 매우 뛰어난 성능을 보입니다. 역색인 구조를 사용해 복잡한 검색 쿼리를 실시간으로 처리할 수 있으며, 확장성이 높아 대규모 데이터셋에서도 높은 성능을 유지합니다.

QueryDSL QueryDSL은 타입 안전한 쿼리 작성을 위한 Java 기반 라이브러리로, JPA와 함께 사용되며 동적 쿼리 작성에 용이합니다. 주로 RDBMS와 결합해 사용되며, SQL과 유사한 방식으로 복잡한 조건 검색을 수행할 수 있습니다. | Elasticsearch는 대용량 데이터를 빠르게 검색하는 데 최적화되어 있으며, 특히 Dart API 를 통한 대용량의 공시 자료를 선택적으로 인덱싱할 수 있기 때문에 선택되었습니다. 대용량 데이터 처리에서 확장성과 성능을 고려할 때, Elasticsearch는 분산 아키텍처를 통해 복잡한 검색 요구 사항을 충족시킬 수 있습니다. | | 종목 조회 성능 개선 | 선택한 기술 ▶ Redis | Redis는 메모리 기반의 비관계형 데이터베이스로, 빠른 데이터 조회와 낮은 지연 시간을 제공하는 키-값 저장소입니다. 캐시로서 자주 사용되며, 데이터가 메모리에 저장되므로 읽기 및 쓰기 속도가 매우 빠릅니다. 또한, Pub/Sub 기능을 통해 실시간 데이터 스트리밍이 가능하고, 단순한 데이터 구조부터 복잡한 데이터 구조까지 지원합니다. | 종목 조회 성능 개선에서 Redis는 메모리 기반의 특성 덕분에 매우 빠른 조회 속도를 제공합니다. 자주 조회되는 종목 데이터를 캐싱함으로써 실시간 응답성을 확보하고, 데이터베이스의 부하를 줄여 대기 시간을 최소화할 수 있습니다. 특히 낮은 지연 시간과 고성능 캐싱을 통한 성능 개선이 필요한 경우 Redis는 최적의 선택입니다. | | Scheduler 의 데이터 처리 작업 개선 | 선택한 기술 ▶ Spring batch

선택지 ▶ AWS Lambda | Spring Batch 특징: Spring Batch는 대용량 데이터 처리를 위한 프레임워크로, 배치 작업을 효율적으로 관리하고 재사용 가능한 구성 요소를 제공합니다. Tasklet 기반으로 작업을 단순한 단계로 나눠서 처리할 수 있으며, 트랜잭션 관리, 로깅, 재시작 기능을 통해 안정적인 배치 처리가 가능합니다.

AWS Lambda 특징: AWS Lambda는 서버리스로서, 이벤트 기반으로 자동 스케일링되는 무상태 함수를 실행합니다. 설정과 관리가 간단하며, 특정 이벤트 발생 시 코드를 자동으로 실행하고 리소스 사용에 따른 비용만 청구됩니다. | Spring Batch는 트랜잭션 관리와 대용량 데이터 처리에 강점을 가지고 있으며, 특히 Tasklet 기반으로 작업을 세분화해 단계별로 관리하기가 용이합니다. 데이터 처리 작업이 반복적이고 복잡한 경우, Spring Batch는 재시작 기능과 상태 관리에서 우수한 성능을 발휘하며, 작업의 복잡성을 효과적으로 제어할 수 있기 때문에 선택했습니다. AWS Lambda는 서버리스의 이점이 있지만, 대용량 데이터 처리 및 세분화된 트랜잭션 관리 측면에서 Spring Batch가 더 적합하다고 판단되었습니다. | | Redis 장애 대응 구축 | 선택한 기술 ▶ Redis Sentinel

선택지 ▶ Redis Clustering | Redis Sentinel

• Redis Sentinel은 고가용성을 보장하며, 마스터 장애 발생 시 자동으로 Failover를 수행하고 슬레이브를 새로운 마스터로 승격하여 지속적인 서비스를 보장.

Redis Clustering

• Redis Clustering은 수평적 확장성을 제공하며, 데이터를 여러 노드에 분산하여 대규모 데이터를 처리할 수 있게 해줌. | Redis pub/sub 기능을 주로 활용하여 실시간 데이터 처리를 하는 경우 데이터 분산과 확장성 보다는 메시지의 일관된 전달이 중요하다고 판단하였고 장애 조치와 고가용성을 주 목적으로 하였기에 Redis Sentinel 을 선택하였습니다. | | 실시간 데이터 처리 방법 | 선택한 기술 ▶ Apache Kafka

선택지 ▶ RabbitMQ | Kafka - 대규모 트래픽 처리와 높은 처리량, 내결함성 및 확장성에 강점을 가진 분산형 메시징 시스템.

RabbitMQ

• 복잡한 메시지 라우팅과 조건부 메시지 전달에 유리하며, 소규모 트래픽이나 유연한 메시지 흐름이 필요한 시스템에 적합. | 현재 프로젝트에서 대규모 트래픽 처리가 요구되기 때문에, Kafka의 높은 처리량, 내결함성, 그리고 수평 확장성이 RabbitMQ보다 적합했습니다. 특히, 실시간 데이터 처리에서 Kafka는 대규모 데이터 스트리밍을 안정적으로 처리할 수 있는 능력을 제공하여 프로젝트의 요구 사항에 맞았습니다. | | 기술 스택 성능 모니터링 | 선택한 기술 ▶ ElK Stack MetricBeats ▶ Promethues, Grafana | ELK Stack (Elasticsearch, Logstash, Kibana) + Metricbeat Metricbeat는 서버에서 CPU, 메모리, 디스크 사용량 등의 성능 데이터를 수집해 Elasticsearch에 전송하고 Kibana를 통해 실시간으로 시각화합니다.

Prometheus Prometheus는 시간별 데이터 수집 및 모니터링에 특화되어, Pull 방식으로 메트릭을 수집하고 시계열 데이터로 저장해 성능 변화를 추적할 수 있습니다.

Grafana Grafana는 다양한 데이터 소스를 시각화할 수 있는 대시보드 툴로, Prometheus와 Elasticsearch와 연동해 성능 데이터를 직관적으로 표현합니다. | 실시간 성능 모니터링, 시계열 데이터 수집, 그리고 시각화에 특화되어 있어, 시스템 성능을 정확하고 효율적으로 추적하고, 직관적으로 분석 및 대응할 수 있도록 해줍니다. ELK Stack과 Metricbeat로 로그 및 시스템 메트릭을 모니터링하고, Prometheus와 Grafana로 시계열 데이터와 성능 지표를 상세히 분석하는 것이 최적의 선택이었습니다 | | 클라이언트에게 실시간 데이터 송신 방법 | 선택한 기술 ▶ Websocket

선택지 ▶ SSE | WebSocket

• 양방향 통신을 지원하여 클라이언트와 서버 간 실시간 데이터를 상호 교환할 수 있는 프로토콜.

SSE (Server-Sent Events) - 단방향 통신을 통해 서버에서 클라이언트로 실시간 데이터를 푸시하는 프로토콜로, 클라이언트는 수신만 가능. | WebScoket 은 TCP 연결을 사용하여 저지연 전송이 가능하면 SSE 는 HTTP 기반으로 연결을 유지해야 하기 때문에 네트워크 지연이 Websocket 보다 클 수 있으며 대규모 트래픽 처리나 빈번한 데이터 업데이트가 필요한 경우에는 Websocket 이 빠를 수 있기에 선택하였습니다. |