Let’s encrypt 사용 방법 변경

 

신규 서버를 세팅 하고 SSL 추가 했을때 당황스럽게도 위와 같은 메세지를 뿌리며 certbot-auto 가 작동하지 않았다.

 

certbot-auto 의 경우 실행 시킬때마다 자동 업데이트를 하는데 버전이 1.11 버전으로 되어 있을경우 발생하는 메세지로 확인이 된다.

 

링크를 따라 갈 경우 snap을 이용해서 설치해서 사용하라고 안내 되어 있다.

snap 은 yum 혹은 apt-get 과 같은 패키지 관리 툴 이다.

 

CentOS 7/8 의 경우 epel-release 가 설치 되어 있다면 yum 으로 snap을 설치할 수 있다. (6번 라인은 양반김 처럼 두번 실행해야 할 수 있다.)

 

이후에 snap 을 이용하여 certbot 을 설치한다.

주의: 기존에 yum 이나 apt-get 혹은 dnf 으로 설치된 certbot은 삭제 하고 진행 해야 한다. (일부 버전에서 심볼링 링크가 안걸리는듯… 하여 8번 라인의 명령어를 추가 실행해야 할 수 있다.)

 

/usr/bin 안으로 링크를 생성하기 때문에 ssl 발급/삭제을 위해서는 아래 명령어를 사용하면 되겠다.

 

장점이 하나 있는데 snapd 에서 sequence 기능으로 설치된 패키지를 자동으로 최신 업데이트를 하는데

발급된 인증서의 renew 역시 자동으로 처리가 된다. (/var/lib/snapd/sequence/certbot.json)

 

ps1 . 기존에 git 에서 clone 을 해서 사용한 경우 삭제까지는 필요 없는듯 하고, renew의 경우 메세지는 나오지만 갱신 하는데에는 문제가 없다.

 

ps2. snap 설치가 되지 않는 리눅스의 경우 certbot-auto 구버전 (1.9.0.dev0) 의 실행파일만 덧씌운뒤 renew 실행하면 당장 급한불을 끌 수 있음.

 

 

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 테이블 생성에 사용된 DDL 쿼리문 (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


 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
16.0 MB/s149 MB/scached: 187.42 MB/sec
disk: 166.60 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 생성 속도가 떨어졌다. (초기 8.1 Mbps 까지 떨어졌지만 추후 테스트 에서 16Mbps 으로 향상됨.)

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


Block Size16kB32kB64kB
Bps16.0 MB/s31.6 MB/s62.4 MB/s
Block Size128kB256kB512kB
Bps106 MB/s135 MB/s150 MB/s

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

Machine Learning 공부 – PlaidML

말로만 듣지 말고 해보자 라는 개념으로 시작했다.

Anaconda3 64비트를 설치 하고 파이선의 venv를 생성 한뒤에 tensorflow 설치 및 keras 설치를 진행 한다.

 

이후 메뉴얼의 트레이닝을 했을때 CPU 연산을 하는것으로 확인이 되었고

연습용 PC 으로 AMD 르누아르 계열을 쓰고 있기 때문에 GPU 연산을 위해 PlaidML 을 설치 진행 하였다.

setup시 대화형인데 동의, 그래픽카드선택, 저장 에 순서 의다.

 

사용방법 – keras를 이용하는 코드에서 아래와 같이 선언만 하면 된다.

 

테스트1 – plaidbench

 

테스트2 – python 코드 VGG19

 

잘 돌기는 도는데 이게 지금 GPU 연산을 하는가? 라는 의문이 있었다.

2020-12-02_174953

위와 같이 작업 관리자의 GPU 그래프가 너무나도 잠잠했기 때문에..

트레이닝을 시켰을때 GPU의 메모리 사용량이 늘은 것을 확인 했으나 GPU 코어 측정 부분이 가만히 있고 덩달아 시스템의 cpu / mem 사용량이 늘어 났다.

 

자세히 디버깅을 하면서 실행 해보니 AI 트레이닝 이전에 CPU/MEM 사용량이 먼저 증가 하였다 ‘ㅅ’a

구동 시나리오상 python도 같이 돌기 때문에 python 이 학습 및 테스트 데이터를 dataframe 에 넣을때 cpu 및 memory 사용량이 늘어나는것 같다.

윈도우 작업 관리자의 GPU 부분은 3D / Copy / Video Encoding, Decoding 등등만 보여주기 때문에 트레이닝시 GPU 로드 그래프 확인이 안되는것으로 추정 된다.

 

그래서 찾은 방법은 GPU-Z 를 설치해서 모니터링 하는 것이다.

2020-12-02_181729

잘된다 🙂

 

다른 방법으로는 트레이닝 시간을 측정해 볼수 있겠다.

CPU연산을 했을때에는 5 columns, 110,281 rows 를 LSTM 연산을 했을때 약 35분 11초(2111초)가 소요 되는 트레이닝이 GPU 연산을 했을때 5분 46초(346초)로 단축이 되었다.

 

PS. PlaidML 은 intel 이 만들었고 keras backend 를 연결하여 intel, AMD gpu를 쓸수 있게 해주는 패키지 이다 ‘ㅅ’a

Nvidia 가 만든 CUDA를 이용하는 구글의 tensorflow 를 쉽게 쓰게 도와주는 keras…

이와 별개로 AMD가 구축하는 ROCm 이 있다 ‘ㅅ’a (이거는 나중에 스스로 공부할때 사용할 키워드를 주절주절 써놓은것…)

S3 버킷 CORS 설정 (json)

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

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

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

 

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

 

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

 

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

 

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

 

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