hojak99 의 블로그

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

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

Real MySQL 책에 복제(Replication)에 관한 내용을 읽고 있었던 중 이런 내용이 있었다. 마스터 서버에서 수많은 동시 사용자가 실행한 데이터 변경 쿼리 문장이 슬레이브 서버에서는 하나의 스레드로 모두 처리돼야 한다(이 부분은 지금의 구조상 피해 갈 방법이 없다). 즉, 마스터 서버에서는 바이너리 로그를 기록하는데 이때 "Binlog dump" 라는 스레드가 이 일을 전담하며 하나의 마스터 서버에 N개의 슬레이브가 연결돼 있다면 "Binlog dump" thread 가 10개가 생긴다. 그리고 슬레이브 서버에서는 relay log 가 존재하는데, 이 relay log 는 마스터의 변경내역이 기록된 로그 파일이며 슬레이브 서버의 I/O thread 가 마스터 서버에 접속해 변경 내역을 해당 ..

Real MySQL 이라는 책을 읽다가 104 페이지에서 다음과 같이 이야기하는 부분이 있었다. MySQL 서버는 프로세스 기반이 아니라 스레드 기반으로 작동하며, 크게 포그라운드 스레드와 백그라운드 스레드로 구분할 수 있다. 그렇다면 왜 MySQL 서버는 프로세스 기반이 아니라 스레드 기반으로 동작하게 했을까? 라는 생각이 들었다. 우선 내 생각은 다음과 같다. 먼저 운영체제를 공부하다가 나오는 프로세스의 개념을 먼저 이해해야 한다. 간단하게 얘기하면 여러 N개의 스레드와 기타 등등으로 굴러가는 하나의 프로그램이라고 보면 된다. 크롬에서의 각각의 탭들을 예로 들 수 있다. 크롬 브라우저의 각 탭들은 하나의 프로세스들로 이루어져 있다. 그래서 탭이 10개라면 10개의 프로세스가 존재한다는 것이다. 이러한..

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

'직접 회원가입 하고 로그인하기' 와 '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 로 옮기는 스케줄러가 존재한다. 그래서 본..

보호되어 있는 글입니다.

갑자기 생각이 들었다. 이렇게 대충 알고 있어서야 내가 과연 네카라 개발자가 될 수 있을까 라고. 어쨌든 내 뇌를 깨어나게 해준 HTTP 완벽 가이드 와 후배 yom-hardy 에게 감사를 표한다. Https 란 우선 Https 는 무엇에 대한 약자인가. wikipedia 에서는 다음과 같이 표현하고 있다. HyperText Transfer Protocol over Secure Socket Layer HTTP over TLS HTTP over SSL HTTP Secure https 를 사용하면 모든 http 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다. 간단하게 https 에 대해서 알고 싶다면 위의 내용만 알면 된다. https 는 http 와 다르게 SSL, TLS 를 이용하여 구현된다...

지금 2019년 12월부터 이 글을 쓰고 있는 지금까지도 야근과 코드, DB 리펙토링을 하느라 책을 잘 보지 못했다. 그래서 책을 읽으려 노력하고 있으며 [클린 아키텍처] 를 읽고 든 생각을 정리해보려고 한다. 물론 책마다 다를 수 있기 때문에 다른 책도 읽어보긴 해야 할 것 같다. SOLID: 변경에 유연하고, 유지보수를 쉽게 만들고자 할 때 시스템에 적용 가능한 원칙 먼저 해당 책에서는 SOLID 에 대해서 얘기 하는 목차가 있다. SRP(단일 책임 원칙: Single Responsibility Principle) 먼저 SRP 부터 소개하는데 내가 평소에 생각하고 있던 것과 다르게 얘기를 한다. 내가 생각하던 SRP 는 "하나의 기능, 메소드는 한 가지의 책임만을 가져야 한다." 였고 책에서는 이게 ..