
개요 Helparty를 클라우드에 배포하고 다른 클라우드 서버에 띄어놓은 여러 어플리케이션들을 연결시켜 대략적인 서비스를 제공하기 위한 기반을 완성했습니다. 네이버 클라우드에서 크레딧을 지급해줘서 비용 문제로 부터 자유로울 수 있었습니다. 이제 ngrinder를 통해 서버에 부하를 걸어보고 난뒤 pinpoint와 어플리케이션들의 cpu 사용률을 보고 모니터링을 진행한 뒤 프로그램을 개선시킬 여지가 있는지 확인해보겠습니다. WAS 서버 증설에 따른 성능 비교 먼저, WAS 서버 1개를 사용할 때와 WAS 서버 2개를 사용할 때를 비교하여 WAS 서버를 Scale Out 방식으로 증설하는 Helparty에서 WAS를 하나씩 늘릴 때마다 얼마나 큰 성능 향상이 있는지 확인해보겠습니다. WAS 1대를 사용하는 ..

개요 제가 만들고 있는 Helparty는 대용량 트래픽이 요청되는 상황에서도 안정적인 운영을 보이도록 설계하고 있습니다. 그러기 위해서는 프로그램에서 성능 이슈에 밀접하게 연관된 데이터베이스 영역을 눈여겨 봐야합니다. 지금의 데이터베이스는 하나의 하드웨어에서 모든 쿼리 연산을 책임지고 있습니다. 하나의 하드웨어만 잘못되도 프로그램 전체가 멈추게 되는 불안정한 구조이고 성능적인 면에서도 이곳에서 문제가 발생하면 프로그램 전체가 느려지는 병목 지점이 됩니다. 따라서 저는 데이터베이스 Replication을 만들어서 쿼리의 성격에 따라 분기를 하여 두대의 데이터베이스로 쿼리를 보내려고 합니다. 이렇게 함으로써 하나의 데이터베이스에서 모든 쿼리의 작업을 도맡아 했던 걸 2개의 데이터베이스가 나눠서 작업을 처리하..

개요 Helparty를 클라우드에 배포하고 다른 클라우드 서버에 띄어놓은 DataBase에 연결시켜서 대략적인 서비스를 제공하기 위한 기반을 완성했습니다. 이제 ngrinder를 통해 서버에 부하를 걸어보고 난 뒤 pinpoint를 was 서버에 붙혀서 서버의 성능을 분석하고 문제를 진단해보겠습니다. ngrinder 서버 환경 저는 처음에 스팩이 '[SSD] mysql-ngrinder 의 기본 스토리지 50 GB'인 A 서버만을 사용하였습니다. 그 서버만을 사용해서 가상 사용자가 300인 요청을 보내도록 테스트를 진행했더니 ngrinder서버에 메모리 릭 현상이 발생했습니다. 그래서 다른 성능이 더 좋은 B 서버를 만들고 두 곳에서 부하를 나눠서 요청을 보내도록 테스트를 진행했습니다. 서로 같은 요청을 ..

프로젝트 'Helparty'를 진행하면서 여러방식의 성능 튜닝 방법들이 있다는 걸 알게되었습니다. 그리고 이번에 진행해볼 방법은 데이터베이스와 소통하는 언어를 튜닝해서 MySql이 일하는 방식을 효율적으로 안내하여 성능을 향상 시키는 '쿼리 성능 튜닝'을 진행하겠습니다. 저의 웹 서비스 'Helparty'에서 사용하는 쿼리 중에 3개의 테이블을 조인 하는 쿼리의 수행시간을 확인하고 실행계획을 토대로 튜닝을 해보겠습니다. 튜닝할 코드 SELECT gb.id id, gb.title title, gb.content content, gb.created_at create_at, gb.modified_at modified_at, g.gym_name gym_name, g.phone_number phone_number..
저는 프로젝트 Helparty를 만들어가면서 수많은 오류들을 만났고 그 오류들은 저의 사소한 오류인 것 부터 시작해 중요한 구조적인 문제까지 다양한 것들이었습니다. 이러한 오류들을 해결하기 위해서는 실행된 코드의 흔적을 알려주는 Log가 필요합니다. 그리고 코드를 훗날 유지보수 할 때 개발자의 시간을 절약해주고 편하게 작업하는데 Log는 필수적입니다. 하지만 이러한 목적을 위해서라면 System.out.println() [이하 sysout]을 사용해도 충분합니다. 그럼 왜 sysout을 사용하지 않고 로그 라이브러리를 사용해야 하는 지 알아보겠습니다. System.out.println을 사용하지 않고 로그 라이브러리를 사용하는 이유 sysout을 사용하면 자바를 처음 배울 때 모두가 알게되는 log를 남..

정황 소개 저는 운동 동행 구하기 웹 어플리케이션 'Helparty'를 만드는 중 입니다. 잘 만들고 있던 중에 게시물 작성 기능과, 수정 기능 그리고 삭제 기능을 만들던 과정에서 로그인 되어 있는 유저의 정보를 확인하기 위해 반복적으로 컨트롤러 클래스에서 session을 통해 로그인 되어 있는 이메일을 가져오는 로직이 반복된다는 것을 알았습니다. 그리고 이런 로그인을 통한 유저 확인 로직은 계속해서 반복되어 나타날 것임을 알고 있습니다. 따라서 저는 이 로그인 정보를 가져오는 로직을 핵심로직의 앞에 반복적으로 나타나는 중복적인 부가로직을 판단하고 분리하기로 했습니다. 1. AOP를 통한 분리 먼저, 메서드 단위로 중복적인 로직을 분리하는 AOP를 통해 구분하였습니다. AOP에는 CGlib, Java P..

스프링 프로젝트를 하는 중에 회원가입을 개발하고 다음으로 로그인 개발을 하였습니다. 그 다음으로 유저의 정보를 수정하는 API를 개발하는데 "이 사용자가 해당 정보를 수정할 수 있는 권한이 있는건가?" 라는 사실을 검사해야하기에 저는 수정 권한을 체크하기 위해서 로그인 여부를 체크하였습니다. 그리고 그 다음으로 회원 탈퇴 API를 개발하였는데 또 다시 로그인 권한을 체크 해야했습니다. 이처럼 로그인 권한 검사는 개발자가 어떠한 목적을 가지고 API 개발하였는 가 와는 별개로 부가적인 로직으로 메소드 앞 부분에 반복해서 추가해야하는 상황이 오게 됩니다. 따라서 저는 이 로그인 부분을 따로 떼어놓아야겠다고 생각했습니다. 그리고 반복되는 부가 로직을 분리하는 방법으로는 3가지가 있습니다. Filter와 Int..

먼저 저는 헬스 동행을 구하는 어플리케이션인 'HELPARTY'를 개발 중에 있습니다. 나중에 이 어플리케이션 서버의 처리량이 한계에 도달했을 때 서버를 확장하는 방법에 대해 알아보았습니다. 먼저 서버의 성능을 올리는 방법에는 2가지가 있다는 것을 알았습니다. Scale Out vs Scale Up 첫번째로 Scale Out과 Scale In이 있습니다. 이것에 대한 정보는 이 포스팅을 참조해주시길 바랍니다. hamryt.tistory.com/1 스케일 아웃 (Scale Out) vs 스케일 업 (Scale Up) #1 스케일 아웃 정의 접속된 서버의 대수를 늘려 처리 능력을 향상시키는 것이다. 서버가 증설됨에 따라 트래픽을 나누어 갖게 되고, 각각의 서버가 이를 처리하게 된다. 수평 스케일로 불린다. ..
- Total
- Today
- Yesterday
- logback
- MySQL
- Filter
- AWS
- devops
- scale in
- 로그
- 쿼리 튜닝
- log4j2
- memcached
- Declarative Transaction
- 성능 테스트
- AOP
- 선언적 트랜잭션
- 유틸클래스
- UTIL
- 성능 향상
- nGrinder
- interceptor
- scale Out
- redis
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |