태그 보관물: aws

Amazon CloudWatch 수집된 지표에 수식계산 Metric Math

아마존 웹서비스를 사용하다보면 사용중인 서비스를 모니터링 하기 위해 CloudWatch 를 한번씩은 사용하게 됩니다. 많은 지표들이 제공되지만 제공되는 지표에 몇가지 더하거나 조합하는 경우 이번에 소개하는 Metric Math 를 이용합니다.

RDS Total IOPS 수치 확인하기

RDS의 모니터링을 예로 들어보면 Read IOPS, Write IOPS라는 지표를 별도로 제공하는데 RDS의 IOPS 제한은 Read와 Write IOPS를 더한값으로 적용됩니다. 그래서 Total IOPS를 알고 있는것이 중요한데 CloudWatch 에서는 Total IOPS를 지표 정보로 제공하지 않습니다.

저 같은 경우 기존에는 Total IOPS를 모니터링 하기 위해 1분마다 Read IOPS와 Write IOPS를 조회하고 다시 Total IOPS라는 새로운 지표로 CloudWatch에 저장하는 작업을 하고 있었습니다. 하지만 Metric Math 기능을 이용하면 더이상 이렇게 할 필요가 없습니다.

CloudWatch 대시보드 혹은 Metrics 에서 RDS 를 선택하고 Read IOPS, Write IOPS를 각자 설정후 Graphed metrics 탭을 선택하고 테이블 상단의 Add a math express 버튼을 클릭합니다.

클릭하면 테이블 목록 상단에 e1 이라는 id를 가진 행이 추가되고 Details에는 SUM(METRICS()) 라고 입력됩니다. 이 수식의 의미는 현재 선택된 지표들을 모두 더한다는 의미입니다. 이 경우 Read IOPS + Write IOPS 인거죠. 수식을 이해하기 쉽게 m1 + m2로 변경해도 동일한 의미가 됩니다. 여기서 m1, m2는 각 행의 id 값입니다.

Total IOPS만 그래프에 표시하기 위해 체크 박스에서 e1 을 제외한 m1, m2는 체크를 해제하면 위와 같이 Total IOPS만 그래프에 표시되는것을 확인할 수 있습니다.

ElastiCache Hit Rate 계산 하기

ElastiCache 의 Hit Rate를 계산하는 것도 Metric Math를 이용하면 유용한 수치입니다. 캐시가 적당하게 잘 되고 있는지 볼 수 있는 유용한 지표가 Hit Rate인데 CloudWatch에서는 제공되지 않습니다.

이제 직접 Hit Rate를 계산해 보겠습니다.

Metrics 에서 모니터링을 원하는 ElastiCache 인스턴스의 Get Hits, Get Misses를 선택하고 앞서 했던 것처럼 Add a math express 버튼을 클릭합니다. 수식 입력란에 (m1 / (m1 + m2)) * 100를 입력하고 m1, m2의 그래프 체크박스를 해제하면 Hit Rate를 볼 수 있습니다.

정리

CloudWatch는 AWS 서비스를 이용하다 보면 한번쯤 접하게 되고 모니터링이나 알림 용도로 자주 사용하게 됩니다. 하지만 제공하지 않는 지표가 있거나 여러 지표를 조합하고자 하는 경우 불편한점이 있었는데 Metric Math 기능으로 인해 사용하기 편해졌습니다.

아쉽게도 현재는 수식이 적용된 지표에 대해서는 알림 기능을 제공하지 않습니다. 알림을 받고 싶다면 기존 방식처럼 별도의 CloudWatch 지표를 매분 마다 생성해야합니다.

이 내용은 제가 운영하는 유튜브 채널인 달구지코딩에서도 확인할 수 있습니다. 구독과 좋아요 부탁드립니다 ^^

참고자료

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

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) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^