저를 괴롭히는 몇 가지 질문이 있으며 여기에있는 모든 멋진 경험 많은 사람들의 도움을 받고 싶습니다.
1) AWS ec2 t2.medium 인스턴스에서 호스팅되는 phpMyAdmin에 액세스 할 때마다이 특정 문제에 직면하고 있습니다 (빈번하지는 않지만 REST API에 액세스하여 ec2 서버에 파일을 업로드하는 Android 앱이 파일을 업로드하지 못하는 것 같습니다. 아래 네트워크 드롭 중 아마도 AWS를 처음 사용하는 것처럼 확실하지 않을 수 있습니다.)
요청한 서버는 트랜잭션 전에 연결을 닫았습니다.
내 AWS 인스턴스가 실행 중입니다.
2) AWS를 처음 사용하고 AWS에 Laravel 기반 백엔드를 성공적으로 배포했으며 Android 앱은 동일한 ec2 t2.medium 인스턴스에서 호스팅되는 REST API에 액세스합니다. 이제 나를 괴롭히는 것은 자동 확장이 어떻게 될지 모르겠습니까? 미디어 파일을 서버에 업로드하는 동안 많은 사용자가 문제에 직면하여 지금 중단 된 마케팅 캠페인을 실행할 때 7000 명 이상의 사용자가 앱을 다운로드했기 때문에 특정 % ge 이후 파일 업로드를 중지하고 나머지 사용자는 사용할 수 있습니다. 파일을 업로드합니다.
Android 앱은 모든 것을 잘 수행하지만 대부분의 사람들은 AWS ec2 t2.medium 인스턴스에서 호스팅되는 Laravel에서 코딩 된 REST API URL에 파일을 업로드하려고 할 때 문제에 직면하고 아래의 Android 라이브러리를 사용하여 내 서버를 통해 파일을 업로드하고 있습니다. 백엔드의 파일 업로드 API :
https://github.com/gotev/android-upload-service
내가 만든 파일 업로드 laravel API는 다음과 같습니다.
public function uploadFile(Request $request, userSubmitData $udb)
{
$creds = $request->all();
$idFromDB = $udb::where('token', $creds['token'])->value('token');
$uid = $udb::where('token', $creds['token'])->value('user_id');
$hasFile = "false";
$file = $request->file('myFile');
$extension = $file->getClientOriginalExtension();
$fileName = $file->getClientOriginalName();
$fileName = $uid."_".$fileName;
Storage::disk('local')->put($fileName, File::get($file));
$udb->where('token', $creds['token'])->update(['fileHandle' => $fileName, 'mime' => $file->getClientMimeType(), 'original_filename' => $file->getClientOriginalName(), 'approved' => NULL, 'rejected' => NULL]);
$hasFile="1";
return Response($hasFile, 200);
}
확장 가능한 기술을 구축하고 AWS를 내결함성, 확장 성 및 가용성이 뛰어난 아키텍처 및 기술로 효율적으로 설정하는 방법에 대한 통찰력을주십시오.
감사합니다.
추신 : 저는 훌륭한 코더가 아닙니다. 코딩과 아름다운 것들을 만드는 것을 좋아하는 초보 아키텍트 일뿐입니다. 저보다 훨씬 훌륭하고 놀라운 사람들이 있습니다. 하하. 그래서 내가 여기서 일을 실행하는 방식에 신경 쓰지 마십시오. 나는 모든 것이 올바르게 작동하고 아름답게 작동하도록 만드는 과정에 있습니다. :)
두 가지 옵션을 제안 할 수 있습니다. 둘 다 필요한 확장 성과 필요한 내결함성을 제공합니다. 약간 장황하지만 방법을 읽어보고 후속 질문을 자유롭게 물어보십시오! :)
옵션 1-Route53, ELB, ASG 및 이중화.
이 솔루션의 경우 Route53 상태 확인, Elastic Load Balancer 및 Auto Scaling 그룹을 사용해야합니다.
스택 :
Route53은로드 밸런서에 DNS 요구 사항을 제공하지만 매우 좋은 상태 확인 및 자동 장애 조치 기능을 제공 할 수도 있습니다. 고 가용성 전략에서 허용 가능한 내결함성 수준에 따라이 상태 확인을 사용하여 대상 (이 경우 ELB)의 전체 상태를 평가하고 항상 보유한 대체 스택으로 DNS를 장애 조치 할 수 있습니다. 달리고 대기합니다. 비용이 많이들 수 있지만 비즈니스 사례에 따라 다릅니다.
Elastic Load Balancer는 Auto Scaling 그룹의 인스턴스를 대상으로하므로 2 개 이상의 가용 영역을 사용하도록 Auto Scaling 그룹을 구성해야합니다. 즉, AZ가 실패하더라도 클라이언트는 애플리케이션을 계속 사용할 수 있습니다. 둘 이상의 AZ가 동시에 실패하는 것은 매우 드문 일이지만 발생할 수 있습니다. AZ에 장애가 발생하면 나머지 AZ가 매우 빠르게 초과 구독된다는 사실을 알아 두는 것도 중요합니다. 즉, 2 개의 AZ를 사용 중이고 그중 하나가 실패하면 애플리케이션이 50 % 감소 된 용량으로 실행되고 실패한 AZ에서 나머지 AZ로 실행되는 모든 사람으로 인해 Auto Scaling 그룹이 어려움을 겪을 가능성이 있음을 의미합니다. 해당 AZ에서 추가 인스턴스를 자동으로 프로비저닝합니다. 따라서 애플리케이션 고 가용성이 고객에게 프리미엄 품질로 서비스 할 수있는 능력만큼 중요하다면 2 개의 AZ를 사용하는 시나리오를 기반으로한다면 각 AZ에서 BAU 용량을 100 % 프로비저닝해야합니다. AZ 중 하나가 실패 할 경우 나머지 AZ에서 일부 대체 인스턴스를 프로비저닝 할 수 있다는 가능성에 대해 도박하려는 경우이 비율을 더 작은 비율로 줄일 수 있습니다. 또는 다른 AZ (총 3+)를 사용할 수 있습니다.
나는 이것에 대해 며칠 동안 이야기 할 수 있지만, 계속해서 ...
마지막으로 애플리케이션 인스턴스입니다. 선택한 Ubuntu AMI에서 프로덕션 준비 상태로 바로 가져갈 스크립트를 생성해야합니다. Auto Scaling 그룹은 인스턴스의 UserData 메타 데이터에서이 스크립트를 사용하여 새 인스턴스를 시작하고 인스턴스는이를 사용하여 준비됩니다. 이 스크립트가 없으면 Auto Scaling 그룹이 생성하는 모든 인스턴스를 수동으로 설정하고 구성해야하므로 이상적이지 않습니다.
중요 : 메모리의 세션 상태로 인해 애플리케이션을 확장 할 수없는 경우 해결해야하는 문제가있는 것입니다. 이를 수행하는 몇 가지 방법이 있지만 Amazon 방식은 세션 스토리지에 ElastiCache를 사용하는 것입니다. 약간의 작업이 될 수도 있지만 솔루션을 훨씬 더 탄력적으로 만들 것입니다.
이렇게하면 애플리케이션을위한 고 가용성 솔루션이 생성되지만 비용과 HA에 대한 몇 가지 비즈니스 결정을 내리는 데 의존합니다.
옵션 2-진정한 클라우드 및 AWS 접근 방식, 서버리스.
위에서 애플리케이션을 가져 와서 클라우드에 배치하고 높은 수준의 HA 및 QOS를 유지하는 데 드는 비용을 빠르게 확인할 수 있습니다. 그러나 응용 프로그램의 일부 부분을 처음 재개발하는 비용으로 사용할 수있는 더 좋고 저렴하며 적은 유지 관리 방법이 있습니다.
이를 위해 애플리케이션 서버를 효과적으로 제거하고 다음 제품을 사용합니다.
애플리케이션 로직과 인스턴스에 대한 종속성을 Lambda로 대체하면 AZ, ELB, ASG, 중복성 및 실패시 초과 구독에 대해 걱정할 필요없이 코드를 실행할 수 있습니다. Lambda는 매우 비용 경쟁력이 있으며 모든 HA 구성 등으로 인스턴스 애플리케이션을 실행하는 비용의 일부도되지 않을 것입니다.
API Gateway를 사용하면 위의 옵션에 비해 매우 적은 노력과 비용으로 관리 가능하고 가용성이 높은 방식으로 Lambda 함수를 사용자에게 노출 할 수 있습니다.
DynamoDB는 AWS에서 제공하는 NoSQL입니다. HA는 필요한만큼 리소스를 확보 할 수 있도록 빠르고 쉽게 맞춤화됩니다. 대안은보다 전통적인 SQL 경험을 제공하는 Amazon RDS이지만, 하루가 끝날 때에도 여전히 클러스터의 인스턴스에 대한 비용과 약간의 관리 비용을 지불하게됩니다.
저는 옵션 2를 목표로 삼아야하지만 이미 작성되고 클라이언트에 서비스를 제공하는 제품이있는 경우 지금은 옵션 1로 진행하고 HA 및 확장 가능한 확신을 얻은 다음 나중에 옵션 2를 프로젝트해야합니다. .
여기에 제가 논의한 모든 주제에 대한 추가 자료가 있습니다. 필요한 경우 더 많은 질문을 할 수 있습니다.
옵션 1 문서
Route53 상태 확인 및 장애 조치 http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
Elastic Load Balancer https://aws.amazon.com/documentation/elastic-load-balancing/
Auto Scaling 그룹 (시작 구성도 확인 하십시오 ) https://aws.amazon.com/autoscaling/ http://docs.aws.amazon.com/autoscaling/latest/userguide/LaunchConfiguration.html
AWS ElastiCache https://aws.amazon.com/documentation/elasticache/
옵션 2 문서
Amazon API Gateway https://aws.amazon.com/api-gateway/
AWS Lambda https://aws.amazon.com/documentation/lambda/
AWS DynamoDB https://aws.amazon.com/documentation/dynamodb/
Amazon RDS https://aws.amazon.com/documentation/rds/
건배,
자비에르
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다