목표: DB부하 최대한 안주면서 많은 트래픽 감당하기
웹서버 3대, WAS 3대, NAS 1대, DB 1대 있음
WAS는 rest api 서버들임. 심플하게 /posts/{postId} 로 요청하면 해당 게시글 데이터를 DB에서 꺼내서 json으로 리턴해줌.
웹서버는 api서버로부터 데이터를 받아서 페이지를 클라이언트에게 내려줌.
웹서버 한대와 WAS서버 한대는 관리자 전용임.
이곳에서 posts를 조회 등록 수정 삭제 할 수 있음.
DB와 NAS는 각각 1대씩인데 더 늘릴순 없음.
이 상황에서 두가지 방법이 논의됨.
1. 관리자서버에서 posts를 생성할때 데이터를 DB에 저장하고 NAS에도 json파일로 저장함. 웹서버에서 API서버로 요청하면 API서버는 NAS에 접근해서 json 읽어오고 값 리턴. 웹서버는 요청 받아서 페이지 랜더링. 이후 관리자가 데이터 업데이트하면 NAS에 있는 json파일도 동시에 업데이트하면서 최신화 유지.
2. 관리자서버에서 posts를 생성. 웹서버에서는 클라이언트의 요청이 오면 API 호출하고, API는 DB로부터 데이터를 받아와서 렌더링. 해당 데이터는 API서버에 캐싱처리해둠. 관리자가 데이터를 수정하게 되면 rabbit mq 이용해서 API서버들에게 캐싱초기화하라고 전달해서 데이터 최신화 유지.
1번의 경우에는 API서버가 꼭 필요한가? 하는 생각이 들었음. 어차피 관리자서버에서 생성하고 바로 NAS에 저장되는거면, API서버 통해서 json파일 가져올게 아니라 그냥 웹서버에서 NAS에 바로 접속해서 가져오는게 낫지않나 생각이 들었기 때문임.
2번의 경우에는 캐싱해야하는 데이터가 많아지면 api 서버에 부하가 심해지지않을까 하는 생각이 들었음.
초보 개발자에게 조언 부탁드림 (- -)(_ _)
코드 좀 보여주셈
코드는없음 머리속 구상중임
db를 늘림
늘릴수없음 이세상에 마지막으로 남은 DB 하나임
딱국추
그대로 챗GPT한테 한번 물어봐봐
시원한 답변이 안나옴
NAS의 접근후 JSON억세스 같이 디스크에서 읽는 건 Seek 타임도 있고해서 딜레이가 있을 수 밖에 없음. 요즘엔 SSD쓰고 SSD 자체에서도 캐싱하니까 좀 빠르긴 하겠다만 정석적인 방법은 아님. 이럴때 캐싱용으로 Redis를 사용하는데, 네트워크로 서버 여러대가 동시 접속가능한 해시테이블이라고 생각하면 됨. 디스크에 저장하는 방식이 아니라 램에 들고 있다가 주는거니까 메모리캐싱임. nas에 저장된 json 의 경로를 key 값으로 내용을 redis에 넣은후 파싱해서 쓰는게 지금 구조에서 가장 간단하게 바꿀수 있는 것 같음.
redis 쓸수있으면 좋겠는데 설치하지말래용 캐싱보다 그냥 나스짬처리가 성능이 나을까요?
redis를 설치하지말라라... 도망쳐야되겠는데?