hojak99 의 블로그

현재 운영 중인 서비스에서 특정 이벤트로 인하여 약 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씨는 단일 상품으로 [티셔츠] 와 [바지] 를 따로 팔고 있었다. 그러나 두 개를 같이..

- mybatis, jpa 장단점 - mybatis -> jpa 전환 이유 - 아키텍처 관련 내용 - 트래픽이 많아졌을 때 애플리케이션, 인프라 관점에서 어떻게 개선할건지 설명 - jwt 도입 이유 - jwt 메세지 내용까지 암호화 처리 했는지 - 구독 갱신 결제 중 환불 났을 때 - 결제 기능에 트래픽 많아졌을 때 어떻게 할건지 - 레디스 죽으면 어떻게 할건지 - 샤딩은 어떻게 실시간으로 할건지. 유저에게 영향안가게 - 서블릿이란 - SOLID - 스프링 장단점 - 이직 사유!! 이거 제일 중요 최대한 발전 하기 위해 이직한걸로 - 프로젝트 아키텍처 어떻게 잡았는지 - jwt vs 세션 - redis, mysql 셀렉트 속도 뭐가 빠른지 내부적으로 설명

상황을 설명하자면 다음과 같다. 입사 후에 백엔드, 프론트 개발을 혼자 담당하고 있는 상황에서 비즈니스 일정으로 인해 기존에 누군가가 세팅해 놓은 인프라 환경을 많이 개선하지 못했었다. 해봤자 개발서버 도입, 서버 이중화, 테이블 정규화를 하여 마이그레이션 한 정도이다. 그러나 이번에 프론트, 백엔드 개발자가 채용이 되면서 나에게 몰려있던 일들이 조금 분산되기 시작했다. 그래서 이제 인프라 환경을 개선할 때가 왔다고 느꼈고 그 첫 시작은 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 장비에 접..

https://ichi.pro/ko/naega-gajang-joh-ahaneun-2020-nyeon-sopeuteuweeo-akitegcheo-hagseub-gwajeong-best-of-lot-6405117203177

보호되어 있는 글입니다.