EC2를 사용하여 여러 대의 서버에 앱을 배포하는 방법은 무엇입니까?

Question

처음으로 상당히 확장이 필요한 응용 프로그램을 개발하고 있습니다. 응용 프로그램을 여러 인스턴스에서 실행해야했던 적이 없었습니다.

어떻게 정상적으로 달성됩니까? SQL 서버를 클러스터링 한 다음 모든 서버에서 프로그래밍을 미러링하고로드 밸런싱을 사용합니까?

또는 하나의 서버에서 일부 서버를 다른 서버에서 실행하는 기능을 분리합니까?

또한 모든 EC2 Windows 인스턴스에 코드를 푸시하는 방법은 무엇입니까?

Answer 1

면책 조항 - 유닉스 컴퓨터에서 항상 작업 해 왔기 때문에 Windows 사양에 대해서는 언급하지 않을 것입니다. 이 지침은 상당히 일반적입니다.

이것은 주관적인 질문이며 모든 사람이 고유 한 시스템을 자신의 스타일에 맞게 조정할 것입니다. 내가 따라야 할 몇 가지 지침이 있습니다.

웹 응용 프로그램 인 경우 프레젠테이션 (프런트 엔드), 미들웨어 (API) 및 데이터베이스 계층을 분리하십시오. 슬라이스 아키텍처는 모 놀리 식 응용 프로그램과 비교하여 최고로 확장됩니다.

1. 데이터베이스 - SQL과 NoSQL의 데이터 저장소에 대한 (당신이 우리 동쪽 가용성 영역에있는 경우 제외) 아마존이 우수하고 고 가용성 서비스를 제공합니다. 관계형 데이터베이스의 경우 RDS을 확인하고 NoSQL의 경우 을 확인하십시오. 확장 성이 뛰어나며 데이터 저장소를 시작한 후에는 데이터 저장소를 관리 /로드/저장하는 것에 대해 걱정할 필요가 없습니다.
2. 미들웨어 API - 이것은 매우 중요한 부분입니다. 백엔드 기능을 서비스로 노출시키는 일련의 API (REST가 좋지만 여기서는 거의 모든 것을 사용할 수 있음)를 갖는 것이 중요합니다. 서비스 지향 아키텍처는 웹, 모바일, 데스크톱, 써드 파티 위젯 등과 같은 다수의 프런트 엔드 클라이언트를 수용 할 수 있도록 매우 쉽게 확장 될 수 있습니다. 미들웨어 API는 일반적으로 비즈니스 로직이 처리되는 곳이 아니어야합니다., 대부분 또는 모두) 높은 성능을 위해 데이터베이스 조회/쿼리로 변환되어야합니다. 이러한 서비스는 고 가용성을 위해로드 균형을 조정할 수 있습니다. 아마존의 Elastic Load Balancers (ELB)은 처음에 유용합니다. 특정 IP 주소 집합에 대한 트래픽을 차단하는 것처럼 더 많은 사용자 지정을 원할 경우 Blue/Green deployments을 수행하면 HAProxy 부하 분산 장치를 개별 인스턴스에 배포하는 방법을 고려해야합니다.
3. 프런트 엔드 - 프레젠테이션 계층이 있어야합니다. 예를 들어 프론트 - 엔드 프래그먼트의 최신 캐시 키를 얻기위한 간단한 Redis 호출과 같이 프론트 - 엔드의 범위에 제한된 것을 제외하고 직접적인 데이터베이스 쿼리는 피해야합니다. 여기서는 서비스 호출에서부터 프론트 엔드 조각에 이르기까지 많은 캐싱을 수행 할 수있는 곳이 있습니다. 정적 자산 게재에는 AWS CloudFront을, 캐시 저장소에는 AWS ElastiCache을 사용할 수 있습니다. ElastiCache는 관리되는 memcached 클러스터입니다. ELB 뒤에 프런트 엔드 노드의로드 밸런싱을 고려해야합니다.

모두 AWS Elastic Beanstalk을 사용하여 자동 크기 조정을 사용하여 번들로 배포 할 수 있습니다. 현재 ASP .NET, PHP, Python, Java 및 Ruby 컨테이너를 지원합니다. AWS Elastic Beanstalk은 여전히 ​​한계가 있지만 모니터링, 확장 및로드 밸런싱을위한 최소한의 번거 로움으로 인프라를 관리하는 매우 멋진 방법입니다.

팁 : 응용 프로그램의 읽기 및 쓰기가 많은 영역을 식별하는 데 많은 도움이됩니다. 그런 다음 인프라를 적절하게 분할하고 한 번에 읽기 또는 쓰기 포커스로 필요한 최적화를 수행 할 수 있습니다.

모든 것을 요약하면 Amazon AWS는 서버 토폴로지를 만드는 데 사용할 수있는 모든 기능을 제공합니다. 구성 요소를 선택하는 것은 사용자에게 달려 있습니다.

희망이 도움이됩니다.

Answer 2

이것은 필요한 요구 사항에 따라 달라질 수 있습니다. 그러나 일반적인 지침 (나는 웹 사이트를 추측하고있다)으로 db, webserver, 캐싱 서버 등을 다른 인스턴스로 분리하고 정적 자산에는 s3 (+ cloudfont)을 사용한다. 또한 합법적 인 부하 만 인프라에 적용되도록 적절한 속도 제한이 있는지 확인해야합니다.

RDBMS 서버의 경우 master-slave db setup (RDS이 더 편하다)을 설정하고 db sharding 등을 사용할 수 있습니다. DB 클러스터 솔루션도 존재하지만 설치가 더 복잡하지만 응용 프로그램 프로그래머를위한 데이터베이스 액세스를 단순화합니다. 나는 또한 모든 db 쿼리와 튠 db/sql 쿼리를 확인합니다. 경우에 따라 순수 NoSQL 유형 데이터베이스는 RDBMS보다 좋을 수도 있고 필요한 데이터에 따라 애플리케이션이 전환되는 두 가지 유형을 혼합하여 사용할 수도 있습니다.

웹 서버의 경우로드 밸런서를 설치 한 다음로드 밸런서 뒤에있는 웹 서버 인스턴스에서 자동 확장을 사용합니다. 앱 서버가있는 경우 유사하게 적용됩니다. 또한 웹 서버 설정을 조정할 것입니다.

캐싱 서버도 인스턴스의 클러스터로 분리됩니다. ElastiCache은 훌륭한 서비스처럼 보입니다. Redis는 memcache에 필적하는 성능을 가지고 있지만 확장 할 때 유용 할 수있는 더 많은 기능 (예 : 목록, 세트 등)을 가지고 있습니다.

Answer 3

내가 할 수있는 방법은 MySQL 서버가 실행되는 DB 서버로 1 대의 서버를 사용하는 것입니다. memcached에있는 모든 데이터는 여러 서버와 클라이언트에 걸쳐 "간단히"memcached에 없으면 db에서 읽은 다음 memcached에 저장하고 반환합니다. "

Memcached는 DB와 비교하여 확장이 쉽습니다. db 스케일링에는 많은 관리 작업이 필요합니다. 그 일을 올바르게하고 일하게하는 고통. 그래서 저는 memcached를 선택합니다. 실제로 필자는 memcached 서버를 추가로 가지고 있는데, 다운 타임 (내 memcached 서버 중 하나 인 경우)을 관리하기 위해서입니다.

내 데이터는 대부분 읽혀지고 글은 적습니다. 그리고 쓰기가 발생하면, 나는 memcached로 데이터를 밀어 넣는다. 이 모든 것이 나를 위해 더 잘 작동합니다. 코드, 관리, 폴백, 페일 오버,로드 균형 방식. 모든 승리. 당신은 단지 "조금"더 나은 코드를 작성해야합니다.

mysql을 클러스터링하는 것은 코드 작성, 배포, 유지 관리 및 유지 및 실행이 더 쉬워 보이기 때문에 더욱 매력적입니다. mysql은 하드 디스크를 기반으로하고 memcached는 메모리를 기반으로하므로 실제로는 10 배 이상 빠릅니다. 그리고 db에서 모든 읽기로드를 처리하기 때문에 db 설정은 정말 간단 할 수 있습니다.

누군가가 여기에 반대되는 주장을하기를 바랍니다. 나는 그 이야기를 듣고 싶습니다.