Woo DEV

[정보보안] SSL 인증서의 동작 원리 및 종류 (+암호화 원리, 유형, 알고리즘)

cwpack0730 — Fri, 31 Jan 2025 17:36:09 +0900

개요

인프라팀에서 근무하며 서비스의 모든 도메인과 SSL 인증서 관리를 진행했었는데, 구매부터 발급, 갱신, 적용 과정을 직접 진행했던 기억이 난다.

작업했던 시스템 별 인증서 적용 방식의 차이(Nginx, Tomcat 등 서버, AWS, NCP 등 클라우드 서비스 등)와 인증서 종류(단일, 와일드카드 등 인증서 유형부터 EV,OV,DV 등 인증서 등급까지)등 내가 경험했던 내용에 대입하여 SSL 인증서의 기본적은 개념과 원리를 한번 되짚어 보려 한다.

1. SSL이란?

SSL(Secure Sockets Layer)은 암호화 기반 인터넷 보안 프로토콜이다. 인터넷 통신의 개인정보 보호, 인증, 데이터 무결성을 보장하기 위해 Netscape가 1995년 처음으로 개발하였다.

SSL은 현재 사용중인 TLS 암호화의 전신이다.

보통 SSL과 TLS를 동일하게 부르며, TLS 1.0은 SSL 3.0을 계승한다.
즉, SSL의 새로운 버전이 TLS이다. (그래서 SSL/TLS로 묶어서 부르기도 한다.)

* 더 상세히 설명하자면 Netscape에서 SSL이 개발되었고, SSL이 폭넓게 사용되다 표준화 기구인 IETF의 관리로 변경되면서 TLS이라는 이름으로 변경된것이다.

1.1 SSL/TLS 작동 원리

다음 4. 암호화 작동 원리 항목에서 상세히 다뤄보겠지만, SSL 개념을 살펴보며 원리를 간단히 확인해보겠다.

SSL/TLS은 웹에서 전송되는 데이터를 암호화한다. 즉, 중간에 데이터를 가로채는 대상은 해독하기 힘든 암호화된 문자열만 보게 된다.
SSL/TLS은 서버와 클라이언트 통신 사이에 핸드세이크라는 인증 프로세스를 시작하며 두 대상의 ID를 확인한다.
또한 데이터 무결성을 제공하기 위해 데이터에 디지털 서명을 진행하며 수신자에게 도착하기 이전에 조작되지 않았다는 것을 확인한다.

원래 웹 상의 데이터는 중간에 가로채면 누구나 읽을 수 있는 일반적인 텍스트 형태로 전송되었다.
즉, 사용자가 쇼핑 웹사이트에서 신용 카드 정보를 입력한다면 이 정보가 숨겨지지 않은채 인터넷을 이동하게 된다.
SSL은 이런 개인 정보를 보호하기 위해 개발되었다. 사용자와 웹 서버 사이를 이동하는 모든 데이터를 암호화하여, 누군가 데이터를 가로채더라도 무작위 문자열만 볼 수 있게 만든다.

2. SSL 인증서란?

SSL 인증서란 쉽게 클라이언트와 서버간의 통신을 제 3자가 보증해주는 문서라고 생각하면 된다.

SSL은 SSL 인증서(물론 공식적으로는 TLS 인증서이다.)가 있는 웹사이트에서만 실행될 수 있다. 웹사이트나 애플리케이션 서버가 SSL 인증서를 웹에 저장하고 표시하며 CA(인증 기관)에서 SSL 인증서 발행을 담당한다.

SSL 인증서는 단일 데이터 파일에 다음 정보를 포함시킨다.

인증서가 발듭된 대상 도메인 이름
발급 받은 사람, 조직, 장치
발급한 인증 기관
인증 기관의 디지털 서명
관련된 하위 도메인
인증서 발급 날짜
인증서 만료 날짜
공개 키(개인 키는 비밀로 유지된다)

인증서는 원본 서버에서 호스팅되며, 웹사이트 로드를 요청하든 모든 시스템에 전송된다.

티스토리에서 제공하는 SSL 인증서 정보

2.1 SSL 인증서 유형

SSL 인증서는 다양한 유형이 있다. 하나의 도메인만 적용되는지, 여러 도메인에 적용되는지에 따라 유형이 달라진다.

단일 도메인	단일 도메인 SSL 인증서는 단 하나의 도메인 (여기서 도메인은 웹사이트에 적용되는 서브도메인을 말한다.) ex, www.cwdev.site)에 적용된다.
와일드카드	와일드카드 SSL 인증서는 Root 도메인에 적용된다. 즉, 서브 도메인을 모두 포함한다. ex, *.cwdev.site로 발급받으면, www.cwdev.site, resume.cwdev.site, api.cwdev.site 등 여러 도메인에 적용 가능하다. 본인의 경우 대부분의 SSL 인증서는 와일드카드로 관리했었다. 지금 생각해보니 회사에 돈이 많았나보다.
멀티 도메인	이름에서 유추할 수 있는데, 멀티 도메인 SSL 인증서는 다수의 Root 도메인에 적용할 수 있다. ex, www.devcw.site www.cwking.com, www.devops.cwpack 등… Sectigo(Comodo) MDC로 사용했던 경험이 있는데, 사용할 도메인을 추가할때마다 비용이 더해지는걸로 기억한다.

2.2 SSL 인증서 등급

SSL 인증서가 적용되는 여러 대상에 대한 유형이 존재하듯, SSL 인증서의 인증 등급에 따른 분류도 존재한다. 즉, SSL 인증서마다 유효성 검사 수준이 차이가 난다.

DV(Domain Validation) 도메인 유효성 검사
- 도메인 소유 검증 절차만 있다. 가장 간단하며 약 5분정도 소요되는 것 같다. 누구나 발급이 가능하다.
- 인증서 분류 중 가장 덜 엄격하다. 도메인을 관리하고 있다는 것만 확인한다.
OV(Organization Validation) 조직 유효성 검사
- 도메인 소유 검증 절차와 조직(회사) 검증 절차가 존재한다. 길면 2~3일 정도 소요된다.
- 실제로 신청한 회사로 인증업체에서 연락이 온다. 내 경우 우리 회사의 재무팀, 경영팀에 전화가 오고, 회사의 주소명과 신청자(나)가 해당 직장에 재직중인지를 확인한다.
- 좀 더 실무적인 프로세스이다. CA가 담당자나 기업에 인증서를 직접 문의한다.
EV(Extended Validation) 확장 유효성 검사
- 도메인 소유 검증 절차와 조직에 대해 구체적인 검증 절차로 진행된다. 최대 3주정도 소요된다고 한다.
- 일반적으로 금융권이나 공공기관에서 사용하며, 브라우저에 따라 녹색 창이 나오는 등 차별화가 있다.
- 조직의 배경을 완전히 검사한 후에 SSL 인증서를 발급한다.

국민은행 페이지의 EV 인증서 참고자료. 브라우저 주소 창이 녹색으로 나타난다.

2.3 자체 서명 SSL 인증서

물론 CA이 아니더라도 기술적으로 누구나 공개-개인 키 페어링을 생성하여 자신만의 SSL 인증서를 만들 수 있다. 이 경우를 자체 서명 인증서라고 부른다.

하지만 자체 서명 인증서를 사용하게 되면 원본 서버가 자신이 주장하는 서버인지 확인할 수 있는 외부 기관(제 3자)이 없다. 그렇기 때문에 브라우저에서는 자체 서명된 인증서를 신뢰할 수 있는 것으로 간주하지 않는다.

즉, 자체 서명 인증서가 있는 사이트는 https://로 접근함에도 불구하고 “안전하지 않음”으로 표시된다.

자체 서명 인증서는 OpenSSL, 자바의 keytool, 어도비 리더, WolfSSL 및 애플의 키체인 및 등 다양한 도구를 사용하여 무료로 발급할 수 있다.

3. HTTP vs HTTPS

HTTPS는 암호화 인증이 포함된 HTTP이다. 즉 두 프로토콜의 유일한 차이점은 HTTPS의 경우 SSL/TLS을 사용하여 HTTP 요청과 응답을 암호화하고 디지털 서명을 한다는 점이다.

HTTPS는 HTTP보다 더욱 안전하며 HTTP를 사용하는 웹 사이트의 URL은 http://, HTTPS를 사용하는 웹 사이트는 https://로 표시된다.

HTTP란?
HTTP는 하이퍼텍스트 전송 프로토콜의 약자로, 네트워크를 통해 데이터를 전송하는데 사용되는 프로토콜 혹은, 정보를 표현하기 위한 규정된 순서와 구문을 뜻한다.
(웹 사이트 컨텐츠 및 API 호출 등 인터넷을 통해 전송되는 대부분의 정보는 HTTP 프로토콜을 사용한다.)

정리하자면 다음과 같다.

HTTP와 HTTPS는 엄밀히 보면 별개의 프로토콜이 아니다. HTTPS는 단순히 HTTP 프로토콜을 SSL/TSL을 통해 암호화로 사용하는 것이다.
HTTP는 80 포트를 사용하며 HTTPS는 443 포트를 사용한다.

4. 암호화 작동 원리

IT의 보안 인증 방식은 대부분 키를 어떻게 관리하며 대칭/비대층을 조합, 비교하며 사용할 것인가에 따라 발전해왔다. 즉, SSL 인증의 보안 방식도 키를 이용한 암호화를 통해 신뢰성을 파악한다.

물론, 보안 방식이 키를 어떻게 대칭시키느냐 뿐만이 아니라 다양한 신뢰 모델과 인증 방식등이 존재한다. 이에 대해서는 따로 IT의 보안 인증 방식에 대해 글을 작성해보겠다.

4.1 암호화란?

암호화는 승인된 당사자만 볼 수 있도록 데이터를 변환시키는 방법이다. 일반적인 텍스트를 사람이 이해할 수 없는 텍스트로 변환하는 과정으로, 암호 텍스트라고도 불린다.

암호화를 사용하려면 *암호화 키를 사용해야 한다.

*암호화된 메세지의 발신자와 수신자가 모두 동의하는 수학적 값 집합

4.2 암호화 동작 방식

암호화는 암호화 알고리즘과 키를 사용하여 데이터를 변경하는 수학적인 프로세스이다.

예를 들어 A가 B에게 “Hello”라는 메세지를 보내며 각 문자를 알파벳 순서에서 두 자리 뒤에 오는 문자로 바꾼다고 가정해보겠다. “Hello” 대신 “Jgnnq”라고 보내지나, B는 다행이도 “2”라는 Key를 알고 있고, 메세지를 다시 “Hello”로 해독할 수 있다.

물론 이는 매우 간단한 암호화 알고리즘이다. 실제로는 더 복잡한 암호화 알고리즘을 사용한다.

즉, 암호화된 데이터는 무작위로 보이지만, 사실 논리적이고 예측 가능한 방식으로 진행되므로 올바른 키를 가지고 있다면 데이터를 다시 해독하여 변환할 수 있는 것이다.

최근의 암호화 방식은 제 3자가 무차별 대입으로 암호문을 해독할 가능성이 거의 없을 정도로 엄청나게 복잡한 키를 사용한다.

4.3 암호화의 유형

SSL 인증 과정. 크게 핸드셰이크 → 전송 → 세션종료의 3가지 단계로 구성되어 있다.

암호화에는 대칭 암호화와 비대칭 암호화 두 가지 주요 유형이 있다.(비대칭 암호화는 공개키 암호화라고도 한다.)

대칭 암호화: 대칭 암호화 방식은 동일한 키로 암호화와 복호화를 할 수 있는 기법을 뜻한다. 즉, 하나의 키로 모든 통신 당사자들은 암호화와 해독 모두 가능하도록 사용한다.
비대칭 암호화: 비대칭(공개키) 암호화 방식은 대칭키 방식과 다르게 2개의 키를 가지고 진행한다. 하나의 키는 암호화에 사용되고, 다른 키는 해독에 사용된다. 해독 키는 개인키라고도 불리며, 비공개로 유지되고, 암호화 키는 누구나 사용할 수 있도록 공개적으로 공유되어 공개키라고도 불린다.

SSL/TLS는 공개 키 암호화라는 기술을 사용한다. 공개 키는 서버의 SSL 인증서를 통해 클라이언트 장치와 공유되며 클라이언트가 서버와의 연결을 열면 두 장치는 공개 키와 개인 키를 사용하여 세션 키라는 새 키에 동의하여 두 장치 간의 추가 통신을 암호화한다.
모든 HTTP 요청과 응답이 이 세션 키로 암호화되므로 통신을 가로채는 사람은 일반 텍스트가 아닌 임의의 문자 문자열만 볼 수 있다.

4.4 암호화 알고리즘과 무차별 대입 공격

일반적으로 사용되는 대칭 암호화 알고리즘은 다음과 같다.

AES
3-DES
SNOW

일반적으로 사용되는 비대칭 암호화 알고리즘은 다음과 같다.

RSA
타원 곡선 암호

무차별 대입 공격

무차별 대입 공격은 해독 키를 모르는 공격자가 수백 ~ 수십억 번의 추측을 통해 키를 알아내려고 시도하는 것이다. 최신 컴퓨터는 암호 대입 공격이 훨씬 빠르므로 암호화 또한 복잡해져야 한다.

최근의 암호화 기법은 비밀번호와 결합되어 무차별 대입 공격에 어느정도 저항력이 있지만, 컴퓨터가 점점 발전함에 따라서 이런 공격에 취약해질 수 있다.

4.5 HTTP 요청 암호화 예시

앞서 설명했듯, HTTPS는 SSL/TLS를 사용하여 HTTP 요청과 응답을 암호화하므로 공격자는 텍스트 대신 무작위로 보이는 문자를 보게 된다.

예를 들어 다음 HTTP 요청을 진행한다 가정했을때 일반적인 HTTP 응답은 다음과 같다.

HTTP 요청 예시

GET /hello.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: en

HTTP 응답 예시

HTTP/1.1 200 OK
Date: Wed, 30 Jan 2019 12:14:39 GMT
Server: Apache
Last-Modified: Mon, 28 Jan 2019 11:17:01 GMT
Accept-Ranges: bytes
Content-Length: 12
Vary: Accept-Encoding
Content-Type: text/plain

Hello World!

그러나 HTTPS로 암호화한다면, 공격자는 다음과 같은 응답을 받게된다.

HTTPS 응답 예시

t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miNieJeJ/FNUjgH0BmVRWII6+T4MnDwmCMZUI/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==

5. 마치며

이번 글을 작성하며 저도 SSL의 작동 원리, 인증서의 개념과 종류, 그리고 HTTP와 HTTPS의 차이, 암호화의 원리 까지 하니씩 다시 되짚어보는 시간을 가지게 되었습니다.

사실 인터넷에서 우리가 주고받는 많은 데이터는 보이지 않는 곳에서 계속해서 보호받고 있습니다. 브라우저에 표시되는 작은 자물쇠 아이콘 하나가 단순한 UI 요소가 아니라 사이트간 신뢰와 보안을 나타내는 정말 중요한 장치라는 점을 느끼게 되었습니다.

현재 IT 공격 방식은 나날히 발전하고 있습니다. 이에 맞춰 보안도 개선되고 있지만, 결국 보안의 기본을 이해하고 실천하는 것이 무엇보다 중요하다고 생각합니다. IT를 다루는 엔지니어라면, 언제나 경각심을 가지고 학습해야 한다는 생각이 드는 시간이였습니다.

읽어주셔서 감사합니다.(_ _) 꾸벅

+ 여담. SSL 인증서 발급 후 DNS 정보가 변경된다면?

가비아를 통해 구입한 도메인을 AWS Route53에 등록하여 사용하고 있었는데, 이때 AWS Route53에 TXT 레코드를 추가하여 SSL 인증서를 발급받았었다.

이떄 AWS → NCP로 마이그레이션을 진행하며 도메인 관리도 Route53 → NCP GlobalDNS로 변경하는 작업을 진행하였는데,

문득 궁금해졌다. DNS 관리 정보가 변경되면 SSL 인증서도 재발급이 필요할까?

SSL 인증서 발급 원리

Q: Route53에서 TXT 레코드를 추가하여 SSL 인증서를 발급받은 후, DNS를 다른 서비스로 이전해도 인증서를 계속 사용할 수 있을까?

A: 결론적으로 사용할 수 있다.

본인의 경우 DV유형의 SSL 인증서로 도메인 소유권을 확인한 후 발급하는 형식인데, 도메인 레코드 설정에서 SSL 인증 기관이 지정해준 TXT 레코드를 추가하여 발급받게 된다.

이때, TXT 레코드는 발급 과정에서만 필요하며, 발급 후에는 인증서 자체에 영향을 주지 않는다.

그리고 DNS 서비스를 이전한다 하더라도, SSL 인증서는 DNS 레코드와 무관하며 웹 서버에서 사용되는 인증서이기 때문에 도메인 이름이 동일하고 SSL 인증서가 잘 설정되어 있다면 문제가 없다.

즉, 도메인 소유권은 인증서 발급 당시에만 존재하면 되고, DNS를 다른 서비스로 이전해도 기존 SSL 인증서는 유효하다.

>. 발급 당시의 소유권만 확인한다면, 생각보다 보안적으로 안전하지 않을 수 있다는 생각이 든다.
그래서 조사를 해봤는데, 보안을 이유로 google은 인증서의 갱신 기간을 90일, apple은 47일로 단축하는 제안을 했다고 한다

링크^^

웹사이트 인증서가 6주마다 만료되면?··· 기업 IT를 위한 가이드북

웹사이트 인증서 업데이트 주기를 대폭 단축하라고 요구하는 움직임이 거세지고 있다. 주로 애플과 구글이 주도하는 이 움직임이 내세우는 명분은 ‘보안’이다. 그러나 이 움직임과 명분에 대

www.cio.com

물론 공식적인 단축 이유는 방치된 도메인 이름을 활용한 피싱, 도용 등을 방지하기 위함이나, 인증 기간을 자주 진행함으로서 도메인 소유권 확인도 더욱 정확해 질 것 같다는 생각이 들었다.

참고자료

https://www.cloudflare.com/ko-kr/learning/ssl/what-is-an-ssl-certificate/

https://aws.amazon.com/ko/what-is/ssl-certificate/

https://nordvpn.com/ko/blog/what-is-ssl-certificate/

https://computing-jhson.tistory.com/117#google_vignette

https://it-sunny-333.tistory.com/144

https://goodgid.github.io/TLS-SSL/

https://12bme.tistory.com/80

https://blog.naver.com/toy_ssl/110167774615

DNS의 동작 원리 및 구성 방법(레코드 종류와 root 도메인)

cwpack0730 — Sun, 26 Jan 2025 14:52:19 +0900

개요

얼마 전, 신규 해외 서비스를 오픈하며 개발과 운영 환경의 도메인을 매핑하는 작업을 진행했다.

개발 환경은 특이하게 Vercel이라는 자동 배포 및 서버리스 클라우드 플랫폼을 활용하고 있었다.(vercel은 Next,js 개발사인데, 그래서 Next.js 프로젝트 배포에 많이 사용되는 것 같다.)

작업 중 Vercel CDN 도메인에 개발용 도메인을 매핑하는 과정에서 진행이 막히는 부분이 발생했었는데, 원인을 파악하면서 내가 놓치고 있던 몇 가지 DNS 기본 개념과 동작 원리를 되돌아보게 되었다.

이번 글에서는 이 과정을 되짚어보며, DNS의 개념과 작동 원리, 그리고 Vercel 배포 시 발생했던 문제를 설명해보려 한다.

1. DNS 개념과 동작 원리

1.1 도메인(domain)과 DNS(domain name system)

도메인은 인터넷에 연결된 시스템을 사람이 쉽게 기억하고 입력할 수 있도록 문자로 만든 인터넷 주소이다. 도메인은 보통 웹사이트와 연결하기 위해 등록하는데, 이때 DNS 관리 서비스를 이용한다.

즉, 도메인은 문자열의 인터넷 주소이며, DNS(Domain Name System)는 이 도메인 이름을 시스템이 읽을 수 있는 IP 주소로 변환하는 것을 말한다.

1.2 일반 최상위 도메인(gTLD)

일반 최상위 도메인(Generic Top-Level Domains)은 특정 조직과 계열에 따라 사용되는 최상위 도메인이다.

.com, .net 등이 포함되어 있으며 다른 최상위 도메인들에 비해 오랜 역사를 가지고 있어 가격대가 낮고 시스템이 안정적이다.

일부를 제외면 신청 자격에 제한이 없다.

ex, .com, .net, .org, .biz 등…

1.3 국가 코드 최상위 도메인(ccTLD)

국가 코드 최상위 도메인(Country Code Top-Level Domains)은 국가 코드로 특정 국가나 지역을 나타낸다.

국가 코드는 일반적으로 ISO(국제 표준화 기구)에서 정한 ISO 3166-1 표준에 따르며,예외적으로 영국은 ISO 기준 약자는 GB이지만, 국가 도메인인 .uk이다.

국가 도메인을 나타낼 때는 언제나 앞에 점을 찍어 사용하는 것을 원칙으로 하고 있다.

ex, .kr(한국), .jp(일본), .us(미국), .uk(영국) 등…

1.4 2차 도메인(SLD)

SLD(2차 도메인)은 최상위 도메인 아래에 직접 위치한 도메인이다. 도메인 확장자라고도 불리며 도메인 이름의 첫 번째 부분이다.

예를 들면, cwdev.site 에서 cwdev 부분이 2차 도메인이다.

2차 도메인은 최상위 도메인과 결합되어 하나의 완전한 도메인 이름을 만든다.

2차 도메인은 등록자가 선택할 수 있으며, 특정 기업이나 개인의 고유 이름을 나타낼 수 있다.
(도메인은 전 세계에서 고유해야 하므로 도메인 등록기관을 통해서 등록해야 한다.)

1.5 루트 도메인과 서브 도메인

루트 도메인은 지금까지 설명한 최상위 도메인(TLD), 2차 도메인(SLD)를 합친, DNS의 최상위 계층이다..

루트 도메인은 베어 도메인(bare domain), 에이펙스 도메인(apex domain)으로도 부른다.

루트 도메인은 DNS 계층에서 최상위에 위치하고 있기 때문에, DNS 서버가 도메인 이름을 찾을 때 가장 먼저 참조하는 기준이 된다.

반면 서브 도메인은 최상위 도메인과 2차 도메인 아래에 위치한 추가적인 도메인으로, 특정 서비스를 구분하거나 웹사이트 내에서 다양한 섹션을 나누는데 사용된다.

예를 들면, www.cwsite.com에서 www부분이 서브 도메인이다..

# 전체 도메인 네이밍 구조
예시: www.cwsite.com
     www    .  cwsite    .     com
 <서브도메인>.<2차 도메인>.<최상위 도메인>
             <--------루트 도메인------->

다시 정리하자면, 루트 도메인은 DNS 트리에서 최상위에 있고, 그 아래 최상위 도메인, 2차 도메인, 서브 도메인이 위치하는 구조로 이루어져 있다.

1.6 도메인과 URL의 차이점

도메인(Domain): 도메인은 문자열의 인터넷 주소로, DNS 서버를 통해 IP 주소로 변환시켜 연결된다.
URL(Uniform Resoruce Locator): 도메인을 포함한 접근 경로. 프로토콜+도메인+경로로 나타난다.

URL 이미지. URL 안에 도메인이 포함된 개념으로 이해하면 편하다.

즉 도메인은 인터넷 주소이며, URL은 인터넷 주소를 포함한 인터넷 자원의 전체 주소이다.. 도메인은 URL의 일부분이며, URL은 특정 위치를 지정하는 더 구체적인 주소라고 볼 수 있다.

1.7 DNS의 흐름

위 도메인 개념에서 DNS는 도메인 이름을 IP주소로 변환하는 역할을 한다고 했었는데, IP 주소로 변환하며 대상을 찾아가는 과정에 대해서 동작하는 원리와 과정을 설명해보겠다.

DNS의 동작 과정은 다음과 같다.

1. 웹사이트 접속 요청	사용자가 웹 브라우저 주소(www.cwdev.site)를 입력하여 접속을 시도함
2. 로컬 DNS 캐시 확인	사용자의 컴퓨터는 도메인 이름에 대한 IP 주소가 로컬 DNS 캐시에 저장되어 있는지 먼저 확인함. 만약 로컬 캐시에 해당 도메인 이름에 대한 IP 주소가 있다면, 이를 즉시 반환하고 웹사이트를 표시
3. DNS 질의 시작	로컬 DNS 캐시에 해당 도메인 이름 IP 주소가 없다면 컴퓨터는 DNS 서버에 질의를 시작
4. 루트 DNS 서버의 IP 주소 조회	사용자의 컴퓨터는 미리 설정되어 있는 최상위 DNS 서버의 IP 주소를 참조하여, 루트 DNS 서버의 주소를 확인 이 과정에서, 컴퓨터는 루트 DNS 서버에 연결하여 도메인 이름을 처리할 수 있는 정보를 찾음
5. TLD DNS 서버 정보 얻기	루트 DNS 서버는 사용자의 요청에 대해 해당 도메인 이름을 관리하는 TLD(Top-Level Domain) DNS 서버의 IP 주소를 제공 예를 들어, .com, .org, .net과 같은 최상위 도메인에 해당하는 TLD 서버가 제공됨
6. Authoritative DNS 서버의 IP 주소 얻기	사용자는 TLD DNS 서버에 질의를 보내어, 해당 도메인 이름을 관리하는 Authoritative DNS 서버의 IP 주소를 받음. 이 서버는 해당 도메인의 정확한 정보를 가지고 있다.
7. IP 주소 조회	사용자는 Authoritative DNS 서버에 최종 질의를 보내어, 해당 도메인 이름에 대한 IP 주소를 얻음. 이 IP 주소는 웹사이트를 표시하는 데 필요한 주소이다.
8. IP 주소 캐시 저장 및 웹사이트 표시	사용자는 얻은 IP 주소를 로컬 DNS 캐시에 저장하고, 해당 주소를 통해 웹 페이지를 브라우저에 표시 이제 웹사이트가 사용자에게 로딩된다.

1.8 Root DNS 서버

Root DNS 서버는 인터넷에서 가장 중요한 DNS 서버 중 하나이다. 전 세계적으로 분산되어 있으며, 인터넷 상의 모든 도메인 이름에 대한 최상위 DNS 서버로, DNS 시스템의 핵심 역할을 담당한다.

루트 도메인 이름을 관리하며(ex, .com), TLD DNS 서버의 IP 주소를 알고 있다.

즉, 위 DNS 동작 과정에서 설명한 내용처럼 Root DNS 서버는 TLS DNS 서버의 IP 주소를 반환하고 사용자의 DNS 쿼리는 TLS DNS 서버로 전달된다.

Root DNS 서버는 ICANN(Internet Corporation for Assigned Names and Numbers)에서 관리된다.

1.9 TLD DNS 서버

TLD DNS 서버는 인터넷에서 사용되는 최상위 도메인 이름(Top-Level Domain)을 관리하는 DNS 서버이다.

.com, .org, .edu 등과 같이 최상위 도메인 이름에 대한 DNS 서버로, 각 도메인 이름의 DNS 쿼리를 처리한다.

TLD DNS 서버는 각 TLD 도메인 이름에 대한 IP 주소와 기타 DNS 레코드 정보를 관리한다.

예를 들어, .com 도메인 이름에 대한 TLD DNS 서버는 .com 도메인 이름에 대한 모든 DNS 쿼리를 처리합니다. 이러한 DNS 쿼리는 해당 도메인 이름에 대한 IP 주소를 찾는 것이 주된 목적이다.

TLD DNS 서버도 Root DNS와 마찬가지로 ICANN에 등록되어 있으며, 해당 TLD 도메인 이름을 사용하는 등록 업체와 협력하여 정보를 업데이트한다.

1.10 Second-Level DNS 서버(Authoritative DNS 서버)

Second-Level DNS는특정 도메인 이름에 대한 IP 주소 정보를 제공하는 DNS 서버이며, 일반적으로 도메인/호스팅 업체의 네임서버를 말한다.

또한 해당 도메인 이름에 대한 정보를 가지고 있는 최종적인 답변자 역할을 한다. 예를 들어 cwdev.site 도메인 이름에 대한 IP 주소를 알고 있는 DNS 서버가 있다면 , 해당 DNS 서버는 Second-Level DNS 서버가 된다.

(ex, 가비아, 후이즈, AWS Route53, Ncloud global DNS 등…)

2. DNS 레코드 종류

DNS 레코드는 DNS에서 도메인 이름과 해당 도메인과 연결된 IP 주소를 매핑하는 데 사용되는 데이터 항목이다. DNS 레코드는 도메인 이름과 관련된 정보를 담고 있으며, DNS 쿼리를 수행하는 서버에 의해 사용된다.

자주 접하는 DNS 레코드 종류는 다음과 같다.

A 레코드	도메인 이름을 IP 주소로 매핑한다. 서버로 직접 붙는 도메인의 경우에 주로 사용한다.
CNAME 레코드	도메인 이름을 다른 도메인 이름으로 매핑한다. 운영 도메인에 많이 사용했다. 보통 CDN이나 로드밸런서 도메인을 등록한다.
MX 레코드	도메인 이름과 연결된 메일 서버의 우선 순위를 지정한다. 이메일을 전송할 때 도메인 이름과 연결된 메일 서버를 찾는 데 사용된다. 보통 웹사이트에서 메일을 연동할때 사용했다.
NS 레코드	도메인 이름에 대한 권한 DNS 서버를 식별한다.DNS 쿼리가 수행될 때 도메인 이름에 대한 권한 DNS 서버를 찾는 데 사용된다. 도메인 관리 서비스를 이용할때 사용했다. ex, 가비아 → AWS Route53 NS 로 변경하여 사용 등…
TXT 레코드	도메인 이름과 연결된 텍스트 정보를 포함된다. 이 레코드는 보안, 인증 등 다양한 목적으로 사용된다. google 사이트 등록 인증과 SSL 인증서 등록을 위해 사용하였다
SPF (Sender Policy Framework) 레코드	이메일 스팸을 방지하기 위해 도메인 이름의 이메일 발송 권한을 확인하는 데 사용된다.
SRV (Service) 레코드	DNS 서버가 제공하는 특정 서비스의 위치를 식별하는 데 사용된다. 이 레코드는 웹 서비스, VoIP, FTP 등과 같은 특정 서비스의 위치를 찾는 데 사용된다.
AAAA 레코드	IPv6 주소를 도메인 이름에 매핑하는 데 사용된다.
SOA (Start of Authority) 레코드	도메인 이름에 대한 기본 설정을 제공한다. (도메인 소유자, DNS 서버, 캐시 정보 유효 기간 등….)

3. 도메인 연결 방법

도메인 연결 방법은 간단한데, 보통 각 도메인 구입처나, AWS, NCP 등 클라우드 DNS 서비스에 등록하여 사용하는 방법이 있다.

나는 vercel 사례와 비슷하게 서버(혹은 IP)에 직접 매핑하는 것이 아닌 운영중인 github 웹 페이지에 CNAME 레코드로 개인 도메인을 매핑하는 실습을 진행해보겠다.

3.1 개인 사이트 연결해보기(A 레코드 설정하여 변경)

기존 내 github에서 운영중인 chanw-pack.github.io 사이트에 가비아에서 구매한 도메인을 연결해보겠다.

(정확히는 가비아에서 대행으로 구매를 해준다는 개념이다.)

! 필자는 가비아로 진행하였지만 여러 도메인 관리 업체 모두 동일한 방식이니 등록 방법보다는 위 설명한 개념적인 부분을 이해하기 위해 확인해본다고 생각하시면 좋습니다.

가비아에 로그인 후, My가비아로 이동한다.

My가비아에 접근하면 구매한 도메인 정보를 확인할 수 있다.

설정할 도메인으로 이동하면 DNS 레코드 설정 항목이 있다.

DNS 레코드 설정에서 resume 라는 서브도메인을 CNAME 타입으로 레코드 생성을 진행하였다.

즉, resume.cwdev.site 로 이동하면 기존 chanw-pack.github.io 사이트로 이동하게 된다.

도메인이 적용된 것을 확인한다.

4. ROOT 도메인에서 CNAME 사용이 가능할까?

이제 DNS 및 도메인 설명에서 돌아와 vercel 사용중 발생한 문제에 대해서 상세히 설명해보겠다.

현재 개발서버에 이미 A도메인을 연결하여 사용중이다.(vercel 사용중)

이 때, 새로운 B 도메인을 매핑하여, 두 도메인을 사용하려고 한다. (두 도메인 모두 사용되어야 한다.)

4.1 환경 소개 및 가능 여부 파악

개발팀에게 요청받은 요구사항
1. cname / cwdev.site / cname.vercel-dns.com (문제되는 요청)
2. cname / www.cwdev.site / cwdev.site
3. A / admin.cwdev.site / 123.123.456.78

ROOT 도메인을 CNAME 레코드 타입으로 생성하는것은 여러 방식에 따라 가능할 수 있다. 하지만 결론부터 말하자면, 위 요청은 우리 환경에서는 불가능했다.

https://blog.enyou.net/ko/archives/517

왜 CNAME은 ROOT에서 쓸 수 없는가? PTR 레코드란 무엇인가? – Enyou’s Atelier

왜 CNAME은 ROOT에서 쓸 수 없는가? PTR 레코드란 무엇인가? 글쓴이 연유 날짜 2020년 4월 30일2020년 4월 30일 개요 도메인 등록 회사를 구글 도메인으로 바꾸면서 도메인의 루트에 CNAME을 등록할 수 없

blog.enyou.net

요약하면, 다음 DNS 표준 규칙으로 제약 사항이 있다.

그 이유를 상세히 확인해보겠다.

1. 현재 본인은 후이즈에서 도메인을 구입하였고, NCP GlobalDNS로 네임서버를 변경하여 사용중에 있다.

2. 위 요구사항 중, 루트 도메인을 CNAME으로 지정해야하는 사항이 있다.그러나 CNAME은 일반적으로는 루트에 등록할 수 없다.

SOA와 NS 레코드는 루트 도메인에서 반드시 표현되어야 한다. (RFC 1912)
DNSSEC의 SIG, NXT, KEY RR 레코드를 제외하고서는 CNAME 레코드는 다른 레코드와 같이 쓰일 수 없다. (RFC 2181)
물론, 기술적으로 완전히 강제되는것은 아니다. 사용하는 도메인 서비스마다 루트 도메인에 CNAME 레코드를 허용하기도 한다. AWS의 경우에도 Route53에 등록할 시, 외부 시스템은 불가하지만 내부(ex,EC2등) 서비스끼리는 루트 도메인의 CNAME 구성이 가능하다.(alias 매핑으로 가능합니다.)
그러나 vercel DNS는 클라우드 플랫폼 외 시스템이라 alias 매핑이 불가하며 A 레코드 또한 vercel DNS가 CDN 처럼 계속 IP가 변경되기 때문에 A레코드로도 할당할 수 없는 상황이다.

4.2 대처방안

1. NCP Global DNS에서 AWS Route53으로 전환
(AWS Route53은 루트 도메인을 CNAME으로 사용 가능하다는 이야기를 얼핏 들은 것 같다.)

일단 route53에서도 루트 도메인에 대해 cname으로 사용이 불가하다.
단, alias를 통해 aws 내부 서비스에는 가능하다.
그래서 aws cli를 통해 직접 대상을 넣는다면, alias를 외부 도메인을 넣을 수도 있을법하다.
- 안됨…

4.3 결론

루트 도메인 사용이 필요한 vercel 레코드를 A 레코드로 사용하도록 변경 요청하여 해결하였다.

5. 마치며

이번 작업에서 root 도메인은 CNAME 레코드 사용 불가하며, 클라우드의 alias 레코드는 내부 서비스에만 연결 가능하다는 사실을 알게 되었습니다. (AWS는 가능할 줄 알았네요.. )

결국 Vercel의 CNAME 레코드를 A 레코드로 변경하여 문제를 해결했지만, 작업을 진행하면서 root 도메인에 CNAME 매핑이 불가능하다는 DNS 정책을 미리 인지했더라면 더 수월하게 작업을 마칠 수 있었을 거란 아쉬움이 남았습니다.

지금까지 많은 도메인 관련 작업을 진행해왔지만, 이번 경험을 통해 도메인의 기본 개념과 구조, 다양한 레코드 타입, 그리고 DNS 표준 규칙으로 인한 제약들의 중요성을 다시 한 번 체감했습니다. 근래 최신 인프라는 점점 더 복잡해지고, 고도화된 기술 능력을 요구하고 있지만, 이런 도메인, URL, DNS 등 기초적인 CS 지식이야말로 기반이 된다는 점을 깨닫게 되는 시간이였습니다.

다음은 SSL 인증서와 도메인 운영 작업에 대해서 제가 경험했던 사례들을 공유해보는 포스팅을 이어가보겠습니다.

읽어주셔서 감사합니다. ‍♂️

+여담. id 도메인의 사용 인증

예전에 cwdev.id라는 도메인을 사용하는데 해당 도메인이 사용이 불가한 상황이 발생했었다.

확인해보니 도메인 Status가 clientHold 상태로 나타났다.

잠겨있음… Why??

이에 후이즈에 문의해보니, .id 도메인의 경우 등록완료 후 인증이 완료되어야 사용이 가능하다고 한다.. (SSL 인증서와 비슷합니다.)

다시 전달받은 메일로 인증 후 정상 동작을 확인하였다.

드디어 됬네…ㅠㅜ 도메인도 인증이 필요한 경우가 있군요

최상위 도메인별로 인증이 따로 발생할 수 있는점, 염두해두시면 좋을 것 같습니다.

참고자료

https://blog.enyou.net/ko/archives/517

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html

[Route 53] CNAME vs Alias

https://velog.io/@jangsebari/route53-을-이용하여-vercel-도메인-변경

https://velog.io/@gun_123/Route-53-CNAME-vs-Alias

https://velog.io/@jungmyeong96/AWS-SAA-Route53-TTL-CNAME-ALIAS

https://vercel.com/docs/projects/domains/add-a-domain

https://vercel.com/docs/projects/domains/managing-dns-records

https://aws.amazon.com/ko/route53/what-is-dns/

https://blog.daouidc.com/blog/domain-definition-0

https://sudo-minz.tistory.com/13

https://aws.amazon.com/ko/route53/what-is-dns/

https://somaz.tistory.com/172

[DELL] RAID 컨트롤러 복구 과정(Multibit ECC와 UEFI0116)

cwpack0730 — Wed, 18 Dec 2024 18:08:27 +0900

개요

최근 사내에서 물리서버 한 대가 디스크 관련 이슈로 갑작스럽게 다운되는 일이 발생했다. 예상 못한 상황에서 긴박하게 진행했었지만, RAID 구성과 물리 디스크 상태를 점검하고 문제가 발새한 장치를 찾아 교체하여 정상적으로 복구를 완료할 수 있었다.

이번 글에서는 당시 상황에 발생한 디스크 오류와 트러블 슈팅 과정을 공유해보려 한다.

작업 히스토리

1. 서버 down 확인
2. RAID 컨트롤러 Error 발생
3. RAID 컨트롤러 캐시 메모리 초기화 시도 -> 실패
4. RAID 컨트롤러 교체(여분 장비)
5. 서버 Up 확인, 데이터 정상 여부 확인 완료

1. 서버 Down 이슈 확인(디스크 문제)

평소 일과를 진행하던 중 사내 개발서버에 연결이 안되는 장애가 발생했다. 정확하게는 물리 서버에서 실행중인 하이퍼바이저는 작동 중이였으나, 그 위에서 동작하는 VM들이 모두 중단되는 상황이였다.

문제 발생 직후 하이퍼바이저 서버에 접근 자체는 가능했지만, 기본적인 시스템 명령어를 입력하면 에러가 출력되었다.

root@vm01:~# lsblk
-bash: /usr/bin/lsblk: Input/output error

- bash: /usr/bin/lsblk: Input/output error

디스크 상태를 확인하기 위해 lsblk 명령을 실행했을때 발생하였는데, 찾아보니 파일 시스템 관련 문제로 확인된다.

시간이 지나면서 결국 하이퍼바이저 서버 자체도 접근이 불가능한 상태가 되어 서버 재부팅을 진행하였으나, 다음과 같은 에러가 발생하며 부팅되지 않았다.

- https://unix.stackexchange.com/questions/542554/got-input-output-error-when-execute-any-commands
- https://askubuntu.com/questions/1216954/bash-usr-bin-top-input-output-error

(다음 자료를 참고해보면 디스크나 파일시스템 손상으로 인해 발생한 것으로 보인다.)

- UEFI0116 One or more boot drivers have reported issues

해당 화면처럼 UEFI0116 오류는 DELL 서버의 부트 드라이버 자체나 설정에 문제가 있다는 것이다.

여러 이유가 있을 수 있는데, 아무 키(Press any key)를 눌러서 상세한 내용을 확인할 수 있다.

해당 에러는 DELL 서버에서 발생하는 오류로, 부트 드라이버 또는 설정에 문제가 있음을 나타낸다.

보통 물리 디스크 문제, RAID 구성 오류, 펌웨어 오류 등으로 발생할 수 있는데, 상세 로그를 확인하기 위해 아무 키(Press any key)를 눌러 드라이버 헬스 매니저(Driver Health Manager)로 접근하였다.

2. RAID 컨트롤러 Multibit ECC Error

서버를 재부팅하며 나타난 UEFI0116 오류 화면에서 Driver Health Manager로 진입하여 드라이버 상태를 확인하였다.

해당 메세지는 사용중인 DELL 440 서버의 RERC H750(RAID 컨트롤러 모델명)에서 치명적인 오류가 발생하여 부팅이 불가능하는 내용이다.

- Multibit ECC Error

Multibit ECC Error는 RAID 컨트롤러의 캐시 메모리에서 다중 비트 오류가 발생하여 자동 복구가 불가능한 상태를 의미한다.

조사해보니 보통 ECC 메모리는 단일 비트 오류를 자동으로 수정할 수 있으나, 다중 비트 오류는 수동으로 처리하거나 하드웨어를 교체해야 하는 경우가 많다고 한다.

보통 다음과 같은 원인으로 발생한다.

RAID 컨트롤러의 캐시 메모리 손상
RAID 배터리 문제
RAID 펌웨어 버그

관련 자료를 조사하던 중, 비슷한 사례를 발견했다. RAID 컨트롤러의 캐시 메모리를 초기화하여 복구하였다는 내용이다.

https://dasandata.tistory.com/entry/Dell-R740-서버-정전-후-UEFI0116-Avago-MegaRAID-FW-Fault-MFI-Register-0xF0FF8302-부팅-불가

Dell R740 서버 정전 후 UEFI0116 Avago MegaRAID F/W Fault MFI Register 0xF0FF8302 부팅 불가

안녕하세요 다산데이타 입니다. Dell R740 서버를 사용하던 고객사에서 갑작스런 정전 후 BIOS POST 에서 아래와 같은 메세지가 발생하면서 RAID Controller 가 인식되지 않고 OS로 진입이 안된다는 접수

dasandata.tistory.com

다음 사례의 요약은 다음과 같다.

RAID 컨트롤러에서 Multibit ECC Error로 인해 부팅 불가
서버 종료 후 전원 공급 장치 제거
RAID 컨트롤러 배터리 방전 유도
-> RAID 컨트롤러의 BBU가 방전되도록 대기
배터리가 방전되며 RAID 컨트롤러의 캐시 메모리 초기화
전원 및 디스크 복구 후 재부팅
정상 부팅 확인

이에 본인도 캐시 메모리를 초기화하는 방법으로 진행해보겠다.

3. RAID 컨트롤러 캐시 메모리 초기화

RAID 컨트롤러와 캐시 메모리 역할

RAID 컨트롤러는 서버의 디스크를 관리하는 장치이다.

본인의 경우 서버는 DELL 440, RAID 컨트롤러는 H750 모델을 사용중이라 해당 모델들을 기준으로 설명하자면, RAID 구성 정보나 데이터들은 물리적 디스크와 컨트롤러에 저장된다.

(RAID 컨트롤러 별로 기능이 상이하기 때문에 잘 확인하고 진행해야한다.)

즉, 물리 디스크에도 RAID 구성 정보가 저장되기 때문에, RAID 컨트롤러를 교체하거나 캐시 메모리를 초기화하더라도 RAID 구성이 유지된다는 것을 확인하였다.

그리고 이번 서버는 개발 용도로 사용중이였고, 데이터는 이미 백업된 상태였기 때문에 데이터 안정성보다 빠른 복구가 필요한 상황이였다.

위와 같은 근거로 RAID 컨트롤러 캐시 초기화를 시도하였다.

캐시 메모리 초기화 작업

다음 절차로 캐시 메모리 초기화 작업을 진행하였다.

대기 전력 제거
(서버 종료 후 전원 케이블, 네트워크 케이블 제거하여 대기 전력 차단)
RAID 컨트롤러 재결합 진행
(서버 내부 RAID 컨트롤러를 분리했다가 다시 결합)
전원 및 네트워크 케이블 연결 후 대기
(케이블 연결 후 전원은 키지 않은 상태로 잠시 대기)
서버 부팅 시도

작업 대상 서버이다.

작업 대상 DELL 440 서버

그리고 해당 부분이 RAID 컨트롤러이다.

DELL 440의 경우 서버 중앙에 위치하고 있다. 하드 디스크가 연결된 장치를 찾아보면 알기 쉽다.

이후 약 30분간 전원을 차단한 뒤 작업을 진행했으나, 결국 동일한 문제가 재발하였다.

추측할 수 있는 원인:

캐시 메모리 초기화가 제대로 이뤄지지 않음
- 캐시 메모리 초기화에 필요한 정확한 대기 시간이 불명확하다. 초기화 과정이 실패했을 가능성이 있다.
RAID 컨트롤러의 물리적인 장애
- RAID 컨트롤라 자체에 손상이 발새했을 가능성도 있음

그래서 다음 작업으로는, 여분 서버에서 RAID 컨트롤러를 교체하여 복구를 시도해보았다.

4. RAID 컨트롤러 교체

RAID 컨트롤러는 이렇게 생겼다.

캐시 메모리 초기화가 실패한 이후, RAID 컨트롤러를 교차하기로 결정하였다. 장치 교체가 가장 확실한 해결책이라고 생각했다.

https://www.dell.com/support/contents/ko-kr/videos/videoplayer/poweredge-r720용-raid-카드를-교체하는-방법/6079773598001

PowerEdge R720용 RAID 카드를 교체하는 방법 | Dell 대한민국

카피 링크가 복사됨

www.dell.com

다음 자료를 참고해서 작업을 진행하였다.

특히 DELL 홈페이지에 동영상으로 상세히 교체 방법이 있다.

교체 작업 진행 : RAID 컨트롤러

아래 사진은 작업 대상이였던 RAID 컨트롤러이다. (위 검색 사진과 똑같다.)

각각 앞면 뒷면이다.

TMI: 우측 이미지에 중앙 네모난 부분이 배터리인데, 배터리 교체를 진행한다면 해당 부분을 교체해주면 된다.

여분 서버에서 부품 수령

올해 IDC에서 NCP로의 마이그레이션 과정 중 남겨진 여분의 서버들 덕분에 동일 모델 RAID 컨트롤러를 확보할 수 있었다.

대부분 폐기 예정이던 서버들인데, 내가 사내 개발환경으로 만들려고 쌓아둔 덕분이였다.(고맙다.. 과거의 나)

여기서 동일 모델의 서버에서 RAID 컨트롤러를 교체해보겠다.

상당히 많은 여분 서버들..

동일 모델인데도 Super-Capacitor 모양이 달라 맞는 컨트롤러를 찾는데 시간이 걸리기도 했다.

교체 후 부팅 성공

RAID 컨트롤러를 교체하고 기도하며 서버를 다시 부팅하였다.

그리고 기도에 보답한걸까.... 성공적으로 부팅되었다.(본인은 무교다)

RAID 구성 차이를 감지하고 적용하는 메시지이다,

해당 메세지는 H750 RAID 컨트롤러를 교체 후 기존 RAID 구성 차이를 감지하여 적용하는 내용이다.

Message PR1: 서버에 RAID 컨트롤러가 교체된 것을 감지했다.
Message PR2: 교체된 RAID 컨트롤러와 디스크의 저장된 RAID 설정 간의 차이를 감지하였다.
Message PR3: RAID 컨트롤러가 디스크에 저장된 RAID 구성을 성공적으로 불러와 적용하였다.

결과적으로 RAID 구성이 유지되었고, 데이터 접근이 정상적으로 복구되었다.

즉, RAID 컨트롤러 교체가 정상적으로 적용되었고, 모든 물리 디스크 상태가 정상 상태임을 확인하였다.

모든 디스크에 초록불이 표시되며 정상 상태임이 확인된다.

데이터 백업이 잘 되어 있어서 다행이였지, RAID 컨트롤러 장애는 정말 치명적인 문제로 이어질 수 있다는 것을 실감한 경험이였다.

단순 OS나 서비스 모니터링 뿐 아니라, 하드웨어 점검과 백업 프로세스를 더 체계화 할 필요가 있음을 느끼게 되었다.

이렇게 여분 서버를 활용하여 비용과 시간을 절약할 수 있었다.

+여담. Tomcat 소스 연결 문제(파일시스템 손상)

서버 복구 후 개발 서비스를 다시 배포하던 중, 개발자분으로부터 연락을 받았다.

해당 경로를 확인해보니 다음과 같이 데이터가 나타난다.

오마이갓 비상사태

순간 데이터가 손상된 줄 알고 식은땀이 줄줄 흘렀다.

서버 복구 후 확인했을때는 기존 모든 데이터가 문제없이 존재했기 때문에 이 현상에 의문이 들었다.(해당 경로만 문제가 있었다.)

이후 확인해보니 RAID 복구와는 별개의 문제였다.

해당 경로에 소스 배포를 진행하던 중 서버가 다운되면서 파일 시스템이 손상된 것이 원인이였다.

파일 삭제 시도

일단 문제가 발생한 파일을 삭제하려 했으나, 아래와 같은 오류가 발생하였다.

rm: cannot remove 'WEB-INF/lib/log4j-api-2.17.2.jar': Structure needs cleaning

rm: cannot remove 'WEB-INF/lib/log4j-api-2.17.2.jar': Structure needs cleaning

rm 명령을 진행 시 나타났던 에러인데, 파일 시스템이 손상되었기에 해당 명령어를 동작시킬 수 없다는 것이였다.

이에 나는 다음과 같은 방법들로 삭제를 시도해보았다.

rm -rf 명령
inode 번호 확인하여 삭제
(find / -inum 1234 -exec rm -rf {} ;)
unlink 명령으로 삭제
dev/null 로 파일 덤프

결론으로는 파일 시스템이 손상된 상태에서는 해당 디렉터리나 파일 자체에 접근이 불가능하기 때문에 위 방법들은 모두 실패하였다.

파일 시스템 복구 진행(fsck 명령어)

파일 시스템 복구를 위해 fsck 명령을 사용했다.

1. 스토리지 마운트 해제

파일 시스템을 복구 하기 이전, 일단 해당 스토리지 umount를 진행한다.

umount /application_data

2. fsck 명령으로 파일 시스템 복구

손상된 파티션에 대해 fsck 명령을 진행한다.

이번 경우는 여러 디스크를 LVM으로 묶어서 사용 중이었기 때문에 LVM 경로로 진행했다.

파일 시스템이 정상적으로 복원되었다.

3. 복구 후 마운트

파일 시스템 복구가 완료된 후 다시 마운트를 진행하여 정상적으로 파일 삭제 및 재 배포가 완료되었다.

mount /application_data

5. 마무리

이번 작업을 통해 RAID 및 파일 시스템 복구라는 온프레미스 환경에서 전형적인 문제를 해결하면서 클라우드 중심의 업무 환경에서 잊고 있었던 중요한 교훈을 되새길 수 있었다.

클라우드 환경에 대한 기술과 관리에 집중하다 보니 온프레미스 환경과 로우 레벨 기술에 소홀했던 부분이 있었다는 점을 몸소 느낀 것 같다.. 특히! 물리 서버와 관련된 문제는 하드웨어와 소프트웨어간 섬세하고 긴밀한? 상호작용으로 많은 이해가 필요하다는 것을 다시 느끼게 되었다.

지금의 인프라 운영은 클라우드로 빠르게 전환되고 있다. 하지만 물리적인 환경이나 하드웨어에 기본적인 작동 원리에 대한 이해도는 언제나 중요한 기반이 되며 이번 같은 로우 레벨의 지식 또한 클라우드 문제 해결에 직접적이나 간접적으로도 기여할 수 있다고 생각한다.

역시 배움은 끝이 없는 것 같다. 클라우드와 온프레미스를 능숙히 다룰 수 있도록 열심히 노력해야겠다!!!

참고 자료

- https://www.dell.com/support/manuals/ko-kr/poweredge-r440/per440_ts_pub/스토리지-컨트롤러-사양?guid=guid-283f7608-ee08-46f0-b687-cbb9f50399e1&lang=ko-kr

- https://www.dell.com/support/kbdoc/ko-kr/000110444/poweredge-하드-드라이브-및-raid-스토리지의-이해-유지-관리-및-문제-해결

- https://louky0714.tistory.com/137

- https://ubuntuforums.org/showthread.php?t=2348768

- https://dasandata.tistory.com/entry/Dell-R740-서버-정전-후-UEFI0116-Avago-MegaRAID-FW-Fault-MFI-Register-0xF0FF8302-부팅-불가

- https://www.dell.com/community/en/conversations/poweredge-hardware-general/dell-perc-h730-driver-health/647f99cef4ccf8a8ded47693

- https://www.2cpu.co.kr/bbs/board.php?bo_table=4raid&wr_id=1730

- https://www.2cpu.co.kr/QnA/816089

- https://www.dell.com/support/kbdoc/ko-kr/000148741/인텔-perc-및-lsi-컨트롤러를-사용하여-raid를-생성하는-방법

- https://pubs.lenovo.com/x3550-m5-8869/ko/t_installing_raid_adapter

CywellSystem X Red Hat 'OpenShift & AI 세미나'

cwpack0730 — Mon, 25 Nov 2024 23:33:28 +0900

이번에 오픈시프트 세미나에 참석할 기회가 있었는데, 참석하며 얻은 내용과 제 생각을 공유하보려고 합니다.

세미나는 쿠버네티스 환경과 오픈시프트 활용, AI 등 다양한 주제가 진행되었습니다.

평소에도 관심있던 레드햇

저는 평소부터 레드햇에 관심이 많았습니다.

첫 프로젝트에서 RHEL를 주로 다뤘던 경험이 있고, 사수 역시 레드햇을 워낙 좋아해서 자연스럽게 영향을 받았습니다. 덕분에 RHCSA를 취득하였고, RHCE도 준비 중입니다.

그러던 어느 날 협력업체 영업대표님과 점심식사 자리에서 레드햇 컨퍼런스와 관련된 이야기를 나누게 되었습니다.

제가 레드햇에 관심이 많다 말씀드렸는데, 마침 그 업체에서도 레드햇 관련 사업을 진행하고 계셨었고, 그 후 몇 차례 레드햇 세미나 초청권을 받았지만, 바쁜 일정 탓에 참석하지 못해 늘 아쉬웠습니다.

그러다 이번에는 운 좋게 시간이 맞아 드디어 세미나에 참석하게 되었습니다.

강서구 양천로 우림블루나인비즈니스센터 3층에서 진행하였습니다.

또한 지금 서비스 중인 환경을 쿠버네티스로 전환하는데 관심이 있었는데, 세미나 참석 시 오픈시프트 60일 무료 사용권을 지원해준다는 내용이 있었고 마침 좋은 기회라고 생각해서 바로 등록했습니다.

쿠버네티스의 목적?

개인적으로 쿠버네티스는 인프라적인 관점보다는 애플리케이션인 측면에서 더 중요한 기술이라고 생각합니다. 즉, 인프라 효율성을 위해 쿠버네티스를 도입한다기 보단, 분리된 애플리케이션 환경(MSA)을 효율적으로 관리하는 것이 더 큰 목적이 되어야 한다고 생각합니다.

생각보다 일찍 도착해 1시간 정도 시간이 남아 카페에서 오픈시프트 관련해서 미리 살펴보고 있었습니다.

이런 관점에서 저는 쿠버네티스 환경부터 먼저 직접 구축하기보다는 우선 동작 중인 애플리케이션을 컨테이너화하고, MSA 아키텍처를 구성하며, 이에 맞게 CI/CD 환경을 먼저 세팅하고 나서 쿠버네티스 환경으로 전환하는데 더 효율적이라고 생각했습니다.

(요즘 쿠버네티스 전환 관련해서 여러 고민과 생각을 하다보니 쿠버네티스 환경 구성을 목표로 개발과 인프라가 따라가는게 아니라, 이미 고도화 된 개발/인프라의 프로세스를 뒷받침 해주기 위해 쿠버네티스가 필요하다고 느꼈습니다. 즉, 쿠버네티스는 목표가 아니라 과정이 되어야 하는게 옳다고 생각합니다.)

이런 이유로 쿠버네티스 환경을 일정 수준까지 관리해주는 오픈시프트에 관심을 가지게 되었고, 세미나에 참석하게 되었습니다.

강연 시작

카페에서 시간을 때우다 어느덧 세미나 시작 시간이 되어서 초청해주신 영업대표님에게 인사를 드린 후 강연실로 이동하였습니다.

입장하자마자 생각보다 사람들이 많아서 놀랐습니다.(거의 만석)

사람이 생각보다 많아 맨 앞자리에 앉았습니다.

컨테이너의 역사부터 쿠버네티스 개요까지

이번 세미나는 쿠버네티스의 기본 개념과 함께 오픈시프트로의 전환했을때의 이점, AI에 대한 내용으로 진행되었습니다.

그동안 다양한 it 세미나를 참석해봤지만, 상용 제품과 관련된 세미나는 종종 기술적인 내용보다는 제품 설명이나 홍보에 치우쳐 실망했던 적이 있었습니다.

하지만 이번 세미나는 다르다는 점을 느낄 수 있었는데, 준비 기간만 3~4개월을 들였다고 하셨고 그만큼 내용이 정말 알찼습니다.

가상화와 컨테이너의 개념부터 시작해 주요 특징과 RHEL에서 컨테이너를 실행하는 방법, 쿠버네티스 환경 구성과 아키텍처에 대한 설명까지 세세하게 다뤘으며, 특히 쿠버네티스의 주요 기능과 지원되지 않는 항목까지 짚어주셔서 지식이 없던 사람도 쉽게 이해할 수 있을 정도였습니다.

이렇게 기초부터 설명을 듣고 나니, 오픈시프트 파트를 들어갔을때 특징과 장점이 훨씬 와닿았습니다. 단순히 제품 설명을 넘어 실질적인 기술적인 내용을 얻을 수 있었다는 점에서 정말 만족스러웠습니다.

Grafana로 저런 애니메이션 효과를 낼 수 있는건가..? 제니퍼를 보는 줄 알았네요..

오픈시프트의 CI/CD

이번 세미나에서 특히 기억에 남는건 오픈시프트의 CI/CD 기능이였습니다.

오픈시프트는 기본적으로 쿠버네티스 환경 위에 모니터링과 CI/CD 기능이 통합되어 제공됩니다. 그래서 UI에서 Git 저장소 주소와 컨테이너 이미지만 지정하면 자동으로 해당 이미지에 소스가 빌드됩니다. (UI가 정말 직관적입니다.)

CI/CD 도구로는 Jenkins도 사용하나 오픈시프트 환경에서는 보통 Tekton이 더 적합하다고 합니다.

(Redhat 공식문서에서도 Tekton 사용을 권장하고 있습니다.)

그래서 오픈시프트 기반의 CI/CD는 보통 Tekton과 ArgoCD가 사용되는 경우가 많은 것 같습니다.

직접 쿠버네티스 환경의 CI/CD를 구성했을때에 비해 오픈시프트의 CI/CD 기능은 통합되어 자동으로 구성되어 UI로 관리하기 때문에 설정이나 운영, 모니터링이 더욱 간단합니다.

(또한 유지보수도 편해져서 할 일이 줄어드는거죠..)

그래서 이런 쿠버네티스 환경을 처음 접하거나 업무적인 효율성이 필요한 경우에 적합하다고 생각합니다.

Ai의 현재와 미래 (+장애처리)

오픈시프트 뿐만이 아니라 AI와 관련된 챕터도 진행되었습니다.

발표는 Ai의 여러 학습 방식과 이에 다른 결과 차이, 발전 과정, 그리고 현재 개발되는 기술들에 대한 내용이였는데 하필 세미나 도중 서비스 장애가 발생하는 바람에 제대로 못 들은 것이 너무 아쉬웠습니다.

(평소에는 멀쩡하다 꼭 이럴때만..왔다갔다 전화받고 확인하는데 하필 맨 앞자리라 눈치보였네요.. )

발표 내용 중 기억나는건 이미지 빅데이터를 분석하고 생성형 이미지를 만드는 과정, (생성형 AI중 가장 핫하죠.) 더 나아가서 이를 토대로 영상까지 생성하는 기술의 발전 과정이였습니다. 특히 발표자분이 주제에 대해 정말 많은 관심과 애정을 가지고 계신지 느껴질 정도로 발표 준비를 많이 하신 것 같았습니다.

예기치 못한 상황이 있어서 발표 내용을 온전히 다 듣지는 못했지만, 짧게마나 Ai에 현재와 미래에 대한 생각을 하게 되는 시간이였습니다.

마치며

수료증과 사은품을 받았습니다. (세미나에서 수료증을 받은건 처음이네요.)

위 내용은 정말 일부이고, 오픈시프트의 오토스케일링이나 모니터링 그리고 VM 관리 기능이 포함된 오픈시프트 OV 등 정말 많은 내용이 있었지만 글이 너무 길어질 것 같아 전부 담지 못했습니다.

이렇게 CywellSystem과 Red Hat이 주관한 이번 Openshift & AI 세미나는 정말 만족스러웠습니다.

현재 운영중인 시스템을 쿠버네티스 환경으로 전환하고 싶은 개인적인 목표와, 이를 개발팀이나 임원진들에게 어떻게 설득할지에 대한 고민이 많았던 터라 이번 세미나는 저에게 큰 의미가 있었습니다.

컨테이너의 역사부터 최근 서비스 운영의 트렌드, 이에 맞춰서 변화하는 애플리케이션 관리 방식까지 다시 확인하며 정리가 되었고, 쿠버네티스 환경으로의 전환이 나 혼자만의 생각이나 욕심이 아니라 정말 앞으로 필요한 목표라는 생각을 다시 한번 가지게 되었습니다.

다음에도 이런 기회가 있으면 꼭 다시 참석하고 싶습니다~ !!

좋은 자리를 마련해주신 영업대표님과 열정적으로 발표를 준비해주신 발표자분들께 감사드립니다.

꾸벅 ( _ _ )

[Linux] ulimit 개념 및 설정 방법(사용자 별 자원 관리)

cwpack0730 — Mon, 18 Nov 2024 17:46:04 +0900

1. ulimit 이란?

ulimit Soft(좌) Hard(우) 설정 값

ulimit는 리눅스(유닉스)에서 사용자별로 프로세스의 자원 한도를 설정하거나 확인할 수 있는 명령어이다.

위 ulimit soft 값과 hard 값을 비교해보면 hard의 값이 훨신 크게 잡혀 있는 것을 알 수 있다.

사용자가 실행하는 프로세스에 대해 다음과 같은 자원 제한을 설정한다.

파일 크기
열 수 있는 파일의 최대 수
사용 가능 메모리
CPU 시간
프로세스 개수
코어 덤프 크기

ulimit [옵션] 값 ( Centos , RHEL 기준)

a : 모든 제한 사항을 보여줌.
c : 최대 코어 파일 사이즈
d : 프로세스 데이터 세그먼트의 최대 크기
f : shell에 의해 만들어질 수 있는 파일의 최대 크기
s : 최대 스택 크기
p : 파이프 크기
n : 오픈 파일의 최대수
u : 오픈파일의 최대수
v : 최대 가상메모리의 양
S : soft 한도
H : hard 한도

각 항목의 설명

# ulimit -a // Soft 설정 보기

# ulimit -aH // Hard 설정 보기

core file size (blocks, -c) 0 : 코어파일의 최대크기

data seg size (kbytes, -d) unlimited : 프로세스의 데이터 세그먼트 최대크기

scheduling priority (-e) 0

file size (blocks, -f) unlimited :쉘에서 생성되는 파일일 최대크기

pending signals (-i) 14943

max locked memory (kbytes, -l) 64

max memory size (kbytes, -m) unlimited : resident set size의 최대 크기(메모리 최대크기)

open files (-n) 1024 : 한 프로세스에서 열 수 있는 open file descriptor의 최대 숫자(열수 있는 최대 파일 수) ,Too many open files error 발생시 해당값 조절해주면됨

pipe size (512 bytes, -p) 8 : 512-바이트 블럭의 파이프 크기

POSIX message queues (bytes, -q) 819200

real-time priority (-r) 0

stack size (kbytes, -s) 10240

cpu time (seconds, -t) unlimited : 총 누적된 CPU 시간(초)

max user processes (-u) 1024 : 단일 유저가 사용가능한 프로세스의 최대 갯수

virtual memory (kbytes, -v) unlimited : 쉘에서 사용가능 한 가상 메모리의 최대 용량

file locks (-x) unlimited

2. ulimit의 종류

ulimit은 soft 제한과, hard 제한 두가지로 나뉜다.

soft : 사용자가 현재 사용할 수 있는 자원의 최대치로, 하드 제한보다 낮게 설정할 수 있다.
일시적으로 변경할 수 있으며 재 로그인하면 기본값으로 변경된다.
hard : 시스템에서 허용하는 자원의 최대치. 관리자를 제외한 일반 사용자는 하드 제한을 초과할 수 없다.

설정방법

1. ulimit 명령을 통한 변경

-n -u를 사용하여 max user process와 open files 개수를 수정한다.

ulimit -n 2048
ulimit -u 4096

ulimit -a
open files        (-n) 2048
max user processes       (-u) 4096

소프트 제한 변경

ulimit -n 4096

하드 제한 변경 (root 관리자 권한 필요)

ulimit -Hn 8192

ulimit 명령으로 설정한 값은 현재 세션에서만 적용된다. 즉, 재 접속시에는 기본값으로 초기화되기 때문에 영구적으로 설정하러면 /etc/profile 또는 사용자 별 .bashrc 파일에 명령어를 추가해야 한다.

혹은 다음과 같이 limits.conf 파일을 수정하는 방법이 있다.

2. /etc/security/limits.conf 설정 파일 수정

vi /etc/security/limits.conf
username hard nofile 8192
username soft nofile 4096
*       soft nproc 4096
*       hard nproc 4096

User 별로 설정 가능하다.

3. 확인

재 로그인 or 리부팅할 경우 기본 설정으로 적용된다.

# ulimit -aH

core file size (blocks, -c) unlimited

data seg size (kbytes, -d) unlimited

scheduling priority (-e) 0

file size (blocks, -f) unlimited

pending signals (-i) 14943

max locked memory (kbytes, -l) 64

max memory size (kbytes, -m) unlimited

open files (-n) 2048

pipe size (512 bytes, -p) 8

POSIX message queues (bytes, -q) 819200

real-time priority (-r) 0

stack size (kbytes, -s) unlimited

cpu time (seconds, -t) unlimited

max user processes (-u) 4096

virtual memory (kbytes, -v) unlimited

file locks (-x) unlimited

[OpenVPN] OpenVPN Server 구축(Linux)

cwpack0730 — Sun, 17 Nov 2024 21:34:38 +0900

개요

예전 사내에 Fortigate SSL-VPN을 구성한적이 있는데 macOS를 사용하는 PC에서는 접속이 안되는 문제가 있었다.

이에 원인은 잘 모르겠지만 당장 접속이 필요한 상황이기 때문에 OpenVPN Server를 구축하여 VPN 통신을 구현해보겠다.

1. 실습 환경

# 실습 환경
cat /etc/*release*
CentOS Linux release 8.5.2111
Derived from Red Hat Enterprise Linux 8.5
NAME="CentOS Linux"
VERSION="8"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-8"
CENTOS_MANTISBT_PROJECT_VERSION="8"
CentOS Linux release 8.5.2111
CentOS Linux release 8.5.2111
cpe:/o:centos:centos:8

2. OpenVPN 서버 구축

openVPN을 구성할 linux 서버에 접속 후 다음 작업을 진행한다.

직접 구성하는 방식과 제공하는 스크립트로 간편하게 구성하는 방식이 있다. 본인은 스크립트로 설정을 진행해보겠다.

# openvpn 자동설치 shell file pull
wget https://git.io/vpn -O openvpn-install.sh

# 파일 실행권한 부여
sudo chmod +x openvpn-install.sh

vpn 설정을 진행한다.

# 스크립트 실행
sudo bash openvpn-install.sh
or
./openvpn-install.sh

Welcome to the OpenVPN installer!
The git repository is available at: https://github.com/angristan/openvpn-install

I need to ask you a few questions before starting the setup.
You can leave the default options and just press enter if you are ok with them.

# OpenVPN에서 사용할 IP 주소이다.
**I need to know the IPv4 address of the network interface you want OpenVPN listening to.
Unless your server is behind NAT, it should be your public IPv4 address.
IP address: 192.168.100.xxx**

# 공용 IPv4 주소 혹은 호스트 이름을 입력한다.
**It seems this server is behind NAT. What is its public IPv4 address or hostname?
We need it for the clients to connect to the server.
Public IPv4 address or hostname: cwOpenVPN**

Checking for IPv6 connectivity...

Your host does not appear to have IPv6 connectivity.

# IPv6는 사용하지 않게 설정했다.
Do you want to enable IPv6 support (NAT)? [y/n]: n

# OpenVPN 포트를 설정한다. 본인은 기본으로 설정하였다.
**What port do you want OpenVPN to listen to?
   1) Default: 1194
   2) Custom
   3) Random [49152-65535]
Port choice [1-3]: 1**

# 프로토콜을 선택한다.
**What protocol do you want OpenVPN to use?
UDP is faster. Unless it is not available, you shouldnt use TCP.
   1) UDP
   2) TCP
Protocol [1-2]: 1**

# DNS resolve를 선택한다. 각 DNS 별 특징이 있으니 잘 찾아보고 선택하자.
**What DNS resolvers do you want to use with the VPN?
   1) Current system resolvers (from /etc/resolv.conf)
   2) Self-hosted DNS Resolver (Unbound)
   3) Cloudflare (Anycast: worldwide)
   4) Quad9 (Anycast: worldwide)
   5) Quad9 uncensored (Anycast: worldwide)
   6) FDN (France)
   7) DNS.WATCH (Germany)
   8) OpenDNS (Anycast: worldwide)
   9) Google (Anycast: worldwide)
   10) Yandex Basic (Russia)
   11) AdGuard DNS (Anycast: worldwide)
   12) NextDNS (Anycast: worldwide)
   13) Custom
DNS [1-12]: 11**

Do you want to use compression? It is not recommended since the VORACLE attack makes use of it.
Enable compression? [y/n]: n

Do you want to customize encryption settings?
Unless you know what you're doing, you should stick with the default parameters provided by the script.
Note that whatever you choose, all the choices presented in the script are safe. (Unlike OpenVPN's defaults)
See https://github.com/angristan/openvpn-install#security-and-encryption to learn more.

Customize encryption settings? [y/n]: n

Okay, that was all I needed. We are ready to setup your OpenVPN server now.
You will be able to generate a client at the end of the installation.
Press any key to continue...

**Tell me a name for the client.
The name must consist of alphanumeric character. It may also include an underscore or a dash.
Client name: cwVPN_Client**

**Do you want to protect the configuration file with a password?
(e.g. encrypt the private key with a password)
   1) Add a passwordless client
   2) Use a password for the client
Select an option [1-2]: 2**

ovpn 파일이 생성되었다.

설정이 완료되면 다음과 같이 ovpn 파일이 생성된다.

해당 파일로 VPN 접근이 가능하다.

이후 서버 방화벽에 포트를 추가한다.

# 포트 추가
firewall-cmd --zone=public --add-port=2294/udp --permanent 
firewall-cmd --zone=public --add-port=21194/udp --permanent 
firewall-cmd --zone=public --add-port=1194/udp --permanent

# 적용
firewall-cmd --reload
firewall-cmd --list-all

3. Windows에서 Client 연결

다운로드 및 설치를 진행한다.

https://openvpn.net/community-downloads/

Community Downloads - Open Source VPN | OpenVPN

The OpenVPN community shares the open source OpenVPN. Download the latest version of the open source VPN release OpenVPN 2.6.3 for a secure network.

openvpn.net

다운받은 cwVPN_Client.ovpn 파일을 import > 파일 불러오기 로 연결한다.

사진-2

사진-3

파일을 생성할 때 암호 사용 설정을 진행했었다. 암호를 입력한다.

사진-4

연결 완료

연결이 완료되었다.

TMI: 추가로 원인은 macOS 문제가 아닌 테더링/핫스팟으로 연결한 문제였다. 보통 이 경우 ipv6로 연결되기 때문에 ipv4 연결만 구성한 기존 VPN 연결이 차단된 것이다.
위 설정을 보면 openvpn도 ipv6를 비활성화 했기 때문에 요청한 PC에서는 openvpn으로도 접속이 불가했을 것이다.

[Tomcat] Apache Tomcat 실행 시 포트 정보(HTTP/HTTPS, AJP 커넥터, Shutdown 등)

cwpack0730 — Sat, 16 Nov 2024 23:29:05 +0900

개요

Tomcat은 server.xml 파일에서 여러 포트를 설정할 수 있는데, 각 포트는 다른 목적으로 사용된다.

주요 포트와 기능에 대해서 설명해보겠다.

1. Connector Port (HTTP/HTTPS)

HTTP 포트 구성. 가장 많이 사용할 것이다.

클라이언트가 HTTP 혹은 HTTPS 프로토콜로 웹 애플리케이션에 접근할 수 있도록 설정하는 포트이다.

태그에서 설정하며 기본적으로 HTTP: 8080, HTTPS: 8443 포트로 적용되어있다.

HTTPS의 경우는 기본적으로 비활성화 되어있다. 사용하러면 주석을 제거하고 SSL 인증서 경로를 지정해주면 된다.

HTTPS 포트 구성. 기본적으로 비활성화 되어있다.

2. Shutdown Port

경우에 따라 비활성화하여 사용하기도 한다.

Tomcat은 안전하게 종료하기 위해 shutdown 포트가 존재한다. 지정한 port를 통해 SHUTDOWN 명령어를 진행하면 tomcat 프로세스를 종료한다.

<Server port="8005" shutdown="SHUTDOWN">
    ...
</Server>

태그에서 지정할 수 있기 때문에 위 이미지에서는 한 라인만 강조하였지만 하위 모든 속성들이 모두 포함되는 형태이다.

기본 포트로는 8005로 설정되어있다.

해당 shutdown 포트를 사용하지 않고 싶다면, 해당 포트를 "-1"로 설정하면 된다.

! tomcat 기동시 HTTP 포트뿐만이 아닌 해당 포트들도 충돌 시 동작하지 않기 때문에, 여러 tomcat이 기동할때는 모든 port 정보를 다르게 구성해야 한다.

3. AJP (Apache JServ Protocol) Port

AJP 포트 구성. 기본적으로 비활성화 되어있다.

Apache HTTP 서버(Apache HTTPd)와 같은 웹 서버와 tomcat 간에 바이너리 데이터를 주고받는 데 사용된다. (보통 프록시 서버를 설정할 때 사용된다.)

HTTPS port와 마찬가지로 처음 구성 시 비활성화 되어있으며, 태그에서 설정이 가능하고 8009port로 기본 설정이 되어있다.

HTTP와 달리 *바이너리 데이터를 주고받으며, 성능이 향샹될 수 있다.

* 바이너리 데이터란 2진수(0과 1)로 표현된 데이터로 컴퓨터 시스템에서 효율적으로 처리할 수 있는 형태이다. 텍스트 기반의 데이터보다 효율성(바이트 크기) 속도(텍스트 파싱이 필요없음), 데이터가 압축되어 전송하기 때문에 불필요한 공백/해더 등이 제거되는 장점이 있다.

4. JMX (Java Management Extensions) Port

webapps/docs/cluster-howto.html

webapps/docs/monitoring.html

애플리케이션과는 직접적인 연관은 없는 포트인데, Tomcat의 모니터링 및 관리를 위해 사용한다.

(위 JMX 포트를 통해서 tomcat의 상태를 외부에서 확인할 수 있게 된다.)

기본적으로 설정되지 않으며 이미지처럼 java 옵션으로 설정해야 한다.

혹은 다음과 같이 intellij 프로젝트에서 설정할 수 있다.

intellji에서 다음과 같이 JMX 포트를 설정할 수 있다. 이클립스도 가능

요약

Port	기본값	역할
HTTP	8080	클라이언트 HTTP 요청 처리
HTTPS	8443	클라이언트 HTTPS 요청 처리
Shutdown	8005	Tomcat 서버 종료
AJP	8009	웹 서버와 Tomcat 간의 연결
JMX	1099	모니터링 및 관리

[Tools] 크기가 큰 텍스트 파일 열기(파일 분할)

cwpack0730 — Fri, 15 Nov 2024 18:03:28 +0900

개요

tomcat 로그를 확인하려하는데, 용량이 너무 커 메모장으로 열 수 없는 상황이다.

에러 로그

어느 정도의 GB 크기의 텍스트 파일은 메모장 외에도 notepad++, visual studio 등의 툴을 사용해서 open할 수 있으나, 내가 확인하려는 텍스트 파일은 40GB(…)를 넘는다.

오랜 시간 끝에 파일을 열어도 일부만 출력되고 나머지는 잘리는 상태인데,

이에 텍스트 파일을 분할하는 방법을 소개하겠다.

1. 텍스트 파일 분할

Text Cleaver.exe

0.10MB

용량은 큰 텍스트의 파일을 라인(줄) 기반으로 분할해주는 프로그램이다.

다운로드 후 실행하면 다음과 같이 나타난다.

사진-2

이후 GO를 선택하면 파일 분할을 시작한다.

사진-3

파일 분할이 정상적으로 완료되었다. 이제 내용 확인이 가능해졌다.

사진-4

[Nginx] 애플리케이션 토큰 헤더 요청 오류 (헤더 옵션 변경)

cwpack0730 — Thu, 14 Nov 2024 23:56:05 +0900

개요

현재 신규 서비스를 개발하고 있는데 빌드가 완료되어 개발서버에 배포를 진행하고 있다.

spring 기반의 서비스이며 nginx와 tomcat으로 운영하고 있는데 서비스 호출은 정상이나 몇몇 api 및 토큰 요청에 문제가 있는 상황이다.

이에 nginx 설정 중 헤더 구성에 원인이 있다고 판단하여 nginx 설정을 확인해보는 시간을 가져보겠다.

현재 구성( nginx.conf )

다음은 예시로 구성한 nginx.conf 이다.

upstream cwking {
    server 192.168.100.20:8080;
}

server {
    listen        80;
    server_name woodev.devcw.site ;

    location / {
        proxy_pass http://cwking/;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /robots.txt {
            return 200 "User-agent: *\nDisallow: /";
        }

    access_log  /app/weblog/woodev.devcw.site-access.log  main;
    error_log /app/weblog/woodev.devcw.site-error.log;
}

tomcat(spring)은 8080 포트로 동작한다고 가정하였을때,

woodev.devcw.site URL에 접근 시 root 경로로 tomcat으로 이동하도록 proxy pass를 구성하였다.

proxy_set_header 지시어로 tomcat이 요청을 처리할 때 클라이언트가 요청한 도메인, 서버 이름 등을 알 수 있게 한다.

Host $host; : 클라이언트 요청의 Host 헤더 값을 백엔드로 전달한다.
X-Forwarded-For $proxy_add_x_forwarded_for; : 클라이언트의 원본 IP 주소를 포함한 X-Forwarded-For 헤더를 백엔드 서버로 전달한다.

위 구성으로 실행하였을때, 서비스 동작 및 api 호출에 문제가 없었다. 그러나 몇몇 호출이나 토큰 응답값 등을 전달/받아오지 못하는 현상이 발생하였는데, 다음과 같이 수정하여 해결하였다.

수정된 구성( nginx.conf )

upstream cwking {
    server 192.168.100.20:8080;
}

server {
    listen        80;
    server_name woodev.devcw.site ;
    # 추가 1
    underscores_in_headers      on;

    location / {
        proxy_pass http://cwking/;
        # 수정 proxy_set_header Host $host;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # 추가 2
        proxy_pass_request_headers  on;
    }

    location /robots.txt {
            return 200 "User-agent: *\nDisallow: /";
        }

    access_log  /app/weblog/woodev.devcw.site-access.log  main;
    error_log /app/weblog/woodev.devcw.site-error.log;
}

추가 및 수정된 항목에 대해 설명하겠다.

underscores_in_headers on;

밑줄이 포함된 헤더를 허용한다는 설정인데, 해당 설정을 활성화하면 클라이언트가 밑줄이 포함된 헤더를 보내도 nginx에서 이를 정상적으로 허용하여 백엔드로 전달한다.

nginx에서 기본적으로는 off 설정으로 되어있다.

! 기본적으로 _(밑줄) 헤더 호출을 차단하는 이유 :
보안 정책과 표준 HTTP 규격을 준수하기 위함인데, HTTP 표준에서는 _(밑줄) 대신 -(하이픈)을 헤더 구분자로 사용하는 것을 권장한다.

proxy_set_header Host $http_host

proxy_set_header Host 설정을 $host에서 $http_host로 변경하였다.

$host는 클라이언트 요청의 Host 헤더에 따라 변경될 수 있으나 #http_host는 클라이언트의 원본 Host 헤더 값을 전달하므로, 원래 호스트 정보가 보장된다.

(조사해보니 Spring 보안 설정에서는 토큰을 생성할 때 호스트 정보가 필요할 수 있는데, $http_host 로 설정하지 않으면 올바른 정보를 전달하지 못해 요청이 실패할 수 있다고 한다.)

proxy_pass_request_headers on;

nginx가 클라이언트의 모든 요청 헤더를 프록시로 전달하도록 한다.

이 설정이 없으면 일부 헤더가 생략되거나 기본값으로 설정될 수 있다고 한다.
인증 및 토큰 요청에서는 Authorization이나 Cookie 같은 헤더가 필요하며, 이 헤더들이 제대로 전달되지 않으면 인증이나 세션 관리가 정상적으로 작동하지 않을 수 있다.

마무리

내가 직접 개발 서버 환경을 구성했는데 개발자분께서 로컬 환경과 동작이 다르게 나타난다고 하셔서 spring 부터 tomcat 설정 변경, 버전 변경, java 버전변경 등 모두 살펴봐도 시스템 상에서의 서비스 동작에는 아무런 문제가 없었다.

다시 개발자분과 구두로 직접 이야기해보면서 동작에 차이가 발생하는것이 헤더 호출 부분이라는 것을 듣자마자 nginx 헤더 설정에 원인이 있다고 생각되어 수정을 진행하고 정말 다행히도 빠르게 해결되어서 다행이였다.

[Proxmox] 하이퍼바이저 재시작 후 VM 실행 오류 (no quorum, vm is locked)

cwpack0730 — Wed, 13 Nov 2024 22:51:01 +0900

개요

개발환경으로 여러대의 온프레미스를 proxmox 서버로 하이퍼바이저를 구성하여 다양한 개발환경으로 사용중에 있다.

오늘 비상전력 작업이 있어, 시스템 재기동을 함께 진행하였는데 proxmox가 재기동 후 몇몇 VM들이 실행되지 않는 현상이 발생하였다.

이에 proxmox VM 실행 오류 2가지의 해결 방법에 대해 알아보겠다.

1. VM is locked (snapshot)

현재 100 VMID의 VM이 잠금 표시가 나타나며 실행되지 않는 상황이다.

잠금 표시가 나타났다.

정확하게는 "VM is locked (snapshot)” 라고 에러가 나타나며 VM이 실행되지 않는데, 이는 표기 그대로 VM이 잠금 상태가 되었기 때문이다.

주로 스냅샷 작업 도중 시스템이 중단되거나 재시작된 경우 발생할 수 있다고 한다.

proxmox 서버에 cli로 접근하여 다음 명령을 입력해서 상태를 확인한다.

잠금 상태 확인

qm listn ‘VMID’

명령어 결과를 보면 VMID 100번이 실행되지 않는것을 확인할 수 있다.

실행중이지 않기 때문에 PID가 0인 것을 확인할 수 있다.

다음 명령으로 잠금을 해제하고 vm start를 진행하겠다.

잠금 해제

qm unlock ‘VMID'

VM 실행 (콘솔에서 GUI로 실행하는 것과 동일하다.)

qm start 'VMID'

사진-3

정상 동작이 확인된다.

2. cluster not ready - no quorum? (500)

오류가 발생한 환경을 잠시 설명하자면,

해당 proxmox서버의 경우는 2개의 proxmox서버를 합쳐 cluster로 동작하고 있었는데, 이후 노드 1개가 제외되어 1개의 노드(proxmox 서버)만 동작중에 있다.

이때 vm 실행 시 no quorum 가 발생하여 실행되지 않는데, 이는 proxmox cluster 중에서 노드 중 하나 이상이 down되어 있거나 네트워크 연결이 끊겼을 때 발생한다.

! proxmox는 홀수 개의 노드로 구성하는것이 좋다.
예를 들어 3개 노드 cluster에서라면, 2개 이상의 노드가 살아 있어야 쿼럼을 유지할 수 있다.
~~(마치 쿠버네…..)~~

즉, 쿼럼을 확보하러면 노드 수를 늘리거나 down된 노드를 다시 켜는 방법이 일반적이다.

나의 경우에는 노드 1개 단일로 사용중이기 때문에 vm 실행 시 쿼럼 인증(요구) 설정을 해제하여 동작시켰다.

다음 명령으로 status를 확인한다.

클러스터 상태 및 쿼럼 여부 확인

pvecm status

사진-4

1, 2는 하이퍼바이저 1, 2를 뜻한다.

Expected votes, Total votes를 확인하면 cluster가 쿼럼을 얼마나 유지하는 지 확인할 수 있다.

(위의 경우 1)

다음 명령을 입력하여 쿼럼 확인 절차를 비활성화한다.

pvecm expected 1

사진-5

위와 같은 조치를 통해 오류를 해결하고 정상적으로 동작할 수 있게 되었다.