AWS

들어가며

최근에 ‘하둡과 스파크를 활용한 실용 데이터 과학’이라는 책을 읽고 따라해 보고 있다. 이 책에서는 실습을 위해 호튼웍스(Hortonworks)의 Sandbox 이미지를 사용해 보기를 권장하고 있다. 그런데 설치 방법을 찾다 보니, 권장 사양이 높은 것 같다는 생각이 들었다. 이 이미지를 VirtualBox에서 사용할 때, 메모리 용량이 8GB로 설정되어 있었다. 그런데 지금 내가 쓰고 있는 노트북의 메모리 용량이 8GB라 좀 어려울 것 같았다. 그래서 AWS에 이 이미지를 올려보게 되었다.

(주의: 이 글에서 설명하는 내용은 AWS의 Free Tier 범위를 넘어가므로 사용한 만큼 요금이 부과됩니다. 크레딧이 있거나 비용 지불이 가능한 경우에 사용하시기 바랍니다. 비용 발생에 대한 책임은 독자에게 있습니다.)

최근에 AWS에서 MongoDB와 호환되는 DocumentDB를 출시했지만, 아직 서울 리전에서는 사용할 수 없다.

(2019년 5월에 서울 리전에 출시되었습니다. 링크한 글을 확인해 주세요~)

그렇지만 필요에 따라 MongoDB를 쓸 일이 있을 것이다. AWS에서 Bitnami의 이미지를 활용해서 EC2에 MongoDB를 올려보고, 시험 삼아 데이터를 넣어보자.

EC2 설정

EC2 인스턴스를 생성하기 위해 AWS의 EC2 콘솔로 들어간다. 아래 스크린샷과 같은 화면이 나오면, ‘인스턴스 시작’을 누른다.

그리고 검색어에서 MongoDB를 입력하고, 왼쪽에서 AWS Marketplace를 누른다.

스크롤을 아래로 내리다 보면, ‘MongoDB Certified by Bitnami’가 있다. 오른쪽의 선택 버튼을 누른다.

S3 버킷에는 여러 파일들을 저장할 수 있다. 그런데, 버킷에 저장된 파일의 목록을 보고 싶은 경우가 있을 것이다. 하지만, AWS의 Python SDK인 Boto3에서 list_objects()나 list_objects_v2() 함수를 이용하면 최대 1,000개까지의 object만 가져올 수 있다. [참고] (근본적으로는 AWS의 API가 최대 1,000개까지의 object만 가져오도록 구현되어 있다. - [참고])

이런 문제를 해결하기 위해, 다음과 같이 Paginator를 이용해 보자.

Paginator 이용하기

get_paginator()로 Paginator 가져오기

기본적으로 S3를 담당할 클라이언트를 생성한 뒤, get_paginator()로 Paginator를 가져온다. 여기서는 하나의 버킷에서 object들을 가져오기 위해 list_objects_v2를 이용한다. (Boto3 문서에서는 list_objects()보다 list_objects_v2()를 이용하는 것을 권장하니 이를 이용하자.)

AWS에는 Step Functions라는 서비스가 있다. 여러 개의 활동(activity)를 조합해서 순서대로 또는 반복적으로 원하는 작업을 실행할 수 있도록 해 주는 서비스이다.

일반적으로는 여러 개의 Lambda 함수를 연결해서 사용하는 경우가 많다. 하지만 Lambda 함수의 실행 시간이 5분을 넘어가면, 다른 방법을 고려해야 한다. 이럴 때 활동을 생성하고 이를 수행하는 코드를 작성하면, 오래 걸리는 작업도 Step Functions로 이용할 수 있다.

활동(Activity) 만들기

1. Step Functions 콘솔의 왼쪽 메뉴에서 활동을 클릭한다.
2. 화면이 바뀌면 우측의 활동 생성을 클릭하여 새로운 활동을 만든다.
3. 활동 이름 입력 창에서 임의의 활동 이름을 입력한다.
4. 여기서 나오는 ARN을 메모한다. 활동 이름은 알고 있어도 되지만 몰라도 상관은 없다.

상태 머신(State Machine) 만들기

1. 콘솔의 왼쪽 메뉴에서 상태 머신을 클릭한다.
2. 우측 상단의 상태 머신 생성을 클릭한다.
3. 상태 머신의 이름을 입력하고, 필요한 경우 IAM 역할을 생성한다. (나를 위한 역할 생성에 체크, AWS Step Functions이 Lambda 함수에 대한... 옵션에 체크)
4. 그리고 상태 머신 정의 칸에는 다음과 같이 입력한다. (여기가 앞에서 메모한 ARN이 사용되는 부분이다. ARN은 뒤에서도 이용하니 메모를 버리지 말자.)

{
  "StartAt": "TestActivity",
  "States": {
    "TestActivity": {
      "Type": "Task",
      "Resource": "앞에서 메모한 ARN 주소",
      "End": true
    }
  }
}

간단하게 설명을 하자면,

RDS MySQL을 이용하면, 아래와 같이 CloudWatch에 일반/감사/느린 쿼리 로그를 찍도록 설정할 수 있다.

그리고 RDS 콘솔에 들어가면 로그 파일을 볼 수 있는데, 일반 로그나 느린 쿼리 로그를 찾을 수 없었다. 그래서 CloudWatch Logs를 찾아봤지만, 역시 로그가 없었다.

그 이유를 찾아 보니, 파라미터 그룹에 로그 관련 설정을 하지 않은 것이 원인이었다.

다음과 같이 설정하면 된다.

test라는 함수가 있고, dev, release라는 별칭(alias)이 존재한다고 하자. 그리고 모든 별칭은 동일한 버전을 가리킨다고 하자.

이 경우 context 객체의 invoked_function_arn은 어떻게 달라지는지 보자. 테스트를 위해, 다음과 같이 파이썬으로 함수를 작성하였다.

import json

def lambda_handler(event, context): 
    print(context.invoked_function_arn)
    return "Success"

그리고 CloudWatch에 기록된 로그를 보자.

dev인 경우

START RequestId: 2dce0b80-5fb4-11e8-b5b7-41e11422a67a Version: 1
arn:aws:lambda:ap-northeast-2:256724228018:function:test:dev
END RequestId: 2dce0b80-5fb4-11e8-b5b7-41e11422a67a
REPORT RequestId: 2dce0b80-5fb4-11e8-b5b7-41e11422a67a  Duration: 1.56 ms       Billed Duration: 100 ms         Memory Size: 128 MB     Max Memory Used: 22 MB

release인 경우