저는 클라우드 아키텍처를 처음 접했지만 적절한 애플리케이션 개발 경험이 있습니다. 현재 저는 웹 애플리케이션을 통해 5~10명의 사용자가 더 쉽게 액세스할 수 있는 대규모 컴퓨팅 파이프라인을 만드는 과정에 있으며 이 모든 것을 AWS에서 설정하고 있습니다.
현재 구현은 두 개의 API와 MySQL 백엔드를 사용하는 경량 React 웹 앱입니다. 이를 통해 사용자는 매개변수가 있는 작업을 대기열에 추가하고 웹 앱을 통해 또는 실행이 완료된 후 사용자에게 전송된 이메일을 통해 최종 결과에 액세스할 수 있습니다.
이 파이프라인의 중간에는 이러한 단계(64GB RAM, 16개 코어, 1TB HDD)를 계산하기 위해 매우 무거운 시스템이 필요하고 이 한 단계에 대해 최대 1.5일 동안 실행할 수 있는 독점 소프트웨어 부분에 대한 종속성이 있습니다. 이것이 전체 파이프라인 중 가장 큰 병목 현상입니다.
가능한 한 비용을 절약하기 위해 여러 EC2 인스턴스 "에이전트"를 활성화하고, 단계를 실행하고, 이메일을 보내고, 웹에 작성하여 병목 현상/서비스 부분을 확장 가능하고 비용 효율적으로 만들려고 노력하고 있습니다. 그런 다음 웹 앱의 작업에 의해 트리거되는 AWS 람다 함수를 통해 인스턴스를 중지합니다.
이 부분의 동시성/확장성이 매우 작기 때문에 웹 앱용 EC2 인스턴스 1개, API 2개, MySQL 서버를 호스팅할 계획입니다. 또한 5~10명의 사용자가 동시 실행을 공유하기 위해 병목 현상 서비스에 대한 또 다른 1~3개의 인스턴스를 갖게 되어 동시에 진행되는 무거운 단계를 최대 3회 실행할 수 있습니다.
병목 현상 서비스에서는 프로그램을 실행하기 위해 유사한 파일이 필요하고 이러한 단계에 대한 입력은 때때로 150GB의 파일 크기가 될 수 있으므로 입력 전송만 걱정하면 되도록 EFS 또는 S3 스토리지를 사용하여 입력을 보관할 생각입니다. 파일을 EC2 인스턴스 전체에서 공유할 수 있는 한 위치에 저장하면 전송 단계를 수행하기 위해 해당 파일이 시작되었는지 확인할 필요가 없습니다. 이것은 파일 크기가 너무 크기 때문에 더 자동화할 수 있는 좋은 방법을 찾지 못한 수동 작업입니다.
내 질문은 내 설정이 합리적으로 들리며 내 구현 아이디어에 허점이 있습니까? 현재 서비스 인스턴스로 EBS 스토리지를 사용하고 있는데 150GB 전송/유지관리를 위해 입력 위치를 최소화하고 싶습니다. 또한 S3와 EFS는 둘 다 다중 인스턴스 마운트가 가능한 것처럼 보이므로 차이점을 잘 모르겠습니다. 하지만 어느 것을 사용해야 합니까? 그리고 작업이 완료된 후 데이터베이스에 쓸 수 있는 서비스가 필요한 경우 웹 앱, API 및 데이터베이스를 하나의 EC2 인스턴스에 유지하는 것이 합리적입니까? 해당 인스턴스는 항상 켜져 있습니다.
도와주셔서 감사하고, 제가 순진하게 말한 것이 있다면 용서해주세요.
답변1
귀하의 설정은 합리적으로 들립니다. 귀하의 API를 "호스팅"하기 위해 API 게이트웨이를 고려해보고 그것이 귀하에게 적합한지 생각해 보시기 바랍니다. 또한 Auto Scaling 그룹에 로드가 많은 EC2 인스턴스를 두는 것을 고려해 볼 수 있으며, 인스턴스 대신 Lambda 제어가 인스턴스와 상호 작용하도록 할 수도 있습니다.
S3와 EFS는 서로 다른 데이터 스토리지 솔루션입니다. S3는 객체 스토리지이고 EFS는 파일 스토리지입니다. S3는 마치 다른 유틸리티를 통한 것처럼 표시될 수도 있지만 정확하게 마운트할 수는 없습니다. 그것이든옳은S3 또는 EFS를 사용하는 방법은 거기에 있는 파일을 어떻게 사용하는지에 따라 다릅니다.
데이터베이스의 경우 버스트 가능한 인스턴스 클래스 또는 서버리스 옵션 중 하나를 사용하여 RDS로 이동하는 것을 고려할 수 있습니다. 하지만 이는 예산과 사용 사례에 따라 달라집니다.
답변2
일반적으로 클라우드에서는 서버보다는 서비스를 활용해 보는 것이 좋습니다. 비용에 유의해야 하지만 이를 통해 솔루션을 더욱 강력하고 빠르며 규정 준수 수준을 높일 수 있습니다.
귀하의 작업량에 대해 몇 가지 생각이 있습니다.
- 많은 AWS 람다 함수를 호출하는 AWS Step 함수와 같은 오케스트레이터를 사용하여 계산을 수행할 수 있습니까? 람다는 아마도 AWS에서 가장 비싼 컴퓨팅 시간이므로 이상적이지 않을 수도 있습니다. 제한이 올바르게 설정되고 워크로드가 적절하면 10,000개의 람다를 시작하고 15분 안에 작업을 병렬로 수행할 수 있습니다.
- EFS/S3 대신 골든 EC2 이미지/AMI를 생성한 다음 모든 작업에 대해 해당 작업을 처리할 수 있을 만큼 큰 스팟/동적 EC2 인스턴스를 회전시키는 것은 어떻습니까? Lambda는 어떤 유형의 이벤트를 기반으로 작업을 조정할 수 있을까요? 그러면 데이터 전송 요금이 부과되지 않습니다. 하지만 EBS/S3에 요금이 부과되는지 여부는 확실하지 않습니다. 스팟 컴퓨팅은 매우 저렴하며 지역/AZ/인스턴스 크기를 올바르게 선택하면 중단이 거의 발생하지 않습니다. 중단된 인스턴스는 종료되고 EBS 볼륨은 유지되므로 작업이 정기적으로 디스크에 기록되고 다시 시작될 수 있으면 더 잘 작동합니다.
나는 아마도 그 거대한 작업을 최적화하는 데 시간을 좀 투자했을 것입니다.