Count visitors with Lambda

이번 장에선 AWS 리소스를 활용하여 방문자 수 카운트 기능을 구현하고 이를 배포 중인 정적 웹 이력서 페이지에 추가하겠습니다.

다음과 같은 기술이 사용되며 이러한 기술들이 상호작용하여 방문자 수 카운트 기능을 구현합니다.

사용 기술

AWS DynamoDB: 방문자 수 정보를 저장
AWS Lambda: 유저가 이력서에 접속하면 방문자 수 정보를 갱신함
AWS API Gateway: 구현한 기능의 Trigger 역할을 함
Javascript: 이력서에 구현된 기능을 불러옴

AWS Dynamo DB

모든 규모에서 10밀리초 미만의 성능을 제공하는 빠르고 유연한 NoSQL 데이터베이스 서비스

Dynamo DB는 AWS에서 제공하는 NoSQL 데이터베이스 서비스입니다. AWS 이외에도 매우 다양한 클라우드 데이터베이스 서비스를 제공하므로 반드시 Dynamo DB를 사용할 필요는 없습니다. 그러나 방문자 수 카운트 기능은 비교적 요구 사항이 단순하므로 별도의 스키마 정의가 필요없는 Dynamo DB를 활용하여 도전 과제를 진행하겠습니다.

Table(테이블)

Dynamo DB는 테이블에 데이터를 저장합니다. 데이터는 JSON 형태로 저장되므로 Dynamo DB의 응답값을 다룰 떈 이 점을 유념해야합니다.

Table 생성하기

Dynamo DB를 활용하기 위해선 새로운 테이블을 생성하고 키-값을 설정해야합니다. Dynamo DB 콘솔로 이동하여 리전 설정을 하고 Create table을 통해 테이블을 생성합니다. 다음은 테이블 이름을 설정해야합니다. 테이블 이름은 본인이 구분짓기 쉬운 이름으로 설정하면 됩니다. 본 예시에선 resume_visitor로 설정하겠습니다.

다음은 Partition key를 설정합니다. 테이블을 생성할 땐 기본키를 지정해야하며, 기본키는 테이블 각 레코드를 고유하게 식별하는 기준 역할을 합니다. Partition key는 Dynamo DB가 지원하는 기본키 중 하나이며, 본 예시에선 String 형태의 stats라는 기본키를 설정하였습니다.

이후 별다른 추가 설정없이 생성해도되지만 이력서 페이지의 조횟수는 그리 높지 않을 것으로 예상되므로 과금 형태를 변경하여 비용을 절약할 수 있습니다. 이를 위해선 Table settings에서 Customize settings을 선택하고 Read/write capacity settings에서 On-demand를 선택하여 발생하는 비용을 줄일 수 있습니다. 이후 Create table을 눌러 테이블을 생성합니다.

테이블을 생성하고나면 테이블에 들어갈 요소들을 추가해야합니다. 이러한 요소를 Item이라 부릅니다. 테이블 목록에서 테이블 이름을 눌러 이동합니다.

이후 화면에서 Actions -> Create item순으로 이동하여 아이템을 생성합니다. 다음 화면에서 테이블 생성시 설정한 Partition key인 stats 보이고 이후 값을 추가할 수 있도록 화면이 구성되어있습니다. 이력서 방문자를 기록해야하므로 다음 예시처럼 값을 넣어 아이템을 생성합니다.

stats의 Value인 views는 추가할 항목을 의미합니다. Partition key생성시 String으로 설정하였으므로 이는 바꿀 수 없습니다. 이후 Attribute name 항목으로 count를 추가하고 해당 타입은 Number로 설정합니다. count의 value는 0을 넣습니다. 이곳에 들어갈 숫자가 조횟수를 의미합니다. 설정을 마치면 Create item을 눌러 아이템을 생성합니다.

AWS Lambda

서버 또는 클러스터에 대한 걱정 없이 코드 실행

AWS Lambda는 이벤트 중심의 서버리스(Serverless) 컴퓨팅 서비스입니다. 서버리스는 말 그대로 서버가 없이 실행됨을 의미하지만 실제로 서버가 없이도 작동하는 것은 아닙니다. 다만 개발자 입장에서는 서버에 대한 신경을 쓰지 않고 온전히 개발에만 집중할 수 있다는 의미에서 서버리스라고 부릅니다.

본 도전 과제는 이러한 Lambda를 사용하여 Dynamo DB에 저장된 방문자 수를 갱신합니다. 사용자가 웹 이력서에 접근하면 API Gateway에서 생성한 엔드포인트가 작동하고 이를 트리거로하여 Lambda function이 실행됩니다. 실행된 Lambda는 Dynamo DB에서 조횟수를 갱신하고 이를 출력합니다.

Lambda 생성하기

Lambda를 생성하기위해 Lambda 콘솔로 이동하고 Create function을 눌러 생성합니다. 다음 화면에서 Function name과 Runtime을 설정합니다. Runtime은 본인이 자신있는 언어라면 어떠한 언어를 선택해도 문제가 없습니다. 본 예시에선 Python 3.9를 선택하겠습니다.

다음으로 권한을 설정해야합니다. 해당 Lambda function은 Dynamo DB를 다루므로 이와 관련된 역할(Role)을 부여해야하며 우선은 기본 역할을 부여한 뒤, 해당 역할에 권한을 추가하는 방식으로 진행하겠습니다. 이를 위해 같은 페이지의 Change default execution role의 Execution role에서 Create a new role with basic Lambda permissions 통해 기본 권한을 가진 역할을 부여합니다. 참고로 기본 역할은 로그와 관련된 권한을 가지고 있습니다.

이제 역할을 수정합니다. 다음 화면에서 Configuration의 Execution role에서 Edit버튼을 누릅니다. 하단의 Existing role을 보면 View the <Lambda 함수 이름> role on the IAM console. 링크가 있습니다. 이를 통해 바로 IAM 콘솔로 이동합니다.

다음 화면의 Permissions policies의 Add permissions버튼을 누르면 Create inline policy를 통해 정책을 추가합니다. 정책은 JSON 포맷으로 추가할 수 있으므로 JSON 포맷을 눌러 다음과 같이 추가합니다

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem"
      ],
      "Resource": "arn:aws:dynamodb:<리전>:<Account_ID>:table/<DynamoDB Table 명>"
    }
  ]
}

위 정책을 사용할 Lambda는 매우 단순한 역할을 수행하므로 Actions에 최소한의 권한을 부여했습니다. 하단의 Resource에선 해당 정책이 작동할 대상 리소스를 선택해야합니다. 자신에 맞게 수정하여 정책을 생성합니다. 참고로 Account_ID는 화면 상단의 IAM_user@계정명 형태의 버튼을 누르면 바로 출력되며 여기서 -를 제외한 12개의 연속된 숫자입니다.

이후 Review policy를 눌러 다음 화면에서 해당 정책의 이름을 설정하고 Create policy를 눌러 생성하고 새롭게 바뀐 역할을 Lambda function을 적용하기 위해 역할 목록을 갱신한 뒤 적용할 역할을 선택하고 save를 눌러 적용합니다.

AWS API Gateway

모든 규모의 API를 생성, 유지 관리 및 보호

API Gateway는 AWS에서 API의 생성, 배포, 관리, 모니터링 역할을 수행하는 리소스입니다. RESTful API와 WebSocket API를 지원하며, 본 예시에선 API Gateway에서 Lambda function의 트리거 역할을 하는 RESTful API를 생성해 사용할 예정입니다. Lambda 자체는 엔드포인트가 존재하지 않아 이러한 외부 트리거 요소가 필요합니다.

트리거 생성 과정

트리거를 생성하기 위해 Lambda function 함수 페이지의 Add trigger 버튼을 누릅니다. 트리거로 사용 선택 가능한 요소는 상당히 많지만 본 예시에선 API gateway를 사용하겠습니다. 또한 REST API를 사용할 예정이므로 하단에서 REST API를 선택합니다.

Security 항목은 불특정 다수가 원활하게 접근할 수 있어야 하므로 별다른 설정을 하지않는 Open을 선택합니다.

API Gateway에서 관리하는 API는 생성 혹은 수정 이후 갱신된 API를 배포해야 사용자들은 업데이트 된 API를 사용할 수 있습니다. 가장 하단의 Deployment stage 항목은 이러한 배포 상태를 부르는 이름을 설정합니다. 본 예시에선 prod로 설정하겠습니다.

트리거를 생성하면 다음과 같은 화면이 출력됩니다. 하단의 API endpoint가 엔드포인트로 사용될 주소입니다.

아직은 Lambda function 내용을 수정하지 않았기 때문에 주소로 이동하면 단순히 "Hello from Lambda!" 문구가 출력됩니다. 이는 Lambda function 생성 시 자동으로 입력된 기본 예시 코드가 실행된 것입니다. 해당 코드를 수정하여 Dynamo DB와 상호작용 하도록 만들겠습니다.

같은 페이지에서 Code 탭으로 이동하면 코드를 수정할 수 있습니다. 본 예시는 Lambda function 생성 시 런타임으로 Python 3.9를 선택했으므로 파이썬 코드로 작성하겠습니다. 여러 구현 방법이 있겠지만 본 예시에선 다음과 같이 코드를 작성하였습니다.

import boto3

dynamodb = boto3.resource('dynamodb', 'us-east-1')
table = dynamodb.Table('resume_visitor')


def update_counter(table_info):
    response = table_info.get_item(
        Key={
            'stats': 'views'
        }
    )

    new_count = response['Item']['count'] + 1

    table_info.put_item(
        Item={
            'stats': 'views',
            'count': new_count
        }
    )

    return new_count


def lambda_handler(event, context):
    return update_counter(table)

Lambda 코드를 작성하면 Deploy 버튼을 눌러 배포를 수행합니다. Lambda를 배포하더라도 아직 메소드가 없어 정상 실행이 되지 않습니다. 메소드를 추가하려면 API Gateway 옆의 API 이름을 눌러 API 설정 페이지로 이동합니다.

다음 화면에서 Actions -> Create Method 순으로 이동하여 GET 메소드를 생성합니다. 이후 우측의 Lambda Function 란에 메소드를 생성할 Lambda 함수 이름을 작성합니다.

GET 메소드가 생성된 상태에서 API 배포를 수행합니다. API 배포는 Actions의 Deploy API에서 할 수 있습니다.

이후 다시 엔드포인트 URL에 접속을 시도하면 여전히 오류가 발생하는 것을 확인할 수 있습니다. 정확한 이유는 모르지만 Lambda function의 변경 내용이 배포 후 갱신되기 까지는 약간의 시간이 걸리는 것으로 생각합니다. 단순히 배포까지 걸리는 시간 때문에 발생하는 오류인지, 아니면 코드 및 설정 등이 잘못됐는지는 메소드를 테스트 해보면 구분할 수 있습니다. 테스트 할 때 정상 실행되면 코드 및 설정이 잘못된 것은 아닙니다. 이 경우엔 배포까지 조금 더 기다려야합니다. 메소드 테스트는 아래와 같은 화면에서 TEST를 누르면 실행할 수 있습니다.

Javascript

생성한 엔드포인트를 웹 이력서에서 사용하기위해 자바스크립트 코드를 작성하겠습니다. 또한 HTML 코드에서 자바스크립트를 불러오도록 약간 수정이 필요합니다. 본 예시에서 사용하는 자바스크립트 파일명은 view_count.js, HTML 파일명은 index.html입니다.

먼저 자바스크립트 코드는 다음과 같습니다.

let url = new URL("<API Gateway 엔드포인트>");

async function updateCount(url) {
    fetch(url)
        .then(async (response) => {
            let data = await response.json()
            if (response.status === 200) {
                document.getElementById("views").innerHTML = data.body
            } else {
                console.log("Something went wrong. HTTP response status not 200");
            }
        })
        .catch((err) => {
            console.log(err);
        })
}

(async () => {
    await updateCount(url);
})();

GET 메소드를 활성화하면 JSON 형태로 응답이 출력되므로 이를 다룰 수 있도록 코드를 작성해야합니다. 이를 위해 response.json을 사용하고, 실제 조회수 부분은 body에 출력되므로 해당 값을 HTML의 views로 넘깁니다.

HTML 코드에선 view_count.js에서 받은 views를 출력합니다. 원하는 위치에 다음과 같은 코드를 추가합니다.


<div style="text-align:center" type="text">views: <span id="views"></span></div>

그리고 HTML의 head 영역에 다음과 같은 코드를 추가하였습니다. 해당 코드는 자바스크립트 코드가 저장된 위치를 지정합니다.


<head>
    <script src="./view_count.js" type="text/javascript"></script>
</head>

변경된 내용이 적용된 HTML, 자바스크립트 파일을 S3 버킷에 업로드한 뒤 웹 이력에 접근해봅니다. 이력서는 정상 출력되지만, 조회수 부분이 잘 출력되지 않는 것을 확인할 수 있습니다. 개발자 도구를 살펴보면 다음과 같은 오류가 발생하는 것을 확인할 수 있습니다.

이 중 눈여겨봐야 할 부분은 'CORS'입니다. CORS(Cross-Origin Resource Sharing)는 API Gateway에서 메소드 생성 시에도 관련된 설정이 있었으며, S3 버킷 설정에서도 있었습니다. 브라우저는 보안상의 이유로 같은 서버로부터 수행된 작업이 아니라면 이를 사용자에게 전달하지 않는 SOP(Same-Origin Policy)가 적용되어있으며, 이를 우회하기 위해선 외부 서버에서 수행된 작업에서 CORS 설정이 필요합니다.

본 예시에서 제한되고 있는 상황은 resume-en.yibyeongyong.com의 자바스크립트 코드가 fetch를 사용해 API Gateway 엔드포인트를 불렀을 때, Dynamo DB의 조회수 데이터가 사용자에게 전달되는 것을 제한하고 있는 상황입니다. 그 결과 사용자가 이력서 페이지에 접근하면 Dynamo DB의 조회수 값은 계속 상승하지만, 이 정보는 사용자에게 출력되지 않습니다. CORS에 대한 상세한 설명은 MDN Web Docs와 AWS Documentation에서 다루고있습니다.

정상적으로 조회수가 출력되려면 Lambda function 코드를 수정하고 API Gateway의 메소드 배포 과정에서 CORS를 허용하는 작업이 필요합니다.

Lambda function 코드의 lambda_handler 함수를 다음처럼 수정하고 배포합니다.

def lambda_handler(event, context):
    new_count = update_counter(table)

    return {
        'statusCode': 200,
        'headers': {
            'Access-Control-Allow-Origin': '<이력서 URL>'
        },
        'body': new_count
    }

기존 Lambda function에서 위 코드를 추가함으로써 응답 헤더에 Access-Control-Allow-Origin 항목을 이력서 주소를 담아 전송합니다. 브라우저는 이를 확인하고 외부 서버에서 수행된 작업임에도 해당 작업을 사용자에게 전달합니다. 다만 모든 주소는 https://를 포함하여 작성해야만 정상적으로 CORS가 적용됩니다.

마찬가지로 메소드 배포 과정에서 Actions -> Enable CORS를 통해 CORS를 허용합니다. Access-Control-Allow-Origin 부분은 Lambda function 코드처럼 이력서 URL을 입력합니다. 마찬가지로 https://를 포함하여 작성합니다. CORS를 허용하면 OPTIONS 메소드가 추가된 것을 확인할 수 있습니다. 이제 변경 사항이 적용되도록 API를 배포합니다.

이후 더 이상 오류가 발생하지 않고 조회수가 정상 출력되는 것을 확인할 수 있습니다

맺음말

지금까지 AWS Dynamo DB, Lambda, API Gateway 그리고 Javascript를 활용하여 이력서에 넣을 조회수 카운트 기능을 구현하였습니다. 개인적으론, 처음 이 도전 과제를 시작할 땐 매우 간단한 기능이니 금방 끝낼 수 있을 거로 생각했으나, 모든 부분을 AWS 리소스를 활용하여 구현하는 것이 생각보다 시간이 많이 소요되고, 오류도 자주 발생해 많은 어려움을 느꼈던 도전 과제였습니다.

다음 장에선 AWS CloudFormation과 SAM을 활용하여 콘솔을 거치지않고 코드만으로 AWS 리소스를 배포하는 방법을 알아보겠습니다.

생각해볼 점

API Gateway의 메소드 생성 부분에서 처음엔 메소드가 없으면 정상작동하지 않았지만 GET 메소드를 한번 생성한 후 다시 삭제하더라도 body부분은 정상적으로 리턴하는 것을 확인할 수 있습니다. 이러한 현상이 발생하는 이유는 무엇일까요?
Lambda function의 호출 횟수에 제한이 없기 때문에 악의적인 사용자에 의해 조회수 정보가 비정상적으로 상승할 수 있으며 비용 또한 과도하게 발생할 수 있습니다. 이러한 문제를 해결할 수 있는 방법은 무엇이 있을까요?

PreviousSecure with SSL NextAWS

Last updated 2 years ago