- 전체보기(77)
- redis(8)
- kafka(4)
- Thread Pool(3)
- 운영체제(3)
- 시스템 프로그래밍(3)
- JUnit5(3)
- 오브젝트(3)
- Java(2)
- lua scripting(2)
- 프로그래밍언어론(2)
- DBCP(2)
- Cache(2)
- JPA(2)
- Perfomance Test(2)
- service(2)
- 데이터베이스(2)
- JWT(2)
- aws(2)
- 네트워크(2)
- 단위 테스트(1)
- 자료구조(1)
- scalability testing(1)
- Cache Stampede(1)
- CopyOnWrite(1)
- rds(1)
- 프로그래밍패러다임(1)
- Hot key(1)
- Mockito(1)
- REST(1)
- Issue Tracking(1)
- 비지니스 로직(1)
- 성능 테스트(1)
- junit(1)
- oAuth(1)
- Domain Model(1)
- PID1(1)
- jacoco(1)
- code deploy(1)
- 연속된 빠른 중복 요청(1)
- 배치(1)
- cluster(1)
- 알고리즘(1)
- MVC(1)
- Idempotent(1)
- bean(1)
- GCC(1)
- micrometer(1)
- sse(1)
- replication(1)
- transaction(1)
- tcp(1)
- 프로그래밍언어(1)
- socket(1)
- exactly-once(1)
- OSI 7(1)
- redis pipelining(1)
- inheritance(1)
- n+1(1)
- CI/CD(1)
- 인터럽트(1)
- OAuth2.0(1)
- test code(1)
- UDP(1)
- Nginx(1)
- docker(1)
- RedBlackTree(1)
- github action(1)
- test coverage(1)
- 트랜잭션(1)
- aop(1)
- 벌크수정(1)
- 아키텍처(1)
- 인터페이스(1)
- 추상클래스(1)
- rdb(1)
- Pubsub(1)
- JIRA(1)
- 시스템 호출(1)
- prometheus(1)
- 전략패턴(1)
- sentinel(1)
- min-insync-replicas(1)
- kafka transaction(1)
- 가상함수 테이블(1)
- 테스트 커버리지(1)
- stress test(1)
- repository(1)
- DBMS Isolation(1)
- JVM(1)
- fork(1)
- load testing(1)
- Optimistic Lock(1)
- virtual function(1)
- aof(1)
- HashMap(1)
- C(1)
- 데이터베이스 예외(1)
- 정렬(1)
- 가상함수(1)
- 프로젝트(1)
- inception(1)
- nosql(1)
- GenerationType AUTO(1)
- 객체지향(1)
- 상속(1)
- 책임주도설계(1)
- Grafana(1)
- metaspace(1)
- 데이터베이스 격리수준(1)
- IPC(1)
- ehcache(1)
- 공룡책(1)
- redis transaction(1)
- Probabilistic Early Recomputation(1)
- Spring(1)
- Controller(1)
- permgen(1)
- test(1)
- I/O Multiplexing(1)
- Real MySQL(1)
- Thread Dump(1)
- actuator(1)
- Provisioned IOPS(1)
- High Availability(1)
- DB connection(1)
- unit test(1)
- sql(1)
- sticky partitioner(1)
[Real Mysql8.0] 4. 아키텍처
책 내용을 그대로 적기 보다는 제가 이해한대로 주요한 내용 위주로 재구성하였습니다. 원본 내용을 원하시면 책을 꼭 읽어보세요!쿼리를 입력했을 때 어떤식으로 동작할지 해당 동작 방식이 어떤 성능을 가질지 이해하기 위해서는 Mysql 아키텍처에 대해서 꼭 이해해야합니다.쿼
Hot key Cache Stampede와 Probabilistic Early Recomputation 적용
0. 작성 배경 이전 포스트에서 읽기 부하를 분산시키기 위해 Redis Cache를 활용하였습니다. 이때, TTL을 5초로 두게 되었는데 캐싱과 관련된 내용들에 대해서 더 학습하게 되면서 Hot key에서 발생할 수 있는 여러 문제점들에 대해서 알게 되었습니다. Hot
Redis Pipelining - round-trip time (RTT), 네트워크 요청횟수 감소
round-trip time (RTT)이란 클라이언트가 서버로 요청하고 응답을 받기까지 걸리는 시간을 의미합니다.Redis Server와 서버와 통신할때에도 당연히 RTT를 가지게 될텐데 이를 줄일 수 있는 방법들에 대해서 알아보려고 합니다.Redis Pipelinin
Redis - atomic하게 실행하여 동시성 문제를 방지하는법(Transaction, Lua-Scripting)
Redis를 사용하면서 동시성 문제가 발생할 수 있음을 알게 되었고 왜 Single Thread임에도 동시성 문제가 발생할 수 있는지, 해당 문제를 어떻게 해결할 수 있는지 등을 정리해보려고 합니다.Redis는 Single Thread입니다. Single Thread이
Kafka와 Exactly Once
분산 시스템에서 Event Queue르 사용할 때 Exactly Once를 만족시켜야 하는 요구사항이 발생했습니다. 이를 나름대로 잘 처리했다고 생각했지만 추가적인 처리가 더 필요하다는 것을 알게 되어 정리하게 되었습니다.결과적으로 알게 된 내용을 정리하면 kafka자
PermGen(JAVA7) VS MetaSpace(JAVA8)
JAVA7까지 사용된 메모리 개념으로 주로 다음 내용이 저장된다.Class, static 정보등의 정적 정보String Constant Pool Heap 내부에 위치한다.\-XX:PermSize=N --> PermGen Default Size 설정\-XX:Ma
DBCP Dead Lock Thread Dump로 확인.
시리즈 이전 포스트에서 1\. GenerationType.AUTO2\. Mysql3\. Thread pool size > DBCP size조건에서 발생하는 DBCP데드락을 분석하고 해결하였다.DBCP 데드락임을 알아챈 근거는 다음과 같다.JMeter로 데이터를 세팅하기
DB 병목 분산 캐시(Redis) 해결 기록
1. 문제 상황 및 원인 서버 튜닝이후 자원들을 적절하게 사용하게 되어 4배가량 TPS를 올릴 수 있었지만 MYSQL에 병목이 발생하였음. 2. 해결 방법 캐시를 통해 조회 부하를 분산하여 해결하기로 결정하였음. 이 과정에서 캐시 전략및 트레이드오프를 고려하여 적절
캐시 정의 및 전략 별 장단점 정리.
캐쉬란 데이터 요청 주체와 메모리 저장공간 사이에 위치하면서 메모리 저장공간에 대한 조회 요청을 앞에서 먼저 대신 처리해주는 저장장치이다.데이터 요청자는 먼저 cache에서 원하는 데이터가 존재하는지 찾아보고 있는 경우 cache의 데이터를 가져가고 없는 경우 원본 데
Scalability Test - Thread Pool, DBCP 적정 설정값 찾기.
0. 이전 포스트 이전 포스트 이전 포스트에서 테스트 시나리오, 테스트 장애지점, 테스트 병목원인에 대해서 분석하여습니다. 이번 포스트에서는 해당 병목을 해결하기 위해서 Thread pool, DBCP적정 값을 설정해보려고 합니다. 1. Thread pool 1-1
DBCP Deadlock 트러블 슈팅과 GenerationType.AUTO(Thread Dump)
Tomcat Thread Pool max size, DBCP maximumPoolSize를 조정하여 JMeter를 통해 테스트를 해보던 중 다음과 같은 예외가 발생하며 요청이 정상적으로 처리되지 못하는 문제가 발생했다.해당 사항과 같은 문제를 찾아보면서 우아한 형제들의
I/O Multiplexing Custom 정적 서버 구현 성능 테스트(Nginx)
42Seoul에서 진행하는 Webserv라는 과제이며 Nginx와 같은 I/O Multiplexing 정적 서버를 c++로 구현하는 프로젝트 입니다.아래 링크를 들어가시면 자세한 내용을 확인하실 수 있습니다.https://github.com/WebservKim
Perfomance Test - 백엔드 아키텍처 병목 확인.
Load TestingLoad Testing은 부하가 임계치(Threshold Value)에 도달할 때까지 시스템의 부하를 지속적으로 증가시키면서 시스템을 확인하는, Performance Testing의 한 유형입니다. 여기서 부하를 증가시킨다는 것은, 동시단말사용자(
AWS Auto Scaling Group EC2 WAS 대상Actuator Prometheus Grafana Micrometer 모니터링 적용
AWS로 Spring Boot Web Application Server를 배포하고 이를 운영하던 중 해당 WAS가 원인 모르게 종료되거나 하는 일이 종종 발생했습니다. Auto Scaling Group을 적용 했었기에 자동적으로 복구 되었지만 어떤 원인으로 해당 문제가
JPA N+1 문제와 해결법 총정리
JPA로 개발 과정에서 N+1문제를 만나면서 해맸던 부분들과 실제 프로덕션에서 이를 제대로 처리하지 못하면 성능적인 저하뿐만 아니라 장애로 이어질 수 있다는 부분을 깨닫고 정리 해보고자 합니다.N+1 문제는 ORM 기술에서 특정 객체를 대상으로 수행한 쿼리가 해당 객체
트랜잭션 동시성 문제 해결- Optimistic Lock과 AOP활용
0. 배경 서로 다른 API요청이 거의 동시에 들어올 경우 동시성 문제가 발생할 수 있는 기능이 있어서 이를 해결하기 위한 부분을 고민하게 되었습니다. 0-1. 기능 설명 해당 프로젝트는 사람들을 모집하는 기능을 제공하는 프로젝트입니다. 그 방식중 하나로 글을 작
트랜잭션 Isolation총 정리
하나의 트랜잭션이 정의 되면 그 트랜잭션 전체가 모두 반영(commit)되거나 모두 미반영(rollback)트랜잭션을 사용하는 이유라고 할 수 있다. Atomicity가 없다면 트랜잭션 도중 문제가 생길 경우 application level에서 실행 도중 생긴 문제를
프로젝트를 데이터 중심 설계에서 책임 주도 설계로 변경해보기(3)
데이터 중심 설계를 책임 주도 설계로 변경하여 객체가 같은 메시지에 대해서 각자가 다르게 책임지는 방식으로 코드를 구성하면 변경에 유리한 코드를 작성할 수 있다.하지만, 실제에서 개발할 때에는 완벽하게 처음부터 객체지향적인 설계를 하는 것은 현실적으로 쉽지 않고 때로는
Apache Kafka 초기 설정 주의점 정리
1. 개요 이전 시리즈 포스팅에서 kafka의 핵심적인 개념과 spring boot연동및 설정방법에 대해서 실습을 해보았습니다. 개인 프로젝트에서 이를 적용해서 사용하던 중 몇가지 문제가 발생하여 검색을 해서 해결책들을 찾아보다 보니 몰랐던 내용들을 알게 되어서 정리
JUnit5과 Spring boot 테스트 코드 작성-테스트 커버리지와 Jacoco (5)
작성한 코드에서 얼마만큼 테스트 코드를 통해서 실행돼었는지를 의미하는 지표이다.테스트 커버리지를 통해 전반적으로 테스트가 부족한지 여부를 알 수 있다.테스트 커버리지는 일정 기준 이하(대략 60%정도로 판단한다고 함)이면 문제가 된다고 판단할 수 있따.하지만 테스트 커