docker-compose로 Cassandra 4.0 노드 3개짜리 클러스터를 로컬에 구성하며, node2·node3은 CASSANDRA_SEEDS=cassandra-db-node1으로 시드 노드를 지정해 클러스터에 참여시킨다. Cassandra의 기본 heap 메모리가 2GB이므로 mem_limit은 반드시 2g 초과로 설정해야 안정적으로 구동된다. 구동 후 cqlsh로 노드 1에서 데이터를 insert하고, 노드 2에서 조회하여 데이터가 클러스터 전체에 샤딩되었음을 확인한다.
Readaws-secretsmanager-jdbc 방식은 설정이 단순하나 Driver 고정 및 Credentials Provider Chain 오동작 위험이 있어, Spring Cloud AWS + DataSource Java Bean 방식을 권장한다. 환경별로 @Profile을 통해 로컬은 JVM 옵션의 Access Key로, 서버 환경은 EC2 IAM Role로 AWS 인증을 분리 구성한다. GetSecretValueResult에서 가져온 JSON 문자열을 DataSourceSecrets 모델에 Jackson으로 매핑하여 DB 접속 정보를 동적으로 주입한다.
ReadSpring Boot 2.7 환경에서 MariaDB Connector와 AWS Aurora(RDS) 조합 사용 시 드라이버 호환성 이슈가 발생할 수 있다. 특히 최신 MariaDB 드라이버(3.x)는 Aurora 전용 모드(aurora)를 지원하지 않아 기존 기능(읽기/쓰기 분산 등)이 제대로 동작하지 않을 수 있다. 따라서 상황에 따라 MariaDB Connector 2.x 유지 또는 AWS 전용 JDBC 드라이버로 변경하는 등의 대응이 필요하다.
ReadSQS의 DLQ(Dead Letter Queue)는 여러 번 처리에 실패한 메시지를 별도 큐로 분리 저장하는 구조다. 메시지는 설정한 재시도 횟수(maxReceiveCount)를 초과하면 자동으로 DLQ로 이동되어 메인 큐의 처리 흐름을 방해하지 않는다. 이를 통해 실패 메시지를 분석·재처리하고, 전체 시스템의 안정성과 장애 대응력을 높일 수 있다.
ReadQueue에서 Consumer는 큐에 쌓인 메시지를 가져와 실제로 처리하는 역할을 하는 주체다. 메시지는 Consumer가 처리할 때까지 큐에 저장되며, Consumer는 필요할 때 메시지를 가져와 비동기적으로 처리한다. 여러 Consumer가 존재할 경우 부하 분산 및 병렬 처리로 시스템 처리량과 확장성을 높일 수 있다.
ReadQueue에서 Producer는 메시지(이벤트/작업)를 생성해 큐에 넣는 역할을 하는 주체다. Producer는 처리 완료를 기다리지 않고 메시지만 전달함으로써 비동기 처리와 서비스 간 디커플링을 가능하게 한다. 이 구조를 통해 시스템은 부하를 분산하고 장애 상황에서도 유연하게 처리할 수 있다.
ReadSQS는 간단한 메시지 큐 기반으로 서비스 간 비동기 처리와 디커플링에 적합한 서비스다. 반면 MSK(Kafka)는 고속·대용량 데이터 스트리밍과 실시간 처리, 이벤트 기반 아키텍처에 최적화된 플랫폼이다. 즉, 단순 메시지 전달이면 SQS, 실시간 스트리밍·분석까지 필요하면 MSK를 선택하는 것이 핵심 기준이다.
ReadHTTP Referer 헤더는 사용자가 어떤 페이지에서 현재 요청으로 이동했는지(유입 경로)를 전달하는 정보다. Chrome에서는 보안 강화를 위해 Referrer-Policy에 따라 전달되는 정보 범위를 제한하며, 기본적으로 도메인 수준만 보내도록 변경되었다. 즉, 과거처럼 전체 URL이 아닌 프라이버시 보호를 위해 최소한의 정보만 전달되는 방향으로 정책이 변화한 것이 핵심이다.
ReadAPI에서 404는 단순히 “데이터 없음”이 아니라, 해당 리소스 자체가 존재하지 않을 때 사용하는 상태 코드다. 따라서 조회 결과가 없는 경우까지 무조건 404를 쓰는 것은 부적절하며, 상황에 따라 200(빈 결과) 등으로 구분해야 한다. 핵심은 HTTP 상태코드를 “리소스의 존재 여부” 기준으로 정확히 설계해야 한다는 점이다.
ReadAPPLE ID 잘 챙기자.
Read