이 모듈에서는 node.js 애플리케이션을 상호 연결된 여러 개의 서비스로 나누고 각 서비스의 이미지를 Amazon ECR 리포지토리로 푸시합니다. 구축 시작
최종 애플리케이션 아키텍처에서는 Amazon Elastic Container Service와 Application Load Balancer를 사용합니다.
a. 클라이언트
클라이언트는 포트 80을 통해 트래픽 요청을 전송합니다.
b. 로드 밸런서
Application Load Balancer(ALB)는 외부 트래픽을 올바른 서비스로 라우팅합니다. ALB는 클라이언트 요청을 조사하고 라우팅 규칙을 사용하여 요청을 규칙과 일치하는 대상 그룹의 인스턴스와 포트로 리디렉션합니다.
c. 대상 그룹
서비스마다 해당 서비스에 대해 실행되는 각 컨테이너의 인스턴스 및 포트를 추적하는 대상 그룹이 있습니다.
d. 컨테이너화된 서비스
Amazon Elastic Container Service(ECS)는 각 서비스를 EC2 클러스터 전체의 컨테이너로 배포합니다. 각 컨테이너는 단일 기능만 처리합니다.
고장의 격리
아무리 뛰어난 엔지니어링 조직이라도 운영 중에 심각한 고장을 겪습니다. 고장을 적절하게 처리하기 위한 모든 표준 모범 사례를 따르는 것 외에, 마이크로서비스를 구축하는 것도 고장이 미치는 영향을 억제하는 방법 중 하나입니다. 서비스의 특정 마이크로 요소가 작동하지 않으면 서비스의 해당 부분만 다운되는 마이크로서비스 아키텍처가 바람직합니다. 즉, 나머지 서비스는 계속 정상적으로 작동할 수 있습니다.
보안을 위한 격리
모놀리스 애플리케이션에서 애플리케이션의 기능 중 하나가 보안 침해를 당하면(예: 취약성을 악용한 원격 코드 실행) 공격자가 시스템의 다른 모든 기능에도 액세스할 수 있는 것으로 간주해야 합니다. 예를 들어 아바타 업로드 기능의 보안 문제로 인해 사용자 암호를 악용한 데이터베이스 보안 침해가 발생한다면 위험할 수 있습니다. Amazon ECS를 사용하여 기능을 마이크로서비스로 분할하면 서비스마다 고유한 IAM 역할을 부여하여 AWS 리소스에 대한 액세스를 보호할 수 있습니다. 마이크로서비스 모범 사례를 따르면 공격자가 특정 서비스를 침해하더라도 해당 서비스의 리소스에만 액세스할 수 있고, 다른 서비스의 다른 리소스에는 수평적으로 액세스할 수 없습니다. 그러기 위해서는 다른 서비스에도 침투해야 합니다.
독립적인 확장
기능을 마이크로서비스로 분할하면 각 마이크로서비스 클래스에 사용되는 인프라의 양과 인스턴스의 수를 독립적으로 확장하고 축소할 수 있습니다. 따라서 손쉽게 특정 기능의 비용을 측정하고, 먼저 최적화해야 할 기능을 파악하고, 특정 기능의 리소스 요구 사항이 통제 불가능한 상태가 되더라도 다른 기능의 성능을 안정적으로 유지할 수 있습니다.
개발 속도
마이크로서비스는 개발의 위험을 줄여 팀의 개발 속도를 높여 줍니다. 모놀리스에서 새 기능을 추가하면 모놀리스에 포함된 다른 모든 기능에 영향을 미칠 수 있습니다. 개발자는 추가하는 코드가 미치는 영향을 신중하게 고려하고 문제를 일으키지 않을지 확인해야 합니다. 반면, 올바른 마이크로서비스 아키텍처에서는 새 기능의 새 코드가 새 서비스에 배치되어야 합니다. 개발자는 2개의 마이크로서비스 간 연결을 명시적으로 작성하지 않는 한, 작성하는 코드가 실제로 기존 코드에 전혀 영향을 미치지 않는다는 것을 확신할 수 있어야 합니다.
아래의 단계별 지침에 따라 모놀리스에서 벗어나십시오. 섹션을 확장하려면 각 단계 번호를 클릭하십시오.
-
1단계. ECR 리포지토리 프로비저닝
이전의 두 단계에서 단일 서비스와 단일 컨테이너 이미지 리포지토리를 사용하여 애플리케이션을 모놀리스로 배포했습니다. 애플리케이션을 3개의 마이크로서비스로 배포하려면 Amazon ECR에서 서비스마다 하나씩 3개의 리포지토리를 프로비저닝해야 합니다
3가지 서비스는 다음과 같습니다.
- users
- threads
- posts
리포지토리를 생성합니다.- Amazon ECR 콘솔로 이동합니다.
- Create Repository(리포지토리 생성)를 선택합니다.
- 리포지토리 이름:
- users
- threads
- posts
- users
- 리포지토리 정보를 기록합니다. [account-id].dkr.ecr.[region].amazonaws.com/[service-name]
♻ 마이크로서비스마다 이러한 단계를 반복합니다.
이제 Amazon ECR에 4개의 리포지토리가 있습니다.
-
2단계. AWS로 Docker 인증(선택 사항)
최근에 이 워크숍의 모듈 1을 이수한 경우 이 단계를 건너뛰어도 됩니다.
- aws ecr get-login --no-include-email --region [region]을 실행합니다.
예: aws ecr get-login --no-include-email --region us-west-2
docker login -u AWS -p ...로 시작하는 방대한 출력이 표시됩니다. 이 전체 출력을 복사하여 붙여 넣고 터미널에서 실행합니다.
Login Succeeded라는 메시지가 나타납니다.
⚐ 참고: 로그인에 실패할 경우 -e none 플래그를 더 이상 지원하지 않는 최신 버전의 Docker를 사용 중이기 때문일 수 있습니다. 이 문제를 해결하려면 출력을 텍스트 편집기에 붙여 넣고, 출력의 끝부분에서 -e none을 제거한 후, 업데이트된 출력을 터미널에서 실행합니다.
- aws ecr get-login --no-include-email --region [region]을 실행합니다.
-
3단계. 각 서비스의 이미지 구축 및 푸시
프로젝트 폴더 amazon-ecs-nodejs-microservices/3-microservices/services에 각 서비스의 파일이 들어 있는 폴더가 있습니다. 기본적으로 각 마이크로서비스는 이전의 모놀리스 서비스의 복제본입니다.
각 서비스와 모놀리스 api 서비스의 db.json 파일을 비교하면 각 서비스가 전문화된 것을 확인할 수 있습니다. 이전에 posts, threads 및 users는 모두 단일 데이터베이스 파일에 저장되었습니다. 이제 각각 해당 서비스의 데이터베이스 파일에 저장됩니다.
터미널을 열고 GitHub 코드의 3-microservices/services 섹션으로 경로를 설정합니다. ~/amazon-ecs-nodejs-microservices/3-microservices/services
각 이미지 구축 및 태그 지정
- 터미널에서 docker build -t [service-name] ./[service-name]을 실행합니다. 예: docker build -t posts ./posts
- 구축이 완료되면 리포지토리로 푸시할 수 있도록 이미지에 태그를 지정합니다. docker tag [service-name]:latest [account-id].dkr.ecr.[region].amazonaws.com/[service-name]:v1 예: docker tag posts:latest [account-id].dkr.ecr.us-west-2.amazonaws.com/posts:v1
- docker push를 실행하여 이미지를 ECR로 푸시합니다. docker push [account-id].dkr.ecr.[region].amazonaws.com/[service-name]:v1
ECR 리포지토리로 이동하면 이미지가 v1으로 태그 지정되어 있는 것을 확인할 수 있습니다.
♻ 마이크로서비스 이미지마다 이러한 단계를 반복합니다.
⚐ 참고: 3개의 이미지를 모두 구축하고 태그를 지정해야 합니다.