태그 Archives: AWS

python – apache pyarrow 를 이용한 parquet 생성 및 테스트

apache 재단에서 진행 되는 프로젝트 이다. python, java, R 등등 많은 언어를 지원 한다.

CSV (Comma-Separated Values)의 가로열 방식의 데이터 기록이 아닌 세로열 기록 방식으로 기존 가로열 방식에서 불가능한 영역을 처리가 가능하도록 한다.

2020-12-24_135314

이미지 출처: 훈민정음 나무위키

 

차이점을 그림으로 표현하자면 아래와 같다.

2020-12-28_090730

문서를 모두 읽는다 에서는 큰 차이가 발생하지 않지만 구조적으로 모든 행이 색인(index) 처리가 된 것처럼 파일을 읽을 수 있다.

sql 문으로 가정으로 “(SELECT * FROM 테이블 WHERE 재질 = ‘철’)” 을 찾게 될 경우 index 가 둘다 없다는 가정하에서

CSV 는 9개의 칸을 읽어야 하지만 (재질->무게->산화->나무->가벼워->탄다->철->무거워->안탄다->return)

parquet 의 경우 5개의 칸만 읽으면 된다. (재질->나무->철->무거워->안탄다->return)

압축을 하더라도 컬럼별 압축이 되기 때문에 필요한 내용만 읽어서 압축해제 하여 데이터를 리턴 한다.

 

적당한 TSV (Tab-Separated Values)데이터를 준비 한다.

2020-12-24_145706

 

python 을 이용하여 TSV 파일을 읽고 python 의 pyarrow를 이용하여 parquet 파일을 생성 하고 읽는 테스트를 한다. (pyarrow, pandas 는 pip install pyarrow pandas 으로 설치할 수 있다.)

 

TSV -> parquet 압축률(높을수록 좋음) 및 처리 시간(낮을수록 좋음)

 defextMBcompress ratioprocessing time
python 2.7
processing time
python 3.6
txt.txt58.8 MB
gzip.txt.gz16.3 MB72%3.24 sec
pyarrowwrite_table,
compression='none'
.parquet
40.1 MB32%0.74 sec0.93 sec
write_table,
compression='snappy'
24.8 MB58%1.31 sec 0.95 sec
write_table,
compression='lz4'
24.7 MB58%0.79 sec0.94 sec
write_table,
compression='zstd'
19.3 MB67%1.00 sec0.98 sec
write_table,
compression='gzip'
18.8 MB68%5.07 sec1.18 sec

읽기/쓰기 테스트 모두 AWS – EC2(m5.large-centos7) – gp2(100GB) 에서 진행 하였다.

 

parquet 을 생성한 이유는 파일을 읽을때 모든 컬럼인 index가 걸려있는것과 같이 빠르게 읽기 위함이니 읽기 테스트도 해본다.

 

TSV, parquet 파일 읽기 테스트 (pandas, pyarrow)

 defextMBprocessing time
python 2.7
processing time
python 3.6
pandasread_csv.txt58.8 MB1.39 sec1.56 sec
read_csv,
compression='gzip'
.txt.gz16.3 MB1.68 sec2.06 sec
read_parquet.parquet
(none)
40.1 MB0.72 sec0.93 sec
.parquet
(snappy)
24.8 MB1.03 sec0.95 sec
.parquet
(lz4)
24.7 MB0.73 sec0.94 sec
.parquet
(zstd)
19.3 MB0.76 sec0.95 sec
.parquet
(gzip)
18.8 MB0.96 sec1.18 sec
pyarrowread_csv,
to_pandas
.txt58.8 MB1.01 sec1.30 sec
.txt.gz16.3 MB1.41 sec1.37 sec
read_table,
to_pandas
.parquet
(none)
40.1 MB0.69 sec0.90 sec
.parquet
(snappy)
24.8 MB0.99 sec0.89 sec
.parquet
(lz4)
24.7 MB0.69 sec0.92 sec
.parquet
(zstd)
19.3 MB0.75 sec0.95 sec
.parquet
(gzip)
18.8 MB0.95 sec1.22sec

 

이 문서 처음에 언급 했다 시피 대용량 파일을 처리 하기 위함. 즉 “빅데이터”(HIVE, Presto, Spark, AWS-athena)환경을  위한 포멧이다.

모두 테스트 해보면 좋겠지만 아직 실력이 부족해서 AWS athena 만 테스트를 진행 한다.

구조적으로 S3 버킷에 parquet 파일을 넣어 두고 athena 에서 테이블을(S3 디렉토리 연결) 생성 하여 SQL 문으로 검색을 하는데 사용 한다.

 

TSV, parquet 파일 읽기 테스트 (AWS – athena)

 ROW FORMAT SERDEextSearched
MB
processing time
(select target 2)
processing time
(select target 50)
athenaorg.apache.hadoop.hive.
serde2.lazy.
LazySimpleSerDe
.txt58.8 MB1.17 ~ 3.35 sec1.86 ~ 2.68 sec
.txt.gz16.3 MB1.37 ~ 1.49 sec1.44 ~ 2.69 sec
org.apache.hadoop.hive.
ql.io.parquet.serde.
ParquetHiveSerDe
.txt.parquet10.48 MB1.11 ~ 1.49 sec1.00 ~ 1.38 sec
.snappy.parquet4.71 MB0.90 ~ 2.36 sec0.90 ~ 1.00 sec
지원 불가.lz4.parquet지원 불가
.zstd.parquet
org.apache.hadoop.hive.
ql.io.parquet.serde.
ParquetHiveSerDe
.gzip.parquet2.76 MB0.89 ~ 1.17 sec0.90 ~ 1.85 sec

읽는 속도가 향상되었고 스캔 크기가 적게 나온다. (parquet 의 강점을 보여주는 테스트)

 

athena 테이블 생성에 사용된 쿼리문 (TSV, parquet)

 

PS. 이건 저도 어려 웠어요…..

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.114US$ 0.912US$ 0.0057US$ 0.0456
크기1 ~ 16384 GB1 ~ 16384 GB
IOPS100 ~ 16000
disk 크기에 따른 자동조정
3000 ~ 16000
기본값 3000 이상 옵션 과금

제한
DISK크기 1MB : 500 IOPS
Throughput125 ~ 250 MiB
disk 크기에 따른 자동조정
125 ~ 1000 MiB
기본값 125 이상 옵션 과금

제한
4 IOPS : Throughput 1 MiB

 

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

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

2020-12-10_095745

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

8GB = 4000 IOPS, Throughput 750 MiB

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

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

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

 

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

2020-12-10_095759

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

2020-12-10_095814

 

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

gp2 -> gp3 로의 볼륨 수정은 서버가 running 상태에서도 변경이 가능하다. (다만 optimizing 시간이 좀 길게 느껴진다)

볼륨 타입 조정 할때 Linux 서버내에서의 성능 테스트를 진행하였다.

Linux 에서의 IO 테스트 방법 1

Linux 에서의 IO 테스트 방법 2

 

결과 (측정중…optimizing 이 오래 걸린다..)

 dd
( 16k / 10000 times)
dd
( 1M / 1000 times )
hdparm
12GBgp2
100 IOPS
125MiB (추정)
29.5 MB/s154 MB/scached: 191.81 MB/sec
disk: 170.53 MB/sec
gp3
120GBgp2 -
360 IOPS
125MiB (추정)
28.8 MB/s153 MB/s
cached: 191.71 MB/sec
disk: 170.58 MB/sec
gp3
3000 IOPS
125 MiB
8.1 MB/s149 MB/scached: 187.30 MB/sec
disk: 166.47 MB/sec
500GBgp2
IOPS 1500
250MiB (추정)
34.3 MB/s347 MB/s
cached: 375.03 MB/sec
disk: 333.46 MB/sec
gp3
1024GBgp2
IOPS 3072
250MiB (추정)
30.9 MB/s345 MB/scached: 374.96 MB/sec
disk: 333.50 MB/sec
gp3
2048GBgp2
IOPS 6144
250MiB (추정)
28.0 MB/s347 MB/scached: 375.04 MB/sec
disk: 333.22 MB/sec
gp3

테스트 예측으로는 같은 값이 나와야 한다.

gp2의 경우 버스트 잔고라는게 적재가 되고 적재된 버스트 잔고가 0이 될때 까지는 iops 가 3000 까지 쓸 수 있다. 이후에는 설정된 100 이라든가 300이라든가로 제한 된다.

하지만 예측과 다르게 테스트 결과 16k 생성 속도가 떨어졌다.

바로 변경한 사람이 벌써 꽤나 된것으로 보아 붐비는 것일 수도 있고 하니 몇일 뒤 마저 테스트 해봐야 겠다 @_@a

 

S3 버킷 CORS 설정 (json)

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

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

 

aws-api-lambda-python-rds

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

 

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

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


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

2020-08-07_154033


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

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

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

2020-08-07_162631


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

2020-08-07_163001


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

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

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

2020-08-07_164220

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


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

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

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

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

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

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

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

2020-08-07_173321

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

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

2020-08-07_174505


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

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

2020-08-07_175052

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

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

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

2020-08-07_175631


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

2020-08-07_180250

2020-08-07_180507

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


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

2020-08-10_113634


테스트를 달려 본다.

2020-08-07_181235

앗싸 가오리!


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

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

aws ubuntu 18.04 자동 업데이트 끄기

aws 에서 서버운영을 하는데

가장 작은 디스크 크기 8GB 으로 생성하고 1년정도 운영을 했을때 디스크가 초반에 4.XX GB만 사용이 되다가 점점 사용량이 증가 되었음 ‘ㅅ’a

 

ubuntu 의 경우 자동 업데이트로 꾸준히 커널을 업데이트 하기 때문에 발생하는 문제이고

특정한 서비스 포트만 열고 서비스 하는 서버이기 때문에 업데이트가 필요 없다고 판단되어 자동업데이트를 끄는 것으로…

 

이후 apt-get 을 이용하여 불필요한 패키지를 삭제한다 ‘ㅅ’a

 

linux-headers가 업데이트가 된 경우 재 부팅 이후에 autoremove를 해야할 수 있다.

혹은 너무 쌓여서 broken 이 된경우 /usr/src 에서  사용되고 있는 headers 를 제외하고 삭제를 해야 할 수 있겠다 ‘ㅅ’a