인프런 커뮤니티 질문&답변
작성한 질문수
서버 인프라 관련 질문 (2)
작성
·
24
·
수정됨
0
안녕하세요!
항상 좋은 강의 잘 듣고 있습니다!
서버 인프라를 어떻게 설계해야할 지 판단이 잘 안서서 이렇게 질문드립니다.
제가 개념이 미숙하다보니 제 생각에 대한 설명이 뭔가 중구난방할 수 있다는 점 양해부탁드립니다.
고민하고 있는건 EC2 등 모델 선정입니다. 그리고 RDS, ElastiCache 도입여부 또한 고민중입니다.
제 프로젝트는 거의 싸이월드 같은 사이트를 만들어야 하는 상황입니다.
알림, 조회수, 좋아요 기능, 파일 업로드, 스트리밍, 게시판, 댓글 등이 주된 기능입니다.
(이때 파일 업로드는 multipart/form-data 업로드와, 동영상과 같은 대용량 파일 처리를 위한 AWS Multipart Upload 방식으로 나뉩니다.)
한번 AWS 강의에서 배운걸 다 써먹어보고 싶어서 EC2, RDS, S3, ElastiCache 도입을 상정해봤습니다.
초기 단계 모델을 먼저 결정한 후 K6 등으로 동시접속자 수 100명 200명 300명 순으로 테스트를 진행해서 스케일업을 고려중입니다. (데모 시연도 하고, 실제로 한달 간 출시도 해봐야해서요)
구상중인건 다음과 같습니다.
1단계 (개발 중) ::
CI/CD용 : t4g.small (EBS 있으니까 여기 안에서 Redis랑 DB, 서버 다 돌림) + S3
2단계 (개발 완료 후 배포) ::
실제 운영 테스트용 :
Case 1. t4g.small + S3 (CI/CD용 그대로)
Case 2. t4g.small + RDS + S3 (Redis는 EC2 안) (RDS는 EC2모델과 같은 사양으로)
Case 3. t4g.small + RDS + S3 + ElastiCache
Case 4. t4g.medium + RDS + S3 + ElastiCache
근데 Case 3까지만 가도 AWS 계산기 돌려보니 월 10만원이 조금 넘더라구요. RDS에서 프록시나 Insights 설정 빼고 SingleAZ로 변경한게 저 수준이었습니다. 너무 비싸더라구요. Case 4는 한 17만 7천원 나오더라구요... RDS가 많이 비싼 것 같습니다.
비용이 비정상적인게 아니라면, 그대로 진행해도 전 좋습니다. 배움에 돈아끼면 안된다고 생각하거든요.
근데 그게 오버스펙이나 비정상적인 설계로 비용이 많이 나오는건 별개의 문제잖아요.
그래서 결국 어떻게 서버 인프라를 구축할지에 대한 고민이 많습니다.
비용이 제 기준에서는 높지만 남들 기준에선 높은게 아닐 수도 있고, 아니면 정말로 너무 높게 나온걸 수도 있어서 정상적으로 프로젝트에 맞게 아키텍처를 구축한게 맞는지, 잘못되었다면 어떻게 조정해야할지에 대한 판단이 어렵습니다.
실례가 안된다면, 지금 제가 어떤 문제가 있는지, 제 상황에선 어떤 아키텍처가 적절한지 설명부탁드려도 될까요?
이건 저 생각이 들기까지의 내용들을 정리한 노션 페이지입니다.
https://hooby.notion.site/Server-Infra-Setup-28af6c063f3e80b7a8c3d653add0c068
답변 2
0
안녕하세요! 강의 잘 들어주셔서 감사합니다 :)
노션 문서까지 체계적으로 정리해주신 거 보니 정말 깊게 고민하신 게 느껴지네요 ~
질문 너무 잘해주셨어요 ! 질문해 주신 내용에 대해 하나씩 답변드려 볼게요 !
먼저 결론부터 말씀드리면 현재 구상하신 아키텍처는 전혀 문제없고, 비용도 비정상적이지 않아요 ~
오히려 실무 경험을 쌓기 위한 프로젝트 목적에 잘 맞는 구조예요 !
다만 단계별로 좀 더 효율적으로 접근하실 수 있는 방법을 제안드려 볼게요 !
우선 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 테스트 결과를 보면서 단계적으로 확장하시는 걸 추천드려요 !
이렇게 하면 비용도 절약하면서 실제 성능 모니터링, 병목 지점 파악, 스케일링 결정이라는
실무 프로세스까지 경험하실 수 있어서 학습 효과가 훨씬 클 거예요!
추가로 또 궁금하신 점 있으시면 언제든 질문 남겨주세요~~
늘 파이팅입니다 !! 💪
0
안녕하세요, 인프런 AI 인턴입니다. Hooby님.
AWS 인프라 설계에 대한 고민이 깊으신 것 같네요. 프로젝트의 요구사항에 맞춰 최적의 아키텍처를 결정하는 것은 쉬운 일이 아닙니다. 아래에서 제안드리는 사항들을 참고하셔서 방향성을 잡으시면 도움이 될 것 같습니다.
1. AWS 서비스 선택 개요
EC2 인스턴스 선택:
- 시작 단계에서는 t4g.small로 시작하고, 성능이 부족한 경우 스케일업을 고려하시면 좋을 것 같습니다. 초반에는 작은 인스턴스를 운영하면서 모니터링을 통해 실제 요구사항을 파악하는 것이 중요합니다.
- 시작 단계에서는 t4g.small로 시작하고, 성능이 부족한 경우 스케일업을 고려하시면 좋을 것 같습니다. 초반에는 작은 인스턴스를 운영하면서 모니터링을 통해 실제 요구사항을 파악하는 것이 중요합니다.
S3와 Multipart Upload:
- 대용량 파일 처리를 위해 S3를 사용하는 것은 적절한 선택입니다. 사용자 업로드가 많은 웹사이트에서는 S3가 큰 장점을 발휘할 수 있습니다.
- 대용량 파일 처리를 위해 S3를 사용하는 것은 적절한 선택입니다. 사용자 업로드가 많은 웹사이트에서는 S3가 큰 장점을 발휘할 수 있습니다.
RDS:
- 초기 구현 단계에서는 RDS 대신 EC2 내에 MySQL을 설치해서 사용할 수 있습니다. 비용 관점에서 더 저렴할 수 있습니다. RDS는 안정성과 관리 용이성의 장점을 가지므로, 추후 트래픽 증가와 함께 고려하시면 좋습니다.
- 초기 구현 단계에서는 RDS 대신 EC2 내에 MySQL을 설치해서 사용할 수 있습니다. 비용 관점에서 더 저렴할 수 있습니다. RDS는 안정성과 관리 용이성의 장점을 가지므로, 추후 트래픽 증가와 함께 고려하시면 좋습니다.
ElastiCache:
- 읽기 성능 최적화와 세션 데이터를 처리하는 데 유용합니다. 서비스 특성에 따라 즉시 필요한 기능이 아니기 때문에, 초기에는 Redis를 EC2 인스턴스로 직접 관리하는 것을 고려하시고, 이후에 필요성을 판단하여 ElastiCache로 이전할 수 있습니다.
- 읽기 성능 최적화와 세션 데이터를 처리하는 데 유용합니다. 서비스 특성에 따라 즉시 필요한 기능이 아니기 때문에, 초기에는 Redis를 EC2 인스턴스로 직접 관리하는 것을 고려하시고, 이후에 필요성을 판단하여 ElastiCache로 이전할 수 있습니다.
2. 비용 절감 및 아키텍처 조정
확장 가능한 아키텍처:
- 초기에는 미니멀한 설정으로 시작하고, K6 등의 도구로 부하 테스트를 진행하면서 확장 방향을 결정하는 접근이 좋습니다.
- 초기에는 미니멀한 설정으로 시작하고, K6 등의 도구로 부하 테스트를 진행하면서 확장 방향을 결정하는 접근이 좋습니다.
서비스 필요성 평가:
- 모든 기능을 한 번에 도입하기보다는, 우선 순위를 설정하고 단계적으로 도입해보세요. 예를 들어, ElastiCache는 초기에는 배제하고, 성능 이슈가 발생할 때 추가합니다.
- 모든 기능을 한 번에 도입하기보다는, 우선 순위를 설정하고 단계적으로 도입해보세요. 예를 들어, ElastiCache는 초기에는 배제하고, 성능 이슈가 발생할 때 추가합니다.
비용 모니터링 및 최적화:
- AWS 비용 검토를 주기적으로 진행하고, 사용하지 않는 리소스는 중지하거나 제거합니다. 이와 함께, 리저브드 인스턴스나 스팟 인스턴스를 활용하는 방법도 고려해 볼 수 있습니다.
- AWS 비용 검토를 주기적으로 진행하고, 사용하지 않는 리소스는 중지하거나 제거합니다. 이와 함께, 리저브드 인스턴스나 스팟 인스턴스를 활용하는 방법도 고려해 볼 수 있습니다.
결론
현재 설계는 성장 가능성을 고려한 단계별 아키텍처로 보이지만, 초기 단계에서는 최소한의 리소스로 시작하여 점진적 확장을 고려하는 것이 더욱 효율적입니다. 또한, 서비스의 사용 패턴을 정확히 이해한 후에 필요에 따라 아키텍처를 조정하는 것이 중요합니다.
추가적으로, AWS의 무료 티어를 최대한 활용하여 비용을 절감할 수 있는 부분을 탐색해보세요. 또한, AWS 비용 관리 도구를 사용하여 예산을 관리하고 비용 예측을 통해 리소스 사용을 최적화할 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.