AWS 기반 프로젝트

현대적 웹 애플리케이션 구축

웹 애플리케이션 배포, 데이터베이스 연결 및 사용자 행동 분석

모듈 5: 사용자 동작 캡처

이 모듈에서는 AWS Lambda 및 기타 서버리스 서비스를 사용하여 사용자 동작을 캡처합니다.

개요

이제 Mythical Mysfits 사이트가 작동 및 실행됩니다. 사용자가 웹 사이트 및 Mysfit과 상호 작용하는 방식에 대해 자세히 알아볼 수 있는 방법을 만들어 보겠습니다. mysfit을 도입하거나 선호하면 백엔드에서 데이터가 변경되는 웹 사이트에서 가져온 사용자 작업을 매우 편리하게 분석할 수 있습니다.

그러나 mysfit을 선호하거나 도입하기 전에 사용자가 웹 사이트에서 수행하는 작업을 파악하면 향후에 향상된 사용자 경험을 설계하는 데 도움이 되며 이를 통해 mysfit의 도입 속도가 훨씬 빨라질 수 있습니다. 이러한 통찰력을 손쉽게 수집할 수 있도록 사용자가 mysfit 프로파일을 클릭할 때마다 소규모 요청을 생성된 새 마이크로서비스 API로 제출할 수 있는 기능을 웹 사이트 프런트엔드에 구현해 보겠습니다. 이러한 레코드는 서버리스 코드 함수에 의해 실시간으로 처리되며 향후 분석을 위해 집계 및 저장됩니다.

최신 애플리케이션 설계 원칙에서는 집중도가 높고 분리된 모듈형 서비스가 선호됩니다. 그러므로 지금까지 사용해 온 기존 Mysfits 서비스에 추가적인 메서드 및 기능을 추가하는 것이 아니라, Mysfits 웹 사이트로부터 사용자 클릭 이벤트를 수신하기 위한 용도의 분리된 새로운 서비스를 구축하도록 하겠습니다. 이러한 전체 스택은 제공되는 CloudFormation 템플릿을 사용하여 표현되었습니다.

아키텍처 다이어그램

사용자 동작 캡처

이 템플릿에서 AWS Lambda를 선택한 이유가 무엇입니까?

Lambda는 데이터 변경 사항, 시스템 상태 변화 또는 사용자 수행 작업에 실시간으로 대응해야 하는 데이터 중심 애플리케이션에 매우 적합합니다. 이러한 애플리케이션은 일반적으로 데이터 스토어에 연결되어 데이터에 액세스하고 이를 분석함으로써 배치 처리, 스트림 분석 및 기계 학습 추론을 수행합니다. Lambda는 현재 총 17개의 이벤트 소스와 함께 데이터 스토어(예: Kinesis Data Streams 및 Data Firehose, S3, CloudWatch Events, CloudWatch Logs 및 DynamoDB)와 통합되므로 이러한 애플리케이션에 매우 적합합니다.   

이 모듈에서 사용되는 서버리스 리소스

AWS Kinesis Firehose 전송 스트림: Kinesis Firehose는 매우 가용성이 높은 관리형 실시간 스트리밍 서비스로, 데이터 레코드를 수락하고 이러한 레코드를 AWS 내의 여러 가능한 스토리지 대상(예: Amazon S3 버킷 또는 Amazon Redshift 데이터 웨어하우스 클러스터)으로 자동으로 수집합니다. 또한, Kinesis Firehose를 사용하면 스트림에서 수신된 모든 레코드가 AWS Lambda로 생성된 서버리스 함수로 자동 전송될 수 있습니다. 즉, 작성한 코드가 레코드의 추가적인 처리 또는 변환을 수행한 후 이를 구성된 대상에 수집 및 저장할 수 있습니다.

Amazon S3 버킷: 새 버킷은 처리된 모든 클릭 이벤트 레코드가 파일로 수집되고 객체로 저장되는 S3에서 생성됩니다.

AWS Lambda 함수: AWS Lambda를 사용하면 개발자는 로직에 필요하고 코드를 배포 및 호출하고 매우 신뢰성 있게 하며 인프라를 관리할 필요 없이 확장하기 위해 필요한 코드 함수만을 작성하면 됩니다. 여기에서 서버리스 코드 함수는 AWS SAM을 사용하여 정의됩니다. 그리고 Python으로 작성된 AWS Lambda로 배포되며 전송 스트림에 의해 수신되는 클릭 레코드를 처리 및 보강합니다. 작성되는 코드는 매우 간단하며 이 코드의 보강은 후속 처리를 수행하지 않고 웹 사이트 프런트엔드에서 수행할 수 있습니다. 함수는 Mysfit에서의 클릭에 대한 추가적인 속성을 검색하여 클릭 레코드를 보다 의미 있게 해줍니다(웹 사이트에서 이미 검색된 데이터). 그러나 이 워크숍의 목적에 따라 코드는 서버리스 코드 함수 등을 포함하여 레코드를 저장하기 전 실시간으로 추가 처리 또는 변환을 수행하기 위해 필요한 아키텍처 상의 가능성을 보여주기 위한 것입니다. Lambda 함수가 생성되고 Kinesis Firehose 전송 스트림이 이 함수에 대한 이벤트 소스로 구성되면, 전송 스트림은 클릭 레코드를 생성된 코드 함수에 대한 이벤트로 자동 전송하고 코드에서 반환되는 응답을 수신하며 구성된 Amazon S3 버킷으로 업데이트된 레코드를 전송합니다.

Amazon API Gateway REST API: AWS Kinesis Firehose는 기타 AWS 서비스와 유사하게 서비스 API를 제공하며 이 경우에는 PutRecord 작업을 사용하여 사용자 클릭 이벤트 레코드를 전송 스트림에 추가합니다. 그러나 웹 사이트 프런트엔드를 Kinesis Firehose PutRecord API에 직접 통합할 필요는 없습니다. 직접 통합하려면 PutRecord API에 대한 해당 API 요청을 인증하는 프런트엔드 코드 내에서 AWS 자격 증명을 관리해야 하며 이로 인해 사용자가 사용 중인 다이렉트 AWS API에 노출됩니다(이를 통해 실제 사용자 동작 이해라는 목표에 유익하지 않거나 형식이 잘못된 레코드를 전송 스트림에 추가하는 악의적인 사이트 방문자가 나타날 수 있음). 그러므로 그 대신 Amazon API Gateway를 사용하여 Kinesis Firehose의 PutRecord API에 대한 AWS Service Proxy를 생성하도록 하겠습니다. 이를 통해 요청을 처리하기 위해 프런트엔드에서 AWS 자격 증명을 관리할 필요가 없는 자체적인 퍼블릭 RESTful 엔드포인트를 구축할 수 있습니다. 또한, API 게이트웨이에서 요청 매핑 템플릿도 사용하며, 이를 통해 요청을 예상되는 구조로 제한하고 그러한 올바른 형식의 요청을 Kinesis Firehose PutRecord API에 필요한 구조로 변환하는 자체적인 요청 페이로드 구조를 정의할 수 있습니다.

IAM 역할: Kinesis Firehose에서는 수신된 레코드를 생성된 Lambda 함수로의 이벤트뿐만 아니라 처리된 이벤트를 대상 S3 버킷으로 전송하는 것을 허용하는 서비스 역할이 필요합니다. 또한, Amazon API Gateway API에서는 API가 수신된 각 API 요청에 대한 PutRecord API를 Kinesis Firehose 내에서 호출하는 것을 허용하는 새로운 역할도 필요합니다.

구현 지침

  • A: 새 CodeCommit 리포지토리 생성

    CloudFormation을 사용하여 배포할 새로운 이 스택에는 인프라 환경 리소스뿐만 아니라 AWS Lambda가 스트리밍 이벤트를 처리하기 위해 실행하는 애플리케이션 코드도 포함되어 있습니다. 단일 배포에 인프라 구축 및 코드를 함께 결합하기 위해 AWS Cloud9 IDE에 미리 설치되어 제공되는 다른 AWS 도구인 AWS SAM CLI를 사용하도록 하겠습니다. AWS Lambda 함수를 위한 코드는 .zip 패키지 형식으로 함수 코드를 Amazon S3 버킷에 업로드하여 서비스로 전달됩니다.

    SAM CLI는 이러한 프로세스를 자동화합니다. SAM CLI를 사용하면, Lambda 함수를 위한 모든 코드가 저장되는 파일 시스템에서 로컬로 참조되는 CloudFormation 템플릿을 생성할 수 있습니다. 그러면 SAM CLI가 이 템플릿을 .zip 파일 형식의 패키지로 만들고 구성된 Amazon S3 버킷으로 업로드한 후 생성된 .zip 패키지가 AWS Lambda로 배포하기 위해 업로드된 S3의 위치를 나타내는 새 CloudFormation 템플릿을 생성합니다. 그러면 SAM CLI에서 생성된 해당 CloudFormation 템플릿을 AWS로 배포한 후 SAM CLI에서 업로드된 코드 패키지를 사용하는 Lambda 함수와 함께 환경이 생성된 것을 확인할 수 있습니다.

    우선, 스트리밍 서비스 코드가 위치할 새 CodeCommit 리포지토리를 생성하도록 하겠습니다.

    aws codecommit create-repository --repository-name MythicalMysfitsStreamingService-Repository

    이 명령에 대한 응답에서 "cloneUrlHttp"에 대한 값을 복사합니다. 이 값의 형식은 https://git-codecommit.REPLACE_ME_REGION.amazonaws.com/v1/repos/MythicalMysfitsStreamingService-Repository여야 합니다.

    다음으로 해당 새 리포지토리와 비어 있는 리포지토리를 IDE로 복제해 보겠습니다.

    cd ~/environment/
    git clone {insert the copied cloneValueUrl from above}
    B: 스트리밍 서비스 코드 베이스 복사

    이제 작업 디렉터리를 새 리포지토리로 이동하겠습니다.

    cd ~/environment/MythicalMysfitsStreamingService-Repository/

    그리고 모듈 5 애플리케이션 구성 요소를 이 새 리포지토리로 직접 복사합니다.

    cp -r ~/environment/aws-modern-application-workshop/module-5/app/streaming/* .

    이제 이 모듈에 대한 CloudFormation 템플릿도 복사합니다.

    cp ~/environment/aws-modern-application-workshop/module-5/cfn/* .
  • A: PIP를 사용하여 Lambda 함수 종속성 설치

    이제 제공된 모든 아티팩트를 사용하여 리포지토리 디렉터리가 설정되었습니다.

    전체 스택을 생성하기 위한 CFN 템플릿.

    Lambda 함수를 위한 코드가 포함된 Python 스크립트: streamProcessor.py

    이 방식은 AWS 고객이 CloudFormation 템플릿을 애플리케이션 코드와 함께 리포지토리에 저장하기 위해 일반적으로 사용하는 방법입니다. 이러한 방법으로 애플리케이션 및 환경에 대한 모든 변경 사항을 한 곳에서 모두 추적할 수 있습니다.

    그러나 streamProcessor.py 파일 내의 코드를 살펴보면 이전에 우리가 생성한 Mythical Mysfits 서비스에 API를 요청하는 Python 패키지 요청이 사용되는 것을 알 수 있습니다. 다른 AWS 고객은 다양한 라이브러리의 다른 버전을 사용할 수 있으므로 외부 라이브러리는 AWS Lambda 실행 시간 환경에 자동으로 포함되지 않습니다.

    그러므로 Lambda 코드 함수와 함께 모든 라이브러리 종속성을 패키지로 묶은 후 Lambda 서비스로 업로드해야 합니다. 이를 위해 Python 패키지 관리자 PIP를 사용하도록 하겠습니다. Cloud9 터미널에서 다음 명령을 실행하여 함수 코드와 함께 요청 패키지 및 종속성을 로컬에 설치합니다.

    pip install requests -t .

    이 명령이 완료되면 리포지토리 내에 여러 추가 python 패키지 폴더가 저장된 것을 확인할 수 있습니다.

    B: Lambda 함수 코드 업데이트

    다음으로 Lambda 함수 코드의 배포 준비가 완료되기 전에 코드를 하나 변경해야 합니다. streamProcessor.py 파일 내의 라인 1개를 Mysfits 서비스 API에 대한 ApiEndpoint로 바꾸어야 하며, 이는 모듈 4에서 생성하고 웹 사이트 프런트엔드에서 사용되는 동일한 서비스 ApiEndpoint입니다.

    replace-api-endpoint

    이 서비스는 DynamoDB에서 MysfitsTable와의 통합을 수행하므로, DynamoDB 테이블과 직접 통합되는 Lambda 함수를 작성하는 경우에도 이는 첫 번째 마이크로서비스의 목적을 벗어나며 별도의 여러 코드 베이스가 동일한 테이블과 통합되게 됩니다. 대신, 기존 서비스를 통해 해당 테이블을 통합하면 훨씬 더 분리된 모듈형 애플리케이션 아키텍처를 달성할 수 있습니다.

    C: 코드를 CodeCommit로 푸시

    이제 변경 사항을 새 리포지토리로 커밋하여 CodeCommit에 저장하도록 하겠습니다.

    git add .
    git commit -m "New stream processing service."
    git push
  • A: Lambda 함수 코드 패키지를 위한 S3 버킷 생성

    Python 파일에서 라인을 변경하고 코드를 커밋함으로써 AWS SAM CLI를 사용하여 모든 함수 코드를 패키지로 묶고 S3로 업로드하며 배포 가능 CloudFormation 템플릿을 생성하여 스트리밍 스택을 생성할 수 있습니다.

    우선, AWS CLI를 사용하여 Lambda 함수 코드 패키지를 업로드할 새 S3 버킷을 생성해 보겠습니다. S3 버킷의 이름은 모든 AWS 고객 전체에서 고유해야 하므로 이 버킷 이름의 끝을 고유한 문자열로 바꿉니다.

    B: SAM CLI를 사용하여 Lambda를 위한 코드 패키지화

    버킷을 생성함으로써 SAM CLI를 사용하여 코드를 패키지로 묶고 업로드하며 CloudFormation 템플릿으로 변환할 준비가 되었습니다. 마지막 명령 파라미터를 위에서 생성한 버킷 이름으로 바꾸었는지 확인합니다(이 명령은 터미널이 리포지토리 작업 디렉터리에 위치하고 있다고 가정함).

    sam package --template-file ./real-time-streaming.yml --output-template-file ./transformed-streaming.yml --s3-bucket replace-with-your-bucket-name

    이 작업에 성공하면 ./MythicalMysfitsStreamingService-Repository/ 디렉터리에 transformed-streaming.yml 파일이 새로 생성된 것을 확인할 수 있습니다. 이 파일의 내용을 살펴보면 서버리스 Lambda 함수의 CodeUri 파라미터가 객체 위치(SAM CLI가 패키지 코드를 업데이트한 위치)로 업데이트된 것을 확인할 수 있습니다.

    C: AWS CloudFormation을 사용하여 스택 배포

    SAM CLI 명령에 의한 반환 값은 새로운 전체 스택을 생성하기 위해 실행되어야 하는 CloudFormation 명령입니다. 그러나 스택은 IAM 리소스를 생성하므로 명령에 추가 파라미터 1개를 추가해야 합니다. 다음 명령을 실행하여 스트리밍 스택을 배포합니다.

    aws cloudformation deploy --template-file /home/ec2-user/environment/MythicalMysfitsStreamingService-Repository/cfn/transformed-streaming.yml --stack-name MythicalMysfitsStreamingStack --capabilities CAPABILITY_IAM

    이 스택의 생성이 완료되면, 전체 실시간 처리 마이크로서비스가 생성됩니다.

    Lambda 함수의 코드만 변경하고 CloudFormation 스택의 나머지는 변경하지 않는 향후 시나리오에서는 위와 동일한 AWS SAM CLI 및 CloudFormation 명령을 반복하면 됩니다. 그 결과, 인프라 환경은 변하지 않지만 Lambda 함수에 대한 코드를 배포할 수 있습니다.

  • A: 웹 사이트 콘텐츠 업데이트

    스트리밍 스택이 작동 및 실행되므로, 이제 우리는 사용자가 mysfit 프로파일을 클릭할 때마다 이벤트를 서비스로 전송하는 JavaScript가 포함된 새로운 버전의 Mythical Mysfits 프런트엔드를 게시해야 합니다.

    새로운 index.html 파일은 ~/environment/aws-modern-application-workshop/module-5/web/index.html에 있습니다.

    이 파일에는 업데이트되어야 하는 모듈 4와 동일한 자리 표시자 및 방금 생성한 새 스트림 처리 서비스 엔드포인트를 위한 추가적인 자리 표시자가 포함되어 있습니다. 이전의 여러 값과 관련해서는 모듈 4에서 업데이트한 이전 index.html 파일을 참조하십시오.

    새 스트리밍 스택에 다음 명령을 수행하여 스트림 처리 서비스를 위한 새 API 게이트웨이 엔드포인트를 검색합니다.

    aws cloudformation describe-stacks --stack-name MythicalMysfitsStreamingStack
    B: 새 사이트 버전을 S3로 푸시

    최종 값을 streamingApiEndpoint에 대한 index.html로 바꾸면 최종 Mythical Mysfits 홈페이지 업데이트를 게시할 준비가 완료됩니다.

    aws s3 cp ~/environment/aws-modern-application-workshop/module-5/web/index.html s3://YOUR-S3-BUCKET/

    브라우저에서 Mythical Mysfits 웹 사이트를 한 번 더 새로 고치면 사용자가 mysfits 프로파일을 클릭할 때마다 사이트가 기록 및 게시합니다.

    처리된 레코드를 확인할 수 있도록 해당 레코드는 MythicalMysfitsStreamingStack의 일부로 생성된 대상 S3 버킷에 수신됩니다.

    이제 최신 애플리케이션 아키텍처가 완료되었습니다. 이제 AWS 콘솔 및 생성한 모든 여러 서비스를 살펴보고 Mythical Mysfits를 시작해 보십시오!

  • 이 워크숍 도중에 생성한 모든 리소스를 삭제하여 더 이상 계속해서 리소스 요금이 청구되지 않도록 하십시오. AWS 콘솔을 사용하여 생성한 리소스를 살펴보고 준비가 되면 삭제하는 것이 좋습니다.

    AWS CloudFormation을 사용하여 리소스를 프로비저닝한 두 사례에서는 단순히 각 스택에서 다음 CLI 명령을 실행하여 해당 리소스를 제거할 수 있습니다.

    aws cloudformation delete-stack --stack-name STACK-NAME-HERE

    생성한 모든 리소스를 제거하려면 다음 AWS 콘솔로 이동하십시오. 여기에는 Mythical Mysfits 워크숍 중에 생성한 리소스가 포함되어 있습니다.

결론

이 경험은 개발자가 AWS 상에서 최신 애플리케이션 아키텍처를 설계하고 구축하는 것이 어떤 것인지에 대한 맛보기를 제공하기 위한 것입니다. AWS 개발자는 AWS CLI를 사용하여 프로그래밍 방식으로 리소스를 프로비저닝하고 AWS CloudFormation을 통해 인프라 정의를 재활용하며 코드 서비스의 AWS 개발자 도구 제품군을 사용하여 코드 변경 내용을 자동으로 빌드 및 배포하고 사용자가 서버를 프로비저닝하거나 관리할 필요가 전혀 없는 다양한 컴퓨팅 및 애플리케이션 서비스 기능을 활용할 수 있습니다!

앞에서 생성한 Mythical Mysfits 웹 사이트의 내부 작동에 대해 자세히 알아보는 다음 단계에서는 제공되는 CloudFormation 템플릿과 이 템플릿에 선언된 리소스에 대해 심층적으로 살펴보도록 하겠습니다.

즐거운 AWS 최신 애플리케이션 워크숍이 되셨기를 기원합니다! 이 자습서는 GitHub에서도 호스팅되므로 추천 사항이 있으면 해당 사항을 제출할 수 있습니다. 코드를 향상하기 위해 공동 작업을 원하는 경우에는 GitHub 풀 요청을 초기화해주십시오.

Developing on AWS에 대한 자세한 정보는 AWS 개발자 센터에서 확인할 수 있습니다.

축하합니다!

최신 웹 애플리케이션을 AWS에 구축하셨습니다.
친구와 이를 공유하고 당사에 피드백을 보내 주십시오.

Twilight Glitter가 귀하의 작업 결과에 감동을 받았습니다.