인프런 커뮤니티 질문&답변
작성한 질문수
서버 인프라 관련 질문 (1)
작성
·
22
·
수정됨
0
안녕하세요!
항상 좋은 강의 잘 듣고 있습니다!
서버 인프라를 어떻게 설계해야할 지 판단이 잘 안서서 이렇게 질문드립니다.
제가 개념이 미숙하다보니 제 생각에 대한 설명이 뭔가 중구난방할 수 있다는 점 양해부탁드립니다.
일단 첫번째로 생각하고 있는건 ELB, Nginx에 대한 고민입니다.
내용이 길어서 질문은 나눠서 올리려고 합니다.
제 머릿 속에 있는 걸 그냥 그대로 끄집어낼게요.
ELB로 EC2에 직접 접근 (Client -> ELB -> Spring Boot)
ELB를 80/443 으로 열고, http에 대한 타겟그룹을 8080로 설정한 후 EC2 쪽 인바운드는 8080만 열어야 하는가?
ELB는 WAS가 아니라서 Nginx처럼 리액트 빌드 결과물 (정적파일)을 서빙 못하지 않을까?
그럼 S3 파트에서 배웠던 내용대로 S3 + Cloud Front 방식으로 리액트 결과물 내보내야 할까?
https 설정은 Nginx 대비 이게 더 편한거같음
Nginx만 사용 (Client -> WAS (Nginx) -> Spring Boot & React)
ELB 대비 https 인증이 경험 상 상당히 까다로웠음 (자동 인증사 만료 처리도 해야하고...)
EC2 안에서 React까지 처리하기 좋았음
이 경우는 인바운드를 80/443 열고 nginx 에서 reverse proxy
ELB + Nginx 사용 (Client -> ELB -> Nginx -> Spring Boot & React)
ELB는 로드밸런서 역할과 https 인증 담당용 (로드밸런싱은 추후 확장가능성 염두, https 인증은 elb가 더 쉬우니까)
Nginx는 내부에서 리버스 프록시 적용
https 처리는 elb가 쉬우니까 이거 쓰고, 리버스프록시와 정적 파일 서빙은 nginx에게 위임하겠다는 취지
만약 이럴 경우, ELB는 80/443 열고 EC2는 80만 허용하면 되는건가? 그러면 80->443 리다이렉션하고 443은 타겟그룹 80을 향해 들어가면, EC2에서 80으로 들어온 요청을 nginx가 리버스 프록시
어떤게 적절한 선택일지 고민중입니다.
서버 인프라를 구성하기 위해 참조할 만한 자료로 깃헙을 찾아보니, 다른 프로젝트 아키텍처 보면 다 2번처럼 하는 것 같았습니다. 근데 실습을 했을 때 ELB가 https 인증이 너무 쉽게 되었던게 매력적이었어서 차마 2번 방식에는 손이 잘 안갑니다. 근데 1번만 하자니, 과연 1번만으로 충분할까? 라는 의문이 들었습니다. 그래서 ELB랑 Nginx를 혼합해서 쓸까라는 생각까지 이어진건데요. 3번은 저 생각대로면 각자의 편의를 챙겨가기는 하지만 좀 더 복잡한 아키텍처같은 생각도 들어요.
우선 각각의 생각에 오류가 있는지, 그리고 전문가의 식견으로 봤을 때 어떤게 더 나은 접근인지 여쭤보고싶습니다.
어려운게 있으면 항상 박재성님 강의부터 찾습니다. 늘 도움받아갑니다. 감사합니다.
답변 2
0
안녕하세요! 강의 잘 들어주셔서 감사합니다 !
질문 너무 잘해주셨어요 ~~
질문해 주신 내용에 대해 하나씩 답변드려 볼게요 !
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번 방식으로 확장하시는 걸 추천드려요 !
또한 작성해 주신 세 가지 방식에 대한 이해도 모두 정확하셨고, 오류는 전혀 없어요 !
실제로 구현해 보시면서 각 방식의 장단점을 체감해보시는 것도 좋은 학습이 될 것 같아요~
추가로 궁금하신 점 있으시면 언제든 질문 남겨주세요 ~~
늘 파이팅입니다 😄
0
안녕하세요, 인프런 AI 인턴입니다. Hooby님.
AWS 인프라 설계에서 ELB와 Nginx의 역할 및 조합에 대해 고민하고 계시군요. 각기 다른 방법의 장단점과 상황에 따라 적절한 방법을 선택해야 할 때가 많습니다. 아래에 각 방법에 대한 설명과 고려사항을 제시해 드리겠습니다.
1. ELB로 직접 접근 (Client -> ELB -> Spring Boot)
초기 설정: ELB는 트래픽을 80⁄443 포트로 받으면서 백엔드 인스턴스로의 트래픽은 포트 8080으로 릴레이할 수 있습니다. ELB를 통한 HTTPS 설정은 자동 갱신이 지원되기 때문에 관리가 용이합니다.
정적 파일 서빙: ELB 자체는 정적 파일을 처리를 지원하지 않기 때문에, 말씀하신 대로 S3 및 CloudFront와 결합하여 정적 파일을 서빙할 수 있습니다. 이 방식은 고성능과 확장성을 유지할 수 있어 좋습니다.
2. Nginx만 사용 (Client -> WAS (Nginx) -> Spring Boot & React)
HTTPS 설정: Nginx에서는 Certbot 등 도구를 사용하여 HTTPS 인증서를 설정하는 것이 가능합니다. 그러나 자동 갱신 스크립트를 추가로 관리해야 할 수 있다는 점에서 관리 비용이 상승할 수 있습니다.
정적 파일 및 프록시: Nginx는 정적 파일을 직접 서빙하고, 리버스 프록시를 통해 Spring Boot와의 연결을 관리할 수 있어 개발 초기 설정이 단순화될 수 있습니다.
3. ELB + Nginx 사용 (Client -> ELB -> Nginx -> Spring Boot & React)
장점: ELB를 통해 HTTPS를 쉽게 설정하고, Nginx가 정적 파일 서빙 및 리버스 프록시를 처리함으로써 복잡한 요구 사항을 효율적으로 관리할 수 있습니다. 로드밸런싱도 ELB를 통해 확장성을 쉽게 확보할 수 있어 유리합니다.
설정 복잡성: ELB와 Nginx 사이의 설정을 잘못하면, 불필요한 복잡도가 증가할 수 있습니다. 따라서 설정을 명확하게 해두고, 모니터링을 통해 성능을 관리하는 것이 중요합니다.
전문가적인 시견
각각의 방법은 특정 상황에서 유리할 수 있습니다. 작은 규모의 프로젝트에서 Nginx만을 사용하는 것이 적합할 수 있지만, 고도의 확장성과 유지 보수의 용이성을 고려하고 있다면 ELB와 Nginx를 결합하는 것도 좋은 방법이 될 수 있습니다.
가능하면 실시간 모니터링과 로깅을 강화하여 예상치 못한 문제를 즉각적으로 대응할 수 있도록 인프라를 설계하고 구성한다면 장기적인 관점에서 안정성과 운영 인프라 효율성이 높아질 것입니다.
관련된 질문 및 사례에서는 아래 링크를 참고할 수 있습니다:
- 서버 인프라 구축 사례
추가적으로 궁금한 점이 있으시면, 언제든지 질문해 주세요. 곧 지식공유자께서도 상세히 답변해 주실 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해 드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏