Ficket

🎈 Eureka Server 구축 1. 프로젝트 생성 프로젝트를 생성할 때 Eureka Server 의존성을 추가합니다. 이 Eureka Server는 API Gateway와 각 서비스의 위치 정보를 관리하는 역할을 하게 됩니다. Eureka Server 의존성

도입 배경 현재 Ficket 프로젝트는 user, admin, event, queue, ticketing, face 총 6개의 마이크로서비스로 구성되어 있습니다. 초기에는 각 마이크로서비스에 개별적으로 인증/인가 로직을 적용하는 방식을 고려했으나, 이로 인해 코드의

Config 서버 도입 배경 현재 Ficket 프로젝트는 user, admin, event, queue, ticketing, face 총 6개의 마이크로 서비스로 구성되어 있습니다. 기존 방식에서는 각 마이크로 서비스의 설정 파일이 개별적으로 관리되고 있어, 공통 설

지난 시간에는 Config 서버 생성 및 설정을 진행하였습니다. 하지만 실행 중인 MSA(Microservices Architecture) 애플리케이션들이 Config 서버와 연결되어 있는 상황에서, Git에 저장된 user-service-local.yml 파일의 내

지난 글에서는 Git Repository를 Private으로 설정하여 Spring Cloud Config Server의 환경 설정 파일을 보호하는 방법을 다뤘습니다. 하지만, 이 방식만으로는 환경 설정 파일의 중요한 정보(예: 데이터베이스 비밀번호, API 키 등)가

저번에 Config Server 암호화를 통해 Spring Cloud Config Server에 암호화를 적용하였습니다. 하지만 몇 가지 의문이 생겼습니다. 암호화를 적용했음에도 민감한 설정 값들이 충분히 안전하게 보호되고 있는가? 예를 들어, Config Serve

문제 발생 Spring Cloud Config 서버에서 암호화된 데이터를 복호화하려는 과정에서 아래와 같은 오류가 발생했습니다: 원인 Config 서버 설정에서 복호화 기능이 비활성화된 상태(spring.cloud.config.server.encrypt.enabl

이번 프로젝트에서는 MSA 기반 프로젝트를 개발하면서 Kafka Connect를 사용하여 독립적인 서비스 간의 DB를 동기화했습니다. 이 글에서는 Kafka와 Kafka Connect 설치부터, MySQL JDBC Connector 설정 및 Docker Compose

마이크로서비스 아키텍처(MSA)는 각각 독립적으로 배포 및 운영될 수 있는 서비스로 구성됩니다. 그러나 이러한 독립성에도 불구하고, MSA 환경에서는 서비스 간에 통신이 필요한 경우가 빈번히 발생합니다. 이를 통해 각 서비스가 데이터를 공유하고 협력하여 사용자의 요구를

개요 MSA(Microservices Architecture) 환경에서는 여러 서비스 간의 통신이 빈번히 이루어집니다. 하지만 특정 서비스에서 장애가 발생하거나 응답 시간이 지연되면 호출하는 서비스에도 영향을 미쳐 전체 시스템의 장애로 이어질 수 있습니다. 이 글에서는

Ficket 프로젝트는 얼굴 인식을 기반으로 한 티켓팅 서비스를 제공합니다. 얼굴 인식 서비스 개발을 위해 빠른 프로토타이핑, 유연한 확장성, 그리고 Python 기반 환경에서의 효율적인 통합이 중요했습니다. 이를 충족하기 위해 경량 웹 프레임워크인 Flask를 서버

Ficket 프로젝트는 얼굴 인식 기반 티켓팅 프로젝트로, 공연 데이터를 실시간으로 관리하며 사용자들에게 빠르고 정확한 검색 환경을 제공하는 것을 목표로 하고 있습니다. 이 프로젝트는 MSA(Microservices Architecture) 기반으로 설계되어 이벤트

저번에 설계했던 시스템은 검색엔진 서버와 이벤트 서버를 중심으로 한 데이터 색인 및 검색 시스템이었습니다. 주요 기술 스택으로는 Elasticsearch, Redis, MongoDB, Object Storage, Spring Boot, Kibana를 사용하여 데이터 색

1. Spring Batch 이전 글에서는 Elasticsearch, Kibana, Redis, MongoDB를 Docker Compose로 구성하는 과정을 다루었으며, 이번 글에서는 Spring Batch, Quartz 설정, CSV 파일 생성 및 S3 업로드, K

이전 글에서는 Elasticsearch, Kibana, Redis, MongoDB를 Docker Compose로 구성하는 과정을 다루었으며, 이번 글에서는 인덱스 생성, S3 저장소 설정, 그리고 전체 색인 작업을 진행하겠습니다. 전체 색인 작업 개요 전체 색인 작

이번 글에서는 Elasticsearch 부분 색인 작업에 대해 다룹니다. 부분 색인은 데이터 변경 이벤트(생성, 수정, 삭제)가 발생했을 때, 해당 데이터를 Elasticsearch에 실시간으로 반영하는 작업입니다. Kafka, Redis, MongoDB를 활용하여

이번 글에서는 Elasticsearch를 활용한 검색 기능 구현 과정을 다룹니다. 주요 목표는 이벤트 검색과 자동완성 기능을 제공하는 API를 설계하고, Elasticsearch의 강력한 검색 및 필터링 기능을 활용하여 성능과 사용자 경험을 극대화하는 것입니다. 검색

1. 문제 상황 로컬 환경에서는 Elasticsearch와의 통신이 정상적으로 이루어졌지만, Docker 환경에서 배포 후 애플리케이션이 Elasticsearch에 연결하려고 할 때 PKIX path building failed 오류가 발생했습니다. 이는 Elasti

1. 프로젝트 소개 Ficket은 얼굴 인식 기반의 티켓팅 서비스입니다. 이벤트마다 사용자가 몰리는 상황에서도 안정적이고 공정한 티켓팅을 제공하기 위해 대기열 시스템을 설계했습니다. 이번 글에서는 Ficket의 대기열 설계를 어떻게 했고, 그 설계를 구현하기 위해 어

이번 글에서는 지난번에 기획하고 설계했던 Ficket 대기열 시스템의 실제 구현 과정을 공유하려고 합니다. 기획 단계에서 설정한 목표는 Kafka, Redis, WebSocket, WebFlux를 활용해 공정하고 확장 가능한 대기열 시스템을 만드는 것이었습니다. 이번

1. 좌석 선점 티켓팅 시스템에서는 좌석이라는 고유 자원을 여러 사용자가 동시에 접근할 때 중복 예약을 방지해야 합니다. 이를 해결하기 위해 다음과 같은 요구 사항을 고려해야 합니다: 긴 락 유지 필요: 좌석을 선점한 사용자가 결제를 완료할 때까지 해당 좌석을 다

AWS Lambda 도입 배경 행사 등록 화면에서는 하나의 포스터 이미지와 하나의 배너 이미지를 등록하지만, 다양한 화면 요소에 맞춰 적절한 크기의 이미지가 필요합니다. 아래 설계도에서 볼 수 있듯이 각 이미지의 사용 목적에 따라 다양한 사이즈로 제공되어야 합니다.

Ficket은 얼굴 인식을 기반으로 한 티켓팅 서비스로, 사용자가 등록한 얼굴 이미지를 통해 현장에서 티켓 소지 여부를 확인할 수 있는 시스템입니다. 이 시스템은 InsightFace를 활용해 얼굴 임베딩(특징 벡터)을 생성하고, AES 암호화를 통해 데이터를 DB에

Ficket 프로젝트는 얼굴 인식 기반 티켓팅 프로젝트로, 사용자 얼굴 이미지를 안전하게 보관하기 위한 방안을 고민했습니다. 민감한 데이터를 다루는 만큼 보안이 가장 중요한 요소였고, 데이터 암호화와 접근 제어를 위해 S3의 SSE-KMS(Server-Side Encr

Ficket 프로젝트에서 얼굴 인식 기반 티켓팅 중, 티켓 구매를 구현하는 과정에서 PortOne(KakaoPay)을 사용하였습니다. 본 문서는 포트원 API V2, 웹훅 V2 버전(2024-04-25 기준), 테스트 기반으로 작성되었습니다. 1. 포트원 연동 (Ka

Ficket 프로젝트를 진행하며 조회수를 기준으로 실시간 랭킹 구현을 맡았습니다. 프로젝트에서는 기존에 Spring의 @Cacheable을 사용해 Redis 캐시를 통해 성능 최적화를 구현한 이벤트 상세 조회 API가 있었는데, 이를 활용하여 랭킹 시스템을 구현하려 했습니다. 하지만 캐시에 데이터가 있는 경우 조회수 증가 로직이 실행되지 않는 문제를 발견하...

문제 발생 이벤트 상세 조회 API에 @Cacheable을 적용하여 조회 시마다 DB 접근을 줄이고 응답 속도를 높이려 했습니다. 그러나 실제 서비스에서 적용 후, 조회수 랭킹이 갱신되지 않는 문제가 발생했습니다. 원인 분석 캐시된 응답이 반환되면서, 실제 조회수 증가 처리를 담당하는 로직이 실행되지 않았습니다. 특히 조회수 랭킹은 Redis의 ZS...

저번에 조회수 기준 랭킹을 구현한 데 이어, 이번에는 예매율 기준 랭킹을 구현했습니다. 구현할 내용은 다음과 같습니다. Redis Sorted Set 사용: 예매 수를 기반으로 상위 50개의 순위를 기록합니다. 키 설정: 일간, 주간, 월간 데이터와 장르별로 구분할 수 있도록 Redis 키를 설정합니다. 주문 성공 시 업데이트: 주문이 성공하면 R...

반영된 최종본 오픈 티켓 화면의 반응형 구현을 위해 Figma에서 화면 설계를 진행했습니다. 아래는 PC와 모바일 화면 설계 이미지입니다. 오픈 티켓 PC 화면 오픈 티켓 PC 화면 오픈 티켓 모바일 화면 오픈 티켓 모바일 화면 설계 차이점 PC와 모바일 화면

tinyMCE 에디터를 사용해서 저장하면 아래와 같이 <html> 태그 형식으로 데이터가 저장됨예시:이러한 방식으로 저장된 데이터는 XSS(크로스 사이트 스크립팅) 공격에 취약할 수 있습니다. 따라서 서버와 클라이언트 모두에서 XSS 방어를 적용해야 합니다.XSS

기존 쿼리 및 실행 시간 (약 3초) 목적 하나의 이벤트에 대해 여러 공연 일정이 존재할 수 있으며, 같은 날에도 여러 시간대의 공연이 열릴 수 있습니다. 예를 들어, 다음과 같은 공연 일정을 가진다고 한다면 2025년 7월 20일: 13시 공연, 20시 공연 2025년 7월 21일: 13시 공연, 20시 공연 이 경우, 프론트엔드에서는 단순히 시간...