안녕하세요. 강사님 RDS를 express-app과 연결해보려고 하는데요. 두 서비스간 통신은 설명해주신 구조와 유사하게 private network를 통해서 하려고합니다. 그러면 express-app을 만들때, service-connect를 client and server로 설정을 하면 되나요? 아니면 로드밸런서를 따로 둔 다음 security group을 설정해야할까요?
안녕하세요. 강사님! 강의 정말 잘 보고 있습니다. lightsail로 서버도 배포해보고, ECS를 사용하여 hello world까지 구현해보고, 관리형 서비스에 대해 공부하는데 많은 도움이 되고 있습니다. 고민이 하나 있어 질문 드립니다. 강사님의 강의를 듣기전에 EC2로 배포한 웹사이트가 하나 있습니다. 이 사이트를 강사님 강의 내용을 기반으로 lightsail 또는 ECS로 전환해보고자 합니다. 전환하려는 이유는 기존 ec2는 로드밸런서 및 오토스케일링이 적용되어있지 않아 고가용성이 힘듭니다. 보안그룹 또한 보완할점이 많다고 생각합니다. Backend의 경우는 DB도 ec2 내부에 있어서, 수평확장도 힘들 것같아, RDS로 데이터를 이관하려고 합니다. 그래서 lightsail과 ECS 선택 기준에 알아보았는데, 소규모 서비스는 lightsail / 대규모 서비스는 ECS로 생각하면 된다고 하더라구요. 당연히 소규모와 대규모는 여러 요인에 따라 달라지긴 하겠지만, LightSail과 ECS를 선택하는 대략적인 기준이 있을까요?
'Express App 받아서 준비하기' 강의 내 강의자료(프로젝트 파일)을 다운받아서 .env 파일에 PORT, REDIS_URL 값만 설정해주고 바로 npm rum dev를 실행시켰는데 계속 저런 오류가 발생하네요... node.js를 전혀 모르다보니... 어떤식으로 트러블슈팅을 해야하는지 감이안잡혀서 질문 남깁니다ㅠ
[섹션 10 - Self-healing! - 죽은 서버(테스크) 자동으로 살려내는 AWS ECS service 알아보기] 강의에서 Task 의 RollingUpdate 하는 모습과 health check 에 의한 Task 소멸 및 생성 모습을 보여주셨는데요. ECS 의 Task 소멸 및 생성 속도가 너무 느려서 놀랐습니다. 집에서 Kubernetes 로 실습해본 경험에 의하면, K8S 에서는 3초면 되는 것이, ECS Fargate 에서는 3분이 걸리는 것 같은데요. 원래 ECS 의 Fargate launch type 이 아주 느린 것인가요? ECS 의 EC2 launch type 이었다면 Fargate 보다는 조금 빠른지요? 로컬에서 돌리는 Kubernetes 만큼 몇초만에 수행을 완료할 정도로 빠르게 하는 방법은 없는지요? ECS 너무 느려서 이걸 써야 되나라는 실망스런 마음이 큰데요. 반응 속도가 빠른 auto scailing 을 구현하려면, 직접 K8S 쓰는 것이 더 현실적인 방법인 것인지 고민이 됩니다.
안녕하세요, 강사님, 섹션 9 : Container Orchestration - [AWS ECS - Service 사용해서 여러개의 Task 생성하고 Load balancer 연결해주기] 강의에서 ECS Cluster 에 Service 를 만들 때, Service 에 적용하는 Load Balancer 도 내부적으로는 EC2 를 이용한 것인가요? Service 에 만든 Load Balancer 에도 별도의 Load Balancer 비용이 부과되나요? LightSail 에서 적용했던 Load Balancer 와 동일하게 비용이 드는지 궁금합니다. 만약, 비용이 부과된다면, ECS 에서 여러 Task 에 auto scailing 을 적용할 경우, Load Balancer 의 갯수가 많아질텐데, 그 갯수만큼 비용이 부과되는지도 궁금합니다.
ecs service 등록하려고 보니, Load balancer 설정 부분에 이렇게 뜨는데,, 제가 Lightsail 볼때 따로 등록 안해줘서 설정 부분이 이렇게 뜨는걸까요? ㅠㅠ ec2에서 설정 따로 해줘야한다는거 같은데 로드밸런싱 활성 작업을 위해서 어떤 어떻게 등록 해야하는 걸까요?
선생님 안녕하세요. MongoDB에 이어 infra 관련 강의도 잘 수강하고 있습니다. 캐싱 관련되어 선생님 의견이 궁금해 질문드립니다. 백그라운드 현재 MongoDB + Nest.JS를 사용해 WAS를 구축한 상태입니다. 도큐먼트 안에 서브 도큐먼트들이 array 형태로 들어가도록 Model을 설계했는데요, 서브 도큐먼트를 가져올 때 aggregation을 사용해 페이지네이션을 적용했습니다. (처음에 설계 시, 잘 못 생각해 이러한 설계를 하긴 했습니다..) aggregation에는 성능 문제가 따라올 위험이 있을까봐 해당 GET 요청 컨트롤러에는 캐싱을 적용했습니다. 문제가 되는 부분은 캐싱처리로 인한 코드의 가독성 저하 입니다. WAS안에서 GET 요청 시 캐싱을 적용하고, POST, PUT, PATCH 요청시에는 캐싱을 지우고 있는데, 비즈니스 로직안에서 이를 처리하다보니 코드의 가독성이 급격히 떨어지더라고요. 제가 생각한 해결 방안 이를 해결하기 위해 event emitter를 사용해 캐싱을 비즈니스 로직으로부터 떼어낼까 고민했습니다. 다만 이 해결방안은 캐싱처리하는 로직 자체가 하나의 WAS에 존재하고 있어 추후에 또 비슷한 문제가 발생하지 않을까 생각이 들더라고요. 질문 선생님께서는 이러한 문제 발생 시 캐싱 처리는 프록시 서버를 띄워서 앞단에서 미리 처리를 하시는지... 아니면 또 다른 좋은 방식으로 설계를 하시는지 궁금해서 질문드립니다.