MySQL을 사용하는 Java EE 웹 응용 프로그램의 Amazon Cloud 구성

Question

제 작품에서 기존의 일부 엔터프라이즈 Java 응용 프로그램을 AWS로 옮겨야합니다. 나는 aws.amazon.com에 많은 페이지를 훑어보고 또한 충분히 googled했다. 또한, stackoverflow에서 모든 관련 질문을 통해 갈려고했습니다. 이 모든 것들이 많은 것들을 분명하게 만들었지 만, 나는 아직도 혼란 스러움을 가지고 있습니다. 다음은 우리의 애플리케이션 구조입니다 :

1. 스프링 MVC를 표현 레이어로 사용하고 비즈니스 및 데이터 로직을 처리하기위한 일반 Java 인터페이스 및 클래스를 사용하는 스프링 기반 응용 프로그램입니다.
2. MySQL은 지속성을 위해 사용됩니다.

따라서 응용 프로그램 아키텍처는 충분히 간단합니다. 그러나이 응용 프로그램의 많은 인스턴스를 배포해야한다는 것이 문제입니다. 이 수는 현재 15이며 30을 초과 할 수 있습니다. 한 가지 더 요점은이 모든 인스턴스가 공통 데이터베이스를 공유한다는 것입니다. 응용 프로그램에 대한

1. 높은 내결함성을 : 지금 여기

   우리가 AWS로 이동하여 달성하는 데 필요한 것입니다. 최근에 우리는 몇 시간의 다운 타임을 야기하는 전용 호스팅에서 서버/전원 장애를 경험했습니다.

2. 응답 시간 및 처리량면에서 모든 응용 프로그램 인스턴스의 성능이 향상되었습니다.
3. MySQL의 내결함성이 향상되었습니다. 근본적으로 MySQL이 예기치 않게 중지되는 일부 하드웨어 (하드 드라이브)로 인해 응용 프로그램 인스턴스가 우리 서버 중 하나에 최근에 다운되었습니다. 하드 드라이브의 전체 파일 시스템이 읽기 전용으로되어 해당 서버에서 호스팅되는 응용 프로그램 인스턴스가 오작동을 일으켰습니다.
4. 분명히 인프라 관리의 총 비용과 오버 헤드를 줄입니다.

지금까지 내가 지금까지 AWS 인프라를 이해할 수 나처럼, 우리가 우리의 설치에 AWS에 필요한 것 인 것이다 : 일부 EBS의,

1. 4 경우, 각각의 호스팅 약 10 응용 프로그램 인스턴스 Tomcat과 MySQL이 설치된 LINUX AMI를 기반으로합니다.
2. 나는 4 인스턴스 각각에 대해 내결함성을 위해 1 인스턴스가 필요하다고 추측하고있다.
3. 모든 서버 인스턴스에는 약 160GB의 EBS가 있습니다. 스냅 샷 등 같은
4. 4 개 탄성 IP를
이
5. 4 탄성로드 밸런서
6. 다른 물건

지금 여기 내 질문은 :

1. 난 정말 그 여분의 서버 인스턴스를해야합니까 EBS가 AWS에 의해 자동으로 백업된다는면을 고려하여 각 주 서버 인스턴스에 대해 (내결함성을 위해) 하드웨어 장애 발생시 새로운 EBS에 동일한 데이터를 제공합니까?

2. 위 시나리오에서 모든 서버 인스턴스 (4x2)간에 어떻게 데이터베이스를 공유합니까? 하나의 옵션은 MySQL 클러스터링을 구현하는 것입니다. MySQL 클러스터에는 1 개의 관리 노드, 3 개의 SQL 노드 및 4 개의 데이터 노드가 포함됩니다.그러나이 경우 클러스터를 유지 관리하는 것은 추가 오버 헤드가 될 수 있으며 인프라 관리를 없애기 위해 허용되지 않을 수 있습니다.

3. 데이터베이스 대신 RDS가 있어야하고 모든 서버 인스턴스 (4x2)에서 MySQL 인스턴스를 제거해야합니까? 그렇다면 EC2 인스턴스 외에도 RDS 인스턴스를 구입해야합니까 (RDS에 대해 별도의 인스턴스를 구입해야한다면 전체 인프라 비용이 적어도 75 % 증가 할 것입니다). RDS 인스턴스는 또한 계산 단위 응용 프로그램 개발을 위해 응용 프로그램 배포를위한 총 인스턴스 수를 줄이십시오?

4. RDS 구현의 경우 실제로 EBS 기반 EC2 인스턴스가 필요합니까? RDS 인스턴스가있는 EC2 인스턴스에서 EBS 요구 사항을 제거하는 방법이 있으면 전체 비용을 줄일 수 있습니다.

아무런 도움이 필요 하시겠습니까? 제 문제를 명시하고 어떤 점에 대해 더 명확히해야하는지 명확하지 않은 경우 알려주십시오.

Answer 1

저는 인프라 전문가는 아니지만 AWS에 대한 경험이 조금 있습니다. 질문에 대해 도움이 되었기를 바랍니다. 내 배경을 통해 인프라 크기 조정에 대한 조언을 드릴 수는 없지만 인프라 종류에 대한 자문을 제공 할 수는 있습니다.
우선 EBS와 꼭 같이 갈 것입니다. 응용 프로그램 서버와 물리적으로 분리되는 것 외에도 높은 안정성과 높은 가용성을 제공합니다. 나는 그것이 몇 번 나를 구했다고 말할 수있다. 크기 조정에 관해서는 아무 것도 말하지 않겠지 만 여분의 "내결함성"인스턴스가 필요하지는 않다고 생각하지만 어쩌면 2 인스턴스를 준비하여 트래픽을 제거 할 수 있습니다.

DB에 관해서는 반드시 RDS for MySQL (http://aws.amazon.com/rds/mysql/)을 사용해야합니다. 이 노드는 사전 구성된 노드, 자동 패치, 자동 백업, 자동 복제 및 원 클릭 스케일링을 (IMHO) 작은 가격으로 제공합니다. 이 모든 기능은 MySQL을 위해 즉시 사용할 수 있습니다. 메트릭 및 모니터링을 사용할 수도 있습니다. 모두 포함되어 있습니다. RDS는 컴퓨팅 장치를 제공하지 않지만 AWS에서 별도로 유지하는 것이 좋습니다. 또한 4 개의 EC2 Tomcat 노드 + 2 개의 RDS 노드로 설정을 할 수 있습니다. 크기 조정의 문제 일뿐입니다.

Amazon Elastic Load Balancing에 대해 이미 읽었 으면 솔루션에 가장 적합합니다. EC2 노드를 각 ELB 노드에 연결할 수 있으며로드 균형 조정을 잊어 버릴 수 있습니다. 그냥 작동하고 원하는 경우 고정 세션을 구성 할 수도 있습니다. 얼마나 많은 ELB 노드를 선택해야할지 모르지만 한 가지 문제에 유의하십시오. 동일한 지역 (예 : 미국 동부 해안)의 EC2 노드 만 동일한 ELB에 추가 할 수 있습니다. 예를 들어 서부 해안의 Tomcat과 East Coast의 다른 Tomcat 사이의 트래픽을 균형있게 조정할 수는 없습니다. 여러 지역에 노드를 분산 시키려면 Amazon 외부에 다른 LB 솔루션이 필요합니다.

마지막으로 조언 드리겠습니다 : ELB + EBS 기반 EC2 + RDS. 그것은 당신의 모니터링, 배치 및 유지 보수를 단순화 할 것이고 비용은 훨씬 더 낮아지는 경향이 있습니다. AWS에서 인프라를 상향 조정하거나 축소하는 것이 매우 쉽기 때문에 각 노드 종류가 얼마나 필요한지 더 잘 알고있을 것입니다.하지만 놓칠 염려가 없습니다.