클라우드, 인프라22 트래픽 증가 대응 고려 트래피 증가 대응 고려 비용 장비를 무턱대고 늘릴순 없음 무턱대고 기술을 막 쓸순 없음 복잡도를 막 증가시켜 해결해야할 수준의 트래픽은 아님 db부하 줄이기 db로 가는 트래픽 감소시키기 인메모리 캐시 확대 변경이 적은/ 없는, 규모가 작은 데이터 DB크기 증가율 줄이기 고객사로 가는 트래픽 감소시키기 방법 고민 -외부 메모리 캐시 적용(레디스) 외부 조회 데이터 미리 넣기(변경이 적은/없는) 푸시 제어 -고객사별 푸시 발송 속도제어, 확대 적용 외부메모리 캐시 적용-외부 조회 데이터 미리넣기(변경이 적은/없는) 푸시제어 - 고객사별 푸시 발송 속도 제어, 확대적용 -고객사들의 상태를 봐가면서 적용 특정 기능단위로 트래픽을 제한하거나 서킷브레이커를 적용 응답시간이 일정횟수 이상 느려지면 에러 응답을 내뱉.. 2024. 1. 10. Consitent hashing https://www.youtube.com/watch?v=rFUjE0mTimw vNode나 닉네임 등을 사용하는 것은 흥미로운 내용이었고 확장적인 서버에서 처리를 어떻게 해야하는지 배울 수 있었던 시간이었습니다. 좋은 내용을 설명해주신 DaeMyung Kang 님께 감사드립니다! 2022. 7. 30. 레디스- 키의 개수가 많을때 저장/활용 법 레디스에 40만~1백만 개 정도의 키를 저장할 일이 생겨 고민하게 되었습니다. 일단 팀장님은 메모리에 직접 내용을 저장하는 게 어떠냐고 하셨는데, redis가 쿠팡, 배민 등 굉장히 많은 데이터를 사용하는 곳에서도 활용되고 있고 속도 문제가 없는 것으로 알고 있기 때문에 이미 어느정도 구현되어 있는 레디스를 버리고 메모리에 이러한 데이터를 적재하기 위해 IMDG나 memcache를 활용하기는 불필요할 수 있다 생각하였고, 다른 회사들에서는 많은 키를 저장하기 위해서는 어떻게 하는지가 궁금해 찾아보았고 해쉬를 활용하는 방법이 있다는 것을 알게되었습니다. 인스타그램에서 작성한 글에 따라 내용을 파악해보았는데요, 예를 들어 백만개의 데이터를 저장하기 위해서는 10000으로 나누고 몫을 버켓으로, 그리고 해당 .. 2022. 6. 16. IMDG (In Memory Data Grid) https://d2.naver.com/helloworld/106824 2022. 6. 16. 이전 1 2 3 4 5 6 다음