실습시 비용 관련 질문드립니다.

deploy가 되면 그 때부터 비용이 발생하는게 정상입니다. task가 생성되면 종료시키기전까지는 해당 서버의 자원은 온전히 질문자님 소유가 되는거에요. 요청(request)이 들어오는 것과는 무관합니다. 요청이 적든 많든 나가는 비용은 동일해요. Serverless 하면 대표적인 서비스가 람다라서 아마 람다 비용정책과 혼돈하신듯 해요! 람다의 경우 요청이 들어올 때만 일시적으로 서버를 켰다가 일정 기간 동안 요청이 들어오지 않으면 자동으로 서버를 종료시킵니다. 즉, 서버가 상시에 켜져 있지 않기 때문에 요청에 비례해서 비용이 발생하죠. 하지만 이건 람다의 특성이지 serverless의 특성은 아닙니다. serverless의 특성은 EC2, lightsail처럼 low level에서의 서버 관리를 안해도 되는게 포인트입니다. Fargate는 일반 서버를 serverless하게 배포할 수 있는 서비스이죠.Public IP는 비용이 발생합니다. 아마 Lightsail에서도 언급을 했었을거에요. IP 또한 유한 자산이라서요.

ECS 클러스터에서 레디스와 express 연결할 때 질문이 있습니다!

안녕하세요~ 답변이 늦어서 죄송합니다!같은 ECS 클러스터 안에 있고 service discovery를 해줘도 Security Group 설정을 해줘야 방어벽을 통과하실 수 있습니다! 6379를 오픈하면서 방화벽을 통과가 가능해졌고 그래서 정상 작동하는겁니다.강의에서는 아마 모든 포트를 허용했을거에요. 대신 설정하신것처럼 소스를 sg-188ba163/default로만 해주시면 됩니다. 그러면 같은 보안그룹을 사용하는 서비스들끼리는 서로 요청을 날릴 수 있도록 방화벽이 풀립니다!

Presigned URL 사용시 데이터베이스 저장 시점

네 맞습니다! 강의 초반에는 서버에 직접 저장하는 기본적인 방법을 보여드립니다. 그러면서 이 방법의 한계점들을 보여주고 이후에 말씀하신 방법으로 발전시킵니다. 애초에 왜 번거럽게 presignedUrl을 사용하는지 왜 별도 S3 같은 저장소에 따로 저장하는지 이유를 명확하게 알고 배우는게 중요하다고 생각해서 이렇게 강의가 구성되어 있습니다. (제가 제작한 다른 강의들도 모두 이런식으로 구성되어 있습니다)

강의에 사용된 코드 다운 받는 사이트 주소 있나요?

백엔드: https://github.com/hoffnung8493/image-tutorial프론트: https://github.com/hoffnung8493/image-tutorial-frontend 최종버전이라 현재 보시고 있는거랑은 코드가 조금씩 다를 수 있어요.

[AWS 배포 완벽가이드] artillery 버전

강의에서 사용했던 Artillery 버전입니다: 2.0.0-35 재밌게 보고 있으시다니 다행입니다!

deploy.yml github action 성공 , 하지만 AWS

네 바로 들어가져야 합니다. github action에서 마지막 부분에서 제대로 작동이 안된것으로 추정됩니다. 이 부분이 다소 불안정할 수도 있어요. 음 몇번 시도 해보시고 그래도 잘 안된다면 일단 계속 강의를 진행보시는걸 추천합니다. 여기서는 VM배포의 불편함, 불안정함 이런걸 기억해두는게 더 핵심입니다. 강의 중반부터는 이 불편한 가정들을 모두 개선하는 내용을 다루게 됩니다. 왜 컨테이너로 배포하는지, ECS를 왜 쓰는지 도움을 주는 목적이 더 큽니다.

ECS ALB설정을 위한 vpc 설정

강의에서 ECS 서비스에 로드밸런서 부착하는 부분이 나오는데 혹시 보셨을까요? 그리고 redis 부분은 그냥 따라 해보시면 좋을듯 해요. 이 강의에서 다루는 레디스 배포는 레디스 사용 자체가 목적이 아니거든요. 그냥 또 하나의 서비스를 배포해보고 배포한 서비스들끼리 어떻게 상호작용 하는지를 보여주기 위함이에요. 실제로는 SSR 프론트 서버 + 백엔드 서버일 수도 있고 혹은 MSA일 수도 있고요

도커는 OS를 공유하지 않나요?

이해를 돕기 위해 VM과 컨테이너를 비교하면서 설명을 했는데 혼선이 좀 있었나봅니다. 환경 분리가 맞습니다. 다만 일반적으로 환경 분리란 무엇인지 모를 수 있기 때문에 환경 분리를 설명해주는 내용들이었습니다.8:14에 한 말을 정확히 여기에 다시 올리면 "겉으로 봤을 때는 운영체제도 분리됩니다" 라고 했어요.여기서 두개의 컨테이너 vs 두개의 VM 비교상황으로 설명을 하고 있습니다. VM은 물리적으로 같은 서버일 수 있어도 독립적인 OS를 가지고 있기 때문에 컨테이너가 할당 받은 리소스와 동일하게 받더라도 상대적으로 리소스가 제한된다는 점을 설명하고 있어요. 그에 반면 컨테이너는 사용자 입장에서 (겉으로 봤을 때)에는 VM처럼 독립된 운영체제를 가지고 있는듯한 isolatiotion을 가지고 있지만 실질적으로는 Linux kernerl을 컨테이너들끼리 공유하고 있기 때문에 상대적으로 훨씬 가볍다 얘기를 하고 있고요. 동일한 강의에서 (4:21) container를 가능하게 해주는(독립적인 OS 설치 없이 환경 분리를 가능하게 해주는!) Linux Kernerl의 Namespacing (Isolation을 가능하게 해주는 기능) 그리고 Control Groups (리소스 나눠주는 기능)을 다루고 있습니다.

user 내장 시 ref 필드 필요성

안쓰시면 빼도 됩니다!

자바 스프링 개발자입니다.

좋은 질문입니다 스프링 개발을 안해봐서 확실하지는 않지만 제가 알기로 자바 PM2 같은게 필요가 없을거에요. 자바 자체에서 요청이 들어올 때마다 요청별로 하나의 스레드를 생성해주니깐요. 하지만 "PM2 + 노드 == 자바 스프링" 이렇게 1대1 적용은 아니긴 합니다. 노드는 각 프로세스가 싱글 스레드이긴 하지만 non blocking event loop 아키텍처이기 때문에 하나의 스레드가 수만개의 요청을 동시에 처리가 가능하니깐요. 그에 반면 자바의 스레드는 하나의 요청(blocking)만 처리하는걸로 알고 있습니다. 한개의 노드 프로레스가 수만개의 요청을 받을 수 있음에도 불구하고 PM2를 사용하게 되는 경우에는 CPU 코어가 여러개 있을 때입니다. 스레드 특성상 한개의 스레드가 여러 CPU를 사용할 수 없거든요. 그래서 보통은 성능 문제보다는 고가용성을 위해 PM2를 사용합니다. 예를 들어 배포할 때 3개의 프로세스가 있으면 순차적으로 배포하면 down time 없이 배포할 수 있게 되죠. 혹은 장애가 발생해서 프로세스가 하나 죽더라도 다른 복구하는 동안 다른 프로세스들이 분담해서 요청을 처리할 수 있게 되고요. 강의를 좀 보시면 PM2 안쓰고 VM을 여러개 쓰는걸로 발전시킵니다. 여기서부터는 싱글스레드이든 아니든 모든 언어에 동일하게 적용됩니다! VM 안에 여러 프로세스를 뛰웠어도 VM 자체가 죽으면 안에 아무리 많은 프로세스를 뛰워도 다 죽기 때문이죠. 그래서 제일 아랫단에 있는 VM 자체를 여러개 더 나아가서 각 VM여러 데이터센터(Availibility Zones)에 분산해서 배포합니다. 혹시라도 정전이 발생해서 데이터센터 자체가 문제가 될 수 있는 상황을 대비하는거죠. 몇년 전에 카카오에서 한개의 데이터센터 레벨에서의 분산이 올바르게 안되서 심각한 문제가 있었죠.PM2는 이런 고가용성 개념을 배우기 위한 진검다리라고 생각하시면 좋을듯 합니다