구현

티켓팅 연습 서비스를 구현하며 내가 사용해보고 싶은 기술을 연습하고 다양한 비즈니스 로직을 처리하고 있다.https://kitaees.tistory.com/96  Docker + GitHub Actions로 CI/CD와 배포하기 (Minikube 테스트와 EC2 프리티어 한계)새로운 사람들과 프로젝트를 시작하며 가장 귀찮고 어렵지만 중요한 서버 배포를 맡았다. 잘못하면 과금이 나가는 AWS와 실질적인 코드를 치는 작업은 거의 없지만 스트레스는 많이 받는 서버kitaees.tistory.comhttps://kitaees.tistory.com/97 실 유저와 가상 유저의 티켓팅 경쟁을 위한 대기열 구현기 (Redis)티켓팅을 위한 트래픽 발생 (서론)요즘 새롭게 하고 있는 프로젝트인 TiCatch의 메인 아..

티켓팅을 위한 트래픽 발생 (서론)요즘 새롭게 하고 있는 프로젝트인 TiCatch의 메인 아이디어는 '티켓팅 연습'이다. 많은 사람들이 한꺼번에 몰리는 티켓팅을 연습시켜주는 서비스라고 생각하면 된다. 우리가 생각하는 그런 티켓팅을 할 만큼 실제 유저를 모으기가 쉽지 않기에 가상 유저들과 경쟁을 하는 서비스이다. 사람들이 한꺼번에 몰리기 때문에 실제 티켓팅을 하기 전의 '대기열'이 상당히 중요한데 이번에는 이 '대기열'을 어떻게 설계하고 구현했는지 기록해보도록 하겠다.  처음에는 프론트에서는 실제 유저의 요청만, 나머지 가상 유저의 트래픽은 백엔드에서 쏴주는 걸로 생각을 했다. 근데 그렇게 했을 때 많은 트래픽을 대기열에서 처리하는데, 이 대기열도 백엔드이고 많은 가상 유저의 트래픽도 백엔드에서 하는게 조..

새로운 사람들과 프로젝트를 시작하며 가장 귀찮고 어렵지만 중요한 서버 배포를 맡았다. 잘못하면 과금이 나가는 AWS와 실질적인 코드를 치는 작업은 거의 없지만 스트레스는 많이 받는 서버 배포 작업이었지만, 저번 하반기부터 클라우드에 대한 관심이 생겨 배포 작업을 자원했다. [Github Action + AWS S3 + AWS CodeDeploy + AWS EC2]- Github Action을 통해 코드를 빌드하고, 이를 압축하여 AWS S3에 업로드, 그리고 원격 서버에서 S3로부터 파일을 가져다가 압축 해제 후 배포하도록 하는 방식 내가 이때까지 진행해오던 프로젝트에서는 CI/CD 파이프라인 및 서버 배포를 위의 방식을 채택해서 사용해왔다. 그 당시에는 해당 파이프라인을 선택한 이유가 다름이 아니라 구..

https://kitaees.tistory.com/94 [구현] 멀티스레드 상황에서의 자원 경쟁 (1)싱글스레드 상황이 아니라 멀티스레드 환경에서 한정된 자원을 경쟁하는 시뮬레이션을 하기 위해 간단한 예제와 함께 공부해보았다. https://www.youtube.com/watch?v=LDi5muN2kgI 테코톡에서 '우르'님이kitaees.tistory.com이번에는 저번 글에 이어 동시성 문제에서 LOCK을 사용해 문제를 해결해보도록 하겠다. 우리는 JPA에서 제공하는 낙관적/비관적 락을 사용해볼 예정이다. 우선 낙관적 락부터 보도록 하자. OptimisticTicket.javapackage jpa.lock;import jakarta.persistence.*;import lombok.Getter;imp..

싱글스레드 상황이 아니라 멀티스레드 환경에서 한정된 자원을 경쟁하는 시뮬레이션을 하기 위해 간단한 예제와 함께 공부해보았다. https://www.youtube.com/watch?v=LDi5muN2kgI 테코톡에서 '우르'님이 발표해주신 예제 코드와 내용을 바탕으로 따라해보면서 공부했음을 미리 알립니다. 우선, 경쟁 상황을 가정해보면 20명의 사람이 있고 5개의 티켓이 있다고 가정한다. 20명의 사람이 동시에 한정된 자원인 5개의 '티켓'에 접근하고자 하는 것이다. 일반적으로 생각했을 때 티켓이 5개 있기 때문에 5명의 사람이 티켓 획득에 성공하고 15명은 획득에 실패하는 것이다. 이제 예시 코드를 봐보자. Ticket.java@Entity @Getter@NoArgsConstructorpublic cla..

회사 프로젝트 중 싱글톤 패턴을 활용해 코드를 짜고 있었다. 스프링에서는 기본적으로 싱글톤 패턴을 제공해주고 있지만 직접 구현하고 쓰는 건 처음이다. 싱글톤 패턴이란 객체의 인스턴스가 오직 1개만 생성되는 패턴을 의미하며 이런 정의는 모두나 알고 있지만 구체적으로 어떻게 쓰이는지, 또 여러 방식으로 쓰이지만 각 방식에 있어서 장단점이 무엇인지 알게된 뿌듯한 시간이었다. 1. Eager Initialization 우선 가장 간단한 방식으로 Eager Initialization 방식이 있다. 코드부터 보도록 하자 public class VoteUtil { private static VoteUtil instance = new VoteUtil(); private VoteUtil() {} public static..

JPA를 사용해서 엔티티에 생성되어있는 created_at과 updated_at의 중복 코드를 줄여보도록 하자 내가 진행하고 있는 프로젝트에서 기존의 Entity들은 아래 코드처럼 컬럼이 정의되어 있었다. @Column(name = "created_at", nullable = false) private LocalDateTime createdAt 그리고 엔티티들이 생성될 때, 나는 각각 생성자에 LocalDateTime.now()를 통해 DB에 저장시켜줬다. @Builder public Answer(String content, Integer emotion, LocalDate date, User user, Boolean isPublic, Boolean isPremium, Boolean isSpare){ th..

왜인지는 모르겠으나 이번 애플 소셜로그인 탈퇴 기능을 구현하면서 생각보다 레퍼런스가 적음을 알았고 저도 구현했던 개념을 공부하고 정리할 겸 블로그에 작성하게 되었습니다. 혹시나 궁금하신 점이나 틀린 점이 있으면 댓글로 남겨주시면 바로 반영하겠습니다 🤔 애플 소셜로그인 탈퇴 도입 과정 기존에 회원탈퇴 기능이 없었던 것은 아니었습니다. 기존의 회원탈퇴 로직은 1. 클라이언트 측에서 회원 탈퇴 요청 (REST API) 2. 서버 측에서 유저 정보 확인 3. 서버 측에서 해당 유저가 작성한 모든 답변 삭제 처리 4. 서버 측에서 해당 유저의 정보를 지우는 것이 아닌 STATUS 컬럼 UPDATE 처리 위 로직을 따르고 있었습니다. 하지만 애플 측에서 하는 말을 보면 애플 소셜로그인 과정에서 사용자 토큰을 넘겨주..

오랜만이에요! 텔링미(https://tellingme.co.kr) 개발팀장이자 서버 개발자인 키태 입니다. 이번 1차 출시에서 푸시알림을 구현하면서 너무나 많은 어려움을 겪었고 레퍼런스가 부족하다고 생각해 모두를 위해 또 저를 위해 저만의 레퍼런스를 작성해볼까 합니다! 개발 환경 사실 참 사소한 글이지만 저는 다른 레퍼런스들을 보면서 저의 개발 환경과 달라 따라하다가 그만두고 실패하고를 많이 반복했기에.. 레퍼런스에 개발 환경을 적어주는 경우가 편했습니다. 다른 분들도 혹시 저의 레퍼런스를 보고 따라하기 전, 자신의 개발 환경과 맞는지 꼭 확인해보세요! Spring Framework - 2.5.9 java - 11 com.google.firebase:firebase-admin:6.8.1 그리고 저희는 클..