엘라스틱 서치(Elasticsearch)와 검색 자동 완성 문제 해결

1. 문제 발생

엘라스틱 서치를 이용해 검색 자동 완성 기능을 구현했지만, 일부 검색어가 정상적으로 인식되지 않는 문제가 발생했다. 검색어에 따라 자동 완성이 예상과 다르게 작동하며, 특정 단어가 검색되지 않는 경우도 있었다.

2. 문제 원인

• 엘라스틱 서치에서 기본적으로 제공하는 Nori 형태소 분석기는 완벽한 형태소 분석을 수행하지 않는다.
• 예를 들어, "용광로"라는 단어가 있을 때, Nori는 이를 다음과 같이 토큰화할 수 있다.

{
  "tokens": [
    { "token": "용", "start_offset": 0, "end_offset": 1, "type": "word", "position": 0 },
    { "token": "왕식", "start_offset": 1, "end_offset": 3, "type": "word", "position": 1 },
    { "token": "용광로", "start_offset": 4, "end_offset": 7, "type": "word", "position": 2 }
  ]
}

• 이러한 방식은 공백 및 사전 단어를 기준으로 최선의 토큰화를 수행하기 때문에, 원하는 자동 완성 결과를 보장하지 않는다.
• 신조어나 외래어, 대명사를 제대로 구분하지 못하는 경우도 발생하여, 일부 검색어가 정상적으로 처리되지 않는 문제가 있었다.

3. 문제 해결책 수립

해결 방법 비교

4. 문제 해결: Nori + Edge-N-gram 조합 사용

현 프로젝트에서는 비용과 개발 시간을 고려하여 Nori 형태소 분석기와 Edge-N-gram을 조합하는 방식을 선택했다.

• Edge-N-gram을 사용하여 자동 완성 기능을 보완
  • 예를 들어, "용광로"라는 단어가 있다면, Edge-N-gram을 적용했을 때 다음과 같이 인덱싱할 수 있다.

    ["용", "용광", "용광로"]
    

  • 이를 통해 사용자가 "용"을 입력해도 "용광로"가 자동 완성될 수 있도록 함.
• Nori 형태소 분석기를 그대로 유지하여 의미 기반 검색 가능
  • 단순한 완전 일치 검색이 아니라, 문맥을 고려한 검색이 가능하도록 유지

결론: 엘라스틱 서치의 기본 형태소 분석기인 Nori만으로는 검색 자동 완성 기능을 완벽히 구현하기 어렵다. 따라서, 자동 완성을 위해 Edge-N-gram을 적용하고, 의미 기반 검색을 위해 Nori 형태소 분석기를 함께 활용하는 방식으로 해결했다.

1. 문제 상황

기존의 모놀로틱 아키텍처에서는 모든 기능이 하나의 코드베이스에서 동작하여 서비스 간 결합도가 높고, 확장성과 유지보수성이 제한되는 문제가 발생했다. 이를 해결하기 위해 도메인 주도 설계(DDD, Domain-Driven Design) 원칙을 적용하여 MSA(Microservices Architecture)로 전환하는 방안을 고려했다.

하지만, 무조건적으로 서비스를 잘게 분리하면 오히려 결합도가 높아지고 성능 저하 및 복잡성이 증가할 가능성이 있어 서비스 간 결합도를 고려하여 적절한 기준을 설정하여 분리하는 것이 중요했다.

2. MSA 분리 기준

(1) DDD 원칙에 기반한 서비스 분리

MSA를 설계할 때 가장 중요한 것은 도메인의 경계를 명확하게 나누는 것이다. 이를 위해 DDD의 Bounded Context(경계 컨텍스트) 개념을 적용하여 각 서비스가 독립적인 도메인 로직을 가지도록 구성했다. 그러나, 서비스 간의 트랜잭션 처리, 데이터 일관성 유지, 성능 고려, 네트워크 요청 수 증가 고려 등의 이유로 너무 세분화된 서비스는 묶어서 운영하는 전략을 사용하기로 했다.

3. 실제 프로젝트의 서비스 분리

아래와 같이 비즈니스 도메인과 트래픽 특성을 고려하여 MSA를 구성했다.

(1) user-chat 서비스

• 분리 이유: 우리 프로젝트에서는 채팅이 상품 주문 완료 후에만 가능하므로, 주문과 채팅 중 트래픽이 몰릴 경우 주문이 우선순위를 가져야 한다.
• 서비스 결합도 고려: 채팅은 주문과 완전히 독립적이지 않으므로 완전히 분리하지 않고 같은 서비스에서 운영
• 설계 방향:
  • 주문 관련 로직을 우선 실행하고, 채팅 요청은 비동기 메시징 시스템(Kafka, RabbitMQ 등)을 활용하여 처리
  • 채팅 서버는 주문 서버와 분리된 워커(worker) 또는 비동기 큐 방식으로 운영

(2) game-product-review-order 서비스

• 분리 이유:
  • 게임 → 상품 → 주문 → 리뷰로 이어지는 선형적인 관계를 가지는 도메인
  • 상품과 주문은 락(Lock) 관리가 필요하여 강한 결합도를 가짐
  • 리뷰는 주문이 있어야만 생성 가능하므로 해당 도메인에 포함
• 설계 방향:
  • 상품과 주문은 트랜잭션을 유지해야 하므로 하나의 서비스에서 운영
  • 리뷰는 트랜잭션 요구사항이 적지만, 주문과 긴밀하게 연결되므로 같은 서비스에서 관리
  • 데이터 정합성을 위해 이벤트 소싱(Event Sourcing) 또는 CQRS 적용 검토

(3) security 서비스

• 분리 이유:
  • 보안 관련 기능(인증, 권한 관리 등)은 다른 도메인과 직접적인 연관이 없음
  • 서비스 전체의 보안 레이어로 동작해야 함
• 설계 방향:
  • JWT, OAuth2, SSO 등을 활용하여 인증 기능 구현
  • API Gateway에서 인증 및 권한 관리 수행
  • 인증/인가 로직이 필요한 서비스에서 security 서비스와 통신하도록 구성

(4) payment-bill 서비스

• 분리 이유:
  • 결제 서비스는 트래픽이 급격히 증가할 가능성이 높음
  • 결제 데이터는 강한 일관성이 필요하며, 스케일링을 고려해야 함
• 설계 방향:
  • 결제 시스템은 **독립적인 데이터베이스(RDS)**를 사용하여 확장성 확보
  • 트랜잭션 안전성을 유지하기 위해 읽기/쓰기 분리(Read Replica 적용)
  • 트래픽 증가 시 Auto Scaling을 적용하여 결제 처리량 조절
  • 외부 결제 시스템(PG사)과의 통합을 고려하여 API 라우팅 최적화

(5) community-comment 서비스

• 분리 이유:
  • 트래픽이 가장 많이 몰리는 서비스이므로, 독립적으로 확장 가능해야 함
  • 커뮤니티와 댓글은 관계가 있지만, 높은 트래픽을 처리하기 위해 분리가 필요
• 설계 방향:
  • 데이터베이스 RDS를 읽기/쓰기 분리하여 트래픽 부하 감소
  • 캐싱(Redis, ElasticSearch 등) 도입하여 성능 최적화
  • Kafka와 같은 메시지 큐를 활용하여 비동기 처리 도입
  • API Gateway에서 Rate Limiting 적용하여 DDoS 공격 방어

4. 결론

(1) 적용한 MSA 분리 원칙

• DDD 원칙에 따라 도메인을 명확하게 구분하여 서비스 분리
• 트랜잭션 및 강한 결합이 필요한 서비스는 묶어서 운영하여 데이터 정합성을 유지
• 트래픽 분산이 중요한 서비스는 별도로 분리하여 확장성 확보
• 읽기/쓰기 부하를 분산하기 위해 RDS의 Read Replica 및 Auto Scaling 활용

(2) 예상되는 효과

1. 확장성 향상 → 서비스별로 독립적인 스케일링이 가능하여 성능 최적화

2. 배포 유연성 증가 → 특정 서비스만 개별 배포 가능하여 배포 속도 증가

3. 트래픽 처리 최적화 → 결제, 커뮤니티 등 고트래픽 서비스의 성능 향상

4. 데이터 정합성 유지 → 강한 결합이 필요한 도메인은 묶어서 관리하여 안정성 유지

(3) 향후 개선 방향

• 서비스 간 통신에서 성능 최적화를 위해 gRPC 적용 검토
• 데이터 정합성을 높이기 위해 이벤트 소싱(Event Sourcing) 및 CQRS 적용 검토
• 모니터링 강화를 위해 Prometheus, ELK Stack을 활용한 실시간 로깅 및 트래픽 분석 도입

이번 MSA 분리는 현재 프로젝트의 구조와 트래픽 특성을 고려하여 최적의 아키텍처를 설계하는 데 집중하였다. 향후 운영 과정에서 지속적으로 성능 및 확장성을 고려하여 개선해 나갈 계획이다.

엘라스틱 서치(Elasticsearch)에서 리뷰 데이터 저장 방식과 동기화 전략

1. 문제 발생

일반적인 정적 데이터는 CRUD와 함께 실시간으로 저장하는 것이 일반적이다. 그러나 프로젝트에서 리뷰 데이터를 Logstash를 통해 저장하는 방식을 선택하면서, MySQL에서 변경되는 데이터를 엘라스틱 서치와 어떻게 동기화할 것인지에 대한 고민이 필요했다.

2. 문제 원인

• 현재 코드에서 리뷰 데이터는 특정 상품의 감성 분석을 위해서만 사용된다.
• 리뷰 데이터는 실시간 갱신이 필요하지 않다. 주기적으로 감성 분석이 필요한 순간에만 동기화하면 된다.
• 제품(Product)의 경우 사용자 요청이 자주 발생하므로, 데이터가 변경될 때마다 갱신해야 한다. 그러나 리뷰 데이터는 인기 상품을 나열하는 특정 주기(예: 하루 한 번 갱신)마다 업데이트하면 충분하다.
• 따라서 MySQL에서 변경될 때마다 엘라스틱 서치에 동기화할 필요 없이, 정해진 주기에 맞춰 동기화하는 방식이 더 적합했다.

3. 문제 해결책 수립

해결 방법 비교

4. 문제 해결: Logstash 기반 주기적 동기화 적용

(1) 리뷰 데이터는 주기적 갱신이 적합

• 인기 상품 추천을 위해 리뷰 데이터를 하루 한 번 감성 분석하는 구조이므로, MySQL에서 변경될 때마다 갱신할 필요가 없음.
• 불필요한 연산을 줄이고, 엘라스틱 서치의 리소스를 절약할 수 있음.
• 예를 들어, 인기 상품을 하루에 한 번 갱신한다면, 리뷰 데이터도 하루에 한 번 동기화하면 충분하다.

(2) Logstash의 데이터 삭제 처리 문제 해결

• Logstash는 기본적으로 데이터를 추가하는 방식으로 동작하기 때문에, MySQL에서 삭제된 데이터를 반영할 수 없음.
• 하지만 현재 프로젝트에서는 소프트 딜리트(Soft Delete) 방식을 사용하여 문제를 해결함.
• MySQL에서 리뷰 데이터를 삭제할 때, 실제로 데이터를 삭제하는 것이 아니라 is_deleted 플래그를 업데이트하는 방식.
• Logstash가 MySQL에서 데이터를 불러올 때, is_deleted 값이 반영되므로 정합성이 유지됨.

하드 딜리트 방식이었다면? MySQL에서 데이터가 삭제되면, Logstash는 해당 데이터를 감지하지 못해 엘라스틱 서치에 남아있게 됨. 그러나 소프트 딜리트 방식을 사용하면, MySQL에서 삭제된 데이터도 동기화 가능.

5. 결론

• 리뷰 데이터는 CRUD 기반 실시간 갱신이 필요하지 않으며, 주기적인 감성 분석 시점에만 동기화하는 것이 가장 효율적이다.
• Logstash 기반으로 리뷰 데이터를 동기화하되, 소프트 딜리트를 활용해 데이터 정합성을 유지한다.
• 이 방식은 불필요한 연산을 줄이고, 엘라스틱 서치의 리소스 사용을 최적화하는 데 효과적이다.

엘라스틱 서치(Elasticsearch)와 트랜잭션 락 문제 해결

1. 문제 발생

내가 담당한 상품과 주문 데이터는 정합성을 유지하기 위해 락이 필요했다. 기존에는 MySQL만 사용했기 때문에 MySQL의 트랜잭션 락을 활용하면 됐다. 하지만 추가로 엘라스틱 서치를 검색 엔진으로 도입하면서, 엘라스틱 서치의 데이터 동기화 과정에서 락이 필요한 문제가 발생했다.

2. 문제 원인

• MySQL은 트랜잭션을 지원하지만, 엘라스틱 서치는 ACID 트랜잭션을 지원하지 않는다.
• MySQL에서 데이터를 업데이트한 후, 엘라스틱 서치에도 동일한 데이터를 업데이트해야 하는데, 이 과정에서 동기화 지연이 발생할 수 있다.
• 만약 MySQL에는 데이터가 업데이트되었지만, 엘라스틱 서치에 즉시 반영되지 않으면 데이터 불일치(Inconsistency) 문제가 발생할 수 있다.
• 이를 방지하기 위해서는 MySQL의 트랜잭션에 엘라스틱 서치의 CRUD 작업도 포함하는 방식이 필요했다.

3. 문제 해결책 수립

해결 방법 비교

4. 문제 해결: MySQL 트랜잭션 락에 엘라스틱 서치 CRUD 포함

가장 안정적인 방법은 MySQL 트랜잭션 내에서 엘라스틱 서치의 CRUD(Create, Read, Update, Delete) 작업도 포함시키는 것이었다.

• MySQL에서 트랜잭션을 시작하고, 해당 데이터에 대한 변경 사항을 반영하는 동안 엘라스틱 서치에도 동시에 업데이트 수행
• MySQL에서 커밋이 완료되면, 엘라스틱 서치에서도 색인을 갱신하여 데이터 일관성을 유지
• 트랜잭션이 롤백되면, 엘라스틱 서치 업데이트도 취소하도록 구현
• 이벤트 기반 동기화를 추가하여, 변경된 데이터를 트리거로 활용해 엘라스틱 서치를 최신 상태로 유지

결론: MySQL과 엘라스틱 서치의 동기화를 위해 MySQL 트랜잭션 내부에서 엘라스틱 서치의 CRUD 작업을 함께 수행하는 방식을 선택했다. 이를 통해 데이터 일관성을 유지하면서도 성능 저하를 최소화할 수 있다.

실상 엘라스틱 서치에 자체적으로 존재하는 보안은 SECURE GURD만 있다고 무방하다.

그 외에 존재하는 LDAP, OAuth, SAML과 같이 대부분의 기업이 자체적으로 사용하는 인증 시스템을 도입하는 경우가 많다

[실제로 현재 엘라스틱 서치 최신 버전인 8.x을 보면 이런 점을 의식한 것인지 보안을 강제하는 경우도 생겼다.]

실상 보안의 종류가 적은 편이라 이유를 찾기 애매하지만 굳이 이유가 붙을 만한 요소는 SSL 정도가 있을 것이다. SSL/TSL은 흔히 데이터 전송 보호 및 무결성을 보장하기 위해서 존재한다. 엘라스틱 서치는 분산 환경으로 보통 구성되고 노드간의 통신이 많은 편이다. 데이터가 자주 왕래하는 만큼 데이터 네트워크 통신의 보안이 중요해 진 것이다.

Q. 하지만 VPN과 방화벽도 네트워크 보안을 수행해 줄 수 있을 텐데 굳이 SSL/TLS를 사용한 이유가 있는가?

A. 있다. VRN의 경우 네트워크 트래픽을 보호하는 것은 맞지만, 엘라스틱 서치 내부 노드간 트래픽 보호가 안된다. 방화벽은 특정 IP만 허용하지만 네트워크 내부 공격(내부 직원, 관리자, 감염된 내부시스템에 의한 공격)에 취약한 점은 마찬가지이다.

왜 SSL은 내부 공격에도 강한가?

위의 접은글의 내용 대로 사실 다양한 이유가 있지만, 가장 큰 이유는 SSL/TLS가 보편적인 데이터 전송 보안에 해당하는 것이 큰 이유이다. 많은 공인된 기관이 인증한 보안 표준인 점이 실상 큰 사용에 이유로서 알려져 있다.

실제로 엘라스틱 서치에 적용 가능한 보안은 한정적이기에, 다음의 보안들이 추가되었다.

1. SSL/TLS 적용 = 데이터 전송 암호화
2. 사용자 역할별 인증 활성화 RBAC = 역할별 인덱스 접근 제한
3. Audit Logging(감사 로깅) = 접근자, 데이터등을 감시

사실 4번의 경우 logback을 사용해서 로그 데이터를 이미 저장하고 있는데 왜 굳이 필요하냐라고 할 수 있는데, logback에서 나오는 로그는 스프링 애플리케이션의 로그만 저장된다.

엘라스틱 서치의 보안에 해당하는 로그 (인증 실패, 접근 차단, 역할 변경, 수십번 로그인 시도, 계정 마다의 행동 기록)의 경우 logbackd으로는 당연히 저장이 안된다. 이를 위해서 Audit Logging 설정이 필요하다.

엘라스틱 서치(Elasticsearch)와 MySQL 데이터 저장 방식 비교

1. 문제 발생

기본적으로 MySQL에 데이터를 저장하는데, 동일한 데이터를 엘라스틱 서치에도 전부 저장해야 하는지에 대한 고민이 발생했다. 데이터가 중복 저장되면 시스템 부하가 증가할 수 있으며, 관리 복잡성이 높아질 수 있다는 판단과 어차피 백업의 기능으로 보면 되는거 아닌가 라는 판단 2개가 상충하는 상황이였다.

2. 문제 원인

• MySQL은 데이터 저장 및 관리가 주된 역할이지만, 엘라스틱 서치는 검색 최적화에 초점이 맞춰진 데이터 저장소다.
• MySQL에 저장된 데이터를 그대로 엘라스틱 서치에 저장하면 중복 저장 문제가 발생하여 저장 공간 낭비 및 데이터 동기화 비용 증가 등의 문제가 생길 수 있다.
• 엘라스틱 서치의 강점은 빠른 검색인데, 모든 데이터를 저장하는 것은 불필요한 리소스 낭비가 될 수 있다.

3. 문제 해결책 수립

해결 방법 비교

4. 문제 해결: 검색에 필요한 데이터만 저장

엘라스틱 서치에는 검색에 필요한 정보만 저장하는 것이 가장 효율적인 해결책이다.

• 불필요한 데이터 저장을 최소화하여 시스템 리소스를 절약할 수 있음
• 검색 속도를 최적화하고, 필요한 데이터만 색인하여 검색 효율을 높일 수 있음
• 데이터 동기화 부담을 줄여 유지보수 비용을 절감할 수 있음
• MySQL과의 역할 분리를 명확하게 하여 검색 및 저장의 목적을 최적화할 수 있음
• MySQL도 자체적인 스냅샷 혹은 백업이 존재야한다.

결론: MySQL과 엘라스틱 서치는 목적이 다르다. 따라서 모든 데이터를 중복 저장하는 것이 아니라, 검색이 필요한 데이터만 엘라스틱 서치에 저장하는 것이 가장 효율적인 방식이다.

아래 정리는 백엔드 면접 시 간단히 기억하고 설명하기 좋은 형태로 작성되었습니다. 각 키워드마다 핵심 요약 → 특징 → 장단점 → 비교(대안/차이점) → 연계 질문 & 간단 답변 예시 순으로 정리하였고, 실제 현업 경험이 있으면 그 예시를 더해주시면 좋습니다.

1. 데이터베이스 (RDB vs NoSQL)

• 핵심 요약
  • RDB(Relational Database): 테이블 형태, SQL 사용, 정형화된 스키마, ACID 보장
  • NoSQL: 문서/키-값/컬럼/그래프 등 다양한 모델, 스키마 유연
• 특징
  • RDB: 정교한 JOIN, 강력한 트랜잭션
  • NoSQL: 수평 확장 쉬움, 높은 성능(특정 케이스), 스키마 유연
• 장단점
  • RDB 장점: 데이터 무결성·일관성 보장, 복잡한 쿼리 지원
  • RDB 단점: 수직 확장 의존(Scale-up), 유연성 낮음
  • NoSQL 장점: 대규모 트래픽 처리에 유리, 스키마 변경이 자유롭고 빠름
  • NoSQL 단점: JOIN이 어려움(또는 미지원), 트랜잭션 일관성이 약함(Eventual Consistency)
• 비교 (대안/차이점)
  • RDB vs NoSQL:
    • 정합성/트랜잭션이 중요 → RDB 적합
    • 유연한 스키마 & 대규모 확장 필요 → NoSQL 적합
• 연계 질문 & 간단 답변 예시
  1. Q: "NoSQL에서 트랜잭션을 보장하려면 어떻게 해야 하나요?"
     A: 몽고DB의 경우 멀티 도큐먼트 트랜잭션 지원(4.0+), 하지만 RDB만큼은 아님. SAGA 패턴 등을 도입하기도 함.
  2. Q: "RDB에서 대규모 트래픽을 처리하려면?"
     A: 샤딩, Replication, Connection Pool 튜닝 등으로 대응. 필요시 NoSQL로 일부 기능 분산.

2. RESTful API

• 핵심 요약
  • HTTP 메서드(GET, POST, PUT, DELETE)와 리소스 중심의 URI 설계
• 특징
  • 클라이언트-서버 구조 명확
  • 무상태성(Stateless)으로 확장성 높음
• 장단점
  • 장점: 사용이 쉽고 범용적, 캐싱 가능, 확장성 우수
  • 단점: Over-fetching / Under-fetching 문제, 실시간 양방향 통신에 비효율적
• 비교 (대안/차이점)
  • GraphQL: 필요한 데이터만 요청 가능, 단일 엔드포인트
  • gRPC: HTTP/2 기반 바이너리 프로토콜, 낮은 지연시간
• 연계 질문 & 간단 답변 예시
  1. Q: "RESTful에서 상태를 어떻게 관리하나요?"
     A: 쿠키/세션/토큰(JWT) 기반 인증으로 관리. API 자체는 무상태 유지.
  2. Q: "REST API가 Over-fetching 문제를 일으킨다면 어떻게 해결?"
     A: GraphQL 도입, API 쪼개기, 혹은 필드를 동적으로 선택할 수 있는 기능 제공 등.

3. GraphQL

• 핵심 요약
  • 클라이언트가 필요한 데이터만 지정해서 요청하는 쿼리 언어
• 특징
  • 단일 엔드포인트 /graphql
  • 스키마 정의로 정확한 타입 보장
• 장단점
  • 장점: Over/Under-fetching 해결, 강력한 타입 시스템
  • 단점: 서버 캐싱 복잡, 학습 곡선 존재
• 비교 (대안/차이점)
  • RESTful API: 여러 엔드포인트, 단순 구조
  • GraphQL: 단일 엔드포인트로 유연한 데이터 요청
• 연계 질문 & 간단 답변 예시
  1. Q: "GraphQL에서 캐싱은 어떻게 처리하나요?"
     A: 주로 클라이언트 레벨에서 캐싱(Apollo Client 등). 서버 캐싱은 REST보다 복잡.
  2. Q: "GraphQL로 파일 업로드는 어떻게 하나요?"
     A: Mutation을 사용하거나, 별도 REST 엔드포인트로 처리 후 URL만 GraphQL로 전달.

4. Spring Boot

• 핵심 요약
  • 스프링 프레임워크를 간편하게 시작할 수 있는 자동 설정 + 내장 WAS 제공
• 특징
  • 스타터(Starter) 의존성, 내장 Tomcat, 설정 최소화
• 장단점
  • 장점: 빠른 개발 & 배포, 일관된 구조
  • 단점: 의존성 무거움, 커스터마이징 복잡
• 비교 (대안/차이점)
  • Spring Boot vs Node.js(Express): 자바 생태계 vs 자바스크립트 생태계, 동기 vs 비동기 중심
  • Spring Boot vs Quarkus/Micronaut: 경량화 프레임워크
• 연계 질문 & 간단 답변 예시
  1. Q: "Spring Boot에서 내장 톰캣 대신 다른 서버를 쓸 수 있나요?"
     A: 예. spring-boot-starter-jetty나 undertow 등 교체 가능.
  2. Q: "스프링 부트에서 설정 오버라이딩은 어떻게?"
     A: application.properties/yaml 혹은 프로파일 별 설정 사용.

5. Spring Security

• 핵심 요약
  • 스프링 기반의 인증/인가 프레임워크
• 특징
  • Filter 체인 구조, 다양한 인증 방식(JWT, OAuth2, Basic Auth 등) 지원
• 장단점
  • 장점: 강력하고 유연한 보안, 스프링과 밀접 통합
  • 단점: 설정 복잡도 높음, 학습 곡선
• 비교 (대안/차이점)
  • 직접 JWT 필터 구현 vs Spring Security Filter 체인 사용
  • OAuth 라이브러리 (Passport.js 등)와 비교
• 연계 질문 & 간단 답변 예시
  1. Q: "Spring Security에서 필터 순서를 제어하는 방법은?"
     A: @Order 또는 SecurityFilterChain을 커스텀하여 순서 지정.
  2. Q: "JWT 토큰 만료 시 재발행 로직은 어떻게 구현?"
     A: Refresh Token 사용, 만료 시점에 재발행 엔드포인트 호출.

6. Docker & Kubernetes

• 핵심 요약
  • Docker: 컨테이너 기술, 애플리케이션을 격리된 환경에서 실행
  • Kubernetes(K8s): 컨테이너 오케스트레이션 툴
• 특징
  • Docker: 이미지로 환경 통일, CI/CD 연계 용이
  • K8s: Pod, Deployment, Service 등으로 확장성, 자동화
• 장단점
  • Docker 장점: 경량 가상화, 이식성 높음
  • Docker 단점: 네트워크·스토리지 세팅 복잡
  • K8s 장점: 자동 스케일링, 롤링 업데이트
  • K8s 단점: 초기 설정·운영 난이도 높음
• 비교 (대안/차이점)
  • Docker Compose vs Kubernetes (Compose는 단일 서버, K8s는 분산 운영)
  • 다른 오케스트레이션 툴: Nomad, Docker Swarm
• 연계 질문 & 간단 답변 예시
  1. Q: "쿠버네티스에서 무중단 배포(롤링 업데이트)는 어떻게 동작?"
     A: Deployment가 새 버전의 Pod을 단계적으로 띄우고, 오래된 Pod을 점진적으로 종료.
  2. Q: "Dockerfile 최적화 방법?"
     A: Multi-stage build, 이미지 레이어 최소화, 불필요한 파일 제거.

7. Kafka

• 핵심 요약
  • 분산 메시징 및 스트리밍 플랫폼, 로그 기반 저장
• 특징
  • 높은 처리량, 다수의 Consumer Group 가능, 파티션 단위 병렬 처리
• 장단점
  • 장점: 대규모 데이터 처리, 영구 저장(디스크)
  • 단점: 운영 복잡도 높음, 브로커/주키퍼 관리 필요
• 비교 (대안/차이점)
  • RabbitMQ: 큐 기반, 메시지 지연 적고 라우팅 유연
  • Redis Pub/Sub: 인메모리, 메시지 영구 보관 X
• 연계 질문 & 간단 답변 예시
  1. Q: "Kafka에서 At Least Once를 보장하려면?"
     A: acks=all, min.insync.replicas 설정, Consumer 수동 Commit.
  2. Q: "Topic 파티션 수 결정 기준?"
     A: 예상 소비량, 병렬 처리 수, 브로커 수 등에 따라 결정.

8. Redis

• 핵심 요약
  • 인메모리 데이터베이스로 빠른 읽기/쓰기가 특징
• 특징
  • Key-Value, Pub/Sub, Sorted Set 등 다양한 자료구조 제공
• 장단점
  • 장점: 캐싱에 매우 유리, 실시간 처리 가능
  • 단점: 메모리 기반이라 데이터 유실 가능성, 영속성(AOF/RDB) 설정 필요
• 비교 (대안/차이점)
  • Memcached: Key-Value만 지원, 구조 단순
  • Redis: 다양한 자료구조, Lua 스크립팅 등 확장성
• 연계 질문 & 간단 답변 예시
  1. Q: "Redis에서 데이터 영속화 어떻게 보장?"
     A: RDB 스냅샷, AOF(Append Only File) 설정.
  2. Q: "Redis Cluster에서 샤딩은 어떻게 동작?"
     A: 해시 슬롯(Hash Slot) 기반 분산.

9. JPA & Hibernate

• 핵심 요약
  • 자바 기반의 ORM(Object-Relational Mapping) 프레임워크
• 특징
  • SQL 대신 **엔티티(Entity)**를 조작, JPQL 사용
• 장단점
  • 장점: 생산성 향상, DB 변경 시 코드 수정 최소화
  • 단점: 복잡한 쿼리 최적화 어려움, Lazy 로딩 N+1 문제
• 비교 (대안/차이점)
  • MyBatis: SQL 매퍼 중심, 쿼리 직접 작성
  • JDBC 직접 사용: 세밀한 제어 가능하지만 보일러플레이트 많음
• 연계 질문 & 간단 답변 예시
  1. Q: "N+1 문제는 무엇이며 해결 방법은?"
     A: 연관관계 로딩 시 매번 추가 쿼리 발생. fetch join, EntityGraph, Batch Size등으로 최적화.
  2. Q: "Spring Data JPA는 어떻게 Repository를 생성?"
     A: 인터페이스 기반, JpaRepository<T, ID>를 상속하면 기본 CRUD 제공.

10. CI/CD (Jenkins, GitHub Actions)

• 핵심 요약
  • 지속적 통합(Continuous Integration) & 지속적 배포(Continuous Deployment) 자동화 도구
• 특징
  • 코드 푸시 → 자동 빌드 → 테스트 → 배포 파이프라인
• 장단점
  • 장점: 빠른 피드백, 릴리스 주기 단축
  • 단점: 초기 설정 복잡, 환경 설정 관리 필요
• 비교 (대안/차이점)
  • Jenkins: 자체 호스팅, 플러그인 풍부
  • GitHub Actions: GitHub에 통합, YAML 기반
• 연계 질문 & 간단 답변 예시
  1. Q: "CI 파이프라인 구성 시 가장 중요한 고려사항?"
     A: 빌드 속도, 테스트 안정성, 환경 일관성.
  2. Q: "CD 시점(Deploy vs Delivery) 차이는?"
     A: Delivery는 준비 상태, Deployment는 실제 프로덕션 반영.

11. 로그 & 모니터링 (ELK Stack, Prometheus)

• 핵심 요약
  • ELK(Elasticsearch, Logstash, Kibana): 로그 수집·분석·시각화
  • Prometheus: 시계열 모니터링 & 알람 시스템
• 특징
  • 실시간 로그 분석, 대시보드 구성, 장애 탐지
• 장단점
  • 장점: 장애 신속 대응, 성능 최적화 데이터 확보
  • 단점: 구성 복잡, 리소스 사용 많음
• 비교 (대안/차이점)
  • ELK vs Splunk: Splunk는 상용, UI/기능은 강력하지만 비용 큼
  • Prometheus vs Grafana: Grafana는 시각화, Prometheus는 데이터 수집
• 연계 질문 & 간단 답변 예시
  1. Q: "Elasticsearch 인덱스 설계를 잘못하면 무슨 문제가 생기나요?"
     A: 검색 성능 저하, 스토리지 급증, 클러스터 불안정.
  2. Q: "Prometheus Alertmanager는 무엇을 하나요?"
     A: 임계값 초과 시 Slack, 이메일 등으로 알림을 보냄.

12. HTTP & WebSocket

• 핵심 요약
  • HTTP: 요청/응답 기반 프로토콜
  • WebSocket: 양방향 실시간 통신 프로토콜
• 특징
  • HTTP: Stateless, 단방향
  • WebSocket: 서버-클라이언트 간 지속 연결, 실시간 송수신
• 장단점
  • HTTP 장점: 광범위한 표준, 캐싱 가능
  • HTTP 단점: 풀링/롱 폴링으로 실시간 구현 비효율
  • WebSocket 장점: 실시간 양방향, 이벤트 주도
  • WebSocket 단점: 연결 관리 복잡, 서버 리소스 부담
• 비교 (대안/차이점)
  • HTTP SSE(Server-Sent Events): 서버→클라이언트 단방향 스트리밍
  • WebSocket: 양방향
• 연계 질문 & 간단 답변 예시
  1. Q: "WebSocket 연결 수가 많을 때 서버 부하를 줄이는 방법?"
     A: 로드밸런싱, 클러스터링, 메시지 브로커 연계(Stomp 등).
  2. Q: "Stateless한 HTTP를 유지하면서 실시간 알림은 어떻게 구현?"
     A: WebSocket, SSE, 혹은 주기적 폴링 기법.

13. 트랜잭션 관리

• 핵심 요약
  • DB 작업이 ACID 속성을 지키도록 묶어주는 메커니즘
• 특징
  • Local Transaction vs Distributed Transaction(2PC, Saga 등)
• 장단점
  • 장점: 데이터 무결성 보장
  • 단점: 성능 저하(락), 분산 트랜잭션은 복잡도 증가
• 비교 (대안/차이점)
  • Local Transaction: 단일 DB 내에서 처리
  • Distributed Transaction: 여러 마이크로서비스/DB 연동 (Saga, 2PC)
• 연계 질문 & 간단 답변 예시
  1. Q: "왜 2PC는 잘 안 쓰이고 Saga를 선호하나요?"
     A: 2PC는 락으로 인한 성능 저하 & 장애 시 복잡함, Saga는 서비스 간 보상 트랜잭션으로 유연.
  2. Q: "스프링에서 @Transactional의 전파(Propagation) 옵션은?"
     A: REQUIRED, REQUIRES_NEW, SUPPORTS 등 7가지. 상황에 맞게 사용.

14. Circuit Breaker (Resilience4j, Hystrix)

• 핵심 요약
  • 장애가 발생한 서비스를 잠시 회로를 열어 트래픽을 차단하고 전체 장애 전파를 막는 패턴
• 특징
  • Closed → Open → Half-Open 상태 전이
  • 장애 지표(에러율 등)에 따라 회로를 열고 닫음
• 장단점
  • 장점: 장애 확산 방지, 서버 보호
  • 단점: 잘못된 설정 시 정상 요청도 차단될 수 있음
• 비교 (대안/차이점)
  • Hystrix(Netflix OSS) vs Resilience4j(더 가볍고 최신)
  • Bulkhead(격리), Rate Limiter도 유사한 보호 패턴
• 연계 질문 & 간단 답변 예시
  1. Q: "Circuit Breaker가 Open 상태가 되었을 때 어떤 로직이 동작?"
     A: 폴백(Fallback) 로직 호출, 혹은 예외 반환. 일정 시간 후 Half-Open으로 전환.
  2. Q: "Circuit Breaker와 Retry는 어떻게 조합?"
     A: 필요 시 재시도( Retry ) + 서킷브레이커로 장애 완화. 설정 주의 필요(과도한 트래픽 발생 방지).

15. MSA (Microservices Architecture)

• 핵심 요약
  • 기능별로 독립 배포/운영이 가능한 마이크로서비스 형태의 아키텍처
• 특징
  • 각 서비스가 자체 DB, 독립된 라이프사이클
  • 서비스 간 통신(REST, gRPC, 메시지 브로커 등)
• 장단점
  • 장점: 확장성, 독립 배포, Fault Isolation
  • 단점: 서비스 간 통합 복잡, 장애 추적 어려움, 운영 비용 증가
• 비교 (대안/차이점)
  • Monolithic: 하나의 큰 애플리케이션, 배포/확장이 일괄적
  • MSA: 작은 단위로 분리, 각각 독립 운영
• 연계 질문 & 간단 답변 예시
  1. Q: "MSA에서 데이터 일관성은 어떻게 맞추나요?"
     A: 분산 트랜잭션 대신 이벤트 소싱, Saga 패턴, 최종적 일관성 개념 적용.
  2. Q: "서비스가 너무 많이 쪼개지면 어떤 문제가 생기나요?"
     A: 서비스 간 의존성 복잡, 배포/운영 비용 급증, 개발·운영 인력 부족 현상.

정리 & 활용 팁

• 면접 대비: 각 키워드를 문장 2~3개로 짧게 말할 수 있도록 암기하고, 필요 시 추가 상세를 붙이는 방식이 좋습니다.
• 연계 질문: 실제 면접에서는 한 키워드만 물어보지 않고, “그럼 이 경우엔 어떻게 하죠?” 식으로 파생 질문이 많으니 위의 연계 질문들을 연습해 보시면 답변에 큰 도움이 됩니다.
• 실무 경험 추가: 가능하면 “프로젝트에서 ~~로 구현했는데, ~~ 문제를 이렇게 해결했다”처럼 개인 경험을 연결하면 면접관의 호응을 얻기 좋습니다.

1. 문제 발생

Kafka 메시징 시스템을 운영하는 과정에서, 메시지를 딱 한 번만 정확히 전송하는 Exactly-Once 방식에서 최소 한 번 전송하는 At-Least-Once 방식으로 변경할 필요가 발생했다. 이 과정에서 성능과 데이터 정합성 사이의 균형을 맞추는 것이 중요한 과제가 되었다.

2. 원인 분석

2.1 Exactly-Once 방식의 문제점

1. 성능 저하:
   • Exactly-Once 방식은 트랜잭션을 사용하여 메시지를 철저히 관리하기 때문에 네트워크 및 처리 속도가 느려짐.
   • Kafka의 Exactly-Once Processing은 모든 메시지를 한 번만 처리해야 하므로, 추가적인 오버헤드가 발생.
2. 운영 복잡성 증가:
   • Exactly-Once 모드를 사용하려면 Kafka, 프로듀서, 컨슈머, 외부 데이터 저장소(RDBMS, NoSQL 등) 간의 정합성을 보장해야 하므로 설정과 유지보수가 복잡해짐.
   • 장애 발생 시 트랜잭션을 롤백해야 하는데, 이 과정에서 데이터 일관성을 유지하기 위한 추가적인 로직이 필요함.
3. 트랜잭션 비용 증가:
   • Exactly-Once 메시징을 위해서는 Kafka의 트랜잭션 프로토콜을 활용해야 하며, 이는 일반적인 메시징보다 높은 리소스를 요구.
   • 병렬 처리를 제한할 수 있으며, 전체적인 시스템 응답 속도를 저하시킬 가능성이 있음.

2.2 At-Least-Once 방식의 장점

1. 성능 개선:
   • 메시지를 최소 한 번 이상 보낼 수 있기 때문에 네트워크 및 시스템 부하가 줄어들며, 더 빠른 처리 속도를 보장.
   • 트랜잭션 오버헤드 없이 빠른 처리 가능.
2. 운영이 단순해짐:
   • Exactly-Once 방식에 비해 설정이 간단하며, 장애 복구 시에도 전체 트랜잭션을 롤백하지 않고 개별 메시지를 기반으로 정합성을 관리 가능.
   • 중복 메시지가 발생할 수 있지만, 서비스 레이어에서 멱등성(idempotency)을 보장하면 문제 해결 가능.
3. 확장성 증가:
   • At-Least-Once 방식은 다량의 메시지를 빠르게 처리할 수 있어, 높은 트래픽을 감당해야 하는 시스템에서 유리.
   • 클러스터 확장 시에도 성능 저하 없이 안정적인 운영 가능.

3. 해결책 수립

3.1 해결책 비교

3.2 최적 해결책 선택

At-Least-Once 방식에서 멱등성 처리(idempotency) 를 추가하는 방식이 가장 현실적인 해결책으로 판단됨.

• 선택 이유:
  • Exactly-Once 방식은 성능 저하 및 운영 복잡성이 크므로, 대량의 트래픽을 처리하는 환경에서는 비효율적.
  • At-Least-Once 방식에서는 메시지가 중복될 가능성이 있지만, 고유 ID(UUID) 기반 중복 방지, Redis 캐싱, 데이터베이스 중복 검사 등의 기법을 적용하면 데이터 정합성을 유지하면서도 성능을 확보할 수 있음.
  • 특히, 고속 처리가 필요한 마이크로서비스 환경에서는 At-Least-Once 방식이 더 유리함.

4. 결론

Kafka 운영 과정에서 Exactly-Once 방식에서 At-Least-Once 방식으로 변경한 이유는 성능 저하와 운영 복잡성을 줄이면서도 확장성을 확보하기 위함이었다. 중복 메시지를 방지하기 위해 멱등성 로직을 적용하여 데이터 정합성을 유지하는 것이 핵심 해결책이었다.

Kafka 운영 시, 설정 최적화 및 모니터링을 병행하여 장애 발생 시 빠르게 대응하는 전략이 필요하다. At-Least-Once 방식은 중복 메시지 처리를 필요로 하지만, 적절한 멱등성 로직을 적용하면 성능과 데이터 정합성을 모두 만족할 수 있는 현실적인 대안이 된다.

1. 메시지 순서 보장 문제

1.1 문제 발생

Kafka는 기본적으로 파티션 단위로 메시지의 순서를 보장하지만, 다중 파티션을 사용할 경우 메시지 순서가 보장되지 않는 문제가 발생했다. 이로 인해 서비스의 일관성이 깨지고, 처리 순서가 중요한 비즈니스 로직에 혼란이 발생했다.

1.2 원인

1. 다중 파티션 사용 시 순서가 보장되지 않음
   • Kafka는 메시지를 여러 개의 파티션에 분산 저장하며, 컨슈머가 다수일 경우 각 컨슈머가 다른 순서로 메시지를 소비할 수 있음
2. 리밸런싱(Rebalancing) 과정에서 메시지 순서가 깨짐
   • 컨슈머 그룹이 리밸런싱될 경우 특정 컨슈머가 다른 파티션을 처리하게 되어 순서가 깨질 가능성이 존재

1.3 해결책 수립

1. 단일 파티션 사용 : 순서를 절대적으로 보장하지만 확장성이 떨어짐
2. Kafka Streams를 활용한 순서 재구성 : 운영 부담이 크고 개발이 복잡함
3. 메시지 키를 활용하여 동일한 파티션으로 메시지 전송 : 순서를 유지하면서도 확장성이 뛰어남 (최적 해결책)

1.4 해결 방법 선택 및 이유

메시지 키를 활용하여 동일한 파티션으로 메시지를 전송

ProducerRecord<String, String> record = new ProducerRecord<>("order-topic", orderId, orderData);
producer.send(record);

• 선택 이유: 동일한 키(Order ID 등)를 가진 메시지는 같은 파티션에 저장되어 순서가 유지되므로, 다중 파티션을 사용할 경우에도 일관성을 보장할 수 있음. 성능 저하를 최소화하면서도 확장성을 유지할 수 있는 가장 실용적인 방법.
• 다른 방법과의 비교: 단일 파티션을 사용하는 방법은 절대적인 순서를 보장할 수 있으나, 성능 확장성이 제한되므로 현실적으로 적용이 어렵다. 반면, Kafka Streams를 이용한 순서 재구성 방식은 추가적인 개발 및 설정이 필요해 운영 부담이 크다.

2. 중복 메시지 처리 문제

2.1 문제 발생

Kafka는 기본적으로 At-Least-Once 메시징을 보장하기 때문에 컨슈머가 동일한 메시지를 여러 번 소비할 가능성이 발생했다. 이는 데이터의 중복 삽입, 리소스 낭비 및 트랜잭션 오류로 이어질 수 있다.

2.2 원인

1. 컨슈머 오프셋 커밋 실패
   • 컨슈머가 메시지를 처리한 후 오프셋 커밋 전에 장애가 발생하면 동일한 메시지가 다시 처리될 가능성이 있음
2. 프로듀서에서 동일한 메시지가 여러 번 전송될 가능성
   • 네트워크 장애 등으로 인해 프로듀서가 동일한 메시지를 여러 번 보낼 수 있음

2.3 해결책 수립

1. Kafka의 Exactly-Once Processing 활용 : 중복 방지가 가능하지만 성능 부담이 큼
2. Redis 또는 DB를 활용한 중복 방지 로직 추가 : 외부 스토리지가 필요하여 운영 비용 증가
3. 멱등한 메시지 처리(Idempotent Consumer) 구현 : 트랜잭션을 단순하게 유지하면서도 중복 처리가 가능 (최적 해결책)

2.4 해결 방법 선택 및 이유

멱등한 메시지 처리(Idempotent Consumer) 구현

• 선택 이유: 가장 일반적인 해결 방법으로, UUID 등의 고유한 ID를 활용해 중복 메시지를 무시함으로써 트랜잭션을 단순하게 유지할 수 있음. Kafka의 Exactly-Once Processing보다 성능 부담이 적고 설정이 간단하여 운영 비용이 낮아짐.
• 다른 방법과의 비교: Kafka의 Exactly-Once Processing 모드는 중복 메시지 문제를 원천적으로 해결할 수 있으나, 성능 부담이 크고 설정이 복잡하여 운영에 부담이 된다. Redis 또는 데이터베이스를 활용한 중복 방지 방식은 단순하지만, 외부 스토리지를 필요로 하므로 유지 비용이 발생한다.

3. 결론

Kafka 운영 과정에서 발생한 메시지 순서 보장 및 중복 메시지 처리 문제를 트러블슈팅한 결과, 주요 해결 방법과 그 이유를 정리하면 다음과 같다.

1. 문제 상황

서비스 간 비동기 메시징을 도입하려 할 때, Redis PUB/SUB, RabbitMQ, Kafka 중 어떤 메시지 브로커를 사용할지 고민해야 했다. 각각의 기술은 특정 용도에 강점을 가지고 있지만, 서비스 요구 사항에 따라 적절한 선택이 필요했다.

1.1 서비스 요구 사항

1. At-Least-Once 메시지 보장: 메시지가 손실되지 않아야 함
2. 구독형 메시징 지원: 하나의 이벤트를 여러 개의 소비자가 구독할 수 있어야 함
3. 확장성과 내구성: 대량의 메시지를 안정적으로 처리할 수 있어야 함
4. 클러스터링 및 장애 복구 가능성: 서비스가 확장되더라도 안정적으로 운영 가능해야 함

이를 기반으로 Redis PUB/SUB, RabbitMQ, Kafka를 비교한 결과, Kafka를 선택하게 되었다.

2. Redis PUB/SUB의 한계

Redis는 빠르고 간단한 구독(Publish-Subscribe) 모델을 제공하지만, 특정 요구 사항을 충족하기 어려웠다.

2.1 장점

1. 빠른 메시징 속도: 메모리 기반이므로 지연이 거의 없음
2. 간단한 구조: 설정이 쉽고 사용하기 간편함
3. 실시간 처리 가능: 즉각적인 메시지 전송 가능

2.2 한계점

1. 메시지 저장 기능 부족: 메시지가 소비되면 사라지므로, 메시지를 다시 받아야 할 경우 별도의 저장소가 필요함
2. 신뢰성 부족: 서버가 재시작되면 메시지 손실 가능성 높음
3. 확장성 부족: 클러스터링을 통한 메시지 분산이 어렵고, 트래픽이 커질수록 관리 부담 증가

Redis를 사용하면서 At-Least-Once 보장을 하려면 별도의 저장소(RDBMS, 파일 시스템 등)에 데이터를 보관해야 함

3. RabbitMQ의 한계

RabbitMQ는 전통적인 메시지 브로커로서 신뢰성 높은 메시징을 제공하지만, 특정 요구 사항을 만족하기 어려웠다.

3.1 장점

1. 메시지 저장 가능: 디스크 기반으로 메시지를 보관 가능
2. 복잡한 메시지 라우팅 지원: 여러 개의 Exchange 타입을 제공하여 유연한 메시지 전달 가능
3. 트랜잭션 지원: 메시지를 처리하는 동안 실패하면 다시 처리 가능

3.2 한계점

1. 구독형 메시징 부족: 하나의 메시지를 여러 개의 그룹이 구독하는 기능이 없음 (여러 그룹에서 동일한 메시지를 사용하려면 별도의 메시지 복제 필요)
2. 확장성 문제: 클러스터링을 통해 확장 가능하지만, 대량 트래픽 처리에는 한계
3. 메시지 처리량이 Kafka보다 낮음: 대량의 데이터 스트리밍에는 적합하지 않음

RabbitMQ는 메시지 저장과 트랜잭션을 보장하지만, 하나의 메시지를 여러 개의 소비자가 구독하는 구조가 필요할 경우 메시지를 여러 번 전송해야 함.

4. Kafka를 선택한 이유

Kafka는 대량의 메시지를 안정적으로 처리할 수 있는 분산형 메시지 브로커로, 높은 내구성과 확장성을 제공한다.

4.1 장점

1. 메시지 저장 가능: 메시지를 로그 형태로 저장하여 재처리 가능
2. 구독형 메시징 지원: 하나의 메시지를 여러 개의 컨슈머 그룹이 구독 가능
3. 확장성 우수: 클러스터링을 통해 수평 확장 가능
4. 대량 데이터 처리 가능: 초당 수백만 개의 메시지를 처리할 수 있음
5. 장애 복구 가능: 데이터 복제(replication) 기능이 있어 장애 발생 시에도 데이터 유실 없음

4.2 한계점

1. 구성 및 운영이 복잡: Kafka 클러스터를 관리하려면 추가적인 인프라 설정이 필요함
2. 레이지 소비(Lazy Consumption) 특성: 실시간 처리보다는 대량의 데이터를 안정적으로 전달하는 데 적합
3. AWS에서 비용 부담: Kafka를 AWS에서 운영할 경우 클러스터링 비용이 상당히 높음

최종 선택: Kafka는 대량의 메시지를 안정적으로 처리해야 하고, 여러 개의 서비스가 동일한 메시지를 구독해야 하는 경우 최적의 선택이었다. 특히 메시지가 일정 시간 보관된다는 점에서 MSA의 정합성 문제 해결에 큰 장점을 보였다.

5. Kafka 사용 결정 요약

5.1 Kafka를 선택한 이유

1. At-Least-Once 메시지 보장이 가능하고, 메시지를 저장할 수 있음
2. 여러 컨슈머 그룹이 동일한 메시지를 구독할 수 있어 중복 메시지 전송이 필요 없음
3. 대량 트래픽을 안정적으로 처리할 수 있는 확장성 제공

5.2 추가 고려사항

1. Kafka를 AWS에서 클러스터링으로 운영할 경우 비용이 높아질 수 있음
2. 작은 규모의 서비스에서는 Kafka 대신 RabbitMQ나 Redis를 사용하여 운영 부담을 줄일 수도 있음

결과적으로, Kafka는 대규모 분산 시스템에서 높은 확장성과 데이터 보존 기능이 필요한 경우 최적의 선택지였으며, 서비스의 요구 사항에 맞춰 RabbitMQ나 Redis와 병행하여 사용할 수도 있다.