티스토리

민스씨의 일취일장

검색하기

블로그 홈

민스씨의 일취일장

ydmins.com/m

하루하루 민스씨가 성장합니다

구독자: 0

방명록 방문하기

주요 글 목록

프로젝트 LOG | Redis를 클러스터로 만들어 분산캐시 도입하기 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 경로로 할 것이다.. 공감수 3 댓글수 2 2024. 9. 15.
Performance Analysis | Redis 캐시 도입 후 성능 변화 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% 향상 (.. 공감수 0 댓글수 0 2024. 9. 12.
프로젝트 LOG | REDIS를 이용해 캐시 도입하기 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.. 공감수 0 댓글수 0 2024. 9. 12.
프로젝트 LOG | 로드밸런스 도입해 서비스 이중화하기 서비스 컨테이너를 하나 더 띄워서 서비스를 이중화 하고, 이를 위해 로드밸런서를 도입하는 과정(Github Issues #18)에 대한 글입니다.로드밸런서 도입해 서비스 이중화하기작업 순서 계획1. 새로운 서버에 동일한 PaymentService 컨테이너 띄우기2. 로드밸런서 서버에 nginx 컨테이너 띄우기3. 로드밸런서와 PaymentService1, 2 연결하기4. 순서대로 로드밸런싱 되는지 확인하기5. 프로메테우스가 PaymentService2와 로드밸런서도 인식할 수 있도록 세팅6. 그라파나 대시 보드 구성하기1. 새로운 서버에 동일한 PaymentService 컨테이너 띄우기AMI를 생성해 기존 세팅을 갖고 있는 서버를 생성해주었다. 컨테이너는 이미 생성돼 있는 상태로 이미지가 만들어 지기 때.. 공감수 1 댓글수 1 2024. 8. 30.
TIssue | AWS EC2 running 상태이고 시스템 로그 문제 없는데 접속 안되는 이유 (Feat. FreeTier) 상황EC2(Free Tier) 상태 running이고, 시스템 로그를 들여다 봐도 문제가 없는데 접속이 안되는 문제가 발생했다.원인CPUCreditBalance가 고갈된 것이 원인이었다. 아무리 프리티어 내의 사용량이여도, 시간당 가용할 수 있는 CPU자원의 한계가 정해져 있다는 것이다. 요즘 성능테스트로 부하를 많이 일으켜서 CPU 사용할 수 있는 Credit을 모두 소진 한 것이다.해결방법해결책은 기다리면 된다. CPU Credit은 시간당 쓸 수 있는 양과 같기 때문에, 시간이 지나면 다시 원상태로 회복된다. 공감수 0 댓글수 0 2024. 8. 30.
TIssue | EC2에 로드밸런서 도입했는데 신호가 Nginx에 도달도 안한다 EC2에 띄운 로드밸런서로 요청이 도달하지 않을 때 빨리 한 번 고려해 보면 좋은 방법에 대한 글입니다.상황EC2 도커로 로드밸런서를 도입하였다. 이미 지난 번에 해본적이 있기 때문에 설정에는 문제가 없는데, 이상하게 어떤 요청도 nginx에 도달하지 않는다. 하지만 EC2에서 localhost로 보내면 간다.원인EC2 보안 그룹이 막혀 있었다.해결방법load balancer에 설정해 놓은 포트를 열어주어라!회고너무 간단한 이슈에서 한 시간 가량을 소비해서 다시는 이런 어처구니 없는 상황을 겪지 않기 위해 작성해둔다. 공감수 0 댓글수 0 2024. 8. 25.
TIssue | AWS EC2 작동중인데 연결 안되는 이슈 (Feat. 연결 추적 테이블 nf_conntrack table이 가득참) AWS EC2 정상 작동중인데 접속이 안돼 확인해 보니, nf_conntract table이 가득찬 이슈가 있었다. 이 것에 대한 해결 과정에 대한 글이다.상황EC2가 정상작동 중인데 접속이 안되는 이슈가 발생했다. 재부팅을 해도 해결이 되지 않는다. 지난 번에도 동일한 증상이 있어서 중지하고 재실행 했었다. 이렇게 했을 경우 ElasticIP를 사용중이 아니라면 접속 IP가 변경되버리고, 해당 IP로 설정해 놓은 모든 곳의 설정을 변경해줘야 햐는 번거로움이 있다. 그래서 이번에는 어떻게든 문제를 찾아 보려고 이것 저것 하다가 새로운 문제를 발견하게 되었다.원인인스턴스 목록에서 문제를 일으킨 인스턴스를 선택한다. 그런다음 오른쪽 위 작업에서 '작업 > 모니터링 및 문제 해결 > 시스템 로그 가져오기' 순.. 공감수 0 댓글수 0 2024. 8. 25.
TIssue | 성능 테스트 적정 환경 찾기 (Feat. 매번 같은 양상의 메트릭 측정 됨) Github Issues #17에 대한 글입니다.성능 테스트 - 적정 환경 찾기이슈nGrinder 컨트롤러와 에이전트를 연결시키고, Prometheus와 Grafana를 이용해 메트릭을 수집하고 시각화하는 것까지 잘 되었다. 그런데 이상하게 어떤 조건에서도 CPU 점유율 양상이나, 평균 반응 시간 등의 그래프가 비슷한 양상을 띄었다. 분명히 조건이 달라진다면 반응도 달라져야 하는데, 언제나 똑같았다.문제 파악문제를 파악하기에 앞서 테스트가 어떻게 이뤄졌었는지 살펴보도록 하겠다.테스트 환경서버 : AWS EC2OS : Amazon-LinuxDatabase : AWS RDS특징 : Docker Container로 구동 테스트 도구nGrinder Controller : 로컬 PC에서 실행nGrinder Age.. 공감수 1 댓글수 0 2024. 8. 24.
nGrinder | 성능 테스트 결과 - Dynamic UserId Case - 서버 과부하 Dynmic UserId Case에 대한 성능 테스트 결과 자료이다.Case 3 성능 테스트 결과Dynamic UserId Case는 동적으로 userId를 생성해, 고정 userId와 다르게 모든 요청이 다른 사용자가 접근하는 시나리오이다.Case 2 - Dynamic UserId Case- 고정 Vuser : 10- 테스트 시간 : 1분- 일정한 부하 유지 (Rampup 없음)- 스레드 랜덤 Sleep 없음- 동적 userID 사용특이사항테스트한 프로젝트는 스레드 안전하지 않았다. Case 3에서부터 프로젝트의 스레드 안정성을 높혀가며 테스트를 진행할 예정이다. Connection을 2밖에 사용하지 않으므로 DB에 접근할 수 있는 유휴 Connection은 충분하다. 하지만 CPU 사용량이 100% .. 공감수 0 댓글수 0 2024. 8. 20.
nGrinder | 성능 테스트 결과 - Simple Case Simple Case에 대한 성능 테스트 결과 자료이다.성능 테스트 결과Simple Case는 앞으로 성능 테스트의 비교군이 될 가장 기초적인 테스트 케이스이다.Case 1 - Simple Case- 고정 Vuser : 10- 테스트 시간 : 1분- 일정한 부하 유지 (Rampup 없음)- 스레드 랜덤 Sleep 없음- 고정 userID 사용 TPS 공감수 0 댓글수 0 2024. 8. 18.
nGrinder | 동시성 시나리오 만들기 이 글은 Github Isssu #12 1-4 nGrinder 동시성 이슈 시나리오 만들기를 다룹니다.nGrinder 동시성 테스트 시나리오 만들기동시성을 고려한 서비스동시성을 고려한 서비스를 만들기 위해 동시성 테스트를 준비하고 있다. 동시성 문제가 유발할 수 있는 환경은 크게 두 가지 방법으로 만들어 낼 수 있다.nGrinder 컨트롤러 설정테스트 Script 수정nGrinder 컨트롤러 설정만으로 동시성 시나리오 구성동시성이라하면 여러명이 동시에 작업을 요청해야 한다. 이를 위해서 여러 Agent를 구성할 수도 있다. 하지만 리소스를 많이 사용하지 못하는 환경에서 작은 규모에 테스트를 진행한다면 하나의 Agent로 동시성 시나리오를 만들 수 있다. 어떻게? 방법은 nGrinder 설정으로 가능하다... 공감수 1 댓글수 0 2024. 8. 17.
Grafana | 성능 테스트 | 모니터링 | 필요한 지표들 선정한 뒤 그라파나 대시보드 생성하기 성능 테스트에서 측정할 지표들에 대한 글로, Github Issue #12의 1-2에 대한 내용입니다.성능 테스트 지표들 선정하기성능테스트를 기반으로 프로젝트를 진행할 계획이다. 이를 통해 적절한 최적화를 진행하며 기능들을 추가해 나갈 것이다. 테스트와 모니터링 환경이 구축되었으니 이제 본격적으로 어떤 정보들을 수집해 분석할 것인지 정해야 한다.어떤 것을 측정할 것인가?어떤 성능을 갖춰야 하는지는 프로젝트의 지향점에서 찾으면 된다. 이번 프로젝트의 목표는 "대용량 트래픽을 빠른 속도로 안전하게 처리할 수 있는 고가용성 결제시스템"을 만드는 것이다. 대용량 트래픽을 빠른 속도로 안전하게 처리할 수 있는 고가용성 결제 시스템 목표에서 중요 키워드를 뽑아보자면 다음과 같다.대용량 트래픽빠른 속도안전성고가용성.. 공감수 0 댓글수 0 2024. 8. 16.
성능 테스트 | 컨테이너 메모리 제한 설정 컨테이너 구동 시 메모리 제한 설정에 대한 글로, Github Issue-#12의 일부 내용입니다. 단일 엔드포인트 성능 테슽 - /payments · Issue #12 · f-lab-edu/MetaPay/payments 엔드포인트에 대한 성능테스트를 진행할 것이다. 작업은 "테스트 준비"와 "테스트 수행"으로 이루어져 있다. 세부 항목은 아래와 같다. 테스트 준비 도커 컨테이너 메모리 설정 Grafana Custogithub.com컨테이너 메모리 제한 설정성능 테스트에 진행하기 앞서, 컨테이너의 환경을 되도록 일정하게 유지할 필요가 있다. 즉, 변인을 통제하기 위해 서비스 컨테이너의 메모리를 고정(제한) 해보려고 한다.제한 방법지금 적용해보려 하는 방법은 두 가지이다.JVM Heap 메모리 제한컨테이너.. 공감수 0 댓글수 0 2024. 8. 16.
TIssue | EC2 내 컨테이너에서 로컬 PC로의 요청이 전달되지 않는 이슈 (feat. Public IP vs. Private IP) EC 내 컨테이너에서 로컬 PC로 보낸 요청이 전달되지 않는 이슈에 대한 글입니다.EC2에서 로컬 PC로 요청이 전달되지 않는 이슈상황 1nGrinder Agent를 EC2에 도커 컨테이너로 띄웠다. Agent는 작동하기 위해선 Controller의 신호를 받아야 한다. 따라서 성능 테스트를 진행하기 전에 Agent가 보내는 신호를 Controller가 수신하는 과정을 거쳐야 한다. 하지만 EC2 컨테이너로 구동된 Agent가 로컬 PC 컨테이너로 구동중인 Controller로 보낸 신호가 도달하지 않는 이슈가 발생했다.원인 파악 과정 1 - 로컬테스트에서는 정상 작동로컬환경에서 nGrinder Controller와 Agent를 연결했을 때는 정상적으로 작동했다. 똑같은 설정이 EC2로 Agent를 옮긴.. 공감수 0 댓글수 0 2024. 8. 14.
TIssue | Nginx | EC2 | 도커 컨테이너로 띄운 로드밸런서가 하나의 서버만 연결하는 이슈 로드 밸런서가 한 곳만 포워딩하는 이슈 해결방법에 대한 글입니다.로드 밸런서가 하나의 서버만 연결하는 이슈Tissue오늘의 이슈는 다음과 같다.EC에 띄운 Nginx 로드밸런서가 요청을 하나의 컨테이너로만 전달한다.(원래는 두 컨테이너에 번갈아 가면서 전달해야 한다.)상황파악 - 기존 Nginx 설정events{ worker_connections 1024;}http{ upstream payment_service{ server metapay-payment:8080; server metapay-payment2:8081; } server { listen 80; .. 공감수 0 댓글수 0 2024. 8. 14.
VisualVM | Java 애플리케이션의 모니터링 도구 with Docker VisualVM 사용하며 겪은 시행착오와 사용 방법에 대한 글입니다.VisualVM이란?VisualVM은 Java 애플리케이션을 위한 성능 모니터링 및 프로파일링 도구이다.VisualVM 사용방법VisualVM은 응용프로그램으로, 간단하게 다운만 받으면 바로 실행할 수 있다.설치아래 링크에서 자신의 OS에 맞는 VisualVM을 다운 받으면 된다. VisualVM: DownloadFirst Steps Unzip the downloaded archive. The archive already contains the top-level visualvm directory. Start VisualVM by invoking the binary appropriate for your OS:visualvm\bin\visu.. 공감수 0 댓글수 0 2024. 8. 7.
프로젝트 | PaymentService 만들며 익힌 기본기 - PR, 예외처리, Test Code, SRP 서비스 하나 만들며 익힌 기본기에 대한 내용이다.기본 서비스 만들기프로젝트를 시작하면서 가장 먼저 핵심 기능을 하는 서비스를 하나 만드는 시간을 가졌다. 단 하나의 메서드의 동작을 구현하고 테스트 코드를 작성해 보면서 여러 기본기를 익힐 수 있었다.기본 서비스 구성읻민스가 진행중인 현재 프로젝트는 페이 서비스를 만들어 보는 것이다. 페이 서비스의 가장 핵심 기능은 "결제"이다. 결제는 다음과 같은 순서로 이뤄지도록 구성했다. 이 "결제" 기능을 수행하기 위해 필요한 것들을 아래와 같이 구성했다.com.ydmins.paymentservice│├── controller│ └── PaymentController.java│├── domain│ └── payment│ ├── Payment.jav.. 공감수 1 댓글수 0 2024. 7. 24.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.