💻 Code Convention
📝 Git Convention
👀 Branch Strategy
인프라 구조 설계
ERD 설계
📁 src
└── 📁 main
├── 📁 java
│ └── 📁 com
│ └── 📁 official
│ └── 📁 memento
│ ├── 📁 auth
│ ├── 📁 global
│ ├── 📁 member
│ ├── 📁 orderinfo
│ └── 📁 schedule
│ ├── 📁 controller
│ │ ├── 📁 dto
│ │ │ ├── 📁 request
│ │ │ └── 📁 response
│ │ ├── 📄 ScheduleApiController
│ │ └── 📄 ScheduleApiDocs
│ ├── 📁 domain
│ │ ├── 📁 entity
│ │ ├── 📁 enums
│ │ └── 📄 ScheduleRepository
│ ├── 📁 infrastructure
│ │ └── 📁 persistence
│ │ ├── 📁 projection
│ │ │ ├── 📄 ScheduleEntity
│ │ │ └── 📄 ScheduleEntityJpaRepository
│ │ └── 📄 ScheduleRepositoryAdapter
│ ├── 📁 service
│ │ ├── 📁 command
│ │ ├── 📁 usecase
│ │ └── 📄 ScheduleService
│ ├── 📁 tag
│ ├── 📁 todo
│ └── 📄 HealthCheckApi
├── 📁 kotlin
└── 📁 resources
우리 서비스가 TPS 1000 이 된다 가정하고, 톰캣, 스프링 설정 값 고민해보기 & 성능에 대한 고민
- 현재 API당 짧게 걸리는 APi는 50ms 부터 800ms 까지 다양합니다.
- 시간이 오래걸리는 애플 켈린더 동기화의 경우 비동기 처리를 하여 워커 쓰레드를 오랫동안 잡고 있는 상황을 방지하고자 합니다.
- 자주 발생하는 api의 경우 50ms부터 200ms 까지 걸리는데 이걸 고려할 경우 평균 0.125ms 정도 걸린다고 하면 125개정도의 워커 쓰레드가 필요합니다. 여유를 두기 위해 조금 더 여유롭게 설정한다면 워커 쓰레드의 갯수는 150~160개 정도로 설정하는게 좋을 거라 생각합니다.
- 디비 커넥션 역시 워커쓰레드와 비슷한 숫자로 설정을 하지만 가장 많이 발생하는 API인 개인 일정 조회를 캐시를 사용하여 디비와 통신하는 수를 줄이고자 합니다.
- 추가적으로
- 요청대기열은 TPS의 50~100퍼센트로 설정한다.
- 우리 서비스는 개인 캘린더 서비스이기 때문에 동시성을 크게 고려할 필요 없다. 따라서 스케일 아웃보다는 트래픽 증가시 스케일 업을 통해 서버 성능을 개선 시킬 예정입니다.
- AI서버와, 일절 시간을 계산하는 배치 서버, 푸쉬 알람 서버를 분리하여 서버의 책임을 분리하여 한개의 서버가 갖는 일을 최대한 분리할 예정입니다.
- 그리고 캘린더 서비스 이기 때문에 쓰기보다는 읽기 작업이 훨씬 많이 일어나기 때문에 개인 일정 같은경우 변경사항을 바로 적용하는 것이 아니라 캐쉬를 통해 저장후 일정 시간에 저장 사항을 반영하는 방식으로 데이터베이스와의 연결을 줄이고자 합니다.
