민스씨의 일취일장

Java Backend 과정 16주차 후기글입니다.F-Lab Java Backend 과정 16주차16주차 멘토링 주제라이브 코딩이론1. 객체 직렬화(Serialization)와 역직렬화(Deserialization)2. Java Thread 생명주기멘토링이 일단 막바지(연장 연부가 결정이 안돼서)이고 요즘 한창 취업 원서 접수하고 있어 취업 관련 주제에 집중하고 있다. 하지만 프로젝트는 여전히 조용히 계속 진행중에 있다!라이브 코딩혹시 발생할 수 있는 라이브 코딩을 대비하기 위해 이번 멘토링 시간엔 짧은 원서 접수 이야기를 나눈 뒤 라이브 코딩에 집중했다. 지난 라이브 코딩은 알고리즘에 포커스를 맞췄다면, 이번에는 실무관점에서 구현에 포커스를 맞춰 진행했다. 빈 클래스 2개에 내용을 넣어가는 방식으로 진..

PaymentService에 적용된 Redis Cache를 분산 캐시(distributed cache)로 전환하는 과정(GitHub Issues #28)에 대한 글이다.Redis를 클러스터로 만들어 분산캐시 도입하기작업 순서 계획1. redis.conf 작성 및 적용2. 새로운 Redis용 인스턴스 생성3. Redis 노드(컨테이너)들을 클러스터 구성(생성) 명령 수행4. Redis 분산 캐시를 사용할 수 있도록 애플리케이션 설정 수정1. redis.conf 작성 및 적용nginx.conf와 마찬가지로, redis.conf를 작성해준다. 이 파일은 Redis 컨테이너 실행시 Volume으로 연결 해 줄 것이다. 경로는 어디다 해도 상관 없지만 민스씨 본인은 redis/redis.conf 경로로 할 것이다..

Redis 캐시 도입 후 선능 변화를 테스트(Gtihub Isssues #26)한 결과입니다.Redis 캐시 도입 후 성능 변화 테스트 시나리오1부터 100번까지의 paymentId를 랜덤으로 100명의 가상 사용자가 1분동안 요청을 보낸다.테스트 1캐시를 사용하지 않은 테스트이다.가상 사용자 99명이 1분동안 캐시 적용되지 않는 서비스에 무작위 요청을 보내는 테스트에 대한 결과이다. TPS(초당 처리량)은 평균 518이며 총 1분간 총 처리량은 20861이다.테스트2캐시를 사용하는 테스트이다.가상 사용자 99명이 1분동안 캐시가 적용된 서비스에 무작위 요청을 보내는 테스트에 대한 결과이다. TPS(초당 처리량)은 평균 679.2이며 총 1분간 총 처리량은 28673이다.테스트 분석TPS 31% 향상 (..

PaymentService에 Redis 캐시를 도입하는 과정(GitHub Issues #26)에 대한 글이다.REDIS를 이용해 캐시 도입하기작업 순서 계획1. 프로젝트에 Redis 설정2. 로컬 Redis에서 테스트3. EC2 Redis용 인스턴스 추가하기4. 작동 확인1. 프로젝트에 Redis 설정캐시를 적용할 서비스(PaymentService)에 Redis 설정을 하면서 캐시 도입을 시작한다.build.gradle에 의존성 추가build.gradle에 Redis 의존성을 추가한다. Redis도 일종의 Database이기 때문에, Database 연결과 비슷한 과정을 거친다.implementation 'org.springframework.boot:spring-boot-starter-data-redis..

F-Lab Java  Backend 과정 15주차 후기글입니다.F-Lab Java Backend 과정 15주차15주차 멘토링 주제프로젝트1. 캐시 도입이론1. JWT, OAuth, SSO프로젝트캐시도입드이어 캐시를 도입하기 시작했다. 멘토링 시작하기 직전에 AWS에 Redis를 이용한 별도의 EC2에 컨테이너를 띄운후, 기존 서비스들과의 연동까지 성공적으로 마쳤다. 이제는 캐시 도입후의 성능 테스를 하면 된다.캐시도입해 보면서 느낀점Redis를 적용해 보면서, 생각했던 것 보다 어려운 작업이 아닌 것을 알게됐다. 물론 깊게 들어가면 또 끝없이 어렵겠지만, 알게된 점은 내가 어떤 새롭고 낯선 기술을 도입하기에 앞서서 너무 사려깊게 살펴보려는 성향을 갖고 있고, 이런 성향 때문에 프로젝트 진행이 속도가 나지..

F-Lab Java Backend 과정 14주차 후기글입니다.F-Lab Java Backend 과정 14주차14주차 멘토링 주제프로젝트1. 로드밸런서 도입 후 성능 저하 문제2. 캐시 도입2. 예외처리이론1. 동시성 이슈2. TDD프로젝트로드밸런서 도입 후 성능 저하 문제인스턴스 6개 생성이번주는 모든 서비스를 독립된 서버로 분리해 서버 이중화를 진행했다. 이를 위해서 서비스 2개, 로드밸런서 1개로 서비스를 위해서 3개의 인스턴스를 생성했다. 여기에 모니터링을 위해 Prometheus 전용 인스턴스 한 개, 테스트를 진행하기 위한 독립적인 Agent 두 개까지 해서 총 6개의 인스턴스를 생성했다.성능 저하 발생예상 시나리오로는 서버를 이중화하고 로드밸런서를 도입하면 성능이 2배이상 높아질 것이라고 예상..

캐시 전략과 캐시 소프트웨어 종류에 대한 정리 글이다.Cache캐시를 도입하기에 앞서 캐시에 대해 알아보려고 한다.캐시란?캐시란 데이터 임시 저장소이다. 주로 자주 사용하는 데이터 또는 이미 사용한 데이터를 저장해 둬, 다시 데이터를 사용하려 할 때 데이터베이스까지 가지 않고 바로 꺼내쓸 수 있도록 한다. 이런 사용방식으로 성능을 향상시키고, 네트워크의 트래픽을 감소시킬 수 있다.전략에 따른 캐시캐시라는 임시 저장소를 어떤 구성, 즉 어떤 전략으로 사용하는지에 따라서 크게 3가지로 구분해 생각해 볼 수 있다.1) 캐시 Cache지금 위에서 설명한 말그대로의 캐시이다. 클라이언트와 서버 사이 또는 서버와 데이터베이스 사이에 위치시켜 서버에 요청을 보내기 전 또는 데이터베이스로 Query를 보내기 전에 임시..

서비스 컨테이너를 하나 더 띄워서 서비스를 이중화 하고, 이를 위해 로드밸런서를 도입하는 과정(Github Issues #18)에 대한 글입니다.로드밸런서 도입해 서비스 이중화하기작업 순서 계획1. 새로운 서버에 동일한 PaymentService 컨테이너 띄우기2. 로드밸런서 서버에 nginx 컨테이너 띄우기3. 로드밸런서와 PaymentService1, 2 연결하기4. 순서대로 로드밸런싱 되는지 확인하기5. 프로메테우스가 PaymentService2와 로드밸런서도 인식할 수 있도록 세팅6. 그라파나 대시 보드 구성하기1. 새로운 서버에 동일한 PaymentService 컨테이너 띄우기AMI를 생성해 기존 세팅을 갖고 있는 서버를 생성해주었다. 컨테이너는 이미 생성돼 있는 상태로 이미지가 만들어 지기 때..

상황EC2(Free Tier) 상태 running이고, 시스템 로그를 들여다 봐도 문제가 없는데 접속이 안되는 문제가 발생했다.원인CPUCreditBalance가 고갈된 것이 원인이었다. 아무리 프리티어 내의 사용량이여도, 시간당 가용할 수 있는 CPU자원의 한계가 정해져 있다는 것이다. 요즘 성능테스트로 부하를 많이 일으켜서 CPU 사용할 수 있는 Credit을 모두 소진 한 것이다.해결방법해결책은 기다리면 된다. CPU Credit은 시간당 쓸 수 있는 양과 같기 때문에, 시간이 지나면 다시 원상태로 회복된다.