hojak99 의 블로그

소프트웨어 아키턱처 101 이라는 책을 읽고 있던 중, 아키텍처 카타(atchitecural kata)라는 것이 나왔다. Ted Neward 라는 아키텍트가 초보 아키텍트가 도메인에 관한 설명을 보고 아키텍처 특성을 도출하는 연습을 할 수 있도록 아키텍처 카타라는 것을 고안했다고 한다. 나는 설계하는 경험은 쉽게 얻을 수 없다고 생각한다. 그렇기에 막상 설계를 해야하는 상황이 닥치면 실수를 꼭 한 가지 이상은 하게 될 가능성이 높다. 나도 물론 그랬다. 코드에 대한 예제가 많는 많다. 예를 들어 클린 코드 같은 여러 도서들에선 이런 코드가 낫다고 말하며 코드를 많이 보여준다. 그러나 설계는 그 예가 별로 없다. 있어봤자 유투브에서 외국인이 트위터를 설계하는 동영상 정도? 그렇기에 연습을 꼭 해야한다고 생..

이 글은 데이터 중심 애플리케이션 설계 라는 책의 내용을 기반으로 제가 이해한 것들을 작성했습니다. 데이터 중심 애플리케이션 설계 라는 책에서는 소프트웨어 시스템이 신뢰성, 확장성, 유지보수성 이라는 세 가지 관심사에 중점을 둔다고 한다. 신뢰성: 시스템은 지속적으로 올바르게 동작해야 한다. 확장성: 시스템의 데이터 양, 트래픽 양, 복잡도가 증가하면서 이를 처리할 수 있는 방법이 있어야 한다. 유지보수성: 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있게 해야 한다. 신뢰성 - 사용자가 기대한 기능 수행한다. - 사용자가 범한 실수, 예상치 못한 사용법을 허용할 수 있다. - 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족한다. - 허가되지 않은 접근과 오남용을 방지한다. 즉..

현재 운영 중인 서비스에서 특정 이벤트로 인하여 약 2000명 정도의 사용자가 동시에 특정 기능을 사용할 예정이었다. 아직 사용자가 많지 않아 APM 은 따로 이용하지 않았고 AWS cloud watch 로 버그로그만 슬랙에 쏘도록 해놓은 상태였다. 그러나 사용자가 특정 시간에 몰릴 것이며 추후에도 계속 사용자가 서비스를 이용할 것이기에 현재 애플리케이션 서버의 성능과 실시간 트랜잭션 모니터링, 분석을 할 수 있도록 APM 을 달기로 결정하였다. APM 은 여러 서비스들이 있는데 그 중 비용, 제공 기능 등을 조사하여 현재 우리 팀에 맞는 서비스를 선정하였다. 어떤 APM 을 사용하게 되었는지는 따로 작성하지 않겠다. 우선 현재 AWS Elastic Beanstalk(EB) 을 이용하여 서비스를 운영하고..

이제 "판매 상품" 들을 장바구니에 담아보자. 쿠팡에서는 크게 "로켓와우" 라는 정기 구독 상품과 판매자들이 등록한 일반 결제 상품이 존재하는 것으로 보인다. 네이버 스마트 스토어에도 판매자들이 등록하는 정기 구독 상품과 일반 결제 상품이 존재한다. 이렇게 각 서비스들은 "정기 구독 상품" 과 "일반 결제 상품" 이 존재할 수 있다. 그러나 일반적인 서비스들에서는 장바구니에 "정기 구독 상품" 과 "일반 결제 상품" 을 함께 장바구니에 담거나 하지 못하는 것으로 보인다. 그래서 다른 서비스들과 다르게 하나의 장바구니에 "정기 구독 상품" 과 "일반 결제 상품" 을 같이 담아 한 번에 결제 할 수 있도록 하는 기능을 개발하게 된 이야기를 작성해보도록 하겠다. 결과론적으로 보면 이 결정으로 인해서 마이페이지..

''왜" 라는 질문을 계속 던지며 이야기를 해보자. 데이터를 가져올 때 MySQL 과 Redis 의 속도는 뭐가 더 빠를까? 1. 디스크, 메모리 관점 2. redis 는 딕셔너리 기반인데 key 로 찾을 때 어떤 식으로 데이터를 찾는지 3. 메모리 꽉차면 스왑 영역 (디스크를 메모리 대신 이용하는 부분) 4. 메모리 파편화 대해서 5. mysql pk 로 접근하면 왜빠른가? clustered index, nonclustered index

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

상황을 설명하자면 다음과 같다. 입사 후에 백엔드, 프론트 개발을 혼자 담당하고 있는 상황에서 비즈니스 일정으로 인해 기존에 누군가가 세팅해 놓은 인프라 환경을 많이 개선하지 못했었다. 해봤자 개발서버 도입, 서버 이중화, 테이블 정규화를 하여 마이그레이션 한 정도이다. 그러나 이번에 프론트, 백엔드 개발자가 채용이 되면서 나에게 몰려있던 일들이 조금 분산되기 시작했다. 그래서 이제 인프라 환경을 개선할 때가 왔다고 느꼈고 그 첫 시작은 SSL 인증서 교체로 시작되었다. 우선 담당하는 서비스는 AWS 에서 제공하는 S3, EC2, RDS, EB, CloudFront 등 매우 많이 이용하고 있다. 그런 상태에서 SSL 인증서의 만료기한이 얼마 남지 않은 것을 파악했고 SSL 인증서가 현재는 sslcert ..

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

주말에 갑자기 서버가 죽었었다. 노트북을 가지고 있지 않았어서 우선 급한대로 서버를 재기동 시켰다. AWS CloudWatch 를 확인해보니 out of memory 로 인해서 그런듯 보였다. 우선 기존에 JVM option 으로 -XX:+HeapDumpOnOutOfMemoryError 를 추가해 놓았기 때문에 힙덤프를 떠 놓았겠지 싶었다. 그러나 베스천 서버를 통해 ec2 서버에 접속해보니 힙덤프 로그는 보이지 않았다. 한 가지 추가하지 않은 것이 있다면 -XX:HeapDumpPath 해당 옵션을 추가하지 않았다. 옵션이 없어도 기본적으로 JVM 시작 디렉토리에 저장이 된다고는 하지만 난 ec2 내에서 찾지 못했다(출처: 권남의 블로그). 어쨌든 서버가 죽었으니 원인을 파악해야 했다. ec2 장비에 접..

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