Today I Learned_220309

AWS Certified Developer Associate

AWS Skill builder에서 강의 수강 : Exam Readiness: AWS Certified Developer – Associate (Digital) (Korean)

Amazon Simple Notification Service(SNS)

유연한 완전 관리형 게시/구독 알림 서비스

모바일 알림에도 사용되며 구독 엔드포인트 및 클라이언트에 메시지 전달을 조정하는데 사용된다.

분산 시스템, 서비스 모바일 디바이스 등 다수의 구독자들에게 메시지 전송 가능

사용 방법 : Amazon Management Console, CLI, AWS SDK 중 하나를 사용

Amazon Simple Queue Service(SQS)

완전 관리형 메시지 대기열 서비스

전송 구성 요소와 송신 구성 요수의 분리 가능

사용 방법 : Amazon Management Console, CLI, AWS SDK 중 하나를 사용

두 가지 유형의 메시지 대기열 제공

• 표준 대기열 : 최대 처리량, 최선의 정렬, 최소 1회 전달 기능을 제공
• SQS FIFO 대기열 : 메시지가 전송된 순서대로 정확히 한 번 처리되도록 설계

visibility timeout, message retention period, delay second -> 나중에 다시 확인해보자

SQS 표시 제한 초과의 기본 설정은 30초이다.

Amazon SNS vs. Amazon SQS

두 서비스 모두 AWS 내의 메시징 서비스로 개발자에게 각기 다른 혜택을 제공한다.

SNS : 애플리케이션이 푸시 메커니즘을 통해 시간이 중요한 메시지를 여러 구독자에게 전송할 수 있으며, 정기적으로 업데이트를 확인하거나 폴링할 필요가 없다.

SQS : 분산 애플리케이션에서 폴링 모델을 통해 메시지를 교환하는 데 사용되는 메시지 대기열 서비스. 각 구성 요소를 동시에 사용할 수 없더라도 애플리케이션의 분산 구성 요소에서 유연성 있게 메시지를 전송 및 수신할 수 있다.

Amazon Step Function

시각적 워크플로우를 통해 분산 애플리케이션과 마이크로서비스의 구성요소를 쉽게 조정할 수 있다.

시각적 콘솔과 자주 사용되는 워크플로우에 대한 블루프린트가 포함됨 -> 분산 애플리케이션의 구성 요소를 병렬/순차적 단계로 쉽게 조정할 수 있다.

각 단계를 자동으로 트리거하므로 애플리케이션이 예상한 순서대로 실행된며, 수백만 개의 단계를 동시에 처리할 수 있어 수요가 증가하더라도 애플리케이션을 사용할 수 있다.

전체 애플리케이션을 수정하지 않고 쉽게 워크플로우를 변경하고 단계 시퀀스를 편집할 수 있다. 코드를 변경하지 않고 구성 요소와 단계를 재사용할 수 있으므로 더 빠르게 실험 및 혁신할 수 있다.

Amazon Status Language

상태 시스템을 정의하는데 사용되는 JSON기반의 구조화된 언어

상태의 종류 : task, choice, fail 등

Amazon API Gateway

웹/앱이 Amazon API Gateway를 통해 HTTP REST API를 사용하여 다른 AWS 서비스와 상호작용하는 함수를 호출한다.

애플리케이션이 백엔드 서비스의 데이터, 비즈니스 로직 또는 기능에 액세스하기 위한 현관 역할을 하는 API를 생성할 수 있는 서비스

최대 수십만 건의 동시 API호출 수락 및 처리와 관련된 모든 작업을 완벽하게 관리하고 처리

관리형 캐시는 Amazon CloudFront를 통해 DDOS공격을 방지하고 지연 시간을 줄인다.

API Gateway를 사용하는 서버리스 아키텍처

API Gateway는 백엔드 요청에 대한 응답을 수신 -> 자체 캐시에 해당 응답을 캐시

동일한 요청이 다시 수신되면 API Gateway는 백엔드에서 확인할 필요 없이 캐시에서 이 요청을 확인하고 반환

캐싱

캐싱이 일어나는 세 계층 : 엣지의 CloudFront, ELB 앞, S3 앞

세션 상태는 Amazon DynamoDB에 저장

관련 솔루션 : Amazon CloudFront, Amazon ElastiCache

Amazon CloudFront

비즈니스 및 웹 애플리케이션 개발자에게 짧은 지연 시간과 빠른 데이터 전송 속도로 콘텐츠를 배포하는 쉽고 비용 효율적인 방법을 제공하는 웹 서비스

엣지 로케이션의 글로벌 네트워크를 통해 최종 사용자에게 파일이 전달

캐시의 객체 TTL(Time To Live)을 지정할 수 있으며, CloudFront를 사용하여 객체 액세스를 여러 가지 방법으로 제한할 수도 있다.

Amazon ElastiCache

클라우드에서 Memcached 또는 Redis 프로토콜 규정 준수 서버 노드를 쉽게 배포하고 실행할 수 있게 해주는 웹 서비스

관리형 인메모리 시스템에서 정보를 검색할 수 있도록 하여 웹 어플리케이션의 성능을 향상

Amazon 컨테이너 서비스

Amazon Elastic Container Service

확장성이 뛰어난 고성능 컨테이너 관리 서비스

Amazon Elastic Container Service for Kubernetes(EKS)

AWS에서 쿠버네티스를 쉽게 실행할 수 있다.

AWS Fargate

Amazon ECS용 기술로 서버를 프로비저닝 또는 관리하지 않고도 컨테이너를 실행할 수 있게 해 준다.

Amazon Elastic Container Registry(ECR)

가용성이 뛰어나고 안전한 프라이빗 컨테이너 리포지토리로 Docker 컨테이너 이미지를 쉽게 저장 및 관리하고 저장 이미지를 암호화 및 압축할 수 있으므로 빠르게 풀링하고 보호할 수 있다.

ECR 액세스 방법

1. AWS에서 제공하는 SDK 사용. 해당 프로그래밍 언어 또는 플랫폼에 맞게 작성된 API로 애플리케이션에서 AWS 서비스를 간편하게 사용할 수 있다.
2. 오픈 소스 및 상용 소프트웨어 IDE를 위한 여러 IDE 도구 키트 사용. Amazon에서 제공하는 클라우드 기반 IDE(Cloud9)를 사용하면 AWS에서 실행되는 EC2 인스턴스를 이용하여 브라우저에서 직접 개발할 수 있다.
3. AWS CLI : 명령줄에서 AWS 서비스를 제어하고 스크립트로 서비스 관리를 자동화할 수 있다.

리팩터링

안티 패턴 : 실제 많이 사용되지만 비효율적이고 비생산적인 패턴

환경 자동화, 확작성 향상

• 안티 패턴 : 앱 서버가 충돌 → 사용자가 관리자에게 수동으로 알림 → 관리자가 새 서버를 수동으로 시작 및 구성
• 모범 사례 : 앱 서버가 충돌 → Amazon CloudWatch가 비정상 인스턴스를 자동으로 감지 → 자동으로 관리자에게 알림 → 변경 관리 솔루션에 자동으로 작업 로깅 → CloudWatch에서 동일한 서버를 시작하고 구성하도록 Auto Scaling에 자동으로 알림

서버 및 서비스 설계

• 안티 패턴

  간단한 애플리케이션은 영구 서버에서 실행된다.

  애플리케이션이 서로 직접 통신

  정적 웹 자산이 로컬로 인스턴스에 저장

  백엔드 서버가 사용자 인증 및 사용자 상태 스토리지를 처리

• 모범 사례

  서버 없는 솔루션이 필요한 시점에 프로비저닝

  메시지 대기열이 애플리케이션 간의 통신을 처리

  정적 웹 자산은 Amazon S3와 같은 외부에 저장됨

  사용자 인증 및 사용자 상태 스토리지는 AWS에서 처리

단일 장애점 제거

모범 사례 : 보조 서버 또는 대기를 생성하고 데이터를 복제하는 것.

주 데이터서버가 오프라인 상태가 되면 보조 서버가 로드를 처리. 앱 서버가 자동으로 요청을 보조 데이터베이스로 전송해야 한다.

캐싱

캐싱 : 향후 요청을 더 빨리 수행하고 네트워크 처리량을 줄이기 위해 요청자와 영구 스토리지 사이의 중간 위치에 데이터 또는 파일을 일시적으로 저장하는 프로세스

• 안티 패턴 (Amazon S3 버킷에서 사용하는 캐싱 서비스가 없음)

  사용자 3명이 Amazon S3 버킷 중 하나에서 한 번에 한 명씩 파일을 요청 → 파일이 동일한 방식으로 각 사용자에게 전달 -> 각 요청을 완료하는데 동일한 시간과 동일한 비용이 소요된다.

• 모범 사례 (Amazon CloudFront가 존재해 S3 앞에서 캐싱을 제공함) 첫 번째 요청이 CloudFront에서 파일을 확인 → 파일을 찾을 수 없는 경우 Amazon S3에서 파일을 가져와 사용자에게 가장 가까운 엣지 로케이션에 있는 CloudFront에 파일 사본을 저장 → 요청한 사용자에게 다른 사본을 전송 → 다른 사용자가 해당 파일을 요청하면 S3대신 더 가까운 엣지 로케이션의 CloudFront에서 가져온다 → 파일 전송 요금을 지불하지 않기 때문에 비용이 절감

마이그레이션과 6가지 전략

6가지 R

1. Rehosting(리호스팅, 리프트 앤 시프트)
2. Replatforming(리플랫포밍), 상품을 AWS 클라우드로 이전하면서 리셰이핑하는 리프트, 틴커 앤 시프트
3. Repurcahsing(재구매, 드롭 앤 숍) : 실제로 상품 또는 리소스를 새 서비스로 교체
4. Refactoring, Rearchitecting(리팩터링, 리아키텍쳐링) : 애플리케이션이 클라우드에서 실행되도록 리코딩 및 리아키텍처링한다. 프로세스를 진행하면서 애플리케이션과 구성 요소를 분리
5. Retire(폐기) : 서비스를 살펴보고 폐기
6. Retain(보존) : 향후 폐기 상태를 위해 클라우드로 이전하지 않을 서비스로 보존

리팩터링

기존 애플리케이션을 재작성, 리아키텍처링, 분리하는 것

애플리케이션을 클라우드로 이전하기 위해 구현할 수 있는 마이그레이션 전략 중 하나

리팩터링 시 기존 애플리케이션 설계 및 성능을 참조해야 하며, 확장성, 가용성, 유연성, 작업, 성능 등을 고려해야 한다.

리팩터링을 위해 마이그레이션에 관해 고려해볼 만 한 질문

설계에 다중 티어 아키텍처 또는 서비스 중심 아키텍처를 포함해야 하는지?

애플리케이션 마이그레이션에 서버리스 아키텍처 구현을 포함할 것인가?

사용되는 서비스에 연결하는 내부 또는 기존 구성 요소를 추가로 포함할 것인가?

리팩터링은 Well Archtected 프레임워크 구현에 어떻게 도움이 되는가?

AWS 모범 사례에 따라 자동화된 ALC(Application LifeCycle) 또는 SDLC(Software Development LifeCycle)를 어떻게 구현할 것인가?

내 AWS 구성 요소를 전체 솔루션으로 어떻게 통합할 것인가?

AWS 클라우드로 마이그레이션되는 애플리케이션의 검증 및 보안에 사용할 수 있는 도구는 무엇인가?

리프트 앤 시프트

올-인

모놀리식 애플리케이션을 통째로 클라우드상에 올리는 것.

마이그레이션이 요청되는 애플리케이션 소유자의 신뢰와 협력을 위태롭게 할 수도 있다.

하이브리드

온프레미스와 클라우드 둘 다 데이터를 상주시키는 것.

대규모 데이터 세트를 경제적으로 저장하거나 클라우드 네이티브 데이터베이스를 활용하거나 데이터를 고객과 더 가까이 이동하거나 비용 효율적인 고가용성으로 백업 및 아카이브 솔루션을 생성하기 위해 이 방법을 많이 사용한다.

마이크로서비스

기존의 모놀리식 아키텍쳐 → 확장의 어려움. 애플리케이션 코드 베이스가 증가함에 따라 업데이트 및 유지 관리가 복잡해지고 있다. 새로운 기능, 언어, 프레임워크, 기술 도입이 점점 더 어려워져서 혁신과 새로운 아이디어를 제한한다.

마이크로서비스 아키텍처 내에서 각 애플리케이션 구성 요소는 자체 서비스로 실행되며 잘 정의된 API를 통해 다른 서비스와 통신한다.

마이크로서비스는 비즈니스 기능을 중심으로 구축되고 각 서비스는 단일 기능을 수행한다. 다양한 프레임워크 및 프로그래밍 언어를 사용하여 마이크로서비스를 작성할 수 있다.

마이크로서비스를 독립적인 단일 서비스로 배포하거나 서비스 그룹으로 배포할 수 있다.

서버리스 애플리케이션

서버를 프로비저닝하거나 관리할 필요가 없는 애플리케이션

운영체제, 액세스 제어, 패치 적용, 프로비저닝, 적절한 크기 조정, 확장성, 가용성 등의 책임이 아닌 핵심 상품 및 비즈니스 로직에 집중할 수 있다. (플랫폼이 해당 책임을 대신 관리함)

Amazon CloudWatch

AWS에서 관리 중인 대부분의 리소스 상태 및 사용률 모니터링을 위한 서비스

인스턴스의 CPU 밑 네트워크 사용률, EBS에 대한 디스크 읽기-쓰기 작업, 관리형 데이터베이스에 대한 메모리 및 디스크 활동과 같은 AWS의 다양한 특성을 모니터링할 수 있다.

일반 지표(Common Matrix) - AWS 리소스 또는 서비스의 일부 속성을 측정한 값

사용자 정의 지표

특정 조건이 충족될 경우 트리거되는 CloudWatch 경보를 구성할 수 있다.

Amazon SNS 또는 SQS 서비스를 사용하여 알림을 게시하도록 CloudWatch 경보를 구성할 수 있다 -> 사람에게 전송하여 사람의 개입이 필요할 수 있는 상태를 알릴 수 있다.

CLI 또는 API를 사용하여 프로그래밍 방식으로 CloudWatch 지표를 읽을 수도 있다 → 사용자 정의 스크립트 또는 애플리케이션을 사용하여 고유한 사전 대응형 알림 시스템을 구축할 수 있다 (사용자 정의 CloudWatch 경보를 사용하여 Auth Scaling을 구현할 수도 있다)

Amazon CloudWatch는 Matrix의 Repository로, 지원되는 AWS 서비스가 지표를 리포지토리로 전송하여 사용자 정의 지표를 리포지토리로 전송할 수 있다.

StatisticSets : 사용 가능한 미리 집계된 데이터 세트

AWS CloudTrail

API 사용량에 대한 로그를 Amazon S3 버킷에 저장한 후 나중에 해당 로그를 분석

AWS X-Ray

배포된 프로덕션 애플리케이션을 개발자가 분석하고 디버깅할 수 있도록 도와주는 서비스

애플리케이션을 통과하는 요청에 대한 엔드 투 엔드 보기를 제공하며 애플리케이션의 기본 구성 요소 맵을 표시

개발 및 프로덕션 환경의 애플리케이션을 모두 분석할 수 있다.

서비스 맵 - 애플리케이션에서 사용하는 서비스의 맵을 생성할 수 있으며, 애플리케이션 내 서비스 간의 연결 보기를 제공하며 종속성 트리를 생성할 수 있게 해 준다. 이 맵을 사용하여 AWS 가용 영역 또는 리전 간에 작업할 때 지연 시간 또는 오류를 감지할 수 있다.

애플리케이션에 대한 각 요청의 응답 코드를 분석하여 애플리케이션 코드의 버그 또는 오류를 자동으로 강조 표시할 수 있다 → 버그나 오류를 재현하지 않고도 애플리케이션 코드를 쉽게 디버깅할 수 있다