태그 Archives: AWS

synology 에 docker 를 이용한 gitea 레포지토리 운영

gitea

git 은 기본적으로 synology 에서 Git Server 를 제공 한다.
다만 GUI를 이용한 관리 환경을 제공 하지 않기 때문에 어렵고 불편 하다.

그래서 Synology 서버에 docker 를 설치 하고 gitea 도커이미지를 이용해서 간단히 Container 를 이용해 내부용 레포지토리를 운영 한다.
클라우드 – ARM 환경에서도 잘 되기 때문에 신규 사용자의 Amazon CodeCommit 이 중지된 지금 시점에서 클라우드내에 IaaS 으로 구축해 사용하기도 좋다.

 


 

  • Synology NAS 에서 docker 또는 Container Manager 를 설치 한다.(DSM 버전에 따라 패키지 명이 다를 수 있다.)

2024-12-18_165142

 

  • gitea/gitea 이미지를 다운로드 받는다.

2024-12-18_165554

 

  • 다운로드가 완료 되면 이미지를 실행해 시킨다.

2024-12-18_170015
내 경우엔 리소스를 제한하고 자동 재시작 옵션을 활성화 했다.
(gitea 는 golang 으로 만들어져 가볍지만 레포가 늘어 나면 메모리 사용량이 꾸준히 증가할 수 있다.)

 

  • 다음 화면에서 연결될 포트를 선언 한다.

2024-12-18_170147
gitea 은 기본적으로 ssh, http 프로토콜을 사용한다.
DSM의 ssh 와 충돌 하지 않도록 포트는 2222 으로 지정 하고 웹 포트는 3000을 사용 하도록 했다.

 

  • 파일 스테이션에서 연결할 폴더를 생성 한다.

2024-12-18_170329
Synology 에서 연결되는 폴더는 docker 를 설치시 생성 되는 /docker 공유 폴더 아래에 있어야 한다.

 

  • 연결할 볼륨 및 환경을 추가 한다.

2024-12-18_170421
USER_UID, USER_GID 는 위 스크린샷과 같이 지정 해도 된다.
다만 정확히 하려면 사용중인 synology 의 관리자 ID 의 uid, gid를 확인해서 대입 한다.

참고로 내 Synology 의 관리자 아이디는 nas-admin 이 아니다. (쓸모 없는 =_= 공격금지)

 

  • 최종 점검 후 실행 한다.

2024-12-18_170444

 


 

  • gitea 으로 접속해 설치를 진행 한다. ( http://[Synology-Nas-IP]:3000 )

2024-12-18_173317
관리자 계정 설정의 ▶ 를 눌러서 관리자 정보를 입력 하는것을 잊지 말자.
중간에 빨간색, 파란색 칸은 Container 를 실행 할때 ssh, http 포트를 입력해야 하는 부분으로 맞추어 주어야 한다.

 

  • 테스트로 github 에 있는 레포지토리를 mirror 으로 생성 해본다.

2024-12-18_174234 2024-12-18_174247 2024-12-18_174347
미러로 생성 하는 경우 원본 에서 8시간 데이터 싱크를 해온다 ‘ㅅ’a
gitea 는 github 과 사용 방법이 비슷 하니 어렵지 않을 것이다.

AWS 서버 발생 로그의 분리 보관 (amazon-cloudwatch-agent)

서버내 dbus -> rsyslogd 에 의해 수집된 시스템 로그는 /var/log 아래에 파일 형태로 저장 된다.

이는 /etc/logrotate.conf 설정에 따라 서버내에 보관이 된다.

 

다만 보관된 파일의 파일 형태로 저장되어 있기 때문에 구조만 알고 있다면 파일을 삭제 하거나 변조 할 수 있으므로

추후 추적을 용의 하게 하기 위해, 데이터 무결성을 보장하기 위해, 혹은 다중의 서버의 데이터를 모아서 보관 하기위해 log 콜렉팅을 하는것이 일반적인 보안 방법 이다.

 

단순한 rsyslogd 를 이용한 udp 푸시 및 graylog collecting 은 기존에 설명을 했지만

AWS 상에서는 CloudWatch Log 라는 기능을 제공 한다 이를 통해 지표 형태로 보거나 알람 설정등을 할 수 있다.

 

서버에서는 CloudWatch log 쪽으로 데이터를 넣어주는 프로그램을 설치해서 운용 하며 이후

Log 파일의 안전한 분리 보관, 보관 주기 설정, 알람 설정 등을 웹 콘솔상에서 편하게 진행할 수 있다.

 

기존에 centos 7 에서는 yum 을 이용하여 awslogs 라는 프로그램을 설치하여 같은 기능을 사용하고 있었으나

Rockylinux 8 에서는 dnf 패키지가 없는 관계로 RPM 설치를 필요로 한다.


AWS 웹콘솔 에서 IAM 메뉴의 Role (역할) 을 생성 하고 권한을 부여 한다. (중간에 권한은 지정하지 않고 생성 하고 추후 인라인 정책으로 생성 한다.)

2022-04-08_161452 2022-04-08_161613 2022-04-08_162326

 

인라인 정책을 생성 한다. (생성한 정책이 다른 계정 이나 역할에 공통으로 부여할 필요하 있으면 일반 정책 생성 후 연결 한다.)

2022-04-08_162608 2022-04-08_163101 2022-04-08_163232

위 json 정책은 ap-northeast-2 (서울) 리전에 로그 를 쌓는 기능만 허용 하는것으로 제한 하였다.

 

생성된 Role (역할) 을 필요한 EC2에 연결 한다.

2022-04-08_164417 2022-04-08_164648

 

위에서 이야기 했지만 yum(dnf) 설치가 RockyLinux 8 에서 되지 않는다. 때문에 AWS 에서 배포 하는 rpm 파일을 가지고 설치를 진행 한다. (amazon-cloudwatch-agent  설치 메뉴얼)

 

편리하게 사용하라고 대화식 명령어를 실행 하도록 되어 있다.
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

하지만 문답 형식의 영어를 읽기도 귀찮고(어렵고) Role (정책)을 부여하여 키없이 로그를 쌓게 하고자 했으나

스크립트에서는 필수적으로 Access Key/Secret Key 를 입력 해야 하는 부분이 있기 때문에 스크립트로 진행이 어렵다.

때문에 /opt/aws/amazon-cloudwatch-agent/bin/config.json 파일을 직접 수정 해 준다. (amazon-cloudwatch-agent 설정 메뉴얼)

위 예제는 apache, php, nginx 등을 dnf(yum) 설치를 한경우 일반 적인 log 포멧의 timestamp를 인식 하도록 정리한 것이다. (secure, message 로그 및 apache, nginx, php-fpm 로그)

필요에 따라 수정을 해서 사용 하도록 한다.

 

이후 다음 명령어로 설정된 config.json 을 점검 하고 문제가 없다면 자동으로 서비스가 시작된다.

 

웹 콘솔 에서 Cloudwatch > 로그 그룹에서 보관 기간 을 설정 하고 로그 데이터가 잘 적재 되고 있는지 확인 한다.

2022-04-08_1810182022-04-08_1649512022-04-08_181557

AWS SES – SMTP 계정 의 키 변경

AWS SES (Simple Email Service) 는 직접 구축이 어려운 이메일 서비스를 제공한다.

sendmail 으로 SMTP 구성을 사용할 수 있지만 보통 스팸 방지를 위한 여러 솔루션에 의해서 차단이 되기 때문에

직접 sendmail 서비스를 구성하고 서비스 하기 위해서는 광범위한 공부가 필요 하다.

1. sendmail – smtp 구축

2. KISARBL 등록 (이것은 한국의 포털 쪽으로 메일 서비스 원활히 발송하기 위해 필요 하다.)

3. ReverseDNS 등록 (이건 해외 포털 서비스 쪽과 관련이 있다. Internet Service Provider 에서 등록이 가능하다. – KT, SK, U+ 등등..)

4. DKIM, DMARC 설정 (해외 포탈 gmail, yahoo 등등)

아울어서 주기적인 IP 신뢰도 관리를 위해 서버내에서 발송되는 메일을 추적, 통제 해야 한다.

 

AWS SES 는 월 62,000건 까지는 무료로 발송이 되며 이후 초과 되는 1000개의 메일당 약 100~150원 정도의 비용이 발생 한다.

물론 수신자의 스팸 신고가 많거나(1%) 허위 메일 주소로 발송(5%)되면 메일 발송 서비스가 차단 된다.

 

메일 발송을 위한 SMTP 계정은 생성을 하게 되면 auth 계정이 할당 되게 되며 사전에 등록된 메일 주소로만 발송을 할 수 있다.

문제는 ID / PW 형식 이기 때문에 유출 되었거나.. 혹은 패스워드 생성일이 오래 되면 보안상 바꾸어 주어야 한다.

 

AWS – IAM 에서 일반적으로 생성하는 액세스 키는 20글자 시크릿 키는 40 글자 를 차지 한다.

2021-01-22_151318

 

AWS – SES 에서는 SMTP 계정을 만들때 패스워드 길이가 44 글자를 가진다.

즉 SES 메뉴에서 “Create My SMTP Credentials” 생성한 계정을 사용할 수 있다.

2021-01-22_151735

 

그래서 찾아 보니 아래와 같은 메뉴얼을 찾을 수 있었다.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/ses-rotate-smtp-access-keys/

 

근데 이해는 잘 되지 않는…

종합해보면 기본으로 제공 되는 파이선코드 를 이용하여 컨버팅 해서 써야 한다는 말이다.

 

시스템 엔지니어링을 하는 입장에서는 생성된 값을 테스트 하고 넘겨 줘야 하는 부분도 있고 python3 전용인 부분도 조금 마음에 안들어서

패스워드 생성 후 SMTP 테스트를 진행 하도록 하였다. ‘ㅅ’a

 

사용 방법은 다음과 같다.

 

IAM 아무렇게나 생성된 계정에서는 작동하지 않고, 계정에 ses:SendRawEmail 권한이 부여 되어 있어야 작동 한다. (SES 에서 생성한 계정은 이미 부여가 되어 있을 것임.)

 

ps. 위에 예시된 엑세스키/시크릿키/SMTP비밀번호는 이 글을 포스팅 한 이후 모두 삭제 했으니까 굳이 테스트 해보지 않으셔도 된다. ‘ㅅ’a

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

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

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

2020-12-24_135314

보이는가 선조의 지혜가 -3-)b

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

 

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

2020-12-28_090732

 

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

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

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

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

PS. 물론 색인(index) 는 이런 구조가 아닌 hash 처리에 따른 협차법 으로 찾아서 빨리 찾을 수 있어 차이가 있다.

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

 

적당한 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.0912US$ 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 에서의 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
3000 IOPS
125 MiB
23.8 MB/s149 MB/scached: 187.18 MB/sec
disk: 166.64 MB/sec
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
3000 IOPS
250 MiB
23.0 MB/s347 MB/scached: 375.04 MB/sec
disk: 333.47 MB/sec
1024GBgp2
IOPS 3072
250MiB (추정)
30.9 MB/s345 MB/scached: 374.96 MB/sec
disk: 333.50 MB/sec
gp3
3000 IOPS
125 MiB
20.6 MB/s149 MB/scached: 187.51 MB/sec
disk: 166.63 MB/sec
2048GBgp2
IOPS 6144
250MiB (추정)
28.0 MB/s347 MB/scached: 375.04 MB/sec
disk: 333.22 MB/sec
gp3
3000 IOPS
125 MiB
23.7 MB/s149 MB/scached: 187.50 MB/sec
disk: 166.63 MB/sec

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

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


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

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