hojak99 의 블로그

쿠팡, 네이버 스마트 스토어와 같은 e-commerce 기능을 개발하게 되었다. 처음으로 e-commerce 기능들을 설계, 개발하게 되면서 했던 고민과 생각들을 정리해서 작성해 보려한다. 이렇게 상세하게는 작성할 생각이 없었는데 그래도 많은 사람들이 도움이 됐으면 해서 정리를 한다. 상품 설계하기 먼저 상품을 크게 상품과 판매 상품으로 나누었다. 상품을 상품과 판매 상품으로 나눈다는 말이 이상하기도 하고 어색하기도 하다. 상품은 상품만의 고유한 특성만을 갖고 있는 것이고, 판매 상품은 판매 되고 있는 상품들을 뜻한다. 이렇게 분리한 이유는 아래의 예를 통해 설명하겠다. 쇼핑몰에서 상품을 관리하고 있는 A씨가 있다. A씨는 단일 상품으로 [티셔츠] 와 [바지] 를 따로 팔고 있었다. 그러나 두 개를 같이..

서버에 트래픽이 많이진다는 상상을 해봤다... 지금 내가 개발 중인 서버는 모놀리틱 기반의 서버이다. 결제에 관련된 기능들과 앱 서비스를 제공하기 위한 수 많은 기능들이 하나의 모놀리틱 서버에서 운영 되고 있다. 만약 사용자가 많아진다면 지금 현 서비스의 구조를 어떻게 가져갈지 고민을 해 보았다. 먼저, 아래에 적어놓는 점들은 시스템 설계를 할 때 고려해야 할 점이라고 한다. 아래와 같은 부분을 시스템 설계 시 참고해야 나중에 다시 설계를 하는 등의 일이 발생하지 않을 것이다. - 가용성 (오랜기간동안 지속적으로 이용 가능) - 성능 - 확장성 - 안정성 - 관리성 - 비용 예를 들어 완전 안전한 시스템을 설계했더니 비용이 너무 많이 나왔다. 경영진에서 비용이 너무 많이 나온다며 비용을 줄여달라고 한다면..

개발을 하다 보면 어떠한 요구사항에 따라 배치 기능을 개발해야 하는 상황이 온다. 예를 들어, "매일 자정에 하루 동안 생성된 데이터를 이용해서 통계를 내주세요!" 와 같은 기능들 말이다. 이 글을 쓰는 이유는 예시와 같은 배치 기능을 개발할 때 일반적으로 transaction 을 걸 텐데 이때 isolation 레벨에 따라서 성능이 달라질 수 있다는 것을 알리고자 작성한다.여기서 얘기하는 내용들은 mysql 5.6 버전 기준이다. 먼저, 왜 isolation 레벨에 따라 성능이 달라질 수 있는지 내 생각을 이야기해보도록 하겠다. mysql isolation 레벨은 다음과 같이 4가지가 존재한다. UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE ..

정산 작업이 존재한다. 사용자가 특정 페이지에서 머물고 있는 시간을 기준으로 하여 특정 시간이 넘어간다면 정산 대상이 되며, 한 번 정산이 된 사용자에게는 다시 정산이 되지 않도록 한다. 쉽게 생각하면 위와 같이 구성 돼 있다. 하루에 한 번씩 배치에서는 A DB 에서 사용자가 페이지를 머무른 기록이 존재하는 테이블에서 데이터를 가져와 B DB 에서 정산 기록 테이블에서 정산 유무를 파악하여 이번 달에 정산이 되야 할 사용자인지 아닌지 판별해야 한다. 그러면 spring batch 에 step 이라는 개념이 존재하는데 해당 step 을 tasklet 으로 구현을 할지 reader, processor, writer 로 구현할지 고민이 되었다. 우선 처음에 생각했던 정산이라는 job 에 대한 작업은 다음과 ..

2021년 6월 N일 오전 11시였다. 갑자기 beanstalk 환경이 재구축이 되면서 한 동안 서비스가 중단 되었다. 1시간 전으로 돌아가서... 오전 10시 출근하자마자 나는 새로 입사하신 개발자분들과 함께 새로운 서비스를 위한 실서버 환경에서 beanstalk 환경을 구축하고 있었다. 그러니 갑자기 다음과 같은 로그가 있었다. 나는 그저 환경을 하나 새로 구축 밖에 하지 않았다. 우선 매우 당황했고 슬랙에 알렸다. 실서버가 다 사라졌다고.. 앱, 웹 접속이 되지 않을 것이라고.. 우선 어찌어찌해서 환경을 새로 만들어서 서비스 정상화를 시켰다. 그리고 원인을 파악하려고 여러 로그를 뒤졌다. 먼저, 재구축 시도한 환경이 새로 살아나지 않는 현상이 발생했다. 다음과 같은 에러를 뿜으며 새로 재구축이 되지..

내가 개발하고 있는 서비스는 매달 구독이 일어난다. 사용자는 첫구매를 진행하고 난 뒤 넷플릭스처럼 다음 달에 자동으로 결제가 이루어지게 된다. 또한, 사용자는 홈페이지에 들어가서 환불/해지를 진행할 수 있다. 재구독 결제 로직이 진행되는 중에 사용자가 환불을 했을 때는 어떻게 하는 것이 좋을까? 물론 요구사항에 따라서 구현 방법이 달라지겠지만 우선 '재구독 중 환불 시 진행 중인 결제는 정상적으로 진행하고 환불을 진행한다.' 로 요구사항을 정하도록 하겠다. 작성 중

'직접 회원가입 하고 로그인하기' 와 'SNS 로 로그인하기' 기능이 존재할 때 로그인을 어떻게 구현할까에 대해 작성한다. 요구사항과 정책에 따라 구현도 달라지기 때문에 다음과 같이 정해보도록 한다. 1. 직접 회원가입 후 로그인을 할 수 있다. 2. 직접 회원가입 한 다음 SNS 연동을 할 수 있다. 3. SNS 연동 시 email 을 기준으로 유저를 식별한다. 4. SNS 에서는 email 을 변경하지 못한다. 5. 7일 이상 접속하지 않을 시 로그아웃 시킨다. 6. SNS 는 구글, 애플, 페이스북, 네이버가 존재한다. 7. SNS 에서 가져오는 정보는 이메일과 초기 세팅할 정보인 이름만 존재한다. 8. SNS 연결을 끊어도 로그인이 된 상태는 유지 되어야 한다. 처음에 난 SNS 연동을 도입한다는..

백엔드 동료들과 앞으로의 백엔드 아키텍처를 어떻게 가져가면 좋을지 이야기를 했다. 예전 글을 보니 예전에도 이런 얘기를 했었던 때가 있었다. 멋도 몰랐지만. 2020.01.08 - [개발/고민과 생각] - 기존 모놀로틱에서 MSA 로..? 먼저 지금 현 회사의 백엔드 아키텍처를 얘기하자면 아래 사진과 같다. 별로다. 그런데 내가 입사 때부터 이렇게 돼 있었고 의존성이 너무 강해서 떼어낼려면 너무 대공사였기에 엄두를 내지 못하고 있다. 실제 유저들에게 서비스하고 있는 P, M 서비스가 존재한다. 이 서비스들은 A 라는 도메인을 기반으로 하여 각기 다른 서비스를 제공하고 있다. 그러나 P 서비스에는 매 분마다 M DB 에 존재하는 A 도메인에 대한 데이터를 P DB 로 옮기는 스케줄러가 존재한다. 그래서 본..

보호되어 있는 글입니다.

예전에 막 개발을 시작했을 때 spring 에서 @Tramsactional 이라는 어노테이션을 단순 select 에서도 적용하는 것을 보고 궁금했었다. 이번에 Real Mysql 책을 보다가 비슷한? 내용이 나왔다. 트랜잭션 내에서 실행되는 SELECT 문장과 트랜잭션 없이 실행되는 SELECT 문장의 차이는 READ COMMITTED 격리 수준에서는 차이가 별로 없다. 그러나 REPEATABLE READ 격리 수준에서는 트랜잭션 동안에 다른 트랜잭션에서 아무리 특정 데이터를 변경하고 커밋하더라도 동일한 결과를 보게 된다. 그렇기 때문에 격리 수준에 따라서 동작이 달라진다. 위의 현상을 non-repeatable read 라고 한다. read committed 일 때는 특정 트랜잭션 내에서 A 데이터를 ..