Notice/News

[NOTICE] 블로그 성능 개선 작업 완료 (2021-05-17)

안녕하세요. ManVSCloud 김수현입니다.

2021년 5월 17일 예정되어 있던 블로그 성능 개선 작업이 정상적으로 완료되었습니다.

※ 작업 내용
→ DNS 작업 (작업 시간동안 임시 Parking 페이지로 출력될 예정입니다.)
→ 데이터 백업(Snapshot)
→ 소프트웨어 버전 업그레이드
→ EC2, RDS 인스턴스 재시작
→ DNS 원복

※ 작업 시간
→ 예정 시간 : 2021-05-17 월요일, 00:00 ~ 06:00(KST)
→ 소요 시간 : 2021-05-17 월요일, 00:00 ~ 02:40(KST)


세부 작업 내용

http://parking.manvscloud.com

http://manvscloud.com 또는 https://manvscloud.com 접속 시 http://parking.manvscloud.com 사이트로 리다이렉트 되도록 설정한 뒤 작업하였습니다.

parking 페이지의 경우 cdn을 이용하려고 했는데 이번 작업 준비 기간이 다소 부족하여
제 테스트 서버를 사용하게 되었습니다.

  • 작업 전 스냅샷 (naming-20210517)
  • PHP 버전 업그레이드 (PHP 7.3.23 → 7.4.15)
<작업 전>
[root@ip-10-0-1-68 ~]# php -v
PHP 7.3.23 (cli) (built: Oct 21 2020 18:39:40) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.23, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.23, Copyright (c) 1999-2018, by Zend Technologies

<작업 후>
[root@ip-10-0-1-68 mcrypt-1.0.2]# php -v
PHP 7.4.15 (cli) (built: Feb 11 2021 17:53:39) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.15, Copyright (c), by Zend Technologies
  • PHP 모듈 추가 설치

PHP 7.4 버전으로 설치 후 mcrypt 모듈이 정상적으로 설치되지 않았습니다.
(가끔 버전업 시 해당 버전에서 특정 모듈 지원 중단으로 설치가 안될 때가 있습니다.)
mcrypt 모듈이 설치가 되지않아 수동으로 설치 해주었습니다.

[root@ip-10-0-1-68 ~]# yum install libmcrypt-devel
[root@ip-10-0-1-68 ~]# cd /usr/local/src
[root@ip-10-0-1-68 ~]# wget https://pecl.php.net/get/mcrypt-1.0.2.tgz
[root@ip-10-0-1-68 ~]# tar xvfz mcrypt-1.0.2.tgz
[root@ip-10-0-1-68 ~]# cd mcrypt-1.0.2
[root@ip-10-0-1-68 ~]# phpize
[root@ip-10-0-1-68 ~]# ./configure
[root@ip-10-0-1-68 ~]# make
[root@ip-10-0-1-68 ~]# make install
[root@ip-10-0-1-68 ~]# echo extension=mcrypt >> /etc/php.ini
  • RDS 버전 업그레이드 및 파라미터 그룹 설정

저는 주로 파라미터 그룹 설정을 아래와 같이 사용합니다.
상황에따라 max_allowed_packet, max_heap_table_size, tmp_table_size 등의 값을 조정해주어야겠습니다.

character_set_client utf8mb4
character_set_connection utf8mb4
character_set_database utf8mb4
character_set_filesystem utf8mb4
character_set_results utf8mb4
character_set_server utf8mb4
collation_connection utf8mb4_general_ci
(collation_server은 utf8mb4_general_ci 를 선택할 수 없어서 그냥 빼버렸습니다.)
time_zone asia/seoul
connect_timeout 3600
skip_name_resolve 1

  • WordPress 최신 버전 업데이트 (5.5.2 → 5.7.2)
  • EC2, RDS 인스턴스 재부팅
  • DNS 원복

마무리

오래 미루어왔던 블로그 품질 향상 및 안정화를 위한 작업이 완료되었습니다.
늘 워드프레스 관리자 사이트에서 Site Health에 노란불이 들어왔었는데 작업 후 확실히 깔끔해진 기분입니다.

개인적으로 작업 시간은 (작업에 필요한 시간 + 장애 시 복구 시간)을 다 합쳐서 정하는 편입니다. 이번 작업은 야간 당직 중 남는 시간 틈틈이 작업을 진행하려 했기에 6시간을 예상했었는데 다행히 당직 간에 큰 일이 없어서 빠르게 작업을 끝낼 수 있었던 것같습니다.
아마 중간중간에 일이 없었다면 1시간 내로 작업이 끝났을 것같군요.
작업이 잘 마무리되어 다행입니다.

다음 포스팅은 [NCP] 네이버 클라우드에서의 보안 – Account 으로 찾아뵙겠습니다.

긴 글 읽어주셔서 감사합니다.

NCP

0. [NCP] 네이버 클라우드에서의 보안 – Introduce

안녕하세요. ManVSCloud 김수현입니다.

오늘은 국내 클라우드 Naver Cloud Platform에서의 보안을 간단히 소개해보는 포스팅을 작성해보려합니다.

포스트 코로나 시대, 즉 접촉없이 연결되는 언택트 시대가 Covid-19의 영향으로 예상보다 빠르게 일상생활의 트렌드를 바꾸어가고 있습니다.
온라인 교육, 화상 면접, 배달 서비스 등 시대에 맞게 비대면 서비스가 증가했으며
IT 분야 역시 이러한 변화로 인해 클라우드 서비스가 많이 사용되고 있습니다.

https://www.parkmycloud.com/blog/aws-vs-azure-vs-google-cloud-market-share/

전통적인 온프레미스 환경에서 클라우드로 변화하거나 온프레미스와 퍼블릭 클라우드를 함께 하이브리드 클라우드로 운영하시는 사용자들이 상당히 많아졌고 공공기관이나 금융기관 역시 이러한 클라우드 서비스에 대해 고려해보게 됩니다.

(네이버 클라우드 플랫폼 – 공공기관용)

(네이버 클라우드 플랫폼 – 금융기관용)

또한 국내 데이터가 해외 클라우드 서버에 저장되는 것부터 그런 데이터들이 보안 문제로 인해 유출되는 부분들까지 많은 고민이 될 것입니다.
네이버 클라우드에서는 국내 공공기관용으로 보안수준을 강화한 클라우드 서비스를 제공하고 금융기관과 핀테크 기업의 조건에 맞는 맞춤형 서비스를 제공하여 데이터를 국내에 저장하며 맞춤형 클라우드 서비스를 사용할 수 있어 더욱 신뢰성과 안정성이 있습니다.

CSA(Cloud Security Alliance) 자료에 따르면 클라우드 환경에서의 11가지 두드러진 위협/위험 및 취약점이 아래와 같이 존재한다고 말합니다.

  1. Data Breaches (데이터 침해)
  2. Misconfiguration and Inadequate Change Control (잘못된 구성 및 부적절한 변경 제어)
  3. Lack of Cloud Security Architecture and Strategy (클라우드 보안 아키텍처 및 전략 부족)
  4. Insufficient Identity, Credential, Access and Key Management (불충분한 ID, 자격증명, 액세스 및 키 관리)
  5. Account Hijacking (계정 하이젝킹)
  6. Insider Threat (내부자 위협)
  7. Insecure Interfaces and APIs (안전하지 않은 인터페이스 및 API)
  8. Weak Control Plane (약한 컨트롤 플레인)
  9. Metastructure and Applistructure Failures (메타 구조 및 애플리케이션 구조 오류)
  10. Limited Cloud Usage Visibility (제한된 클라우드 사용 가시성)
  11. Abuse and Nefarious Use of Cloud Services (클라우드 서비스의 남용 및 악의적인 사용)

위 보안 위협에 대한 자세한 내용은 아래 사이트에서 다운로드 받을 수 있으니
취약점에 대한 자세한 내용을 알고싶으신 경우 자료 참고하시면 좋을듯 합니다.

이런 보안 위협에 대한 대비는 앞으로 더욱 중요한 사항이 될 것으로 보입니다.


Naver Cloud – Security

네이버 클라우드를 사용하며 각 서비스들마다 어떤 보안 관리를 할 수 있을지 알아보겠습니다. 우선 네이버 클라우드 플랫폼을 사용하기 위해서는 해당 페이지로 로그인을 해야합니다.

여기서 사용하는 계정을 해킹 당한다면 상당히 크리티컬한 문제로 이어집니다.
때문에 네이버 클라우드에 접속하는 계정 보안은 아주 중요하다고 볼 수 있습니다.
두번째로 네트워크 보안입니다. VPC 플랫폼을 예로 VPC 생성 후 서비스 목적에 맞게 그리고 보안 요구 사항에 따라 네트워크를 분리 하는 것이 좋습니다. 세번째로 서버 보안입니다. 서버에 올라가는 OS의 취약점부터 해당 서버로 접근할 수 있는 접근 제한 등 각 서비스 포트별로 관리도 필요합니다.

DB 보안도 필수죠. DB의 경우 아무래도 데이터 유출이나 손실이 발생하면 상당히 곤란할 때가 많습니다. 인증, 기밀성, 무결성, 가용성을 유지하기 위해 다소 많은 고민을 해야합니다. 그 외에도 스토리지 보안과 모든 활동에 대한 감사 등 보다 안전한 서비스를 구성하기 위해서는 고려해야할 사항들이 다수 많이 존재합니다.

manvscloud – ncloud security

Compliance Guide

네이버 클라우드 플랫폼에서는 Compliance Guide가 무료로 제공됩니다.

Compliance Guide가 무엇이냐?! 서비스 설명에서는 아래와 같이 설명 하고 있습니다.

“Compliance Guide는 네이버 클라우드 플랫폼이 보유한 인증서와 관련 문서를 제공하여 고객이 보안 인증에 대응하는데 도움을 주며, 네이버 클라우드 플랫폼의 각 서비스 이용 시 어떤 통제 항목이 해결되는지, 고객이 추가로 수행하여야 하는 부분은 어떤 항목인지 등을 손쉽게 확인할 수 있도록 돕습니다.”

즉 보안 인증이나 규제에 대응에 필요한 사항을 쉽게 정리한 규정 준수 가이드입니다.

이 가이드를 통해 KISA ISMS-P 인증 심사나 PCI DSS와 같은 인증에 대한 대비를 보다 원활하게 진행할 수 있습니다.

▶ 네이버 클라우드 플랫폼의 책임이 되는 통제 규격
▶ 고객의 책임이 되는 통제 규격
▶ 네이버 클라우드 플랫폼과 고객의 공통 책임이 되는 통제규격

Coverage 기능에서는 책임 통제 규격에 대한 식별이 쉽도록 구분되어 있으며
명확한 구분으로 사용자가 담당해야할 부분에 대한 보안 통제를 확실히 알고 대응할 수 있습니다.

또한 Products 기능을 사용한다면 네이버 클라우드의 각각의 서비스가 지원하는 통제 규격과 적용해야 하는 통제 규격을 쉽게 알 수 있습니다.

위 사진을 보면 알 수 있다시피 상품 카테고리에서 Networking-VPC를 선택하면 VPC 제품에 대한 규격을 색깔로 구분해두어 VPC 상품은 이 부분을 지원하는구나 또는 어떤 통제 규격을 적용해야하구나를 자세히 알려줍니다.

또한 “정보시스템 관련 자산(하드웨어, 운영체제, 상용 소프트웨어, 패키지 등) 변경에 대한 절차를 수립·이행 하고 있는가?”라는 내용에 마우스 커서를 올리면 해당 내용에 대한 통제를 구현하는데 이용되는 상품, 통제를 적용해야 하는 상품, 통제를 구현하는데 이용되는 상품을 알 수 있습니다.


마무리

6월 18일에 “[6월 Intermediate] 네이버클라우드플랫폼 보안 강화 교육” 이라는 주제로
네이버 클라우드 플랫폼에서 교육이 진행됩니다.

현재 아쉽게도 모집은 마감된 상태라 추가적인 신청이 불가능한 상태이므로
제가 해당 교육을 듣고난 후 추가적인 후기 포스팅을 남기고 제가 포스팅하고 있는 “네이버 클라우드에서의 보안” 주제에 빠진 부분을 추가 포스팅으로 채워볼 예정입니다.

다가오는 보안 교육 전에 먼저 “[NCP] 네이버 클라우드에서의 보안”이라는 주제로 포스팅을 진행하게 될 것이며 다음 포스팅은 앞서 간단히 소개된 계정, 네트워크, 서버, 데이터베이스, 스토리지, 감사, 이중화, 백업 등에서의 보안을 하나씩 자세히 다루어보는 내용으로 나누어 포스팅 됩니다.

이제는 클라우드, 인공지능(AI) 등 IT가 생활에 매우 가까워졌고 다양한 산업에 혁신을 만들며 산업 생태계를 주도하고 있습니다.
IT가 함께하는 세상이 찾아온만큼 보안에 대한 인식 역시 높아져야겠습니다.

긴 글 읽어주셔서 감사합니다.


Certificate

NAVER Cloud Platform Certified Professional (NCP) 합격과 시험 후기

안녕하세요. ManVSCloud 김수현입니다.

드디어 Naver Cloud Platform Professional 시험에 합격하였습니다.
2020.06.30 NAVER Cloud Platform Certified Associate 응시 이후
Professional 은 약 10개월만에 시험을 보게되었습니다.

Naver Cloud Professional 시험은 총 3번의 시험을 합격해야 Professional 자격을 얻게됩니다.

200 – NCP(Overview, Compute/Storage) – 2021.05.11 (화)
207 – NCP(Troubleshooting) – 2021.04.15 (목)
202 – NCP(Network/Media, Database/Management/Analytics) – 2021.04.13 (화)

위 3개의 시험을 나누어 보게되었고 아래 자격증을 얻게되었습니다.

◈ NAVER Cloud Platform Certified Professional (NCP)
Issue Date : 2021-05-12


시험 TIP

간단하게 Naver Cloud Platform Professional 시험의 Tip을 적어볼까합니다.

우선 Professional 시험부터는 필기 시험뿐만이 아니라 실기 시험도 존재합니다.
어느정도 사용 경험이 있지 않으면 합격할 수 없으니 실습도 병행하여 준비하셔야겠습니다.
(각 시험별 필기 문제는 약 40문제이며, 실기 문제는 3문제입니다.)

우선 공통적으로 아래 두 사이트를 참고하실 필요가 있는데 설명서의 경우
Overview, Compute/Storage(200)와 Network/Media, Database/Management/Analytics(202) 시험에 필수적으로 과목별 내용을 정독 후 시험 보시는 것을 권장드립니다.

아래 edwith 사이트에서 “Authorized Course – Professional level” 영상 강의를 참고하실 수도 있는데 Troubleshooting(207) 과정을 준비하실 때에 필수적으로 봐주시면 좋을듯합니다.

물론 기존에 현장에서 엔지니어로 일하고 계실 경우Troubleshooting 과목이 가장 쉬운 난이도로 느껴지실 수 있을 것입니다.

개인적으로 느낀 시험 난이도는 아래와 같습니다.

필기 : 200 > 202 > 207
실기 : 200 = 207 > 202

전반적으로 실기 시험의 난이도는 높지 않습니다.
다만 202 시험은 당황하면 자칫 한 문제를 놓칠 수도 있겠구나 싶었습니다.
그리고 200 시험의 경우 서버 생성이 필요하여 서버 생성 시간이 약 20분 정도 소요되는데 여기서부터 이슈가 생깁니다. 나머지 두 문제는 첫번째 문제를 해결해야 풀 수 있으므로 첫 번째에서 막히면 사실상 탈락이라 보아도 될 것같습니다. 필기+실기의 총 시간이 1시간인데 필기에서 많은 시간을 소요하여 실기를 못보는 경우가 생기지 않도록 필기를 잘 준비해야 할 것입니다.

또한 필기를 적절히 풀었는데 서버 생성 시간이 다소 오래 걸려 이에 대해 시험관에게 말할 경우 추가적인 시간을 준다고도 하니 참고하여 당황하지 않길 바랍니다.

실습의 경우 비용이 부담되신다면 위 네이버 클라우드에서 진행하는 교육에 참가해보시기 바랍니다.

네이버 클라우드에서 진행하는 교육을 참가하실 경우 교육 당일부터 그 주의 일요일까지 실습 계정을 사용할 수 있어 교육 후에도 시험을 대비한 실습 테스트가 충분히 가능합니다.

또한 기본적인 실습 감각을 익히기 위해서 “NAVER CLOUD PLATFORM Hands-on Lab” 교육을 신청하시는 것을 추천드립니다. 실습에 대한 경험이 없는 분들이 시작하기 좋은 교육이며 Hands-on Lab의 경우 매달 1,2차로 나누어 자주 하는 교육인만큼 접근성에 있어 상당히 좋은 교육이라 생각됩니다.

실기 준비는 Compute/Storage/Database/Networking/Media/Analytics 카테고리에 있는 제품들을 위주로 실습해보시기 바라며 핵심적인 팁으로는 시험 시간이 필기+실기 합쳐서 1시간으로 정해져있어 한 문제당 시간 소요가 상당히 소모되는 제품은 나오지 않는 것같습니다?
(실습은 VPC 환경에 익숙해지도록 해보시면 좋을듯합니다.)

후기

목표했던 Naver Cloud Platform Professional 자격증을 드디어 얻게되었습니다.
Naver Cloud 시험의 경우 올해 후반기에 출시 예정인 Expert 시험까지 생각중에 있습니다.

코로나로 어디 나가지도 못하고 제한되다보니 가끔 공부에 대한 의지가 꺽일 때가 많습니다.
“나는 원래 카공족이고 집에서는 원래 공부가 안되는데…”라고 하면서.

하지만 한창 공부와 거리가 먼 때에는 코로나가 아니었음에도 불구하고 그럴싸한 이유를 만들어서 하지 않았던 걸로 기억합니다.
만약 지금도 하지 않는다면 앞으로도 어떻게든 이유를 만들어서 안하겠구나.. 생각했습니다. 또, 그런 핑계를 만들어서 하지 않을 사람도 있겠다라는 생각도 듭니다.
이런 때에 열심히 한다면 그것 또한 기회라고 생각합니다.
현재 자신이 처한 상황을 핑계로 아무것도 하지 않는 것보다 기회로 생각하고 나아간다면 이 상황이 끝났을 때 보다 나은 자리에 있으리라 믿습니다.

올해 목표해둔 자격증까지 총 4가지 정도가 남은듯합니다.
남은 자격증도 열심히 준비해서 합격 후 후기로 포스팅해보겠습니다.

긴 글 읽어주셔서 감사합니다.

Notice/News

[Notice] 블로그 성능 개선 작업 안내 (2021-05-17)

안녕하세요. ManVSCloud 김수현입니다.

최근 블로그 방문자 수가 늘어 사이트 작업 시 공지 후 작업을 진행하기로 하였습니다.

2021년 5월 17일 새벽 간에 안정적인 서비스를 위한 소프트웨어 버전 업그레이드 작업이 예정되어 있습니다.
작업 내용과 일정은 아래에 추가해두었으며 해당 시간동안 블로그 페이지가 정상적으로 출력되지 않을 수 있으니 참고하시기 바랍니다.

※ 작업 내용
→ DNS 작업 (작업 시간동안 임시 Parking 페이지로 출력될 예정입니다.)
→ 데이터 백업(Snapshot)
→ 소프트웨어 버전 업그레이드
→ EC2, RDS 인스턴스 재시작
→ DNS 원복

※ 작업 시간
→ 2021-05-17 월요일, 00:00 ~ 06:00(KST)

블로그의 품질 향상과 안정화를 위한 작업으로 작업 이후 Site Health 개선과 재부팅 작업으로 인한 캐시 메모리 확보로 사이트가 조금이나마 쾌적한 환경으로 운영될 것으로 보입니다.

감사합니다.

NCP

[NCP] 네이버 클라우드에서 SSH Key 파일로 로그인 & 키 분실 시 트러블슈팅

안녕하세요. ManVSCloud 입니다.

오늘은 Naver Cloud Platform에서 AWS와 접속 방식이 동일하게 설정해보려 합니다.
(서버 생성 시부터 키가 생성되는 건 아닙니다…)

전에 이런 질문은 받은 적이 있었는데 갑자기 생각나서 작성하게 되었습니다.
“어? AWS에서는 key파일로 접속하던데 네이버 클라우드는 root로 접속이 바로 되고 패스워드로 로그인이 가능하네요. AWS처럼 root 계정 접속 막고 사용자 계정으로 접근할 수 없나요?”

일단 결론부터 말씀드리자면 가능합니다만… 키 관리를 상당히 잘 하셔야합니다.
키를 분실했을 경우 조금 번거로운 작업이 필요할 수 있습니다?!

그래도 그 방법에 대해 포스팅 해보도록 하겠습니다.


서버 생성과 계정 생성

우선 테스트는 VPC 환경에서 진행할 것입니다. 간단하게 서버 한 대만 만들어주면 됩니다.
사양은 크게 상관없습니다.

우선 서버 생성 후 받은 key 파일을 이용하여 root 계정 패스워드 확인 후 해당 서버로 접근합니다.

서버 접근 후 일반 사용자 계정을 생성합니다.
앞으로 root 계정 대신 이 계정으로 접근해야 root 권한을 가질 수 있도록 할 것입니다.
마치 AWS ec2-user 처럼요.

[root@manvscloud-dev-pub-kr1 ~]# useradd -c "NCLOUD Default User" -d /home/ncloud -s /bin/bash ncloud

[root@manvscloud-dev-pub-kr1 ~]# id ncloud
uid=1001(ncloud) gid=1001(ncloud) groups=1001(ncloud)

[root@manvscloud-dev-pub-kr1 ~]# gpasswd -a ncloud wheel
Adding user ncloud to group wheel
[root@manvscloud-dev-pub-kr1 ~]# gpasswd -a ncloud systemd-journal
Adding user ncloud to group systemd-journal

[root@manvscloud-dev-pub-kr1 ~]# grep -E "wheel|systemd-journal" /etc/group
wheel:x:10:ncloud
systemd-journal:x:190:ncloud

사용자 계정명은 ncloud로 했습니다.
생성 후에 필요한 그룹에 해당 계정을 추가해주긴했는데 사실 wheel에 굳이 추가해주지 않아도 /etc/sudoers에 등록해주면 됩니다.
(일반 사용자 계정은 1000부터인데 1001로 만들어집니다.
이는 nbpmon 계정때문인데 이 계정의 홈디렉토리로 가보면 네이버 클라우드에서 사용되는 에이전트와 관련된 계정인 것같습니다.)

[root@manvscloud-dev-pub-kr1 ~]# cat << EOF > /etc/sudoers.d/10-ncloud-users
# User rules for ncloud
ncloud ALL=(ALL) NOPASSWD:ALL
EOF
[root@manvscloud-dev-pub-kr1 ncloud]# chmod 440 /etc/sudoers.d/10-ncloud-users

위에서 말한 /etc/sudoers 입니다.
sudoers.d 아래에 10-ncloud-users 파일을 만들어 ncloud 계정에게 sudo를 사용할 수 있도록 허용해주었습니다.

NOPASSWD 를 주어 패스워드 없이 sudo를 사용할 수 있게 해줍시다.

[root@manvscloud-dev-pub-kr1 ncloud]# passwd -l root
Locking password for user root.
passwd: Success

마지막으로 root 계정을 Lock을 걸어줍시다.

여기까지 했다면 계정 관리부분에서 해주어야할 것은 마무리 됐습니다.


Key 파일 생성

[root@manvscloud-dev-pub-kr1 ~]# cd /home/ncloud/

이제 Key 파일을 생성할 것입니다.
우선 위에서 생성한 ncloud 계정의 홈 디렉토리로 이동 해줍시다.

[root@manvscloud-dev-pub-kr1 ncloud]# openssl genrsa -out master.pem 4096
Generating RSA private key, 4096 bit long modulus
..................................................................................++
.....................................++
e is 65537 (0x10001)
[root@manvscloud-dev-pub-kr1 ncloud]# chmod 600 master.pem
[root@manvscloud-dev-pub-kr1 ncloud]# chown ncloud:ncloud master.pem

openssl 명령어로 master.pem이라는 이름의 RSA Key 파일을 생성해주었습니다.

[root@manvscloud-dev-pub-kr1 ncloud]# mkdir .ssh
[root@manvscloud-dev-pub-kr1 ncloud]# ssh-keygen -y -f master.pem > .ssh/authorized_keys
[root@manvscloud-dev-pub-kr1 ncloud]# chmod 700 .ssh
[root@manvscloud-dev-pub-kr1 ncloud]# chmod 600 .ssh/authorized_keys
[root@manvscloud-dev-pub-kr1 ncloud]# chown -R ncloud:ncloud .ssh

마지막으로 ncloud 계정으로 로그인할 수 있도록 authorized_keys을 생성해줍시다!
이 설정으로 이제 ncloud 계정이 SSH로 접근할 때 필요한 key 파일 설정은 완료되었습니다.


sshd.config 수정

[root@manvscloud-dev-pub-kr1 ncloud]# cat -n /etc/ssh/sshd_config | grep -E "PermitRootLogin|PasswordAuthentication" | grep -v "#"
    38	PermitRootLogin yes
    65	PasswordAuthentication yes

마지막으로 현재 서버는 패스워드로 로그인이 가능한 상태입니다.
Key파일로만 로그인 할 수 있도록 설정할 것이며 패스워드로 로그인이 불가능하도록 막아봅시다.

위와 같이 명령어로 확인해보면 root로 로그인이 가능하며 패스워드로 접근될 수 있도록 설정되어있습니다.

변경 해줍시다.

[root@manvscloud-dev-pub-kr1 ncloud]# sed -i '38s/PermitRootLogin/#&/' /etc/ssh/sshd_config
[root@manvscloud-dev-pub-kr1 ncloud]# sed -i '65s/yes/no/g' /etc/ssh/sshd_config

38번 행 PermitRootLogin yes 부분 앞에 주석처리를 해주었고
65번 행에 yes를 no로 변경해주었습니다.

[root@manvscloud-dev-pub-kr1 ncloud]# sed -n '38p' /etc/ssh/sshd_config
#PermitRootLogin yes
[root@manvscloud-dev-pub-kr1 ncloud]# sed -n '65p' /etc/ssh/sshd_config
PasswordAuthentication no

변경한 뒤 결과를 보면 위와 같이 원하는 결과를 얻게됩니다.
이제 모든 설정이 끝났습니다.

[root@manvscloud-dev-pub-kr1 ncloud]# systemctl restart sshd

sshd를 재시작 해주고 이제 설정이 잘 되었나 확인해봅시다.


결과 확인

  • root 계정 로그인

root 계정으로 로그인을 하니 접속이 불가능합니다.
패스워드도 입력할 수 없고 이런 저런 키로 로그인 시도를 해보아도 선택된 사용자 키가 서버에 등록되어 있지 않다고 합니다.

이제 root로는 로그인을 할 수 없게되었습니다.

  • ncloud 계정 로그인

ncloud 계정으로 로그인 하였습니다.
접속 시 아까 만든 master.pem 키를 이용하여 접근하니 잘 접근이 되네요.

그리고 sudo su – 명령어로 root 권한도 얻을 수 있습니다.
AWS의 ec2-user와 접근 방식이 동일하게 되었네요.


키 분실 시 트러블슈팅

Naver Cloud Platform에서 KEY 파일로 SSH 로그인에 대해 알아보았습니다.

하지만 가끔 .ssh와 .ssh/authorized_keys 파일을 수정하시거나 잘못된 권한을 주어 문제가 생겼을 경우 또는 키 파일을 분실했을 경우, sshd 파일을 잘못 설정한 경우 등 다양한 원인으로
로그인에 문제가 생길 수 있습니다.

키 파일을 이용하시다가 만약 키를 분실하셨을 경우 어떻게 이를 해결할 수 는지 추가적으로 알아보도록 하겠습니다.

1. 우선 루트 볼륨을 떼어서 다른 서버에 붙일 수 없습니다.
→ 사실 이 방법이 가장 원인 파악하기 좋은데 루트 볼륨을 떼서 다른 서버에 붙일 수 없는 것이 조금 아쉽습니다.
(온프레미스의 경우 싱글 모드로 부팅하여 확인하거나 다른 서버에 장착하여 확인이 가능합니다.)

2. 루트 볼륨을 스냅샷으로 생성하여 restore 서버에 장착한다?
→ 우선 스냅샷으로 서버 생성은 되지 않습니다. 스토리지만 생성이 가능합니다.
이 말은 즉, 해당 스토리지 문제를 해결한다고 해도 위에서 말한 루트 볼륨 교체가 불가능하여 사실상 의미가 없습니다.

또한 원인 파악을 위해 다른 서버에 붙이더라도 루트 볼륨은 정상적으로 마운트 되지 않고
아래와 같은 에러가 발생하며 정상 마운트가 되지 않습니다.

[root@manvscloud-restore-pub-kr1 ~]# mount /dev/xvdb2 /restore
mount: wrong fs type, bad option, bad superblock on /dev/xvdb1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

3. 마지막으로 이미지 생성 후 복원하는 방법입니다.
→ 이미지로 생성 후 해당 이미지로 서버를 재생성하여 만들어도 sshd.config 파일에서
패스워드가 아닌 키 파일로만 접근이 가능하게 설정을 해두었기때문에 생성한 이미지로 서버를 재생성 하여도 콘솔에서 확인되는 root의 패스워드만 변경될 뿐 패스워드 입력 불가능 및 root 계정 Lock으로 로그인을 할 수 없습니다.

단, 원인을 알고 있다면 이는 충분히 복원이 가능합니다. 어떻게 가능하냐?!
바로 Init Script를 이용하는 것입니다.

원인이 .ssh와 .ssh/authorized_keys 수정인지, 권한 문제인지, sshd.config 파일 수정으로 인한 문제인지 어떤 것을 수정하였는지 정확한 원인을 모른다면 이 방법도 크게 해결 방안이라 보기 어렵지만 단순히 키 분실이라는 원인으로 해결을 원하신다면 아래와 같은 방법이 있습니다.

Server – Init Script
Init Script 생성
#!/bin/bash
passwd -u root
sed -i '38s/#//' /etc/ssh/sshd_config
sed -i '65s/no/yes/g' /etc/ssh/sshd_config
systemctl restart sshd

Init Script를 recovery-due-to-key-loss라는 이름으로 생성해주었습니다.

스크립트 내용은 간단합니다.
본문 내용에서 root 계정 Lock을 걸었던 것을 풀어주고 sshd_config에서 주석 처리 및 수정했던 값들을 다시 원래대로 수정하고 sshd를 재시작하는 것입니다.

만약 몇번째 행인지 알 수 없다면 스크립트를 아래와 같이 사용할 수도 있겠습니다.

#!/bin/bash
passwd -u root
sed -e '/PasswordAuthentication/s/^/#/g' -i /etc/ssh/sshd_config
echo PasswordAuthentication yes >> /etc/ssh/sshd_config
echo PermitRootLogin yes >> /etc/ssh/sshd_config
systemctl restart sshd

PasswordAuthentication라는 특정 문자열이 들어가는 라인을 전부 주석 처리하고
/etc/ssh/sshd_config 파일 아래에 PasswordAuthentication yes와 PermitRootLogin yes를
추가해준 뒤 sshd를 재시작하는 스크립트입니다.

키 분실 서버를 선택하여 ‘내 서버 이미지 생성’으로 이미지를 생성해줍니다.
서버 중지없이 이미지를 생성할 수 있으니 참고하시면 좋을듯합니다.

생성된 이미지로 서버를 아래와 같이 생성해줍니다.
서버 생성 화면에서 Script 선택 시 위에서 만들어준 Init-Script를 넣어주는 것이 포인트입니다.

이후 생성된 서버를 실행시켜보면 아래와 같이 root 접속 시 password로 접속할 수 있게 되며
접근도 가능하게 됩니다.

중요한 건… 이 방법 역시 원인을 알고 있을 경우 Init Script로 해결할 수 있는 것이지
원인을 모른다면 해결이 어려우니 이미지 백업을 주기적으로 하거나 중요한 데이터 스토리지는 루트 볼륨에 저장하기보다 스토리지를 분리하여 사용하는 것이 좋습니다.


마지막으로…

Naver Cloud, AWS, Azure, GCP, IBM, Oracle, 알리바바, 텐센트 등 상당히 많은 클라우드 플랫폼이 존재하게 되었습니다. 한국의 네이버 클라우드 역시 새로운 기능들이 재빠르게 추가되며 무서운 성장속도를 보여주는 것같습니다. 아직 원하는 기능들과 바라는 점들이 있지만 그런 부분들도 어서 추가되었으면 하는 바람입니다.

데이터를 국내에 보관할 수 있다는 점도 좋지만 무엇보다 모든 설명서나 소개, 웨비나, 교육들이 한국어로 진행되다보니 습득하는데에 큰 어려움이 없다는 점과 이 가장 매력인듯합니다.

이상 네이버 클라우드에서 SSH KEY 파일로 로그인 하는 방법과 키 분실 시 트러블슈팅 방법에 대해 알아보았습니다. 다음 포스팅은 더욱 알찬 내용으로 찾아뵙겠습니다.

긴 글 읽어주셔서 감사합니다.

NCP

[NCP] Load Balancer 사용 시 웹서버 로그에서 Client IP를 볼 수 있을까?

안녕하세요. ManVSCloud 김수현입니다.

오늘은 Naver Cloud Platform에서 LOAD BALANCER 사용 시에 웹서버 내 로그에 찍히는 IP가 Client IP가 찍히도록 설정하는 방법에 대해 포스팅 하겠습니다.

HTTP 헤더 중 하나인 X-Forwarded-For를 이용하는 방법과 각 소프트웨어의 모듈을 이용하여 Client IP를 식별하는 방법 두 가지에 대해서 알아보겠습니다.


테스트 기본 세팅

해당 이미지를 더블 클릭하시면 큰 화면으로 이미지를 자세히 볼 수 있습니다.

저는 VPC 환경에서 테스트를 진행하였습니다.
(Classic도 동일한 방법으로 가능합니다.)

centos-7.8-64로 생성해주었습니다.
서버 생성 후 Apache를 설치합니다.

[root@manvscloud-web-pub-kr2 ~]# yum install httpd httpd-devel -y
[root@manvscloud-web-pub-kr2 ~]# systemctl enable httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
[root@manvscloud-web-pub-kr2 ~]# systemctl start httpd

테스트 준비는 끝났습니다.
이제 LB가 없을 때, X-Forwarded-For를 사용할 때, 각 소프트웨어의 모듈을 사용할 때에 대해서 살펴보겠습니다.


Load Balancer가 없을 때

우선 Load Balancer가 없을 때 해당 서버로 접근 할 경우 정상적으로 Client IP가 찍힙니다.
(Client – Server)


Load Balancer를 추가했을 때

Application Load Balancer로 생성하였습니다.
index.jsp → index.html
tail -f /var/log/httpd/access_log

Load Balancer를 추가하게되면 위와 같이 Client IP가 아닌 LB의 사설 IP가 찍히게 됩니다.
(Client – LB – Server)

이제 LB가 있는 상태에서 Client IP를 볼 수 있도록 설정해보겠습니다.


X-Forwarded-For

[root@manvscloud-web-pub-kr2 html]# grep -n LogFormat /etc/httpd/conf/httpd.conf 
196:    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
197:    LogFormat "%h %l %u %t \"%r\" %>s %b" common
201:      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio

Apache의 LogFormat을 보면 현재 위와 같이 되어있습니다.
이 LogFormat을 조금 변경해줄 것입니다.

vi /etc/httpd/conf/httpd.conf 를 이용하여 196 라인에 LogFormat을 아래와 같이 변경 해주겠습니다.

    196     LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

기존 LogFormat 가장 앞부분에 %{X-Forwarded-For}i 을 추가해준 것입니다.
이를 추가해준 뒤에 Apache 재시작 1회 진행 후 다시 한 번 로그를 확인해보면 Client IP가 찍히게 됩니다.

웹 접속 시 Client IP가 추가된다.

이 설정은 Apache 뿐만 아니라 Nginx, Tomcat에서도 당연히 설정이 가능합니다.
아래 링크를 참고하면 좋을듯합니다.


Network Proxy Load Balancer

이제 Apache와 Nginx에 모듈을 추가하여 Client IP 식별하는 방법에 대해 알아볼 것입니다.

모듈을 설명하기 앞서 기존에 사용하던 ‘애플리케이션 로드밸런서’에서
‘네트워크 프록시 로드밸런서’로 변경해줄 것입니다.

LB 생성은 크게 다를 것이 없습니다.
다만 Target Group에서 조금 다르게 설정을 해줄 것입니다.

프로토콜은 PROXY_TCP로 해줍니다!
그리고 TargetGroup 설정에서 ProxyProtocol을 클릭해줍니다.

콘솔에서 해줄 작업은 이걸로 끝입니다. 이제 모듈을 추가하러 갑시다!


Apache Module

[root@manvscloud-web-pub-kr2 src]# apachectl -M | grep myfixip

Apache에서는 myfixip 모듈을 이용할 것입니다.
해당 모듈의 경우 기본 내장 모듈이 아니라 아래와 같이 추가해주어야합니다.

[root@manvscloud-web-pub-kr2 html]# cd /usr/local/src
[root@manvscloud-web-pub-kr2 src]# wget --no-check-certificate https://raw.githubusercontent.com/ggrandes/apache24-modules/master/mod_myfixip.c
[root@manvscloud-web-pub-kr2 src]# apxs -aic mod_myfixip.c 
[root@manvscloud-web-pub-kr2 src]# apachectl -M | grep myfixip
 myfixip_module (shared)

myfixip_module이 추가된 것을 확인할 수 있습니다.
이제 httpd.conf에 해당 모듈을 추가해주고 사용할 것입니다.

[root@manvscloud-web-pub-kr2 ~]# cat << EOF >> /etc/httpd/conf/httpd.conf
> LoadModule myfixip_module modules/mod_myfixip.so
> <IfModule mod_myfixip.c>
> RewriteIPResetHeader off
> RewriteIPAllow 10.0.0.0/16  
> </IfModule>
> EOF
[root@manvscloud-web-pub-kr2 ~]# systemctl restart httpd

RewriteIPAllow은 Load Balancer가 있는 대역을 추가해주면 됩니다.
위에서 추가한 Proxy LB로 접속하게 되면 이제 아래와 같이 Log가 남습니다.

Apache myfixip

정말 깔끔하게 Client IP가 보이고 있습니다.
이제 Apache와 함께 많이 사용되고 있는 Nginx에서 설정을 해보겠습니다.


Nginx Module

우선 Nginx는 아래 내용을 참고하면 간단하게 설치가 가능합니다.

[root@manvscloud-web-pub-kr2 ~]# vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1
[root@manvscloud-web-pub-kr2 ~]# yum install nginx
[root@manvscloud-web-pub-kr2 ~]# systemctl start nginx

Nginx에서의 설정도 어렵지 않습니다.
Nginx에서는 realip module이 있는지 확인해주어야합니다.

nginx -V 2>&1 | grep 'http_realip_module'
해당 이미지와 같이 모듈이 존재한다면 준비는 완료되었습니다.

vi /etc/nginx/nginx.conf 로 nginx의 config파일을 아래와 같이 변경해줄 것입니다.

#    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
#                      '$status $body_bytes_sent "$http_referer" '
#                      '"$http_user_agent" "$http_x_forwarded_for"';

    log_format  main  '$proxy_protocol_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';


        proxy_set_header X-Real-IP         $proxy_protocol_addr;
        proxy_set_header X-Forwarded-For   $proxy_protocol_addr;

        server
        { 
                root    /usr/share/nginx/html;
                listen 80  proxy_protocol;
                set_real_ip_from 10.0.2.0/24;
                real_ip_header proxy_protocol;     
        }

기존 log_format은 주석처리하고 그 아래에 전부 새로 추가한 내용들입니다.

  1. $remote_addr$proxy_protocol_addr로 변경해줍니다.
  2. proxy_set_header을 추가해줍니다.
  3. proxy protocol과 real_ip 설정도 해줍니다.

설정이 끝난 뒤 nginx를 1회 재시작하고 로그를 확인해봅니다.

Apache와 동일하게 Nginx도 Proxy LB로 접속하면 Client IP가 그대로 남는 것을 확인할 수 있었습니다.

이로써 LOAD BALANCER 사용 시에도 웹서버 로그에서 CLIENT IP를 볼 수 있다는 것을 알 수 있습니다.
이 글을 읽으시는 분들께서도 해당 포스팅을 참고하여 서버에서 Client IP가 보이도록 설정해보시는 건 어떠신가요?

웹 로그에서 Client IP를 확인하는 일은 꽤 많은 것같습니다.
가끔 MaxClients 설정이 낮지않은데 MaxClients 수치보다 많은 프로세스로 인해 확인을 해보면 특정 IP가 ESTABLISHED와 CLOSE_WAIT 을 반복하여 대량의 CLOSE_WAIT를 남겨 MaxClients가 순식간에 늘어나는 것을 많이 보았습니다.

그 특정 IP를 log파일에서 여러 명령어와 조합하여 wc -l 로 뽑아내면 공격성 및 이상 접근으로 의심되는 접근을 빠르게 판단하고 차단 / 조치 할 수 있게되는 것 같습니다.

해당 포스팅은 여기서 마무리해보려 합니다.

긴 글 읽어주셔서 감사합니다.

IT/Linux/Kubernetes

Rocky Linux 8.3 Release Candidate 1 출시 / Test Installation

안녕하세요. ManVSCloud 김수현입니다.

어제 일자로 기다리던 ROCKY LINUX 8.3 RELEASE CANDIDATE 1이 출시되었습니다.
아직 불안정한 시험판으로 나오긴 했으나 상당히 기대되지 않을 수 없습니다.

Rocky Linux 는 CentOS 프로젝트의 창시자인 Gregory Kurtzer 가 시작한 프로젝트로 현재의 CentOS 처럼 RHEL 의 공개 소스를 가져와서 다시 빌드하고 패키징하는 것을 목표로 하고 있으며 심지어 RHEL 의 버그까지 똑같이 재연하는 것을 목표로 하고 있습니다.

레드햇 측에서 CentOS 프로젝트가 CentOS 8 지원을 2021 년 말에 종료하는 것을 발표했었습니다. CentOS 7 버전이 2024 년까지 계속 지원될 예정이지만 CentOS 8의 지원 종료 기간이 2021년 12월 31일로 정해지며  Red Hat Enterprise Linux 8 에 대한 무료 배포판 역할이 사라지게 된 것입니다.

물론 아직까지 지원 종료가 되어버린 CentOS4,5,6을 사용하는 유저들도 존재하는 것으로 알고있습니다. 2024년도 이후 CentOS 7 마저 지원이 종료된다면 보안 패치의 부재와 Repo 중단으로 많은 불편함이 존재할 것입니다.

기존 CentOS 8 유저나 OS 버전 업이 필요할 경우 CentOS Stream으로 전환이 필요하게됩니다.

https://www.lesstif.com/lpt/centos-8-centos-stream-98927171.html

CentOS 가 종료되고 CentOS Stream 로 전환되는 22년부터는 아래와 같은 관계가 됩니다.

https://www.lesstif.com/lpt/centos-8-centos-stream-98927171.html

즉, 안정성 입증이 어려워졌고 신뢰성이 떨어진 현재 CentOS를 더 사용하기 애매해져버린 상황입니다.

오늘은 어제 발표된 ROCKY LINUX 8.3 RELEASE CANDIDATE 1을 간단하게 설치해보는 것까지 진행해볼 것이고 이후 서비스 운영부분까지 테스트해볼 예정입니다.


설치

설치는 간단하게 “Rocky-8.3-x86_64-minimal” 로 설치했습니다.
좌측에 Rocky Linux가 매력있는 듯합니다.

아직 정식 출시가 아닌 RC라 개발 및 테스트 목적으로만 사용하시길 바랍니다.

설치 및 부팅 후 CLI 콘솔 화면에서 Rocky 로고가 나옵니다.
Rocky Linux 설치 시 cockpit이 설치가 되어있나봅니다.

  • cokpit : Web UI 기반의 모니터링 및 관리 툴입니다.
원래는 9090포트입니다. (포트포워딩 해둬서 9999상태)
[아래 네트워크 작업을 한 뒤 확인 한 것]

NAME이 Rocky Linux로 나오네요.
멋있습니다.

네트워크 설정을 간단히 마쳐주고 간단하게 이런저런 설치만 해보았습니다.

Rocky Linux 8.3 AppStream 에서 dnf 로 php 설치 시 기본 버전이 7.2로 되어있습니다.

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm

위 명령어처럼 EPEL 저장소를 추가해주어야 dnf module list php 명령어를 입력했을 때 추가 버전을 확인할 수 있을 것입니다.

그외에도 ImageMagick을 설치 시 –set-enabled powertools 을 해주어야하는 부분 역시 CentOS 8과 동일했습니다.

dnf install -y epel-release
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
dnf config-manager --set-enabled powertools
dnf install -y ImageMagick ImageMagick-devel
pecl install imagick
echo "extension=imagick.so" > /etc/php.d/20-imagick.ini
cat /etc/php.d/20-imagick.ini

# Repo 추가 및 사용 방법도 CentOS8과 동일함

vi /etc/yum.repos.d/MariaDB.repo

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.5/centos8-amd64
module_hotfixes=1
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

dnf install MariaDB-server MariaDB-client –disablerepo=AppStream

그 외에도 이런 저런 간단한 설치들을 하는데에 크게 문제없이 잘 되는듯보였습니다.
간단한 설치 테스트는 여기서 마치고 이후에는 CentOS 7에서 서비스를 CentOS8로 이전, 서비스 정상 작동 여부까지 확인 해볼 것입니다.


후기

오래 전부터 기다리고 있던 Rocky Linux의 RC 1 이 나와서 정말 기뻤습니다.
이번 설치 테스트 때 GUI 설치 후 GUI 구경을 못해본 게 아쉬운데 다음 테스트 때 설치해서 구경해야겠습니다.

Rocky Linux의 정식 출시를 응원하며 글을 마무리하도록 하겠습니다.

긴글 읽어주셔서 감사합니다.

NCP

[NCP] NAVER Cloud Platform Certified Professional 도전

안녕하세요. ManVSCloud 김수현입니다.

오랜만에 포스팅을 하게되는 것같습니다.
올해도 2020년도와 같이 바쁜 4월을 보내고 있어 벌써부터 연말이 기대됩니다.

요즘엔 NCP의 Associate의 다음 단계인 Professional Level의 시험을 진행하고 있습니다.


NAVER Cloud Platform Certified Professional

Professional 시험은 Associate의 시험과 다르게 3번의 시험을 치르게 됩니다.
각 과목별 5만원의 비용이 발생하며 과목의 종류는 아래와 같이 나뉩니다.

또한 기존 NCA 시험과 차이가 있다면 Pro 시험부터는 실기 시험이 포함된다는 점입니다!
이론 뿐만이 아니라 충분한 실습 경험이 있어야 쉽게 시험에 합격하실 수 있을 것입니다.

  • Overview
    Compute/Storage
  • Network/Media
    Database/Management/Analytics
  • Troubleshooting

현재 3개의 시험 중 2개의 과목은 합격하였으며 Overview/Compute/Storage 시험만 남겨두고 있습니다.

처음 본 시험은 Network/Media/Database/Management/Analytics 시험이었는데
무난히 필기를 보고 실기에서 조금 당황하여 시간 내에 겨우 마무리 하게 되었습니다.
하지만 두번째 시험은 Troubleshooing 시험은 대체로 실무자 입장에서는 난이도가 낮은 편이라 편한 시험이었습니다. 확실히 Troubleshooting 시험을 합격하기 위해서는 어느정도 실무경험이 없는 상태에서 시험을 보게 된다면 문제를 보자마자 조금 당황할 수 있겠구나라는 생각이 들었습니다. 말 그대로 Troubleshooing 시험이었습니다.

각 시험마다 실기 시험이 있다보니 평소에 실습을 많이 해보는 것이 필요합니다.

네이버 클라우드에서는 교육 및 행사 일정을 보게되면 꽤 많은 교육이 무료로 이루어지고 있습니다. NAVER CLOUD PLATFORM Hands-on Lab부터 차근 차근 실습이 이루어지는 교육을 들어보시고 기본적인 생성과 각 서비스의 사용법을 터득하셨다면 Professional에 도전해보셔도 될 것같습니다.


Helpful Sites


앞으로의 시험 일정

5월 11일에 NAVER Cloud Platform Certified Professional 마지막 시험이 진행될 것같습니다.

이후 6월에 일정상 미뤄왔던 AWS Solutions Architect Professtional을 마무리 지을 생각이며
7~8월에 Certified Kubernetes Administrator 시험을 계획하고 있습니다.

학점이 필요해 국내 시험도 같이 준비할까하여 최근에 네트워크 관리사 2급도 알아보았습니다. 올해 2월 시험을 한 번 풀어봤는데 따로 준비 없이 합격이 되어 5월 30일에 있는 시험을 보러다녀올 생각입니다.

올해말까지 AWS Advanced Networking과 Security까지 생각중이며
내년부터는 개발쪽을 추가적으로 공부해볼 예정입니다.

NAVER Cloud Platform Certified Professional 자격증과 이후 추가적인 포스팅으로 찾아뵙겠습니다.

긴 글 읽어주셔서 감사합니다.

AWS

[AWS] CloudFront 캐시 적중률 늘리기 (cache hit ratio)

안녕하세요. ManVSCloud 김수현입니다.

오늘은 ANOS 2기 스터디 후 6주차 CloudFront 과정을 마친 후 예정되어 있던 포스팅으로
CloudFront 캐시 적중률 늘리기에 대한 주제로 글을 써보려합니다.

이 포스팅을 준비하기 위해 생각보다 많은 공부를 하게되어 생각보다 시간이 소요되었지만 평소한 것들보다 만족스럽다는 생각이 들었습니다.

그럼 [AWS] CLOUDFRONT 캐시 적중률 늘리기 (CACHE HIT RATIO)에 대해 알아보겠습니다.


What is Cache?

캐시 메모리, 캐시 저장소, 캐시 서버 등 캐시는 무엇을 말하는 것일까요?
캐시는 쉽게 말하면 임시로 저장해두는 장소라고 말할 수 있겠습니다.

이 캐시로 인해 우리는 평소보다 조금 더 빠르게 접근이 가능하게되는데
Cache Hit 상태라면 우리가 원하는 것을 Cache가 가지고 있는 것이며
Cache Miss는 Cache가 아직 그것을 가지고 있지 않는 상태입니다.

Cache에 대해서는 이 정도로만 간단히 설명하고 다음으로 넘어가겠습니다.


What is CloudFront?

Fast or Slow 사이트에서 제 테스트 웹 페이지 하나에 대해 속도 측정을 해보았습니다.
(위 링크에서 여러분들의 웹 사이트를 속도 측정 할 수 있습니다. (해외 차단 시 불가))

출발한 패킷이 해외 지역에 도달하는데에 걸리는 시간이 각각 다른 것을 알 수 있습니다.
우리는 이 시간을 Latency라고 부르며 출발지와 거리가 멀 수록 Latency가 크게 발생하게 됩니다.

아프리카와 유럽쪽의 응답시간이 다른 지역에 비해 더 늦다는 것을 확인할 수 있습니다.
반면 한국과 가까운 일본이나 홍콩은 다른 지역보다 빠릅니다.

그렇다면 해외 서비스를 운영할 때 발생하는 컨텐츠의 느린 응답 속도를 해결할 수 있는 방법은 없는 것일까요?

그렇지 않습니다. 이를 해결하기 위해 Contents Delivery Network(CDN)을 이용한다면
지리적 또는 물리적으로 떨어진 대상에게 컨텐츠를 빠르게 제공이 가능해집니다.

CDN 사이트 테스트 시 이전 사이트의 Latency에 비해 비교적으로 낮아진 값을 확인할 수 있었습니다.
또한 CDN 업체의 각 CDN Node로 인해 보다 빠른 통신이 가능하다는 것을 알 수 있었습니다.

CDN을 사용한다면 해외 사용자가 컨텐츠를 다운로드 할 때 Origin에서 직접 컨텐츠를 가져오지 않고 주변 CDN 서버에서 컨텐츠를 가져오므로 속도 보장은 물론 국제 회선으로 발생하는 비용 역시 절감할 수 있게 됩니다.

CloudFront는 CDN 서비스를 제공합니다. 또한 CloudFront는 엣지 로케이션 215개 이상, 리전별 중간 티어 캐시 12개의 글로벌 네트워크를 사용하여 캐싱을 통해 짧은 지연 시간과 높은 처리량 및 안정적인 네트워크 연결(부하 분산)이 제공됩니다.

이런 CDN에 대해 관심이 많으시다면 GSLB 기술에 대해 한 번 알아보는 것도 나쁘지 않을 것같아 링크 추가해봅니다.

세계 지도 png에서 kor.pngtree.com

Cloudfront의 전체를 그림 하나로 표현하기에 부족하겠지만 한 번 만들어보았습니다.

캐싱 데이터가 생성된 Edge로 인해 안전성, 비용, 속도를 보장 받을 수 있으니 Cloudfront는 무조건 사용해야한다?, Cloudfront만 사용하면 무조건 빠르다? 는 정답이 될 수 없습니다.

무조건 사용하지 않습니다. 잘 사용해야합니다.
또한 서비스의 속도는 오직 캐싱만으로 결정되지 않습니다.
Rendering, 압축, 개발 소스 등 역시 속도의 원인이 될 수 있으며 최신화를 위해 정적/동적 데이터 구분하여 설정 및 캐싱 예외 처리, TTL 등 고려해야할 사항이 많습니다.

하지만 이 포스팅의 주제는 Cloudfront의 캐시 적중률을 어떻게하면 높일 수 있을까에 대한 주제이므로 캐시 적중률을 높일 수 있는 방법에 대한 내용을 중점으로 다루겠습니다.


How can CloudFront cache hit rate be increased?

CloudFront의 캐시 적중룔, 어떻게하면 높일 수 있을까요?

AWS 가이드에서는 총 7가지가 있다고 합니다.

CloudFront에서 객체를 캐시하는 기간 지정
Origin Shield 사용
쿼리 문자열 매개 변수를 기반으로 한 캐싱
쿠키 값에 따른 캐싱
요청 헤더 기반 캐싱
압축이 필요하지 않은 경우 Accept-Encoding 헤더 제거
HTTP를 사용하여 미디어 콘텐츠 제공

7가지 중 3가지 정도만 자세히 알아보도록 하겠습니다.
(다소 양이 방대하기때문에 나머지는 최하단 Docs 링크 추가해두었으니 참고 부탁드립니다.)


▶ CloudFront에서 객체를 캐시하는 기간 지정

첫번째 방법으로 CloudFront에서 객체를 캐시하는 기간을 지정해주는 것입니다.
Cache-Control max-age의 수치가 길면 길수록 캐시 적중률이 높아집니다.
다만 오리진이 아닌 캐시된 파일을 불러오기에 객체 최신화에 문제가 있습니다.
그렇다면 Cache-Control max-age 수치를 어떻게 주면 좋을까요?

우선 TTL과 Cache-Control에 대해서 알아봅시다.

브라우저 캐시 TTL은 최종 사용자 브라우저가 리소스를 캐시하는 시간입니다.
이 리소스의 경우 TTL이 만료 될 때까지 브라우저 로컬 캐시에서 제공하며 만료 시 브라우저가 재요청을 하게됩니다. 이때 TTL은 해당 컨텐츠가 있는 원본 서버의 Cache-Control을 참고하게 됩니다. 예를들어 원본 서버에서 Cache-Control 설정이 public; max-age=60로 설정되어있을 경우 60초의 시간 동안 브라우저 로컬 캐시에 저장됩니다.

Cache-Control은 응답을 캐시할 수 있는 사용자와 해당 조건 그리고 기간을 제어하는데
즉, 웹 컨텐츠 캐시 정책을 컨트롤 하는 지시문이라 볼 수 있습니다.

Cache-Crontrol에 대한 링크를 추가하였으니 참고하시면 좋을듯합니다.

Cache-Control 설정은 웹 사이트 성능 최적화에 중요한 역할을 합니다.
Cache-Control은 컨텐츠 유형별로 다른 설정을 해준다면 웹 사이트 성능 최적화에 좋은 결과를 기대할 수 있을 것입니다.

컨텐츠 유형은 크게 정적 컨텐츠(Static Contents)와 동적 컨텐츠(Dynamic Contents)로 나뉩니다.

정적 컨텐츠는 css, js, png, jpg, html 파일 등이 대표적이며, 동적 컨텐츠는 업데이트가 잦아 항상 최신화가 필요하거나 요청마다 다른 응답을 주어야하는 리소스들이 되겠습니다.

정적 컨텐츠는 제가 포스팅 시 업로드한 이미지,영상 파일들이나 우리가 흔히 게임을 하기위해 다운로드를 받는 소프트웨어의 경우 TTL이 높아도 상관이 없습니다.
다만 우리가 보는 뉴스 기사들은 TTL이 높을 경우 빠르게 최신 뉴스를 볼 수 없게 될 것입니다. 그러므로 각 컨텐츠 별로 다르게 설정적 컨텐츠는 제가 포스팅 시 업로드한 이미지,영상 파일들이나 우리가 흔히 게임을 하기위해 다운로드를 받는 소프트웨어의 경우 TTL이 높아도 상관이 없습니다.다만 우리가 보는 뉴스 기사들은 TTL이 높을 경우 빠르게 최신 뉴스를 볼 수 없게 될 것입니다. 그러므로 같은 정적 컨텐츠라도 다르게 설정해줄 필요가 있겠습니다.

제 블로그에 올라간 이미지 파일들은 이미지가 변경되어야 할 이유가 크게 없습니다.
이 경우 아래와 같은 예시로 Cache-Control을 사용할 수 있겠습니다.
예시) max-age = 31536000;(브라우저) 또는 s-maxage=86400(프록시와 같은 공유 캐시에만 적용)
max-age의 최대치는 31536000 입니다.

날씨와 같이 1분 주기로 최신화를 하고 싶다면 아래와 같이 할 수 있겠습니다.
예시) public; max-age=60 또는 no-cache; max-age=60 등의 방법

동적 컨텐츠는 항상 최신화가 필요할 것입니다.
항상 최신화를 위해 아래 예시의 방법이 있습니다.
예시) no-cache, max-age=0 또는 private, no-store 등의 방법

제 블로그 역시 Cache-Control이 적용되어있습니다.

Apache를 이용하여 Cache-Control 헤더를 사용한다면 .htaccess를 이용하여
아래와 같은 방법을 사용할 수 있습니다.

<filesMatch ".(ico|jpg|jpeg|png|gif)$">
 Header set Cache-Control "max-age=2592000, public"
</filesMatch>

<filesMatch ".(css|js)$">
 Header set Cache-Control "max-age=86400, public"
</filesMatch>

제 블로그의 이미지 파일들은 AWS S3에 있습니다.
그렇다면 이 S3에 있는 이미지 파일들에게 Cache-Control 설정은 해줄 수 없을까요?

가능합니다.
우선 S3의 해당 버킷을 선택한 뒤Cache-Control을 설정할 파일 또는 디렉토리를 선택합니다.
그리고 [작업]-[작업 편집]-[메타데이터 편집]을 선택 클릭하면 메타데이터 편집을 통해
Cache-Control을 수정 및 설정할 수 있습니다.

자 그럼 이제 CloudFront에서 객체를 캐시하는 기간을 설정하는 방법에 대해 알아 보겠습니다.

Cloudfront의 [Behaviors]에서 설정할 수 있습니다.

또한 아래 사진처럼 Create Behavior로 Path Pattern을 나누어 우선 순위를 설정한 뒤 각 경로나 파일마다 다르게 설정할 수도 있습니다.

수정이 필요한 Behavior를 선택 후 [Edit]을 누르면 아래와 같은 창으로 이동합니다.
Cache and origin request settings을 선택해줄텐데 직접 수정하려면 아래
[Use legacy cache settings]를 선택해주어야합니다.

[Use a cache policy and origin request policy]를 선택하여 Managed-CachingOptimized를 사용할 경우 관리형 캐시 정책에 대한 아래 Docs를 참고하면 되겠습니다.

legacy cache settings를 선택할 경우 아래 추가로 입력할 수 있는 창이 생깁니다.
Object Caching을 Customize로 체크해줄 경우 아래 TTL 값을 원하는 값으로 수정이 가능하게됩니다.

* [참고] Cache Based on Selected Request Header가 요청 헤더 기반 컨텐츠 캐싱을 지정해주는 것이고 Query String Forwarding and Caching은 쿼리 문자열 매개 변수를 기반으로 한 캐싱, Forward Cookies가 쿠키 값에 따른 캐싱에 해당됩니다. 아래에서 Query String Forwarding and Caching에 대해 추가로 다룰 예정입니다.

지금까지 위에서 다룬 TTL 값을 변경하는 방법을 알아보았습니다.
다만 다음과 같은 특이 케이스가 있을 것입니다.

??? : ” 정적 컨텐츠였는데 지금 이미지 하나를 급하게 최신화 해야합니다. 하지만 Cloudfront에 기존 TTL 값이 너무 높게 설정이 되어있습니다. 어떻게 방법이 없을까요? “

있습니다. [Invalidation]을 사용한다면 캐시가 만료되기 전에 파일의 내용을 갱신할 수 있습니다. 이는 캐시 무효화 기능인데 CloudFront Edge 로케이션에 저장된 캐시를 삭제해줍니다.

여기까지 CloudFront에서 객체를 캐시하는 기간을 지정하여 캐시 히트율을 높이는 첫번째 방법에 대해 알아보았습니다.


▶ Origin Shield 사용

두번째 방법으로는 Origin Shield를 사용하는 방법이 있겠습니다.
Origin shield는 CloudFront 캐싱 인프라의 추가 계층으로 Origin 앞에 추가적인 캐싱 계층을 제공해줍니다. 모든 캐싱 계층에서 Origin에 대한 모든 요청이 Origin shield를 통과하기에 CloudFront 배포의 캐시 적중률을 개선하는데 큰 도움이됩니다.

또한 Origin의 부하를 최소화하며 가용성을 높여 운영 비용을 줄이는 데에 큰 도움이 됩니다.
캐시에 없는 컨텐츠에 대한 요청은 동일한 객체에 대한 다른 요청과 통합되어 Origin으로 가는 요청이 하나만 발생하게 되는데 이로 인해 동시 요청 수를 줄일 수 있으며 최대 로드, 트래픽 급증 중에 Origin의 가용성을 유지할 수 있고 동적 패키징, 이미지 변환 및 데이터 전송과 같은 비용을 줄일 수 있습니다.

Feb 20, Origin Shield 사용 전 (21일에 적용)
Feb 23, Origin Shield 사용 2일 후 (21일에 적용)

(포스팅 당일은 캐싱되지 않은 새로운 컨텐츠가 존재하여 cf-cache-status : MISS가 발생할 수 있습니다.)

제 블로그에 적용 당시 Origin shield입니다.
적용 후 그래프의 캐시 적중률(Hits)이 상승한 것을 볼 수 있습니다.

Origin Shield 설정 – 1
Origin Shield 설정 – 2

위와 같은 방법으로 Origin Shield 설정이 가능합니다.

그외에도 Origin Shield는 CloudFront의 리전 엣지 캐시를 활용하며 CloudFront 위치에서 Origin Shield 로 연결할 때 각 요청에 대해 활성 오류 추적을 사용하여 Default Origin Shield 를 사용할 수없는 경우 요청을 보조 Origin Shield 위치로 자동 라우팅하므로 고 가용성까지 갖췄습니다.


▶ 요청 헤더 기반 캐싱

마지막으로 요청 헤더 기반 캐싱에 대해 알아보겠습니다.

위에서 언급했듯 요청 헤더 기반 캐싱은 Behavior을 [Edit] 시Query String Forwarding and Caching를 선택할 수 있습니다.

이는 Query String을 캐시 구분자로 사용할지 물어보는 것입니다.

# None(캐시 향상) : 이를 선택할 경우 모든 쿼리스트링에 대해 캐시합니다.
# Forward all, cache based on whitelist : whitelist를 선택하여 값을 입력할 경우 whitelist에 입력된 쿼리스트링에 대해서만 캐시가 되지 않고 나머지는 캐시가 됩니다.
# Forward all, cache based on all : all을 선택하게 되면 캐시를 하지 않게됩니다.

None과 all은 캐시 된다/안된다이니 whitelist를 잘 써야봐야겠습니다.
아래 사진으로 예를 들어보겠습니다.

제 블로그는 도메인명 뒤에 ?p가 붙습니다.
ex)https://manvscloud.com/?p=612

만약 제가 포스팅되는 글들은 캐시되지 않고 오리진에서 최신화하여 불러왔으면 좋겠다고 했을 때 위와 같이 설정해줄 수 있습니다.
whitelist에 p를 넣어주면 https://manvscloud.com/? 뒤에 p의 쿼리스트링에 대해서 캐시하지 않고 항상 최신화하게 됩니다.

그렇다면 이 쿼리스트링을 여러개 사용해야한다면 어떤 방법이 있을까요?
예를 들어 이미지가 요청할 때마다 항상 다른 사이즈로 리사이징되어야 하는 경우입니다.

첫 요청 시 /?w=200&h=150&f=webp&q=90 으로 요청했는데
이후 /?w=100&h=300&f=webp&q=90으로 요청이 올 경우 바로 리사이징 된 이미지를 보여주어야합니다.

위와 같은 방법을 사용할 수 있습니다.
각 w,h,f,q 쿼리스트링에 대한 whitelist를 입력하여 해당 쿼리스트링 요청 시 캐싱되지 않고 오리진에서 불러올 수 있도록하는 것입니다.

이 방법을 사용한다면 원하는 것만 최신화 하고 나머지는 항상 캐싱되니
캐시를 잘 사용한다고 볼 수 있겠습니다.

캐시 적중률이 높다는 것은 hit율만 높고 최신화가 되지 않는 것을 말하는 것이 아닙니다.
최신화 되어야할 부분은 최신화 되면서 캐싱이 되어야 비로소 캐시가 잘 적중했다라고 생각됩니다.

지금까지 캐시 적중률을 높이는 3가지 방법에 대해 자세히 알아보았습니다.
이 외에도 나머지 4가지 방법이 더 있습니다.
제일 하단 링크에 추가된 링크를 통해 나머지 4가지 방법도 찾아보시길 바랍니다.


Opinion

검색 엔진 최적화(SEO)에는 웹 사이트 속도와 상관 관계가 있다고 합니다.
조사에 따르면 웹 페이지가 출력되는데에 4초 이상이 소요될 경우 75%의 사람들은 이미 해당 웹 사이트를 종료한다고 합니다.

캐시 적중률을 높여 웹 페이지의 속도를 빠르게 해보시는 것은 어떠신가요?
많은 분들에게 도움되는 포스팅이 되었길 바랍니다.

(원래 추가로 Cloudfront + Lambda@Edge를 활용한 Image Resizing에 대한 포스팅도 첨부하여 이미지 리사이징을 통해 SEO 최적화하는 방법을 더하려 했으나… 왜 안되는지 잘 모르겠습니다?… )

CloudFront의 캐시 적중률을 높여보자는 게 그만 내용이 꽤 길어졌습니다.
처음에 작성하려 했던 양보다 훨씬 많아졌네요…
7가지 중에 3가지만 했는데도 이 정도 양이니…
나머지 4개는 제가 여러분들에게 드리는 숙제인걸로…!
찾아보면서 공부하는 재미가 있더라구요😋 홧팅!!

다음 AWS 공부는 Elasticache나 Elastic Beanstalk을 생각하고 있지만 곧 NCP 시험과 Kubernetes 일정으로 인해 다음 AWS 포스팅까지는 다소 시간이 걸릴듯합니다.

긴 글 읽어주셔서 감사합니다.


References