%20%EC%82%AC%EC%9A%A9.png)
저는 시퀀스 번호 0,1,...을 사용하여 고정 크기 레코드를 포함하는 대규모 파일 모음으로 쉽게 표시할 수 있는 데이터베이스를 설계하고 있습니다. 이는 파일 이름을 기본 키로, 레코드 시퀀스 번호를 정렬로 사용하여 DynamoDB에 잘 맞을 수 있습니다. 키가 있지만 EFS에서 느슨한 파일을 사용하는 것에 대해 생각하고 있습니다. 내결함성 시스템에서는 이미 복제되었으므로 복제가 필요하지 않습니다. 내 Lambda 함수에는 항상 알려진 파일의 알려진 오프셋에 있는 개별 레코드를 읽고, 쓰고, 업데이트하는 것보다 더 멋진 작업이 필요하지 않습니다. 100개의 동시에 활성화된 람다가 있을 수 있지만 일반적으로 서로 다른 파일에 액세스합니다. fcntl/lockf를 사용하여 모든 경합을 동기화할 수 있는 것 같습니다.
겉으로 보기에는 원시 파일을 사용하면 비용이 최소한 절반으로 줄어들고 성능도 더 좋아질 것 같습니다. 내가 이 일을 후회할 수 있는 이유는 무엇입니까?
답변1
몇 가지 간단한 실험을 바탕으로 이 접근 방식이 가능해졌습니다. Rust를 사용하면 약 20ms의 Lambda 런타임(반복 호출 시)에 파일을 업데이트할 수 있었습니다. fcntl 권고 잠금(F_SETLKW)을 사용하면 동일한 파일에 대해 경합하는 소수의 동시 Lambda에 아무런 문제가 없었습니다. 경합 없이 대기 시간이 최대 약 30ms까지 증가했으며 경합 중에 예상되는 대기 시간도 발생했습니다.
이들은 dynamoDB와 동일한 야구장에 있는 것 같습니다. 그러나 많은 작은 파일이 포함된 워크로드에 대해 EFS를 피하라는 권장 사항을 여러 곳에서 보았습니다. 하지만 이는 EBS와 관련이 있는 경우가 많으며 요청당 1개의 Lambda로 달성할 수 있는 간단한 동시성을 무시하는 것 같습니다.
dynamoDB로 이 성능을 능가하려면 Simple Queue Service를 사용하여 동시 Lambda 수를 제한해야 할 것 같습니다.
제가 예상하는 가장 큰 단점 중 하나는 업그레이드 가능성입니다. 파일 형식을 변경해야 하면 빠르게 지저분해집니다. 핵심 작업 흐름을 넘어서는 모든 종류의 쿼리에는 사용자 지정 구현이 필요합니다.
답변2
가능해야 할 것 같아요. 이 블로그 게시물에는 유용한 정보가 있습니다…