여기서 소개해는 코드 스니핏(code snippet)은 아파치에서 사용하는 형식과 닮아 있습니다.
css, gif, ico, jpeg, js, png, woff, woff2, ttf, ttc, otf, eot 형식을 제어 허용된 리퍼러가 아니면 403에러를 내라고 설계
첫번째 룰은 블랭크 리퍼러를 허용 일부 사용자는 웹 브라우저가 보내는 페이지 레퍼러 정보를 삭제하는 방화벽 설정 또는 바이러스 백신 프로그램을 사용하기 때문에 이 옵션을 추가할 필요가 있음 이를 허용하지 않으면 해당 사용자에게는 모든 이미지가 보여지지 않게 될 수 있음
두번째 룰은 자기 사이트 도메인 하위 부분 허용 세번째 룰은 자기 사이트 도엠인
네번째부터는 구글을 비롯한 사이트와 구글봇 등을 지정
맨 마지막에는 첫번째 룰부터 마직막 룰까지 적용한다는 것 명시
location ~* \.(css|gif|ico|jpeg|jpg|js|png|woff|woff2|ttf|ttc|otf|eot)$ {
if ($http_referer !~ "^$"){
set $rule_0 1$rule_0;
}
if ($http_referer !~ "^http://mysite.com/.*$"){
set $rule_0 2$rule_0;
}
if ($http_referer !~ "^http://mysite.com$"){
set $rule_0 3$rule_0;
}
if ($http_referer !~* "google."){
set $rule_0 4$rule_0;
}
if ($http_referer !~* "search?q=cache"){
set $rule_0 5$rule_0;
}
if ($http_referer !~* "msn."){
set $rule_0 6$rule_0;
}
if ($http_referer !~* "yahoo."){
set $rule_0 7$rule_0;
}
if ($http_user_agent !~* "googlebot"){
set $rule_0 8$rule_0;
}
if ($http_user_agent !~* "msnbot"){
set $rule_0 9$rule_0;
}
if ($http_user_agent !~* "slurp"){
set $rule_0 10$rule_0;
}
if ($rule_0 = "10987654321"){
return403;
break;
}
}Code language:PHP(php)
valid_referers 활용 NGINX 핫링크 방지 방안
허용된 리퍼러만 이미지 등 콘텐츠 링크를 허용하는 방안에 대해서는 거의 표준화된 방법인데요.
인터넷 검색하면 기본적으로 이 방법을 소개하고 있습니다. 그만큼 많이 사용되고 사용에도 편하다는 것이겠죠.
이 방법에 대한 수많은 설명이 많이 있지만 “NGINX 이미지 외부 링크 막기 설정 방법”에서 비교적 자세하게 설명되어 있기 때문에 이 글을 기반으로 (일부 먹히지 않는 부분은) 수정 설명해 봤습니다.
NGINX에서 이미지 핫링크 방지는 server 블럭 안의 위치하는 location에서 확장자를 지정, 해당 확장자 파일들은 valid_referers에서 요청하는 경우에만 제대로 보여주고 그 외 리퍼러 요청은 403에러 처리하는 하도록 합니다.
($host)으로 해당 사이트가 반영되도록
~.domain. 형식으로 이미지를 보여줘도 되는 사이트 지정 도메인 지정 와이드카드는 오직 *만 제대로 작동하는 것 같음 도메인 지정은 *.google.com 같은 포맷만 제대로 작동하고, ~.google.과 같은 방식은 작동하지 않음
이미지 요청이 올 경우 보여줄 이미지를 설정하든지 아니면 403 에러 메세지 보여주기 결정 . rewrite (.*)$ /custom/403_forbidden.png redirect; . return 403;
어디에서 핫링크를 요청하는지 로그에서 기록 access_log /var/log/nginx/hotlink-access.log;
저의 경우는 이미 jpg나 png 파일에 대해서는 webp 파일로 대체하하는 location 명령을 적용하고 있었습니다.
그런 상태에서 뒷부분에 아미지 파일에 대해서 location 블럭을 추가하고valid_referers 명령을 사용하지 제대로 작동하지 않았습니다.
그래서 webp를 적용한 jpg나 png 이미지 파일에 대해서는 webp 적용 명령과 valid_referers 적용 명령을 사용하고, 이어 나머지 이미지 파일 및 기타 파일 포맷에 대해서는 별도 location 블럭을 만들고 valid_referers 명령만을 적용했습니다.
SEO 전설 중의 한명인 랜드 피쉬킨(Rand Fishkin)의 유명한 SEO 강의를 SEO 공부하던 차에 발견했습니다. 무료 SEO 강의라고 무시할 게 아니라 나름 깊이도 있기 때문에 공부겸 해서 여기에 MOZ가 제공하는 무료 SEO 강의를 공유해 봅니다.
여기 소개하는 The One-Hour Guide to SEO는 MOZ의 SEO 강의 중 하나로 MOZ의 콘텐츠를 시험적으로 청취해보고 나머지 강의도 들어보라는 의미에서 무료로 공개하고 있는 자료입니다. 이는 아래처럼 6개 주제에 대해서 약 15분 정도씩 설명하고 있습니다.
이 SEO 강의는 랜드 피쉬킨(Rand Fishkin)이 매주 금요일마다 SEO 관련 소주제를 기반의 강의했던 whiteboard friday 강의 중 하나라고 합니다. 이러한 금요일마다 진행되는 SEO 강의는 그가 복귀하면서 다시 시작한다고 하네요.
이 무료 SEO 강의에는 아래와 같은 6가지 주레를 다루고 있습니다.
SEO Strategy
Keyword Research
Searcher Satisfaction
On-page Optimization
Technical SEO
Link Building – Ready to dive in?
여기서 시원스럽게 강의하고 있는 랜드 피쉬킨(Rand Fishkin)는 MOZ에서 SEO 강의로 명성을 날리다 잠시 다른 일을 하느라 MOZ를 떠났다가 최근 다시 복귀했다고 합니다.
그는 이번에 복귀해서 시리즈별로 10분 씩 1시간에 걸쳐 SEO 기봉에 대한 강의한다고 해서 기대를 모으고 있습니다.
사이트 운영 시 필히 만날 수 밖에 없는 이미지 도용 핫링크를 방지해 트래픽을 안정적으로 유지하고, 서버 자원을 효율적으로 이용하는 워드프레스 핫링크 방지 방법에 대해서 알아봅니다.
오늘 서버 문제가 있어서 이런 저런 log 파일들을 살펴보다가 생각보다 많은 이미지와 폰트들이 다른 사이트에 핫링크되어 사용되고 있다는 것을 발견했습니다.
나름 서버단에서 이미지 핫링크에 대한 대비를 했다고 생각했는데 뭔가 문제가 있는지 이미지 핫링크 방지가 제대로 작동하지 않는 것 같았습니다. 어쩌면 제가 적용했던 코드가 완전하지 않았을 수 있을 것입니다.
그래서 다시 한번 이미지 핫링크 방지 방법에 대해서 살펴봤습니다.
이미지 핫링크(Image hotlink)란?
핫링크란 이미지나 동영상과 같은 콘텐츠를 보여줄 때, 이 콘텐츠 소스가 해당 사이트에서 제공하는 것이 아니라 다른 사이트의 이미지나 동영상을 가져다 보여주는 것을 말합니다.
우리 말로 이야기하면 이미지 무단 도용이라고도 할 수 있습니다. 대개 해당 사이트 주인장의 허락없이 이미지나 동영상 링크를 그대로 사용해기 때문에 여러가지 문제를 일으킵니다.
핫링크로 인해서 오리지널 사이트 소유자에게 비용이 발생합니다. 아시다시피 사이트 운영이 공짜가 아니기 때문에 해당 사이트를 운영하기 위해서는 서버와 같은 물리적 하드웨어 사용 비용과 인터넷으로 데이타를 보내고 받는 트래픽에 대한 비용이 발생합니다. 핫링크 규모가 커지면 사이트 운영자는 추가로 비용을 내야하는 문제가 발생합니다.
대부분 핫링트는 불법입니다. 어쩌면 많은 사람들이 인식하지믄 못하지만 웹 이미지에는 라이센스 제한이 걸려 있기 때문에 이러한 핫링크로 불법 상태가 되어 버립니다. . “귀하가 소유한 사이트 또는 블로그에서만 사용”한다는 라이센스 규정에 위반
핫링크가 증가하면 해당 서버 자원이 금방 고갈될 수 있습니다. . 핫링크가 걸려 갑자기 트래픽이 증가되는 경우 평소의 몇백만배 이상의 서버 리퀘스트(요청)가 발생하면서 CPU등 사용 자원 여분이 줄어들고 . 심지어는 공동으로 자원을 하용하는 호스팅에서는 해당 계정을 정지해 버릴 수 있습니다.
일반적으로 핫링트를 사용하는 사람들은 핫링크 행위가 문제가 된다는 의식이 별로 없는 경우가 많습니다. . 그러나 위에서 지적하다시피 불법이고, 해당 사이트 운영을 어렵게 만들기 때문에 사용해서는 안됩니다.
이번에 운영 서버를 우분투 20.04에 PHP 8을 적용해 업그레이드 하면서 MySql 최적화 DB 설정 시 검토했던 내용을 여기에 정리해 봅니다.
여기는 워드프레스 사이트를 운영하기 위한 작은 사이트 기준이므로 이를 감안해 주시구요. DB 크기가 1G정도로 사이즈를 기준으로 했습니다. 이는 블로그 글 3~4,000개 정도 되는 사이트에 해당합니다.
MySql 최적화, Basic Settings
Basic Settings에서 생각해 볼 것은 tmpdir을 어디에 둘 것인지 여부입니다. 기본으로는 하드디스크인 /tmp에 설정되어 있습니다. 전체 세팅을 잘 변경해 보아도 임시 테이블이 하드디스크에 생성되는 것을 막을 수는 없던데, 메모리 여유가 있다면 램에 tmpdir을 지정하는 것이 좋을 것 같습니다.
여러 번 시행 착오 끝에 리눅스 tmpfs 파일시스템은 일부 임시 파일생성을 허용하지 않기 때문에 에러가 발생하다는 사실을 확인하고 임시 파일 폴더를 메모리에 올리는 것을 포기 했습니다. 제가 받은 에러 메세지는 리눅스 커널에서 MariDB가 tmpfs 파일시스템에서 일부 임시 파일 생성하는 것을 허용하지 않아 에러가 발생, mariadbd: O_TMPFILE is not supported on /dev/shm (disabling future attempts). .
skip-external-locking 항목이 있는데, 이는 MySQL 4.0 이후에는, 모든 시스템에서 외부 잠금을 비활성화 하는 것이 디폴트로 외부 잠금을 사용하지 말라고 권고 되고 있습니다. .
skip-name-resolve Mysql 서버가 외부로부터 접속 요청을 받으면 인증을 위해 ip 주소를 호스트 네임으로 변경하면서 불필요한 부하가 발생할 수 있으므로 skip-name-resolve를 설정하면 접속 시 IP 기반으로 접속을 하게 되어 hostname lookup 과정 생략되어 좀 더 빠르게 접속 가능하다고 합니다.
max_connection : 최대 동시 접속자 수, 늘어나면 날수록 메모리가 고갈되고 스케줄링 오버헤드도 증가 이전 최대 접속자 수의 2배 정도 잡는다.
connect_timeout : mysqld 서버가 패킷과 연결하기 위해서 대기하는 시간 기본값은 10초
wait_timeout : 서버가 데이타 패킷과 연결된 후 연결을 유지하는 시간 . 기본값은 28800초(8시간) . DB 서버 접속이 많다면 wait_timeout을 최대한 적게 (20~30 정도를 추천) 설정하여 불필요한 연결을 빨리 정리 필요. 그러나 Connection Miss Rate(%)가 1% 이상이 된다면 wait_timeout 을 좀 더 길게 가져야 함.
max_allowed_packet : 허용 패킷 크기 . 기본값 16MB이며 최대값은 1GB, . MySQL 서버가 잘못된, 너무 큰 패킷을 제어하는 데는 도움이 되지만 규모 이상으로 큰 패킷을 수신하면 문제가 있다고 판단해 연결을 끊어 버리기 때문에 이를 피하려면 값을 새로 설정하고 mysql을 다시 시작해야 함
thread_cache_size : . 기본값 8 . Cache Miss Rate(%)가 높다면 기본값보다 높게 잡는다
sort_buffer_size . 리눅스에는 256K 또는 2MB라는 임계점이 존재하는데 이 이상의 값은 메모리 할당이 크게 느려질 수 있으므로 이보다 낮은 값을 사용하는 것으로 고려
join_buffer_size . MySqlTunner에서는 최소 1MB이상으로 제안
tmp_table_size . group by 시 디스크를 사용하지 않고 임시 테이블을 만들기 위해 사용하는 메모리 크기
max_heap_table_size . 내부 메모리 임시 테이블이 너무 커지면(tmp_table_size와 max_heap_table_size 를 넘어서는 경우) 자동으로 테이블을 메모리에서 디스크 내 형식으로 변환
default_storage_engine = InnoDB 기본 데이타베이스 엔진으로 InnoDB를 사용한다는 것 표시
innodb_buffer_pool_size . 운영중인 시스템의 DB 크기 이상을 할당 (저의 경우 DB 크기가 970MB였기 때문에 1GB를 설정 . 시스템 메모리의 65%~75% 권장, 시스템 메모리 8GB RAM라면 일반적으로 5~6GB 정도 할당 . buffer pool이 너무 작으면 페이지가 buffer pool에서 플러시 되어 잠시 후 다시 필요하게 되므로 과도한 I/O 가 발생할 수 있으며, 너무 큰 경우 메모리 경쟁으로 스와핑이 발생할 수 있음
innodb_log_file_size . 데이타베이스 충돌 발생 시 다시 실행하거나 이전으로 되돌릴 때 사용하는 메모리 . 지나치게 크면 복구 시간이 길어지면서 비효율적이 될 수 있음 . 위에서 설정한 innodb_buffer_pool_size의 25% 정도 할당
innodb_buffer_pool_instances . 인스턴스 수를 늘리면 트랜잭션 간 Lock 경합을 줄일 수 있음 . 기본값은 8 . 메모리가 많은 시스템에서는 buffer pool을 여러 개 buffer pool instance로 나누어 동시성을 향상 시키는 것이 가능
innodb_flush_log_at_trx_commit . 0은 성능 중심, 1은 안정성 중심
innodb_flush_method . O_DIRECT – 데이터 읽기/쓰기에 OS 캐시를 사용하지 않다 바로 MySql/MariaDB에서 가져 오겠다는 설정 쓰기 성능은 나빠질 수 있지만 더블 버퍼링을 막아 메모리를 효율적으로 사용하겠다는 것 . O_DSYNC – 데이터 읽기/쓰기에 OS 캐시를 사용 속도는 더 빠르지만 대기 시간, 충돌로 데이타가 일관적이지 않을 수 있다고 함
innodb_io_capacity . InnoDB 변경 성능은 플러쉬 속도, 즉 스토리지 I/O 속도에 의존하므로 빠른 스토리지 사용 필요 . 현재 사용하고 있는 디스크의 IOPS와 유사한 값 설정 . SSD와 같이 속도가 빠른 스토리지는 값을 올리고, 일반 HDD라면 값을 내린다.
table_definition_cache . 테이블 오픈 속도를 향상 시키기 위한 캐시 수
table_open_cache . 각 쓰레드별 오픈할 테이블 수 . 기본 값은 2000 . max_connection * N개가 되어야 함 여기서 N은 실행하는 쿼리에서 조인 당 최대 테이블 수 . MySql에서 show global status like ‘%table_open_cache%’ ; 명령 결과에서 miss가 있다면 늘려 봄
open_files_limit . table_open_cache 값의 2배 또는 3배 . file-max 값은 리눅스에서 한 번에 운용할 수 있는 파일 수를 의미하며, 보통 4MB 메모리 당 256개의 파일을 운용할 수 있다고 한다. 대략 1G -> 65536개, 2G -> 131072 개
query_cache_size . 쿼리 결과를 캐싱하기 위해서 할당된 메모리 크기 . query_cache_size가 너무 크다면 갑자기 엄청난 쓰기 작업이 발생 시 서버는 바로 쿼리 작업을 하는 대신 cache를 찾아 작동하는데 집중해 오히려 속도가 느려짐 . 시스템에서 사용하지 말라고 권고
binlog_cache_size . 이 값은 버퍼 명령문에 할당되어, 명령문이 이 값보다 크면 쓰레드는 트랜젝션을 저장하기 위해 임시 파일을 사용
binlog_cache_use 상태 변수는 명령문을 저장하기 위한 용도로 이 버퍼(또는 임시 파일)를 사용한 트랜젝션 숫자를 의미하며, binlog_cache_disk_use 상태 변수는 이 임시 파일을 실제로 사용한 트랜젝션의 숫자를 표시 . 이 두 가지 변수를 이용해 임시 파일 사용을 피하기 위한 binlog_cache_size를 튜닝하는 데 사용
general_log / slow_query_log . 로그 활성화 시 1, 비활성 시 0 사용
long_query_time . 이 변수 값보다 쿼리 처리가 길게 걸리면 에러 로그에 기록
근래 사이트 운영 환경이 급격하게 변동되면서 우분투 20.0와 PHP 8 등 최신 버전을 적용 가상 서버 설치 및 워드프레스 설치 가이드를 재 작성해 기존 정보들을 업데이트할 필요가 있었습니다.
오래 전부터 우분투와 PHP를 적용한 서버 설치 및 이 서버에서 워드프레스 설치 및 워드프레스 운영 가이드를 작성해 공유해 왔습니다. 그렇지만 시간이 흐르면서 이 사이트에서 제공하는 정보가 낡았다는 지적이 있기도 했습니다. 그럼에도 정보가 유용하다는 병주고 약주는 그런 평가도 있기도 했습니다.
그래서 이번 PHP 8 출시 및 이에 맞춘 워드프레스 5.6버전이 나왔기 때문에 이를 모두 반영한 설치 가이드를 정리해 보기로 했습니다.
여기 설치 가이드에서는 2020년에 출시한 운영체제 20.04 LTS와 PHP 8 그리고 MariaDB 10.5를 반영했습니다. 그리고 그 동안 업데이트 된 보안 관련 내용도 반영하였습니다.
1. 운영체제 우분투 20.04을 선택하다.
리눅스를 기반 운영체제 중에서 우분투가 상대적으로 업그레이드가 빠르다는 평이 많기 때문에 선택했습니다.
새로운 리눅스 버전이 나오면 각 운영체제들은 그들이 가진 비즈니스 전략과 운영 전략에 따라 적절한 시기에 업데이트를 진행하는데요.
우분투는 상대적으로 이런 업데이트가 빠르기에 바로 사용하고 싶은 욕구가 크기 때문에 선택 했습니다. 그리고 가장 많은 사용자는 아니지만 상대적으로 많은 사용자가 있어 관련 정보 획득에 용이하다는 점도 고려했습니다.
1.1. 20.04는 18년 4월 버전이라는 의미이다.
우분투 버전은 출시한 연도와 월에서 따옵니다. 만약 우분투 24.08이 있다면 이는 2024년 8월에 출시한 버젼입니다.
마찬가지로 최근에 출시된 우분투 20.10은 2020년 10월에 출시한 우분투 버전을 의미합니다.
1.2. 우분투 20.04는 LTS 버전이다.
우분투의 탄생 배경은 기존 데비안의 업데이트가 너무 느리기 때문에 이에 불만을 품고 우분투가 시작되었기 때문에 업데이트가 잦은 편이며 이에 따라 잦은 판올림이 이루어 집니다.
그런데 우분투 버젼이 빠르게 변하기 때문에 지원 기간이 짧아질 수 밖에 없습니다.
우분투 자체로 어떤 비즈니스 모델을 만들고 이를 통해서 떼돈을 버는 것이 아닌 비영리기관에서 운영하는 것이기 때문에 버젼별로 무한정 지원할 수 없기때문에 짧을 수 밖에 없습니다. 최근에는 평균 지원기간이 9개월 정도로 짧습니다.
그런데 서버 운영 입장에서는 그렇게 자주 서버 운영체제를 업그레이드 할 수 없습니다. 대규모 사이트에서는 업그레이드하려면 챙겨야 하는 점들이 많을 수 밖에 없기 때문에 조금만 잘못해도 커다란 비즈니스 손실을 봐야 하기 때문에 조심스러울 수밖에 없습니다.
그렇게 때문에 우분투에서는 기업용으로 5년동안 지원하는 LTS(Long Term Support) 버젼을 출시합니다. 이 LTS 버젼은 짝수년도 4월에 출시합니다.
현재 사용 가능한 LTS 버전은 16.04, 18.04 그리고 20.04가 있습니다.
1.3. 버전명과 코드네임이 다 활용된다.
일반적인 프로젝트에서 코드네임은 프로젝트가 끝나면 사용되지 않죠.
그렇지만 우분투에서 코드네임은 패키지 저장소나 관련 앱 버젼 관리 시 사용되므로 서버를 관리하려면 버젼명과 코드네임을 알고 있어야 합니다.
지금 현재 설치 가능한 버젼은 16.04, 18.04, 20.04, 20.10이 있는데 이들의 코드 네임은 아래와 같습니다.
16.04 : Xenial Xerus
18.04 : Bionic Beaver
20.04 : Focal Fossa
20.10 : Groovy Gorilla
2. Vultr에서 우분투 20.04 설치 준비
여기에서는 Vultr에서 서버 설치를 위해 서버 위치, 서버 종류, 운영체제 선택, 운영 플랜 등 기본적인 사항을 선택하는 방법을 소개합니다.
Vultr를 사용하지 않고 다른 회사를 선택한다면 넘어가 주세요.
Vultr에서는 개개의 서버를 Instance라고 부릅니다. 서버 세팅, Vultr에서 이야기하는 Deploy New Instance 화면의 Vultr Cloud Compute(VC2)화면에서 세팅을 시작할 수 있습니다.
아래는 간단히 서버 세팅 과정을 보여주고 있습니다.
2.0. 서버 종류 선택
예전 Vultr 서버 종류는 그리 복잡하지는 않았지만 지금은 High Frequency가 추가되어 Cloud Compute, High Frequency, Bere Metal, Dedicated Cloud의 4가지 종류를 선택할 수 있습니다.
우리가 가장 일반적으로 저렴한 버전은 Cloud Compute이구요.
이보다 더 나은 CPU와 NVme라는 고성는 디스크를 사용해 성능을 높인 High Frequency를 선택할 수 있습니다. 다면 가격이 20% 더 비쌉니다.
독립형 서버를 사용하고 싶다면 Dedicated Cloud를 선택할 수 있지만 지원 지역이 많지는 않습니다. 당근 가격도 비싸겠죠.
2.1. 서버 위치 선택
서버 위치는 2020년 12월 6일 현재 18년 1월 현재 글로벌로 17군데가 있는데요. 아시아권에는 서울, 일본 도쿄 그리고 싱가폴에 있습니다.
주요 비즈니스 영역이 한국이라면 당연 서울을 선택하면 될 것 같습니다. 그렇지만 한국과 북미를 비슷한 비중으로 운영한다면 LA 지역도 좋을 것 같습니다.
▽ 서버 위치를 설정 장면
2.2. 서버 운영 체제
이번에는 서버 운영 체제를 선택합니다. 서버를 선택, 설치하는 데에는 여러가지 방법이 있는데요. 아래를 보시면 알겠지만 굉장히 다양한 방법을 제공하고 있습니다.
2.2.1. Vultr에서 제공하는 서버 운영 체제 설치 방법
첫째, 일반 프로그램 설치하듯이 자신에게 맞는 운영 체제를 선택해 설치하고, 이어서 필요한 프로그램을 설치하는 방식
둘째, Application이라고 해서 운영체제 + 제반 프로그램을 일괄 설치하는 방법
셋째, 다른 곳에서 만들어 놓은 ISO 파일을 업로드해서 그대로 사용하는 방법
넷째, Vultr에서 제공하는 ISO 파일을 그대로 사용하는 방법
다섯째, 이미 Vultr을 이용하는 상태라면 유료로 백업 서비스를 받고 있다면 이 백업 파일로부터 서버를 생성하는 방법
여섯째, 이미 Vultr을 이용하는 상태라면 기존에 만들어 놓은 Snapshot으로 그대로 서버를 떠주는 방법
Application 설치 방식은 운영 체제과 관련 프로그램을 한꺼번에 설치해주므로 편하긴 하지만 원하는 프로그램을 선택할 수 없고 최신 프로그램은 지원하지 않은 경우가 많습니다.
예를 들어 20년 12월 현재 wordpress 설치 Application은 우분투 18.04를 설치하도록 되어 있습니다. 센토스를 선택하거나 우분투(Ubuntu) 최신 버젼, 20.04 또는 20.10를 선택하고 싶다면 사용할 수 없지요.
전문가라면 다른 곳에서 만들어 놓은(제대로 잘 세팅된) ISO를 업로드 하는 것도 괜찮을 겁니다. 그렇지만 초심자에게는 너무 먼 이야기이지요.
Vuktr에서 제공하는 ISO는 일반 프로그램 설치와 거의 같은 방식입니다.
따라서 저는 일반 프로그램처럼 설치하는 첫번째 방식을 사용했습니다.
2.2.2. 32비트? 64비트?
윈도우즈도 32비트 64비트가 있듯이 리눅스계열도 32비트와 64비트로 나누어져 있습니다. 그래서 64비트를 설치할 것 인지, 32비트를 설치할 것 인지를 선택해야 합니다.
일반적으로 RAM이 512MB, 765MB 적을 경우 32비트를 설치하는 게 좋다고 하네요. 32비트가 최소 메모리를 사용하기 때문이라고 합니다.
그리고 최소 1GB정도 되어야 64비트가 아주 원활합니다. 실제로 워드프레스 등 운영 시 최소 메모리를 1GB로 권장하고 있습니다.
2.2.3. 어떤 운영 체제, 어떤 버전을 선택할 것인가?
운영체제를 무엇으로 할 것 인지도 고민인데요. 센토스나 우분투등이 일반적으로 많이 사용되므로 둘 중 하나를 고르면 됩니다. 저는 최근 뜨고 있다는 우분투를 선택했습니다.
우분투 버전을 선택해야하는데, 우분투는 16.04, 18.04 그리고 20.04 버젼이 출시 후 5년동안 지원하는 LTS 버젼이므로 가능하면 이를 선택하라고 조언하고 있습니다. 이외에 가장 최근에 나온 20.10을 사용해 볼 수 있습니다.
버젼별로 새로운 기능이 추가되기는 했지만 성능에 큰 영향을 미치지는 않은 것 같습니다. 최신이면서 오랬동안 지원되는 LTS 버젼을 사용하면 될 듯 합니다.
이 글을 업데이튼 하는 20년 12월 현재 저는 20.04 버전을 적용하고 하고 있습니다. Vultr는 항상 최신 버전을 설치할 수 있도록 빠르게 대응하고 있습니다. 국내 서버 업체들을 보면 대부분 최신 버전 지원 시기는 출시 한참 시간이 지낭 후 지원하는 것 같습니다.
최신 버전에 민감하고 이를 빨리 테스트해보고 싶다면 그런 의미에서 Vultr도 좋은 대안이 될 듯 하네요.
서버 운영체제로 우분투 버전 선택 모습
서버 운영체제를 어플리케이션과 함께 선택
▽ 서버 타입 선정 화면 – Application을 중심으로 선택, 설치 할 수 있다.▽ 서버 타입 선정 화면 – Vultr에서 제공하는 ISO List에서 선택, 설치할 수 있다.
2.3. 플랜 결정 – 서버 크기
이 단계에서는 가장 중요한 가격대를 선택해야 합니다. 국내의 많은 웹호스팅과 마찬가지로 상위 플랜으로 업그레이드는 가능하지만, 다운그레이드는 허용하지 않기 때문에 처음에는 당장 사용할 수준 정도로 시작하고 점차 업그레이들 하면 좋습니다.
나중에 다시 정리하겠지만 상위 플랜으로 업그레이드는 서버를 유지한 채 버튼 하나만 눌러서 몇분 내에 끝납니다. 아주 쉽고 간단합니다.
저는 데이타베이스 크기가 300MB 정도이고 하루 방문객이 5,000명이 안되기 때문에 처음에 5$ 플랜으로 시작했었습니다. 아무래도 워드프레는 램을 비롯한 자원을 많이 사용하는 경향이 있어서 충분한 속도를 내기 위해서 4GB 램과 120GB 스토리지의 월 24$ 플랜으로 업그래이드 하려고 합니다.
▽ 서버 크기를 선정 화면
서버 설치, 가상서버호스팅 vultr 서버 크기, 플랜 선택 장면
2.4. 추가 기능 설정
이어서 추가 기능을 선택할 수 있습니다.
IPv6를 추가할 수 있고(무료)
자동백업 선택(이는 요금 플랜의 20%가 붙습니다. 위에서 5$ 플랜을 선택 시 1$, 10$ 플랜을 선택 시 2$ 등)
DDOS Protection 항목이 있는데 이는 미국 일부 지역만 현재 가능하다고 함
Private Networking 선택, 이는 Vultr에 여러 개 서버를 운영하는 경우 서버별 내부 IP를 할당받아 내부 트랜지션을 할 수 있는 기능
3. 웹서버 보안 기본 설정
위에서 서버가 설치되면 가장 먼저 해야할 것이 바로 웹 서버 보안 설정입니다.
일반적으로 웹 서버 세팅이 끝난 후 보안 설정을 하는 경우가 있는데 그동안에는 무방비 상태이므로 가능하면 SSH에 처음 접속하는 순간부터 바로 보안 설정을 하도록 합니다.
3.1. ssh 포트 변경
일반적으로 ssh포트s는 22번으로 할당됩니다. 그렇기 때문에 너무 잘 알려쟜기 때문에 이를 이용해 공격해오는 경우가 있다고 합니다.
따라서 자기만 아는 포트 번호로 변경 사용하는 게 필요합니다. 이렇게 개인만 아는 포트로 변경하면 서버 공격이 확 줄어듭니다.
특정 서버를 목표로 공략한다면 또 다른 강력한 보안 정책이 더 필요하지만 일반적으로는 22포트를 기반으로 무작위적 공격하는 경우가 많기 때문에 포트 변경 시 상대적으로 공격을 덜 받을 수 있습니다.
22번 포트를 변경하려면 먼저 sshd_config에서 22번대신 사용할 포트 번호로 바꾸어 준다. 즉
/etc/ssh/sshd_config 에서 Port 22 를 찾아서 자기가 사용할 포트 숫자를 기억하기 쉽고 10,000자리이상에서 임의의 숫자를선택한다. 예를 들어 58722, 65322 등등
Port 번호는 1에서 65535 사이의 사용하지 않는 포트를 사용할 수 있습니다. 루트에서만 사용할 수 있는 권한있는 포트 (포트 1-1024)를 선택하는 것이 좋다는 의견이 있습니다만 저의 경우 루트를 10000이상 포트를 사용하는데 별다른 기능 사용 한계를 느낄 수 없었습니다.
그리고 나머지 ip는 모두 사용 중지 시킵니다. 이는 /etc/hosts.deny 파일을 수정합니다.
nano /etc/hosts.denyCode language:PHP(php)
여기에서 ALL을 추가합니다. 허용된 ip외는 모두 거부하라는 명령으로 아주 강력합니다.
sshd: ALLCode language:PHP(php)
3.3. 특정 사용자만 허용 또는 금지
또 sshd_config 파일에서 특정 사용자를 허용하든지 금지시킬 수 있습니다.
nano /etc/ssh/sshd_configCode language:PHP(php)
이 파일에서 아래처럼 AllowUsers 다음에 허용할 사용자를 추가합니다. 예를 들면 daisy 사용자만 추가한다면 다음과 같은 명령을 사용합니다.
AllowUsers daisyCode language:PHP(php)
4. 웹서버 보안 설정
여기에서는 웹서버 보안 설정 방법에 대해서 설명합니다.
우분투에서 기본적으로 사용할 수 있는 ufw를 사용할 수 있고 아니면 조금 더 정교하게 보안을 설정하기 위해서는 iptales을 이용할 수도 있습니다.
4.1. 웹서버 보안 ufw 설정
ufw는 우분투에서 제공하는 방화벽 도구로 아래에서 설명하는 iptales를 간단히 사용할 수 있도록 만든 것입니다.
운영체제별로 이와 같은 간단히 편하게 사용할 수 있는 보안 설정 방법을 제공하고 있습니다.
전는 아래에서 사용하는 iptales를 이용하려고 하기 때문에 기본적인 ufw 설명만 소개하고 넘어가도록 하겠습니다.
ufw enable # 방화벽을 활성화한다.
ufw allow 80/tcp # 일반 웹 정보 관련 입출력 통로
ufw allow 443/tcp # SSL 설치 시 웹 정보 관련 입출력 통로
ufw allow 26977/tcp # ssh용 신규 포트 위에서 개인적으로 설정한 포트 번호Code language:PHP(php)
4.2. 우분투에서 IPtables 사용하기
우분투에서는 기본 방화벽으로 UFW(Uncomplicated Firewall)를 사용하고 있습니다. UFW는 아주 간단하고 명료한 방화벽을 구성할 수 있고, 무엇보다도 쉽기 때문에 초보가 사용하기에 좋습니다.
그러나 UFW는 IPtables를 조금 더 편리하게 사용할 수 있도록 만든 것에 불과하므로 조금 더 복잡하고 디테일한 방화벽을 구성하려면 IPtables를 사용하는 것도 좋습니다.
IPtables 사용전에 UFW 사용 중지
처음 서버 세팅 시라면 UFW를 적용하지말고 바로 IPtables을 설치하면됩니다.
그러나 방화벽으로 UFW를 사용하다가 IPtables로 바꾼다면, 우분투 서버에서 Iptables를 설정하기 전에 먼저 UFW를 사용 중지합니다.
UFW 중지 명령은 아래와 같습니다.
ufw disableCode language:PHP(php)
그리고 UFW를 기반으로 설정되어 있는 방화벽 설정을 모두 초기화 시킵니다. 이는 UFW도 IPtables를 기본으로 활용하므로 아래와 같은 명령을 사용합니다.
iptables -FCode language:PHP(php)
IPtables를 안정적으로 사용하기 위한 패키지 설치
IPtables이나 Fail2Ban과 같은 보안 프로그램들은 다시 시작하면 기존 설정이 초기화됩니다. IPtables도 마찬가지로 시스템을 다시 시작한다든지 다시 시작하게되면 설정이 초기화됩니다.
최신 버전의 우분투(Ubuntu)에서 이는 특히 피할 수 없이 나타는 현상이므로 이를 해소할 수 있는 패키지를 설치합니다.
이러한 패키지로 추천되는 것이 바로 iptables-persistent입니다. 여기서는 이를 사용하도록 합니다.
그리고 netfilter-persistent도 같이 설치합니다. netfilter는 IPtabels를 이용하면서도 이를 뛰어넘을 솔류션으로 인기를 끌고 있다고 하네요.
로그를 분석해 의심스러운 접근을 금지시키는 방법이 DenyHosts나 Fail2Ban이라는 프로그램입니다.
이 중 Fail2ban은 DenyHosts보다 훨씬 진보된 방식으로 SSH, Apache, Courier, FTP 등등에서 의심스러운 접근을 차단할 수 있는 프로그램입니다.
Fail2ba은 로그 파일을 모니터링해서 넘 많은 패스워드 입력 실패나 공격 감행 징후들이 보이면 IP를 차단합니다.
예전에도 Fail2Ban을 소개한적이 있지만 오늘은 Fail2Ban을 보다 적극적으로 활용해 서버 보안을 한단계 업그레이드해보도록 하죠.
기본적으로 Fail2Ban 설치를 다시 해보면서 시작하도록 합시다.
apt-get install fail2banCode language:PHP(php)
5.1. Fail2Ban 설정 변경 옵션 설명
그 다음 설정을 변경합니다. 보통 세팅 시 다음과 같은 항목을 중점적으로 설정합니다.
ignoreip : 절대로 믿을 수 있는 white ip 리스트, 예를들어 관리자가 항상 접속하는 ip 등등 이는 123.123.123.123/32와 같은 형태로 적고 스페이스바로 구분
bantime : 접속을 차단할 시간, 기본은 86400초 영구 접속 차단을 원할 경우 -1을 사용 영구 차단 또는 차단 시간을 길게 주면 재부팅시 fail2ban 다시 ip차단 리스트를 읽어오기 때문에 느려질 수 있다고 합니다. 그러나 요즘 서버 컴퓨터 성능도 좋아지고 있으므로 이는 어느정도 감수할 만한 수준으로 보여집니다.
findtime : 통계를 찾을 시간, 기본 10m
maxretry : 허용 fail 횟수, 기본은 5
banaction : ip 차단 방법 이는 /etc/fail2ban/action.d 폴더에 있는 action을 입력할 수 있습니다. firewalld 을 사용한다면 “firewallcmd-new” 값 입력. iptables 을 사용한다면 “iptables-multiport” 값 입력. 기본은 banaction = iptables-multiport로 설정되어 있음
banaction_allports 기본은 iptables-allports
action : 알림 메일등을 받을 것인지 결정 action에 “%(action_mw)s” 값 입력 시 ip차단하면 알림메일이 전송. 알림메일을 받지않으려면 “%(action_)s” 값으로 변경
[sshd] enabled : sshd를 모니터링 할것인지 결정 fail2Ban에서 가장 중요한 설정으로 설치 시 기본 사용토록 되어 있습니다. 우분투에서는 /etc/fail2ban/jail.d 폴더에 있는 defaults-debian.conf에서 설정되어 있습니다.
5.2. 기본 설정 변경 파일
Fail2Ban의 기본 설정 파일은 /etc/fail2ban/jail.conf 입니다.
대부분 여기서 수정해도 문제가 없지만 몇가지 경우에는 업데이트 시 기본 설정 파일이 초기된다고 합니다. 예를 들어 yum을 사용해서 설치한 경우 yum업데이트 시 자동으로 기본 세팅으로 바뀝니다.
이럴경우 기본설정 파일을 직접 수정하지 않고, 기본 설정파일을 참조하여 새로 생성한 사용자 설정파일에서 설정해주는 방법으로 하면 업데이트가 되는 경우에도 사용자 설정 파일을 덮어쓰지 않게 됩니다.
이 파일은 /etc/fail2ban/jail.d 폴더에 위치하게 됩니다. 보통 local.conf라는 이름으로 많이 사용하네요.
Current default time zone: 'Asia/Seoul'
Local time is now: Mon Jun 1821:57:36 KST 2020.
Universal Time is now: Mon Jun 1812:57:36 UTC 2020Code language:PHP(php)
6.4. 메일 발송 프로그램 설치하기
메일을 발송할 수 있는 sendmail 프로그램을 설치, 압축 해제 프로그램 그리고 SSL을 위한 letsencrypt도 같이 설치합니다.
다만 메일발송 프로그램으로 요즘 핫하다는 Postfix를 이용한다면 여기서 설치할 필요는 없습니다.
메일 발송 프로그램은 시간이 조금 걸립니다. 잘못되었나 걱정하지 말고 인내를 가지고 기다리면 됩니다. 그렇다고 몇분이상 걸리는 것을 아닌데 다른 프로그램에 비해서 조금 더 걸립니다.
NGINX를 사용한다면 php handler에서 서버 API를 연결하도록 되어 있는데요. 여기서 php 8로 변경 설정해야 합니다.
nginx에서 변경해야 하는 파일은 /etc/nginx/conf.d/default.conf 인데요.
사람에 따라선 이를 다른 이름으로 사용하는 분도 있습니다. 여러 개의 사이트를 운영하는 경우 사이트명을 변경하는 경우도 있습니다. 저도 이를 happist.com.conf라는 이름으로 사용하고 있습니다.
이 파일에서 fastcgi_pass unix:/run/php/php7.4-fpm.sock; 을 fastcgi_pass unix:/run/php/php8.0-fpm.sock;으로 바꾸어줘야 합니다. 그래야 php8.0을 인식하고 php8.0으로 작동합니다.
# Add PHP handler
location ~ \.php$ {
try_files $uri =404; # comment out this line if php-fpm is hosted on a remote machineinclude /etc/nginx/fastcgi.conf;
fastcgi_cache WORDPRESS;
# add_header X-Cache $upstream_cache_status;# fastcgi_pass unix:/run/php/php7.4-fpm.sock; --> 아래로 변경
<span class="highlight">fastcgi_passunix:/run/php/php8.0-fpm.sock;</span>
fastcgi_no_cache $skip_cache;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return404;
}
}Code language:PHP(php)
이는 매우 중요한 세팅으로 반드시 필요합니다. 우분투 18.04부터는 위치가 조금 바뀌었습니다.
예전에는 my.cnf 파일을 직접 편집하도록 되어 있지만 지금은 mariadb.cnf를 편집하면 my.cnf에 그대로 반영됩니다.
nano /etc/mysql/mariadb.cnfCode language:PHP(php)
아래 내용으로 변경한다.
# MariaDB-specific config file.# Read by /etc/mysql/my.cnf
[client]
Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8mb4
[mysqld]
#
* Character sets
#Default is Latin1, if you need UTF-8 set all this (also in client section)
#
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
character_set_server = utf8mb4
collation_server = utf8mb4_unicode_ciCode language:PHP(php)
변경 내용을 반영해 DB를 다시 시작합니다.
service mysql restartCode language:PHP(php)
9.3. Nginx와 PHP-FPM 연결
nginx는 기본적으로 nginx 사용자 권한으로 실행되고, PHP-FPM 프로그램은 기본적으로 www-data 사용자 권한으로 실행되므로 둘의 사용자 권한을 www-data로 일치시킨다.
nano /etc/nginx/nginx.confCode language:PHP(php)
user nginx; 를 user www-data; 로 변경
worker_processes 1; 를 worker_processes auto; 로 바꾼다. 고사양 서버에서 성능이 더 좋아진다고. 일반적으로 트래픽이 적은면 1을 사용하고 트래픽이 많아지면 auto를 사용한다.
이런 저런 문제를 해결하고자 고민하다 문제 원인을 못 잡으면 다시 설치하고 또 다시 설치하고를 반복하게 되죠.
그런데 Let’s Encrypt SSL인증서는 1주일에 5번까지 발급 받을 수 있도록 제한되어 있습니다. 여러번 시행 착오를 통해서 5번이 넘어서면 아래와 같은 메세지가 나오면서 발급이 안됩니다.
An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains: test.com www.test.comCode language:PHP(php)
이러면 자동으로 디렉토리를 만들게 됩니다. 그리고 나서 NGINX 시스템을 다시 실행합니다. –> 이제 새로운 RAM Disk를 마운트합니다.
service nginx restart
mount -a
df -h # 메모리 및 저장 공간 사용 현황을 보여줍니다. Code language:PHP(php)
참고로 RAM Disk를 없애려면 /etc/fstab에서 Ram 디스크를 지우고, 터미널에서 umount 명령을 사용합니다.
umount /dev/shm/fastcgiCode language:PHP(php)
Object Cache Redis
조금 더 성능을 강화하기 위해서는 Object Cache를 설치하면 도움이 됩니다. 그렇지만 워드프레스에서 이 Object Cache를 할용하려면 별도 플러그인을 사용하라고 하는데요.
이 플러그인들은 워드프레스 업데이타나 PHP 업그레이드 등에서 충돌을 일으키는 경우가 종종 있어 불안정 합니다.
저도 사용하다가 지금은 중단한 상태입니다. 참고로만 보시기 바랍니다. PHP 8.0에서는 에러를 내기 때문에 조금 더 안정화되기를 기다리면 좋을 것 같습니다.
sudo apt install redis-server
sudo service php8.0-fpm restartCode language:PHP(php)
워드프레스에서 이 오브젝트 캐시를 사용하려면 edis Object Cache 플러그인을 사용합니다. Redis Object Cache by Till Krüss가 추천된다고 합니다.
[참고] MySQL tmp 디렉토리를 램에 올리면 안되는 이유
mysql을 최적화해도 상당수의 데이타를 처리하기 위해서 디스크에 temp 파일을 저장하면서 사용합니다.
이를 막기 위해서 tmp 폴더를 램으로 지정해 주는 것을 추천했었는데요. 이는 에러 요인이 되기 때문에 tmp 디렉토를 메모리에 올리면 안됩니다.
처음에는 아애 소개하는 방법대로 /tmp 디렉토리를 메모리에 올려 사용했으나 치명적인 문제는 없지만 지속적으로 에러가 발생한다는 것을 알았습니다.
여러 번 시행 착오와 error log 분석을 통해서 결국 리눅스 tmpfs 파일시스템은 일부 임시 파일생성을 허용하지 않기 때문에 에러가 발생하다는 사실을 확인하고 임시 파일 폴더를 메모리에 올리는 것을 포기 했습니다.
제가 받은 에러 메세지는 리눅스 커널에서 MariDB가 tmpfs 파일시스템에서 일부 임시 파일 생성하는 것을 허용하지 않아 에러가 발생하는 “mariadbd: O_TMPFILE is not supported on /dev/shm (disabling future attempts)” 였습니다.
우선 mysql로 진입합니다. MariaDB 최근 버전부터는 시스템 비밀번호를 공유하기 때문에 이미 시스템에 들어와 있으면 별다른 비밀번호가 필요하지는 않습니다.
mysqlCode language:PHP(php)
아래와 같은 명령어를 사용해 db이름과 db 사용자 및 비밀번호를 등록합니다.
CREATE DATABASE wp;
CREATE USER username@localhost;
SET PASSWORD FOR happist@localhost= PASSWORD('password');
GRANT ALL PRIVILEGES ON wp.* TO username@localhost IDENTIFIED BY 'password';
FLUSH PRIVILEGES;Code language:PHP(php)
우리에게 도브 비누로 잘 알려져 있기도 하고 사회적 목소리를 높이는 기업으로 유명한 밴앤제리스 아이스크림을 인수하기도 했던 유니레버가 기업 최초로 유니레버 탄소중립 정책을 주주총회에 상정하겠다고 밝혔습니다.
올해 들어 기업 단위 뿐만이 아니라 국가 단위에서 탄소중립 목표를 앞다투어 선언하고 있죠.
우리나라도 지난 11월 문재인대통령이 국회 시정연설에서 2050년 탄소중립을 추진하겠다고 밝히고, 2020년 12월 10일 환경위기시각 9시 47분에 ‘탄소중립’ 선언하기도 했습니다. 그 이전에 도저히 그렇 것 같지 않았던 중국도 2020년 유엔총회에서 2060년 탄소중립을 선언해 세계를 놀라게 하기도 했습니다.
이처럼 기업 분만이 아니라 국가 단위에서 탄소중립이 중요 시 되면서 기업의 생존 전략의 하나로 탄소중립과 같은 지속 가능 성장이 중요한 이슈가 되고 있습니다
그런 가운데 유니레버가 단순한 탄소중립 선언이 아니라 이를 구체적으로 실행하기 위한 계획을 수립하고, 이러한 계획을 주주총회에서 투표로 승인 받겠다는 선언을 통해서 유니레버의 탄소중립 의지가 얼마나 굳건하고 진지한 지를 보여주겠다고 밝히고 있습니다.
런던에 본사를 두고 있는 유니레버는 2020년 12월 14일(월), 그들의 경영 활동으로 발생하는 탄소 배출의 영향과 그로 인한 기후 변화를 줄이기 위한 계획을 수립하고 이를 3년마다 주주들의 승인을 받겠다고 밝혔습니다.
물론 이러한 주주들의 승인이 법적 강제를 가지는 것은 아니고 조언에 불과할지라도 유니레버는 이러한 행동을 통해서 그들의 진지함을 표명하고 싶어 했습니다.
유니레버는 2030년까지 자체 경영 전반에 걸처 탄소 배출을 제로화하고, 2039년까지 매입 및 판매 단계에서도 탄소 배출을 제로화하는 탄소중립을 달성하겠다는 목표를 제시
또한 향후 10년 내에 유니레버 제품을 절반으로 줄이겠다는 계획을 밝혔는데 이는 자사 제품에서 탄소 배출을 줄이는 것보다도 더욱 더 어려운 목표 임
유니레버는 이러한 목표 달성 전략을 21년 1분기에 자세히 공개하고, 2022년에 주주총회에서 연간 진행 사항을 보고할 계획
유니레버 탄소중립에 적극적인 이유
다른 회사들 보다 한발 앞서 탄소중립 달성 계획을 선제적으로 공개하고 이를 주주총외에서 승인을 받겠다는 계획을 밝힌 이유는 무엇일까요?
무엇보다도 투자자들의 압력이 거세지고 있습니다.
유니레버의 가장 큰 투자자 중의 하나인 블랙록(BlackRock)은 2020년 초 기업들이 주요 산업 표준에 따라 기후 변화 위험과 이를 줄일 계획을 공개하지 않는다면 경영진과 이사회에 반대표를 던지겠다고 위협해 왔습니다.
뿐만이 아니라 기후 변화에 대응해 기업들이 조치를 취하도록 압력을 강화하고 있는 투자자 그룹 Climate Action 100+도 블랙록처럼 기업들에게 기후 대응을 촉구해 왔습니다.
또한 지속 성장 전략에 대한 일반 투자자들의 관심이 증가하면서 미래 성장을 위한 지속 가능 성장 전략을 요구하는 분위기가 높아지고 있습니다.
일반 소비자, 특히 Z세대들의 환경에 대한 관심이 높아지고 있습니다.
기업 이익에 가장 많은 관심을 가지는 투자자들이 앞장서서 탄소중립이나 지속 가능 성장 전략을 요구하는 것은 앞으로 이러한 적극적인 전략 없이 생존이 불가능하기도 하거니와 소비자들의 탄소중립이나 지속 가능 성장 전략을 브랜드 평가의 중요한 요인으로 삼고 있기 때문이기도 합니다.
특히 Z세대를 구별하는 가장 큰 특징 중 하나는 기후 변화와 환경에 대한 관심을 가지고 있고 그들의 브랜드 평가와 쇼핑에서 이를 적극적으로 반영하고 있기도 합니다.
또한 트렌드 예측가 WGSN이 2019년 11월에 1,800명을 대상으로 진행한 조사에 따르면 Z세대의 95%가 지구 온난화에 맞서기 위해 자신의 습관과 생활 방식을 바꾸겠다고 응답했습니다..
“Z세대들 사이에서 이런 행동을 하게 된 가장 중요한 동인은 기후 변화입니다. 분명하고 단순합니다.”
Z세대는 타 세대보다 환경 지향적
2019 년 12월 디지털 리서치 회사, 퍼스트 인사이트(First First Insight)가 1,000명 대상으로 설문 조사 결과를 보면 Z세대 73%는 지속 가능한 제품에 더 많은 돈을 지불 할 의향이 있으며, 그들 대다수는 그러한 품목에 10%이상 더 지불할 의향을 가지고 있습니다.
이러한 Z세대의 지속가능한 상품에 대한 선호는 밀레니얼세대, X세대, 베이비 부머 세대 등 다른 세대들보다도 높은 수준입니다.
Z세대 73%
밀레니얼 세대 68%
X세대 55%
베이비 부머 세대 42%
마치며
유니레버는 브랜드 정체성으로 친환경 등 올바른 브랜드 이미지를 심고자 노력해 왔습니다.
그들의 브랜드 로고도 친환경 느낌이 풀풀 나도록 바꾸었습니다.
친환경 이미지를 갖는 유니레버 로고가 있는 풍경, unilever Logo crop
또 아래는 유니레버 홈페이지 메인 이미지인데요. 유니레버가 지향하는 브랜드 정체성을 잘 보여 준다는 생각입니다.
그렇기에 탄소중립과 같은 그들의 브랜드 정체성에 부합하는 이슈는 적극적으로 수용해 자기 브랜드 이미지, 연상으로 발전시키는 것도 좋은 접근 방법으로 판단한 것으로 보입니다.
We have joined other key players in the coconut industry to sign the first Sustainable Coconut Charter. This aims to…
The soil beneath our feet is crucial to our food systems, our environment and life on Earth. But we need to take much better care of it. We can all play a part. #WorldSoilDay
이번 기업 최초로 그들의 탄소중립 전략을 및 실행 계획을 주주들에게 승인 받겠다는 계획을 발표함으로써 다른 브랜드보다 친환경 이슈를 선점하는 확실한 효과를 거두었습니다.
그리고 블랙록이나 Climate Action 100+와 같은 투자자들의 환영을 받으면서 안정적으로 투자 자금을 마련할 수 있는 유리한 환경을 만들기도 했습니다
“이는 단지 자문 투표일 뿐으로 유니레버에게 강제할 수 있는 것이 아님에도 불구하고 유니레버의 주주총회에서 탄소중립 전략을 승인 받겠다는 계획은 탄소중립 계획의 중요성과 그들의 의지를 명확하게 보여줄 수 있다는 점에서 긍정적입니다.” – 유니레버 투자자그룹 대표 피어스 휴 스미스
2020년 12월 10일(현지 시간) 디즈니는 투자 설명회를 통해서 디즈니플러스 가입자 등 현재 상황과 행후 디즈니플러스 비젼과 디즈니플러스를 포함해 그들이 그리는 디즈니 스트리밍 서비스 미래에 대한 계획을 밝혔습니다.
이에 따르면 디즈니플러스 가입자가 8천 7백만명에 이르렀으며, 디즈니플러스와 훌루 그리고 ESPN+를 포함한 전체 스트리밍 가입자는 1억 3천 7백만명에 달했다고 밝혔습니다.
그렇지만 디즈니의 자신감인지 모르지만 디드니플러스 구독료를 현재 6.9달러에서 7.9달러로 인상하겠다는 계획도 밝혔습니다. 가격 인상 소식은 주식 시장이 즉각 반영하면서 디즈니 가격은 엄청난 폭등하는 하나 계기가 되기도 했습니다.
아울러 Star로 불리우는 엔터테인먼트 콘텐츠 브랜드를 런칭한다고 밝혔습니다. 아울러 딛즈니플러스 글로벌 확장 스케줄도 밝혔는데요. 2021년 2월 싱가폴 출시 후 하반기에는 한국, 일본, 홍콩 그리고 동유럽에서 출시한다고 밝혔습니다.
그리고 관심을 모았던 디즈니 비젼에 대서는 회계년도 202년 디즈니플러스 가입자 2.6억명을 비롯해 전체 디지탈 스트리밍 서비스 가입자를 3억명 ~ 3.5억명까지 늘린다는 계획을 발표했습니다.
이러한 목표 달성을 위해 2024년에 콘텐츠 투자 140억 ~ 160억 달러 투자 추진 등 보다 공격적인 투자 계획을 밝혔습니다. 이러한 투자에도 불구하고 가입자 증가에 따라 디즈니플러스는 2024년, 흘루와 ESPN+는 2023년에 각각 수익을 낼 수 있을 것으로 전망했습니다.
20년 12월, 디즈니플러스 가입자 8,680만명
20년 12월 10일 딪니 투자 설명회에서 밝힌 20년 12월 2일 기준 디즈니플러스 가입자는 8천 6백 8십만명으로 지난 3분기 실적 시 밝힌 7천 3백 7십만명에 비해서 약 1천 3백만명이나 늘었습니다.
디즈니플러스 가입자 추이, 디즈니플러스 구독자, Disney+ Subscribers(Millions), Graph by Happist
디즈니플러스 가입자를 넷플릭스 가입자와 직접 비교해 보면 아직은 많은 차이가 있지만 빠르그 그 차이가 줄어들고 있음을 알 수 있습니다.
넷플릭스 가입자와 디즈니플러스 가입자 증가 추이 비교( ~ 20년 12월), Graph by Happist
디즈니플러스, 훌루 그리고 ESPN+ 가입자 합계, 1억 3,710만명
한편 디즈니는 또 다른 스트리밍 서비스인 훌루(Hulu) 가입자를 약 3천 9백만명으로 밝혔는데요. 이 또한 지난 3분기 실적 시 밝힌 가입자보다도 2.2백만명이 증가한 것입니다.
또한 디즈니의 스포츠 중계 스트리밍 서비스인 ESPN+도 가입자가 11.5백만명으로 지난 3분기에 비해서 1.2백만명 증가했습니다.
디즈니 3대 스트리밍 서비스 가입자 증가 추이, Disney streaming service Subscribers(Millions), Graph by Happist
디즈니 스트리밍 서비스 전체 가입자 1.37억 명
이처럼 디즈니가 운영하고 있는 3대 스트리밍 서비스, 디즈니플러스/훌루/ESPN+ 가입자 합계는 1억 3,710만명으로 지난 3분기에 비해서 1,650만명이 늘었습니다.
2020년 12월 2일 기준으로 넷플릭스 가입자 수치를 모르기 때문에 장확히 비교하기는 그러하지만 지난 3분기 기준으로 디즈니 전체 가입자가 넷플릭스 60% 수준에 불과했지만 조만간 70% 가까이 증가할 것으로 보입니다.
분기별 디즈니+, 디즈니 전체, 넷플릭스 구독자 추이( ~ 20년 12월), Graph by Happist
이러한 전망은 생각보다 빠르게 디즈니플러스 출시국이 증가하고 있기 때문입니다. 2020년 현재 네플릭스 진출국은 190국가라고 합니다. 반면에 디즈니플러스 출시국은 아직 많지 않습니다. 37개국정도..
그런데 디즈니플러스가 미국 시장에서의 성공을 기반으로 빠르게 글로벌 런칭을 추진하고 있고 한국에는 21년 하반기에 서비스를 출시할 예정입니다.
디즈니 스트리밍 비즈니스 미래
이번 디즈니 투자 설명회에서 디즈니는 주로 디즈니 스트리밍 서비스 비젼을 빍혔는데요. 디즈니 회계년도 2024년(2023년 10월 ~ 2024년 9월)까지 콘텐츠 투자 계획 및 각 스트리밍 서비스 가입자 목표를 제시 했습니다.
디즈니플러스 비젼, 2024년 디즈니플러스 가입자 2.6억명
한편 이번 디즈니 투자설명회에서는 디즈니가 예상하는(디즈니가 목표로 한다는 표현이 더 정확하겠죠) 디즈니 플러스 가입자 목표를 밝혔는데요.
디즈니 회계년도 2024년(캘린더 이어로는 2023년 10월 ~ 2024년 9월) 디즈니플러스 유료 가입자 2억 ~ 2.6억명에 이를 것으로 전망
훌루(Hulu) 가입자는 5천 ~ 6천만명의 가입자 확보 목표
ESPN+ 가입자는 2천 ~ 3천만명 가입자 목표
따라 2024년 디즈니 스트리밍 서비스 가입자는 3억 ~ 3.5억명으로 증가할 것
스트리밍 서비스를 위한 콘텐츠 투자 강화
이러한 목표를 달성하기 위해서 디즈니는 콘텐츠에 막대한 투자를 진행하겠다고 밝혔는데요.
우선 2021년을 목표로 62편의 시리즈물과 42편의 영화 계획을 발표, 이 중 80%이상으로 DTC로 공개할 예정이라고 합니다.
그리고 디즈니가 밝힌 회계년도 2024넌까지 디즈니 목표 및 비젼에 대해서 아래와 같이 정리해 봤습니다.
디즈니 회계년도 2024년 콘텐츠 투자 140억 ~ 160억 달러 투자 추진 이 중 디즈니플러스 투자는 80~90억 달러에 달할 것 특히 마블과 스타워즈를 비롯한 5개 브랜드만 매년 100개 이상의 새로운 타이틀 제작 추진 – 이러한 투자에 대해서 넷플릭스는 2020년에만 콘텐츠 투자에 170억 달러를 투자했기 때문에 디즈니플러스 콘텐츠 투자가 엄청난 것이라고 볼 수는 없음 – 그러나 시장 예측 또는 기존에 알려진 디즈니 오리지널 콘텐츠 투자비보다 최소 2배 이상으로 증가
매년 마블, 스타워즈 등 100여개 이상의 신규 타이틀을 제작 발표 예정이며, 글로벌 시장 공략을 위해서 현지 제작을 강화할 예정
이러한 투자에 따라 디즈니플러스는 회계년도 2021년에 적자폭이 극대화 될것이며, 이후 가입자 증가에 따라 2024년부터는 수익을 낼 수 있을 것으로 전망
우선 PHP 8에 워드프레스 5.6 적용 시 문제가 되는 플러그인들과 php 코드가 너무 많았습니다.
워드프레스 debug 모드를 활성화해서 어떤 문제가 있는지 차자아내, 문제가 되는 플러그인들을 제거하니 그럭저럭 사이트가 작동은 되더군요.
그렇지만 유사한 조건으로 PHP 7.4에 워드프레스 5.6을 적용한 사이트가 PHP 8 적용한 사이트보다 빨랐습니다. 서버 성능은 PHP 8을 적용한 서버가 한 단계 더 높은 성능을 낸다는 Vultr High Performance 였습니다. 그런데도 전체 성능은 오히려 더 좋지 않더군요.
결국 현 단계에서는 PHP 8 적용 리스크가 너무 크고, 속도도 개선되지 않고 오히려 이런저런 문제가 있어서 인지 속도가 더 느립니다.
PHP 8 적용 시 나타나는 문제
여러 사이트를 테스트해 보았지만 일부 플러그인이 가장 큰 문제로 보였습니다.
저의 경우 애드센스 광고를 뿌려 주는 Ad Insert pro라는 플러그인이 치명적인 오류(Fatal error)를 낸다고 나왔고, Rank Math도 상당히 많은 문제를 일키는 것 같더군요.
디버그 모드에서 발생하는 문제가 아래처럼3 4개로 굉장히 많은데요. 참고로 보시기 바랍니다. 기록 삼아 남겨보겠습니다.
이 사이트를 들어가면 아래 캡춰 이미지처럼 주요 도메인별로 가장 저렴하게 등록할 수 있는 업체를 소개하고 있습니다. 가장 저렴한 도메인 등록, 가장 저렴한 도메인 이전 등
닷컴의 경우 도메인 등록 시 Porkbun이 가장 저렴하며, 도메인 갱신 시는 Sav가 가장 저렴
닷넷의 경우도 도메인 등록 시 Porkbun이 가장 저렴하며, 도메인 갱신 시는 Sav가 가장 저렴
도메인 종류별 상세 업체 비교
조금 더 구체적으로 살펴보기 위해서 원하는 도메인 종류를 선택하면 훨씬 더 자세하고 업체별 가격을 볼 수 있습니다. 저는 co 도메일 갱신을 고민하고 있었기 때문에 co를 눌러 살펴 보았습니다.
Co 도메인 등록, 도메인 갱신, 도메인 이전 모두 Sav라는 업체가 가장 저렴
원래 Co 도메인을 등록했던 namecheap의 도메인 갱신 비용은 26달러 vs 가장 저렴한 Sav는 21달러(도메인 이전 시 20달러) 갱신 비용만 5$ 차이가 나기 때문에 굳이 namecheap를 고집할 필요가 없으므로 Sav로 이전하기로 해서 6달러를 절약하기로 결정
국내 도메인 구매 비용 비교
위에서 소개한 TLD LIST는 주로 글로벌 도메인이 중점이라 우리나라 국내 도메인 가격 비교는 도움이 안됩니다. kr 도메인에 대한 비교도 볼 수 있지만 여기 가격이 훨씬 더 비쌉니다. 고대디가 가장 저렴한데 등록 22달러, 갱신 22달러로 등록되어 있군요.
아무래도 로컬 도메인은 로컬 업체를 사용하는 것이 가장 좋을 것 같습니다.
우리나라 도메인 관리 업체별 가격 비교는 KRNIC에서 제공하는 가격 비교 서비스를 이용하면 좋을 것 같습니다. 아래 링크를 이용해 접속할 수 있습니다.
애플이 미래 먹거리로 자율주행 시스템을 기반으로 애플카를 추진하고 있다는 소식이 있어, 애플 자율주행차 개발 소식과 더불어 애플 차세대 전략에 대해서 살펴 봣습니다.
애플 미래 사업은 무엇일까요? 스마트폰 시장 성숙에 따라 아이폰을 대체할 수 있는 비즈니스가 무엇인가는 애플을 비롯한 IT업계를 주목하는 사람이면 관심을 가질만한 주제입니다.
그래서 아이폰을 이어서 애플의 차세대 성장 동력이 될 것으로는 서비스 비즈니스가 강력하게 떠오르고 있었습니다. 여기에 최근 에어팟 성공등으로 웨어러블도 유력한 후보가 되기도 했습니다.
그러나 최근 자율주행 자동차를 애플 미래 먹거리로 개발한다는 정보가 있습니다. 테슬라가 가장 유력한 후보로 떠오르고 있는 자율주행 모빌리티 산업에 애플도 자율주행차로 출사표를 던지려고 준비중이라는 소식입니다.
애플카 컨셉_애플카 전면 모습, Apple Car Front, Aristomenis Tsirbas
최근 대만 매체 디지타임스는 애플이 애플카 개발을 위해 전장업체와 협상 중이며, 미국 내 공장 설립을 추진 중이라고 보도 했습니다.
애플은 2014년부터 애플카(Apple Car) 관련 청사진을 공개해 왔음
애플은 테슬라 등 기존 자동차 업계 임원 및 엔지니어를 스카우트하기 위해 접촉 중이고 채용을 계속하고 있음
미국 내에 애플카를 생산항 공장 설립을 준비 중
기존 글로벌 자동차 전장 공급망 업체들과 예비 협상을 시작
TSMC와 자동차용 자율주행 칩 개발을 진행 중
최근 애플카와 관련된 부품 업체들 사잉
애플카 공급망 회사들 리스트는 2021년에 윤곽을 드러낼 것으로 전망
애플카는 2024년 ~ 2025년에 공개될 것으로 전망
애플 자율주행차 프로젝트 타이탄, 애플 인공지능(AI) 부서로 이관
앞서 소개한 디지타임즈에서는 애플이 애플카를 생산할 미국 내 자동차 공장을 건설할 예정이라고 전했지만, 애플카 프로젝트는 실제로 애플이 자동차 메이커가 되어 애플카를 생산, 판매하는 것이 아니라 다른 자동차 제조업체가 만든 자동차에 상요할 수 있는 자율주행 기술 개발에 초점을 맞추고 있다는 해석이 더 유력합니다.
애플은 2014년부터 테슬라나 기타 자동차 제조업체를 목표로 자율주행 전기자동차를 연구하기 시작했습니다. 뒤에서도 언급하는 “프로젝트 타이탄(Project Titan)”이 그것이라고 할 수 있습니다.
그러다 2016년 이런 자율주행 전기차에 대한 야망을 접은 듯 활동을 축소했습니다. 이 프로젝트가 방향성, 리더쉽 및 기술적 과제를 해결하는데 어려움을 겪고 있었다고 알려졌습니다.
이때부터 스티브 잡스의 왼팔이라 불렸던 밥 맨스필드(Bob Mansfield)가 이 프로젝트 타이탄을 이끄릭 시작했습니다.
이러한 리더쉽은 최근 변화를 겪었다고 블름버그가 전하고 있습니다. 이 블룸버그 기사에 따르면 “프로젝트 타이탄(Project Titan)”은 밥 맨스필드(Bob Mansfield)가 완전히 은퇴하면서 이 프로젝트를 애플 인공지능(AI) 및 머신러닝을 총괄하는 수석 부사장인 존 지안안드레아(John Giannandrea)가 지휘하는 것으로 변경되었다고 합니다.
애플 인공지능(AI) 및 머신러닝을 총괄하는 수석 부사장인 존 지안안드레아(John Giannandrea), Image from Bloomberg
이는 스티브 잡스의 왼팔이라 불렸던 밥 맨스필드(Bob Mansfield)가 은퇴하면서 조정된 것이라는 알려졌으나 “프로젝트 타이탄(Project Titan)” 프로젝트를 인공지능(AI) 및 머신러닝 연구와 합쳐 시너지를 내겠다는 전략으로 해석할 수 있을 것 같습니다.
블룸버그는 미국 캘리포니아주 차량관리국(DMV) 기록을 토대로 애플이 현재 66대의 자율주행 차량을 보유하고 있으며 2017년부터 일반 도로에서 자율주행차 기술을 테스트하고 있다고 보도했습니다.
I saw one of these a few weeks ago pull up to an Apple shuttle stop-sit there for a few then drove off. pic.twitter.com/gUudZY1TIA
대만 매체 디지타임스(Digitimes)기사를 전적으로 신뢰한다면 애플은 테슬라의 길을 걷을 것으로 보입니다. 테슬라가 그랬듯이 전기차 양산 능력을 어느 정도 갖춘 자동차 스타트업이나 기존 자동차 메이커를 인수 후 여기에서 애플 주도로 개발한 자율주행 시스템을 장착한 애플 자율주행차를 양산, 판매할 것입니다.
애플카 컨셉_애플카 내부 및 측면 모습, Apple Car Inside, Aristomenis Tsirbas
그러나 9TO5Mac에서 지적하듯이 애플이 자동차 메이커를 인수해 자율주행차 산업에 뛰어들기 보다는, 애플카 프로젝트는 다른 자동차 제조업체가 만든 자동차에 사용할 수 있는 자율주행 기술 개발해 기존 자동차 업체에게 라이센스를 주어 일정 수익을 올리는 라이센스 비즈니스 모델에 집중할 가능성이 높아 보입니다.
미래 자율주행차에서 중요한 것은 자율주행 시스템도 중요하지만 전지차라면 효율적인 배터리 공급망을 구축해야 합니다. 테슬라처럼 장기적으로 스스로 배터리 생산까지 고려하든지 아니면 LG화학과 같은 배터리 전문 업체와 협력하는 방안도 있겠죠.
규모로 보았을 시 애플처럼 여러가지 제품과 서비스를 운용하는 회사는 자율주행차 하나에 몰빵할 수 없기 때문에(없다기 보다는 효율적이지 않을 수 있기 때문에) 자율주행차 산업 전체를 참전하는 것 보다는 실속있는 자율주행 시스템 라이센스 사업에 당분간 집중하지 않을까요?
그러다 어느 정도 자신이 붙고 시장이 본격적으로 형성된다면 본격적으로 전기차 자율주행차 시장에 메인 플레이어로 참전하지 않을까 싶습니다.