태그 Archives: apache

OCI arm 인스턴스에서 docker로 web, was 사용

OCI 에서 제공되는 무료 서버를 이용하여 nginx(x86) – was(arm64) – DB(arm64) 으로 잘 사용하고 있었다.

기존엔 snapd(certbot) 도 arm64에서 정상 동작지 않았고 http3를 구현한 nginx도 베타 였으나 현재는 mainline-quic 으로 되었기 때문에 native-arm64 환경으로 이행을 통해 메모리가 적어서 상대적으로 속도가 느렸던 x86서버를 버리기 위해서 아래와 같은 목표를 구현하는 것을 목표로 잡았다.

1. Docker – rockylinux9 – nginx-quic(http3) 구축

2. Docker – Was(http,php-fpm) 의 OS를 amazonlinux2 -> rockylinux9 으로 변경 하여 php-8.3 사용

 

베이스 OS는 rockylinux 8(arm64) 이며, 먼저 arm 서버에 docker, memcached 를 설치하고 활성화 한다.
php-fpm에서 세션 저장 위치로 호스트OS에 memcached(:11211)를 사용한다.

 

Was 컨테이너 안에서 웹서비스가 apache:apache 권한 으로 동작 되기 때문에 아래와 같이 베이스 os에 같은 권한을 생성하여 웹동작 과 웹서비스 폴더및 파일의 소유권을 일치화 한다.

 

파이어월 설정을 해서 memcache 와 was 포트를 허용한다.

 

https://hub.docker.com/r/san0123/rocky9-arm64-http-php

도커는 pull 을 별도로 하지 않더라도 정확한 주소를 사용할 경우 자동으로 pull 하는 기능이 있으므로 바로 run 을 실행 한다. nginx 가 80,443 을 사용할 예정이기 때문에 9000번 포트를 이용해 run 한다.

 


Nginx 용 도커를 띄우기 위해 아래와 같이 방화벽 설정을 한다.

 

웹용 도커는 베이스os에서 virtualhost 설정파일을 수정 하고 docker를 재실행 하기 위해 먼저 해당 파일을 생성해 둬야 한다.

 

https://hub.docker.com/r/san0123/rocky9-arm64-nginx

Nginx용 도커를 실행 한다.
컨테이너를 재 생성 할때마다 인증서나 가상호스트 파일을 수정하지 않도록 두개의 마운트 포인트를 추가해서 실행한다.

 

Let‘s encrypt 를 생성하는 명령어는 다음과 같다.

 

이후 베이스OS 에서 /var/www/conf/virtual.conf 를 자신의 url에 맞게 수정하고 발급된 인증서가 동작할 수 있도록 아래와 같이 수정을 한다.

 

이후 nginx를 재시작 하기 위해 컨테이너를 재시작 한다.

 

http3가 잘 활성화 되어있는지 확인 한다. ( https://http3check.net/ )

2024-04-27 17 14 57

 

인증서가 약 2-3개월 마다 갱신해야 하기 때문에 cronatb에 아래와 같이 등록해서 주기적인 인증서 업데이트 및 적용을 위한 재시작을 한다. (매주 월요일 오전 8시)

 

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. 이건 저도 어려 웠어요…..

TLS 1.3 활성화 (apache, nginx)

RFC 8446 이 발표 되고 TLS 1.3 의 표준이 제정 되었다. (https://tools.ietf.org/html/rfc8446)

아래의 조건을 만족하는 경우 TLS v1.3 를 사용할 수 있다.

openssl 1.1.1 이상 / nginx 1.13.0 이상 / apache 2.4.37 이상

 

openssl 이 웹서버 데몬(apache,nginx) 에 의존성이 있으므로 openssl 을 업데이트 하고 웹서버를 재설치 해야 하는 경우가 발생할 수 있다.

 

nginx.conf 에서의 SSL 관련 설정 방법

 

apache 의 SSL 설정 방법

 

2019-01-08_113231_001

 

브라우저 호환성 (https://caniuse.com/#feat=tls1-3)

TLS v1.3 이 나왔다고 TLS v1.2 끌 경우 많은 브라우져가 접속하지 못한다.

현재 TLS v.1.3을 지원하는 브라우져는 FireFox, Chrome, Safari, Opera, IOS Safari, Chrome for Android, FireFox for Android 정도 이다.

Let’s enctypt 를 의 발급/갱신을 단순화 하기 위한 방법

Let’s encrypt 는 발급/갱신을 할때 http://도메인/.well-known/acme-challenge/xxxxxxxxxxxxxxxxxxxxxxxxx 를 호출 한뒤 호출에 성공한경우 도메인 소유권이 있는것으로 판단하여 발급/갱신이 이루어 진다.

다만 이경우 .htaccess 를 쓰는 워드프레스 라던가 XE 라던가 혹은 개인 설정에 의해 .htaccess 에서 리다이렉트 운용을 할 경우 발급/갱신이 어려워 질 수 있다.

 

때문에 아래와 같이 apache 의 Alias 설정 해서 좀더 효율적인 인증을 할 수 있다.

 

위 설정을 하고 난뒤에 발급 명령어는 아래와 같다.

webroot를 /var/www/html 에 고정을 하고  6번째 줄만 맞게 수정을 해서 사용하면 됩니다 ‘ㅅ’b

 

/var/www 폴더는 selinux 에서 파일컨텍스트가 허용된 폴더로 selinux 를 사용하더라도 별도의 허용처리를 할 필요가 없어서 좋음 🙂

mod_pagespeed with apache 2.4.x

구글이 공개한 mod_pagespeed를 컴파일된  apache 2.4 에 설치하는 방법을 설명 한다.
구글의 경우 nginx 의 경우 컴파일 버전을 apache 버전은 rpm 버전으로 제공 하고 있으며
일반적으로 yum 설치되어 /etc/http 안에 위치한경우 rpm 설치만으로 활성화가 가능 하다.

 

다만 컴파일을 해서 prefix 가 다른곳에 있을경우 rpm을 설치한다면 dependency 때문에 yum 으로 httpd 가 설치되어 시스템이 꼬이게 되므로 설치할 수 없는게 일반적인 상식 ‘ㅅ’..

하지만 yum 으로 설치가능한 httpd 의 경우 버전이 매우 낮아 새로운 기술을 전혀 활용하지 못한다… SNI 라던가 HTTP/2 라던가..
때문에 구글이 배포한 rpm을 분해하여 서버에 맞게 편집한뒤에 적용을 한다 ‘ㅅ’b
1. mod_pagespeed 배포 는 https://developers.google.com/speed/pagespeed/module 에서 다운받아서 rpm2cpio 명령어를 이용해 rpm을 분해 한다.

 

2. 압축해제된 파일을 경로에 맞게 수정 이동 시킨다 ‘ㅅ’a  ( 예제 에서 컴파일된 위치는 /usr/local/apache 이다. )

 

3. httpd.conf 에서 pagespeed.conf 파일을 불러오도록 설정 한다.

 

4. 아래는 개인적으로 편집한 pagespeed.conf 파일이다 ‘ㅅ’a

memcache 를 쓴다면 중간에 주석처리된 ModPagespeedMemcached 관련 옵션을 활성화 한다. ‘ㅅ’a

 

외부에서 js 를 가져오는 부분의 속도가 빨라지기 때문에 js를 많이 쓰는 복잡하고 느린 사이트일수록 사이트 가속된것을 체감할수 있는것으로 확인됨 ‘ㅅ’b
그리고 또 js minify 기능이 있기 때문에 별도로 개발자가 신경을 쓰지 않아도 되기 때문에 매우 편한 mod 인듯…

설치를 추천합니다 ‘ㅅ’ b

간혹 캐시 적용으로 사이트가 특정 경로상에 문제가 발생하는 경우 아래와 같이 특정 경로에서 기능을 끄거나
사이트 전제 pagespeed 적용을 해제 할 수 있다.