ETC28 Read Consistency with Database Replicas by Shopify Shopify의 Read Consistency with Database Replicas에 대한 짧은 분석 read-heavy한 애플리케이션이 있을 때, DB의 쓰기(Write) 기능에 성능 저하를 막기 위해 DB replication을 구성하는 경우가 많다. 즉, 서버에서 쓰기 쿼리는 Primary DB에 보내되 읽기 쿼리는 Replica DB에 보내는 식으로 구성하여 쓰기 성능에 영향을 덜 주는 것이다. 위와 같은 환경에서 Shopify의 포스팅에서 얘기하는 문제는 Replica가 2대 이상으로 구성하였을 때 생기는데, 서버가 여러 번의 쿼리를 통해 조회한 데이터를 aggregation 하는 경우이다. 아래와 같이 2대의 Replica DB를 운용하는 경우를 예를 들어보자. - Replica 1 DB는.. 2022. 12. 9. [Bash] &&를 쓰는 이유 먼저 bash에서 &&는 일반적인 고수준 프로그래밍 언어에서 지원하는 AND 연산자와 동일한 역할을 한다. Bash Reference Manual - 3.2.4 Lists of Commands https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Lists AND 이기 때문에 - 앞서 실행된 커맨드의 결과가 성공(zero exit status)인 경우, 뒤의 커맨드를 실행시켜야지 AND 연산 결과를 알 수 있기 때문에 뒤의 커맨드를 실행한다. - 앞서 실행된 커맨드의 결과가 실패(non-zero exit status)인 경우, AND 연산 결과가 failure이기 때문에 뒤의 커맨드를 실행시키지 않고 연산이 종료된다. 즉, &&를 쓰면 앞의 .. 2022. 11. 28. [Refactoring] 여러 역할을 갖는 엔티티 리팩터링하기 레거시 시스템을 살펴보다보면 하나의 엔티티(테이블)에 서로 다른 역할의 데이터 필드(컬럼)가 모여있도록 모델링 된 경우가 있다. 초기에는 하나의 역할의 데이터만 있었지만, 서비스가 확장되면서 기존 시스템을 재활용하다보니 기존의 엔티티(테이블)에 다른 역할의 데이터 필드(컬럼)를 추가한 경우이다. 이번 포스팅에서는 여러 역할을 갖으면서 SRP를 위반하는 엔티티와 그 문제점을 알아보고 이를 어떻게 리팩터링하면 좋을지에 대한 방법을 설명하도록 하겠다. (예제 코드는 여기에서 살펴볼 수 있다) SRP를 위반하는 엔티티와 그 문제점 예를 들어 처음에는 물리적인 굿즈를 팔기 위한 상품을 담기 위한 상품 엔티티를 만들었다고 하자, class Product( id: ProductId, name: String, pric.. 2022. 11. 16. Types of Time-sequential ID generator 일단 시작에 앞서 auto increment ID를 피하는 이유로는 How to Do UUID as Primary Keys the Right Way의 Why You Should Avoid Auto-Incremented Integers를 참고하길 바란다. 그렇지만 DB의 auto increment ID를 사용하는건 이미 널리 쓰이고 있고 그다지 나쁜 선택이 아니다. 하지만 여러 측면을 고려하였을 때, DB의 auto increment ID를 사용하는 것은 아무래도 좋지않다는 판단을 한 경우라면 이제 ID를 어떻게 ID를 만들지가 중요해진다. UUID v4와 같이 random한 ID의 경우 ID 충돌에 있어 큰 문제는 없지만, random한 값이기에 DB의 Primary Key로 사용하기엔 무리가 있을 수 .. 2022. 10. 17. [채팅 시스템] 특정 키워드에 대해 시스템 메세지 보내기 채팅 서비스가 처음에는 단순히 유저 간에 메세지를 주고받기 위함이었어도, 서비스가 고도화 되다보면 꼭 채팅 도메인과는 관련되지 않아도 서비스와 관련하여 유저의 주의를 끌기 위해 몇가지 기능이 추가될 수 있다. 그 중 하나로는 채팅방에 특정 키워드가 발생했을 때 해당 채팅방에 시스템 메세지를 보내는 기능이 있다. 실제 사례를 예로 들자면 당근마켓의 채팅 시스템 메세지 기능이 있을 것이다. 이처럼 채팅 도메인과는 약간 동떨어졌지만 채팅 시스템과 통합되어야하는 기능에 대해 어떤 식으로 시스템을 설계할지에 대해 정리해본다. 먼저 채팅을 위한 웹소켓 서버의 경우 Scaling을 위해 Message Queue나 Redis Pub/Sub 등을 사용하여 다른 웹소켓 서버와 연결된 유저에게 메세지를 보낼 것이다. 위.. 2022. 9. 13. 입개발) 슬랙 알림 기능 개발 가끔 새로 개발한 기능을 유저가 사용하는지 궁금할 때가 있다. 또는 배치를 돌릴 때 배치 결과를 보고싶을 때도 있다. 하지만 업무 중에 주기적으로 어드민 사이트나 DB 데이터를 매번 볼 수 없으니 운영 편의상 특정 이벤트(유저가 특정 액션을 했다던가, 특정 설정을 변경했다던가) 후에 슬랙 채널로 알림을 보내곤 한다. 슬랙 알림 기능을 개발할 때 참고할 수 있는 몇 가지를 정리해본다. Incoming WebHooks Incoming WebHooks는 특정 채널에 슬랙 메세지를 보내기 가장 쉬운 방법이다. 쓰기도 쉽고 설정도 매우 단순하다. Apps에서 Incoming WebHooks를 검색하여 추가를 할 때 간단한 설정만 해주면 된다. 그리고 만들어진 WebHooks의 URL로 HTTP 요청을 보내면 된다.. 2022. 8. 20. 이전 1 2 3 4 5 다음
