이번 주차에서는 이벤트 발행과 브로커, 그리고 컨슘에 대해 배웠다.사실 이러한 개념에 대해 잘 와닿지 않았는데 멘토님이 설명해주신 그 식당썰 덕에 바로 와닿게 되었다 ㅎㅎ (최고) 사실 주문 트랜잭션에 주문 로직과 결제 로직을 모두 넣으면서 그동안 하나의 트랜잭션에서 관리되어야 맞다고 생각해왔다.왜냐면 결제가 실패하면 주문이 실패해야 맞지.. 아니면 중간이 삐긋하면 어떡해.. 롤백해야지 라는 생각을 계속 지니고 있었다.하지만 이번주차를 배우면서 핵심 트랜잭션과 부수적인 트랜잭션을 나누면서 서로 경계를 잘 지켜야 된다는 것을 알게 되었다. 또한 내가 그동안 실무에서 작성한 코드들의 트랜잭션이 지닌 역할이 너무 크다는 것을 또한번 느끼게 되었다. (언제 수정하징 ...ㅜㅠㅠ) 아무튼 ! 이번 주차도 무사히 ..

개요주문을 하면서 결제 API 로 인해 시간 지연이 되면 주문 트랜젝션도 그만큼 오래 가져가야 할까 ?좋아요 처리를 할 때, 좋아요는 성공 했지만 상품의 좋아요 집계 처리를 하는 데에 실패하면 좋아요도 취소되어야 할까 ?이런 질문들은 이벤트 처리를 함으로써 해결할 수 있다. 그러면 한번 이벤트를 발행하고, 소비하는 것에 대해 알아보자이벤트 처리그렇다면 여기서 이벤트란 무엇일까 ? 이벤트는 한마디로 "사건" 이다.그렇다면 사건은 무엇을까? 그리고 우리가 자주 말하는 이벤트 프로듀서, 이벤트 브로커, 이벤트 컨슈머는 무엇일까 ? 예시를 들어보자.나는 식당에 가서 밥을 먹으려고 한다. 그래서 주문을 하고자 한다."여기 주문좀 해주세요"그랬더니 어떤 종업원이 1번 테이블 주문이요 ~ 라고 외친다.그러자 1번 테..

이번주는 장애에 1차적으로 대응하는 방법에 대해 알아보았다.내가 회사에서 진행중인 서비스는 모두 외부 api를 통해 로그인을 하도록 되어있다. 그런 기능을 구현하며 이렇게 외부 api 호출 실패 시, 어떻게 해야하는지를 고려해본 적이 없다. 따라서, 사용자가 많아져 외부 api 서버에 부하가 많아져서 서버에러가 발생한다면 이런식으로 대처하면 좋을 것 같다는 생각이 들었다. 또한, 트랜젝션에 대해 한번 더 생각하게 되었다.테스트코드를 돌려보니 결제 부분에서 포인트결제와 카드결제를 분기하는 함수에 트랜젝션이 새로 만들어지도록 헤두었더니 동시성 이슈가 생겼다. 그래서 범위를 카드 결제로만 좁히니 다시 동시성 오류가 발생하지 않게 되었다이런 식으로 트랜젝션 범위를 어느정도로 가져갈 지 또한 중요하다는 것을 한번..

개요여러 프로젝트를 진행하는 동안 외부 API를 사용하는 경우가 많았다. 가볍게는 소셜로그인부터 카카오톡 메세지 전송, 사내 앱 푸시 알림 등 운영중인 프로젝트에서도 사용하였다.하지만 모든 경우에 장애가 발생한다는 것을 확인하지 않았다. 장애가 발생하면 바로 실패메세지가 뜨고, 따로 다시 시도를 한다거나, 얼만큼 기다렸다가 시도를 한다거나 하는 것 말이다. 수업에서 사용하는 도메인은 커머스로서, 사용자가 결제요청을 했고 모든 정보를 입력하였음에도 불구하고 외부 API가 불안정하다는 이유만으로 결제가 되지 않는다면 이는 회사의 실질적인 매출에 영향을 줄 것이다.그래서 이번 주에는 외부 API를 의존하고, 이에 문제가 발생할 경우 어떻게 대처해야할 지에 대해 배우게 되었다.RestTemplate 이용하기외부..

개요이번 주차의 대주제는 "성능 최적화" 이다.회사의 팀내 서비스는 모든 사용자들의 수가 탈퇴한 회원까지 다 합쳐도 500명 채 되지 않는 서비스이다 보니 사실 성능이 그다지 중요하지는 않다. 하지만 최적화는 하면 할수록 생각을 더 많이하게 하는 것이기 때문에 열심히 해보고자 한다.우선 요구사항은 다음과 같다.Structure상품 목록/상세 조회 시 좋아요 수를 조회 및 좋아요 순 정렬이 가능하도록 구조 개선을 진행한다.좋아요 적용/해제 진행 시 상품 좋아요 수 또한 정상적으로 동기화되도록 진행한다. 인덱스상품 목록 API에서 brandId 기반 검색, 좋아요 순 정렬 등을 처리한다.조회 필터, 정렬 조건별 유즈케이스를 분석하여 인덱스를 적용하고 전 후 성능비교를 진행한다. (Optional 카디널리티 ..

이번주에는 동시성에 대해 배웠다.사실 내가 회사에서 제공하는 서비스들은 동시성을 고려하지 않아도 된다. 유저가 적기도 하고, 특정 시간에만 잠깐 사용하는 서비스 위주로 구현하고 있기 때문이다.그런데 이번에 멘토링중 이야기하셨던 것이 사람이 따닥하는 것 뿐만 아니라 네트워크 문제 등으로 인해 동시성 문제가 발생할 수 있다고 하셨다. 포인트 같은 경우에도 동일한 유저가 같은 상품을 다른 기기로 동시에 주문하여 보유 포인트보다 더 많은 상품을 살 수 있는 경우가 거의 없지만, 요청은 1-2초정도 차이가 나도 서버에 동시에 도착할 수 있다고 하신게 기억에 남는다.그래서 나도 돈과 관련이 있거나 아니면 뭔가 이력이 중요할 때 이러한 식으로 동시성 문제를 고려하며 코드를 작성해볼까하는 생각이 들었다. 아무튼 이번주..

한 번쯤 이런 생각 해본 적 있을 것이다“주문을 한 번만 눌렀는데, 상품이 두 개 왔으면...”소비자 입장에서는 꽤 기분 좋은(?) 일이지만, 개발자나 서비스 운영자 입장에서는 절대 웃을 수 없는 심각한 시스템 오류이다. 이런 문제는 종종 동시성 문제(Concurrency Issue)로 인해 발생한다. 이번 글에서는 동시성 문제란 무엇인지, 그리고 이를 해결하는 대표적인 방법인 낙관적 락(Optimistic Lock), 비관적 락(Pessimistic Lock)에 대해 알아보고자 한다.동시성 문제란?동시성 문제란 여러 요청이 같은 데이터에 동시에 접근하거나 수정하려고 하면서 발생하는 문제이다. 그런데 컴퓨터는 한 번에 하나씩 처리하는 거 아닌가?맞다. 실제로는 동시에 처리되는 게 아니라 아주 빠른 시간 ..

이번 주차는 설계에 대해 배웠다. 사실 회사에서 우리 팀에 백엔드에 대해 자세히 아시는 분이 많이 없어 시퀀스 다이어그램, 클래스 다이어그램 등은 거의 그리지 않고, 로직에 대한 플로우차트 정도만 그리고 있다.하지만, 이번 강의를 듣고, 만약 5개월간 프로젝트를 한다면 그중 4개월은 설계이고 나머지 1개월 동안은 설계한 것을 구현하는 시간이라는 것을 알게 되었다. 즉, 설계를 다같이 하고, 설계대로 구현하는 것을 개발자가 하는 것이다. (사실 이 부분이 이번 주차에서 가장 크게 와닿은 부분이었다.)만일 그렇게 한다면 설계문서만 봐도 개발자든, 비개발자든 모두 같은 로직으로 이해할 수 있을 것이라 생각이 든다. (너무너무 좋은 방법이고 배우고 싶은 방법이라, 나도 회사에서 이러한 식으로 해보자고 건의할 생..

* 해당 포스팅에 나오는 내용과 코드들은 아직 학습중이기 때문에 완벽하지 않음을 알려드립니다.* loop:Pak L2 Backend에서 공부하며 배운 것들과 생각한 것들을 정리한 내용입니다.개요요즘 회사에서 새로운 프로젝트를 들어가기 위한 프로젝트 설계작업을 거의 하루종일 하고 있다. 그러면서 만들고자 하는 서비스를 사용하게 될 사람들에게 무엇이 필요한지 물어보고 이를 해결하기 위해 어떤 정보들이 있는지, 그리고 어떤 식으로 정보를 전달하면 좋을 지에 대해 고민하고 있다.이에 맞춰 loop:Pak 에서도 설계 관련 강의를 듣게 되었다.그래서 이번 기회에 설계에 대해 배우고 회사 업무에 적용할 수 있는 문서 작성법에 대해 알아보고자 한다.모든 프로세스는 주문하기 기능을 위주로 작성해보도록 하겠다.요구사항 ..