카테고리 Archives: AWS

AWS – EBS 타입 gp3

aws 의 EC2 인스턴스에 연결하여 사용하는 EBS(disk) 의 경우 기존에 gp2 만 존재 했었다.

이번 reinvent 2020 에서 발표된 gp3가 기존 gp2가 어떤 부분이 다른지 확인을 해본다.

가격테이블(리전: Seoul/ap-northeast-2)

	gp2 GB / month	gp3 GB / month	gp3 IOPS( 1 )	gp3 Throughput( 1 MiB )
가격	US$ 0.114	US$ 0.0912	US$ 0.0057	US$ 0.0456
크기	1 ~ 16384 GB	1 ~ 16384 GB
IOPS	100 ~ 16000 disk 크기에 따른 자동조정	3000 ~ 16000 기본값 3000 이상 옵션 과금 제한 DISK크기 1MB : 500 IOPS
Throughput	125 ~ 250 MiB disk 크기에 따른 자동조정	125 ~ 1000 MiB 기본값 125 이상 옵션 과금 제한 4 IOPS : Throughput 1 MiB

gp2 에서는 IOPS 가 34GB ~ 5334GB 에서 디스크 자동 조정이 되었고, Throughput 의 경우 168 GB ~ 334 GB 에서 자동 조정이 되었다.

모든 경우값을 다 대입 할순 없겠지만 엑셀로 정리했을때 아래와 같다.

상위 표중 gp3 max speed 는 최대의 IOPS 및 Throughput 으로 하게 되며 디스크 크기에 따라아래와 같이 속도가 제한 되었다.

8GB = 4000 IOPS, Throughput 750 MiB

30GB = 15000 IOPS, , Throughput 1000 MiB(max)

기본적인 가격은 낮아졌기 때문에 gp2 보다는 gp3 를 선택해서 사용 하는게 이익이다.

다만 단순히 TYPE 만 변경 하게 될 경우 속도 상에서 기존 gp2에 비해 느릴 수 있겠다. 때문에 적절히 IOPS 와 Throughput 을 적용하는것이 좋겠다.

그래프로 그려봤을땐 아래와 같다.

좀더 현실적으로 많이 사용할 500GB 까지의 그래프는 아래와 같다.

gp2 에서 gp3 으로의 이행을 할 경우 성능 조정 없이 사용할 경우 사용료가 20% 절약이 된다.

gp2 -> gp3 로의 볼륨 수정은 서버가 running 상태에서도 변경이 가능하다. (용량에 따라 optimizing 시간이 좀 걸린다.)

Linux 에서의 IO 테스트 방법 1

~]# dd if=/dev/zero of=test bs=16k count=10000 oflag=direct && rm -f test

~]# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct && rm -f test

Linux 에서의 IO 테스트 방법 2

1 2	~]# hdparm --direct -t -T /dev/nvme0n1p1

		dd ( 16k / 10000 times)	dd ( 1M / 1000 times )	hdparm
12GB	gp2 100 IOPS 125MiB (추정)	29.5 MB/s	154 MB/s	cached: 191.81 MB/sec disk: 170.53 MB/sec
12GB	gp3 3000 IOPS 125 MiB	23.8 MB/s	149 MB/s	cached: 187.18 MB/sec disk: 166.64 MB/sec
120GB	gp2 - 360 IOPS 125MiB (추정)	28.8 MB/s	153 MB/s	cached: 191.71 MB/sec disk: 170.58 MB/sec
120GB	gp3 3000 IOPS 125 MiB	16.0 MB/s	149 MB/s	cached: 187.42 MB/sec disk: 166.60 MB/sec
500GB	gp2 IOPS 1500 250MiB (추정)	34.3 MB/s	347 MB/s	cached: 375.03 MB/sec disk: 333.46 MB/sec
500GB	gp3 3000 IOPS 250 MiB	23.0 MB/s	347 MB/s	cached: 375.04 MB/sec disk: 333.47 MB/sec
1024GB	gp2 IOPS 3072 250MiB (추정)	30.9 MB/s	345 MB/s	cached: 374.96 MB/sec disk: 333.50 MB/sec
1024GB	gp3 3000 IOPS 125 MiB	20.6 MB/s	149 MB/s	cached: 187.51 MB/sec disk: 166.63 MB/sec
2048GB	gp2 IOPS 6144 250MiB (추정)	28.0 MB/s	347 MB/s	cached: 375.04 MB/sec disk: 333.22 MB/sec
2048GB	gp3 3000 IOPS 125 MiB	23.7 MB/s	149 MB/s	cached: 187.50 MB/sec disk: 166.63 MB/sec

성능 테스트 결과 최대 속도의 경우 gp2 와 gp3가 동등하다.
gp3의 장점은 사용료가 저렴한 부분과 크레딧이 없어 일정한 속도가 유지 되는면이 있고,
아울러서 gp2 의 경우 높은 성능을 원하는 경우 디스크 크기를 증가 시켜야 하는데
gp3의 경우 성능만 높일 수 있다는 점이 장점이라고 할 수 있겠다.

gp3의 단점은 작은 용량의 파일 처리에서는 속도가 gp2에 비해 떨어진다.

Block Size	16kB	32kB	64kB
Bps	16.0 MB/s	31.6 MB/s	62.4 MB/s

Block Size	128kB	256kB	512kB
Bps	106 MB/s	135 MB/s	150 MB/s

테스트 블럭 사이즈에 비례 하게 속도가 늘어난다 @_@a

S3 버킷 CORS 설정 (json)

S3 의 CORS 설정이 기존 XML 방식에서 Json 방식으로 변경이 되었다 ‘ㅅ’a

웹콘솔에서 s3 버킷을 선택 하고 관리 탭의 하단에 있다.

사실 문법만 틀리겠지만 미리 정리를 해본다.

다음은 가장 일반적인 형태의 자신의 도메인 주소를 추가 하는 방법이다.

[

{

"AllowedOrigins": [ "https://enteroa.com" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

{

"AllowedOrigins": [ "https://*.enteroa.com" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

{

"AllowedOrigins": [ "http://enteroa.com" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

{

"AllowedOrigins": [ "http://*.enteroa.com" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

}

]

IDE를 가지고 개발하는 경우.. 개발자 PC 에서 웹서버가 자주 실행하고 테스트 해야 된다면 아래와 같이 localhost:* 을 추가 한다.

[

{

"AllowedOrigins": [ "http://localhost:*" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

{

"AllowedOrigins": [ "http://127.0.0.1:*" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

}

]

모든 곳에 허용(메일 삽입 이미지 등등) 하는 것은 Origin 설정을 * 으로 하면 된다 ‘ㅅ’a

[

{

"AllowedOrigins": [ "*" ],

"AllowedMethods": [ "GET", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

}

]

AllowedMethods 는 GET, POST, HEAD, PUT, DELETE 를 지정 할수 있다.

PS. 터미널에서 curl 으로 CORS 검사는 아래와 같이 할 수 있다.

~]# curl -sI \

-H 'Origin: http://test.com' \

-H 'Access-Control-Request-Headers: Origin, Accept, Content-Type' \

-H 'Access-Control-Request-Method: GET' \

https://enteroa-bucket.s3-us-west-2.amazonaws.com/img/123.jpg

AWS 상에서의 API Gateway – Lambda – python – pymysql – rds(mariadb) 구현

aws 에서는 API Gateway 를 제공 한다.

이는 serverless 기반의 API 생성 및 운영을 손쉽게 할 수 있는 서비스 이다. (근데 손쉽지 않더라..)

물론 굉장히 난해 하고 어렵지만 처음 한걸음은 항상 어려 웠다 ‘ㅅ’a (이 산을 넘으면 devops 가 되는 첫걸음이 된다.)

위 이미지 생성은 클라우드크래프트 (https://cloudcraft.co/) 에서 진행 하였다. (AWS 아키텍쳐를 짜는데 매우 유용함.)

즉 restful API 를 AWS 상에서 API gateway 와 Lambda 서비스를 이용하여 구축 하여 운영하는 것이다.

이미 이와 같은 많은 글을 참고 하였으나 대부분 아마존에서 제공 하는 nodojs 를 활용하는 방법만 존재 하더라…

1. Lambda 에서 함수를 생성 한다.

2. 함수가 생성 되면 기본 설정에서 함수의 제한 등을 확인할 수 있다.

핸들러의 의미는 함수가 실행되었을때 lambda_function.py 한의 def lambda_handler() 를 실행한다는 의미가 된다.

(물론 편집도 된다. DB 접근 시간이 있기 때문에 제한시간을 10~15초로 늘린다.)

3. 스크롤을 올려 보면 AWS Cloud 9 IDE 의 간소화 버전을 이용하여 수정을 할 수 있다.

4. Test 버튼을 눌러 테스트 셋을 생성 한다. (이미지는 없음)

테스트를 위한 좀더 많은 json 은 https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/sample-apps/nodejs-apig/event.json 에서 확인할 수 있다.

{

"httpMethod": "GET",

"queryStringParameters": { "nick-name": "Enteroa", "Locate": "인천" }

}

{

"httpMethod": "POST",

"body": "{\"nick-name\":\"Enteroa\",\"Locate\":\"인천\"}"

}

다시 TEST 버튼를 눌러보면 실행 API Gateway 에 연결 되었을때 실행 후 결과 값이 확인 된다.

함수 생성이 완료 되었지만 Hello World 를 보려고 이것을 하는게 아니기 때문에 API의 근본 목적인 데이터베이스 접속을 할 차례이다 ‘ㅅ’a

배포용 코드 작성은 AWS cloud 9 IDE 를 통해 작성을 할 예정이다. (일반적인 linux 나 windows 환경에서도 가능하다.)

물론 Cloud 9 을 통해 lambda 배포가 가능하지만 단순 소스 작성을 위해서만 이용할 예정 이다 ‘ㅅ’a (이걸 하려면 또 Cloud Fomation 을 해야 하기 때문에…)

Lambda 에서는 일부 json, logging 등을 별다른 설정 없이 import 할 수 있지만 pymysql 과 같은 서버에 별도 설치가 필요한 부분은 같이 업로드가 되어야 한다.

때문에 아래와 같이 pymysql 설치를 한다.

~]$ mkdir -p pydbcon

~]$ cd pydbcon

~]$ pip install -t ./ pymysql

~]$ touch dbinfo.py lambda_function.py

db 정보를 저장할 dbinfo.py 파일과 AWS lambda 핸들러에서 지정된 lambda_function.py 파일을 같이 생성 한다.

db_host = "mydb.ap-northeast-2.rds.amazonaws.com"

db_username = "enteroa"

db_password = "pa55w@RD"

db_name = "enteroa"

db_port = 3306

import json

import logging

import pymysql

import dbinfo

log = logging.getLogger()

log.setLevel(logging.INFO)

db = pymysql.connect(

host = rds_config.db_host,

port = rds_config.db_port,

db = rds_config.db_name,

user = rds_config.db_username,

password = rds_config.db_password,

ssl = {'ca':rds_config.db_ssl_ca},

charset = "utf8" )

def lambda_handler(event, context):

with db.cursor(pymysql.cursors.DictCursor) as cursor:

if event['httpMethod'] == 'GET':

bodydata = json.loads(json.dumps(event['queryStringParameters']))

response = {

'statusCode': 200,

'headers': {

'content-type': 'application/json; charset=utf-8'

'body': json.dumps(bodydata),

'isBase64Encoded': False

}

return response

if event['httpMethod'] == 'POST':

req_body_dict = json.loads(event['body'])

cursor.execute('SELECT VERSION()')

list1 = cursor.fetchall()

for a in list1:

req_body_dict['MariaDB-Version'] = a['VERSION()']

bodydata = req_body_dict

response ={

'statusCode': 200,

'headers': {

'content-type': 'application/json; charset=utf-8'

'body': json.dumps(bodydata),

'isBase64Encoded': False

}

return response

db.close()

위와 같이 작성을 하고 zip 파일로 압축을 한다.

~]$ ls

PyMySQL-0.10.0.dist-info lambda_function.py pymysql dbinfo.py

~]$ zip -r lambda001.zip ./*

adding: lambda_function.py (deflated 62%)

adding: dbinfo.py (deflated 25%)

adding: pymysql/ (stored 0%)

adding: PyMySQL-0.10.0.dist-info/ (stored 0%)

압출한 파일을 AWS 웹콘솔 에서 업로드 한다.

zip 파일이 압축 해제가 되며 lambda001 아래에 파일 및 폴더가 위치 할 수 있는데 아래와 같이 드래그 앤 드롭으로 맞추어 준다.

아니면 기본설정-핸들러를 lambda_function.lambda001.lambda_handler 으로 바꾸어도 될꺼 같기도 하다 ‘ㅅ’a

데이터베이스의 경우 보안 때문에 IP를 막고 일부만 열어서 서비스 하는것이 일반적이기 때문에 실행하는 람다를 VPC 내에서 실행 되게 해야 한다.

그래서 생성한 lambda 함수가 자신의 VPC 에서 네트워크 인터페이스를 사용할 수 있는 권한을 주어야 한다.

화면 최상단의 권한 으로 이동하고 실행 역할(IAM role) 을 눌러 해당 정책에 정책 추가를 진행해야 한다.

아래의 권한으로 정책을 새롭게 생성해서 연결 해도 되고 인라인 정책 추가를 해도 된다.

추후 생성되는 Lambda 함수는 권한 부분에서 기존 역할로 이미 VPC 권한이 부여된 역할을 선택 해주면 좀더 편하게 사용할 수 있겠다.

{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "VisualEditor0",

"Effect": "Allow",

"Action": [

"ec2:CreateNetworkInterface",

"ec2:DescribeInstances",

"ec2:DescribeNetworkInterfaces",

"ec2:DeleteNetworkInterface",

"ec2:AttachNetworkInterface"

"Resource": "*"

}

]

}

lambda 실행될 VPC 에 대한 정보를 설정해 주어야 한다.

사용자 지정 VPC 지정과 VPC 지정 subnet 지정(2개 이상) 과 EC2보안그룹을 지정 하면 된다.

그리고 RDS 서버의 보안그룹에서 위에서 lambda 가 사용할 것으로 지정된 두개의 서브넷(172.31.0.0/20, 172.31.16.0/20)을 허용한다.

테스트를 달려 본다.

앗싸 가오리!

너무 길어져서 API 게이트웨이는 나중에 추가 할 예정이다 =_=a

팔로우 할때 주의 할점은 API 게이트 웨이의 리소스 > 메소드 에서 “통합 요청”의 유형이 LAMBDA 가 아닌 LAMBDA_PROXY 으로 해야 하는 python 코드 이다.

MDS / Zombie Load 취약점

Intel CPU 에서 또다른 취약점인 MDS 취약점이 공개 되었다.

심각도는 impotant 이며 CVE-2018-11091, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 항목이다.

KISA 공지 사항: https://www.boho.or.kr/data/secNoticeView.do?bulletin_writing_sequence=35030

CPU 캐쉬내 데이터는 적재한 프로세스가 아닌 다른 프로세스에서 엑세스 할 수 있는 취약점이다.

중요도가 높다보니 취약점 패지가 이미 배포 되어 yum 업데이트만으로 해결이 가능하다.

업데이트 항목이 kernel 과 intel-microcode 다 보니 재부팅이 필요 하다.

~]# yum update yum

~]# yum update

~]# reboot

음 AWS 서비스의 경우 아래와 같이 안내 되어 있다.

https://aws.amazon.com/ko/security/security-bulletins/AWS-2019-004/

AWS has designed and implemented its infrastructure with protections against these types of bugs, and has also deployed additional protections for MDS

All EC2 host infrastructure has been updated with these new protections, and no customer action is required at the infrastructure level

뭐 AWS 인프라 레벨에서 MDS 취약점을 처리 하였으니 유져가 EC2 호스트에서 별도로 조취할 필요가 없다고 한다 🙂

랄라~

AWS 인스턴스 시작, 중지 스크립트

aws cli 명령어를 이용하여 ec2 서버를 껏다 켰다 하는 스크립트 이다.

일반 환경에서는 불필요 하고 개발 환경의 서버를 24/7 을 켜둘 이유가 없다.

개발자의 개발 환경을 고려하여 월~금 사이 AM 8:50 ~ PM 18:30 까지 만 사용 한다면 1일에 10시간만 사용함으로서 청구금액을 낮출 수 있다.

t3.medium ( 2 Core / 4G-RAM ) = 시간당 US$ 0.0416

0.0416 * 24 * 365 = $364

0.0416 * 10 * (365 / 7 * 5) = $108

* 예약 인스턴스 (Reserved instances) 를 사용한다면 더 낮출 수 있다.(30% ~ 63%) *

그래서 상시 떠있어야 하는 product 레벨의 서버 라든가 syslog 서버 등에서 아래와 같이 스크립트를 작성 하고 운영 하여 절감을 한다.

서버가 UTC 으로 세팅 되어 있는 서버 이기 때문에 cron 등록은 아래와 같이 진행하였다.

(cron : 50 23 * * 0-4 bash /shell/aws-start-instance.sh ) 월~금 KST AM 08:50 분에 작동

(cron : 30 09 * * * bash /shell/aws-start-instance.sh ) 매일 KST PM 18:30에 작동

인스턴스 자동 시작 스크립트 ( /shell/aws-start-instance.sh )

#!/bin/bash

##################################################################################

# - script dependency awscli. (~]# pip install awscli)

# by Enteroa ( enteroa.j@gmail.com )

##################################################################################

export AWS_ACCESS_KEY_ID=AAAAAAAAAAAAAAAAAAAA

export AWS_SECRET_ACCESS_KEY=BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

AWSCLI=$(which aws)

AWS_INSTANCES=(

ap-northeast-2:i-xxxxxxxxxxxxxxxxx

ap-northeast-2:i-88888888888888888

)

## instance status : stopped -> pending -> running

instance_start() {

until [[ $INSTANCE_CHECK == "running" ]]

INSTANCE_CHECK=$($AWSCLI ec2 describe-instances --region $REGION --instance-ids $INSTANCE --output text \

--query "Reservations[*].Instances[*].[State.Name]")

if [[ $INSTANCE_CHECK == "stopped" ]];then

$AWSCLI ec2 start-instances --region $REGION --instance-ids $INSTANCE

sleep 5

elif [[ $INSTANCE_CHECK == "pending" ]];then

sleep 10

elif [[ -z $INSTANCE_CHECK ]];then

break 1;

((COUNT_LOOP++))

if [ $COUNT_LOOP -ge 360 ];then

break 1;

done

unset INSTANCE_CHECK COUNT_LOOP

}

for a in ${AWS_INSTANCES[*]}

REGION=$(echo $a|cut -d":" -f1)

INSTANCE=$(echo $a|cut -d":" -f2)

instance_start;

unset REGION INSTANCE

done

unset AWS_INSTANCES AWSCLI AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY

exit 0

인스턴스 자동 정지 스크립트 ( /shell/aws-start-instance.sh )

#!/bin/bash

##################################################################################

# - script dependency awscli. (~]# pip install awscli)

# by Enteroa ( enteroa.j@gmail.com )

##################################################################################

export AWS_ACCESS_KEY_ID=AAAAAAAAAAAAAAAAAAAA

export AWS_SECRET_ACCESS_KEY=BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

AWSCLI=$(which aws)

AWS_INSTANCES=(

ap-northeast-2:i-xxxxxxxxxxxxxxxxx

ap-northeast-2:i-88888888888888888

)

## instance status : running -> stopping -> stopped

instance_stop() {

until [[ $INSTANCE_CHECK == "stopped" ]]

INSTANCE_CHECK=$($AWSCLI ec2 describe-instances --region $REGION --instance-ids $INSTANCE --output text \

--query "Reservations[*].Instances[*].[State.Name]")

if [[ $INSTANCE_CHECK == "running" ]];then

$AWSCLI ec2 stop-instances --region $REGION --instance-ids $INSTANCE

sleep 5

elif [[ $INSTANCE_CHECK == "stopping" ]];then

sleep 10

elif [[ -z $INSTANCE_CHECK ]];then

break 1;

((COUNT_LOOP++))

if [ $COUNT_LOOP -ge 360 ];then

break 1;

done

unset INSTANCE_CHECK COUNT_LOOP

}

for a in ${AWS_INSTANCES[*]}

REGION=$(echo $a|cut -d":" -f1)

INSTANCE=$(echo $a|cut -d":" -f2)

instance_stop;

unset REGION INSTANCE

done

unset AWS_INSTANCES AWSCLI AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY

exit 0