분류 전체보기

티켓팅 연습 서비스를 구현하며 내가 사용해보고 싶은 기술을 연습하고 다양한 비즈니스 로직을 처리하고 있다.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..

최근 어느정도 업무에 익숙해지기도 했고 스스로 컴포트존(Comfort Zone)에 들어왔다고 생각했다. 집을 회사 근처로 옮긴 후에는 출근 전, 퇴근 후 조금이지만 체력과 시간이 남아있었다. 이 컴포트존에서 벗어나기 위해 해보지 않은 기술 공부, 공부를 하더라도 프로젝트에 옮길 수 있는 환경이 필요하다고 생각했었다. 운이 좋게도 학교 후배가 좋은 의미의 사이드 프로젝트를 같이하자고 연락을 줘서 선뜻 수락을 했다. https://causw.co.kr/ CAUSW causw.co.kr "동문 네트워크'라는 프로젝트이며 중앙대 소프트웨어학부 동문만 사용할 수 있는 커뮤니티 서비스로, 단순 소셜 네트워크 기능 뿐만 아니라 사물함 신청, 동아리 신청 및 학생회 사업/행사 신청 등 전반적으로 소프트 학생 사회를 하..

회사 프로젝트 중 싱글톤 패턴을 활용해 코드를 짜고 있었다. 스프링에서는 기본적으로 싱글톤 패턴을 제공해주고 있지만 직접 구현하고 쓰는 건 처음이다. 싱글톤 패턴이란 객체의 인스턴스가 오직 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..

[가상 면접 사례로 배우는 대규모 설계 기초]의 책을 읽고 공부한 내용을 정리하는 글 입니다. 사진과 내용을 해당 블로그에서 많이 참고했습니다. 감사합니다:) 먼저 대규모 시스템을 설계하기 전에, 가장 태초의 단일 서버인 상황을 생각해보자 이 단일서버에서 우선 사용자는 도메인 이름 (www.mysite.com)을 이용해서 웹 사이트에 접속한다. 그러면 DNS가 웹 서버의 IP 주소를 반환해주고 해당 IP 주소로 HTTP 요청이 전달된다. 그 후 웹 서버로부터 HTML 페이지나 JSON 형태의 응답이 반환되는 구조이다. 해당 구조에서 사용자가 늘어나면 당연히 서버 하나로는 부족할 것이다. 그래서 데이터베이스를 담당하는 서버를 하나 추가한다. 데이터베이스는 크게 RDBMS, NoSQL 2가지로 나눌 수 있는..

https://kitaees.tistory.com/55 [회고] 창업팀에서 백엔드 개발자로서 앱을 출시하며 느낀점 요즘 나는 중앙대학교 LINC 3.0 Start-up Members 학생 창업팀인 '텔링어스'에서 개발팀장 겸 백엔드 개발자로서 일하고 있다. 프로젝트 선에서 끝내는게 아닌 실제로 출시하고 유저들이 사용하며 조금 kitaees.tistory.com 위 글에서 말한대로 8월 중후반에 우리 팀은 앱 스토어에 서비스를 출시하는데 성공했다. 하지만 개발자 입장에서 마냥 완벽한 서비스는 아니었다. 출시 기간을 더이상 늦추면 루즈해진다고 판단해 위험성을 감수하고 출시했기 때문이다. 아직까지 크리티컬한 운영 에러는 나오지 않지만 분명 9월이 되어 서비스 마케팅을 시작하면 트래픽이 증가해 수많은 에러가 나..