대규모 서비스의 특성 Elastic : 트래픽이나 상황에 따라서 서버의 추가 / 제거가 쉬워야 합니다. Resiliency : 특정 장비의 장애 등은 자동으로 복구되어야 합니다. 서버가 복구되는 것은 아닙니다. 해당 장비의 장애로 인해 다른 쪽이 영향 받지 않아야 합니다. Scale Up : 초당 1000 TPS 처리가 가능했다가 초당 3000 TPS 처리를 감당해야 한다면 3배(3000 TPS) 처리가 가능한 서버 1대로 교체 투입합니다. Scale Out : 초당 1000 TPS 처리가 가능한 서버를 3대 투입합니다. SPOF (Single Point Of Failure) 을 방지해야 합니다. 장애가 나면 서비스 전체를 마비시키는 병목 지점 어디를 확장해야 할까? API 서버에만 부하가 몰리는 작업은..
Redis (in Memory) Key에 대한 단위 연산이 빠릅니다. 하지만 여러 Key에 대한 연산은 느릴 수 있습니다. 메모리를 저장소로 쓰는 경우, 아주 빠른 Get과 Put을 지원합니다. 장점 Sharding / Replication 이 용이합니다. Speed (간단한 데이터 200만건을 1.28초에 저장합니다.) In-Memory 데이터 TTL(Time to Live), Expire 단점 Sharding을 클라이언트에서 잘 지정할 필요가 있습니다. Replication시 blocking (2.4 버전부터 non-blocking하면서 속도를 개선했습니다.)
RDBMS의 한계 Schema 문제: 빅 데이터를 RDB의 Schema에 맞춰 변경해서 넣으려면 매우 긴 시간의 Down Time이 발생합니다. Scale Up의 한계: RDBMS는 애초부터 Scale Out(분산 환경)을 염두에 두고 설계되지 않았습니다. NoSQL (Not Only SQL) 기본 RDBMS의 한계를 극복하기 위해 만들어진 새로운 형태의 DB입니다. 빅 데이터를 다룰 때, RDBMS로만 트래픽을 감당하기 어려워졌고, 이를 해결하기 위해 탄생했습니다. NoSQL은 분산 환경에서 대용량의 데이터를 빠르게 처리하기 위해 개발되었습니다. 핵심은 Horizontal Scalability(수평 확장)과 High Availability(고가용성)입니다. 특징과 장점 거대한 Map로서 Key-Valu..
- Total
- Today
- Yesterday
- synchronized
- auth
- MongoDB
- https
- cross
- 대규모
- class
- ehcache
- 404
- web
- cors
- stateless
- Runnable
- script
- redis
- ngrinder
- output
- Java
- SPOF
- stateful
- NoSQL
- HTTP
- Token
- URI
- Spring Boot
- Groovy
- iinput
- Cross Origin
- JWT
- thread
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |