[AWS] Solutions Architectures(솔루션 아키텍처) 세 번째

Stateful Web App : MyWordPress.com

• 완전히 확장 가능한 WordPress 웹사이트를 만들려고 한다.
  WordPress는 웹사이트를 만드는데 흔히 사용되는 방법으로 아주 인기가 많다.
  사람들은 WordPress를 AWS에 배포하는 걸 좋아한다.
• WordPress가 작동하는 방식으로 어떤 드라이브에 그림을 저장하고 기본적으로 모든 인스턴스들이 그 데이터에 접근해야 한다.

 

RDS layer

(출처 : 구글이미지)

• 첫 번째로 할 일은 RDS가 있는 계층을 생성하는 것이다.
• 다중 AZ이고 모든 EC2 인스턴스에 걸쳐 적용된다. 만약 정말로 크게 확장하고 싶다면 어떻게 할까?
  다음 예시를 보자.

Scaling with Aurora : Muti AZ & Read Replicas

(출처 : 구글이미지)

• 위의 계층을 오로라 MySQL로 교체할 것이다. 다중 AZ, 읽기 전용 복제본, 원하면 글로벌 데이터베이스까지 적용할 수 있다. 오로라를 사용함으로써 연산을 줄일 수가 있다. 오로라는 보다 확장성이 있고 기록하기 쉽기 때문이다.
• 이제 이미지 저장에 대해 다루는 다음 예시를 보자.

Scaling with Aurora : Storing images with EBS

(출처 : 구글이미지)

• 하나의 EC2 인스턴스가 있고, 하나의 EBS 볼륨이 연결되어 있는 단일 AZ의 아주 단순한 솔루션 아키텍처를 살펴보자.
• 일단 로드 밸런서에 연결되어 있다. 사용자는 로드 밸런서로 이미지를 보내고 그 이미지는 EBS까지 도달한다.
  그리고 EBS에 저장된다.
• EC2 인스턴스가 하나일 때는 EBS 볼륨까지 바로 연결되고, 이미지를 불러올 때도 정말 잘 작동된다.
  그러나 확장하기 시작하면 문제가 생긴다. 다음 예시로 넘어가 보자.

(출처 : 구글이미지)

• 이제 두 개의 EC2 인스턴스와 두 개의 AZ가 있다. 그리고 각각의 EC2 인스턴스는 각각의 EBS 볼륨을 가지고 있다.
• 위의 인스턴스로 이미지를 보내면 해당 EBS 볼륨에 저장된다. 이미지를 불러오고 싶다면 위의 인스턴스쪽으로가서 읽어들 일 수 있다.
• 그러나 흔한 오류는 이미지를 읽어들이기 위해 아래쪽 인스턴스로 갈 수 있다.
  그러면 같은 EBS 볼륨이 아니기 때문에 아래쪽에는 이미지가 없고, 이미지에 접근 할 수가 없다.

Storing images with EFS

(출처 : 구글이미지)

• 위에 있었던 상황을 해결하려면 EFS를 사용할 수 있다.
• EFS는 탄력적인 네트워크 인터페이스를 위해 각각의 AZ에 ENI를 생성한다.
  이 ENI는 EFS 드라이브에 접근하는 모든 EC2에 사용할 수 있다.
    = 스토리지가 모든 인스턴스에게 공유된다는 점이다.
• M5 인스턴스로 이미지를 보내면 ENI를 거쳐 EFS로 전달되고 이미지가 EFS에 저장된다.
• 이미지를 불러오고 싶다면 아래쪽으로 가서 ENI를 거쳐 EFS로부터 읽어들인다.
• EFS에 그 이미지가 있고 이미지를 보낼 수 있다.
• 이것은 가용 영역이나 인스턴스 숫자에 관계없이 모든 인스턴스가 동일한 파일에 접근하도록 허용하기 위해 다수의 EC2 인스턴스에 걸쳐 웹사이트 스토리지를 확장하는 아주 흔한 방법이다.

 

 

• 위의 내용들로 EBS와 EFS의 차이에 대해 알아가고 싶었다.
    - 적은 연산량과 다중 AZ 및 읽기 전용 복제본을 갖춘 오로라 데이터베이스에 대해 알아보았다.
    - 단일 인스턴스 애플리케이션에서 아주 잘 작동하는 EBS에 데이터를 저장하는 것에 대해서도 알아보았다.
    - 인스턴스가 많아지면 잘 작동하지 않기 때문에 EFS를 사용하여 다중 AZ에 걸친 분산 애플리케이션을 만들 수 있다.

cf) 비용 관점에서 볼 때 EBS가 EFS 보다 싸다. 그러나 EFS를 사용할 때 많은 이점을 얻을 수 있다.