태그 보관물: aws

Amazon Athena를 이용해 CloudFront 로그 분석하기

CloudFront(클라우드 프론트)를 이용하다 보면 요청 로그를 직접 분석해야 할 필요가 있습니다.

CloudFront에서 제공하는 통계 메뉴에서도 전체 요청수, Hit, Miss, Error, 상태코드, 용량, 인기객체 등 많은 데이터를 볼 수 있지만 각 요청중 오래 걸리는 요청에 대해 분석하고 싶은 경우에는 CloudFront 로그를 직접 확인해야합니다.

CloudFront 로그파일 저장

CloudFront 기본 옵션은 요청 로그를 따로 저장하지 않습니다. 로그를 저장하기 위해 Distribution 설정에서 Logging 옵션을 On으로 변경하고 로그가 저장될 S3 버킷 이름과 경로를 지정합니다.

저장된 로그의 저장 기간을 설정하기 위해 S3 Bucket 설정에 가서 Management > Lifecycle 에서 Lifecycle Rule을 새로 생성후 Prefix에 따른 로그 삭제 기간을 설정합니다.

삭제에 대한 정책을 생성하지 않으면 용량이 점점 커져서 비용이 비싸지고 로그 분석하는 데도 오래 걸립니다. 문제 해결에 필요한 로그라고 판단되는 3일치 데이터만 놔두고 3일이 지나면 삭제되도록 설정했습니다. 기간은 서비스 특징에 따라서 조정하면 됩니다.

Athena 테이블 생성하기

Athena 에서는 데이터를 분석하기 전에 테이블 생성작업을 해야합니다. 생성할 테이블은 앞서 생성했던 S3 데이터를 참고 하도록 설정하는것이고 이 시점에는 논리적인 테이블만 생성되고 실제 S3 데이터를 읽지 않습니다.

Athena의 Query Editor에서 아래 쿼리를 입력후 실행하면 cloudfront_logs 테이블이 생성됩니다.

CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_logs (
  `date` date,
  `time` string,
  `location` string,
  bytes bigint,
  requestip string,
  method string,
  host string,
  uri string,
  status int,
  referrer string,
  useragent string,
  querystring string,
  cookie string,
  resulttype string,
  requestid string,
  hostheader string,
  requestprotocol int,
  requestbytes bigint,
  timetaken double,
  xforwardedfor string,
  sslprotocol string,
  sslcipher string,
  responseresulttype string,
  httpversion string
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES
 (
 "input.regex" = "^(?!#)([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)$"
 )
LOCATION 's3://로그가저장된S3버킷이름/cf-logs/';

준비를 위한 작업이 모두 끝났습니다. 복잡하다고 생각할수도 있지만 다른 서비스를 이용하는 경우 여기까지의 준비 작업을 위해 데이터를 파싱하고 다시 저장하는등의 작업을 해야되는것을 생각하면 Athena의 준비 작업은 간단합니다.

느린 요청 로그만 추출하기

이미지 요청 속도가 특별히 느린 사용자들의 특징을 찾기 위해 응답시간이 느린 로그만 추출 해보겠습니다.

SELECT 
   date,
   time,
   timetaken,
   location,
   requestip,
   resulttype,
   responseresulttype,
   concat('https://', host, uri)
 FROM "default"."cloudfront_logs" 
 WHERE 
   timetaken > 1
 LIMIT 100;

위 SQL은 응답시간이 1초 이상 걸린 로그만 보여줍니다. 이를 통해 특정 엣지에서 요청이 느린것인지 아니면 특정 IP만 느린지 확인할 수 있습니다.

엣지 로케이션 별로 1초 이상 걸린 요청의 갯수를 알고 싶다면 아래 SQL을 실행합니다.

SELECT 
   location,
   count(*) as cnt
 FROM "default"."cloudfront_logs" 
 WHERE 
   timetaken > 1
 GROUP BY location
 ORDER BY cnt DESC

결과를 보니 별 의미는 없네요. ICN으로 시작하는건 한국 엣지 로케이션인데 절대적인 요청수가 많다보니 1초 이상 걸린것도 많이 나왔습니다.

이외에도 UserAgent를 분석해 기기나 OS에 따른 구분이나 HTTP 프로토콜 버전에 따른 구분등 할 수 있는것이 많습니다. 본인만의 SQL을 좀더 잘 만들어 본다면 CloudFront를 잘 사용하는데 도움이 될것입니다.

주의 할점

Athena는 데이터 분석에 필요한 데이터를 스캔하는 용량 만큼 과금됩니다. SQL을 잘못 작성해서 너무 많은 데이터를 참고 하게 되면 많은 비용이 청구 될 수 있으니 데이터를 적절히 제한해서 SQL 을 작성하는 노력이 필요합니다.

데이터가 많지 않으면 그냥 막 해도 상관 없습니다. 1TB 데이터를 스캔 하는데 $5 정도라서 데이터가 100기가 라면 500원 10 기가라면 50원이니까요 ^^

참고자료

대표 이미지 : Photo by NASA on Unsplash

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

AWS EC2 디스크 크기 늘리기

EC2를 사용하다보면 처음 예상과는 다르게 디스크 공간이 부족한 경우가 생깁니다.

EC2에서 EBS 볼륨을 사용한다면 서버를 중지하지 않고도 디스크 크기를 쉽게 늘릴수 있습니다. 현재 세대 인스턴스(t2, m3, m4, c3, c4, r3, r4등)만 가능하고 이전세대 인스턴스(m1, m2, c1, c2, t1 등) 를 사용하는 경우 인스턴스를 중지하고 작업해야합니다.

  1. AWS 콘솔에 접속후 크기를 늘리고자 하는 EC2 인스턴스의 볼륨을 선택
  2. ‘Modify Volume’ 을 눌러서 새로운 디스크 크기를 입력
  3. 볼륨의 상태정보중 “State” 값이 in-uses-optimizing 으로 변경된후 다음 작업 진행
  4. EC2 인스턴스에 SSH로 접속

lsblk 명령어를 입력해서 현재 상태를 확인

ubuntu@myserver:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 60G 0 disk
└─xvda1 202:1 0 30G 0 part / 

여기서 보면 xvda 디스크 크기는 새로 변경한 60G 인데 그 밑에 있는 파티션은 아직 바뀌지 않아서 30G로 되어 있습니다.

파티션을 늘리기 위해 다음 명령어를 입력

$ sudo growpart /dev/xvda 1
$ sudo resize2fs /dev/xvda1

여기서 주의할점은 처음 명령어에서는 /dev/xvda 라는 디스크 이름을 적고 공백 다음에 숫자 1을 입력했는데 두번째 명령어에서는 /dev/xvda1 으로 파티션 이름을 입력했다는점 입니다.

다시 lsblk 명령어를 실행하면 파티션의 크기도 60G로 늘어난것을 확인할 수 있습니다.

ubuntu@myserver:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 60G 0 disk
└─xvda1 202:1 0 60G 0 part / 

df -h 명령어를 이용해서 디스크 용량을 볼때도 늘어나 있습니다.

ubuntu@myserver:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G   12K  3.9G   1% /dev
tmpfs           799M  484K  798M   1% /run
/dev/xvda1       59G   22G   35G  39% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            3.9G     0  3.9G   0% /run/shm
none            100M     0  100M   0% /run/user

참고정보

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

AWS elasticsearch 에서 스냅샷 생성 및 복원

AWS elasticsearch 에서는 자동백업을 지원하지만 이걸 복원하려면 AWS Support에 직접 요청하는 방식이라 원하는 시점에 복원하지 못할 수 도 있습니다. 또한 elasticsearch 버전을 올리기위해 마이그레이션을 할때는 새로운 elasticsearch를 생성하고 직접 백업 및 복원을 해야합니다.

그래서 이번 글은 AWS elasticsearch 스냅샷 생성 및 복원에 대해 처음부터 끝까지 적어봤습니다. IAM Role 설정같은데서 헷갈려서 제가 좀 헤맨 부분이 있어 다른분들한테도 도움이 될것 같네요.

사전작업

  1. 백업파일이 위치할 S3 파일을 생성
  2. IAM Role 생성
  3. IAM Policy 생성후 2번에서 생성한 Role에 추가

1. S3 버킷 생성

my-es-snapshot 버킷을 생성. 이건 그냥 버킷만 생성하면 됩니다 ~ 될수 있으면 elasticsearch 와 같은 region 으로 맞춰주는게 좋겠지요?

2. IAM Role 생성

IAM 메뉴 접속후 “Role > Create New Role” 을 이용해 새로운 Role을 생성. Role 이름은 아무거나 정하고 여기서는 “esSnapshotRole”로 지정. “Select Role Type”에서는 “Amazon EC2” 선택. 그다음 Attach Policy 에서는 아무것도 선택하지 않고 “Next Step”

이렇게 하면 Role 이 생성됩니다.

3. IAM Policy 생성후 연결

IAM 메뉴 접속후 “Policies > Create Policy” 버튼을 클릭.
“Create Your Own Policy”를 선택하고 “Policy Document”에 다음 내용을 붙어녛기 합니다

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::my-es-snapshot"
            ]
        },
        {
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "iam:PassRole"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::my-es-snapshot/*"
            ]
        }
    ]
}

여기서 my-es-snapshot 은 S3 버킷 이름으로 본인의 상황에 맞게 변경합니다

이렇게 생성된 Policy 의 상세화면에 들어가서 “Attached Entities” 에서 Attach 버튼을 클릭해 앞서 생성한 IAM Role에 연결합니다

스냅샷 저장소 생성

AWS Elasticsearch 같은경우 스냅샷 저장소 생성은 curl 명령어를 이용해서는 불가능합니다. 맥의 경우를 가정하면 터미널을 실행후 아래 명령어를 실행합니다.(윈도우 사용자분들은 알아서 자알 ~ 파이썬 설치하고 pip 뭐 이런거 동작하게 설치하면 될거에요)

$ sudo pip install boto

이 다음에 snapshot.py 라는 파일을 만들고 아래 내용을 붙여넣기후 저장

from boto.connection import AWSAuthConnection

class ESConnection(AWSAuthConnection):

    def __init__(self, region, **kwargs):
        super(ESConnection, self).__init__(**kwargs)
        self._set_auth_region_name(region)
        self._set_auth_service_name("es")

    def _required_auth_capability(self):
        return ['hmac-v4']

if __name__ == "__main__":

    client = ESConnection(
            region='ap-northeast-2',
            host='search-xxx-yyyy.ap-northeast-2.es.amazonaws.com',
            aws_access_key_id='xxxxx',
            aws_secret_access_key='yyyyy', is_secure=False)

    print 'Registering Snapshot Repository'
    resp = client.make_request(method='POST',
            path='/_snapshot/s3_repository',
            data='{"type": "s3","settings": { "bucket": "my-es-snapshot","region": "ap-northeast-2","role_arn": "arn:aws:iam::xxxx:role/esSnapshotRole"}}')
    body = resp.read()
    print body
region, host, aws_access_key_id, aws_secret_access_key, path, data 등은 본인의 상황에 맞게 변경합니다.
  • region=’ap-northeast-2′
    • 이건 서울의 경우. 다른 지역에 있는 elasticsearch 라면 변경이 필요
  • host=’search-xxx-yyyy.ap-northeast-2.es.amazonaws.com’
    • AWS elasticsearch 주소
  • aws_access_key_id=’xxxxx’, aws_secret_access_key=’yyyyy’
    • AWS elasticsearch 에 접근권한이 있는 계정의 인증정보
  • path=’/_snapshot/s3_repository’
    • elasticsearch 에 생성할 스냅샷 저장소 경로. s3_repository 부분을 원하는 이름으로 변경
  • “bucket”: “my-es-snapshot”
    • 앞서 생성한 S3 버킷 이름
  • “region”: “ap-northeast-2”
    • S3 버킷의 region
  • “role_arn”: “arn:aws:iam::xxxx:role/esSnapshotRole”
    • 앞서 생성한 IAM Role의 ARN 문자열. Role 상세페이지에서 “Role ARN” 속성으로 확인가능
설정을 본인에 맞게 변경후 터미널에서 다음 명령어를 실행합니다
$ python snapshot.py

실행후 별다른 에러 없으면 스냅샷 저장소 생성 성공 ~

맥의 경우에는 파이썬이 설치되어 있어서 별도의 파이썬 설치가 필요없지만 윈도우라면 알아서 잘 설치하고 진행하면 됩니다.

스냅샷 생성

아래 명령어를 터미널에서 실행해서 새로운 스냅샷을 생성합니다.
$ curl -XPUT 'https://search-xxx-yyy.ap-northeast-2.es.amazonaws.com/_snapshot/s3_repository/first_snapshot'

위의 명령어는 앞서 생성한 s3_repository 스냅샷 저장소에 first_snapshot 이라는 스냅샷을 생성합니다.

위 명령어의 결과는 바로 반환되고 뒤에서는 스냅샷을 생성하고 있다. 완료여부를 확인하려면 다음 명령어를 실행합니다.

$ curl -XGET 'https://search-xxx-yyy.ap-northeast-2.es.amazonaws.com/_snapshot/s3_repository/first_snapshot'
이거의 반환값의 “state” 항목이 “SUCCESS” 이면 스냅샷 생성이 완료된것입니다. 참고로 스냅샷 생성이 완료되지 않았을때는 아무런 에러없이 오랫동안 반환이 안되요

스냅샷 복원

아래 명령어를 이용해 복원을 시작한다
$ curl -XPOST 'https://search-xxx-yyyy.ap-northeast-2.es.amazonaws.com/_snapshot/s3_repository/first_snapshot/_restore'

스냅샷 생성때와 마찬가지로 실행하자마자 반환값이 나오지만 뒤에서 계속 복원이 진행중인 상태입니다.

복원이 진행중일때는 클러스터 상태가 Red 이고 완료되면 원래의 클러스터 상태로 돌아오므로 클러스터 상태를 통해 복원이 완료되었는지 확인할 수 있습니다

아래 명령어가 클러스터 상태 확인하는 명령어

$ curl -XGET 'https://search-xxx-yyyy.ap-northeast-2.es.amazonaws.com/_cluster/health'

다른 elasticserach 로 스냅샷을 복원하는 경우

elasticsearch 를 마이그레이션 하거나 다른 elasticsearch 클러스터에 복원하려는 경우 새로운 elasticserach 에 스냅샷 저장소만 생성하면 됩니다. 스냅샷 저장소를 앞서 생성한 스냅샷 저장소와 동일한 옵션으로 생성하면 같은 S3를 바라보게 되므로 복원도 바로 됩니다

참고자료

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^