하루의 기억

AWS Lambda는 서버리스 컴퓨팅 서비스로, 개발자가 서버 인프라에 대해 걱정하지 않고 코드를 실행할 수 있게 해준다.

lambda의 장점

서버 관리 필요 없음: AWS Lambda를 사용하면 서버를 설정하거나 관리할 필요가 없다.

이를 통해 인프라 운영에 대한 부담을 줄이고 애플리케이션 개발에 집중할 수 있다.

자동 확장: Lambda는 트래픽 패턴에 따라 자동으로 규모를 조정한다.

코드가 동시에 수천 번 실행되어야 하는 경우에도 Lambda가 자동으로 처리한다.

고성능: Lambda는 코드를 동시에 실행하므로 응답 시간을 줄일 수 있다.

비용 효율성: AWS Lambda는 사용한 컴퓨팅 시간에 대해서만 비용을 청구한다.

코드가 실행되지 않는 경우 비용이 청구되지 않으므로, 비용 효율적이다.

이벤트 기반 실행: Lambda는 HTTP 요청에 응답하거나 AWS 서비스로부터의 이벤트를 처리하는 등 다양한 유형의 응답을 위해 트리거 될 수 있다.

통합: Lambda는 다른 AWS 서비스와 강력하게 통합되어 있어, S3 버킷에서 파일이 변경될 때마다 실행되거나, DynamoDB 테이블에 새로운 레코드가 추가될 때 실행되는 등 다양한 시나리오에서 사용될 수 있다.

보안: AWS Lambda는 기본적으로 VPC 내에서 실행되며, IAM 역할과 정책을 이용해 권한을 제어할 수 있다.

AWS Key Management Service(KMS)를 이용해 환경 변수를 암호화할 수도 있다.

개발 생산성 향상: 코드를 작성하고 즉시 업로드한 후 실행할 수 있기 때문에 개발 과정이 단순화되고, 개발 및 배포 시간이 단축된다.

이러한 이유로 인해 AWS Lambda는 웹 애플리케이션, 데이터 변환, 실시간 파일 처리 등 다양한 유형의 애플리케이션에 사용된다.

lambda의 단점
AWS Lambda는 많은 이점을 제공하지만, 그 특성상 일부 단점도 존재한다:

Cold Start: Lambda 함수가 처음 실행될 때나 일정 시간 동안 실행되지 않았을 때, "Cold Start"라는 현상이 발생한다.

이는 Lambda가 실행 환경을 초기화하는데 필요한 시간으로, 이 시간 동안에는 함수의 응답 시간이 증가한다.

실행 시간 제한: AWS Lambda 함수는 최대 15분 동안만 실행될 수 있다.

이 시간 제한으로 인해 긴 작업을 수행하기 어렵다.

리소스 제한: 각 Lambda 함수는 메모리, CPU, 디스크 공간 등 리소스에 대한 제한을 가지고 있다.

특히 메모리는 128MB에서 최대 10240MB까지 설정할 수 있다.

디버깅과 모니터링의 어려움: 서버리스 아키텍처의 특성상 전통적인 디버깅과 모니터링 방법을 적용하기 어렵다.

AWS는 이를 위한 도구를 제공하지만, 학습 곡선이 있을 수 있다.

높은 트래픽에 대한 처리: 갑작스럽게 높은 트래픽이 발생하는 경우, Lambda는 요청률 제한을 초과할 수 있다.

이 경우 일부 요청이 실패할 수 있다.

상태 유지(statefulness)의 부재: Lambda 함수는 상태를 유지하지 않는(stateless) 설계로, 함수 실행 간에 데이터를 공유하거나 유지할 수 없다.

이는 일부 애플리케이션 유형에는 적합하지 않을 수 있다.

종속성 관리: Lambda 함수에서 사용하는 외부 패키지나 라이브러리를 관리하고 배포하는 것이 복잡할 수 있다.

따라서 AWS Lambda를 사용할 때는 이러한 제한 사항과 단점을 고려하여 개발 및 배포 전략을 결정해야 한다.

그러면 lambda는 어떤 서비스에 이용되면 좋을까?

AWS Lambda는 서버리스 컴퓨팅 모델을 제공하여, 개발자가 서버 인프라를 관리하는 데 걸리는 시간과 비용을 줄일 수 있다.

이러한 특성으로 인해 Lambda는 다양한 유형의 애플리케이션과 작업에 이용될 수 있다:

실시간 파일 처리: AWS Lambda는 S3 버킷에 파일이 업로드되면 자동으로 트리거될 수 있다.

이를 이용해 업로드된 파일을 실시간으로 처리하는 작업(예: 이미지 리사이징, 로그 파일 처리 등)에 Lambda를 사용할 수 있다.

백엔드 API: AWS API Gateway와 함께 Lambda를 사용하면, 확장성 있는 백엔드 API를 쉽게 구축할 수 있다.

API Gateway가 HTTP 요청을 받아 Lambda 함수를 호출하고, Lambda는 비즈니스 로직을 처리하여 결과를 반환한다.

데이터 변환: AWS Lambda는 스트리밍 데이터를 변환하거나, 데이터베이스에 대한 CRUD(Create, Read, Update, Delete) 작업을 처리하는 등의 데이터 처리 작업에 사용될 수 있다.

실시간 스트림 처리: AWS Kinesis나 DynamoDB Streams와 같은 실시간 스트림 서비스와 Lambda를 결합하면, 실시간 데이터 스트림을 효과적으로 처리할 수 있다.

배치 작업: 주기적인 배치 작업이나 크론 작업을 수행하기 위해 AWS Lambda를 사용할 수 있다.

AWS CloudWatch를 이용해 특정 시간에 Lambda 함수를 호출하도록 설정할 수 있다.

알림: Lambda는 AWS SNS(Simple Notification Service)나 SES(Simple Email Service)와 함께 사용되어, 사용자에게 이메일 알림을 보내는 등의 작업을 수행할 수 있다.

IoT 백엔드: AWS IoT Core와 Lambda를 결합하면, IoT 디바이스에서 보내는 데이터를 처리하거나, 디바이스에 명령을 보내는 등의 작업을 수행할 수 있다.

Amazon Aurora와 Amazon RDS (Relational Database Service)는 AWS에서 제공하는 관계형 데이터베이스 서비스다.

PostgreSQL을 포함하여 여러 데이터베이스 엔진을 지원하며 두 서비스는 다음과 같은 주요 차이점이 있다.

설계 및 아키텍처

[Amazon Aurora]

Aurora는 MySQL 및 PostgreSQL과 호환되는 고성능, 고가용성 데이터베이스다.

Aurora는 분산된 스토리지 계층에 데이터를 6개의 복제본으로 저장하며, 두 개의 가용 영역(AZ)에 걸쳐서 동작한다.

이로 인해 자동 및 연속적인 백업, 빠른 복구 및 고가용성을 제공한다.

[Amazon RDS]

RDS는 Aurora, MySQL, MariaDB, PostgreSQL, Oracle, 및 Microsoft SQL Server와 같은 다양한 데이터베이스 엔진을 지원한다.

각 엔진에 대한 기본 설정 및 관리 작업을 단순화하며, 자동 백업, 패치 관리 및 failover와 같은 기능을 제공한다.

성능

[Amazon Aurora]

Aurora는 기존의 RDS MySQL 또는 PostgreSQL보다 최대 3배, 2배의 성능 향상을 제공한다고 AWS에서 주장한다.

Aurora는 자체적으로 최적화된 스토리지 시스템을 사용한다.

[Amazon RDS]

RDS의 성능은 선택한 데이터베이스 엔진 및 인스턴스 유형에 따라 다르다.

Aurora의 자체 최적화 기능에 비해 성능이 떨어질 수 있다.

가용성 및 내구성

[Amazon Aurora]

Aurora는 데이터를 자동으로 6개의 복제본으로 저장하며, 최소 4개의 복제본이 동작하는 한 데이터베이스는 계속 작동한다. 또한, 멀티 AZ 자동 failover를 지원한다.

[Amazon RDS]

RDS는 멀티 AZ 배포와 스탠드바이 복제본을 제공하여 고가용성을 지원한다.

또한, Read Replicas를 통해 읽기 전용 복제본을 여러 가용 영역에 생성할 수 있다.

비용

[Amazon Aurora]

Aurora는 고성능 및 고가용성 기능을 제공하므로 일반적으로 RDS의 특정 인스턴스 유형보다 비용이 높다.

[Amazon RDS]

RDS는 사용한 리소스와 선택한 데이터베이스 엔진 및 인스턴스 유형에 따라 비용이 발생한다.

일반적으로 Aurora보다는 낮은 비용으로 시작할 수 있다.

확장성

[Amazon Aurora]

Aurora는 자동 및 수동으로 Read Replicas를 추가하여 읽기 쿼리 성능을 확장할 수 있다.

[Amazon RDS]

RDS도 Read Replicas를 지원한다.

읽기 및 쓰기 작업에 대한 성능을 향상시키기 위해 인스턴스 크기를 조정하는 것도 가능하다.

기타 기능

[Amazon Aurora]

Aurora는 Global Databases, Aurora Serverless, Aurora Multi-Master 등과 같은 추가 기능을 제공한다.

[Amazon RDS]

RDS는 특정 데이터베이스 엔진과 관련된 특정 기능 및 옵션을 제공한다.
결국 선택은 워크로드, 비즈니스 요구 사항, 예산 및 기타 요인에 따라 달라진다.

얼마전에 장애가 발생했다.

서비스가 죽은건 아니지만 CUD시 장애가 발생하기 시작했다.

월요일 오전이라 배포한것도 없고 도대체 무슨 문제지?

로그를 확인해보니 새벽시간에 RDS가 업그레이드 되버렸다.

PostgreSQL RDS에 Aurora PostgreSQL 읽기전용 복제본을 생성하여 사용중인데 PostgreSQL RDS만 업그레이드가 진행되 

데이타복제가 안되는 현상이였다.

이전에 업그레이드 메일을 받기는 하였으나 다른업무들로 인해 우선순위가 계속 밀렸고 자동 업그레이드가 된다는 내용으로

업그레이드시 문제되는 부분을 일부 체크는 해두었기에 큰 문제는 없을거라 오판을 했다.

자동업그레이드가 RDS만 되고 Aurora는 안될거라고는 생각도 못했다.

RDS와 Aurora PostgreSQL 는 독립적인 서비스이며 그렇기 때문에 자동 업그레이드 별도로 진행되게 된다.

AWS에서 RDS PostgreSQL 10 버전의 인스턴스들은 maintenance window 시간에 관계없이 강제로 업그레이드되며 

내부적으로 담당자들이 수동으로 수행하는 작업이 아니라 back-end 로 무작위 scan 후 특정 공지 없이 업그레이드를 수행되기때문에 

RDS와 Aurora PostgreSQL 동시에 진행 될 수 없다.

클라우드 인프라는 처음이라 쓴 경험을 쌓고 있다.

Amazon VPC를 생성할 때 고려해야 할 주요 구성 요소들에 알아보자.

CIDR 블록

Amazon VPC를 생성할 때 필요한 첫 번째 요소는 CIDR (Classless Inter-Domain Routing) 블록이다.

이는 VPC 내에서 사용할 수 있는 IP 주소 범위를 정의한다.

서브넷 

Amazon VPC를 생성한 후에는 서브넷을 만들 수 있다.

서브넷은 VPC의 IP 주소 범위를 세분화하여, VPC 내의 섹션을 만든다.

서브넷을 사용하면 네트워크 구성을 더욱 세밀하게 제어할 수 있다.

인터넷 게이트웨이 

인터넷 게이트웨이는 VPC와 인터넷 간의 통신을 가능하게 한다. 

이를 VPC에 연결하면, VPC 내의 리소스가 인터넷과 통신할 수 있게 된다.

라우팅 테이블 

라우팅 테이블은 네트워크 트래픽이 어떻게 라우팅되는지를 결정한다. 

각 서브넷은 라우팅 테이블을 하나씩 가질 수 있으며, 이를 사용해 서브넷의 트래픽이 어떤 방향으로 흐르는지 제어할 수 있다.

네트워크 ACL 및 보안 그룹 

네트워크 ACL (Access Control List)과 보안 그룹은 VPC 내의 리소스에 대한 액세스를 제어한다. 

네트워크 ACL은 서브넷 레벨에서 트래픽을 필터링하는 반면, 보안 그룹은 인스턴스 레벨에서 트래픽을 제어한다.

NAT 게이트웨이 또는 NAT 인스턴스

NAT 게이트웨이 또는 NAT 인스턴스를 사용하면 private 서브넷 내의 인스턴스가 인터넷에 접근할 수 있게 해주지만, 인터넷에서 직접 접근은 허용하지 않는다.

VPC 피어링 

두 VPC 간에 VPC 피어링 연결을 설정하면, 각 VPC가 서로의 private 네트워크로 통신할 수 있다.

엔드포인트 및 엔드포인트 서비스 

VPC 엔드포인트를 사용하면 VPC에서 지원되는 AWS 서비스와 VPC 엔드포인트 서비스로 제공되는 사설 연결을 통해 트래픽을 라우팅할 수 있다.

RFC 1918는 '인터넷 표준'에 대한 권고안으로, 개인 네트워크에서 사용하기 위한 IP 주소 공간을 정의한다. 

이 주소 공간은 인터넷에 직접 라우팅되지 않으므로, 개인 네트워크에서는 이 주소 공간 내에서 IP 주소를 자유롭게 할당할 수 있다.

RFC 1918에서 정의하는 개인 주소 범위는 다음과 같습니다:

10.0.0.0 - 10.255.255.255 (10.0.0.0/8)
172.16.0.0 - 172.31.255.255 (172.16.0.0/12)
192.168.0.0 - 192.168.255.255 (192.168.0.0/16)

Amazon Web Services (AWS)의 Virtual Private Cloud (VPC)는 이러한 개인 주소 공간을 활용한다. 

VPC를 생성할 때, 사용자는 이런 개인 주소 범위 내에서 VPC에 대한 CIDR 블록을 정의해야 한다. 

이 CIDR 블록은 VPC 내에서 사용할 수 있는 IP 주소 범위를 나타낸다.

예를 들어, 사용자가 10.0.0.0/16을 VPC의 CIDR 블록으로 선택한다면, 그 VPC 내에서는 10.0.0.0부터 10.0.255.255까지의 IP 주소를 사용할 수 있게 된다. 

이 주소 범위는 VPC 내에서 EC2 인스턴스나 다른 AWS 리소스에 IP 주소를 할당하는 데 사용된다.

RFC 1918이 정의하는 개인 주소 범위를 사용하면, VPC를 안전하게 격리시키고 사용자 정의 네트워크 환경을 구성하는 데 유용하다. 

이 주소 범위는 인터넷에 라우팅되지 않으므로, VPC 내의 리소스는 인터넷에서 직접 액세스할 수 없게 된다.

이런 리소스들은 VPC의 게이트웨이나 VPN, 또는 AWS Direct Connect를 통해서만 외부와 통신할 수 있다.

AWS의 Virtual Private Cloud (VPC)는 사용자가 정의한 가상 네트워크로서, 사용자는 이 VPC 내에서 AWS 리소스를 안전하게 시작하고 사용자 정의 네트워크 환경을 구성할 수 있다.

VPC를 만들 때, 사용자는 VPC에 대한 IP 주소 범위를 CIDR(Classless Inter-Domain Routing) 형식으로 지정해야 한다.

이 CIDR 블록은 VPC에서 사용할 수 있는 IPv4 주소의 범위를 결정한다.

사용자는 또한 VPC 내에서 여러 서브넷을 만들 수 있으며, 각 서브넷도 자체 CIDR 블록을 가지게 된다.

이 서브넷 CIDR 블록은 해당 서브넷에서 사용할 수 있는 IP 주소 범위를 결정하며, 이는 VPC CIDR 블록의 하위 범위여야 한다.

AWS VPC에서는 주로 RFC 1918 정의한 다음의 사설 IP 주소 범위를 사용한다:

10.0.0.0 - 10.255.255.255 (10.0.0.0/8)
172.16.0.0 - 172.31.255.255 (172.16.0.0/12)
192.168.0.0 - 192.168.255.255 (192.168.0.0/16)

예를 들어, 사용자가 VPC의 CIDR 블록을 10.0.0.0/16으로 설정한다면, 해당 VPC 내에서는 10.0.0.1부터 10.0.255.254까지의 IP 주소를 사용할 수 있다.

사용자는 이 범위 내에서 서브넷을 만들고, 각 서브넷에 CIDR 블록을 할당할 수 있다.

예로 10.0.1.0/24는 VPC 내의 한 서브넷에 할당될 수 있는 CIDR 블록.

이 경우, 해당 서브넷에서는 10.0.1.1부터 10.0.1.254까지의 IP 주소를 사용할 수 있다.

VPC의 IP 대역을 계획할 때는 현재 필요한 용량뿐만 아니라 미래의 확장 가능성도 고려해야 한다.

너무 작은 CIDR 블록을 선택하면 나중에 IP 주소가 부족해질 수 있으며, 이는 VPC를 다시 설계하거나 새로 만들어야 하는 번거로움을 초래할 수 있다.

반면, 너무 큰 CIDR 블록을 선택하면 IP 주소가 낭비될 수 있다. 따라서, 적절한 규모의 CIDR 블록을 선택하는 것이 중요하다.

Amazon Web Services (AWS)에서 Virtual Private Cloud (VPC)는 사용자가 정의한 가상 네트워크이다. 

이를 통해 사용자는 AWS 클라우드에서 로직적으로 격리된 공간을 가질 수 있으며, 사용자는 이 공간에 AWS 리소스를 시작하고 네트워크 환경을 사용자 정의할 수 있다.

AWS VPC의 주요 기능은?

보안

VPC를 사용하면 네트워크를 통해 실행되는 리소스에 대한 보안과 액세스 제어를 향상시킬 수 있다.

보안 그룹과 네트워크 액세스 제어 목록 (ACL)을 사용하여 인바운드 및 아웃바운드 트래픽을 제어할 수 있다.

서브넷팅과 라우팅

VPC는 하나 이상의 서브넷으로 구성된다.

각 서브넷은 특정 IP 주소 범위를 가지며, 이는 사용자가 VPC를 생성할 때 선택한 IP 주소 범위에서 파생된다.

사용자는 서브넷을 public (인터넷에 연결) 또는 private (인터넷과 분리)로 설정할 수 있다.

라우팅 테이블을 사용하여 서브넷 간의 트래픽 흐름을 제어할 수 있다.

서브넷의 인터넷 연결 

인터넷 게이트웨이를 사용하여 VPC를 인터넷에 연결할 수 있다.

이를 통해 VPC 내의 인스턴스가 인터넷과 통신할 수 있다.

VPN 연결

Virtual Private Network (VPN) 연결을 사용하여 VPC를 기업 네트워크에 연결할 수 있다.

이를 통해 VPC 내의 리소스를 기업 네트워크의 확장으로 사용할 수 있다.

VPC Peering 

VPC 피어링을 사용하면 두 VPC 간에 트래픽을 직접 라우팅할 수 있다.

이는 AWS 계정 간 또는 같은 계정 내의 두 VPC 간에 설정할 수 있다.

VPC는 사용자가 AWS 리소스를 보호하고 네트워크 트래픽을 제어하는 데 도움이 되는 핵심 AWS 서비스이다.

사용자는 VPC 설정을 변경하거나 여러 VPC를 함께 사용하여 복잡한 네트워크 아키텍처를 만들 수 있다.

Amazon Web Services(AWS)에서 "public", "private", "dedicated", "spare"는 네트워킹 및 컴퓨팅 리소스와 관련된 용어들이다.

Public
AWS에서 "public"는 주로 인터넷에 연결된, 누구나 액세스할 수 있는 리소스를 의미한다.

예를 들어, public subnet은 인터넷 게이트웨이에 연결되어 있어 인터넷에서 직접 액세스할 수 있으며 또한 public IP 주소는 인터넷에서 직접 연결할 수 있는 IP 주소를 의미한다.

Private
AWS에서 "private"는 인터넷에 직접 연결되어 있지 않은, 특정 네트워크 안에서만 액세스 가능한 리소스를 의미한다. 

예를 들어, private subnet은 일반적으로 인터넷에서 직접 액세스할 수 없으며, 보안 목적으로 사용되며 또한 private IP 주소는 해당 네트워크 내에서만 사용되는 IP 주소를 의미한다.

Dedicated
AWS에서 "dedicated"는 특정 고객만이 사용하는 리소스를 의미한다. 

예를 들어, dedicated instances는 다른 고객과 공유되지 않는 EC2 인스턴스이며 또한 dedicated hosts는 사용자가 전체 물리적 서버를 제어하고, 이를 통해 규정 준수 요구 사항을 충족하거나 특정 서버 경계를 유지할 수 있다.

Spare
AWS에서 "spare"는 보통 Spot Instances와 연관된다. Spot Instances는 AWS의 미사용 EC2 컴퓨팅 용량을 의미하며, 이는 경매 시스템을 통해 사용자가 입찰하여 사용할 수 있다.

이 용량은 "spare" 또는 여분의 용량으로, 사용자가 표준 인스턴스보다 훨씬 저렴한 가격으로 이를 활용할 수 있다.

단, Spot Instances는 AWS에 의해 언제든지 회수될 수 있으므로, 중단 가능한 작업에 가장 적합하다.

용어들은 AWS의 다양한 서비스와 기능을 이해하고 올바르게 활용하는 데 도움이 될거라 생각한다.

각각의 용어가 특정 서비스나 상황에 어떻게 적용되는지를 이해하는 것은 AWS를 효과적으로 사용하는 데 중요한 요소로 보인다.