HTTP란 무엇이며, 어떤 특징을 가지는가?

HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트와 서버 간 데이터를 주고받는 프로토콜로, 기본적으로 비연결형(Connectionless), 무상태(Stateless) 방식으로 동작합니다.

• HTTP 1.1: Keep-Alive 기능으로 다중 요청 가능
• HTTP 2: 멀티플렉싱(Multiplexing) 지원, 헤더 압축
• HTTP 3: UDP 기반의 QUIC 프로토콜을 사용하여 속도 개선

대규모 서비스의 데이터 폭발과 처리 전략

현대의 초대형 플랫폼은 수억 건, 때로는 수십억 건에 이르는 레코드와 수백 기가바이트에서 테라바이트 단위의 데이터를 다룹니다. 단순한 웹 애플리케이션과는 달리, 대규모 서비스는 데이터의 양뿐 아니라 실시간 처리, 정합성, 확장성 등 여러 측면에서 극복해야 할 도전 과제가 산적해 있습니다. 이번 글에서는 대규모 데이터 환경의 규모를 재조명하고, 그에 따른 시스템 성능 최적화 및 처리 전략에 대해 알아보겠습니다.

1. 대규모 데이터 규모, 상상을 초월하는 데이터 양

일반적인 웹 서비스가 수 기가바이트 단위의 데이터를 다루는 것과 달리, 초대형 서비스에서는 데이터 규모가 훨씬 큽니다. 예를 들어볼 수 있는 가상의 데이터 규모는 다음과 같습니다:

• entry 테이블: 8천만 건 이상 → 50GB ~ 100GB
• bookmark 테이블: 2억 건 이상 → 150GB 이상
• tag 테이블: 1억 건 이상 → 80GB ~ 100GB
• HTML 데이터: 압축 저장 시 1TB 이상, 일부 서비스에서는 10TB를 넘기도 함

더 나아가, Google, Facebook, Amazon과 같은 글로벌 플랫폼은 페타바이트(PB) 단위의 데이터를 처리하며, 데이터 레이크(data lake)나 분산 파일 시스템(HDFS, Amazon S3 등)을 활용해 저장 및 분석하고 있습니다.

2. 대규모 데이터베이스의 쿼리 처리와 병목 현상

이처럼 방대한 데이터를 다루다 보면, 단순한 쿼리 하나에도 상당한 부하가 발생합니다.

• 인덱스가 제대로 활용되지 않으면 단 한 건의 데이터를 찾는 데 수백 초가 걸릴 수 있습니다.
• 실제로 수십억 건의 레코드를 대상으로 한 단순 조회도 디스크 I/O, 네트워크 대역폭, CPU 처리 등 다양한 병목 구간 때문에 예기치 못한 지연을 발생시킵니다.

특히, 분산 시스템에서는 노드 간 데이터 일관성과 네트워크 지연 등도 고려해야 하므로 쿼리 최적화 및 인덱스 설계가 더욱 중요해집니다.

3. 메모리와 디스크, 그 속도의 괴리

대규모 데이터 처리의 핵심 문제 중 하나는 메모리와 디스크 사이의 속도 차이입니다.

(1) 메모리 vs. 디스크

• 메모리: 전기 신호 기반으로 데이터 접근 속도가 마이크로초(10^-6초) 단위로 매우 빠릅니다.
• 디스크: HDD의 경우 기계적인 헤드 이동과 원반 회전으로 인해 밀리초(10^-3초) 단위의 지연이 발생하며, SSD 역시 버스 및 컨트롤러의 한계로 메모리보다는 느립니다.

(2) 전송 속도 차이

• 실제 벤치마크에서는 메모리 전송 속도가 7.3GB/초에 달하는 반면, 디스크는 약 855MB/초 정도로 10배 이상의 차이가 발생합니다.
• 이런 차이는 대규모 데이터베이스에서 캐싱과 인메모리 데이터 처리의 필요성을 더욱 부각시킵니다.

4. 대규모 데이터 처리 전략과 최신 기술

대규모 데이터를 효과적으로 관리하기 위해선 단일 서버가 아닌 분산 시스템을 도입하는 것이 필수적입니다. 다음과 같은 전략들이 주로 활용됩니다.

인덱스 최적화와 쿼리 튜닝

• 인덱스 설계: 올바른 컬럼에 인덱스를 설정하면, 수십 기가바이트 또는 테라바이트 규모의 데이터에서도 원하는 정보를 빠르게 검색할 수 있습니다.
• 쿼리 최적화: 불필요한 전체 스캔을 피하고, 조건절을 최적화하여 데이터 접근 시간을 줄입니다.

분산 처리 및 샤딩(Sharding)

• 수평 확장: 데이터를 여러 서버에 분산 저장함으로써 하나의 서버에 과부하가 걸리지 않도록 합니다.
• 샤딩: 데이터를 일정 기준에 따라 여러 파티션으로 나누어, 각각의 샤드에서 독립적으로 쿼리를 처리하게 함으로써 전체 성능을 향상시킵니다.
• 분산 데이터베이스: Google의 Bigtable, Apache Cassandra, Amazon DynamoDB 등 분산형 데이터베이스는 데이터 일관성과 가용성을 유지하면서 수십 테라바이트 이상의 데이터를 효율적으로 관리합니다.

캐싱과 인메모리 처리

• 캐싱 계층: Redis, Memcached와 같은 인메모리 캐시는 자주 조회되는 데이터를 디스크 접근 없이 빠르게 제공하여 전체 시스템의 응답 속도를 높입니다.
• 데이터 레이크 및 분석 시스템: Apache Hadoop, Apache Spark 같은 프레임워크는 대용량 데이터에 대해 병렬 처리 및 실시간 분석을 가능하게 합니다.

하드웨어 혁신과 클라우드 인프라

• SSD 및 NVMe 드라이브: 최신 SSD나 NVMe 기반 스토리지는 전통적인 HDD보다 훨씬 빠른 데이터 접근 속도를 제공하며, 대규모 데이터 처리의 병목을 완화합니다.
• 클라우드 기반 솔루션: Amazon Web Services, Google Cloud Platform, Microsoft Azure 등은 확장성 높은 분산 스토리지와 컴퓨팅 자원을 제공하여, 데이터 규모가 커질수록 유연하게 대응할 수 있게 합니다.

5. 트러블슈팅과 지속적인 최적화

대규모 데이터 환경에서는 예상치 못한 문제들이 빈번하게 발생합니다. 이러한 문제를 해결하기 위해선 다음과 같은 접근 방식이 필요합니다.

• 모니터링과 로깅: 실시간 모니터링 도구를 활용하여 성능 병목과 장애를 조기에 감지합니다.
• 자동화된 스케일링: 시스템 부하에 따라 서버를 자동으로 추가하거나 축소하는 오토스케일링 기술이 중요합니다.
• 테스트와 피드백 루프: 실제 운영 환경과 유사한 테스트 환경을 마련해 다양한 시나리오를 검증하고, 시행착오를 통해 최적의 설정을 도출합니다.
• 전문가 네트워크와 커뮤니티: 다양한 사례와 최신 기술 정보를 공유하며, 문제 발생 시 빠른 해결책을 모색할 수 있는 네트워크가 큰 도움이 됩니다.

결론

대규모 서비스에서는 데이터의 양이 수십 기가바이트에서 테라바이트, 나아가 페타바이트 단위로 확장될 수 있으며, 이로 인해 발생하는 다양한 성능 및 정합성 문제를 해결하기 위한 기술과 전략이 필수적입니다.

• 메모리와 디스크의 속도 차이는 캐싱과 인메모리 데이터 처리의 필요성을 강조하며,
• 분산 처리와 샤딩은 단일 서버의 한계를 극복하는 핵심 전략입니다.
• 최신 클라우드 인프라와 하드웨어 혁신은 이러한 전략들을 현실화하는 데 큰 역할을 합니다.

대규모 데이터를 효율적으로 관리하기 위해선 단순한 쿼리 최적화뿐 아니라, 시스템 아키텍처 전반에 걸친 전략 수립과 지속적인 모니터링, 그리고 경험을 통한 문제 해결 능력이 요구됩니다. 여러분의 서비스가 더욱 빠르고 안정적으로 성장할 수 있도록, 이번 글에서 소개한 다양한 기술과 방법론을 참고하여 최적의 데이터 처리 환경을 구축해 보시기 바랍니다.

DDD란?

DDD(Domain-Driven Design), 도메인 주도 설계는 비즈니스 Domain 별로 나누어 설계하는 설계 방법 입니다.

서비스는 고객의 요구사항이나 비즈니스 환경의 변화에 따라 지속적으로 업데이트 되고 변화합니다. 하지만 이러한 변화에 맞춰 시스템의 복잡성을 관리하는 것은 쉽지 않습니다. 이러한 문제를 해결하기 위해 DDD 방법론이 만들어졌습니다.

DDD는 서비스의 ‘기능’을 기준으로 코드를 구분하지 않고, ‘도메인’이라는 비즈니스 영역을 기준으로 코드를 구분하는 것이 핵심입니다.

Event Storming

Event Storming은 서비스와 관계 있는 모든 이해 관계자들이 서로가 가지고 있는 생각을 공유하며, 서비스에서 발생하는 이벤트를 중심(Event-First)으로 분석하는 기법입니다.

Event Storming은 서비스에서 발생하는 주요 이벤트를 중심으로 도메인 모델을 만드는 방법론입니다. 모든 이해관계자들이 참여하여 서비스에서 발생하는 이벤트를 정의하고, 그 이벤트가 어떻게 발생하는지를 함께 이해하려는 접근 방식입니다.

Domain Event

도메인에서 실제로 발생하는 ‘결과’입니다.

실제 요청 사항을 통해 발생한 결과를 ‘도메인 이벤트(Domain Event)’라고 합니다. 이는 서비스에서 발생한 사실, 결과, 특정 행위의 Output을 표현하기 위해 사용됩니다.

Command

도메인에서 특정 주체가 요청하는 ‘행위’입니다.

예를 들어 고객이 “자동차를 대여하겠다”는 요청을 한다면, 이는 Command로 분류됩니다.

Service API 개발 할 때 고려할 사항

1. 설계 및 요구사항 분석
   • API의 목적 정의: 어떤 문제를 해결하기 위한 API인지 명확히 정의.
   • 요구사항 명세: 클라이언트가 필요로 하는 데이터와 기능을 명확히 이해.
   • URI 설계: RESTful API라면 리소스 기반으로 직관적이고 일관된 URI 설계.
2. 성능
   • 데이터 처리량 고려: 예상되는 트래픽과 데이터 양에 맞는 설계.
   • 캐싱 전략: 자주 요청되는 데이터를 캐싱하여 성능 최적화.
   • 효율적인 데이터베이스 쿼리: 데이터베이스 성능을 고려한 쿼리 작성과 인덱스 설계.
   • 비동기 처리: 대용량 데이터 처리를 위한 비동기 프로세스 도입.
3. 확장성
   • 모듈화 설계: 변경 사항이 생겼을 때 최소한의 영향으로 수정 가능.
   • 수평적 확장 지원: 서버를 쉽게 추가하여 부하 분산 가능하도록 설계.
   • 버전 관리: API 버전 관리(V1, V2 등)를 통해 하위 호환성 유지.
4. 보안
   • 인증 및 권한 부여: OAuth2, JWT 등 안전한 인증 방식 사용.
   • 입력 데이터 검증: SQL 인젝션, XSS 등 보안 취약점 방지를 위한 철저한 데이터 검증.
   • HTTPS 사용: 데이터 전송 과정에서 암호화.
   • Rate Limiting: 악성 트래픽이나 과도한 요청 방지를 위한 속도 제한.
5. 개발 및 유지 보수
   • 코드 품질 관리: 일관된 코드 스타일, 주석, 문서화를 통해 유지보수 용이성 확보.
   • 테스트: 단위 테스트, 통합 테스트, 성능 테스트 등을 통한 품질 보증.
   • 로깅 및 모니터링: 장애 발생 시 신속히 대응할 수 있도록 로그와 모니터링 도입.
   • 자동화: CI/CD 파이프라인을 구축해 코드 배포 자동화.
6. 사용자 경험
   • 응답 시간: 최소한의 딜레이로 빠른 응답 제공.
   • 일관된 에러 핸들링: 에러 코드와 메시지를 직관적이고 표준화된 방식으로 전달.
   • 문서화: Swagger 또는 Postman과 같은 도구를 이용해 사용하기 쉬운 API 문서 제공.
7. 기술 스택 및 경험
   • 프레임워크: FastAPI, Express.js, Spring Boot 등 프로젝트에 적합한 프레임워크 선택.
   • 데이터베이스: MariaDB, MongoDB, Redis 등 요구사항에 맞는 데이터베이스 선택.
   • 클라우드 인프라: AWS, Azure, GCP 등 서비스 확장성과 안정성을 위한 클라우드 사용.
8. 배포 환경
   • 컨테이너화: Docker와 Kubernetes를 이용한 이식성과 확장성 강화.
   • 부하 테스트: 실제 트래픽 상황에서의 성능을 사전에 확인.
   • 롤백 전략: 문제가 발생했을 때 빠르게 이전 상태로 복구할 수 있는 전략 마련.

이제 Kafka는 안녕~

요약

WarpStream이라는 S3 위에 구축된 Kafka 프로토콜 호환 데이터 스트리밍 플랫폼이 나와 이제 Kafka는 사라질꺼라는 WarpStream 뉴스입니다. 

뉴스 요약 내용은 아래와 같습니다.

WarpStream는 S3 바로 위에 구축된 Kafka 프로토콜 호환 데이터 스트리밍 플랫폼입니다. 하나의 상태 없는 Go 이진 파일로 제공되므로 관리해야 할 로컬 디스크나 리밸런싱할 브로커, 운영해야 할 ZooKeeper가 없습니다. WarpStream은 데이터가 직접 S3로 스트리밍되므로 클라우드에서 Kafka보다 5-10배 저렴합니다. 이는 규모 있는 Kafka 배포의 인프라 비용의 80% 이상이 될 수 있는 지역 간 네트워킹을 사용하지 않기 때문입니다."

[출처]

https://www.warpstream.com/blog/kafka-is-dead-long-live-kafka

Build

코드 파일을 컴퓨터에서 실행할 수 있도록 형태 변화하는 것을 Build라고 합니다.

자바 개발을 하면 .java 파일이 생성되고 build하게 되면 .java 코드 파일을 컴퓨터에서 실행할 수 있도록 변화(compile한다고 합니다.)과정을 거치면 .class 파일이 생성됩니다. 그리고 META-INF와 MANIFEST.MF 들을 하나로 압축하는 과정을 진행합니다.

Deploy

Build된 파일을 원하는 위치에 옮기는 것을 말합니다.

Complie

인간이 작성한 코드를 기계가 읽을 수  있도록 작업하는 것을 compile이라고 합니다.

WEB-INF와 META-INF 차이

WEB-INF

- Web Information의 약자입니다.

- WEB-INF폴더에는  브라우저에서 직접 접근할 수 없고 오직 서버내에서만 접근이 가능합니다.

META-INF

- Java에서 설정관련 파일을 저장하는 폴더입니다.

- Java 패키징 기술인 jar의 일부입니다.

- jar 파일들을 풀어보면 META-INF 폴더 아래 MANIFEST.MF 라는 파일이 있습니다.

문제

postman에서 get 방식 호출하는데 

Cloud Agent Error: Can not send requests to reserved address. Make sure address is publicly accessible or select a different agent.

발생했습니다. 

이유는 postman에서 호출하는건 localhost가 아니라서 인거 같습니다.

해결

Desktop을 다운 받고 실행하니 해결되었습니다.