Dratini의 공부공방

API Gateway 생성

먼저 API Gateway를 생성해준다.

Rest API는 VPC내부의 Private ALB와는 연결할 수 없기 때문에 HTTP API로 생성해줘야한다.

그리고 통합 생성 및 구성은 지금 당장은 넘겨도 된다. API Gateway를 생성하고 나서 구성해도 늦지않다.

경로 구성도, 스테이지 구성도 건드리지 않고 넘긴다.

모든 과정을 거친 후 생성시켜준다.

그리고 VPC 링크를 만들어줘야한다. 그래야 API Gateway가 VPC의 보호를 받고 있는 내부의 ALB에 접근할 수 있다.

VPC링크 생성은 쉽다. API Gateway가 접속할 VPC를 선택해주고 이름만 입력해주면 된다. 물론 VPC를 선택하고나서 어떤 서브넷에 연결시킬 것인지, 보안그룹은 어떻게 설정할지는 ALB를 고려해서 잘 선택해줘야한다.

그리고나서 만들어둔 HTTP API로 가서 라우트 탭으로 들어가서 알맞은 메서드와 리소스를 생성해주면된다.

리소스와 메서드를 생성했다면 이제 ALB와 연결할 차례다. Integration탭으로 가서 원하는 메서드를 선택해 통합을 생성해준다.

 통합 유형에는 VPC에 있는 리소스와 연결하는 프라이빗 리소스를 선택해주고,

 수동으로 선택 ==> ALB/NLB를 골라주나서 내가 연결하길 원하는 로드 밸런서를 선택해준다.

 뭐..리스너도 설정할 수 있고 고급 설정에서 호출할 메서드랑 타임아웃같은 옵션도 정할 수 있는데 그건 알잘딱하게 선택해주면 된다. 그리고 캡처화면에는 없지만 맨 아래 VPC링크를 선택하는 것도 잊으면 안된다.

그럼 아마 이렇게 생성이 돼있을 거다. 이제 끝났다. 배포 스테이지 탭으로 가서 링크로 들어가면 ALB가 잘 열릴 것이다.

AWS 버스트 가능 성능 인스턴스 메커니즘

AWS는 사용자에게 탁월한 유연성과 효율성을 제공하도록 설계된 많은 서비스와 기능을 제공합니다. 그 중 하나가 AWS 버스트라고 부르는 '버스트 가능 성능 인스턴스'다. 이 서비스는 시스템에 가끔이나 부정기적으로 부하가 발생하는 경우 매우 유용하다고 할 수 있다. 그렇다면 '버스트 가능 성능 인스턴스'는 어떤 원리로 작동하는 것인지 한번 알아보자.

버스트 가능 성능 인스턴스

버스트 가능 성능 인스턴스는 일반적인 작업량에는 낮은 CPU 성능을 제공하지만, 필요한 경우 잠시 높은 성능을 제공할 수 있는 EC2 인스턴스 유형이다.. 이 기능은 "CPU 크레딧"이라는 개념을 이용해 CPU 성능을 관리한다.

CPU 크레딧

CPU 크레딧은 인스턴스가 가용한 CPU 성능을 측정하는 단위인데, vCPU 시간의 단위로 표현된다.
 예를 들어, CPU 크레딧 1개는 vCPU 1개를 1분 동안 100% 사용하는 것을 말한다.

획득 크레딧 및 소비 크레딧

인스턴스가 실행 중일 때, 계속해서 CPU 크레딧이 적립된다. 이를 '획득 크레딧'이라고 하는데, 반대로 인스턴스가 실행 중일 때 CPU를 사용할 때 적립돼있는 CPU 크레딧을 소비한다. 이렇게 소비되는 크레딧을 '소비 크레딧'이라고 한다.

기준 사용률

'기준 사용률'은 인스턴스가 CPU 크레딧을 얻는 속도와 사용하는 속도가 같을 때, 인스턴스가 사용할 수 있는 CPU 수준을 말한다. 기본적으로 각 인스턴스 유형은 미리 정의된 기준 사용률을 가지고 있어서 해당 기준을 준수하는 방식으로 작동한다.

크레딧 누적 한도 및 시작 크레딧

각 인스턴스는 일정 시간 동안 누적할 수 있는 CPU 크레딧에 한도가 있는데, 이를 '크레딧 누적 한도'라고 한다. 그리고 새로 생성된 인스턴스는 일정량의 '시작 크레딧'을 가지고, 이 크레딧은 인스턴스가 처음 실행될 때 기준 이상으로 버스트하는 데 쓰인다.

무제한 모드와 스탠다드 모드

AWS는 무제한 모드와 스탠다드 모드라는 두 가지 크레딧 구성 모드를 제공한다. 스탠다드 모드에서는 크레딧 잔액에 적립된 크레딧을 사용하여 인스턴스를 기준 이상으로 버스트할 수 있는 반면, 무제한 모드에서는 필요한 경우 언제든지 기준 이상으로 인스턴스를 버스트할 수 있다. 당연하게도, 이 경우 추가 요금이 발생할 수 있다.

마치며

버스트 가능 성능 인스턴스를 알아봤는데 AWS가 제공하는 매우 유용한 기능이다. 이것을 이해하고 제대로 활용한다면, 부하가 일시적으로 높아지는 시스템에서 돈 낭비 없이 효율성과 성능을 얻을 수 있을 것이다. 

VPC?

AWS 서비스 안에서 클라우드 내 프라이빗 공간을 제공함으로써, 클라우드를 퍼블릭과 프라이빗으로 분리할 수 있다.

 VPC가 없었을 땐, 클라우드 내의 리소스를 격리할 방법이 없었다. 해서 인스턴스들이 서로 연결됨과 동시에 인터넷과도 연결되어 시스템의 복잡도를 어마어마하게 높이고, 의존도 또한 늘려버렸다. 이 말은 즉, 시스템의 유지/관리에 돈과 시간이 많이 든다는 뜻이다.

 하지만 VPC는 각 인스턴스의 구획을 분리함으로써 확장성을 가질 수 있고, 클라우드 시스템 네트워크에 대한 통제를 할 수 있다.

VPC 설정

VPC 설정에는 크게 4단계가 있다.

1. 먼저 프라이빗 네트워크 안에서 사용할 수 있는 프라이빗 ip주소 범위를 설정한다.
2. 가져온 네트워크 범위를 서브넷으로 나눠 바운더리를 나눠준다.
3. 인터넷으로 연결되어 통신할 수 있게끔 라우팅 설정하기
4. 접속이 허용된 사람이 프라이빗 클라우드에 접속 할 수 있도록 설정하기

VPC의 라우팅 기법 CIDR(Classless inter-domain routing)

CIDR는 사이더라고 불리우며, 클래스 없는 도메인 간 라우팅 기법으로 1993년 도입되기 시작한 국제 표준의 IP주소 할당 방법이다. ()

기존에는 클래스에 따라 정해진 Network Address와 Host Address를 사용해야 했다면, CIDR은 원하는 블록만큼 Network Address를 지정해 쓸 수 있다.

예시를 들자면, 

여기서 /16은 첫 16bit를 Network Address로 사용한다는 의미로, 총 2^16인 65,536개의 IP주소를 사용할 수 있는 네트워크 블록을 표시한다.

AWS에서는 RFC 1918에 명시된 ip주소를 사용할 것 권장한다. 해당 ip주소 대역을 한번 살펴보면 다음과 같다.

왜냐하면 이 RFC규약을 안지키고 ip주소 대역을 사용하면 퍼블릭 ip와 프라이빗 ip가 엉켜서 네트워크 통신에 혼선이 올 가능성이 있기 때문이다.

서브넷(Subnet)

서브넷은 서브네트워크(Subnetwork)의 줄임말로 IP 네트워크의 논리적인 하위 부분이다. 서브넷을 통해 하나의 네트워크를 여러 개로 나눌 수 있다. VPC를 사용하면 퍼블릭 서브넷, 프라이빗 서브넷, VPN only 서브넷 등, 필요에 따라 다양한 서브넷을 생성하면 된다.

• 퍼블릭 서브넷 : 인터넷을 통해 연결 할 수 있는 서브넷
• 프라이빗 서브넷 : 인터넷을 연결하지 않고, 보안을 유지하는 배타적인 서브넷
• VPN only 서브넷 : 기업 데이터 센터와 VPC를 연결하는 서브넷

서브넷은 VPC의 CIDR 블록을 이용해 정의되며, 최소 크기의 서브넷은 4bit부분만 서브넷으로 사용하는 /28 이다. 이때 주의 할 점은 서브넷은 AZ당 최소 하나를 사용할 수 있고, 여러 개의 AZ에 연결되는 서브넷은 만들 수 없다.

VPC 서브넷 권고사항

두번째 /24 서브넷에서 가용주소의 갯수가 251개인 이유는 AWS가 확보한 서브넷 중 처음 네 개의 IP주소와 마지막 IP주소는 AWS측에서 네트워크 관리를 위해 사용하기 때문이다. 그래서 예를 들어, 10.0.0.0/24 체계의 CIDR 블록이 있는 서브넷에서 10.0.0.0, 10.0.0.1, 10.0.02, 10.0.0.3, 10.0.0.255 등 5개의 IP주소는 사용자가 사용하지 않고, AWS에서 사용한다.

라우팅 테이블(Routing Table)

트래픽의 전송 방향을 결정하는 라우트 규칙을 만들어 정리한 것 라우팅 테이블이라고 한다. 

즉, 라우팅 테이블은 하나의 지점에서 또 다른 지점으로 가기 위한 모든 정보를 제공하기 위한 테이블이다.

특정 VPC의 서브넷이 라우팅 테이블에 인터넷 게이트웨이(VPC와 인터넷 간 통신을 가능하게 하는 구성요소)를 포함하고 있다면, 해당 서브넷은 인터넷 액세스 권한 및 정보를 가지게 된다.

각각의 서브넷은 항상 라우팅 테이블을 가지고 있어야 하며, 하나의 라우팅 테이블 규칙을 여러 개의 서브넷에 연결하는 것도 물론 가능하다. 서브넷을 생성하고 별도의 라우팅 테이블을 생성하지 않는다고 하더라도 AWS 클라우드가 자동으로 VPC의 메인 라우팅 테이블을 연결한다.

VPC 네트워크 보안

Network ACLs

서브넷 단위로 적용가능한 방화벽이다.

 다만 적용방식이 stateless(비연결) 즉, 상태를 보관하지 않는다. 그래서 인바운드로 80번 포트를 열어줬다면, 80번포트의 아웃바운드가 같이 허용되는 것이 아니라 관리자가 따로 설정해줘야만한다.

기본적으로 모든 트래픽을 block하도록 설정돼있기 때문에 연결을 하고싶다면 따로 설정해줘야한다.

보안 그룹

인스턴스에 대한 인바운드/아웃바운드 트래픽을 제어하는 가상 방화벽이다.

 NACL과 다른 점은 보안 그룹은 stateful(연결) 즉, 상태를 보관한다. 그래서 인바운드로 80번 포트를 열어줬다면, 기본 아웃바운드 설정이 미허용이더라도 80번 포트에서 통신을 했던 상태(state)를 기억하고 있기 때문에 따로 설정해주지 않더라도 데이터의 왕래가 가능하다.

VPC 간 연결: VPC peering

 인증, 로깅과 같은 기능의 공통 모듈을 만들어서 서비스 구축에 적용하고자 할 때, 이 리소스들을 외부와 격리시킨 네트워크에서 사용하도록 하고싶을 때 VPC peering기능을 사용해 데이터센터 - 데이터센터 간의 직통라인처럼 VPC간의 연결을 해서 훨씬 프라이빗한 통신을 가능하게 해준다.

 VPC 피어링을 통해서 VPC간의 연결을 하면, 각각 VPC가 가진 보안 그룹들을 서로 참조할 수 있어 보안성을 강화할 수 있다.

 여담으로 다른 계정이 가진 VPC와도 peering을 할 수 있다.

VPC peering 절차

VPC 피어링은 그냥 설정만 한다고 만들어지는 것이 아니다. 그래서 어떻게 만들어지는지 살펴보면

1. 한쪽에서 피어링 요청을 시작한다.
2. 피어링 요청을 받은 VPC가 요청을 수락하고, 수락한 응답을 요청한 쪽으로 보낸다.
3. 양쪽에서 서로에게 통신할 수 있도록 설정하는 라우팅 테이블을 만들어준다.

이렇게 편해보이는 VPC 피어링에서 제약사항이 있다.

 위 이미지에서 볼 수 있듯이 A-C, A-D간 통신은 가능하지만, C-D경로의 통신은 불가능하다. 이것은 VPC의 프라이빗한 특성을 보호할 수 있는 특성이다.

서비스(회사) 네트워크와 VPC의 연결

비즈니스의 중요한 정보가 오고가는 통신환경에서 인터넷을 통해 VPC - 회사 간의 통신을 한다는 것은 보안적으로 굉장히 부담스러운 일이다. 그래서 VPC에서는 회사네트워크와 프라이빗하게 연결할 수 있는 방법을 제공하고 있다.

VPN(Virtual Private Network)

 먼저 VPN을 사용해서 프라이빗한 연결을 구현하기 위해서는 먼저 연결하고자하는 회사측의 VPN 장비가 필요하다.

이것을 AWS VPC에 있는 Gateway에 연결하면된다.

 아 혹시라도 회사의 VPN장비와 AWS VPN이 호환이 안되면 어떡하지? 라는 고민은 하지 않아도 좋다.

 VPC VPN연결을 설정할 때, 회사측의 VPN 장비가 어떤장비인지 AWS에게 알려주면, AWS측에서 맞춤 연결을 해주기 때문이다.

참고 : https://www.youtube.com/watch?v=R1UWYQYTPKo 

https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-VPC-%EA%B0%9C%EB%85%90-%EC%82%AC%EC%9A%A9-%EB%B3%B4%EC%95%88-%EC%84%A4%EC%A0%95-Security-Group-NACL#security_group_%EB%B3%B4%EC%95%88%EA%B7%B8%EB%A3%B9

오늘은 AWS에서 제공하는 서비스들에는 어떤 것들이 있는지, 그 중에서도 ec2와 스토리지, RDS 에 대해서 자세히 알아봤다.

AWS 서비스

AWS 에는 엄청나게 많은 서비스들이 있다. 그래서 어떤 종류의 서비스가 있는지 대략적으로만 알아보자.

컴퓨트(Compute)

컴퓨트 서비스에는 클라우드에서 높은 확장성과 높은 컴퓨팅 파워를 동시에 제공하기 위한 서비스들이 있다.

이 서비스들은 기본적으로 서버와 서버리스 기반 모두의 환경 설정 기능이 제공되고, 리소스 확장과 애플리케이션의 배포를 효과적으로 만들어주는 도구들이 포함된다. 제공되는 서비스는 다음과 같다.

• Elactic Compute Cloud(EC2)
• EC2 Auto Scaling
• Lambda
• EC2 Container
• Elastic Kubernetes

네트워킹 (Networking)

네트워킹 또한 AWS의 주력 서비스 중 하나다. 기업에서 구축한 클라우드 인프라를 외부요소, 혹은 내부의 다른 요소들과 분리/연결을 할 수 있도록 도와주는 서비스다. AWS는 네트워킹에 있어서 수많은 옵션들을 제공하고, 그것으로 애플리케이션 구성요소 간의 상호작용을 최적화 시킬 수 있다. 제공되는 서비스는 다음과 같다.

• Virtual Private Cloud
• Route 53
• Elastic Load Balancing
• Direct Connect
• App Mesh
• Global Accelerator

보안 (Security)

클라우드 보안은 두말할 것도 없다. AWS에서 가장 신경쓰고 있는 부분 중 하나다. 고객 데이터, 그리고 서비스 인프라를 효과적으로 보호하기 위해서 보안 레이어가 제공되고, 인프라에 관련된 여러 준수규정 매뉴얼 도 제공된다. 그 준수규정들은 다음과 같다.

• Identity and Access Management(IAM)
• Inspector
• Certificate Manager
• Directory Service
• GuardDuty
• Shield
• Web Application Firewall
• Macie
• Secrets Manager
• KMS

스토리지 (Storage)

AWS는 엄청 다양하고 강력한 데이터 저장 서비스를 제공하고, 고객은 각자의 비즈니스에 알맞는 스토리지 서비스를 선택할 수 있다. 제공되는 서비스는 다음과 같다.

• Identity and Access Management(IAM)
• Simple Shared Storage(S3)
• Amazon Glacier
• Elastic Block Store (EBS)
• Elastic File System (EFS)
• Storage Gateway
• CloudFront

데이터베이스 (Database)

AWS는 관계형(RDBMS), 비관계형(NoSQL)같은 유형에 제한 받지 않는 다양한 데이터베이스 서비스와 웨어하우징 서비스, 인메모리 캐싱 서비스를 제공한다. 제공하는 주요 서비스 목록은 다음과 같다.

• Relational Database Service(RDS)
• DynamoDB
• Redshift
• ElastiCache
• Aurora
• DocumentDB

개발자 도구

AWS는 개발 환경설정같은 자잘한 업무에 대한 부담을 줄이고 좀 더 신속하게 코드를 개발/배포할 수 있는 다양한 서비스를 제공한다. S/W 라이프사이클 동안 해야 할 다양한 업무를 연속적으로 처리할 수 있도록 다양한 개발환경에서 사용할 수 있는 여러 SDK 및 도구를 제공하며 이를 이용해 작성한 코드를 즉시 배포할 수 있도록 도와주는 서비스다. AWS가 제공하는 주요 개발자 도구 서비스는 아래와 같다.

• CodeCommit
• CodePipeline
• CodeBuild
• CodeDeploy

메시징(Messaging)

클라우드로부터의 notification 수신, 애플리케이션에서의 메세지 발송, 구독자에 배포, 메시지 큐 관리 등 메시징을 위한 폭 넓은 서비스를 제공한다.

• Simple Notification Service (SNS)
• Simple Email Service (SES)
• Simple Queue Service (SQS)