안녕하세요 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번 포트는 꼭 열어두셔야 해요 ! 추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~
안녕하세요 thrkrif님 ! 질문 잘 해주셨어요~ 결론부터 말씀드리면, yml에 server.port: 8081 로 고정해 두었더라도 서버를 여러 대 띄울 수 있습니다! Spring Boot는 설정값을 여러 곳에서 읽는데, 실행할 때 따로 넘겨준 값이 yml에 적힌 값보다 우선순위가 높아요. 그래서 yml은 그대로 두고, 실행할 때마다 포트만 다르게 넘겨주시면 됩니다 :) 1. jar로 실행하는 경우 java -jar consumer.jar --server.port=8082 java -jar consumer.jar --server.port=8083 2. 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처럼 외부에서 호출해야 하는 서버라면 위 방법들로 포트를 직접 지정해서 띄우시면 됩니다! 이 외로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~
안녕하세요 태경님 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! "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 연결은 그대로 진행하셔도 문제없어요:) 추가로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~
안녕하세요 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! "이전 테스트 보다 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 적용 전후의 성능 차이는 똑같이 확인하실 수 있을 거예요 :) 추가로 궁금하신 점 있으시면 언제든 편하게 추가질문 남겨주세요 ~~
안녕하세요! 좋은 피드백 남겨주셔서 너무 감사드립니다:) 올해 말이나 내년 초에 강의를 리뉴얼을 고민하고 있었는데 리뉴얼 강의를 할 때 말씀해주신 피드백 내용 꼭 반영해서 강의 구성해보도록 하겠습니다! 시간 내셔서 자세한 피드백 내용 남겨주셔서 다시 한 번 감사드립니다!!
