일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- IntellJ
- 스트림
- Collection
- 자바
- gradle
- OS
- thread
- 토비의 스프링 정리
- mysql
- 자바 ORM 표준 JPA 프로그래밍
- 토비의 스프링
- list
- 이스티오
- 보조스트림
- jvm
- GC
- spring
- 백준
- K8s
- 스프링
- 쿠버네티스
- Kotlin
- Stack
- Java
- Stream
- Real MySQL
- MSA
- JPA
- redis
- SpringBoot
- Today
- Total
목록session (2)
인생을 코딩하다.
프로젝트를 scale out 방식으로 확장할 계획을 하면서 그에 따른 session의 정합성에 관한 이슈가 생겼습니다. 별도의 독립적인 session 저장소로 세션의 정합성 문제를 해결하기 위해서는 대표적인 redis와 memcached 데이터 베이스를 고려해볼 수 있습니다. Amazon ElastiCache는 Memcached 및 Redis 캐시 엔진을 지원합니다. 각 엔진에는 몇 가지 장점이 있습니다. 이 항목의 정보를 활용하면 요구 사항에 가장 잘 맞는 엔진과 버전을 선택하는 데 도움이 됩니다. Memcached와 Redis 엔진은 둘 다 인 메모리 키-값 저장소입니다. NoSql 데이터베이스라고도 할 수 있죠. 그러나 실제로 상당한 차이점이 있습니다. session의 정합성 이슈를 해결하기 위해서..
프로젝트에서 세션 로그인 기능을 만들었습니다. 그리고 추후 저는 대용량 트레픽을 감당할 수 있는 서버를 만들 계획이 있었습니다. 대용량 트레픽을 감당할 수 있는 서버를 만들기 위해 scale up을 고려해 서버를 한 대만 놓는다면, 서버 한 대에 모든 부하가 집중되므로 장애 시 서버가 복구될 때까지 서비스를 중단해야 하는 상황이 발생합니다. 사용하려던 서비스가 중단된다면, 그에 안좋은 기억이 생기고 타 서비스로 이용을 바꾸거나, 서비스를 사용하지 않을 수 있는데, 이것은 엄청난 비즈니스 손실(수익 손실)이 생길 수 있습니다. 그러기 위해선 scale out을 고려해 서버를 확장해야 했습니다. 하지만 서버 확장시 제가 만든 세션 로그인 기능에 문제가 생길 우려가 있었습니다. 이 문제는 아래에서 그림과 함께..