sihoon

안녕하세요 😃&nbsp;프로그래밍 언어는 무관합니다! 강의에서 노드를 사용하고 있기는 하지만 노드를 다루는 부분은 극히 일부입니다. 그냥 배포할 대상이 필요한데 노드가 선택 되었을 뿐이에요.

springboot

섹션 7. 도커 강의부터 들으시면 됩니다. 그런데 가급적이면 그 전 부분을 따라하지는 않고 2배속으로라도 보는걸 추천해요. 단순히 VM (EC2와 유사한 Lightsail) 쓰는 방법을 가르쳐주기보다는 VM의 불편한점들을 가르쳐주면서 ECS로 빌드업해가는 과정이거든요.

강의 영상 시청문의

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

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

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

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

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

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

백엔드: <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/hoffnung8493/image-tutorial">https://github.com/hoffnung8493/image-tutorial</a>프론트: <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/hoffnung8493/image-tutorial-frontend">https://github.com/hoffnung8493/image-tutorial-frontend</a>&nbsp;최종버전이라 현재 보시고 있는거랑은 코드가 조금씩 다를 수 있어요.

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

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

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

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

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

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

ECS ALB설정을 위한 vpc 설정

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

sihoon

Bài viết