AWS Summer: EFS 및 Lambda+ 서버 프레임워크 없음

가을이 막 지나갔습니다. 이것은 완벽한 순간이었습니다. AWS가 작년 여름에 발표한 기능들을 돌이켜보면 - 특정한 순서가 없습니다. 단지 저는 그것들이 멋있다고 생각했기 때문입니다. - 그리고 유용합니다:)

서버 문제 없음

만약 당신이 이미 한동안 서버 없는 응용 프로그램을 개발했다면, 확실한 것은 낡은 냉각 시작 문제를 제외하고, 당신은 몇 가지 도전에 직면하고 있으며, 이러한 문제들은 어느 정도에 설정의 병행 특성을 통해 해결되었다는 것이다.
예를 들어 Lambda 함수에 사용되는 대형 규칙 파일을 불러와야 한다고 가정하면 이 함수는 규칙 엔진을 실현하거나 호출 사이에 이 함수가 동적으로 생성된 데이터 파일을 보존해야 합니다.Lambda는 일부 국부 공간을 제공합니다. - 512MB - 사용할 수 있지만, 매우 작고 짧기 때문에 이런 장면에는 쓸모가 없습니다.
데이터베이스에 저장-RDS, DynamoDB, S3...그러나 그에 따른 것은 개발, 성능, 원가의 비싼 대가다.만약 우리가 초당 수백 또는 수천 개의 요청의 최고치가 있다면, 시작할 때 큰 파일을 불러오고 동시에 파일을 데이터에 기록해서 저장하면 어떻게 됩니까?
좋습니다. 적어도 우리는 파일의 크기에 따라 성능에 큰 영향을 받을 수 있습니다. 시작할 때 파일을 검색하는 지연 + Lambdas의 차가운 시작 - 입력 설정 및 발송 - 중간 파일을 데이터 저장소에 저장하는 지연 - S3에서 저장하고 검색하는 것은 DynamoDB에서 저장하고 검색하는 것과 다릅니다.
그래서 선택의 여지가 없나요?응, 우리는 운이 좋았어. 왜냐하면 AWS가 6월에 Lambda에 대한 지지를 발표했기 때문이야!
EFS AWS의 이미지 특성
Amazon은 널리 알려져 있기 때문에 저는 이 서비스에 대해 깊이 연구하지 않고 Amazon Elastic File 서비스가 NFS 파일 시스템을 제공하여 수요에 따라 업그레이드하고 높은 흡수량과 낮은 지연을 제공할 수 있음을 언급하고 싶습니다.스토리지와 병렬 액세스에 필요한 서비스를 공유할 때 유용합니다.

구성 및 고려 사항

'권력은 책임을 가져온다', 또는 우리의 예에서 강력한 기능은 약간의 배치 제약을 가져온다.EFS는 VPC 내의 서로 다른 서브넷에서 실행됩니다. 이것은 우리의 Lambda 기능도 반드시 VPC 내에서 실행되어야 한다는 것을 의미합니다.이에 따라 IP 방향, 성능 손실 가능성, AWS 글로벌 서비스와의 연결 중단, 예를 들어 NAT 게이트웨이나 전용 링크/게이트웨이를 사용해야 할 수도 있습니다.
작년에 EFS가 발표되었을 때 이 제약은 크게 개선되었다. 몇 개의 ENI만 허용하기 때문에 몇 개의 IP만으로도 대량의 Lambda 호출을 처리하고 기능 확장과 ENI 설정을 분리할 수 있다.

구성 - 서버 프레임워크 없음

다음 그림과 같이 전용 네트워크 리소스에 액세스하기만 하면 전용 네트워크 탭에서 실행되는 Lambda 함수의 구성이 간단할 수 있습니다.
Hyperplane ENI for Lambda 서버 프레임워크 YAML - 이미지 MNube가 없습니다.조직하다
Lambda 기능은 ENI의 서브넷 ID를 배치하고 네트워크 인터페이스를 생성, 삭제, 설명할 수 있는 보안 그룹을 필요로 합니다.
VPC Lambda-Image MNube.조직하다
Lambda 기능은 현재 우리의 전용 네트워크에서 실행되고 있으며, 선택한 서브넷마다 ENI를 설치하지만, EFS 인스턴스에 액세스하기 위해서는 다음과 같은 라이센스가 필요합니다.
역할 라이센스 EFS, Lambda - 이미지 MNube.조직하다
이제 VPC 내에서 EFS를 생성할 수 있습니다.이를 위해 콘솔, Cloudformation, Serverless, AWS CLI, AWS SDK 등...사용할 수 있습니다.
EFS 인스턴스 - 이미지 MNube.조직하다
실례를 만든 후에 응용 프로그램에 접근할 수 있도록 액세스 포인트를 제공해야 합니다.이것은 "AWS::EFS::AccessPoint"라는 새로운 리소스입니다.이것은 컨트롤러에서 만들 수도 있고, 클라우드 formation 파일을 통해 만들 수도 있습니다. EFS ID: ${self.provider}를 제공해야 합니다.
서버 프레임워크 YAML - 이미지 MNube가 없습니다.조직하다
마지막으로 Lambda 함수에 파일 시스템을 연결하여 EFS의 arn, 액세스 포인트의 arn, 로컬 마운트 경로를 제공합니다. 다음 그림과 같습니다.
이미지 MNube.조직하다
EFS 인스턴스는 Lambda 함수로 액세스할 준비가 되었습니다:)

솔루션

저는 이미 를 사용하여 해결 방안을 만들었지만 AWS SAM과 Cloud 9을 공식 대체 방안으로 사용할 수 있습니다.나는 Serverless에 대해 풍부한 경험을 가지고 있으며 이를 몇 개 회사에 소개했는데 Serverless framework를 포함하여 큰 성공을 거두었다.
Everis 아키텍처 - MNube.조직하다
Lambda 함수에서 액세스할 수 있는 규칙 파일을 만들거나 전송합니다.
AWS DataSync, EC2 인스턴스 등 다양한 서비스를 사용하여 파일을 전송할 수 있으며 코드에서 파일을 생성할 수도 있습니다.우리는 EC2에서 전송된 파일을 Lambda 함수에서 접근할 수 있기 때문에 이런 방법을 사용할 것이다.
EC2 인스턴스를 생성한 후 - t2 하나.충분합니다. - VPC의 서브넷에서 EFS ENI에 액세스하려면 디렉토리 -/EFS가 필요합니다.이 디렉토리에는 EFS 인스턴스에 대한 링크가 없으므로 디렉토리를 마운트해야 합니다.
한 가지 방법은 EFS 도구를 사용하는 것입니다.

                     sudo yum install -y amazon-efs-utils

디렉터리를 불러올 수 있는 접근점을 만들었습니다.웹 컨트롤러에서 필요한 명령줄을 쉽게 얻을 수 있습니다.Amazon EFS>Access Point>id 링크로 이동하여 Attach 버튼을 누릅니다.
EFS 설치 - 이미지 MNube.조직하다
디렉터리 (녹색) 를 설치하면 파일을/efs 디렉터리로 전송할 수 있습니다.
파일-IMage MNube를 설치하고 생성합니다.조직하다
이제 Lambda 함수에서 디렉토리에 완전히 액세스할 수 있습니다.디렉토리에 포함된 파일을 나열하는 최소 Lambda 함수를 작성했습니다.
Lambda 함수 - 이미지 MNube.조직하다
이제 솔루션을 배포할 수 있습니다.서버가 없는 부분만 보여줬다는 것을 기억하세요.yml, 인프라 시설을 제공하는 데 사용할 수 있는cloudformation 파일입니다. 연습용으로 남겨 드리겠습니다.
서버 배포 없음-단계 개발-지역 eu-west-1
서버 스택 없음 - 이미지 MNube.조직하다
Lambda 함수를 호출하는 API 게이트웨이를 만들 때 프레임워크는 URL 링크를 제공합니다.
Cloudwatch 로그 - MNUBE의 이미지입니다.조직하다
Cloudwatch 로그에서 요청 추적을 포착했습니다. 그곳에서/efs:test의 파일을 볼 수 있습니다.txt와 규칙.txt와 요청의 낮은 지연.

기타 용례

Lambda 레이어에서 처리할 수 없는 대형 라이브러리를 로드합니다.

정기적으로 업데이트되는 파일입니다.

잠금이 필요한 파일에 동시 액세스합니다.

대용량 파일 액세스 - 압축/압축 해제.

동일한 파일을 처리하기 위해 서로 다른 컴퓨팅 아키텍처(EC2, ECS)를 사용합니다.