최근하고있는개발은영

0. 들어가기 앞서주로 관계형 데이터베이스를 다루고 있지만, 레거시 프로젝트를 담당하게 되면서 MongoDB를 자주 다루게 되었습니다. 내부적으로 레거시가 많이 있어 이를 보완하고 어떻게 전환해야 하는지에 대해 많은 학습들이 필요하다고 생각되어 기본이 되는 MongoDB의 기능이나 내부적인 동작 원리에 대해서 이해하고자 글을 작성하게 되었습니다. 1. MongoDB 특징 및 관련 개념1.1 MongoDB의 특징MongoDB는 관계형 DB가 아닌 NoSQL DB입니다. 관계형 데이터베이스는 데이터를 테이블의 행과 열로 표현하고 테이블 간의 관계를 나타내지만 MongoDB는 하나의 데이터를 BSON 문서 형태로 저장합니다. RDB인 경우에는 특정 테이블 기본키를 외래키로 사용하고 있는 경우에 존재하지 않는..

0. 들어가기 앞서트랜잭션 이벤트 리스너를 활용하고 있지만 정확히 그 원리에 대해서는 이해하지 못하고 있었던 거 같습니다. 또한 트랜잭션 이벤트 리스너가 트랜잭션과 함께 만났을 때 어떻게 동작하는지도 지레짐작으로 파악을 했었는데 제가 생각했던 활용 예시를 바탕으로 왜 그렇게 동작하게 되었는지 알아보고자 합니다. 1. 첫번째 케이스(TransactionEventListener, Transactional 사용) 1.1 예제 코드Spring boot 3.x 버전과 JPA 그리고 MySQL을 사용하는 환경에서 아래와 같은 코드를 작성했습니다. 이전에 핵심 비즈니스 로직에 대해 트랜잭션 처리가 끝나면 알림 데이터를 저장하는 코드입니다. 아래 코드는 어플리케이션 서버를 실행했을 때 예외를 터트리는 코드입니다. 그렇..

0. 목적결제 시스템을 도입하면서 결제사에서 들어오는 웹훅을 어떻게 활용할지 많은 고민을 했습니다. 결과적으로 웹훅을 어떻게 사용해야 한다고 생각했는지 그리고 결제 시스템을 구축하면서 어떤 어려움을 겪었는지 경험을 남겨보고자 글을 작성하게 되었습니다. 그래서 이 글에서 얻을 수 있는 점은 다음과 같습니다.결제 기능을 개발할 때 어떤 점을 조심해야 하는지?결제 API 개발 예시웹훅을 언제 사용해야 하고 웹훅을 보조할 수 있는 수단이 왜 필요한지? 1. 결제 로직 작성1.1 결제 상태 정의하기결제 데이터의 상태는 결제 대기, 결제 성공, 결제 실패 3가지로 나누었습니다. 결제 대기 상태는 왜 있는가 했을 때 서버에서 결제 데이터를 DB에 저장할 때 결제 API를 호출하지 않았기 때문에 결제 성공 여부를 알..

인프런 CTO로 재직 중이신 향로님의 회고를 보고 간단하게 월별 회고를 해보면 좋겠다는 생각을 했다. 내가 분명 바쁜 시간도 있었지만 정말로 내가 알차게 보냈는지도 확인이 필요하지 않나 생각이 들었기 때문이다. 1월근속년수 1년을 채움이때 1년간 일을 하면서 내가 뭘 했는지 돌아보고 이력서에 녹여보려고 했다. 많은 일들을 해왔지만 조금 더 주도적으로 일을 해야 할 필요성을 느꼈다. 팀원들에게 좋은 평가를 받았지만, 스스로에게 야박했고 더 잘하고 싶다는 욕심이 생겼다. 물론 1년 동안 프로젝트를 더 많이 이해해야 큰 그림을 그리고 더 좋은 방법을 생각할 수 있었다고 믿었기에 아쉬움이 있거나 하진 않았다.2월첫 커피챗글또 활동을 하면서 처음으로 커피챗을 해보았는데, 이때 인턴으로 재직 중인 분과 취준 중이신..

0. 들어가기 앞서0.1 문제점EC2 인스턴스를 사용해서 ECS 환경을 구축해 API 서버 운영다만 실제 컨테이너가 사용하고 있는 메모리양과 ECS Agent가 사용하는 메모리를 합치면 가용 메모리를 아슬아슬하게 남김그래서 간헐적으로 서버가 내려가는 경우가 발생했다가 ECS가 최대한 고가용성을 보장하기 위해 컨테이너를 다시 띄우는 문제가 발생0.2 다루는 내용컨테이너가 죽어버리는 과정에서 OOM Killler의 개입을 판단한 로그OOM Killer의 역할 및 OOM Killer 회피 방법 1. 원인 파악1.1 구성 환경 EC2 t3a 인스턴스, Linux 2, ECS Agent 1.100.0Spring Boot 3.X, Java 17아래와 같이 task-definition 구성// 다른 설정 생략{ "..

0. 들어가기 전현재 SQS를 주로 사용하고 있지만 Kafka가 어떻게 동작하고 있는지 궁금하고, 어느정도 개념을 잡아두면 나중에 기술 비교할 때 도움이 될 거 같다는 생각이 들었습니다. 그리하여 Kafka의 전반적인 용어와 개념들을 익혀보고, SQS와 조금 비교해보면서 글을 정리하고자 합니다. 1. Kafka 기초1.1 Kafka 정의고성능 데이터 파이프라인, 스트리밍 분석 등의 애플리케이션에 사용되는 오픈 소스 분산 이벤트 스트리밍 플랫폼요약하면 대규모 데이터를 처리할 수 있는 메시지 큐1.2 Kafka 구성 용어 Kafka를 이해하기 위해서 아래의 용어들을 알아두는 것이 좋습니다.노드 : Kafka가 설치된 서버를 의미클러스터 : 여러대의 서버가 연결되어 하나의 시스템처럼 동작하는 서버의 집합. 즉..

0. 서론결제 시스템을 개발하면서 결제 API의 멱등성을 어떻게 보장할 수 있을까에 대해 고민해 봤습니다. 왜냐하면 결제 버튼을 두 번 클릭(일명 따닥)하거나, PG사를 통해 결제를 완료했음에도 서버 문제로 사용자가 문제를 해결할 수 없는 경우가 발생할 수 있기 때문입니다. 저는 그중 더블 클릭과 같이 여러 번 API를 호출하는 경우 멱등성을 보장하기 위한 방법을 고민하고 이를 해결하고자 합니다. 1. 멱등성 보장을 안한 경우 문제점멱등성이란?멱등성이란 동일한 연산을 여러 번 수행해도 결과가 달라지지 않는 성질을 말합니다. 멱등성은 시스템의 오류, 유저 실수로 인한 중복 처리를 방지하고, 데이터의 일관성을 유지할 수 있습니다. 멱등성은 API 설계, 클라우드 서비스, 메시지 큐 시스템에 적용할 수 있습니..

1. 문제 이해 및 설계 범위 확정1.1 기능 요구사항5000개 호텔에 100만 개 객실을 갖춘 웹사이트예약시 결제하는 서비스10% 초과 예약 가능객실 가격은 유동적 서비스 주요 기능호텔 정보 페이지 표시객실 정보 페이지 표시객실 예약 지원초과 예약 지원1.2 비기능 요구사항높은 수준의 동시성 : 성수기이거나 이벤트를 할때 특정 객실에 대해 고객이 많이 몰릴 수 있기 때문적절한 지연시간 : 예약을 할때 너무 오래만 안 기다릴 정도로 유지1.3 규모 추정예약 건수 추정총 5000개 호텔, 100만개 객실이 있다고 가정평균적으로 객실의 70%가 사용중이고, 평균 투숙 기간을 3일이라고 가정했을때일일 예약 건수는 1백만 * 0.7 / 3 = 233,333 (약 240,000)초당 예약 건수는 3에 근접해 T..

1. 문제 이해 및 설계 범위 확정1.1 개략적 요구사항 및 가정아래와 같은 요구사항과 설계 범위를 정했다고 가정어떤 정보를 수집해야하는가? 시스템 운영 지표(CPU 부하, 메모리 사용률, 디스크 사용량, RPS 등등)시스템의 규모는 어떤가? MAU 1억, 서버 풀 1000개, 풀당 서버 수 100개지표 데이터 보존 기간은? 데이터 보관 기간 1년오래 수집한 데이터는 어떻게 저장되어야 하는가? 7일, 30일 ,1년 순으로 해상도를 낮추어 보관1.2 비기능 요구사항규모 확장성 : 시스템은 늘어나는 지표 수와 경보의 양에 맞게 확장될 수 있어야함낮은 레이턴시 : 대시보드와 경보를 신속하게 처리하기 위해 쿼리에 대한 낮은 레이턴시를 보장해야함안정성 : 높은 안정성을 제공해 중요 경보를 놓치지 않도록 하기 위해..

0. 서론Prometheus를 사용하고 있지만 수많은 기능들이 있고, 그 기능들이 어떤 구조와 의미를 가지는 정확히 알지 못하고 있습니다. 그래서 이를 더 잘 활용하고 다른 툴들과 비교하기 위해선 지금 사용하고 있는 기술에 대해 더 잘 이해해기 위해 글을 작성했습니다. 1. Prometheus1.1 Prometheus란SoundCloud 사에서 처음 개발된 오픈소스 System Monitoring 및 Alerting toolkit현재는 독립된 오픈소스 프로젝트를 유지중Prometheus는 메트릭을 시계열 데이터로 수집하고 저장메트릭 정보는 timestamp와 함께 저장되며, Label이라고 하는 키-값 쌍도 함께 저장1.2 Prometheus에서 제공하는 기능들메트릭 이름과 키/값 쌍으로 식별되는 시계..