핫 맵 도구를 만들 때 사용되는 AWS 어레이(S3, Lambda, API Gateway, AppFlow)

디프의 광고 달력 15일째 보도입니다.
어제는 PHP에 관한 기사였는데 PHP를 사용한 업무 경험은 거의 없지만 흥미를 느낍니다.
오늘은 UI/UX 개선을 담당합니다@maaaaaya9
최근 웹 사이트를 개선하기 위해 핫맵 도구를 만들었다.그 인프라에서 AWS를 사용했지만 AWS를 처음 접했기 때문에 행동이 급해서 그 견해를 정리했다.
같은 일이 생겨 괴로워하는 사람 등에게 도움이 된다면 좋겠다.
(참고: 이 문서는 모범 사례가 아니며 참고용)
　

문자

전제)총체적 구조
1. S3에서 객체가 업데이트되지 않은 문제
2. S3+Lambda에서 발생하는 귀속 무한 순환
3. Lambda+API Gateway 협업이 원활하지 않은 문제
4. AppFlow + Google Analytics 협업이 원활하지 않은 문제

전제) 전체 구조

Google Tag Manager로 사용자의 열람 시간을 측정하고 Google Analytics에 지표 데이터를 저장합니다.AppFlow를 사용하여 매일 데이터를 S3로 출력하고, Lambda 통계 데이터를 사용하여 결과를 다른 S3로 출력합니다.세분화된 열영사 결과를 보려면 Chrome을 통해 매개 변수를 확장하고 Api Gateway를 통해 Lambda를 실행하여 결과를 S3로 출력합니다.

① S3에서 객체가 업데이트되지 않은 문제

<이벤트 >

Lambda에서 기존 S3 객체를 업데이트(또는 추적)하려고 했지만 몇 번의 파일 내용을 실행해도 이전 상태로 유지되어 업데이트할 수 없는 상황이 발생했습니다.

<이유>

원인을 조사한 결과 S3의 덮어쓰기와 삭제는 결과 완전성을 제공했다. "새로 만든 객체는 바로 참조할 수 있지만 업데이트와 삭제는 반영되기 전에 오래된 데이터로 돌아갈 수 있다."
(참조)AWS 공식/A 아마존 S3의 데이터 완전성 모델
※ 다른 말로는 S3의 대상에 대한 캐시 관리도 발견되었는데, 키 이름이 같으면 업데이트 판정을 받지 않고 오래된 내용을 참조한다는 보도가 나왔지만 신뢰할 수 있는 정보인지는 알 수 없습니다.

<처리>

일치성 관점에서 볼 때 S3는 대상의 추적 등 업데이트 처리를 하지 않고 독특한 키 이름으로 새 대상을 만든다.(사회적으로 새 객체를 사용하는 방법을 권장함)
　

② S3+Lambda에서 발생하는 반복 무한 순환

<이벤트 >

1 문제를 해결하기 위해 Lambda가 실행될 때마다 대상을 새로 만들고 S3 (heatmap-bucket) 에 두기로 했습니다.

그러나 Lambda가 한 번만 실행되었어야 하는데 Lambda가 100번 정도 계속 실행되었고 대상도 이 횟수에 따라 생성되었습니다.

<이유>

이것은 중대한 문제가 하나 있다.S3(heatmap-bucket)의 대상을 트리거로 만든 Lambda가 존재하기 때문에
Lambda 시작 → S3 창설 대상 → S3 촉발 Lambda 또 시작 → S3 창설 대상 → S3 촉발 Lambda 또 시작 → S3 창설 대상...
문서 레지스트리에 항목을 추가합니다.
Lambda에서 S3 트리거를 설정할 때의 확인 항목에 잘 쓰여 있습니다.

내용을 이해하고 검사를 했지만 이렇게 할 줄은...
왜 무한 집행을 하지 않고 100회 정도에서 멈추었는지 말하자면, 같은 키 이름의 대상을 새로 만들었기 때문에 AWS 측에서 자동으로 기호와 수치를 키 이름으로 부여하여 대상을 독특하게 만들었고, 지속적으로 부여한 결과, 키 이름이 규정된 문자 수를 초과하여 오류가 발생했습니다.불행 중 다행이다.

<처리>

S3(heatmap-bucket)는 Lambda의 트리거이기 때문에 트리거하지 않은 다른 S3(heatmap-output)에서 대상을 만듭니다.
　

③ Lambda+API Gateway 협업이 원활하지 않은 문제

<이벤트 >

API Gateway를'Lambda 프록시 통합'으로 설정하여 만들고 싶습니다. Lambda 함수로 설정된 트리거입니다. API Gateway에서 Lambda를 호출하려고 하지만CORS가 잘못되었습니다.

<이유>

API 게이트웨이에서 "Lambda 프록시 통합"을 설정하면 기존 방법의 통합 응답에 접근 제어 Allow-Origin 헤더를 추가하려고 시도하지만 정상적으로 작동하지 않을 수 있으므로 수동으로 추가해야 합니다.
(참조)AWS 공식/REST API 리소스를 사용하는 CORS

<처리>

먼저 API 게이트웨이에서 생성된 리소스에 대해 "CORS 활성화"를 실행하고 API를 배포합니다.그리고 Lambda 함수의 응답에서 "AccessControllow-Origin"을 실행합니다.
Python은 아래와 같이 액세스 제어 Allow-Origin을 머리글에 추가합니다.

import json

def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'headers': {
            'Access-Control-Allow-Headers': 'Content-Type',
            'Access-Control-Allow-Origin': '*'
        },
        'body': json.dumps('Hello from Lambda!')
    }

　

④ AppFlow + Google Analytics 협업이 원활하지 않은 문제

AppFlow는 2020년 4월에 출시된 서비스로 코드를 쓰지 않고 외부 SaaS 응용 프로그램과 AWS 간의 데이터 협업을 자동화하는 전체 관리 서비스입니다.SaaS 애플리케이션은 Datadog, Google Analytics, Salesforce, Slack, Zendesk 등을 지원합니다.
(참조)AWS 공식/ApFlow 문서

<이벤트 >

이번에 이 AppFlow를 사용하면 구글 Analytics의 데이터를 하루에 한 번씩 S3에 출력하지만 AppFlow를 실행하면 503 오류가 자주 발생합니다.

The request failed with the Googleanalytics status Code 503: Status Code 503 Error message: The service is currently unavailable., RequestId:XXXXXXXX

<이유>

이 오류는 테스트 환경에서 발생하지 않고 생산 환경에서만 발생하지만 데이터가 대량으로 발생하거나 복잡한 요청을 대량으로 보내는 등 서버에 대한 부하가 커지면 구글 Analytics API에서 이 오류가 발생할 수 있습니다.

<처리>

이런 상황에서 요청 데이터의 대상 기간을 단축하는 방법을 생각할 수 있을 것 같지만 AppFlow의 일정 설정에서 가장 짧은 것은 하루에 한 번씩 실행하기 때문에 시간당 등보다 더 짧은 기간을 지정할 수 없다.오류가 발생하면 다시 실행하는 기능도 발견되지 않고 자동으로 실행하는 해결 방법을 찾지 못해 오류가 발생하면 수동으로 다시 실행하는 처리를 취했다.
　

마지막

AppFlow는 2020년 4월에 출시된 서비스이기 때문에 정보가 적고 예상치 못한 동작이 자주 발생하기 때문에 새로운 서비스를 사용할 때 공식적인 환경을 구상한 데이터로 잘 확인하는 것이 중요하다.또한 람다의 무한 순환 속에서 나 자신을 너무 믿지 말고 설정을 잘 확인하는 것도 중요하다는 것을 다시 한 번 느꼈다.AWS를 단단히 만지며 좋은 지식을 배웠습니다.
더 좋은 해결책을 알고 있거나 잘못이 있으면 댓글을 달아주시면 기쁩니다.
그럼 내일 행사 달력을 계속 기대해 주세요