오토스케일아웃이 가능한 REST API 서버가 있고, 인메모리 DB 를 사용하게 되었다고 가정
인메모리 DB는 속도가 빠른게 장점인데
인스턴스마다 인메모리 DB 를 하나씩 두자니 스케일아웃 되면 디비간에 데이터 공유가 안되고
인메모리 DB 만 돌리는 인스턴스를 두자니 네트워크를 타서 속도가 느릴텐데
이놈은 오토스케일아웃이 필요한 환경에서 어떤 식으로 사용하는거임?
오토스케일아웃이 가능한 REST API 서버가 있고, 인메모리 DB 를 사용하게 되었다고 가정
인메모리 DB는 속도가 빠른게 장점인데
인스턴스마다 인메모리 DB 를 하나씩 두자니 스케일아웃 되면 디비간에 데이터 공유가 안되고
인메모리 DB 만 돌리는 인스턴스를 두자니 네트워크를 타서 속도가 느릴텐데
이놈은 오토스케일아웃이 필요한 환경에서 어떤 식으로 사용하는거임?
WAS 인스턴스들은 똑같은 db 인스턴스에 연결하고 db는 replica 설정 - dc App
N개의 인스턴스를 하나의 db 인스턴스에 연결한다는 말? 하나에 연결하는데 레플리카가 왜필요함? 아니면 앞의 db는 인메모리 db고 뒤에 db 는 디스크 db를 말하는건가
Read only로 Replica 만들어서 메인 DB 부하 분산용도 AWS에 레디스 쓰면 ElasticCache 설정하면 됨 - dc App
db 를 레플리케이션 하지 않고 별도로 분리하고 db 서버도 스케일아웃이 가능하게끔 하는 경우는 없음?
추가로, 이것저것 찾아보고 나서 드는 생각인데 사용하는 클라우드 플랫폼에서 로드밸런서를 제공을 안하면 오토스케일링 자체가 불가능하거나 아주 까다로워보이는데 맞음? 그렇게 생각한 근거 1. 인스턴스가 어떤 주소에 생성될지도 모르므로 2. 주소를 안다 해도, 마스터(?)서버에서 트래픽을 감지하고 늘리고 자체 로드밸런서를 수정하고 하는 등의 작업이 아주 까다로움
DB를 레플리케이션 하지 않고 분리하고 스케일 아웃이 가능하게끔 한다는게 뭔 말인지 잘 모르겠는데 RDB나 인메모리 DB는 스케일 아웃 보통 안하는걸로 앎 인메모리 DB는 거의 캐싱용도로 쓰니까 인스턴스끼리 공유하고
글고 AWS 같은 경우에는 EC2에 웹 애플리케이션 서버 올리고 RDB는 Amazon RDS 같은거 따로 씀 웹 애플리케이션 서버랑 DB 서버 분리하는게 일반적임
말을 좀 이상하게 했네
별도로 분리 라는 말은 db를 서버앱이랑 같은 인스턴스에서 돌리는게 아니라 외부 인스턴스로 빼거나 외부 디비 서비스를 사용하는 경우를 말한거였음
인메모리 디비는 네트워크를 타도 빠름
그런게 어떻게 가능함? 뭐라 찾아봐야함? 인메모리디비 네트워크 지연 이런걸론 안나오는데
디스크 탐색 + 네트워크 vs 메모리 탐색 + 네트워크 인데 여기서 네트워크 속도는 고정에 제일 느린놈 아닌가
아.. 인메모리 디비구나 메모리 디비로 착각함 인메모리 디비는 애초에 공유용이 아냐
디스크 탐색은 생각보다 느리고 인덱스 구조도 문제임 네트워크는 당연히 최대한 빠르게 구성해야지 물리적 위치도 가까워야하고
인메모리DB == 메모리DB 가 아니야? 검색하면 똑같은것만 나오는디
네트워크 지연을 감안해도 많이들 사용하는거보면 진짜 유의미하게 빠르긴 한가보네
어플리케이션의 jvm 메모리를 이용하는게 인메모리고 메모리는 레디스같은거 말하는거 맞나?
음.. 내가 용어를 잘못알았네 내가 겪어본 팀들에서는 보통 h2같은걸 테스트용 인메모리 디비라고 했고 레디스는 메모리 디비라고 했거든 ㅋㅋ
인메모리 디비라는 단어 자체가 엄격한 단어가 아닌듯 암튼 레디스는 빠르지, 메모리에서 읽기도 하고 시간복잡도도 달라
그럼 다시 돌아가서 1. 인메모리 디비는 네트워크 속도를 감안하더라도 충분히 빠르고 2. 공유가 필요한 경우에는 별도 서비스(엘라스틱캐시)나 인메모리디비용 인스턴스를 만들어 접근한다 가 맞아?
애초에 초대량의 데이터를 상정한 구조가 아님 저장소와 자료구조 자체가 속도만을 위한거
맞어
ㄱㅅㄱㅅ 궁금한게 좀 해소되었음 추가로, 메세지큐나 이벤트큐(카프카 같은 애들)도 별도 인스턴스로 분리하고 스케일아웃 가능한 서버앱에서 접근해서 사용하도록 만들면 되는거야??
질문이 좀 그런가? 상황에 따라 다를 수 있는 부분인가
일반적으로는 그러함
ㅇㅎ~~이제 조금은 알겠네