전체 글

개요사용자가, 상품을 구매를 하고 그에 합당한 포인트를 적립을 받아야 한다. 물품 구매 요청에는 → 결제, 제고차감, 포인트 적립로직이 있다. 포인트 적립 로직은 메시지큐에 담아 비동기적으로 실행한다.또한 포인트 적립의 경우는 회원이 해당 포인트를 바로 사용하는 경우를 고려하기보다는 안정적으로 적립이 되도록 보장만 해주면 된다 생각했기에 비동기처리로 구현을 했다. 하지만, Spring Boot Server와 Kafka는 다른 시스템이기 때문에 Transaction이 원자적일 수 없다. 가령, 고객의 물품이 성공적으로 구매가 되었으나 네트워크 오류로 포인트 적립 메시지 발행이 안되었어도. 롤백이 되지 않는다. 물론 이런 상황이 실제로 일어나진 않았다. 만들면서 메시지큐를 도입하면 이런 상황이 있지 않을까?..

개요Kafka를 처음 도입했을 때, 파티션의 개수, 중개인의 개수, 컨슈머의 개수의 타협에 있어 고민했던 기록과틀린 주관일 수 있으나, 나름의 기준을 새운 과정을 정리함. 문제가 되는 경우Broker Pod 가 3대. Partition이 2개, 복제본이 2이라는 토픽을 만든다면kafka-topics.sh --create \ --topic A \ --bootstrap-server kafka-broker-0.kafka-broker-headless.kafka.svc.cluster.local:9092 \ --partitions 1 --replication-factor 2 어플리케이선이 토픽을 소비할 때 두 개의 프로커에 있는 p0, p1 리더 파티션에서 메시지를 소비할 것이다. 하지만 첫번째 Broker가..

https://kingmusung.tistory.com/114 DB 커넥션 풀과 파드 수의 상관관계 실험(회고)개요프로젝트 당시 EKS환경에서 포인트 적립 인프라를 구축했을 때.목표했던 대규모 트래픽 처리에 못 미치는 1,300 TPS라는 아쉬운 수치를 기록했다. 당시 일정상 해결을 하지 못했기에, 해당 상kingmusung.tistory.com https://kingmusung.tistory.com/115 ProxySQL 멀티플렉싱을 통한 부하 환경 안정화 및 성능 최적화(회고 2탄)https://kingmusung.tistory.com/114 DB 커넥션 풀과 파드 수의 상관관계 실험(회고)개요프로젝트 당시 EKS환경에서 포인트 적립 인프라를 구축했을 때.목표했던 대규모 트래픽 처리에 못 미치는 1..

https://kingmusung.tistory.com/114 DB 커넥션 풀과 파드 수의 상관관계 실험(회고)개요프로젝트 당시 EKS환경에서 포인트 적립 인프라를 구축했을 때.목표했던 대규모 트래픽 처리에 못 미치는 1,300 TPS라는 아쉬운 수치를 기록했다. 당시 일정상 해결을 하지 못했기에, 해당 상kingmusung.tistory.com 이전 실험에서 커넥션 풀과 파드의 수의 상관관계 회고 실험에서 커넥션 10개를 할당한 파드 5개가 가장 높은 처리량을 보여주었다.궁극적으로 해보고 싶은 점은부하가 쏟아졌을 때 실패율을 줄이면서 처리량을 유지해보고 싶었다.총처리량은 물리적 한계에 봉착돼 있는 점을 인지했으니 안정성을 어떻게 하면 올릴 수 있을까에 중점을 둬보았다.어떤 병목일까현제 실험은 Upda..

개요프로젝트 당시 EKS환경에서 포인트 적립 인프라를 구축했을 때.목표했던 대규모 트래픽 처리에 못 미치는 1,300 TPS라는 아쉬운 수치를 기록했다. 당시 일정상 해결을 하지 못했기에, 해당 상황을 분석해 보고자 로컬 쿠버네티스 환경에서 실험을 재현해 보았다.가설 설정당시 병목의 원인을 파드의 무분별한 스케일 아웃으로 인한 DB Row Lock 경합과 커넥션 오버헤드로 가설을 세웠다.이를 증명하기 위해 k6를 활용해 부하 테스트를 진행하며, 커넥션 풀과 파드 수의 상관관계를 단계별로 검증 커넥션풀과 처리량의 상관관계 확인커넥션풀을 단순히 늘린다고 처리량이 늘어날까? 단일 파드 커넥션 10개현제 타임아웃을 3초로 잡았으며, 실패한 것들은 타임아웃에 의해 1,76% 실패율을 보인다. RPS : 356TP..

후속조치AWS ASG기반으로 실행되는 Node Group의 한계를 돌파해 보기 위해Karpenter를 사용을 했으나, Karpenter의 도입으로 인한 사이드 이 팩 드는 고려를 안 해보았기 때문에.아쉬운 마음에 적어본다 AWS ASG대신 Karpenter를 도입한 이유정확한 상황은, 기본 적인 구축 후 스케일링 도구를 도입하려 했다.AWS EKS의 기본 NodeGroup을 가용영역 두 개에 프라이빗 서브넷에 걸치게 구축했다. Jenkins, ArgoCD등 이것저것 올라오다 보니 파드가 Pending인 상황.문제는 ENI 고갈로 인해 파드가 할당받을 아이피가 없음. NodeGroup에 수동으로 노드를 늘렸지만 여전히 eni고갈, 두 개의 서브넷의 아이피를 계산해 보았을 때 부족 할 수가 없었다. 이게 웬..

MySQL Source Replica (Master Slave)개요Debezium 도입 전 원리 공부 중, MySQL의 bin_log에 있는 로그를 순차적으로 읽어 CDC를 해주는 원리이다.하지만 Mysql의 Source Replica패턴 또한 bin_log에 있는 로그를 기반으로 데이터를 동기화한다.유사한 방식에 있어 간단하게 mysql의 복제 방식이 어떻게 이루어지는지 살펴봄과 동시에 Docker 환경에서 여러 개의 컨테이너가 어떤 식으로 네트워크 통신을 하면서 bin_log를 읽어 오는지 탐구를 해보고 싶었다.마지막으로 Master Slave를 수동으로 구현함에 있어 발생하는 단점과 그것을 극복하는 과정에 대한 트레이드오프에 대해 생각을 해보았다. Source Replica우선 Master Slav..

1. Jenkins와 WebHook연결 과정Jenkins 프로젝트를 만들지 않으면 ping에 실패 웹훅을 먼저 만들게 되면 GitHub에서 Ping이 안 가서 오열하는 나 자신을 볼 수 있다. Jenkins 프로젝트를 먼저 만들자!! 1. 파이프 라인을 각 환경별로 만든다 Pipeline을 골라준다 빌드 트리거로 Github WebHook을 사용한다. 레포가 여러 개 있다면, 트리거를 받고자 하는 레포의 주소를 잘 적어준다. Branch Specifier 부분은, WeebHook이 올 때 내가 잡아야 할 브렌치에 대한 WeebHook을 선택하게 하는 옵션이다. 브렌치별로 빌드 파이프라인을 다르게 할 거라면 브렌치 이름을 잘 적어주어야 한다. ScriptPath는 해당 브렌치로부터 온 신호를 받아 어..