VPC 엔트포인트

VPC 엔드포인트를 사용하지 않으면 VPC는 인터넷 게이트웨이 및 NAT 게이트웨이 또는 퍼블릭 IP 주소가 있어야 VPC 외부에서 서버리스 서비스에 액세스할 수 있습니다.

VPC 엔드포인트는 VPC와 지원되는 AWS 서비스 간의 신뢰할 수 있는 경로를 제공합니다. 그러므로 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Driect Connect 연결이 필요하지 않습니다. VPC의 인스턴스는 서비스의 리소스와 통신하는 데 퍼블릭 IP 주소를 필요로 하지 않습니다.

엔트포인트는 가상 디바이스로, 수평으로 크기가 조정되는 고가용성 중복 VPC 구성 요소입니다. 네트워크 트래픽에 가용성 위험이나 대역폭 제약 없이 VPC의 인스턴스와 서비스 간에 통신할 수 있습니다.

게이트웨이 및 인터페이스 VPC 엔드포인트

게이트웨이 VPC 엔드포인트와 인터페이스 VPC 엔드포인트는 AWS 백본을 통해 서비스에 액세스하는 데 도움이 됩니다.

1. 게이트웨이 엔드포인트
   게이트웨이 VPC 엔드포인트(게이트웨이 엔드포인트)는 라우팅 테이블에 있는 경우의 대상으로 고객이 지정하는 게이트웨이입니다. 게이트웨이 엔드포인트는 지원되는 AWS 서비스로 전송되는 트래픽의 대상입니다. AWS 서비스에는 S3 및 DynamoDB가 지원됩니다.
   
   
2. 인터페이스 엔드포인트
   인터페이스 VPC 엔드포인트는 서브넷의 IP 주소 범위에 속하는 프라이빗 IP 주소가 있는 탄력적 네트워크 인터페이스입니다. 네트워크 인터페이스는 지원되는 서비스로 전송되는 트래픽의 진입점 역할을 합니다.

게이트웨이 엔드포인트

게이트웨이 VPC 엔드포인트를 S3 및 DynamoDB로 향하는 트래픽의 라우팅 테이블의 대상으로 지정합니다. 게이트웨이 엔드포인트 용에 따른 추가 요금은 없습니다. 데이터 전송 및 리소스 사용량에 대한 표준 요금이  그대로 적용됩니다.

위 예시에서 퍼블릭 서브넷의 인스턴스 A는 인터넷 게이트웨이를 통해 S3와 통신합니다. 인스턴스 A에는 VPC의 로컬 대상에 대한 경로가 있습니다. 인스턴스 B는 고유한 게이트웨이 엔드포인트를 사용하여 S3 버킷 및 DynamoDB 테이블과 통신합니다. 

프라이빗 라우팅 테이블은 경로를 사용하여 각 게이트웨이 엔드포인트를 통해 S3 및 DynamoDB 요청을 전송합니다. 라우팅 테이블은 접두삿 목록을 사용하여 각 서비스의 대상을 특정 리전으로 지정합니다.

상세

인터페이스 엔드포인트

인터페이스 VPC 엔드포인트를 사용하면 서비스가 VPC 내에 포함되어 있는 것처럼 VPC를 서비스에 프라이빗 방식으로 연결할 수 있습니다. 인터페이스 엔드포인트가 생성되면  VPC에서 라우팅 테이블 변경 없이 트래픽이 새 엔드포인트로 전달됩니다.

위 예시에 나와 있는 리전에서는 에제 VPC 외부에 Systems manager가 있습니다. 예제 VPC에는 퍼블릭 서브넷과 프라이빗 서브넷이 있으며, 각 서브넷에는 EC2 인스턴스가 있습니다. Systems Manager 트래픽은 프라이빗 서브넷의 탄력적 네트워크 인터페이스로 전송됩니다.

상세

ECS(Elastic Container Service)

ECS는 Docker 컨테이너를 지원하는 확장성이 뛰어난 컨테이너 관리 서비스입니다. ECS는 컨테이너화된 애플리케이션의 크기 조정, 유지 관리 및 연결을 관리합니다.

ECS를 사용하면 ECS 태스크를 시작하는 ECS 서비스를 생성할 수 있습니다. ECS 태스크는 하나 이상의 컨테이너 이미지를 사용할 수 있습니다. ECS 서비스는 애플리케이션의 수요를 충족하도록 실행 중인 태스크 수를 조정합니다.

애플리케이션을 위한 전용 인프라를 갖춘 ECS 클러스터를 생성합니다. AWS Fargate에서 관리하는 서버리스 인프라에서 태스크 및 서비스를 실행할 수 있습니다. 인프라를 더 효과적으로 제어하려는 경우 EC2 인스턴스의 클러스터에서 태스크 및 서비스를 관리할 수 있습니다. EC2 인스턴스를 클러스터에 추가하거나 클러스터에서 제거하여 클러스터의 EC2 호스팅 용량 크기를 조절할 수 있습니다.

ECS를 사용하면 클러스터 관리 및 구성 관리 시스템을 직접 운영하거나 관리 인프라의 크기 조정에 대해 걱정할 필요가 없습니다.

기능

ECS는 다음과 같은 기능을 제공합니다.

1. 완전관리형
   ECS는 완전관리형 서비스이므로 컨트롤 플레인, 노드 또는 추가 기능을 관리할 필요가 없습니다. 그러므로 팀이 환경 관리가 아닌 애플리케이션 구축 작업만 중점적으로 수행할 수 있습니다.
   
   
2. 서비스 검색
   ECS에서는 서비스 검색이 지원됩니다. 서비스 검색 기능을 사용하면 도메인 이름 시스템(DNS) 이름에 ECS 서비스를 등록할 수 있습니다. 예를 들어 "backend" 서비스는 backend.example 등의 프라이빗 DNS 네임스페이스에 등록하고 "frontend" 서비스는 frontend.example과 함께 등록할 수 있습니다. 그런 다음 이러한 서비스를 구성하여 동일한 VPC내에서 서로 검색할 수 있습니다. 서비스 검색을 사용하면 마이크로서비스 구성 요소가 생성 및 종료될 때 자동으로 검색되어 네임스페이스에 추가됩니다.
   
   
3. AWS 통합
   ECS는 다음과 같은 여러 AWS 서비스와 통합할 수 있습니다.
   • ECR
     컨테이너화된 애플리케이션이 원활하게 컨테이너 이미지에 액세스하여 해당 이미지를 실행할 수 있습니다.
   • IAM(Identity Access managemen)
     각 컨테이너에 세분화된 권한을 배정할 수 있습니다. 그러면 애플리케이션 구축 시에 컨테이너를 높은 수준의 격리가 가능합니다.
   • CloudWatch Logs 및 Container Insights
     컨테이너화된 애플리케이션과 인스턴스의 로그를 한 곳에서 편리하게 확인할 수 있습니다.
4. 유연한 호스팅 옵션
   ECS에서는 EC2, 그리고 AWS Fargate를 통한 서버리스 호스팅을 모두 사용할 수 있습니다. 리소스 요구 사항, 격리 정책 및 가용성 요구 사항에 따라 클러스터 전체에 컨테이너 배치를 예약할 수  있습니다.
   
   
5. 개발 워크플로
   ECS는 지속적 통합/지속적 배포(CI/CD)를 지원합니다. Docker 컨테이너 기반 마이크로서비스 아키텍처에서는 일반적인 프로세스입니다. 다음 작업을 수행하는 CI/CD 파이프라인을 생성할 수 있습니다.
   • 소스 코드 리포지토리의 변경 사항 모니터링
   • 해당 소스에서 새 Docker 이미지 구축
   • ECR, Docker Hub 등의 이미지 리포지토리에 이미지 푸시
   • 애플리케이션에서 새 이미지를 사용하도록 ECS 서비스 업데이트

상세

EKS(Elastic Kubernetes Service)

Kubernetes(이하 K8s)는 컨테이너화된 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어입니다. K8s는 EC2 컴퓨팅 인스턴스의 클러스터를 관리하고 배포, 유지 관리 및 스케일링의 프로세스를 통해 이러한 인스턴스에서 컨테이너를 실행합니다. K8s를 사용하면 온프레미스나 클라우드에서 동일한 도구들을 사용하여 원하는 유형의 컨테이너화된 애플리케이션을 실행할 수 있습니다.

EKS는 준수 인증을 받은 관리형 Kubernetes 서비스입니다. EKS는 고가용성의 안전한 클러스터를 제공하는 데 도움이 되며 패치 적용, 노드 프로비저닝 및 업데이트와 같은 주요 태스크를 자동화합니다. 이외에도 다음과 같은 기능들이 있습니다.

• 대규모로 애플리케이션 실행 - 복잡한 컨테이너형 애플리케이션을 정의하고 서버 클러스터 전체에서 대구모로 실행할 수 있습니다.
• 애플리케이션을 원활하게 이전 - 컨테이너화된 애플리케이션을 로컬 개발 시스템에서 클라우드의 프로덕션 이전할 수 있습니다.
• 어디서든 실행 - 가용성 및 확장성이 뛰어난 K8s 클러스터를 실행할 수 있습니다.

상세

EKS 솔루션

EKS는 자체 K8s 클러스터를 설치 및 운영할 필요 없이 AWS에서 K8s를 쉽게 실행할 수 있도록 해주는 관리형 서비스입니다. EKS를 사용하면 AWS에서 고가용성 서비스 및 업그레이드를 사용자 대신 관리합니다. EKS는 세 가용 영역에서 3개의 K8s관리자를 실행합니다. EKS는 비정상 관리자를 탐지하여 교체하고 관리자에 대한 버전 업그레이드 및 패치를 자동으로 실행합니다. 또한, EKS는 다양한 AWS 서비스와 통합되어 애플리케이션에 확장성과 보안을 제공합니다.

EKS는 최신 버전의 오픈 소스 K8s 소프트웨어를 실행하므로, K8s 커뮤니티의 기존 플러그인과 도구를 모두 사용할 수 있습니다. EKS에서 실행되는 애플리케이션은 모든 표준 K8s 환경에서 실행되는 애플리케이션과 완벽하게 호환됩니다. 애플리케이션 실행 위치에 관계없이 호환성이 보장됩니다.

Fargate

Fargate는 서버 또는 클러스터를 관리할 필요 없이 컨테이너를 실행하는 데 사용할 수 있는 ECS와 EKS를 위한 기술입니다. Fargate를 사용하면 더 이상 컨테이너를 실행하기 위해 VM 클러스터를 프로비저닝 및 구성하고 크기를 조정할 필요가 없습니다. 따라서 서버 유형을 선택하거나, 클러스터 크기 조정 시점을 결정하거나, 클러스터 패킹을 최적화할 필요가 없습니다.

Fargate에서는 서버 또는 클러스터에 대해 고민하거나 상호 작용할 필요가 없습니다. Fargate를 사용하면 애플리케이션을 실행하는 인프라의 관리 대신 애플리케이션 설계 및 구축에 집중할 수 있습니다.

컨테이너 서비스 선택 기준

AWS에 관리형 컨테이너 솔루션을 배포하려면 오케스트레이션 도구와 시작 유형을 선택해야 합니다.

컨테이너화된 애플리케이션 관리

• ECS에서는 수동 구성 작업은 줄이면서 다른 AWS 서비스와 더 쉽게 통합할 수 있는 관리형 솔루션을 제공합니다.
• EKS에서는 자체 K8s 클러스터를 설치 및 운영할 필요 없이 AWS 클라우드 또는 온프레미스에서 K8s 애플리케이션을 유동적으로 시작 및 실행하고 크기를 조정할 수 있습니다. 이 옵션은 오픈 소스 도구를 사용하는 조직에 적합합니다. EKS를 사용하려면 구성을 추가로 수행해야 하지만 환경을 더욱 잘 제어할 수 있습니다.

컨테이너 호스팅

• EC2에서 컨테이너를 호스트하려면 구성을 추가로 수행해야 합니다. 그러나 컨테이너를 호스트하는 데 사용하는 리소스를 더욱 자세하게 제어할 수 있습니다. 또한 EC2에서는 더욱 비용 효율적으로 컨테이너를 호스트할 수 있습니다.
• Fargate에서 컨테이너를 호스팅할 때는 서버리스 기술을 사용하는 자율 컨테이너 운영 기능이 제공됩니다. 그러믈 ㅗ구성, 패치 적용 및 보안관련 작업에 소요되는 시간을 줄일 수 있습니다.

AWS에서 컨테이너 실행

AWS에 관리형 컨테이너 솔루션을 배포하려면 다음 구성 요소를 선택하고 구성해야 합니다.

1. 레지스트리
   컨테이너화된 애플리케이션을 개발할 대는 컨테이너를 실행하는 데 필요한 모든 항목이 포함된 컨테이너 이미지를 구축합니다. 이러한 항목으로는 애플리케이션 코드, 런타임, 시스템 도구, 시스템 라이브러리, 설정 등이 포함됩니다. 그런 다음 버전 제어를 위해 이미지를 리포지토리에 푸시하고 해당 이미지를 리포지토리에서 끌어와 컨테이너를 배포합니다. 레지스트리는 리포지토리 모음입니다.
   
   AWS는 다른 AWS 서비스와 통합을 지원하는 컨테이너 이미지 레지스트리로 ECR을 제공합니다.
   
   
2. 오케스트레이션 도구
   컨테이너 오케스트레이션 도구를 사용하여 컨테이너화된 애플리케이션을 규모에 맞게 관리할 수 있습니다. 오케스트레이션 도구는 컨테이너의 크기 조정, 네트워킹 및 유지 관리 작업을 관리합니다. 컨테이너 시작 및 종료 관리, 컨테이너 상태 모니터링, 업데이트 배포 및 장애 조치 및 복구 관리에 도움이 됩니다.
   
   • EKS
     AWS에서 Kubernetes 컨테이너 오케스트레이션 소프트웨어를 실행하는 데 사용할 수 있는 관리형 서비스입니다. 구성을 추가로 제어해야 하는 경우 이 옵션을 선택할 수 있습니다.
   • ECS
     컨테이너 배포 보다는 관리된 모델을 제공하는 관리형 컨테이너 오케스트레이션 서비스입니다. ECS에서는 기타 AWS 서비스와의 통합 기능도 추가로 제공됩니다.
     
     
3. 컨테이너 호스팅
   오케스트레이션 도구가 컨테이너를 호스트하는 데 사용하도록 할 컴퓨팅 리소스를 결정해야 합니다. 이러한 리소스를 컨테이너의 시작 유형이라고도 합니다.
   • EC2를 선택하여 다양한 인스턴스 유형에서 컨테이너를 시작할 수 있습니다. 수요가 변경되면 컨테이너를 호스트하는 데 사용되는 EC2 인스턴스 수를 확장 및 축소할 수 있습니다. 이 방법은 비용 효율성이 우수하며, 인스턴스 유형을 더욱 효과적으로 제어할 수 있습니다.
   • Fargate는 컨테이너를 지원하기 위해 CPU 및 메모리 리소스를 자동으로 할당하는 서버리스 호스팅 서비스입니다. Fargate 사용 시에는 기본 컴퓨팅 리소스를 프로비저닝하거나 관리할 필요가 없습니다.

ECR(Elastic Container Registry)

ECR은 관리형 Docker 컨테이너 레지스트리입니다. 컨테이너 이미지리를 ECR로 푸시한 후 이미지를 끌어와서 컨테이너를 시작할 수 있습니다. ECR을 사용하면 컨테이너 이미지에 대한 압축, 암호화 및 제어할 수 있습니다. 또한 버전 관리 및 이미지 태그도 관리할 수 있습니다. 각 AWS 계정에 ECR 프라이빗 레지스트리가 제공됩니다. 레지스트리에 리포지토리를 하나 이상 생성한 후 리포지토리에 이미지를 저장할 수 있습니다.

위 예시에서는 컨테이너를 사용하여 모놀리스 포럼 애플리케이션을 마이크로서비스로 리팩터링합니다. 리팩터링에서는 코드를 사용자 서비스, 주제 서비스 및 메시지 서비스와 같은 개별 캡슐화된 서비스로 분할합니다. 이러한 각 서비스에 대해 컨테이너 이미지를 구축하면 독립적으로 시작, 업데이트 및 종료할 수 있습니다. 이 예에서는 각 서비스의 컨테이너 이미지가 각 이미지의 여러 버전을 저장하는 자체 리포지토리로 푸시됩니다. 오케스트레이션 서비스는 필요에 따라 이러한 컨테이너 이미지를 끌어와 새 컨테이너를 배포할 수 있습니다.

컨테이너

마이크로서비스 지향적 아키텍처의 이점은 인프라 수준까지 전파되어야 합니다. 이 목표를 컨테이너를 통해 달성할 수 있습니다.

클라우드에서 가상 장치를 실행하면 동적이고 탄력적인 환경이 확보되지만, 개발자의 프로세스를 단순화할 수 있습니다. 컨테이너는 애플리케이션의 코드, 구성 및 종속성을 하나의 객체로 패키징하는 표준화된 방식을 제공합니다.

컨테이너는 서버에 설치된 운영 체제를 공유하며 리소스가 격리된 프로세스 형태로 실행되므로 환경에 상관없이 빠르고 안정적이며 일관된 배포를 진행할 수 있습니다.

컨테이너와 마이크로서비스

컨테이너는 확장성과 이동성이 뛰어나며 지속적인 배포가 가능하므로 마이크로서비스 아키텍처에 이상적인 선택입니다.

마이크로서비스 아키텍처는 전통적인 모놀리식 아키텍처를 서비스로 실행되고 경량 API를 통해 통신하는 독립된 구성 요소들로 분해합니다. 이러한 마이크로서비스 환경에서는 복원력, 효율성, 그리고 전반적인 민첩성이 향상되어 반복 작업을 신속하게 처리할 수 있습니다.

각 마이크로서비스를 컨테이너에 구축할 수 있습니다. 각 마이크로서비스는 별도의 구성 요소이므로 장애를 더 잘 견딜 수 있습니다. 컨테이너에 장애가 발생할 경우 컨테이너를 종료하고 그 특정 서비스에 새 컨테이너를 신속하게 시작할 수 있습니다. 특정 서비스에 트래픽이 많은 경우 그 마으크로서비스를 처리하는 컨테이너를 스케일 아웃할 수 있습니다. 이러한 구성 방식으로 인해 전체 애플리케이션을 지원하기 위해 서버를 추가로 배포할 필요가 없습니다. 마이크로서비스와 컨테이너는 지속적 배포에도 적합합니다. 애플리케이션의 다른 구성 요소에 영향을 주지 않고 개별 서비스를 업데이트할 수 있습니다.

가상화 및 추상화 수준

베어 메탈 서버는 라이브러리를 사용하여 하나 이상의 애플리케이션으로 독립 실행형 OS를 실행합니다. 서버의 사용률이 0%이든 100%이든 관계없이 비용이 일정하게 유지됩니다. 크기를 조정하려면 서버를추가로 구매하여 구성해야 합니다. 그리고 여러 서버에서 작동하는 애플리케이션을 구축하기도 어렵습니다. 이러한 서버의 OS가 동일해야 하기 때문입니다. 뿐만 아니라 애플리케이션 라이브러리 버전도 동기화해야 합니다.

가성 장치를 사용하여 애플리케이션 및 해당 라이브러리를 자체 OS 전체와 함께 격리할 수 있습니다. VM의 단점은 가상화 계층이 무겁다는 것입니다. 각 VM은 자체 OS를 사용하므로 호스트 CPU와 RAM이 더 많이 필요합니다. 따라서 효율성과 성능이 낮아집니다. VM마다 개별 OS가 있다는 것은 물리적 호스트에서 더 많은 패치와 더 많은 업데이트, 더 많은 공간을 차지한다는 뜻이기도 합니다.

컨테이너화를 수행하면 컨테이너는 시스템의 OS 시스템 커널을 공유하며 기본 OS 파일 시스템이 노출됩니다. 시스템의 OS 시스템 커널을 공유하면 공유 라이브러리를 사용할 수 있으며 필요에 따라 개별 라이브러리도 사용할 수 있습니다. 그러므로 컨테이너는 휴대성이 뛰어납니다. 또한 컨테이너는 VM보다 빠르게 시작하고 중지할 수 있습니다. 컨테이너는 가볍고 효율적이며 빠릅니다.

VM과 달리 컨테이너는 적절한 커널 기능이 지원되며 Docker daemon이 있는 어떤 Linux 시스템에서나 실행할 수 있으므로 휴대성이 뛰어납니다. 랩톱, VM, EC2 인스턴스, 베어 메탈 서버에 호스트할 수 있습니다. 또한, 하이퍼바이저가 필요 없다는 것은 성능 오버헤드가 거의 발생하지 않는다고 볼 수 있습니다. 프로세스가 커널과 직접 커뮤니케이션하며, 대체로 다른 독립 컨테이너에 대해서는 인식하지 못합니다. 대부분의 컨테이너는 몇 초 이내로 부팅이 완료됩니다.

AWS 컨테이너

AWS에서 컨테이너를 실행할 때 여러 옵션을 사용할 수 있습니다. 일반적으로는 EC2 인스턴스를 기반으로 컨테이너를 실행하고 VM 배포 및 컨테이너화의 요소를 사용하게 됩니다.

위 그림에서는 물리적 서버, 하이퍼바이저, 가상 게스트 OS 2개가 포함된 기본 서버 인프라가 나와있습니다. 운영 체제 중 하나는 Docker를 실행하고 다른 하나는 별도의 애플리케이션을 실행합니다.  Docker가 설치된 가상 게스트 OS는 컨테이너를 빌드하고 실행할 수 있습니다. 이러한 유형의 배포는 사용되는 EC2 인스턴스 크기까지만 조정이 가능합니다. 또한 컨테이너의 네트워킹, 액세스 및 유지 관리를 고객이 직접 관리해야 합니다.

오케스트레이션 도구는 AWS에서 컨테이너를 실행하기 위한 확장 가능 솔루션입니다. 오케스트레이션 도구는 수백 개의 EC2 인스턴스를 포함하여 컨테이너를 호스팅할 수 있는 컴퓨팅 리소스 풀을 사용합니다. 오케스트레이션 도구는 애플리케이션의 수요가 변경됨에 따라 컨테이너를 시작하고 종료합니다. 그리고 컨테이너의 연결을 관리합니다. 또한 컨테이너 배포 및 업데이트를 관리하는 데에도 도움이 됩니다.

OS

Operating System (OS)은 컴퓨터 하드웨어와 소프트웨어 사이의 인터페이스 역할을 하는 핵심 소프트웨어입니다. OS는 컴퓨터의 자원을 효율적으로 관리하고, 사용자가 컴퓨터를 쉽게 사용할 수 있도록 도와줍니다. 즉, 하드웨어와 사용자 간의 중재자 역할을 수행합니다.

OS는 스스로 어떠한 기능을 수행하기 보다 다른 응용프로그램이 작업을 원활히 진행할 수 있도록 작업 환경을 마련해줍니다. 즉, 응용프로그램을 운영(Operating)하기 쉽도록 만든 시스템(System)이라고 생각하면 좋을 것 같습니다.

주요 기능

• 하드웨어 자원 관리: CPU, 메모리, 입출력 장치 등 컴퓨터의 자원을 효율적으로 관리합니다.
• 프로세스 관리: 여러 개의 프로그램을 동시에 실행할 수 있도록 프로세스를 생성, 관리, 종료합니다.
• 메모리 관리: 프로그램이 사용할 메모리를 할당하고, 사용이 끝난 메모리를 회수합니다.
• 파일 관리: 파일을 생성, 삭제, 수정, 액세스하는 기능을 제공합니다.
• 장치 드라이버 관리: 하드웨어 장치와 통신할 수 있도록 장치 드라이버를 관리합니다.

유형

• 단일 사용자/단일 작업 OS: 한 번에 한 명의 사용자만 사용하고, 한 번에 하나의 프로그램만 실행할 수 있습니다. 예를 들어, MS-DOS, CP/M 등이 있습니다.
• 다중 사용자/다중 작업 OS: 여러 명의 사용자가 동시에 사용할 수 있고, 여러 개의 프로그램을 동시에 실행할 수 있습니다. 예를 들어, Windows, macOS, Linux 등이 있습니다.

서버 결합 방식

기존 모놀리식 인프라의 경우 강력하게 통합된 서버 체인을 중심으로 움직이며 각 서버는 특정 목적을 가지고 있습니다. 이러한 구성 요소 또는 계층 중 하나에 중단이 발생하면 시스템에 치명적인 영향을 줄 수 있습니다. 이 구성은 크기 조정에도 악영향을 미칩니다. 한 계층에 서버를 추가하거나 제거하는 경우, 모든 계층의 모든 서버도 연결해야 합니다.  또한 강하게 결합된 아키텍처에서 한 애플리케이션 서버가 다운될 경우 웹 서버와 애플리케이션 간의 연결에서 오류가 발생할 수 있습니다.

반면 느슨한 결합을 사용하는 경우 관리형 솔루션을 시스템 계층 간의 중간자로 사용할 수 있습니다. 이렇게 하면 중계자가 구성 요소를 분리하는 주요 솔루션 중 2가지는 로드 밸런서와 메시지 대기열입니다. 예를들어 로드밸런서를 사용해 웹 서버와 애플리케이션 서버간 요청을 라우팅한다면, 한 서버에 장애가 발생해도 로드 밸런서가 모든 트래픽을 자동으로 정상 서버로 보내기 시작합니다.

마이크로서비스

마이크로서비스는 소프트웨어 개발에 대한 구조적이고 조직적 접근 방식입니다. 마이크로서비스 방식을 사용하면 소프트웨어를 소규모 서비스 모음으로 설계할 수 있습니다. 각 서비스는 독립적으로 배포되고 잘 정의된 API를 통해 통신합니다. 이 프로세스를 진행하면 배포 주기가 가속화되고, 혁신이 촉진되며, 애플리케이션의 유지 관리와 확장성이 모두 향상될 수 있습니다.

마이크로 서비스는 다음과 같은 특징이 있습니다.

1. 자율적
   마이크로서비스 아키텍처의 구성 요소 서비스는 서로 분리되어 있고 API를 통해 통신합니다. 그러므로 다른 서비스에 영향을 주지 않고 서비스를 개발, 업데이트, 배포, 운영하고 크기를 조정할 수 있습니다. 소규모 자율 팀이 이러한 서비스를 소유할 수 있으므로 민첩하게 관련 작업을 처리할 수 있습니다.
   
   
2. 전문적
   특정 문제를 중점적으로 해결하는 일련의 기능을 제공하도록 각 서비스를 설계합니다. 팀은 해당 서비스에 가장 적합한 프로그래밍 언어로 각 서비스를 작성할 수 있습니다. 그리고 각기 다른 컴퓨팅 리소스에서 서비스를 호스트할 수도 있습니다.

상세

모놀리식 아키텍처

모놀리식 아키텍처는 하나의 코드 베이스를 사용하여 여러 비즈니스 기능을 수행하는 소프트웨어 개발 모델입니다. 모놀리식 시스템의 모든 소프트웨어 구성 요소는 시스템 내의 데이터 교환 메커니즘으로 인해 상호 의존적인 성질이 있습니다.

모놀리식 아키텍처는 소프트웨어 개발의 가장 오래된 모델 중 하나이며, 여전히 많은 소프트웨어 시스템에서 사용됩니다.

모놀리식 아키텍처의 장점은 다음과 같습니다.

• 단순성: 모든 코드가 단일 코드 베이스에 있으므로 개발 및 유지 관리가 쉽습니다.
• 성능: 모든 구성 요소가 단일 프로세스에서 실행되므로 성능이 뛰어납니다.
• 확장성: 시스템의 요구 사항이 증가하면 서버를 추가하여 확장할 수 있습니다.

그러나 모놀리식 아키텍처는 다음과 같은 단점도 있습니다.

• 변경의 어려움: 한 구성 요소를 변경하면 다른 구성 요소에 영향을 미칠 수 있으므로 변경이 어렵습니다.
• 테스트의 어려움: 모든 구성 요소를 함께 테스트해야 하므로 테스트가 어렵습니다.
• 확장성의 한계: 시스템이 복잡해지면 확장성이 한계에 도달할 수 있습니다.

모놀리식 아키텍처는 다음과 같은 경우에 적합합니다.

• 시스템이 작고 복잡하지 않을 때
• 시스템의 요구 사항이 안정적이고 변경 가능성이 적을 때
• 시스템의 성능이 중요하거나 확장성이 필요할 때

마이크로서비스 아키텍처

마이크로서비스 아키텍처는 대규모 애플리케이션을 작은 규모의 독립적인 서비스로 분리하여 개발하는 아키텍처 스타일입니다. 각 서비스는 하나의 비즈니스 기능을 수행하며, 서로 느슨하게 결합되어 있습니다.

마이크로서비스 아키텍처는 다음과 같은 장점을 제공합니다.

• 변경의 용이성: 한 서비스만 변경하면 다른 서비스에 영향을 미치지 않습니다. 따라서 새로운 기능을 추가하거나 기존 기능을 변경하는 것이 쉽습니다.
• 테스트의 용이성: 서비스별로 테스트할 수 있으므로 테스트가 쉽고 빠릅니다.
• 확장성의 향상: 서비스별로 확장할 수 있으므로 시스템의 요구 사항에 따라 쉽게 확장할 수 있습니다.
• 기술의 혼합: 각 서비스는 독립적인 기술 스택을 사용할 수 있으므로 최적의 기술을 선택할 수 있습니다.

그러나 마이크로서비스 아키텍처는 다음과 같은 단점도 있습니다.

• 복잡성: 구성 요소가 많아지고 의존성이 복잡해집니다.
• 관리의 어려움: 여러 서비스를 관리해야 합니다.
• 성능의 저하: 서비스 간 통신으로 인해 성능이 저하될 수 있습니다.

마이크로서비스 아키텍처는 다음과 같은 경우에 적합합니다.

• 시스템이 복잡하고 요구 사항이 자주 변경되는 경우
• 새로운 기능을 빠르게 출시해야 하는 경우
• 기술의 혼합이 필요한 경우

마이크로서비스 아키텍처를 구현하기 위해서는 다음과 같은 사항을 고려해야 합니다.

• 서비스의 분할: 비즈니스 기능을 기반으로 서비스를 분할해야 합니다.
• 서비스 간의 통신: 서비스 간 통신은 느슨하게 결합되어야 합니다.
• 서비스의 배포: 서비스는 독립적으로 배포할 수 있어야 합니다.
• 서비스의 관리: 서비스의 상태와 성능을 모니터링하고 관리해야 합니다.

마이크로서비스 아키텍처는 모놀리식 아키텍처의 단점을 보완하고, 현대 소프트웨어 시스템의 요구 사항을 충족하는 아키텍처 스타일입니다. 그러나 마이크로서비스 아키텍처는 복잡하고 관리가 어려울 수 있으므로, 시스템의 특성에 맞게 적절하게 적용하는 것이 중요합니다.

마이크로서비스 아키텍처를 구현하기 위한 몇 가지 주요 기술은 다음과 같습니다.

• API: 서비스 간의 통신은 API를 통해 이루어집니다.
• 컨테이너화: 서비스는 컨테이너로 실행하여 이동성과 확장성을 향상시킬 수 있습니다.
• 마이크로서비스 플랫폼: 마이크로서비스 플랫폼은 서비스의 배포, 관리, 모니터링을 지원하는 도구와 서비스를 제공합니다.

최근에는 마이크로서비스 아키텍처를 구현하기 위한 다양한 도구와 프레임워크가 제공되고 있습니다. 이러한 도구와 프레임워크를 활용하면 마이크로서비스 아키텍처를 보다 쉽게 구현하고 관리할 수 있습니다.

인프라 도구

인프라 배포 도구를 선택할 때는 편의성과 제어 가능 범위를 모두 적절하게 고려해야 합니다. 일부 도구는 완전한 제어 기능을 제공하며 모든 구성 요소 및 구성을 선택하도록 할 수 있습니다. 비즈니스 요구 사항에 맞게 배포를 사용자 지정할 수는 있지만, 이 방법을 사용하려면 더 높은 수준의 전문 지식과 관리 및 유지 관리에 더 많은 리소스가 필요합니다.

다른 도구는 편의를 위해 설계되었으며 미리 구성된 일반 솔루션용 인프라 템플릿이 포함되어 있는 도구도 있습니다. 이러한 도구는 더 간편하게 사용할 수 있으며 유지 관리 작업도 더 적지만, 인프라 구성 욧를 사용자 지정하지 못할 수 있습니다. 다음 도구를 이용하여 인프라 배포를 자동화할 수 있습니다.

• Elastic Beanstalk
  개발자 도구와 통합되며 애플리케이션 수명 주기를 한 곳에서 관리할 수 있는 환경을 제공합니다. 이 도구는 애플리케이션 지원을 위해 애플리케이션 인프라를 프로비저닝하고 관리합니다.
• Solutions Library
  광범위한 산업 및 기술 사용 사례를 위해 AWS와 AWS Partner가 구축한 솔루션을 제공합니다. 이러한 솔루션에는 CloudFormation 템플릿, 스크립트, 참조 아키텍처 등 작업을 빠르게 시작하는 데 필요한 도구가 포함됩니다.
• Cloud Debelopment Kit(CDK)
  일반적인 프로그래밍 언어를 사용하여 애플리케이션 리소스를 모델링 및 프로비저닝할 수 있는 오픈 소스 소프트웨어 개발 프레임워크입니다. AWS CDK를 사용하면 CloudForamtion 템플릿을 간편하게 생성 및 배포할 수 있습니다. CDK는 모범 사례에 따라 미리 구성된 구성 요소 그룹과 인프라 구성 요소를 제공합니다. 하지만 구성 요소와 해당 설정은 사용자 지정할 수 있습니다.
• AWS CloudFormation
  모든 리소스와 해당 구성을 정의할 수 있습니다. 그리고 인프라의 모든 구성 요소를 세부적으로 제어할 수 있습니다.

관리 도구인 AWS Systems Manager를 사용하면 AWS에서 인프라를 보고 제어할 수 있습니다. 다양한 유지 관리 및 배포 태스크를 자동화하거나 예약할 수 있습니다.

관리와 유지 관리

관리는 시스템 또는 자산의 상태를 감독하고 계획하고 조직하는 프로세스입니다. 관리에는 목표 설정, 예산 편성, 자원 배분, 의사 결정, 모니터링, 평가 등이 포함됩니다.

유지 관리는 시스템 또는 자산의 상태를 최상의 상태로 유지하기 위한 활동의 집합입니다. 유지 관리에는 예방적 유지 관리, 고장 수리, 보조 활동 등이 포함됩니다.

Elastic Beanstalk

Elastic  Beanstalk의 목표는 개발자가 기본 인프라에 대해 걱정할 필요 없이 클라우드에 확장 가능한 웹 애플리케이션 및 서비스를 배포하고 유지 관리하도록 돕는 것입니다. 이 도구는 환경 내 각 EC2 인스턴스를 선택한 애플리케이션 유형에 맞는 애플리케이션을 실행하는 데 필요한 구성 요소로 구성합니다. 애플리케이션 스택을 설치하고 구성하기 위하여 인스턴스에 로깅하는 작업에 대해 걱정할 필요가 없습니다. 이 도구를 사용할 시에는 웹 애플리케이션, 작업자 서비스 등의 일반 애플리케이션 설계를 지원하는 인프라를 프로비저닝할 수 있습니다.

AWS 솔루션 라이브러리

AWS Solutions Library를 활용하면 AWS를 통해 솔루션을 더욱 빠르게 구축하고 일반적인 문제를 해결할 수 있습니다. AWS 아키텍트가 검증한 라이브러리 내의 솔루션은 운영 효율성, 신뢰성, 안정성 및 비용 효율성이 매우 우수합니다. 대다수 AWS 솔루션에는 사전 구축된 CloudFormation  템플릿이 포함되어 있습니다. 그리고 세부 아키텍처, 배포 가이드, 자동/수동 배포 지침도 포함될 수 있습니다. 이 환경을 생성하고 실행하는 데 ㅇ사용하는 리소스에 해당하는 요금이 부과됩니다.

자세한 내용

AWS CDK

CDK는 개발자가 잘 알고 있는 프로그래밍 언어와 선언적 모델을 사용하여 클라우드 애플리케이션 리소스를 정의할 수 있는 소프트웨어 개발 프레임워크입니다. CDK에는 사용자 지정 가능 구문 라이브러리가 포함되어 있습니다. 공통 구성을 포함하는 이러한 구문은 하나 이상의 리소스로 구성된 빌딩 블록입니다. AWS CDK를 사용해 CloudFormation 템플릿을 생성하고  애플리케이션 런타임 자산과 함께 인프라를 배포할 수 있습니다.

 AWS CDK에서는 Python, JavaScript, TypeScript, Java, C# 등의 일반 프로그래밍 언어를 사용할 수 있습니다.

AWS Systems Manager

인프라를 설꼐할 때는 인프라 관리를 계획해야 합니다. 이 계획은 인프라 배포 방식에 영향을 줍니다. 관리 도구에 올바른 보안 정책을 적용해야 하기 때문입니다. 또한 인스턴스에  관리 에이전트를 설치해야 할 수도 있습니다.

AWS Systems Manager를 사용하는 경우 중앙 위치에서 AWS 리소스를 확인하고 관리할 수 있으므로 운영 과정을 완벽하게 파악하여 제어할 수 있습니다. 또한, 이 도구를 활용해 다음과 같은 작업을 수행할 수 있습니다.

• 애플리케이션, 애플리케이션 스택의 여러 계층 또는 개발/프로덕션 환경과 같은 논리적 리소스 그룹을 생성할 수 있습니다.
• 리소스 그룹을 선택하고 최근 API 작업, 리소스 구성 변경 사항, 관련 알림, 운영 경보, 소프트웨어 인벤토리 및 패치 규정 준수 상태를 확인할 수 있습니다.
• 운영 요구에 따라 각 리소스 그룹에서 작업을 수행할 수 있습니다.
• 여러 AWS 서비스의 운영 데이터를 중앙집중화하고 AWS 리소스 전체에서 태스크를 자동화할 수 있습니다.

EC2 콘솔에서 Systems Manager를 열 수 있습니다. 그런 다음 관리할 인스턴스를 선택하고 수행할 관리 태스크를 정의합니다. 무료로 제공되는 Systems Manager를 통해 EC2 리소스와 온프레미스 리소스를 관리할 수 있습니다.

상세

CloudFormation

CloudFormation은 기본적으로 API 래퍼입니다. AWS 관리 콘에서 EC2 인스턴스를 생성하면 EC2 서비스에 대한 API 호출이 시작됩니다. 마법사를 통해 입력하는 정보는 파라미터로 전달됩니다.

CloudFormation은 이러한 API를 사용합니다. AWS 관리 콘솔에서와 같이, CloudFormation 템플릿에서 정의하는 리소스가 AWS 서비스로 전송되는 API 호출로 변환됩니다. CloudFormation은 종속성과 관계를 관리합니다.

원하는 코드 편집기를 사용하여 CloudFormation 템플릿을 작성한 후 GitHub 또는 CodeCommit 같은 버전 관리 시스템에 체크인합니다. 그리고 배포 전에 파일을 검토합니다.

CloudFormation은 모든 AWS 리전에서 사용 가능하며, 사용하는 리소스에 대해서만 요금을 지불합니다.

CloudFormation 템플릿과 관련하여 추가로 확인해야 하는 사항은 다음과 같습니다.

• Git, Subversion(SVN) 등 선택한 버전 제어 시스템을 사용하여 CloudFormation 템플릿을 관리할 수 있습니다.
• JSON 템플릿 파일에서 전체 애플리케이션 스택(애플리케이션에 필요한 모든 리소스)을 정의합니다.
• 템플릿에 대한 런타임 파라미터를 정의합니다(EC2 인스턴스 크기, EC2 키 페어 등).
• CloudFormation 관리 범위 외부에서 AWS 리소스를 생성한 경우 리소스 가져오기를 사용하여 해당 기존 리소스를 CloudFormation 관리 범위 내로 가져올 수 있습니다.

YAML 형식 CloudFormation 템플릿은 기존 JSON 서식 템플릿과 같은 구조를 따르며 동일 기능을 모두 지원합니다.

스택

스택의 모든 리소스는 해당 스택의 CloudFormation 템플릿을 통해 정의됩니다. 스택을 생성, 업데이트 또는 삭제하여 리소스 모음을 관리할 수 있습니다. 예를 들어 웹 서버, DB, 네트워킹 규칙 등 웹 애플리케이션을 실행하는 데 필요한 모든 리소스를 포함할 수 있습니다. 더 이상 웹 애플리케이션이 필요하지 않은 경우 스택을 삭제할 수 있습니다. 그러면 관린 리소스가 모두 삭제됩니다.

CloudFormation은 스택 리소스를 하나의 단위로 취급합니다. 스택이 생성 또는 삭제되려면 모든 리소스가 성공적으로 생성 삭제 되어야 합니다. 리소스를 생성할 수 없는 경우 CloudFormation은 모든 리소스가 생성될 때까지 스택을 롤백합니다. 리소스를 삭제할 수 없는 경우 CloudFormation은 전체 스택이 성공적으로 삭제될 수 있을 때까지 나머지 리소슨느 유지됩니다.

스택 설정이나 스택의 리소스를 변경해야 하는 경우 스택을 삭제하고 새로 생성하는 대신 스택을 업데이트합니다. 실행 중인 스택을 변경하려면 수정된 템플릿이나 새 입력 파라미터 값 중 하나 또는 두 가지를 모두 제공하여 변경 내용을 제출합니다. 그러면 CloudFormation은 스택을 제출한 변경 사항과 비교하여 변경 세트를 생성합니다.

사용 설명서

여러 템플릿 사용

계층형 아키텍처에서는 스택이 여러 수평 계층으로 구성됩니다. 각 계층은 중첩 구축됩니다. 각 계층은 바로 하위 계층에 대한 종속성을 가집니다. 각 계층에 하나 이상의 스택을 포함할 수 있지만, 각 계층 내의 스택은 수명 주기 및 소유권이 유사한 AWS 리소스를 포함해야 합니다.

모범 사례

코드형 인프라(Infrastructure as Code, IaC)

코드형 인프라를 사용해 AWS 리소스를 간편하게 배포할 수 있습니다. IaC 사용 시에는 코드를 사용하여 인프라 정의, 배포, 구성, 업데이트, 제거를 수행할 수 있습니다.

템플릿은 환경에서 배포할 리소스를 설명 및 정의하는 텍스트 파일ㅇ립니다. 지정한 리소스를 프로비저닝하는 엔진이 해당 템플릿을 처리합니다. 템플릿의 기능은 다음과 같습니다.

• JSON 또는 YAML 템플릿 파일에서 전체 애플리케이션 스택(애플리케이션에 필요한 모든 리소스)을 정의합니다. 템플릿은 ㅌ코드로 간주하여 버전 제어 시스템을 통해 관리합니다.
• EC2 인스턴스 크기와 EC2 키 페어 등 템플릿의 런타임 파라미터를 정의합니다.
• IaC 솔루션은 템플릿에 정의된 리소스를 프로비저닝합니다.

IaC를 활용할 때 이점은 다음과 같습니다.

• 빠른 속도와 높은 안정성
  프로그래밍 방식으로 인프라를 구축하므로 수동 배포보다 속도가 빠르며 오류 발생 가능성은 줄어듭니다.
• 재사용성
  인프라를 재사용 가능한 모듈로 구성할 수 있습니다.
• 문서 및 버전 제어
  템플릿에는 배포된 리소스를 문서화하고, 버전 제어는 시간이 지남에 따라 인프라의 기록을 제공합니다. 오류가 발생할 경우 인프라가 정상적으로 작동했던 이전 버전으로 롤백할 수도 있습니다.
• 유효성 검사
  템플릿에서 코드 검토를 수행하므로 오류 발생 가능성을 줄일 수 있습니다.

AWS CI/CD

IaC 이점

인프라를 코드형으로 구축하는 경우, 환경을 구축하면서 반복성과 재사용성의 이점을 활용할 수 있습니다. 템플릿 하나 또는 여러 템플릿의 조합으로 복잡한 동일 환경을 구축할 수 있습니다. 아래의 예에서는 아키텍처 템플릿을 사용하여 여러 AWS 리전에서 동일한 리소스를 생성합니다. 그중 하나는 개발 환경이고 다른 하나는 프로덕션 환경입니다.

특정 컨텍스트와 일치하도록 리소스를 구축하려면 조건에 따라 환경을 생성합니다. 예를 들어 개발 환경이나 프로덕션 환경에서 각기 다른 AMI를 사용하도록 템플릿을 설계할 수도 있습니다.

템플릿에 새로운 리소스를 추가하도록 업데이트 된다면, 이러한 환경을 시작하는 데 사용되는 템플릿을 한 번만 변경하는 것으로 모든 환경에 새로운 리소스가 추가됩니다. 이 기능을 활용해 리소스를 일관된 방식으로 더 간편하게 유지 관리할 수 있고, 작업을 병렬 처리할 수 있으므로 작업량도 줄일 수 있습니다.