일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- java
- 부트캠프
- 트러블슈팅
- nGrinder
- 알고리즘
- backend
- 데이터구조
- 에프랩
- 로드밸런서
- 자바백엔드
- 멘토링
- github
- FLAB
- 플러터
- redis
- 후기
- 코딩테스트
- MySQL
- 레디스
- error
- 자바
- 성능테스트
- F-Lab
- 도커
- Flutter
- EC2
- grafana
- Spring
- 백엔드
- AWS
- Today
- Total
목록Projects (17)
민스씨의 일취일장
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..
서비스 컨테이너를 하나 더 띄워서 서비스를 이중화 하고, 이를 위해 로드밸런서를 도입하는 과정(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은 시간당 쓸 수 있는 양과 같기 때문에, 시간이 지나면 다시 원상태로 회복된다.
EC2에 띄운 로드밸런서로 요청이 도달하지 않을 때 빨리 한 번 고려해 보면 좋은 방법에 대한 글입니다.상황EC2 도커로 로드밸런서를 도입하였다. 이미 지난 번에 해본적이 있기 때문에 설정에는 문제가 없는데, 이상하게 어떤 요청도 nginx에 도달하지 않는다. 하지만 EC2에서 localhost로 보내면 간다.원인EC2 보안 그룹이 막혀 있었다.해결방법load balancer에 설정해 놓은 포트를 열어주어라!회고너무 간단한 이슈에서 한 시간 가량을 소비해서 다시는 이런 어처구니 없는 상황을 겪지 않기 위해 작성해둔다.