로바이

AWS와 연결해서 생각해보면 무슨 "보안 서비스"나 "방화벽" 같은 느낌이 들기도 하는데, 사실은 우리가 소위 말하는

"Gateway Server"에 가깝습니다. 아니면, "서버접근제어" 라고 해도 될 것 같구요.

아시다시피, Private Subnet에 배포된 instance의 경우 외부에서 접근이 차단이 되어 있어서, 운영자 입장에서 ssh로 접근할 방법이 없습니다. 이 경우 Bastion host를 구성해서 외부에서 ssh로 접근이 가능하도록 할 수 있습니다.

모든 private subnet에 있는 instance들을 Bastion host를 통해 접속하도록 설정 및 관리할 수 있습니다.

다만, 보안적으로 Bastion Host가 공격 당하면 내부 네트워크 전체가 위험해 질 수 있으므로, 관리를 잘 해야할 것 같습니다.

- Bastion Host는 Public Subnet에 위치하도록 EC2 Instance를 생성함.

- 외부 사용자들은 Bastion host를 통해 접속함

- 외부 사용자의 특정 IP만 허용하여 Bastion host에 접속 가능하도록 ACL과 Security Group을 설정

- Bastion host를 통해 Private Subnet에 있는 instance로 접속

AWS 공식 사이트에서의 특징을 몇가지 정리해보면

 > 두 가용 영역에 걸쳐 있는 고가용성 아키텍쳐 구성

 > Private subnet의 리소스에 대한 outbound 인터넷 access 허용하기 위한 NAT G/W  (NAT G/W역할도 하나봅니다)

 > EC2 auto scaling 그룹 구성

 > Elastic IP 사용 (인터넷에서 접속이 되어야 하니 당연한거 같습니다)

 > 세분화된 inbound access 제어를 위한 Security Group

Task를 flow에 따라 수행하도록 하는 부분은 같은데, 세부적인 내용을 살펴보면 약간 다른 부분이 있습니다.

완전관리형이냐 아니냐의 차이와 serverless환경에서 수행되느냐 , 모든 리전에서 서비스 하느냐

정도의 차이가 있는 것 같습니다.

SWF (Simple WorkFlow)
 - 2012년 발표
 - 모든 리전에서 서비스 제공
 - Task 통합 관리할 때 세분화된 컨트롤 가능
 - workflow를 배포 및 시작할 수 있는 host(EC2와 같은)가 필요함
 - host의 위치는 상관없음(인터넷을 통해 통신 가능)
 - 비관리형 서비스
 - 사용자가 다루어야할 activity가 많은 대신 복잡해 질 수 있음(자유도 높음)
 - 비교적 긴 사용시간이 필요한 경우 사용

Step Functions
 - 2016년 발표
 - 특정 리전에서만 서비스 제공
 - 완전 관리형 서비스
 - SWF에 비해 Task 통합관리시에 세분화된 컨트롤이 약함
 - AWS Lamda functions을 이용해 배포되므로, 별도의 host 불필요
 - 완전 관리형 서비스의 특성으로 인해 사용자 제어 측면에서는 어느정도 유연성이 떨어짐.
 - 비교적 짧은 사용시간이 필요할 경우 사용

ElastiCache는 주로 DB의 처리 결과를 메모리에 저장했다가 다음 요청시에 저장된 결과를 반환함으로써, 애플리케이션을 빠르게 구동할 수 있게 해줍니다.

앞에서 설명드린 CloudFront와 컨셉만 보면 매우 비슷하죠? 캐싱기능이라는 점에서 유사성이 있긴 합니다. 물론, 사용하는 곳은 전혀 다르지만요... 아키텍쳐 설계 시 두가지를 함께 써서 설계를 하는 문제가 나올 수도...나왔을 수도 있습니다.^^;;;

ElastiCache는 인 메모리 캐시를 간편하게 배포,운영할 수 있도록 도와주는 AWS의 서비스입니다.

인 메모리 캐시는 일반적인 데이터베이스와는 다르게 데이터를 메모리에 올려놓고 사용한다고 하네요.

따라서, 상대적으로 느린 디스크 기반의 데어터 베이스가 아닌 메모리 캐시에서 정보를 검색하고 분석하기

때문에 처리량을 개선할 수 있고, 그로 인해 더욱 고성능의 서비스를 제공할 수 있습니다.

그리고, ElastiCache는 우리가 일반적으로 생각하는 캐싱과 달리, 캐시에도 쓰고, DB에도 함께 쓰는 방식이며, 읽을때만 캐시에서 읽어오는 구조라고 합니다. (흐름도를 그려야 할 경우에 주의가 필요해 보입니다)

아래 그림의 7번,8번 흐름도를 참고하시면 될 것 같네요.

ElastiCache는 현재 Memcached와 Redis 캐싱 엔진을 지원하고 있습니다.

두 캐싱엔진은 특성이 다르기때문에, 사용할 때 특성을 잘 알고 사용해야 합니다.

1. Memcached

  > 클러스터 노드를 추가하여 용량을 증설할 수 있음

  > 간단하게 처리할 때 주로 사용

  > Memcached로 묶인 모든 서버는 동일한 가상 메모리 풀을 공유

  > 분산 메모리 캐시를 적용하게 되므로, 캐싱을 통해 DB나 API호출에 대한 횟수를 줄일 수 있고,

     이로 인해 부하를 줄일 수 있음.

2. Redis

  > 클러스터 구성이 불가하며, 노드 추가로 인한 용량증설 효과를 볼 수 없음

  > 스냅샷 생성과 Read  Replica 기능 사용 가능

  > Read Replica 마스터 캐시 노드의 Failover 기능(Read Replica 승격) 사용 가능

  > Key-Value 저장방식이며, Value에는 일반적인 string외에 set,list,hash와 같은 집합형 데이터 구조를 지원

  > 저장된 데이터에 대한 연산이나 추가 작업 가능

 내용이 조금 복잡해 보일 수 있는데, 찾아보니 대부분의 경우에 Redis를 사용하는 것이 더 좋다고 하네요.

이부분은 아래 사이트에 잘 정리가 되어 있습니다.

http://blog.leekyoungil.com/?p=200

AWS 공식 홈페이지에서 정의하는 CloudFront에 대한 설명을 보시면....

Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다.

CloudFront는 엣지 위치라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가

요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 라우팅되므로 콘텐츠 전송 성능이 뛰어납니다.

 라고 되어 있습니다.

일반적으로 CDN(Contents Delivery Network)하고 동일한 개념으로 알려져 있습니다.

조금 풀어서 정리해보면, 아래와 같습니다.

1. 웹 콘텐츠(정적 및 동적 콘텐츠)를 사용자에게 빨리 배포하기 위한 서비스이다.

2. Edge location을 통해 서비스를 제공한다.

3. 사용자 요청시 가장 지연지간이 낮은 Edge location에서 서비스 한다.

일반적으로 웹 콘텐츠를 S3에 보관을 하게 됩니다. 다시말해서 CloudFront 와 S3 조합을 많이 사용하게 되죠.

다행히도, S3에서 CloudFront로 데이터 전송비용은 무료라고 하네요.(CloudFront 서비스가 무료라는 얘기는 아닙니다)

그럼, 동작 원리를 한번 보시죠...(AWS 공식 홈페이지에서 퍼왔습니다.)

위에 번호하고 아래 설명을 맵핑해서 보시면 됩니다.

먼저 CloudFront 를 구성한 후,

1. 사용자가 객체를 요청합니다.

2. DNS가 최적으로 서비스할 수 있는 CloudFront Edge-Location으로 요청을 라우팅합니다.

   (위에서 설명드린대로, 가장 지연시간이 낮은 Edge-Location으로 라우팅합니다.)

3. 파일이 Edge-Location의 캐시에 있으면, CloudFront는 요청한 파일을 사용자에게 반환합니다.

   파일이 없을 경우에는

   3a. 오리진 서버에 파일 요청을 합니다.

   3b. 오리진 서버는 파일을 Cloud Edge-Location으로 보냅니다.

   3c. Edge-Location은 사용자에게 파일을 전달합니다.

 > 다른 사용자가 동일한 파일을 요청할 경우 Edge-Location은 캐시에 있는 파일을 사용자에게 반환합니다. (1->2->3)

VPC간 연결 방법으로 가장 쉽게 생각할 수 있는 방법에는 VPC Peering 이 있습니다.

교육후기에 공유했듯이 VPC Peering을 할 경우 VPC의 IP대역대가 겹치면 안되고요,
Internet Gateway는 필요하지 않습니다.

Public N/W을 타지 않기때문에 인터넷망에서 발생할 수 있는 보안 이슈 및 DDOS로 인한 영향을
받지 않습니다.

다만, 아래와 같이 여러 VPC간 VPC peering을 사용할 경우 네트워크가 복잡해 질 수 있습니다.

이 경우 사용할 수 있는 것이 AWS Transit Gateway입니다.

아래와 같이 Transit Gateway를 사용하여 네트워킹 모델을 단순화 할 수 있습니다.

Transit Gateway는 다른 VPC들의 Hub가 되어 VPC간 통신 연계를 가능하게 해줍니다.
Resource Manager를 통해서 Transit Gateway를 타 계정에 공유해서 타 계정의 VPC와 연동도 가능합니다.
On-Premise에서는 Transit Gateway로의 접근은 VPN방식으로만 가능하며, 일부 리전에서만 Direcet connet를
지원한다고 하네요. (매우 중요)

AWS 공식 사이트에서 언급한 특징은 아래와 같습니다.

==================================================

다음은 VPC Transit Gateway에 대해 알아두어야 할 몇 가지 다른 사항입니다.

> AWS 통합 – Transit Gateway는 Amazon CloudWatch에 지표를 게시하고 VPC Flow Log 레코드를 생성합니다.

> VPN ECMP 지원 – VPN 연결에 대해 ECMP(Equal-Cost Multi-Path) 지원을 활성화할 수 있습니다. 여러 연결에서 동일한

                          CIDR 블록을 알리는 경우 트래픽이 해당 연결 간에 균등하게 분산됩니다.

> 라우팅 도메인 – 동일한 Transit Gateway에 여러 개의 라우팅 테이블을 사용하고, 연결별로 라우팅을 제어하는 데 이러한
                        라우팅 테이블을 사용할 수 있습니다. VPC 트래픽을 격리하거나 특정 VPC에서 별도의 점검 도메인으로
                        트래픽을 우회시킬 수 있습니다.

> 보안 – VPC 보안 그룹과 네트워크 ACL을 사용하여 온프레미스 네트워크 간의 트래픽 흐름을 제어할 수 있습니다.

> 요금 – Transit Gateway가 연결되어 있는 시간에 대한 시간당 요금과 GB당 데이터 처리 요금을 지불합니다.
      
> Direct Connect – 현재 AWS Direct Connect 지원 기능을 개발하는 중입니다.