Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- 해킹
- kafka
- FCM
- Spark
- n-gram
- 알림무시
- Core/Context
- 파이어베이스
- 웹보안
- bag of words
- 이미지 푸시
- Slack Rate Limit
- firebase
- 자연어처리 #konlpy #형태소분석
- 슬랙
- 카프카
- 머신러닝
- 스카우터
- Rate Limit
- Slack Limit
- 팀 발달 모델
- 카프카 성능
- 슬랙 파일업로드 제한
- Scouter
- 코어/컨텍스트
- 슬랙 파일업로드
- Scale Cube
- Tuckman
- Slack File Upload
- 스케일 큐브
Archives
- Today
- Total
목록스케일 큐브 (1)
플랫폼 개발팀 기술 블로그
The Scale Cube (규모 확장성 모델)
INTRO일정 규모 이상의 정보 서비스를 제공하고 있다면, 아마도 대부분 한대 이상의 서버를 배치하여 부하분산을 시키고 있을 것입니다. 이런 배치 전략을 로드밸런싱이라고 하죠. 로드밸런싱은 대량의 트래픽을 수용하기 위해 여러대의 (동일한) 서버가 요청을 나눠서 처리하도록 하는 부하분산을 통해 서비스의 처리량을 증가 시키고자 하는 것이 주 목적입니다. 물론 로드분배 알고리즘과 서버 상태를 기반으로 해서 고가용성(HA)의 요건도 같이 충족되는 것이 일반적입니다. 만일 트래픽이 점점 더 늘어난다면, 그에 맞춰 Service #4, Service #5, ... 이런식으로 서비스의 복제본을 늘려 나가기만 하면 되기 때문에 손쉽게 확장이 가능합니다. 애플리케이션의 확장성을 보장하기 위해서는 다양한 전략을 구사할 수..
Article
2019. 2. 22. 14:51