서버 인프라 관련 질문 (2)

안녕하세요! 강의 잘 들어주셔서 감사합니다 :)노션 문서까지 체계적으로 정리해주신 거 보니 정말 깊게 고민하신 게 느껴지네요 ~질문 너무 잘해주셨어요 ! 질문해 주신 내용에 대해 하나씩 답변드려 볼게요 ! 먼저 결론부터 말씀드리면 현재 구상하신 아키텍처는 전혀 문제없고, 비용도 비정상적이지 않아요 ~ 오히려 실무 경험을 쌓기 위한 프로젝트 목적에 잘 맞는 구조예요 !다만 단계별로 좀 더 효율적으로 접근하실 수 있는 방법을 제안드려 볼게요 !우선 1단계 개발 중에는 현재 구상하신 대로 t4g.small EC2 내부에 Spring Boot, Redis, DB를 모두 두고 S3와 함께 사용하시면 돼요 ! CI/CD 파이프라인 구축하고 개발하시는 단계에서는 충분히 합리적이에요 ! 2단계 개발 완료 후 배포 단계에서는 t4g.small과 db.t4g.micro RDS, 그리고 S3 조합을 추천드려요 !즉, RDS 모델만 조정하시는 걸 추천드려요 !초기 단계에서는 텍스트 데이터가 주된 부하이고 100~300명 동시접속 테스트 정도면db.t4g.micro로도 충분히 감당 가능해요 ~ 또한 비용도 거의 절반으로 줄일 수 있죠 !K6 테스트 해보시고 DB CPU가 지속적으로 70% 이상 찍히면 그때 db.t4g.small로 업그레이드하시는 걸 추천드려요 ! ElastiCache는 일단 보류하시는 걸 추천드려요 !초기 단계에서는 EC2 내부에 Redis를 두고 시작하신 후, K6 테스트에서 Redis 메모리 사용률이나 EC2 전체 메모리 사용률이 85% 이상 지속되면 그때 분리하시는 게 훨씬 효율적이에요 !실제 트래픽 증가 시에는 K6 테스트 결과에 따라 단계적으로 확장하시면 돼요 !EC2 메모리가 부족하면 cache.t4g.micro ElastiCache를 추가하고, DB 성능이 부족하면 db.t4g.small로 업그레이드하며, EC2 전체 성능이 부족하면 t4g.medium으로 업그레이드하는 식으로 진행하시는걸 추천드려요 :) 정리하자면, 현재 설계는 전혀 문제없고 배움에 투자하시는 마인드도 정말 좋아요 !다만 초기에는 db.t4g.micro부터 시작하시고, K6 테스트 결과를 보면서 단계적으로 확장하시는 걸 추천드려요 !이렇게 하면 비용도 절약하면서 실제 성능 모니터링, 병목 지점 파악, 스케일링 결정이라는 실무 프로세스까지 경험하실 수 있어서 학습 효과가 훨씬 클 거예요!추가로 또 궁금하신 점 있으시면 언제든 질문 남겨주세요~~늘 파이팅입니다 !! 💪

서버 인프라 관련 질문 (1)

안녕하세요! 강의 잘 들어주셔서 감사합니다 !질문 너무 잘해주셨어요 ~~질문해 주신 내용에 대해 하나씩 답변드려 볼게요 ! 1. ELB로 EC2에 직접 접근 (Client -> ELB -> Spring Boot)"ELB를 80/443 으로 열고, http에 대한 타겟그룹을 8080로 설정한 후 EC2 쪽 인바운드는 8080만 열어야 하는가?"-> 네 맞아요 ! ELB의 보안그룹은 80/443 열고, EC2는 ELB 보안그룹으로부터의 8080만 허용하면 됩니다 ! "ELB는 WAS가 아니라서 Nginx처럼 리액트 빌드 결과물 (정적파일)을 서빙 못하지 않을까?""그럼 S3 파트에서 배웠던 내용대로 S3 + Cloud Front 방식으로 리액트 결과물 내보내야 할까?"-> 정확하게 이해하셨어요! ELB는 로드밸런서라서 정적 파일 서빙은 못해요 ! 그래서 말씀하신 대로 S3 + CloudFront 조합이 이 경우에 가장 적절하죠 :) 2. Nginx만 사용 (Client -> WAS (Nginx) -> Spring Boot & React)-> Certbot으로 Let's Encrypt 인증서 받고 자동 갱신 설정하는 게 ELB에 비해 번거롭긴 하죠 !하지만 한 번 세팅해두면 자동으로 잘 돌아가기도 하고 그렇게 엄청 러닝커브가 심한편이 아니긴 해요 !또한 EC2 하나로 모든 걸 처리할 수 있다는 장점이 있지만, 트래픽이 늘어나면 확장성 측면에서 한계가 있을 수 있는 방법이에요 ! 3. ELB + Nginx 사용 (Client -> ELB -> Nginx -> Spring Boot & React"만약 이럴 경우, ELB는 80/443 열고 EC2는 80만 허용하면 되는건가? 그러면 80->443 리다이렉션하고 443은 타겟그룹 80을 향해 들어가면, EC2에서 80으로 들어온 요청을 nginx가 리버스 프록시 "-> 네 맞아요 ! 정확히 잘 이해하시고 계세요 ! 이 방식은 실무에서도 많이 사용되는 패턴이에요 ! 제 의견에 대해 정리해 드려볼게요 !1번 방법은 프론트엔드와 백엔드를 완전히 분리하고 AWS 서비스를 최대한 활용하고 싶을 때 추천드려요 !React는 S3와 CloudFront로, Spring Boot는 ELB와 EC2로 구성하는 방식인데요.가장 확장성이 좋고 https 인증도 쉬우며 정적 파일 서빙도 최적화되지만, AWS 리소스 관리 포인트가 늘어나고 비용이 상승할 수 있다는 점은 고려하셔야 해요! 2번 방법의 경우 소규모 프로젝트에서 단일 서버로 충분한 경우에 적합해요 !심플하고 비용 효율적이라는 장점이 있지만, 확장성에 제한이 있고 https 인증을 직접 관리해야 한다는 단점이 있어요 ! 3번 방법의 경우 중규모 이상의 서비스에서 확장 가능성을 고려하면서도 프론트엔드와 백엔드를 같은 서버에서 운영하고 싶을 때 추천드려요 ! ELB의 로드밸런싱 기능과 쉬운 https 인증, 그리고 Nginx의 유연성을 모두 활용할 수 있지만 아키텍처 복잡도가 증가한다는 점을 감안하셔야 해요 ! 개인적으로는 1번 방법으로 시작하시는 걸 추천드려요 !이 구조만으로도 충분하며, 확장 가능하고 AWS의 장점을 최대한 활용할 수 있어요 !그러다가 이후 내부 관리자 페이지를 백엔드와 같이 배포해야 하는 경우 또는 SSR이 필요한 경우와 같이 프론트엔드를 EC2에서 같이 서빙해야 한다면, 그때 3번 방식으로 확장하시는 걸 추천드려요 ! 또한 작성해 주신 세 가지 방식에 대한 이해도 모두 정확하셨고, 오류는 전혀 없어요 !실제로 구현해 보시면서 각 방식의 장단점을 체감해보시는 것도 좋은 학습이 될 것 같아요~추가로 궁금하신 점 있으시면 언제든 질문 남겨주세요 ~~늘 파이팅입니다 😄

HTTPS 적용 이후 아이피로 접속

안녕하세요 ! 질문 잘해주셨어요 !질문해 주신 내용에 대해 답변드려볼게요!" 아이피인 43.200.101.5 혹은 43.200.101.5:80 혹은 43.200.101.5:3000으로 접속하면 HTTPS가 적용이 안 되어 있습니다. 이유가 뭘까요?"-> 우선 IP 주소로 직접 접속하시면 HTTPS가 적용되지 않는 건 정상적인 동작이에요 !현재 발급받으신 인증서는 도메인 이름(api.jscode-test.net)에 대해서만 발급된 인증서에요 ~즉, 인증서에는 "api.jscode-test.net이라는 도메인에 대해서만 HTTPS를 보장한다"라는 정보가 담겨있는 거죠! "왜 구글은 아이피로 접속해도 HTTPS가 되고 제 사이트는 안 되는 걸까요? 구글은 뭔가 다른 설정을 더 했기 때문인가요?"-> 구글의 경우도 사실 IP로 직접 접속하면 처음엔 경고가 뜨는 것처럼, 기본적으로는 같은 원리가 적용돼요 !다만, 구글은 여러 개의 도메인과 여러 개의 IP 주소를 가지고 있고, 더 복잡한 인증서 설정(IP SAN)을 통해 여러 도메인을 하나의 인증서로 관리하고 있어요 !즉, 일반적인 도메인용 SSL 인증서와 달리 “특정 IP 주소도 인증서 유효 대상에 포함”되어 있는 구조예요 !구글처럼 큰 서비스들은 각 IP마다 별도의 인증서를 설정해두는 경우도 있지만, 일반적인 웹 서비스에서는 도메인 이름으로 접속하는 것이 정상적인 사용 방법이고, IP로 직접 접속하는 건 권장되지 않아요 :) 추가로 궁금하신 점 있으시면 편하게 질문 남겨주세요~~

쿼리 결과 그리드에서 TYPE, POSSIBLE_KEYS 다릅니다

안녕하세요 ! 질문 잘해주셨어요 !질문해 주신 내용에 대해 답변드려볼게요! "똑같이 했는데 왜 TYPE과 KEY 변경되어 있을까요?제가 잘못하고 있는건가요?"-> 전혀 잘못하신 게 아니에요 !더미 데이터를 생성하기 위해 RAND() 함수를 사용했었는데, 이로 인해 데이터 분포가 매번 달라져 MySQL 옵티마이저의 실행 계획이 약간 달려져서 그런거예요 !실행 계획이 조금 다르더라도 인덱스를 잘 사용하고 있으니 이상이 없어요 :) 추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

인증서 발급받을 때 도메인

안녕하세요 ! 질문 잘해주셨어요 !질문해 주신 내용에 대해 답변드려볼게요! "이럴 경우 jscode-test.net에 대한 인증서가 아닌 api.jscode-test.net에 대한 인증서만 발급받은 거 맞죠?"-> 네 맞아요 ! api.jscode-test.net으로 인증서를 발급받으면 해당 서브도메인에 대해서만 인증서가 적용돼요 !jscode-test.net (루트 도메인)이나 다른 서브도메인들은 이 인증서로 보호받을 수 없어요 ! "현업에서는 인증서를 요청할 때 어떤 식으로 하나요?"-> 현업에서는 아래와 같은 와일드카드 인증서를 주로 사용해요 !도메인을 *.jscode-test.net 형식으로 요청하면 api.jscode-test.net, temp.jscode-test.net, mail.jscode-test.net 등 모든 서브도메인에 대해 하나의 인증서로 커버할 수 있어요 :) 추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

탄력적 IP 주소 연결 해제 버튼 활성화

안녕하세요 ! 질문 잘해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요! "왜 첫 번째 사진에선 탄력적 IP 주소 연결 해제 버튼이 활성화되어 있지 않고, 이번엔 왜 활성화되어 있는 건가요?"-> 결론적으로 EC2 인스턴스 삭제 시점과 탄력적 IP 주소 페이지 새로고침 여부에 따라 달라져요 !첫 번째 이미지의 경우 EC2 인스턴스를 삭제했지만, AWS 콘솔에서 해당 변경사항이 아직 반영되지 않아서 탄력적 IP가 여전히 인스턴스에 연결되어 있다고 인식되어 "연결 해제" 버튼이 비활성화된 상태예요 !두 번째 이미지는 EC2 인스턴스 삭제 후 시간이 지난 뒤 새로고침하셔서 변경사항이 제대로 반영된 상태여서 탄력적 IP가 더 이상 인스턴스에 연결되지 않은 것으로 인식되어 "연결 해제" 버튼이 활성화된 거예요 ! 추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

Route 53의 호스팅 영역도 삭제해야 하죠?

안녕하세요 ! 질문 잘해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요! "호스팅 영역은 삭제해야 비용 청구가 안 되는 거 맞죠?"-> 네 맞아요 ! 호스팅 영역은 삭제하지 않으면 비용이 청구 돼요 ! "혹시 이후 강의에서 만들어 뒀던 호스팅 영역을 재사용하나요?"-> 이후 강의에서는 재사용하지 않아요 ~또한 호스팅 영역 생성은 어렵지 않으니 걱정 안 하셔도 돼요 :) 추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

Cloudfront UI 변경에 따른 문의 드립니다!

안녕하세요 bonobono88님! 질문 잘 해주셨습니다:)혹시 AWS 측에서 없앤 건가 싶어서 확인해봤는데 아직까지 팝업이 뜨고 있긴한데, 팝업 창을 끄게 되면 go to previous ~ 라는 상단 탭이 뜨지 않네요,,,!! 우선 아래 링크로 접속해서 이전 버전 ui로 접속해서 강의 따라가보시겠어요~?https://us-east-1.console.aws.amazon.com/cloudfront/v4/home?region=ap-northeast-2#/distributions/create?mode=legacy그러고 추후에도 go to previous 버튼이 뜨지 않으면 말씀해주세요!제가 새로운 UI에 맞춰서 보충 자료 올려드릴게요:)

설치 코드부분이 notion에선 온전한데 pdf에선 코드가 잘려있습니다.

안녕하세요 민철님! 제보 해주셔서 감사합니다!! 저도 방금 확인해보니 PDF에서는 코드가 짤리더라구요ㅠㅠ노션의 아쉬운 한계점인 것 같네요,,,!!민철님 말씀대로 정확한 코드 부분은 노션 참고하시는 걸 권장드립니다!

Kafka 음성메세지 브로커로도 적합한가요?

안녕하세요 Mia님! 질문 잘 해주셨어요 ~질문해주신 내용에 대해 답변드려 볼게요 ! "Kafka 음성메세지 브로커로도 적합한가요?"-> 실시간 음성 인식기를 구현해본 경험은 따로 해본 적이 없어서 서치를 조금 해봤어요! 찾아보니 실시간 음성 인식 용도로는 Kafka를 잘 쓰지 않고 이미 구현된 라이브러리나 솔루션(ex. Amazaon Transcribe)을 활용해서 많이 구현하더라구요! 그래서 realtime 음성 인식을 직접 구현해야 하는 게 아니라면이미 구현된 솔루션의 방향성으로 찾아보시는 건 어떠실까요?! 이 외로 추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~