rds에 db 인스턴스 크기가 없는데 어떤 걸 선택하면 될까요?

안녕하세요~! 그 사이에 UI가 바뀌어 버린것 같습니다. 가장 기본 스펙으로 선택하면 될것 같아요. 선택해주신걸로 진행하시면 될것 같습니다.

openjdk:17-jdk-alpine이 docker hub에서 삭제된 거 같습니다.

엇... 그사이에 삭제가 됐나보군요. 내용 공유 감사합니다~!

실무에서 Redis에서 0번 이외의 DB를 사용하나요?

안녕하세요~ 제가 드린 설명은 single 레디스 기반으로 설명을 드리다보니 db를 나누어 데이터들을 저장한다고 설명했습니다.다만 , 많은 실무 시스템에서는 redis 인스턴스를 여러개 두거나 클러스터모드로 구성합니다. 그경우엔 db자체를 나누기보다는 0번 디비를 쓰면서 redis인스턴스 자체를 확장해서 인스턴스1번에 인증, 인스턴스2번에 캐싱 이렇게 사용하는게 더 일반적인것 같습니다.

초기 클러스터 생성시 나타나는 오류

안녕하세요~!아마도 VPC나 서브넷 관련한 원인일 가능성이 커보입니다.혹시, default vpc 또는 default 서브넷을 삭제했다가 다시 만들었다거나, eks생성시 vpc, 서브넷의 default값이 잘 선택됐는지 확인한번 부탁드립니다.

StompHandler 관한 질문

안녕하세요~! 좋은 질문 주셔서 감사합니다. 일단, StompHandler 레벨에서 SecurityContextHolder를 사용하여 인증객체를 꺼내는건 불가능합니다. Http요청이 아니기 때문에 FilterChain레벨에서 인증객체가 만들어져 있지 않습니다. 그래서, pricipal 즉, id또는 email을 꺼내고 싶다면 token에서 파싱해서 꺼내주시면 될것 같습니다.

실시간 서비스 관련 질문

안녕하세요~!! 말씀해주신것처럼 실시간으로 채팅이 쏟아지는데 동기적으로 db에 업데이트 작업을 하는건 부하가 크고 응답속도가 느려질수도 있을것 같습니다. 일단 이 부분 관련해서는 수업에서는 고도화가 되어있지는 않습니다. redis는 해당 이슈관련 외의 목적으로 사용돼요. 이경우 실전에서는 여러 대안을 고민을 해볼수 있을겁니다. 그중에 카프카를 도입해서 비동기적으로 읽음여부를 업데이트하는게 가장 현실적인 대안이 될것 같습니다. 읽음여부를 관리하려면 db부하가 없을순 없겠지만, 비동기처리로 인해 성능을 향상시킬수 있을것 같습니다. 레디스를 쓸수도 있겠지만 레디스에 올려두기에는 데이터규모가 너무 클것 같다는 생각이듭니다.

3강 spting 빌드환경에서 mysql 부분 질문있습니다.

혹시 현재 코드가 어떻게 구성돼있는지 캡쳐가능할까요? 포스트맨 테스트도 어떻게 진행한건지 캡쳐 한번 부탁드립니다.

S3 업로드 역할 부여 질문 드려요

안녕하세요~! EC2에 S3 접근 권한을 부여했다고 하셨는데, 혹시 application.yml이나 환경 변수에서 S3 접근 키를 설정하지 않고, EC2 인스턴스 자체에 IAM Role을 부여하신 것인가요? 일반적으로는 Spring Boot 애플리케이션이 직접 S3 접근 권한을 가진 IAM 사용자의 자격 증명(accessKey, secretKey) 을 가지고 S3에 접근하게 됩니다.그래서 EKS를 통해 배포된 Pod 환경에서도, Pod나 EC2 차원에 IAM Role을 직접 부여하는 것이 아니라, Spring Boot 애플리케이션이 자체적으로 해당 자격 증명을 이용해 S3에 접근하는 방식을 사용하는 것이 일반적입니다. 그렇게 하게 되면 EC2든, EKS의 POD이든 따로 고민하실것 없이 동일하게 springboot에 iam설정만 해주면 됩니다.

수업 자료는 어디서 확인 가능한가요?

안녕하세요 성우님. 강의소개에 링크가 있습니다~!

실무에서의 복잡한 쿼리 결과 캐싱 전략(크기, TTL 등) 관련 질문

안녕하세요 지니님. 일단 좋은 질문 주셔서 감사합니다. 말씀해주신 사례를 들어보니, 아마도 조회 데이터의 결과값이 단건이 아니라 목록(list)였을것으로 생각됩니다. 단건 데이터가 아닌경우엔 일반적으로 캐싱처리하기에는 부적절하다고 생각합니다. 통상적으로 목록상의 데이터는 빈번히 변경될 여지가 있으므로, 보통은 단건의 데이터에 한해 캐싱처리를 한다고 보시면 됩니다. 다만, 말씀해주신 사례처럼 변경이 빈번하지 않을것으로 생각된다고 말씀하셨으니, 그 경우에는 전체 데이터가 아닌 핵심 데이터 요약결과 정도만 캐싱처리하는게 적절하다고 생각합니다. 이 경우에도 데이터의 변경가능성을 충분히 고려하여 캐싱처리를 해주셔야 할것 같습니다.