[90DaysOfDevOps] Day 53~55 - AWS + AWS app mesh

Main Reference

• https://github.com/MichaelCade/90DaysOfDevOps/blob/main/2023/

90DaysOfDevOps/2023/day53.md at main · MichaelCade/90DaysOfDevOps

 

Day 53

< AWS Systems Manager >

 

 

• AWS Systems Manager = 사용자가 AWS 및 온프레미스 리소스 모두에서 운영 작업을 관리하고 자동화할 수 있게 해주는 완전관리형 서비스
• AWS 리소스, 가상 머신 및 애플리케이션을 관리하기 위한 중앙 집중식 플랫폼을 제공
  • 이를 통해 DevOps 전문가는 운영 작업을 자동화하고 규정 준수를 유지하며 운영 비용을 절감할 수 있음
• AWS Systems Manager를 사용하면 사용자는 패치 관리 자동화, OS 및 애플리케이션 배포 자동화, Amazon 머신 이미지(AMI) 생성 및 관리, 리소스 활용도 모니터링과 같은 작업을 수행할 수 있음
• 실행 명령, 상태 관리자, 인벤토리 및 유지 관리 기간을 포함하여 인스턴스 구성 및 관리를 위한 도구 세트를 제공
• AWS Systems Manager는 운영 데이터에 대한 통합 보기를 제공하므로 사용자는 EC2 인스턴스, 온프레미스 서버 및 AWS 서비스를 비롯한 AWS 인프라 전체에서 운영 데이터를 시각화하고 모니터링할 수 있음
  • 이를 통해 사용자는 문제를 더 빠르게 식별하고 해결하여 운영 효율성을 향상하고 가동 중지 시간을 줄일 수 있음

 

AWS System manager 시작 단계

 

 

Day 54

< AWS CodeCommit >

 

 

• AWS CodeCommit = 개발자가 프라이빗 Git 리포지토리를 쉽게 호스팅하고 관리할 수 있도록 AWS에서 제공하는 완전 관리형 소스 제어 서비스
  • "GitHub이지만 기능이 적다" 정도로 이해할 수 있음.
• 코드에 대해 협업하고 보안 액세스 제어 지원을 통해 코드를 클라우드에 안전하게 저장할 수 있음 (암호화 및 자동 백업)
• AWS CodeCommit을 사용하면 개발자는 강력한 코드 검토 및 워크플로 도구를 사용하여 Git 리포지토리를 쉽게 생성, 관리 및 협업할 수 있음
• AWS CodePipeline 및 AWS CodeBuild와 같은 다른 AWS 서비스와 원활하게 통합되므로 완전히 자동화된 방식으로 애플리케이션을 더 쉽게 구축하고 배포할 수 있음

 

>> 일부 주요 기능

• 코드 검토 및 풀 요청을 지원하는 Git 기반 리포지토리
• 안전한 액세스 제어를 위해 IAM와 통합(큰 장점)
• 저장 및 전송 중인 데이터 암호화
• 자동 백업 및 장애 조치 기능을 통해 확장성과 가용성이 뛰어남

 

 

Day 55

< AWS Codepipeline>

 

• CodePipeline = IaC 또는 소프트웨어 릴리스 프로세스를 자동화할 수 있는 완전관리형 지속적 전달 서비스(fully managed continuous delivery service)
• 코드 변경 사항을 지속적으로 (적절한 테스트를 통해) 안정적으로 빌드, 테스트 및 배포하는 파이프라인을 생성할 수 있음
• CodePipeline을 사용하면 빌드, 테스트 및 배포 워크플로를 자동화하는 파이프라인을 생성하여 코드 변경 사항이 대상 환경에 안정적으로 배포되도록 할 수 있음
• 이를 통해 더 빠른 릴리스 주기를 달성하고, 개발 및 운영 팀 간의 협업을 개선하고, 소프트웨어 릴리스의 전반적인 품질과 안정성을 향상시킬 수 있음

 

• AWS CodePipeline integrates with other AWS services:

• Source Action Integrations
• Build Action Integrations
• Test Action Integrations
• Deploy Action Integrations
• Approval Action Integrations
• Invoke Action Integrations

+ GitHub, Jenkins, Bitbucket과 같은 타사 도구와도 통합됨, AWS CodePipeline을 사용하여 여러 AWS 계정 및 리전에서 애플리케이션 업데이트를 관리할 수 있음

 

Codepipeline CI/CD Example : https://youtu.be/MNt2HGxClZ0?si=fC3q855WJZyII9mn

 

 

---

 

++ AWS app mesh

https://docs.aws.amazon.com/app-mesh/

https://docs.aws.amazon.com/app-mesh/

 

 

< AWS app mesh란? >

• 서비스를 손쉽게 모니터링하고 제어할 수 있는 서비스 메시입니다.
• 서비스 메시는 일반적으로 애플리케이션 코드와 함께 배포된 간단한 네트워크 프록시 배열을 통해 서비스 간 통신을 처리하는 전용 인프라 계층입니다.
• App Mesh는 서비스가 통신하는 방법을 표준화하여 end to end 가시성을 제공하고 애플리케이션의 고가용성을 보장합니다.
• App Mesh는 애플리케이션의 모든 서비스에 대한 일관된 가시성 및 네트워크 트래픽 제어를 제공합니다.

 

예제

 

< App Mesh 구성 요소 >

• 서비스 메시 ( Mesh - apps )
  • 서비스 메시 = 내부에 있는 서비스 간의 네트워크 트래픽에 대한 논리적 경계
  • 이 예제에서 메시는 이름이 apps이며 메시에 대한 다른 모든 리소스를 포함

 

• 가상 서비스 ( Virtual service )
  • 가상 서비스 = 가상 노드가 가상 라우터를 통해 직간접적으로 제공하는 실제 서비스의 추상화
  • 그림에서 두 개의 가상 서비스는 두 개의 실제 서비스를 나타냅니다.
  • 가상 서비스 이름은 실제 서비스에서 검색 가능한 이름입니다.
  • 가상 서비스와 실제 서비스의 이름이 같으면,  여러 서비스가 App Mesh가 구현되기 전에 사용한 것과 동일한 이름을 사용하여 서로 통신할 수 있습니다. 

 

• 가상 노드 ( Virtual node )
  • 가상 노드 = Amazon ECS 또는 Kubernetes 서비스와 같은 검색 가능한 서비스에 대한 논리 포인터 역할을 합니다.
  • 각 가상 서비스에는 하나 이상의 가상 노드가 있습니다.
  • 그림에서 servicea.apps.local 가상 서비스는 이름이 serviceA인 가상 노드에 대한 구성 정보를 가져옵니다. serviceA 가상 노드는 서비스 검색을 위한 servicea.apps.local 이름으로 구성됩니다. 
  • serviceb.apps.local 가상 서비스는 serviceB라는 가상 라우터를 통해 serviceB 및 serviceBv2 가상 노드로 트래픽을 라우팅하도록 구성됩니다.

 

• 가상 라우터 및 경로 ( Virtual router & Route )
  • 가상 라우터 = 메시 내에 있는 하나 이상의 가상 서비스에 대한 트래픽을 처리합니다.
  • 경로는 가상 라우터와 연결됩니다. 이 경로는 가상 라우터에 대해 일치하는 요청을 찾고 관련 가상 노드에 트래픽을 분산하는 데 사용됩니다.
  • 이전 그림에서 serviceB 가상 라우터에는 트래픽의 일정 비율을 serviceB 가상 노드로, 일정 비율을 serviceBv2 가상 노드로 전달하는 경로가 있습니다. 특정 가상 노드로 라우팅되는 트래픽의 비율을 설정하고 시간이 지남에 따라 변경할 수 있습니다.
  • HTTP 헤더, URL 경로, gRPC 서비스 및 메서드 이름과 같은 기준에 따라 트래픽을 라우팅할 수 있습니다.
  • 응답에 오류가 있는 경우 연결을 재시도하도록 재시도 정책을 구성할 수 있습니다.
    • 예를 들어, 그림에서 경로에 대한 재시도 정책은 serviceb.apps.local에서 특정 유형의 오류를 반환하는 경우 serviceb.apps.local에 대한 연결을 5번 재시도하고 재시도 간격은 10초가 되도록 지정할 수 있습니다. 

 

• 프록시 ( Proxy )
  • 메시와 해당 리소스를 생성한 후, 프록시를 사용하도록 서비스를 구성합니다.
  • 프록시 = App Mesh 구성을 읽고 트래픽을 적절하게 전달합니다.
  • 그림에서 servicea.apps.local에서 serviceb.apps.local로의 모든 통신은 각 서비스에 배포된 프록시를 통해 이루어집니다.
  • 서비스는 App Mesh를 도입하기 전에 사용한 것과 동일한 서비스 검색 이름을 사용하여 서로 통신합니다.
  • 프록시가 App Mesh 구성을 읽으므로, 두 서비스가 서로 통신하는 방식을 제어할 수 있습니다.
  • App Mesh 구성을 변경하려는 경우, 서비스 자체 또는 프록시를 변경하거나 재배포할 필요가 없습니다. 

 

 

< 시작 조건? >

>> App Mesh를 사용하려면 AWS Fargate, Amazon ECS, Amazon EKS, Amazon EC2의 Kubernetes 또는 Docker가 있는 Amazon EC2에서 실행되는 기존 서비스가 있어야 함.

 

 

https://aws.amazon.com/ko/blogs/korea/introducing-aws-app-mesh-service-mesh-for-microservices-on-aws/

AWS App Mesh, 마이크로서비스를 위한 서비스 메시 | Amazon Web Services

 

사용하는 프록시 

> app mesh는 오픈 소스 프록시인 Envoy를 사용함.

 

 

+  Service Mesh에서 Sidecar로 주로 사용되고 있는 Envoy Proxy란?

 

이것에 대한 정보는 다음 글에서 자세히 알아보도록 하자... Service Mesh 정복 기다려 ㅋㅋ 

 

근데 궁금해졌다. Istio가 service mesh 중에 가장 유명한 이유가...

지피티에게 물어봄

Kubernetes에서 AWS App Mesh 대신 Istio를 사용하는 이유와 Istio의 장점은 다음과 같습니다:

**Istio의 장점:**
1. **다양한 기능과 유연성:** Istio는 풍부한 기능을 제공하며, 서비스 메시에서 필요한 여러 기능을 지원합니다. 이는 트래픽 관리, 보안, 모니터링, 로깅 등 다양한 영역에 걸쳐 유연하게 구성할 수 있음을 의미합니다.
2. **강력한 보안 기능:** Istio는 통신을 암호화하고 서비스 간 보안을 강화하기 위한 기능을 제공합니다. mTLS(Mutual TLS)를 통해 서비스 간 통신을 보호하고 인증 및 권한 부여를 통해 보안을 강화할 수 있습니다.
3. **종합적인 모니터링과 트래픽 관리:** Istio는 서비스 메시에서의 모든 트래픽을 관찰하고 제어할 수 있는 기능을 제공합니다. 이를 통해 실시간 모니터링, 트래픽 라우팅, 로드 밸런싱 등을 수행할 수 있습니다.
4. **다양한 환경 지원:** Istio는 다양한 환경에서 사용할 수 있습니다. 예를 들어, Kubernetes뿐만 아니라 가상 머신, 온프레미스 환경에서도 사용할 수 있습니다.


**AWS App Mesh의 단점:**
1. **클라우드 공급자 종속성:** AWS App Mesh는 AWS의 클라우드 서비스에 종속되어 있습니다. 이는 AWS 외부의 환경에서는 사용할 수 없음을 의미합니다. 따라서 다중 클라우드 또는 하이브리드 클라우드 환경에서는 제한될 수 있습니다.
2. **기능 제한:** AWS App Mesh는 Istio에 비해 제한된 기능을 제공합니다. Istio는 훨씬 더 다양한 기능을 제공하며, 보안, 모니터링, 트래픽 관리 등의 영역에서 더 많은 유연성을 제공합니다.
3. **커뮤니티 지원 부족:** Istio는 많은 기업 및 개발자 커뮤니티의 지원을 받고 있으며, 활발한 개발과 지속적인 업데이트가 이루어지고 있습니다. 반면에 AWS App Mesh는 상대적으로 커뮤니티 지원이 적고, 새로운 기능이나 업데이트를 기다리는 시간이 길 수 있습니다.

이러한 이유로 Istio를 선택하는 경우가 많으며, 특히 다양한 환경에서 유연하게 사용하고 싶거나 고급 보안 및 모니터링 기능을 필요로 하는 경우에 적합합니다. 그러나 AWS 환경에서의 통합 및 단순한 설정이 필요한 경우에는 AWS App Mesh를 선택할 수 있습니다.

 

그렇다고 한다.