선생님 질문있습니다!

안녕하세요 ! 질문 잘 해주셨어요~질문해주신 내용에 대해 답변드려볼게요!"우려스러운건 그럼 DB에는 어떻게 언제 저장해야하나요?"-> 우선 정리해주신 의사코드가 정확합니다!검색할 때마다 DB에 UPSERT하고 매번 정렬해서 조회하던 걸, Redis의 Sorted Set으로 옮겨서 처리하는 게 핵심이에요 !강의에서는 Sorted Set 활용에 집중하기 위해 Redis에만 저장하도록 구현했는데요,DB에도 데이터를 남겨야 한다면 앞에서 배운 '좋아요 수 폭증' 실습의 Write Back 전략을 응용하시면 돼요 ~검색 요청이 들어오면 Redis의 Sorted Set에만 score를 올려두고, 스케줄러가 주기적으로 Redis에서 키워드와 score를 조회(ZRANGE … WITHSCORES)해서 DB에 한꺼번에 반영하는 방식이에요 !이렇게 하면 검색할 때마다 DB에 쓰기 작업이 발생하지 않으면서도, Redis에 문제가 생겼을 때를 대비해 데이터를 DB에 남겨둘 수 있어요 ! 참고로 인기 검색어처럼 실시간성이 중요하고 일부 유실돼도 치명적이지 않은 데이터라면, DB에 저장하지 않고 Redis만으로 운영하는 경우도 많죠 !그래서 검색 기록을 통계 등으로 계속 활용해야 하는지에 따라 DB 저장 여부를 결정하시면 좋을 것 같아요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

강의 영상이 나오질 않습니다...

해결되셨다니 다행입니다! @구피 빠르게 처리해주셔서 감사합니다:)

안녕하세요 도커실행과 관련해서 질문드립니다.

안녕하세요 ! 질문 잘 해주셨어요~질문해주신 내용에 대해 답변드려볼게요!우선 올려주신 docker version 결과를 보면 Client와 Server(Engine 29.7.2)가 모두 정상적으로 잡혀있네요 !도커 설치나 실행 자체에는 전혀 문제가 없는 상태라서 삭제 후 재설치는 안 하셔도 괜찮아요 ~"도커를 실행하면 이런 알림창이 계속 무한반복되는데 무엇이 문제인가요?"-> 도커가 아니라 WSL의 GUI 기능(WSLg) 때문에 뜨는 알림창이에요 !윈도우에서 Docker Desktop은 WSL2 위에서 동작하는데, WSL2가 켜질 때 리눅스 GUI 프로그램을 윈도우 화면에 띄워주는 WSLg라는 기능도 같이 실행돼요 ~그런데 이 WSLg가 내부적으로 윈도우의 원격 데스크톱(RDP)을 사용해서 화면을 전달하는 구조라, 윈도우의 원격 데스크톱 관련 파일(rdclientax.dll)에 문제가 있으면 지금처럼 Remote Desktop / RemoteApp 알림창이 뜨게 돼요 !도커를 쓰실 때는 WSLg가 필요 없어서 꺼주시면 깔끔하게 해결될거에요 !파일 탐색기 주소창에 %USERPROFILE% 을 입력해 들어가신 뒤, 그 폴더에 .wslconfig 파일을 만들어 [wsl2] 를 적고 아래 줄에 guiApplications=false 를 적어서 저장해주세요 ! 그 다음 cmd에서 wsl --shutdown 을 입력하고 Docker Desktop을 다시 실행해보시면 돼요~참고로 이 알림창과 별개로 도커는 지금 정상 동작하고 있어서, n8n 연결은 그대로 진행하셔도 문제없어요:)추가로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~

Request Failed 가 뜹니다.

안녕하세요 ! 질문 잘 해주셨어요~질문해주신 내용에 대해 답변드려볼게요!"이전 테스트 보다 20배정도 처리속도가 개선된건 확인했으나 실패율이 계속 뜨는건 OS차원의 문제일까요? (OS는 Windows 입니다)"-> 추측하신 대로 코드나 Redis 쪽 문제가 아니라 로컬 환경의 한계 때문에 발생하는 현상이 맞아요 ~connectex: No connection could be made 에러는 서버가 죽어서 나는 게 아니라, 톰캣이 미처 처리하지 못한 연결 대기열이 꽉 차서 OS가 새로 들어오는 연결을 거절할 때 나오는 에러에요 !가상 유저 1000명이 한 대의 노트북에서 동시에 연결을 맺다보니 부하 생성기(k6)와 서버가 같은 머신의 네트워크 자원을 나눠쓰게 되는데, 윈도우는 동시에 쓸 수 있는 포트 수나 연결 대기열이 맥/리눅스보다 여유가 적은 편이라 이런 에러가 조금 더 자주 보이는 편이에요 ~그리고 올려주신 테스트 결과를 같이 보시면 더 명확한데요, 실패한 요청 수 자체는 Redis 적용 전이 1046건, 적용 후가 1103건으로 거의 똑같아요 ! 전체 요청 수만 17,619건에서 333,202건으로 늘어나서 실패율이 5.93%에서 0.33%로 떨어진 것이구요~처리량이 20배 늘었는데도 실패 건수는 그대로라는 건, 애플리케이션 로직이 아니라 로컬 환경이 감당할 수 있는 동시 연결 수의 한계에 걸렸다는 신호로 볼 수 있어요 !이번 실습의 목적은 Redis 적용 전후의 TPS를 비교해보는 것이기 때문에, 이 에러는 무시하고 그대로 진행하셔도 괜찮아요 ~그래도 신경쓰이신다면 스크립트의 vus 값을 300~500 정도로 낮춰서 한 번 돌려보세요 !실패율이 0에 가깝게 나오면서도 Redis 적용 전후의 성능 차이는 똑같이 확인하실 수 있을 거예요 :)추가로 궁금하신 점 있으시면 언제든 편하게 추가질문 남겨주세요 ~~

S3 관련 강의 개선 제안

안녕하세요! 좋은 피드백 남겨주셔서 너무 감사드립니다:)올해 말이나 내년 초에 강의를 리뉴얼을 고민하고 있었는데리뉴얼 강의를 할 때 말씀해주신 피드백 내용 꼭 반영해서 강의 구성해보도록 하겠습니다! 시간 내셔서 자세한 피드백 내용 남겨주셔서 다시 한 번 감사드립니다!!

env 파일을 제대로 작성한 후에도 사이트에 연결할 수 없습니다.

안녕하세요 kjm5880님! 질문이 누락돼 빠르게 확인하지 못해서 뒤늦게 답변 남기게 된 점 죄송합니다ㅠㅠ! 아직 해결이 안 되셨다면 아래 링크로 질문 주시면제가 같이 디버깅 도와드리겠습니다!! https://open.kakao.com/o/sLAt7ORh

S3 강의 개선 제안

안녕하세요 xiest님! 말씀해주신 내용을 꼼꼼히 전부 다 읽어봤습니다! 이렇게 정성스럽게 시간을 들여서 피드백 남겨주셔서 너무 감동이네요🥹 작성해주신 내용을 읽어보니 말씀해주신 대로 보완해야 할 필요가 있다고 느껴지네요! 공교롭게도 올해 말 또는 내년 초에 지금까지 만든 강의를 전부 개선을 할 예정이었는데말씀해주신 내용을 반영하면 너무 좋겠다는 생각이 드네요ㅎㅎ 리뉴얼 강의를 제작할 때 말씀해주신 내용도 꼭 포함해서 제작하도록 하겠습니다!! 시간내서 꼼꼼하게 피드백해주셔서 정말 감사드립니다:D

키페어 설정

안녕하세요 ! 질문 잘 해주셨어요~질문해주신 내용에 대해 답변드려볼게요!"이런 키페어 설정은 어떻게 해야하나요?"-> 강의에서는 EC2에 접속할 때 EC2 Instance Connect(AWS 콘솔에서 브라우저로 바로 접속하는 방식)를 사용하기 때문에 키 페어가 없어도 실습하시는 데 전혀 문제가 없어요 ! 그래서 "키 페어 없이 계속 진행"을 선택하시고 인스턴스 시작 버튼 눌러주시면 돼요 ~다만 나중에 터미널에서 SSH로 직접 접속해보고 싶으시다면 그 때는 키 페어가 필요해요 !그런 경우엔 "새 키 페어 생성"을 선택하시고 이름은 편하게 지어주신 뒤에 키 페어 유형은 RSA, 프라이빗 키 파일 형식은 .pem 그대로 두고 생성하시면 돼요 ~이 때 다운로드되는 pem 파일은 나중에 재발급이 안 되니 안전한 곳에 잘 보관해두세요 :)추가로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~

api.basic-server.com

안녕하세요 ! 질문 잘 해주셨어요~해결되셨다니 다행이네요ㅎㅎ말씀해주신 방식이 정확한 방향이에요 !Route 53 호스팅 영역에 자동으로 생성된 네임서버 주소가 기준이 되고, 도메인 등록기관 쪽 네임서버를 그 값에 맞춰 수정해주셔야 정상적으로 연결돼요 ~반대로 Route 53의 NS 레코드를 건드리시면 오히려 꼬이게 되니 이 부분만 기억해두시면 좋을 것 같아요~~참고로 네임서버를 변경하고 나면 전 세계 DNS에 반영되는 데까지 시간이 조금 걸려요 ! 보통은 10~30분이면 되지만 길게는 몇 시간까지 걸리기도 해서, 설정을 제대로 하셨는데도 바로 접속이 안 되는 것처럼 보일 때가 있어요 ~그러니 다음에 비슷한 상황이 생기면 설정을 지웠다 다시 만들기보다는 조금 기다려보신 뒤에 확인해보시는 걸 추천드려요:)고생 많으셨구 추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

p.created_at vs u.name 인덱스 문의

안녕하세요 태경님 ! 질문 잘 해주셨어요~질문해주신 내용에 대해 답변드려볼게요!"join시 인덱스 방식이 달라지는지 궁금합니다."-> 조인이라서 달라진다기보다는, 그 쿼리에서 어떤 조건이 데이터를 가장 많이 걸러주느냐에 따라 인덱스 걸 위치가 달라진다고 보시면 돼요 ! 조인에서는 MySQL이 한 테이블을 먼저 읽고 그 결과 건수만큼 반대편 테이블을 찾아가기 때문에, 먼저 읽는 테이블의 결과를 최대한 줄이는 게 핵심이에요 ! 유저 이름은 동등 조건(=)이라 범위 조건인 created_at보다 훨씬 적은 행으로 좁혀지다보니 u.name에 인덱스를 거는 게 효과적이었던 거죠 ! EXPLAIN으로 어떤 테이블이 먼저 읽히는지 직접 확인해보시면 훨씬 이해가 잘 되실 거예요 :)"또, 다른 곳에서 파티셔닝, 클러스터링?? 이라는 용어들도 보이던데 이것도 인덱스에서 파생된 것일까요?"-> 인덱스에서 파생된 건 아니고 별개의 기술이에요 ! 파티셔닝은 큰 테이블을 특정 기준으로 쪼개 저장해서 필요한 조각만 읽게 하는 방식이구요, 클러스터링은 InnoDB에서 PK 기준으로 데이터가 정렬되어 저장되는 걸 뜻하기도 하고 DB 서버를 여러 대 묶는 걸 뜻하기도 해요 ! 다만 지금 단계에서는 굳이 파고들지 않으셔도 괜찮아요ㅎㅎ 인덱스 감부터 확실히 잡으신 뒤에 보셔도 늦지 않아요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~