42.Express의 3000번 포트 인바운드 설정이 왜 필요한지 궁금합니다.

안녕하세요 ladea1224님 ! 질문 잘해주셨어요 !질문해 주신 내용에 대해 답변드려볼게요 ~"외부의 요청은 nginx가 처리하고, 3000번 포트 접근은 내부에서만 이루어지는데 Express의 3000번 포트를 인바운드 설정 해 줄 필요가 있는건가요?"-> 정확하게 이해하셨어요 ! 결론적으로 실제 서비스를 운영할 때는 3000번 포트를 열어둘 필요가 없어요 ! Nginx가 proxy_pass http://localhost:3000/ 으로 요청을 넘길 때는 EC2 내부에서 통신하는 거라 보안그룹(인바운드 규칙)을 거치지 않거든요 !그럼에도 수업 자료에서 3000번 포트를 열어준 이유는 "테스트" 목적이에요 !Express 포트를 80번에서 3000번으로 바꾼 직후에 http://:3000 으로 직접 접속해서 Express 서버가 3000번에서 잘 떠 있는지 먼저 확인하기 위해서예요 !이렇게 해두면 나중에 HTTPS 연결이 안 될 때 Express 쪽 문제인지, Nginx·Certbot 쪽 문제인지 나눠서 확인하기가 훨씬 쉬워지거든요 :)그래서 Nginx 리버스 프록시 설정까지 끝내고 https:// 로 잘 접속되는 걸 확인하셨다면, 보안그룹에서 3000번 인바운드 규칙은 지워주시는 걸 추천드려요 !그래야 외부에서 Nginx를 거치지 않고 Express에 바로 붙는 길이 막혀서 더 안전해요 ~대신 Nginx가 받는 80번, 443번 포트는 꼭 열어두셔야 해요 !추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

[실습] 웹 프론트엔드 프로젝트(HTML, CSS, JS) 배포하기 - 403 Forbidden 오류 관련 질문

안녕하세요 경태님! 해결하셨다니 다행이네요ㅎㅎ또 수업 들으시다가 막히는 포인트 생기시면 질문 남겨주세요~~

30강

안녕하세요 thrkrif님 ! 질문 잘 해주셨어요~결론부터 말씀드리면, yml에 server.port: 8081로 고정해 두었더라도 서버를 여러 대 띄울 수 있습니다!Spring Boot는 설정값을 여러 곳에서 읽는데, 실행할 때 따로 넘겨준 값이 yml에 적힌 값보다 우선순위가 높아요. 그래서 yml은 그대로 두고, 실행할 때마다 포트만 다르게 넘겨주시면 됩니다 :)1. jar로 실행하는 경우java -jar consumer.jar --server.port=8082java -jar consumer.jar --server.port=80832. IntelliJ에서 실행하는 경우Run/Debug Configurations에서 기존 실행 설정을 복사(Copy Configuration)한 뒤에Program arguments에 --server.port=8082 (또는 VM options에 -Dserver.port=8082)를 넣어 주세요.설정을 포트별로 하나씩 만들어 두면 각각 따로 실행할 수 있어요.(Spring Boot 실행 설정이면 Modify options > Allow multiple instances를 켜고 같은 설정을 여러 번 실행하는 방법도 있는데, 이때는 포트가 겹치니 위처럼 설정을 나눠 두시는 걸 추천드려요!)3. 환경변수로 넘기는 경우SERVER_PORT=8082 java -jar consumer.jar참고로 강의에서 port: 0을 쓴 이유는, 이렇게 서버마다 포트를 일일이 지정하지 않아도 빈 포트를 알아서 잡아 주기 때문이에요.Consumer 서버는 외부에서 HTTP 요청을 받을 일이 없어서 포트 번호가 몇 번인지 중요하지 않거든요 ~ 반대로 API처럼 외부에서 호출해야 하는 서버라면 위 방법들로 포트를 직접 지정해서 띄우시면 됩니다!이 외로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~

intellij나 파이참 기준 어떻게 하는지 궁금합니다

안녕하세요 태경님 ! 질문 잘 해주셨어요~질문해주신 내용에 대해 답변드려볼게요!"webstorm 환경에서 해주셨는데 인텔리제이, 파이참 ide에서도 역시 실행이 가능할까요? github-actions-basic -> .github(패키지?) -> workflows? -> deploy.yml???"-> 네! IntelliJ, PyCharm에서도 똑같이 가능해요 !Github Actions는 내 컴퓨터의 IDE에서 실행되는 게 아니라, 코드를 Github에 push했을 때 Github 서버(runs-on: ubuntu-latest)에서 실행되는 방식이에요 ! 그래서 어떤 IDE를 쓰시든 상관없이 정해진 위치에 yml 파일만 만들어서 push하시면 돼요 :)그리고 구조는 정확하게 이해하셨어요! 다만 .github는 패키지가 아니라 일반 폴더(디렉터리)에요 !프로젝트 최상단(github-actions-basic)에서 마우스 우클릭 → New → Directory를 선택하고 .github/workflows 라고 입력하시면 두 폴더가 한 번에 만들어져요 !그 다음 workflows 폴더에서 우클릭 → New → File을 선택해서 deploy.yml 파일을 만들어주시면 됩니다~~참고로 .github/workflows 폴더를 src 폴더 안처럼 다른 위치에 만들면 Github Actions가 인식하지 못하니, 꼭 프로젝트 폴더 최상단에 만들어주셔야 해요 :)추가로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~

후속강의 쿠폰

안녕하세요 merci j님! 질문 잘 해주셨어요~ 후속 강의 쿠폰은 기재해주신 휴대폰 번호의 문자 또는 카카오톡으로 발송될 예정입니다! 다만, '후속 강의'는 추후에 새로 출시되는 강의를 의미하기 때문에새로 강의가 출시 될 때 새로운 강의의 쿠폰을 제공해드리고 있습니다. 만약 기존에 나와있는 강의의 쿠폰을 받고 싶으신 거라면 블로그 리뷰 이벤트에 참석해주셔야 합니다! 이 외로 궁금하신 점 있으시면 편하게 질문 남겨주세요~

선생님 질문있습니다!

안녕하세요 ! 질문 잘 해주셨어요~질문해주신 내용에 대해 답변드려볼게요!"우려스러운건 그럼 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 관련 강의 개선 제안

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