일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Spring Data Redis
- ci/cd
- 동시성
- java
- 제네릭
- 지연로딩
- Ehcache
- 부하테스트
- Jenkins
- 주문
- 상태패턴
- CaffeineCache
- 재고 시스템
- JDK14
- lazyloading
- GithubActions
- Redis
- nonclustered index
- JPA
- 카카오 화재
- 트랜잭션
- JAVA8
- B+TREE
- Metaspace
- method area
- backend
- springboot
- 리팩터링
- 웹캐시
- 공변
- Today
- Total
NDM
6. 프로젝트의 클라우드 아키텍처를 설계해보자 ( feat. Naver Cloud ) 본문
타임딜 프로젝트를 진행하며 내가 사용한 서버는 다음과 같다.
넘블 X 네이버 클라우드의 혜택으로 크레딧 20만원을 받아 아키텍처를 설계할 수 있었다.
1. SpringBoot 서버 1대
2. Nginx 서버 1대
3. Redis 서버 1대 ( Session & Caching )
4. MySQL 서버 1대
5. Pinpoint 서버 1대
6. Jmeter 서버 1대
7. Prometheus & Grafana 서버 1대
1. SpringBoot Server
4vCPU, 8GB Mem, 50GB Disk 서버를 사용했다. 더 좋은걸 사용할수도 있었지만, 초기 세팅은 이정도로만 하고
나중에 Ngrinder로 부하를 발생시키며 Pinpoint로 모니터링하면서 크레딧이 얼마 남았는지 확인하며 스케일 업을 할 예정이다.
2. Redis Server
8vCPU, 8GB Mem, 50GB Disk 서버를 사용했다.
이번 프로젝트에서는 Redis를 2가지 용도로 사용한다. 하나는 세션 외부 저장소, 하나는 캐싱.
때문에 세션과 캐싱을 하나의 Redis 서버에서 처리하기 보다 2대의 Redis를 사용하고 싶었다.
하지만 크레딧을 아껴써야 했기 때문에 일단은 1대의 서버에서 요청을 처리하도록 했다.
재고 / 캐싱 / 세션을 한 서버에서 관리할 예정이기에 어느정도 성능이 있는 서버를 사용했다.
3. MySQL Server
이번 프로젝트에서 해보고 싶었던 것 중 하나는 MySQL의 Replication과 Partitioning이었다.
Slave를 한대 더 두고 2대로 운영해보고 싶었지만, 이 역시 크레딧을 아껴써야 했기에 보류하게 되었다.
또한 이번 프로젝트 주제와 요구사항에서 Replication은 필수적인 요구사항도 아니며, 타임딜 상품 조회나 재고 모두 Redis에서 처리하기 때문에 크게 MySQL 서버를 개선해야겠다는 필요성도 느끼지 못했다.
4. Nginx Server
필수적인 요구사항도 아니었기 때문에 사용할지 말지를 고민했다.
"서버를 1대로만 제한한다" 라는 요구사항이 있었기 때문에 오히려 적용하지 말라는건가 ? 까지 생각했다.
하지만 API 서버는 1대로 제한하지만 이후 확장성까지 고려하지 말라는 말은 없었으며 Nginx의 gzip 설정만으로도 성능에 이점이 된다는 글을 읽은적이 있기에 사용하기로 했다. 다만, 크레딧을 고려해 다른 서버보다 성능은 낮은걸로 사용했다.
5. Jmeter
부하테스트를 위해 Jmeter를 사용했고, GUI로 사용하는게 편해 로컬에서 테스트하기로 했다.
물론 내 노트북이 성능이 좋은편이 아니지만(4코어, 8GB RAM), 그래도 Spring API 서버와 테스트하는 서버가 분리되어있다는 것에 의의를 두고 진행했다.
6. Pinpoint
Naver Cloud Platform 에서 제공하는 서버 이미지를 통해 설치했고, Agent는 SpringBoot와 같은 서버에 두도록 했다.
Proemetheus & Grafana 라는 시스템 모니터링 툴을 같이 사용하고 있는데 Pinpoint까지 사용할 일이 있을까? 라고 고민했으나, https://meetup.nhncloud.com/posts/237 포스팅을 읽고 둘 다 사용하기로 했다.
결론적으로, 내가 궁금한것은 내 프로젝트에서 "대량의 동시주문이 발생했을 때 어떻게 되는지", "상품 조회가 잘 이루어지는지" 를 보고싶었기 때문에 Redis 서버의 부하나 메모리적인 측면은 Grafana를 통해 관찰하고, 비즈니스 로직에 대한 트레이싱 목적으로 pinpoint를 별도 구성하기로 했다.
7. Prometheus & Grafana
본래 실제 환경에서는 Prometheus와 Grafana를 각각 다른 서버에 구축하는것이 일반적이나 내 경우는 토이프로젝트이기도 하고, 실제 서비스도 아닐뿐더러 대용량의 트래픽도 발생하지 않을것이기에(부하테스트를 진행하기는 할 것이지만!)
그냥 같은 서버에 구축했다. Grafana 대시보드는 이미 만들어져있는걸 사용했다.
'[프로젝트] 타임딜 API 서버' 카테고리의 다른 글
재고 처리 로직 동시성 이슈 해결 일지 2 (0) | 2023.06.05 |
---|---|
시스템 디자인 재설계로 상품 조회 api를 개선해보자 (0) | 2023.06.04 |
상품 조회 api와 주문 api 설계하기 (0) | 2023.06.03 |
Jmeter를 이용한 이벤트 상품 조회 api 부하 테스트와 개선일지 (0) | 2023.06.01 |
확장성을 고려한 로그인 세션 관리하기 (0) | 2023.02.27 |