https://school.programmers.co.kr/learn/courses/30/lessons/293260

Level: 2

문제 설명

낚시앱에서 사용하는 FISH_INFO 테이블은 잡은 물고기들의 정보를 담고 있습니다. FISH_INFO 테이블의 구조는 다음과 같으며 ID, FISH_TYPE, LENGTH, TIME은 각각 잡은 물고기의 ID, 물고기의 종류(숫자), 잡은 물고기의 길이(cm), 물고기를 잡은 날짜를 나타냅니다.

단, 잡은 물고기의 길이가 10cm 이하일 경우에는 LENGTH 가 NULL 이며, LENGTH 에 NULL 만 있는 경우는 없습니다.

문제

월별 잡은 물고기의 수와 월을 출력하는 SQL문을 작성해주세요.

잡은 물고기 수 컬럼명은 FISH_COUNT, 월 컬럼명은 MONTH로 해주세요. 결과는 월을 기준으로 오름차순 정렬해주세요. 단, 월은 숫자형태 (1~12) 로 출력하며 9 이하의 숫자는 두 자리로 출력하지 않습니다. 잡은 물고기가 없는 월은 출력하지 않습니다.

SELECT COUNT(ID) AS FISH_COUNT, MONTH(TIME) AS MONTH
FROM FISH_INFO
GROUP BY MONTH(TIME)
ORDER BY MONTH ASC;

GROUP BY와 ORDER BY를 사용하여 간단하게 풀 수 있는 문제.

Level: 2

문제 설명

대장균들은 일정 주기로 분화하며, 분화를 시작한 개체를 부모 개체, 분화가 되어 나온 개체를 자식 개체라고 합니다. 다음은 실험실에서 배양한 대장균들의 정보를 담은 ECOLI_DATA 테이블입니다. ECOLI_DATA 테이블의 구조는 다음과 같으며, ID, PARENT_ID, SIZE_OF_COLONY, DIFFERENTIATION_DATE, GENOTYPE 은 각각 대장균 개체의 ID, 부모 개체의 ID, 개체의 크기, 분화되어 나온 날짜, 개체의 형질을 나타냅니다.

최초의 대장균 개체의 PARENT_ID 는 NULL 값입니다.

문제

각 분기(QUARTER)별 분화된 대장균의 개체의 총 수(ECOLI_COUNT)를 출력하는 SQL 문을 작성해주세요. 이때 각 분기에는 'Q' 를 붙이고 분기에 대해 오름차순으로 정렬해주세요. 대장균 개체가 분화되지 않은 분기는 없습니다.

SELECT CONCAT(CEIL(MONTH(DIFFERENTIATION_DATE) / 3), 'Q') QUARTER, COUNT(ID) ECOLI_COUNT
FROM ECOLI_DATA
GROUP BY QUARTER
ORDER BY QUARTER

MONTH 함수를 이용해 '월'을 뽑아낸다. 그 후 3으로 나누고 올림(CEIL)해주면 분기를 구할 수 있다. QUARTER 함수는 특정 날짜가 속한 연도의 분기를 1부터 4까지의 정수 값으로 반환한다.

DNS란

DNS 서비스

DNS는 Domain Name System의 약어로, 네트워크 통신으 위한 주소 체계를 문자 형태인 도메인으로 매핑하여 연결하는 서비스를 의미한다. 여기에서 네트워크 통신 주소는 일반적으로 IP 주소를 사용하는데, 한마디로 IP 주소를 문자 형태의P 주소를 사용하는데, 한마디로 IP 주소를 문자 형태의 도메인 주소로 매핑해서 사용하는 서비스를 의미한다.

예를 들어 구글 웹 페이지에 접속한다고 가정하면, 구글 웹 서버의 IP 주소로 접속해야 한다. 하지만 우리는 IP 주소가 아닌 google.com이라는 문자로 된 주소로 접속한다. DNS 서비스 덕분에 바로 이런 google.com이라는 도메인 주소로 구글 웹 페이지에 접근할 수 있다.

그렇다면 도메인 주소를 활용한 웹 서버 접근은 어떤 단계를 거치는가?

1. 웹 서버의 IP 주소를 도메인 주소로 사용하고자 ongja.com 도메인을 구매하고 등록한다. 그러면 DNS 서버는 ongja.com의 IP 주소가 무엇인지 알고 정보를 기록해둔다.

2. 사용자는 ongja.com이라는 도메인 주소가 어떤 IP 주소인지 모르고 있으므로 해당 정보를 확인하는 작업이 필요하다.

3. 사용자는 도메인 주소의 IP 주소를 확인하기 위해 DNS 서버에 ongja.com의 도메인 주소를 요청하고 응답받는다. 이때 UDP 53번 포트를 사용하는 DNS 프로토콜을 이용하여 통신한다. 그러면 사용자는 ongja.com에 대한 IP 주소가 무엇인지 알 수 있다.

4. 사용자는 ongja.com의 IP 주소를 알아냈기 때문에 해당 IP 주소로 통신한다.

물론 DNS 서버는 용도에 따라 종류가 다양하며 이들 사이에 복잡한 통신 과정이 있다.

도메인 구조

루트 도메인

우리가 사용하는 모든 도메인 주소의 가장 마지막에는 온점이 있는데, 일반적으로 이 부분은 생략하고 사용한다. 여기에서 마지막에 위치하는 온점을 루트 도메인이라고 한다.

탑 레벨 도메인

도메인 주소에서 가장 상위에 위치한 도메인을 탑 레벨 도메인이라고 하며, 줄여서 TLD(Top Level Domain)라고 한다.

세컨드 레벨 도메인

TLD 다음에 위치한 두 번째 도메인 영역을 세컨드 레벨 도메인이라고 하며, 줄여서 SLD(Second Level Domain)라고 한다. 이런 SLD는 상위 TLD에서 유일하게 존재하고 식별하는 도메인 영역이다. 일반적으로 도메인 이름은 SLD와 TLD를 합친 형태로 표현한다.

서브 도메인

도메인을 용도에 따라 앞에 명칭을 부여해서 분류할 수 있는데, 이를 서브 도메인이라고 한다.

DNS 서버 종류

도메인 구조를 루트 도메인, 탑 레벨 도메인, 세컨드 레벨 도메인, 서브 도메인으로 구분하는 가장 큰 이유는 영역별 도메인을 관리하는 주체를 분리하기 위해서이다. 도메인은 DNS 네임 서버로 관리하는데, 이때 도메인 영역별로 DNS 네임 서버를 분류해서 관리한다.

루트 네임 서버

루트 도메인을 관리하는 DNS 서버를 루트 네임 서버라고 한다. DNS 요청에 대해 TLD에 해당하는 네임 서버 정보를 응답한다. 루트 네임 서버는 전 세계에 13개만 존재한다.

TLD 네임 서버

도메인 이름의 최상위 영역인 TLD를 관리하는 DNS 서버로, TLD 네임 서버라고 한다. TLD 영역에서 식별되는 모든 SLD를 관리하여 DNS 요청에 대해 SLD 네임 서버 정보를 응답한다. 예를 들어 .com이라는 TLD 네임 서버는 .com 내에 있는 google.com 도메인을 관리하는 SLD 네임 서버 정보를 알고 있다. 해당 도메인에 대한 DNS 요청이 있으면 SLD 네임 서버 주소를 알려준다.

SLD 네임 서버

실질적인 도메인 이름을 관리하는 DNS 서버로, SLD 네임 서버(권한 있는 네임 서버)라고 한다. 이런 SLD 네임 서버는 실제 도메인의 최종 관리 서버로 권한이 있는 네임 서버라고 한다. 도메인 주소에 대한 IP 주소를 확인하는 가장 마지막 단계이다.

DNS 해석기

사용자와 네임 서버 사이에서 중계자 역할을 수행하는 목적으로 DNS 해석기가 있다. 사용자가 DNS 해석기로 DNS 요청을 하면, DNS 해석기가 DNS 네임 서버와 정보를 주고받아 도메인 주소를 해석하여 최종적으로 IP 주소를 사용자에게 알려준다.

DNS 통신 흐름

1. 사용자 PC에서 blog.cloudneta.net이라는 도메인 주소의 IP 주소를 알기 위해 DNS 서버에 질의한다. 여기에서 DNS 서버는 DNS 해석기를 이용하여 다양한 네임 서버와 통신하는 중계자 역할을 수행한다.

2. 기본적으로 DNS 해석기는 전 세계에 있는 루트 네임 서버의 주소를 알고 있다. 해당 루트 네임 서버에 blog.cloudneta.net 도메인 주소의 IP 주소를 물어본다. 여기에서 루트 네임 서버는 blog.cloudneta.net이라는 도메인 주소를 알지 못하지만 .net의 TLD 네임 서버는 알고 있기 때문에 해당 정보를 DNS 해석기에 전달한다.

3. 그러면 DNS 해석기는 .net에 해당하는 TLD 네임 서버에 blog.cloudneta.net 도메인 주소의 IP 주소를 물어본다. 여기에서 TLD 네임 서버는 blog.cloudneta.net이라는 도메인 주소를 알지 못하지만 cloudneta.net의 SLD 네임 서버는 알고 있어 해당 정보를 DNS 해석기에 전달한다.

4. 다시 DNS 해석기는 cloudneta.net에 해당하는 SLD 네임 서버에 blog.cloudneta.net 도메인 주소의 IP 주소를 물어본다. 이 SLD 네임 서버는 도메인 주소의 최종 정보가 있는 '권한이 있는 네임 서버'로, blog.cloudneta.net에 대한 IP 주소를 DNS 해석기에 전달한다.

5. DNS 해석기는 blog.cloudneta.net에 대해 최종적으로 해석한 IP 주소를 사용자 PC에 전달한다. 이것으로 사용자 PC는 blog.cloudneta.net 도메인 주소의 IP 주소를 알게 되어 해당 IP 주소로 통신한다.

DNS 레코드 유형

DNS 레코드는 도메인에 대한 요청 처리 방법을 정의한 것으로, 용도에 따라 DNS 레코드 유형을 분류한다.

A 레코드 유형

도메인 이름을 IPv4 주소로 매핑하는 가장 기본적인 DNS 레코드 유형이다. 다음 형태로 표현한다. blog.cloudneta.net A 52.219.60.13 blog.cloudneta.net이라는 도메인 주소로 질의하면 IPv4 주소인 52.219.60.13으로 응답한다.

AAAA 레코드 유형

도메인 이름을 IPv6 주소로 매핑하는 DNS 레코드 유형이다. A 레코드 유형의 IPv6 버전이라고 생각하면 된다. 다음 형태로 표현된다. blog.cloudneta.net AAAA 2001:A10::2001 blog.cloudneta.net이라는 도메인 주소로 질의하면 IPv6 주소인 2001:A10::2001로 응답한다.

NS 레코드 유형

도메인 이름의 네임 서버 주소로 매핑하는 DNS 레코드 유형이다. 다음 형태로 표현한다. net NS a.gtld-servers.net. blog.cloudneta.net이라는 도메인 주소로 질의하면 .net의 TLD 네임 서버 주소인 a.gtld-servers.net. 이라는 도메인 주소로 응답한다.

CNAME 레코드 유형

도메인 이름의 별칭을 지정하는 DNS 레코드 유형으로, 다른 도메인 이름을 정의한다. 다음 형태로 표현한다. www.cloudneta.net CNAME cloudneta.net www.cloudneta.net이라는 도메인 주소로 질의하면 cloudneta.net의 도메인 주소로 응답한다.

이외에도 다양한 DNS 레코드 유형이 있으며, 이런 DNS 레코드 유형은 DNS 서버에서 다양하게 정의하고 동작한다.

Amazon Route 53 서비스

Amazon Route 53 서비스는 AWS에서 제공하는 관리형 DNS 서비스이다.

Amazon Route 53의 주요 기능

Amazon Route 53은 다음 그림과 같은 형태의 아이콘으로 표현한다. Amazon Route 53은 주로 도메인 이름 등록과 호스팅 영역 생성, 레코드 작성 같은 기능을 제공한다.

도메인 이름 등록

도메인 이름을 사용하려면 도메인 이름을 등록하는 절차가 필요하다. 도메인을 등록하려면 전 세계에 위치한 네임 서버에 도메인 이름을 사용한다고 알려야 하는데, 이 작업은 개인이 아닌 등록대행소에서 관장한다. 즉, 사용자가 도메인 등록대행소에 도메인 이름 등록을 요청하면 도메인 등록 작업을 대행하는 것이다. 도메인 등록대행소로 국내외에 다양한 웹 사이트가 존재하는데 Amazon Route 53도 도메인 등록대행소 역할을 수행한다.

도메인 이름을 등록하는 작업을 살펴보기 전에 도메인 영역별 네임 서버를 관리하고 등록을 관장하는 단체들을 알아보자. 가장 상위에 ICANN이라는 비영리 단체가 루트 네임 서버를 관리하고 TLD 네임 서버를 등록하는 역할을 수행한다. 다음으로 '등록소'라고 하는 기관이나 기업들이 TLD 네임 서버를 관리하고 권한 있는 네임 서버를 등록하는 역할을 수행한다.

이런 구성에서 Amazon Route 53의 도메인 등록 대행소는 도메인 이름의 TLD에 해당하는 등록소로 도메인 등록 작업을 수행한다. 그래야 앞서 설명한 DNS 통신 흐름에 따라 최종적인 서비스가 가능하다.

호스팅 영역 생성

Amazon Route 53으로 호스팅 영역을 생성하여 네임 서버를 관리할 수 있다. 이렇게 호스팅 영역을 생성해야 Amazon Route 53이 등록된 도메인 이름에 대한 권한 있는 네임 서버이자 SLD 네임 서버의 역할을 수행할 수 있다. 호스팅 영역의 네임 서버들은 고가용성을 위해 다수의 서버로 구성하는데, 마치 네임 서버들의 Zone을 구성하는 개념이다.

레코드 작성

Amazon Route 53은 DNS 레코드를 정의하여 도메인에 대한 요청 처리 방법을 정의할 수 있는데, 이런 DNS 레코드는 다양한 형태의 라우팅 정책을 연결하여 도메인 요청에 대한 응답 방식을 정의할 수 있다.

Amazon Route 53의 라우팅 정책

단순 라우팅 정책

단순 라우팅 정책은 도메인에 대해 특정 대상을 지정하는 방식으로 여러 대상이 있으면 랜덤한 대상을 선택하고 응답한다. 예를 들어 ongja.com이라는 도메인의 A 레코드가 10.1.1.1과 10.1.1.2로, 단순 라우팅 정책으로 레코드를 구성하면 DNS 요청에 대해 둘 중 하나의 IP 주소로 랜덤하게 응답한다.

가중치 기반 라우팅 정책

단순 라우팅 정책이 랜덤하게 대상을 지정했다면 가중치 기반 라우팅 정책은 대상의 가중치를 지정하여 비중에 따라 대상을 선택하고 응답한다. 참고로 가중치는 0~255 범위에서 설정하는데, 대상별 가중치 값을 합산한 전체 가중치를 대상별 가중치로 나누어 비중을 부여한다. 예를 들어 ongja.com이라는 도메인의 A 레코드가 10.1.1.1과 10.1.1.2로, 가중치 기반 라우팅 정책으로 레코드를 구성할 때 10.1.1.1의 가중치가 90이고 10.1.1.2의 가중치가 10이라고 하자. 그러면 DNS 요청에 대해 10.1.1.1로 응답하는 비중은 90/100이고 10.1.1.2로 응답하는 비중은 10/100이 된다.

지연 시간 기반 라우팅 정책

지연 시간 기반 라우팅 정책은 다수의 리전에 대상 자원이 있으면 사용자와 인접한 리전을 기준으로 대상 자원의 리전까지 지연 시간을 파악해서 낮은 지연 시간의 대상을 선택하고 응답한다. 예를 들어 ongja.com이라는 도메인의 A 레코드가 10.1.1.1과 10.1.1.2로, 지연 시간 기반 라우팅 정책이라고 하자. 이때 10.1.1.1은 도쿄 리전에 위치하고 10.1.1.2는 런던 리전에 위치한다고 가정하면, 사용자 위치상 인접한 리전과 대상 자원의 리전까지 지연 시간을 파악한다. 이때 도쿄 리전은 50ms의 지연 시간을 갖고 런던 리전은 230ms의 지연 시간을 갖는다면 DNS 요청에 대해 도쿄 리전에 속한 대상으로 응답한다.

장애 조치 라우팅 정책

장애 조치 라우팅 정책은 다수의 대상 자원에 대해 액티브와 패시브로 분류하고 대상 상태를 주기적으로 검사하여 액티브 대상을 선택하고 응답한다. 액티브 대상이 통신 불가능할 때는 패시브 대상을 액티브로 승격하여 대상 경로로 라우팅한다.

그 밖에 사용자 PC가 지정하는 DNS 서버의 지리적으로 인접한 리전에 위치한 대상으로 경로를 선택하는 지리 위치 라우팅 정책, 지리 위치 라우팅과 형태가 동일하지만 영향도를 조정하는 바이어스(bias)라는 값을 사용하여 제어하는 지리 근접 라우팅 정책이 있다. 또한 DNS 요청에 대해 다수의 값을 반환할 수 있는 다중 값 응답 라우팅 정책도 있다.

데이터베이스와 DBMS

데이터와 데이터베이스

데이터(data)는 어떤 이론을 세우는 데 기초가 되는 자료로, 문자와 숫자, 그림, 영상 등의 형태로 된 단위이다. 데이터는 원시적인 자료에 불가할 뿐 특정한 의미와 가치는 없다. 이런 데이터를 특정 목적에 따라 가공하고 이론을 세워 의미와 가치를 부여한 결과를 정보라고 한다. 데이터베이스는 데이터를 하나에 모아 두는 것을 의미한다. 데이터 베이스는 간단히 데이터를 모아 두는 집합이라고 정의할 수 있다. 또한 데이터 베이스를 관리하는 시스템을 DBMS(DataBase Management System)라고 하며, DBMS는 데이터에 대해 사용자의 논리적 명령을 해석하고 필요한 데이터를 찾아 주는 시스템이라고 정의할 수 있다.

데이터베이스 모델 유형

데이터베이스는 구조, 운영, 저장 방식에 따라 크게 계층형(hierarchical), 네트워크형, 관계형(relational), 객체 지향형(object-oriented) 모델 유형으로 구분할 수 있다.

계층형 데이터베이스 모델

계층형 데이터베이스 모델은 트리(tree) 구조를 기반으로 하며, 데이터는 1:N으로 상하 종속 관계 구조로 되어 있다. 데이터에 빠르게 접근이 가능하지만, 구조 변경에 대한 유연성이 부족하다는 단점이 있다.

네트워크형 데이터베이스 모델

네트워크형 데이터베이스 모델은 계층형 데이터베이스의 정형화된 구조를 해결하기 위해 1:N뿐 아니라 1:1, N:N 형태의 구조를 가질 수 있다. 하위 개체는 다수의 상위 개체를 가질 수 있어 형태가 좀 더 자유롭다. 다만 다양한 개체 간 연결에 따라 복잡성은 높아지기 때문에 데이터베이스 전반의 구조를 이해하는 데 어려움이 따를 수 있다.

관계형 데이터베이스 모델

관계형 데이터베이스 모델은 데이터의 논리적 관계를 초점으로 특정 개체 정보를 이용하여 열(column)과 행(row)으로 된 테이블(table)이라는 최소 단위로 구성된다. 앞서 계층형과 네트워크형 데이터베이스 모델은 데이터가 변화하면 상관관계에 따라 모든 데이터를 변경해야 하지만, 관계형 데이터베이스 모델은 데이터가 변화하면 쉽게 적용할 수 있다는 장점이 있다. 하지만 시스템 자원을 많이 차지해서 상대적으로 느리다는 단점이 있다. 물론 하드웨어가 발전하면서 느린 동작은 점점 해소되고 있는 편이다. 관계형 DBMS는 현재 가장 많이 사용하는 데이터베이스 모델이며, SQL(Structured Query Language)이라는 프로그래밍 언어를 사용하여 손쉽게 데이터베이스를 읽고 쓰고 해석한다.

객체 지향형 데이터베이스 모델

객체 지향형 데이터베이스 모델은 모든 데이터를 테이블 형태로 구성하는 관계형 데이터베이스 모델과 다르게 객체(object)라는 형태의 최소 단위로 표현한다. 객체 집합을 정의하고 연결 구조를 확립하여 복잡한 객체 구조도 즉각적으로 표현할 수 있으며, 사용자 정의 데이터, 멀티미디어 등 비정형 데이터도 지원한다. 하지만 보편적으로 사용하는 관계형 데이터베이스의 호환성 문제와 복잡성에 따른 문제도 있다. 현재 객체 지향형 데이터베이스 모델은 특수한 전문 분야가 아니면 잘 쓰지 않는다.

관계형 DBMS의 SQL 언어

SQL 데이터 정의

DBMS와 연계되는 다양한 응용 프로그램에서 요구하는 데이터의 형식과 구조를 정의하는 기능으로, 테이블이나 관계의 구조를 정의하는 목적에 따라 CREATE, ALTER, DROP 등의 명령어가 있다.

• CREATE: 테이블을 구성하고 속성에 대한 제약을 정의하는 명령어
• ALTER: 생성된 테이블 속성을 정의하고 변경하는 명령어
• DROP: 생성된 테이블을 삭제하는 명령어

SQL 데이터 조작

데이터 검색, 삽입, 삭제 등을 처리하는 인터페이스를 제공하는 기능으로 SELECT, INSERT, UPDATE, DELETE 등의 명령어가 있다.

• SELECT: 테이블에 있는 정보를 가져오는 명령어
• INSERT: 테이블에 새로운 데이터를 삽입하는 명령어
• UPDATE: 테이블에 있는 데이터를 수정하는 명령어
• DELETE: 테이블에 있는 기존 데이터를 삭제하는 명령어

SQL 데이터 제어

데이터 무결성 유지와 접근 권한 및 다수의 사용자 데이터베이스에 정확하게 접근하는 기능으로 GRANT, DENY, REVOKE 등 명령어가 있다.

• GRANT: 테이블에 대한 권한을 허용하는 명령어
• DENY: 테이블에 대한 권한을 차단하는 명령어
• REVOKE: 테이블에 대한 권한을 회수하는 명령어

DBMS 종류

다양한 회사에서 만든 DBMS 제품들이 있는데, 대표적으로 Oracle, MySQL, MS-SQL, PostgreSQL 등이 있다. 인기도 확인: https://db-engines.com/en/ranking

AWS 데이터베이스 서비스

AWS 에서는 사용자 요구 사항에 따라 관계형 데이터베이스 서비스, 키-값 데이터베이스, 인-메모리 데이터베이스 등 다양한 데이터베이스 서비스를 제공한다.

Amazon RDS

Amazon RDS(Relational Database Service)는 클라우드 환경에서 관계형 데이터베이스를 간편하게 설정하고 운영할 수 있는 서비스이다. 원하는 성능 요구에 따라 다양한 데이터베이스 인스턴스 유형을 선택할 수 있다. Amazon Aurora, PostgreSQL, MariaDB, Oracle Database, SQL Server 등 관계형 데이터베이스 엔진을 선택할 수 있다.

Amazon RDS는 관계형 데이터베이스 모델 유형으로, 테이블 구조에 행과 열로 구성된다. 또한 Amazon RDS는 관계형 데이터베이스 엔진을 사용하기 때문에 SQL 언어 기반으로 데이터베이스를 손쉽게 제어할 수 있다.

Amazon RDS는 사용 편의성이 높고, 모니터링 및 지표와 이벤트 알람을 이용하여 높은 관리 효율성을 보장하며, 비용도 상대적으로 매우 저렴하다. 또한 간편한 복제 기능을 이용하여 워크로드의 가용성과 확장성을 확보할 수 있다.

Amazon RDS의 데이터 복제

Multi-AZ 복제 방식

Multi-AZ 복제 방식은 기본적으로 액티브-스탠바이(active-standby) 형태로 동작한다. Primary DB가 액티브(활성) 상태이며, 보조의 Standby Replica가 스탠바이(대기) 상태이다. Primary DB에 문제가 발생하면 Standby Replica를 Primary DB로 승격하여 동적으로 유지한다. 이런 Multi-AZ 복제 방식은 데이터 정합성을 유지하는 것이 가장 중요하다. 데이터 정합성이란 데이터가 서로 일관되게 일치하는 것으로, 이를 위해 동기식 복제(synchronous replica)로 다른 가용 영역에 있는 데이터베이스와 데이터를 동기화한다. 여기에서 동기식 복제는 데이터에 변화가 일어나면 원본 데이터를 복제해서 전달하여 동기화하는 것을 의미한다.

Read Replica 복제 방식

Read Replica 복제 방식은 원본 데이터를 Primary DB에 두고, 읽기 전용의 복제 데이터를 Read-Replica 데이터베이스에 생성하여 유지한다. 읽기 전용 복제 데이터가 있는 Read Replica 데이터베이스는 확장이 가능하며, 데이터 읽기 처리 속도를 높일 수 있다. Amazon RDS는 최대 다섯 개의 Read Replica 데이터베이스를 복제할 수 있으며, 다른 리전까지 Read Replica 데이터베이스를 가질 수 있다.

Amazon Aurora

AWS 관계형 데이터베이스 서비스는 Amazon RDS를 이용하여 MySQL, PostgreSQL, Oracle 등 데이터베이스 엔진을 주로 사용하다 Amazon Aurora라는 AWS 자체의 클라우드 데이터베이스 엔진을 개발했다. Amazon Aurora는 엔터프라이즈 수준의 관계형 데이터베이스 엔진으로 안정적이고 고성능의 데이터베이스 처리가 가능하다. 또한 오픈 소스를 기반으로 다른 관계형 데이터베이스와 호환성이 우수하며, 비용 효율이 높다는 장점이 있다. 이런 Amazon Aurora 데이터베이스 엔진은 Amazon RDS에서 관리하며 프로비저닝, 패치, 백업, 복원, 장애 복구 등의 작업을 수행한다.

Amazon Aurora 복제 방식

Amazon Aurora 데이터베이스 엔진은 다른 관계형 데이터베이스 엔진보다 스토리지 내결함성이 우수하다. 예를 들어, MySQL 데이터베이스 엔진은 데이터베이스 인스턴스에 EBS 스토리지가 연결되어 서로 다른 가용 영역으로 동기식 복제가 된다. 반면 Amazon Aurora 데이터베이스 엔진은 공유 스토리지를 통해 최소 세 개의 가용 영역에서 두 개씩 총 여섯 개의 복제 데이터를 가지고 있어 더욱 안정적으로 서비스할 수 있다.

Amazon DynamoDB

Amazon DynamoDB는 비관계형 데이터베이스로, 키-값(key-value) 메소드를 사용하는 키-값 데이터베이스이다. 여기에서 비관계형 데이터베이스는 관계형 데이터베이스와 다르게 데이터가 서로 연결되지 않는 개별 형태로 저장하여 복잡하고 구조화되지 않은 데이터 유형에 적합한 데이터베이스이다. 앞서 관계형 데이터베이스가 SQL 언어를 사용했다면, Amazon DynamoDB는 비관계형 데이터베이스로 SQL 문을 사용하지 않는다. 이런 측면에서 NoSQL 데이터베이스라고도 한다.

Amazon DynamoDB의 데이터베이스 구조는 키와 값으로 된 비관계형 데이터베이스 유형이다. 키를 데이터의 고유한 식별자로 사용하고, 값은 유형의 제한이 없어 단순한 개체(entity)뿐 아니라 복잡한 집합체까지 무엇이든 가능한 비정형 데이터를 입력할 수 있다. 이런 키와 값을 쌍으로 집합해서 저장한다.

키-값 데이터베이스는 데이터베이스 구조가 단순하여 빠른 처리가 가능하다. 이런 특성에 따라 Amazon DynamoDB는 대규모 환경에서도 일관되게 10밀리초 미만의 처리 성능을 제공한다. 그리고 Amazon DynamoDB는 별도 서버를 구축하지 않고 운영되는 서버리스(serverless)로 동작하기 때문에 서버에 대한 프로비저닝, 패치, 소프트웨어 설치가 필요 없고 용량에 따라 테이블을 자동으로 확장 및 축소해서 관리 편의성이 높다.

Amazon ElastiCache

Amazon ElastiCache는 인-메모리 데이터베이스로, 데이터를 메모리에 젖아하는 형태로 동작한다. 데이터가 메모리상에 위치하여 데이터를 빠르게 처리할 수 있다는 장점이 있지만, 데이터양이 많다면 데이터 처리가 느려질 수 있기 때문에 대용량 데이터에는 적합하지 않고 주로 데이터를 빠르게 자주 접근해야 할 때 사용한다. 이런 Amazon ElastiCache는 Memcached 방식과 Redis 방식 두 가지로 구분된다.

Amazon ElastiCache for Memcached

Memcached는 보편적으로 사용하는 메모리 객체 캐싱 시스템으로, 인-메모리 데이터베이스 서비스이다. Amazon ElastiCache for Memcached는 Memcached와 호환하여 자주 접근할 데이터를 메모리에 놓고 빠르게 처리할 수 있다.

Amazon ElastiCache for Redis

Redis는 데이터베이스, 캐시, 메시지 브로커 및 대기열 용도로 사용되는 인-메모리 데이터베이스 서비스이다. Amazon ElastiCache for Redis는 오픈 소스인 Redis 기반으로 구축되고 Redis API와 호환하여 개방형 Redis 데이터 형식으로 저장한다. 실시간 애플리케이션을 지원할 수 있도록 1밀리초 미만의 지연으로 빠른 데이터를 처리할 수 있다.

Level: 3

문제 설명

낚시앱에서 사용하는 FISH_INFO 테이블은 잡은 물고기들의 정보를 담고 있습니다. FISH_INFO 테이블의 구조는 다음과 같으며 ID, FISH_TYPE, LENGTH, TIME은 각각 잡은 물고기의 ID, 물고기의 종류(숫자), 잡은 물고기의 길이(cm), 물고기를 잡은 날짜를 나타냅니다.

단, 잡은 물고기의 길이가 10cm 이하일 경우에는 LENGTH 가 NULL 이며, LENGTH 에 NULL 만 있는 경우는 없습니다.

FISH_NAME_INFO 테이블은 물고기의 이름에 대한 정보를 담고 있습니다. FISH_NAME_INFO 테이블의 구조는 다음과 같으며, FISH_TYPE, FISH_NAME 은 각각 물고기의 종류(숫자), 물고기의 이름(문자) 입니다.

문제

물고기 종류 별로 가장 큰 물고기의 ID, 물고기 이름, 길이를 출력하는 SQL 문을 작성해주세요.

물고기의 ID 컬럼명은 ID, 이름 컬럼명은 FISH_NAME, 길이 컬럼명은 LENGTH로 해주세요. 결과는 물고기의 ID에 대해 오름차순 정렬해주세요. 단, 물고기 종류별 가장 큰 물고기는 1마리만 있으며 10cm 이하의 물고기가 가장 큰 경우는 없습니다.

SELECT A.ID, B.FISH_NAME, A.LENGTH
FROM FISH_INFO A
JOIN FISH_NAME_INFO B ON A.FISH_TYPE = B.FISH_TYPE
WHERE A.LENGTH = (
  SELECT MAX(LENGTH)
  FROM FISH_INFO
  WHERE FISH_TYPE = A.FISH_TYPE
)

HAVING 또는 서브쿼리를 써야한다.

FISH_TYPE별로 가장 큰 LENGTH를 서브쿼리로 구해서 해당 LENGTH와 같은 값을 가진 행만 필터링한다.

Level: 4

문제 설명

대장균들은 일정 주기로 분화하며, 분화를 시작한 개체를 부모 개체, 분화가 되어 나온 개체를 자식 개체라고 합니다. 다음은 실험실에서 배양한 대장균들의 정보를 담은 ECOLI_DATA 테이블입니다. ECOLI_DATA 테이블의 구조는 다음과 같으며, ID, PARENT_ID, SIZE_OF_COLONY, DIFFERENTIATION_DATE, GENOTYPE 은 각각 대장균 개체의 ID, 부모 개체의 ID, 개체의 크기, 분화되어 나온 날짜, 개체의 형질을 나타냅니다.

최초의 대장균 개체의 PARENT_ID 는 NULL 값입니다.

문제

3세대의 대장균의 ID(ID) 를 출력하는 SQL 문을 작성해주세요. 이때 결과는 대장균의 ID 에 대해 오름차순 정렬해주세요.

예시

예를 들어 ECOLI_DATA 테이블이 다음과 같다면

PARENT ID 가 NULL 인 ID 1, ID 2가 1 세대이며 ID 1에서 분화된 ID 3, ID 2에서 분화된 ID 4, ID 5 가 2 세대입니다. ID 4 에서 분화된 ID 6, ID 3에서 분화된 ID 7 이 3 세대이며 ID 6에서 분화된 ID 8은 4 세대입니다.

따라서 결과를 ID 에 대해 오름차순 정렬하면 다음과 같아야 합니다.

SELECT A.ID
FROM ECOLI_DATA A, ECOLI_DATA B, ECOLI_DATA C
WHERE B.ID = A.PARENT_ID && (B.PARENT_ID) = C.ID && C.PARENT_ID IS NULL
ORDER BY ID ASC;

이게 레벨 4가 맞나..? 싶을 정도로 쉽다. 테이블을 나누는게 어색하다면 낯설 수 있지만, 천천히 조건만 잘 읽고 대응하면 쉽게 풀 수 있다. A.ID의 PARENT_ID를 가지는 B.ID를 고려한다. B.ID의 PARENT_ID가 C.ID 값인 해당 C.ID의 PARENT_ID가 NULL값이면, A.ID값을 출력해준다.

Level: 2

문제 설명

SUBWAY_DISTANCE 테이블은 서울지하철 2호선의 역 간 거리 정보를 담은 테이블입니다. SUBWAY_DISTANCE 테이블의 구조는 다음과 같으며 LINE, NO, ROUTE, STATION_NAME, D_BETWEEN_DIST, D_CUMULATIVE는 각각 호선, 순번, 노선, 역 이름, 역 사이 거리, 노선별 누계 거리를 의미합니다.

문제

SUBWAY_DISTANCE 테이블에서 노선별로 노선, 총 누계 거리, 평균 역 사이 거리를 노선별로 조회하는 SQL문을 작성해주세요.

총 누계거리는 테이블 내 존재하는 역들의 역 사이 거리의 총 합을 뜻합니다. 총 누계 거리와 평균 역 사이 거리의 컬럼명은 각각 TOTAL_DISTANCE, AVERAGE_DISTANCE로 해주시고, 총 누계거리는 소수 둘째자리에서, 평균 역 사이 거리는 소수 셋째 자리에서 반올림 한 뒤 단위(km)를 함께 출력해주세요. 결과는 총 누계 거리를 기준으로 내림차순 정렬해주세요.

예시

SELECT 
  ROUTE,
  CONCAT(ROUND(SUM(D_BETWEEN_DIST), 1), 'km') AS TOTAL_DISTANCE,
  CONCAT(ROUND(AVG(D_BETWEEN_DIST), 2), 'km') AS AVERAGE_DISTANCE
FROM 
  SUBWAY_DISTANCE
GROUP BY 
  ROUTE
ORDER BY 
  SUM(D_BETWEEN_DIST) DESC;

MySQL은 'km'같은 문자열을 붙일때 CONCAT()을 사용해주어야 한다. 반올림 같은 조건은 ROUND로 잘 충족시켜줘야 한다. 그 이외에는 아주 쉬운 문제이다.

스토리지 개요

스토리지(Storage)란 데이터를 보관하는 장소로, 우리가 사용하는 모든 저장 장치를 스토리지라고 할 수 있다. 데이터 보관 방식과 데이터 사용 용도에 따라 여러 형태가 있다. 예를 들어 이동성 및 휴대성을 고려해서 간단한 데이터를 보관할 때 사용하는 USB(Universal Serial Bus), 대용량의 데이터를 보관하거나 백업할 때 사용하는 외장하드(SSD, HDD)가 있다. IT가 발전하면서 스토리지도 변화했으며, 클라우드 환경에서 사용되는 스토리지 역시 그 목적에 따라 다양하게 변화했다.

스토리지 서비스 및 주요 기능

AWS에서 제공하는 스토리지 서비스 종류에는 블록(block) 스토리지, 파일(file) 스토리지, 객체(object) 스토리지가 있는데, 각 목적에 따라 사용하는 것이 좋다.

블록 스토리지

블록 스토리지는 단일 스토리지 볼륨을 '블록'이라는 개별 단위로 분할해서 저장한다. 각 블록은 저장된 위치에 고유한 주소가 있기 때문에 서버에서 파일을 요청하면 블록들을 재구성하여 하나의 데이터로 서버에 전달한다. 클라우드 환경에서 블록 스토리지의 각 블록은 가상 머신 인스턴스에 위치하며, 마치 일반 컴퓨터에 하드디스크를 추가하여 C 드라이브, D 드라이브처럼 논리적으로 구분해서 사용하는 것과 같다. 일반적으로 블록 스토리지는 SAN(Storage Area Network) 또는 가상 머신의 디스크로 사용된다.

파일 스토리지

파일 스토리지는 파일 수준 또는 파일 기반 스토리지라고 하며, 디렉터리 구조로 파일을 저장한다. 각 파일은 폴더에 종속되고 폴더 역시 다른 폴더에 종속되어 계층 구조를 이룬다. 따라서 파일을 찾으려면 어느 위치에 있는지 알아야 한다. 파일 스토리지는 개인용 컴퓨터와 서버에서 일상적인 작업을 공유하여 사용할 수 있지만, 파일이 늘어나면 분류하거나 정리(file system indexing)하는 데 시간이 점점 더 소요된다는 단점이 있다. 일반적으로 파일 스토리지는 NAS(Network Attached Storage)에 사용된다.

객체 스토리지

객체 스토리지는 각 데이터 조각을 가져와서 객체로 지정하고, 개별 단위로 저장한다. 파일 스토리지와 다르게 모든 객체는 중첩된 계층 구조 없이 단일한 평면적인 주소 공간에 저장된다. 이 평면 주소 공간에는 데이터 및 관련 메타데이터(metadata)로 구성된 객체에 고유 식별자가 있다. OS나 파일 시스템에 의존하지 않으면서 데이터를 저장하고 객체에 쉽게 접근할 수 있다. 객체 스토리지 시스템에서는 객체의 키(이름)만 알고 있으면 쉽고 빠르게 대상을 검색할 수 있다. 객체 스토리지 접근에는 HTTP 프로토콜 기반의 REST(Representational State Transfer) API(Application Programming Interface)를 사용한다. 객체 스토리지는 저장할 수 있는 데이터의 수와 파일 크기에 제한이 없으며 데이터 저장의 총용량 역시 무제한에 가깝다고 할 수 있다.

스토리지 선택 기준

클라우드 스토리지는 어디에서나 접근할 수 있는 편의성, 대량의 데이터를 수용할 수 있는 확장성을 갖추고 있다. 따라서 스토리지를 도입할 때는 클라우드 스토리지의 종류별 특징을 충분히 이해하고 목적과 상황에 맞게 선택해야 한다.

[스토리지를 선택할 때 고려 사항]

• 내구성: 데이터 손실 가능성
• 가용성: 서비스 지속 시간
• 보안: 저장 및 전송 중 데이터 보안
• 비용: 스토리지 단위 가격
• 확장성: 스토리지 크기 및 사용자 수 변경
• 성능: 스토리지 크기 및 사용자 수 변경
• 통합: 다른 서비스와 호환성

Amazon EBS

EBS란

Amazon EBS(Elastic Block Store)는 EC2 인스턴스에 사용할 수 있는 블록 스토리지 볼륨을 제공하는 서비스이다. 블록 스토리지 특성을 이용한 저장 방식이므로 데이터를 일정한 크기의 블록으로 나누어 분산 저장하는데, 볼륨 위에 파일 시스템을 생성하거나 하드디스크 드라이브 같은 블록 디바이스를 사용하는 것처럼 볼륨을 쓸 수 있다. 쉽게 운영 체제에 외장 하드디스크를 연결해서 데이터를 저장한다고 생각하면 됩니다. 또한 인스턴스에 연결된 EBS 볼륨의 구성을 동적으로 변경할 수 있다. 이처럼 EBS는 데이터베이스처럼 데이터 출입이 많은 서비스에 적합하다.

EBS 스토리지는 AWS 관리 콘솔에서 필요한 용량과 성능에 맞추어 볼륨을 생성한 후 EC2 인스턴스에 연결하고 파일 시스템을 포맷한 후 사용한다. 이때 파일 시스템 포맷은 운영 체제에 따라 다르게 사용된다. 리눅스는 xfs 또는 ext4 유형이 주로 사용되며, 윈도우는 NTFS 포맷이 주로 사용된다. 포맷이 완료되면 해당 볼륨을 서버에서 마운트한 후 데이터를 해당 디렉터리에 저장해서 사용한다.

EBS는 고속 네트워크로 연결되어 있으며, 데이터 수명 시간이 독립되어 있다. 독립된 데이터 수명 시간이란 '서로 연결된 인스턴스와 볼륨을 사용하나 해당 인스턴스를 삭제해도 볼륨은 계속 사용할 수 있고 그 볼륨에 저장된 데이터도 다른 인스턴스와 연결하여 이어서 사용할 수 있다'는 의미이다. 결론적으로 인스턴스와 EBS 볼륨은 서로 종속 관게에 있지 않으며, 인스턴스는 다수의 볼륨을 연결하여 사용할 수 있다. 하지만 하나의 EBS 볼륨은 한 번에 하나의 인스턴스에만 연결할 수 있고, 해당 인스턴스에서 지원하는 형태의 시스템으로 포맷해야만 사용할 수 있다.

EBS 특징

• 데이터 가용성: 단일 하드웨어 구성 요소의 장애 때문에 데이터가 손실되지 않도록 해당 가용 영역 내에서 자동으로 데이터를 복제한다.
• 데이터 지속성: EBS 볼륨은 인스턴스 수명과 관계없이 유지되는 비관계형 인스턴스 스토리지이다.
• 데이터 안정성: Amazon EBS 암호화(encryption) 기능으로 암호화된 EBS 볼륨을 생성할 수 있으며, 암호화 표준 알고리즘(AES-256)을 사용한다.
• 데이터 백업: 모든 EBS 볼륨의 스냅샷(백업)을 생성하고, 다중 가용 영역에 중복 저장이 가능한 Amazon S3(Simple Storage Service)에 볼륨 내 데이터 사본을 백업할 수 있다.
• 데이터 확장성: 서비스를 중단할 필요 없이 볼륨 유형, 볼륨 크기, IOPS(Input/Output operations Per Second) 용량을 수정할 수 있다.

EBS 볼륨 유형

EBS 볼륨에는 크게 SSD와 HDD 유형이 있다. SSD는 메모리형 디스크를 사용하며, HDD는 플래터(platter) 디스크를 사용한다. 데이터를 빠르게 읽고 처리하는 능력이 좋은 SSD는 주로 서버의 운영 체제가 설치되는 OS 영역이나 일반 데이터베이스 보관용 스토리지 유형으로 사용된다. HDD는 속도와 상관없이 데이터 저장 용량이 많아 필요할 때 사용하므로 데이터 분석에 주로 활용된다.

EBS 스냅샷

EBS 스토리지의 대표적인 특징인 EBS 스냅샷 기능은 말 그대로 특정 시점에 포인트를 찍어서 그 시점으로 되돌아갈 수 있는 지점을 만드는 기능이다. 증분식 백업 방식을 이용하여 마지막 스냅샷 이후 변경되는 데이터 블록만 기록하고 복제하므로 저장 비용과 시간도 효과적으로 절감할 수 있다.

또한 매번 원본과 크기가 같지 않아도 변경된 부분만 증분되어 백업되기 때문에 특정 데이터를 삭제해도 어느 한 부분의 스냅샷만 가지고 있다면 복구할 수 있다. 스냅샷은 기본적으로 Amazon S3라는 스토리지 공간에 저장되어 여러 가용 영역에 자동으로 복제된다.

EFS란

Amazon EFS(Elastic File System)는 클라우드 환경과 온프레미스 환경에서 사용할 수 있는 완전 관리형 네트워크 파일 시스템이다. 완전 관리형이란 클라우드에서 하드웨어 프로비저닝 유지 관리, 소프트웨어 구성, 모니터링, 복잡한 성능 조절 등 모든 것을 관리하기 때문에 사용자 입장에서는 별다른 관리가 필요 없다는 의미이다. 처음 파일 시스템을 생성한 후 서버에 연결하면 사용한 만큼 자동으로 스토리지 크기가 확장되고, 사용한 만큼만 비용을 지불하면 되기 때문에 사실상 용량 제한 없이 사용할 수 있다.

EFS 특징

EFS는 고성능 네트워크 파일 시스템으로, 여러 대의 컴퓨터가 네트워크상의 동일한 데이터에 접근해야 할 때 사용한다. NFS 표준 프로토콜 기반의 연결을 지원하고 있어 기존 다양한 애플리케이션과 유연하게 통합할 수 있고, 여러 컴퓨팅 인스턴스에서 동시에 사용할 수 있다. 또한 기존 NAS처럼 사용자 홈 디렉터리를 공유하여 애플리케이션을 개발하고, 테스트 환경의 다양한 웹 서비스와 콘텐츠 관리, 분석이나 미디어 업무에도 활용할 수 있다.

EFS 볼륨은 IOPS가 높고 용량이 매우 크기 때문에 처리량이 많고 대기 시간이 짧다. 또한 파일 시스템의 사용 증가에 따라 자동으로 용량 및 성능이 조정되는 탄력성을 제공하여 네트워크 스토리지의 용량 및 성능 부족을 걱정할 필요가 없다.

EFS는 EBS처럼 가용 영역 단위의 서비스가 아니라 가용 영역 전반에 걸쳐 사용할 수 있는 스토리지이므로, 가용 영역 장애를 고려한 디자인이 가능해서 전통적인 NAS보다 뛰어난 가용성을 가진다.

Amazon S3

S3 소개

Amazon S3는 AWS 서비스 중에서 EC2 서비스와 더불어 가장 오래되고, 기본이 되는 객체 스토리지 서비스이다. S3에 저장되는 데이터를 객체라고 하며, 이 객체 저장소를 버킷(bucket)이라고 한다. 그리고 객체에 대한 입출력은 HTTP 프로토콜로 하며, REST API를 이용하여 명령이 전달된다.

이 스토리지의 가장 큰 특징은 높은 내구성인데, 99.999%의 내구성으로 디자인되어 있어 데이터 손실을 최소화하도록 규정되어 있다. 또한 데이터 저장 공간이 거의 무제한에 가까워 특별한 용량 제한 없이 데이터를 저장할 수 있다. 필요한 경우 다양한 스토리지 계층으로 데이터를 분류하여 데이터 저장 비용을 절감할 수도 있다.

S3의 객체는 기본적으로 웹 접속이 가능하기 때문에 간단한 정적 웹 콘텐츠를 S3에 올려 웹 서버의 도움 없이 바로 웹 서비스가 가능하다. 그리고 S3는 보안 규정 준수 및 감시 기능을 제공하고 있어 데이터가 안전하게 저장되고 인증된 사용자만 접근할 수 있도록 구성한다. 필요한 경우 접근 권한 정책을 이용하여 해당 객체의 접근을 제어할 수 있다.

S3 구성 요소

• 버킷: 데이터 스토리지를 위한 S3의 기본 컨테이너이다. 객체는 반드시 버킷에 저장되어야 하며, 하나의 리전에서 생성된 후에는 버킷 이름과 리전을 변경할 수 없다.
• 객체: S3에 저장되는 기본 매체로, 객체 데이터와 객체 메타데이터로 구성되어 있다. 메타데이터는 객체를 설명하는 이름-값에 대한 하나의 쌍으로 존재한다. 객체를 저장할 때 사용자 정의 메타데이터를 지정할 수 있으며, 객체는 키(이름) 및 버전 ID를 이용하여 버킷내에서 고유하게 식별된다.
• 키: 버킷 내에서 객체의 고유한 식별자이다. 버킷 내 모든 객체는 고유한 하나의 키를 갖게 되며, S3는 '버킷 + 키 + 버전'과 객체 사이의 기본 데이터 맵으로 생각할 수 있다.
• S3 데이터 일관성: S3 버킷에 있는 객체에 대해 여러 서버로 데이터를 복제하여 고가용성 및 내구성을 구현하고 데이터 일관성 모델을 제공한다.

S3 특징

Amazon S3는 객체에 대해 빠르고 내구성과 가용성이 높은 키 기반의 접근성을 제공하여 데이터의 저장 및 검색에 특화된 객체 스토리지이다.

S3는 하나의 리전 내 최소 세 개 이상의 물리적으로 분리된 가용 영역에 데이터를 복제해서 저장하므로 높은 내구성과 고가용성을 제공하며, 서버의 OS 도움 없이 객체별 접근이 가능하므로 데이터 저장 및 활용에 용이하다.

또한 Amazon S3는 동일 버킷 내 여러 개의 객체 변형을 보유하여 데이터 복구에 특화된 객체 스토리지이다. S3에 버전 관리 기능을 이용하면 버킷에 저장된 모든 버전의 객체를 보존하거나 검색 및 복원할 수 있으며, 의도하지 않은 사용자 작업 및 애플리케이션 장애에서 쉽게 복구될 수 있다.

S3 스토리지 클래스

S3는 여러 사용 사례에 맞게 설계된 다양한 스토리지 클래스를 제공한다. 여기에는 자주 접근하는 데이터를 저장하는 S3 standard와 알 수 없거나 변화하는 접근 패턴이 있는 데이터를 저장하는 S3 intelligent-tiering, 데이터 수명은 길지만 자주 접근하지 않는 데이터를 저장하는 S3 standard-IA 및 S3 one zone-IA, 데이터 수명이 제한되어 추후 삭제 예정인 데이터 및 백업을 위한 S3 glacier 등이 있다. 데이터 수명 주기에 따라 데이터를 관리할 수도 있다.

[AWS S3 스토리지 클래스의 종류 및 특징]

• standard: 가장 일반적인 스토리지 클래스이며, 데이터를 검색할 때 요금 및 최소 사용량에 제한 없이 사용한 만큼 비용을 지불하면 된다.

• intelligent-tiering: 객체 접근 정보가 고정되어 있지 않을 때 자동으로 빈번한 접근 그룹과 간헐적 접근 그룹에 나누어서 저장한다.

• infrequent access: 객체가 자주 사용되지는 않지만 조회가 필요할 때 사용되는 데이터를 저장하는 클래스이다. 두 개의 하위 클래스로 나뉜다.

  • standard-infrequent access: 최소 세 개 이상의 가용 영역에 데이터가 저장되기 때문에 내구성이 높은 클래스이다.
  • one zone-infrequent access: 이름처럼 하나의 가용 영역에만 데이터가 저장되기 때문에 상대적으로 내구성이 낮고, 데이터가 삭제되어도 다시 생산할 수 있는 데이터를 위한 클래스이다.

• S3 glacier: 데이터 아카이브와 장기간 백업을 고려하여 만든 스토리지 클래스이다. 아카이빙 데이터는 오랫동안 데이터가 저장되어 있는 것을 의미하며, 이런 아카이빙 데이터에 접근하려면 많은 시간이 소요될 수 있다. 또한 데이터를 다른 클래스로 옮기려면 기가바이트당 비용이 발생하므로 주로 보관이 목적일 때 사용한다.

• S3 glacier deep archive: 재사용이 거의 없는 데이터를 보관할 때 사용하는 클래스이다. 일정 기간이 지나면 삭제할 데이터를 주로 보관하며, 조회하는 데 수 시간에서 수일이 소요될 수 있다. 그 대신 데이터 보관 비용이 가장 저렴하므로 데이터 목적에 따라 매우 유용한 저장소가 될 수 있다.

S3 보안

S3 버킷 접근은 일반적으로 버킷을 생성할 때 사용한 버킷 이름을 포함하여 생성된 유일한 식별자를 기반으로 언제, 어디에서든 접근이 가능하다. 그런 점에서 보안은 가장 중요한 부분이다. 그렇기 때문에 AWS의 자격 증명 서비스인 IAM(Identity and Access Management)과 밀접하게 연관되어 있고, IAM으로 접속 사용자나 데이터 접근을 관리할 수 있다. 특정 S3 버킷 접근에 대해 허용과 거부가 발생한다면 IAM에서 접근 권한을 통제하기 때문에 일어나는 상황이라고 이해하면 된다.

IAM으로 사용자 및 정책별 접근 권한을 제어할 수 있지만, 접근 권한이 있는 사용자가 개별 객체에 접근할 수 있게 하는 S3만의 버킷 정책으로 S3 버킷 내 모든 객체에 대한 권한을 조정할 수도 있다.

또한 쿼리를 요청할 때 쿼리 문자열을 인증하여 사용자 인증 정보도 함께 보낼 수 있는데, 해당 객체에 접근할 때 이 인증 정보로 일시적 허용 여부 권한을 이용할 수 있다. 대표적인 예가 임시 권한을 부여해서 접근하는 presign 기능이다.

다만 S3 객체는 기본적으로 외부 사용자가 접근할 수 없도록 설정되어 있다. 객체 소유자와 루트 사용자만 해당 객체에 접근할 수 있으며, 외부에서 접근하려면 별도의 정책을 이용하여 직접 설정해야 한다.

Level:2

2025 프로그래머스 코드챌린지 1차 예선

문제 설명

당신은 비밀 조직의 보안 시스템을 뚫고 중요한 정보를 해독해야 합니다. 시스템은 1부터 n까지의 서로 다른 정수 5개가 오름차순으로 정렬된 비밀 코드를 가지고 있으며, 당신은 이 비밀 코드를 맞혀야 합니다.

당신은 비밀 코드를 알아내기 위해 암호 분석 도구를 사용하며, m번의 시도를 할 수 있습니다. 각 시도마다 서로 다른 5개의 정수를 입력하면, 시스템은 그 중 몇 개가 비밀 코드에 포함되어 있는지 알려줍니다.

• 만약 비밀 코드가 [3, 5, 7, 9, 10]이고, 입력한 정수가 [1, 2, 3, 4, 5]라면 비밀 코드에 포함된 정수는 3, 5 두 개이므로 시스템은 2를 응답합니다.

당신은 m번의 시도 후, 비밀 코드로 가능한 정수 조합의 개수를 알고 싶습니다.

비밀 코드에 사용된 정수의 범위가 1~10일 때, 아래와 같이 5번의 시도를 했다고 가정해 보겠습니다.

비밀 코드로 가능한 정수 조합은 아래와 같이 3개가 있습니다.

• [3, 4, 7, 9, 10]

  • 첫 번째 시도에서 비밀 코드에 포함된 정수가 3, 4로 2개 있습니다.
  • 두 번째 시도에서 비밀 코드에 포함된 정수가 7, 9, 10으로 3개 있습니다.
  • 세 번째 시도에서 비밀 코드에 포함된 정수가 3, 7, 9, 10으로 4개 있습니다.
  • 네 번째 시도에서 비밀 코드에 포함된 정수가 7, 9, 10으로 3개 있습니다.
  • 다섯 번째 시도에서 비밀 코드에 포함된 정수가 3, 4, 7로 3개 있습니다.

• [3, 5, 7, 8, 9]

  • 첫 번째 시도에서 비밀 코드에 포함된 정수가 3, 5로 2개 있습니다.
  • 두 번째 시도에서 비밀 코드에 포함된 정수가 7, 8, 9로 3개 있습니다.
  • 세 번째 시도에서 비밀 코드에 포함된 정수가 3, 7, 8, 9로 4개 있습니다.
  • 네 번째 시도에서 비밀 코드에 포함된 정수가 5, 7, 9로 3개 있습니다.
  • 다섯 번째 시도에서 비밀 코드에 포함된 정수가 3, 5, 7로 3개 있습니다.

• [3, 5, 7, 8, 10]

  • 첫 번째 시도에서 비밀 코드에 포함된 정수가 3, 5로 2개 있습니다.
  • 두 번째 시도에서 비밀 코드에 포함된 정수가 7, 8, 10으로 3개 있습니다.
  • 세 번째 시도에서 비밀 코드에 포함된 정수가 3, 7, 8, 10으로 4개 있습니다.
  • 네 번째 시도에서 비밀 코드에 포함된 정수가 5, 7, 10으로 3개 있습니다.
  • 다섯 번째 시도에서 비밀 코드에 포함된 정수가 3, 5, 7로 3개 있습니다.

정수 n, 입력한 정수를 담은 2차원 정수 배열 q와 시스템 응답을 담은 1차원 정수 배열 ans가 매개변수로 주어집니다. 이때, 비밀 코드로 가능한 정수 조합 개수를 return 하도록 solution 함수를 완성해 주세요.

제한사항

• 10 ≤ n ≤ 30
• 1 ≤ (q의 길이 = m) ≤ 10
  • q[i]의 길이 = 5
  • q[i]는 i+1번째 시도에서 입력한 5개의 서로 다른 정수를 담고 있으며, 오름차순으로 정렬되어 있습니다.
  • 1 ≤ q[i][j] ≤ n
• ans의 길이 = m
  • ans[i]는 i+1번째 시도에서 입력한 5개의 정수 중 비밀 코드에 포함된 정수의 개수를 나타냅니다.
  • 0 ≤ ans[i] ≤ 5
• 비밀 코드가 존재하지 않는(답이 0인) 경우는 주어지지 않습니다.

입출력 예

#include <string>
#include <vector>
#include <algorithm>
#include <bitset>
#include <numeric>

using namespace std;

int solution(int n, vector<vector<int>> q, vector<int> ans){
    int answer = 0;

    vector<bitset<31>> qbit;
    for (auto& v : q){
        bitset<31> b;
        for (int x : v){
            b.set(x);
        }
        qbit.push_back(b);
    }

    vector<int> nums(n);
    iota(nums.begin(), nums.end(), 1);

    vector<int> mask(n, 0);
    fill(mask.end() - 5, mask.end(), 1);

    do{
        bitset<31> cand;
        for (int i = 0; i < n; ++i){
            if (mask[i]){
                cand.set(nums[i]);
            }
        }

        bool valid = true;
        for (int i = 0; i < q.size(); ++i){
            int match = (cand & qbit[i]).count();
            if (match != ans[i]){
                valid = false;
                break;
            }
        }

        if (valid){
            answer++;
        }

    }while (next_permutation(mask.begin(), mask.end()));

    return answer;
}

아아.. 알고리즘 문제를 너무 오랫동안 놓고 있어서 그런지 안풀려서 검색하면서 풀었다. 이 코드는 bitset, next_permutation, iota, fill 등의 함수를 사용하여 풀었다.

qbit에 대한 설명

vector<bitset<31>> qbit; → 비어 있는 bitset들이 들어갈 예정이고, 각 bitset은 1부터 30까지의 정수를 표현할 수 있도록 31비트로 설정했다.

b의 구성

for문을 돌면서 b는 31개의 0으로 채워지고, 이중 for문을 돌면서 b에 q[i]의 원소들이 set된다. 여기서 set은 bitset의 .set() 메서드이고, C++ STL의 std::set이 아니다. 예를 들어 q[i] = {3, 5, 9, 13, 25} 라면, b.set(3), b.set(5) 등을 통해 해당 비트만 1이 된다.

nums는 iota로 1부터 n까지

iota는 연속된 숫자로 채워주는 함수이다. iota(nums.begin(), nums.end(), 1); → 1, 2, ..., n

mask는 끝 5개가 1

fill(mask.end() - 5, mask.end(), 1); → 조합 5개를 고르는 마스크 역할이다. mask의 끝 5개가 1로 채워진다. (나머지는 0)

cand는 mask에 따라 채워짐

mask[i] == 1 → nums[i]를 선택 → cand.set(nums[i]);

cand & qbit[i]의 의미

bitset & bitset → 공통으로 1인 비트들만 남기고 .count() → 1의 개수를 세어줌 → 즉, candidate와 q[i]가 몇 개 겹치는지 알려주는 역할

ans와 다르면 제외

이 조건을 m번의 시도 모두 통과한 조합만 정답으로 인정해서 answer++ 해준다.

네트워킹이란

네트워킹 정의

네트워킹은 '서로 연결한다'는 뜻으로, 서로 간에 의사소통을 하는 환경이다.

네트워킹 요소

국제표준화기구(ISO)에서 개발한 OSI 7계층 모델로, 네트워킹 통신 구조를 계층 일곱 개로 분류하는 방식이다.

IP 주소와 서브넷

IP 주소

IP(Internet Protocol) 주소는 인터넷상에서 IT 자원을 식별하는 고유한 주소이다. IP 버전에는 IPv4와 IPv6 두 가지가 있으며, 일반적으로 IPv4를 더 많이 사용한다.

퍼블릭 IP 주소와 프라이빗 IP 주소

퍼블릭 IP 주소는 실제 인터넷에서 사용하려고 인터넷 서비스 공급자(ISP)에서 제공하는 유일한 공인 IP 주소이다. 반면 프라이빗 IP 주소는 인터넷이 아닌 독립된 네트워크 내부에서만 사용하려고 네트워크 관리자가 제공하는 사설 IP 주소이다.

[프라이빗 IP 주소]

• 클래스 A: 10.0.0.0 ~ 10.255.255.255
• 클래스 B: 172.16.0.0 ~ 172.31.255.255
• 클래스 C: 192.168.0.0 ~ 192.168.255.255

고정 IP 주소와 유동 IP 주소

IP 주소는 할당하는 방식에 따라 고정 IP 주소와 유동 IP 주소로 분류된다. 고정 IP 주소는 네트워크 관리자가 수동으로 할당하는 방식이며, 유동 IP 주소는 특정 서버가 IP 주소 범위에 따라 동적으로 할당하는 방식이다.

유동 IP 주소는 DHCP(Dynamic Host Configuration Protocol) 프로토콜을 통해 주소를 제공하는 서버와 주소를 할당받는 클라이언트로 구성되며, IP 주소를 임대(lease)하는 형태를 취한다.

[DHCP 프로토콜 메세지]

• DHCP Discover: DHCP 클라이언트에서 DHCP 서버를 찾는 메시지
• DHCP Offer: DHCP 서버에서 할당할 IP 주소와 임대 시간을 알리는 메시지
• DHCP Request: DHCP 클라이언트에서 DHCP 서버로 할당받을 IP 주소를 요청하는 메시지
• DHCP Ack: DHCP 서버에서 최종적으로 할당할 IP 주소 승인을 알리는 메시지

서브넷과 서브넷 마스크

모든 네트워크는 하나의 네트워크로만 구성되어 있지 않다. 주체와 목적에 따라 부분 네트워크로 나뉘고, 서로 연결하여 거대한 네트워크 환경을 이루고 있다. 여기에서 서브넷(subnet)은 부분 네트워크를 의미하며, 다양한 서브넷이 연결되어 거대한 네트워크 환경을 이루고 있다고 이해하면된다. 서브넷을 구분하고 식별할 때 사용하는 것이 서브넷 마스크(subnet mask)이다.

라우팅과 라우터

TCP와 UDP

TCP 송수신 대상 간 연결을 맺고 데이터 전송 여부를 하나씩 확인하며 전송하는 연결형 프로토콜로, 신뢰성 있는 데이터 전송을 보장한다.

UDP TCP와 반대로 송수신 대상 간 연결 없이 전달하는 비연결형 프로토콜이다.

포트 번호 TCP와 UDP를 사용하는 응용서비스는 서로 구분할 수 있도록 포트 번호를 사용한다. 이런 포트 번호는 IANA(Internet Assigned Numbers Authority)라는 인터넷 할당 번호 관리 기관에서 정의한다.

• 잘 알려진 포트 번호(well-known port): 0~1023
• 등록된 포트 번호(registered port): 1024~49151
• 동적 포트(dynamic port): 49152~65535

AWS 네트워킹 소개

AWS 네트워킹 서비스는 AWS 글로벌 인프라에서 생성된 다양한 자원의 워크로드를 수행하는 네트워킹 서비스이다.

AWS 리전 네트워킹 디자인

리전은 전 세계 주요 도시의 데이터 센터를 군집화(clustering)하는 물리적인 위치를 의미한다. AWS 리전 내부에는 트랜짓 센터(transit center)와 가용 영역이 서로 연결되어 네트워크 환경을 이루고 있으며, 네트워킹 측면으로 어떤 대상과 연결되었는지에 따라 다음과 같이 분류할 수 있다.

Intra-AZ 연결

리전 내부에는 논리적인 데이터 센터의 집합인 가용 영역이 여럿 존재한다. 가용 영역에 존재하는 데이터 센터들은 고밀도 광섬유 케이블을 사용하여 100GE 또는 400GE(Gigabit Ethernet)로 상호 연결되어 네트워킹 환경을 구성한다. 이런 데이터 센터 간 연결을 Intra-AZ 연결(connection)이라고 한다.

Inter-AZ 연결

리전 내부에 위치하는 가용 영역은 실제 100km(서로 60마일 간격) 이내로 떨어져 있다. 이렇게 물리적으로 거리를 두는 이유는 정전이나 자연재해 같은 문제에 가용성을 유지하기 위함이다. 또한 AWS 클라우드 자원을 다수의 가용 영역에서 실행하도록 설계하여 내결함성을 강화할 수 있다. 지리적으로 떨어져 있는 가용 영역끼리 연결되어 네트워킹 환경을 구성하고 있으며, 이런 가용 영역 간 연결을 Inter-AZ 연결(connection)이라고 한다.

트랜짓 센터

리전에서 외부 인터넷 구간과 통신이 필요할 때는 트랜짓 센터를 통해 통신한다. 내부에 있는 가용 영역들은 외부 인터넷 통신을 위해 트랜짓 센터와 연결되어 네트워킹 환경을 구성하며, 이런 가용 영역 간 연결을 트랜짓 센터 연결(transit center connection)이라고 한다.

AWS 글로벌 네트워크와 엣지 POP

엣지 POP(edge Point Of Presence)는 AWS 글로벌 네트워크라는 전용망을 활용하여 안정적으로 고성능 서비스를 제공하는 센터이다. 엣지 POP을 통해 사용자에게 글로벌 서비스 콘텐츠를 빠르게 제공할 수 있다. 엣지 POP은 엣지 로케이션(edge location)과 리전별 엣지 캐시(regional edge cache)로 구성되며, 전 세계 300개 이상의 엣지 로케이션과 13개의 리전별 엣지 캐시가 서로 연결된 AWS 글로벌 네트워크를 구성하고 있다.

엣지 POP이 속해 있는 AWS 백본 네트워크는 AWS 글로벌 네트워크와 연결되어 있으며, 모든 리전(중국 리전 제외)은 백본 네트워크를 중심으로 서로 연결되어 있다.

AWS 네트워킹 서비스

AWS의 다양한 자원이 서로 원활하게 통신할 수 있도록 도와주는 것이 바로 AWS 네트워킹 서비스이다.

대표적인 AWS 네트워킹 서비스를 정리해보면 다음과 같다.

• VPC: 사용자 전용 가상의 프라이빗 클라우드 네트워크로, 네트워크 자원을 탄력적으로 활용하는 서비스를 제공한다.
• Transit Gateway: 중앙 허브 개념처럼 VPC와 온프레미스 네트워크를 연결하는 게이트웨이 역할의 서비스를 제공한다.
• Route 53: AWS에서 제공하는 관리형 DNS 서비스로 도메인 등록, 라우팅, 상태 확인 등 서비스를 제공한다.
• Global Accelerator: AWS 글로벌 네트워크를 통해 애플리케이션을 빠르고 안정적으로 사용할 수 있도록 가용성 및 성능을 보장하는 서비스를 제공한다.
• Direct Connect: 온프레미스 환경에서 AWS의 전용 네트워크 연결 서비스를 제공한다.
• Site-to-Site VPN: IPsec VPN 연결을 생성하여 암호화된 네트워크를 구성하는 서비스를 제공한다.

Amazon VPC

Amazon VPC 기본 구성 요소

리전과 VPC

Amazon VPC는 리전마다 독립적으로 구성되어 있다. 예를 들어 서울 리전에 VPC를 생성했다면 생성한 VPC는 서울 리전에만 있으며, 다른 리전에는 없다. 또한 리전 내에는 다수의 VPC를 생성할 수 있으며, 각 VPC는 서로 독립적으로 분리된다. 이런 측면에서 사용자는 어느 리전에 VPC를 생성할지 미리 계획해야 한다.

서브넷과 가용 영역

Amazon VPC라는 하나의 독립된 클라우드 네트워크에도 서브넷을 이용하여 분리된 네트워크로 구성할 수 있다. 서브넷은 VPC 내 별도로 나누어진 네트워크라고 생각하면 된다. 또한, 서브넷은 반드시 하나의 가용 영역에 종속적으로 위치한다.

서브넷은 VPC 네트워크 환경 구성에 따라 퍼블릭 서브넷과 프라이빗 서브넷으로 분리할 수 있다. 퍼블릭 서브넷은 인터넷 구간과 연결되어 있어 외부 인터넷 통신이 가능한 네트워크 영역이고, 프라이빗 서브넷은 인터넷 구간과 연결되지 않은 폐쇄적인 네트워크 영역이다.

IP CIDR

IP CIDR은 네트워크에 할당할 수 있는 IP 주소 범위를 표현하는 방법이다. Amazon VPC는 내부에 생성할 서브넷의 IP 주소 범위를 할당하기 위해 IP CIDR을 가지고 있으며, VPC 내 생성된 서브넷도 VPC의 IP CDIDR에서 분할된 IP CIDR을 가지고 있다. 즉, VPC라는 큰 네트워크의 IP CIDR에서 서브넷이라는 작은 네트워크의 IP CIDR이 분할되어 있다. 결론적으로, 서브넷에 생성되는 자원은 IP CIDR 범위 안에 있는 IP 주소를 할당받을 수 있다.

가상 라우터와 라우팅 테이블

Amazon VPC를 생성하면 기본적으로 네트워크 경로를 확인하여 트래픽을 전달하는 목적의 가상 라우터가 생성된다. 이렇게 생성된 가상 라우터는 기본 라우팅 테이블을 보유하고 있으며, 라우팅 테이블을 통해 네트워크 경로를 식별할 수 있다. 물론 기본 라우팅 테이블 외에 별도의 라우팅 테이블을 생성할 수 있고, 생성된 라우팅 테이블은 서브넷과 연결(attach)하여 서브넷마다 라우팅 테이블을 가질 수도 있다.

라우팅 테이블은 목적지 대상의 IP CIDR 블록과 타깃 대상으로 구성되어 있다. 참고로 타깃 대상에서 로컬은 VPC 내부 간 통신을 의미하며, 특수한 목적을 수행하는 인터넷 게이트웨이나 NAT 게이트웨이 등을 타깃 대상으로 지정할 수 있다.

보안 그룹과 네트워크 ACL

Amazon VPC는 보안 그룹(security group)과 네트워크 ACL(Access Control List) 같은 가상의 방화벽(firewall) 기능을 제공하여 서브넷과 생성된 자원에 대한 트래픽을 보호한다. 트래픽 접근을 통제하는 것이 주된 목적이며 IP CIDR 블록, 프로토콜, 포트 번호 등을 정의하여 허용(allow)과 거부(deny)를 결정하는 보안 규칙을 만든다. 가상의 방화벽을 기준으로 들어오는 인바운드(inbound) 규칙과 빠져나가는 아웃바운드(outbound) 규칙이 있기 때문에 트래픽 흐름을 고려한 보안 규칙을 세워야 한다.

보안 그룹과 네트워크 ACL은 송수신 트래픽의 접근을 통제한다는 점에서 서로 같지만, 차이점이 있다. 차이점은 크게 3가지로 나뉜다.

트래픽 접근 제어 대상

보안 그룹과 네트워크 ACL의 가장 큰 차이점은 접근 제어 대상이 서로 다르다는 것이다. 보안 그룹은 인스턴스와 같은 자원 접근을 제어하며, 네트워크 ACL은 서브넷 접근을 제어한다.

스테이트풀과 스테이트리스

보안 그룹은 이전 상태 정보를 기억하고 다음에 그 상태를 활용하는 스테이트풀(stateful) 접근 통제를 수행하며, 네트워크 ACL은 이전 상태 정보를 기억하지 않아 다음에 그 상태를 활용하지 않는 스테이트리스(stateless) 접근 통제를 수행한다.

보안 그룹의 스테이트풀 동작을 보면 인바운드 규칙에 따라 트래픽을 허용한 경우 정보를 기억하고 아웃바운드 규칙에 상관없이 자동으로 접근이 허용된다. 반대로 네트워크 ACL의 스테이트리스 동작을 보면 인바운드 규칙에 따라 트래픽을 허용했어도 아웃바운드 규칙으로 트래픽 허용 여부를 판단한다.

허용 및 거부 정책

보안 그룹의 정책 테이블은 허용 규칙만 나열하며 허용 규칙에 해당하지 않으면 자동 거부된다. 반면 네트워크 ACL의 정책 테이블은 허용 규칙과 거부 규칙이 모두 존재하여 규칙을 순차적으로 확인하고 허용과 거부를 판단한다. 네트워크 ACL에도 모든 규칙이 매칭되지 않으면 거부하는 규칙이 기본적으로 있다.

Amazon VPC와 다른 네트워크 연결

인터넷 게이트웨이

Amazon VPC는 프라이빗 클라우드 네트워크 환경으로, 외부 인터넷 구간과 연결되지 않은 독립적인 네트워크이다. 인터넷 게이트웨이는 VPC와 인터넷 구간의 논리적인 연결이자 인터넷으로 나가는 관문이 되는 네트워킹 자원이다.

퍼블릭 서브넷은 외부 인터넷 통신이 가능한 네트워크이다. 서브넷의 라우팅 테이블에서 외부 인터넷으로 나가는 타깃 대상을 인터넷 게이트웨이로 지정하여 퍼블릭 서브넷 환경을 만든다.

NAT 게이트웨이

NAT 게이트웨이(Network Address Translation gateway)는 프라이빗 서브넷에서 외부 인터넷으로 통신하는 관문 역할을 한다. NAT는 IP 주소를 변환하는 기능을 제공하며, 프라이빗 IP 주소를 퍼블릭 IP 주소로 변환하여 외부 인터넷 구간 통신 환경을 만든다. 프라이빗 서브넷은 외부 인터넷 구간과 단절된 독립된 네트워크이지만 외부 인터넷 구간과 통신이 필요할 때는 NAT 게이트웨이를 통해 프라이빗 IP 주소를 퍼블릭 IP 주소로 변환하여 외부 인터넷 구간과 통신할 수 있다.

VPC 피어링

VPC 피어링은 서로 다른 VPC를 연결하는 기능이다. 동일 리전뿐만 아니라 다른 리전에 위치한 VPC와 연결할 수도 있고, 다른 계정에 위치한 VPC까지 연결할 수 있다. VPC 피어링으로 연결할 경우 IP CIDR 블록이 중복되면 연결이 불가능한 제약이 있어 VPC 피어링으로 클라우드 네트워크를 확장할 때는 IP 주소 대역을 반드시 점검해야 한다.

전송 게이트웨이

전송 게이트웨이(transit gateway)는 다수의 VPC나 온프레미스를 단일 지점으로 연결하는 중앙 집중형 라우터이다. 단일 지점 연결이라 네트워크 구성이 간소화되고 비용도 절감되는 효과가 있다.

가상 프라이빗 게이트웨이

가상 프라이빗 게이트웨이(virtual private gateway)는 관리형 AWS Site-to-Site VPN을 연결하거나 AWS Direct Connect로 온프레미스 환경을 연결한다.

Amazon VPC 요금

기본적으로 Amazon VPC를 사용하면서 요금은 발생하지 않지만, VPC 기능 중 일부는 요금이 발생할 수 있다. NAT 게이트웨이는 최초 프로비저닝한 후 시간에 따른 요금이 부과되며, 기가바이트 단위로 데이터 처리 요금도 부과된다. 실습을 진행할 때는 기가바이트 단위의 데이터가 발생하지 않아 문제가 되지는 않지만, 시간에 따른 요금이 발생하는 것은 불가피하다.

Amazon ELB 기능

부하분산이란

부하분산은 서버-클라이언트 환경에서 서버가 클라이언트 요청을 받아 처리하는 과정에서 발생하는 부하(연산 작업)에 대해 동일한 목적을 수행하는 다수의 서버에 분산 처리하는 기능이다. 이런 부하분산을 로드 밸런싱(load balancing)이라고 하며, 부하분산을 수행하는 대상을 로드 밸런서(load balancer)라고 한다.

Amazon ELB 기능

AWS에서는 ELB(Elastic Load Balancing)라는 로드 밸런싱 기술을 제공한다. ELB는 Amazon EC2 인스턴스에서 운영 중인 애플리케이션, 마이크로서비스 또는 컨테이너 서비스로 유입되는 트래픽을 자동 분산처리하는 기술이다. EBLB는 애플리케이션 가용성을 향상시키고 HTTP, HTTPS, TCP, SSL 등 다양한 프로토콜을 지원하며 사용자가 같은 인스턴스에서 세션을 유지할 수 있도록 지원한다. 또한 AWS의 CloudWatch 기능을 이용하여 로그와 메트릭을 모니터링할 수 있으며, AWS의 오토 스케일링 기능과 결합해서 트래픽이 증가할 때 자동으로 인스턴스를 추가하거나 제거하면서 애플리케이션 가용성을 유지한다.

Amazon ELB 구성 요소

• 로드 밸런서: 여러 대의 EC2 인스턴스, IP 주소, 람다 등을 사용하여 트래픽을 대상 그룹에 있는 인스턴스로 분산시켜 애플리케이션의 가용성을 유지하는 역할을 한다. 로드 밸런서는 사용자 요청을 받아 애플리케이션 서버로 전달하고, 애플리케이션 서버의 응답을 사용자에게 반환한다.

• 대상 그룹: 로드 밸런서에서 분산할 대상의 집합을 정의하는 구성요소이다. 대상 그룹의 인스턴스에 대해 정적 또는 동적으로 구성할 수 있으며, 라우팅 규칙에 따라 요청을 받아들일 대상 그룹을 선택한다. 로드 밸런서는 대상 그룹에 포함된 대상들의 상태를 정기적으로 확인하여 장애 발생 대상을 자동으로 제외하고, 정상적으로 동작하는 대상에만 요청을 전달한다.

• 리스너: 로드 밸런서에서 사용할 포트와 프로토콜을 설정하는 구성 요소이다. 리스너는 로드 밸런서에서 클라이언트 요청을 수신하고, 해당 요청을 처리할 대상 그룹을 선택하는 역할을 한다. 리스너는 로드 밸런서에 연결된 프로토콜과 포트를 사용하여 클라이언트 요청을 수신하고, 해당 요청을 대상 그룹으로 라우팅한다.

Amazon ELB 동작 방식

Amazon ELB를 생성하면 설정한 가용 영역별로 로드 밸런서 노드가 생성되고 앞단에 리스너를 실행한다. 이런 리스너는 다양한 프로토콜을 지원하며, 요청에 대한 대상 그룹의 라우팅을 정의한다. 이에 따라 로드 밸런서는 가용 영역에 속한 대상 그룹의 인스턴스로 트래픽을 전달한다.

1. 클라이언트 요청 수신: 로드 밸런서에서 클라이언트 요청을 수신한다. 로드 밸런서는 클라이언트와 연결을 유지하며, 요청을 수신하려고 리스너를 등록한다.

2. 대상 그룹 선택: 수신한 클라이언트 요청을 처리할 대상 그룹을 선택한다. 대상 그룹은 인스턴스, IP 주소, 람다 함수, ALB 등 여러 유형의 대상으로 구성된다.

3. 트래픽 분산: 선택된 대상 그룹에서 요청을 처리할 대상을 선택하고 해당 대상으로 요청을 분산한다. 이때 로드 밸런서는 각 대상의 가용성 상태를 모니터링하고 가용하지 않은 대상을 제외한다.

4. 응답 반환: 분산된 요청을 대상에서 처리하고 클라이언트에 응답을 반환한다. 이때 응답은 로드 밸런서에서 수신한 것으로 반환되므로, 클라이언트는 로드 밸런서가 대상 그룹에서 선택한 대상에게서 마치 응답을 받는 것처럼 느낄 수 있다.

[ELB 생성 시 로드 밸런서와 통신하는 방식]

• 인터넷 경계 로드 밸런서: 외부에서 직접 로드 밸런서에 접근하는 방식

• 내부 로드 밸런서: 외부의 접근이 차단된 격리된 네트워크(내부 서버 전용)에서 로드 밸런서를 사용하는 방식

Amazon ELB 교차 영역 로드 밸런싱

Amazon ELB는 여러 가용 영역에서 로드 밸런서 노드를 실행하며, 각 노드는 가용 영역 내 대상 그룹으로 요청을 분산한다. 이때 대상 그룹에 등록된 대상이 여러 가용 영역에 걸쳐 있다면 기본적으로 로드 밸런서는 동일한 비중으로 가용 영역 내에 있는 대상으로 트래픽을 분산한다. 이는 대상 그룹의 가용성을 높이는 방법이라 유용하지만, 가용 영역 내 인스턴스 수량이 불균형할 때는 일부 인스턴스로 트래픽이 몰리고 다른 인스턴스는 유휴 상태가 되는 불균형 처리 문제가 발생할 수 있다.

교차 영역 로드 밸런싱 비활성화

그림에서 가용 영역별로 로드 밸런서가 배치되고 다수의 인스턴스가 구성되어 있다. 이때 대상 인스턴스 수량이 첫 번째 가용 영역은 두 대, 두 번째 가용 영역은 여덟 대로 영역별로 불균형하게 구성되어 있다. 사용자 PC에서 ELB 도메인 주소로 트래픽을 전송하면, 도메인을 해석하여 50:50 비중으로 각 가용 영역에 위치한 로드 밸런서로 전달할 것이다. 그러면 첫 번째 로드 밸런서는 총 50이라는 비중에서 두 대의 대상 인스턴스에 25의 비중으로 트래픽을 로드 밸런싱할 것이다. 따라서 첫 번째 가용 영역에 위치한 대상 인스턴스에 트래픽 부하도가 높아지게 되며, 전체적으로 로드 밸런싱이 불균형해지는 것을 확인할 수 있다.

이런 불균형 로드 밸런싱을 해결하는 데 Amazon ELB에서 제공하는 교차 영역 로드 밸런싱 기능을 사용할 수 있는데, ELB 교차 영역 로드 밸런싱(cross-zone load balancing)은 여러 가용 영역에 걸쳐 있는 EC2 인스턴스나 컨테이너 등 대상을 더 효과적으로 로드 밸런싱하는 기능이다. 이런 교차 영역 로드 밸런싱은 가용 영역별로 인스턴스 수량이 불균형하게 위치할 때 트래픽 비중을 보정할 수 있으며, 트래픽을 분산하는 기준이 가용 영역이 아닌 대상 그룹에 속한 자원을 기준으로 균일한 비중의 로드 밸런싱을 수행할 수 있다.

교차 영역 로드 밸런싱 활성화

앞의 상황과 동일하게 가용 영역별 인스턴스 수량이 불균형한 환경에서 가용 영역별로 50:50 비중으로 트래픽을 전달한다고 하자. 대상 자원의 비율에 따라 가용 영역을 교차하기 때문에 각 10의 비중을 맞추어 균일하게 열 대의 인스턴스 대상에 로드 밸런싱하는 것을 확인할 수 있다. 이렇게 교차 영역 로드 밸런싱을 활성화하면 가용 영역과 무관하게 대상 자원의 비율을 고려하여 가용 영역을 교차할 수 있어 좀 더 효율적으로 로드 밸런싱을 할 수 있다. 교차 영역 로드 밸런싱은 ALB를 사용할 때 기본적으로 활성화되어 있으나, NLB는 비활성화되어 있다. 또한 교차 영역 로드 밸런싱은 대상 그룹 수준에서 구성할 수 있으므로 필요에 따라 각 대상 그룹별로 별도로 구성할 수 있다. 단 사용할 때 가용 영역 간에 통신 비용이 발생할 수 있다.

Amazon ELB 종류

CLB

CLB(Classic Load Balancer)는 Amazon ELB의 가장 초기에 출시된 로드 밸런서로, 4계층과 7계층 프로토콜을 모두 지원한다. HTTP/HTTPS 요청에 따른 최신 HTTPv1.2 프로토콜과 TCP의 SSL/TLS 암호화 프로토콜도 지원하며, SSL 인증서를 사용한다. 고정 IP 주소를 사용하여 로드 밸런서를 생성하고, 로드 밸런서에 대한 DNS 이름으로 액세스할 수 있다. 그러나 CLB는 서버의 기본 주소가 변경되면 로드 밸런서를 새로 생성해야 하며, 기능적인 한계 때문에 포트나 헤더 같은 데이터를 수정하거나 변경할 수 없는 등 제약 사항이 있다. 현재는 NLB와 ALB 같은 새로운 로드 밸런서 서비스가 출시되어 CLB를 대체해서 사용하는 추세이다.

ALB

ALB(Application Load Balancer)는 AWS에서 제공하는 L7 로드 밸런서로, HTTP/HTTPS 같은 웹 애플리케이션 프로토콜을 지원한다. ALB는 대상 그룹 단위로 트래픽을 분산하며, 각 대상 그룹은 ALB가 요청을 전달할 EC2인스턴스, 람다 함수, 컨테이너 및 IP 주소로 라우팅하는 기능을 제공한다.

[ALB의 특징]

• HTTP 헤더를 확인하여 다양한 라우팅 기능을 제공
  • 경로 기반 라우팅: URL 경로를 기반으로 요청을 분산
  • 호스트 기반 라우팅: 호스트 이름을 기반으로 요청을 분산
  • 쿼리 문자열 기반 라우팅: URL 쿼리 문자열을 기반으로 요청을 분산
• 오토 스케일링과 함께 사용하여 확장성 있는 애플리케이션 구성 가능
• 대상 그룹 내 인스턴스에 대해 상태 검사를 수행하고, 문제가 발생하면 자동으로 장애 조치를 취할 수 있음
• Amazon CloudWatch Logs와 통합되어 로그 및 지표 데이터를 수집하고 모니터링 및 분석 가능

따라서 ALB는 웹 애플리케이션에 특화된 세밀한 라우팅을 제어할 수 있어 웹 애플리케이션을 위한 로드 밸런서로 사용된다.

NLB

NLB(Network Load Balancer)는 AWS에서 제공하는 L4 로드 밸런서로, TCP/UDP/TLS 프로토콜을 지원한다. ALB와 달리, 클라이언트와 로드 밸런서 간 연결을 TCP 레벨에서 유지하므로 대규모 트래픽을 처리할 수 있다. 이를 위해 NLB는 높은 처리량, 초당 연결 수, 대역폭 등 기능을 제공하며 동일한 IP 주소에서 여러 대상 그룹을 지원할 수 있다.

[NLB의 특징]

• 높은 처리량: 초당 수백만 개의 연결을 처리할 수 있음
• 빠른 응답 시간: 빠른 응답을 위해 최적화된 L4 로드 밸런싱 알고리즘을 사용
• 높은 가용성: 여러 가용 영역에서 인스턴스를 실행하고 매우 빠른 인스턴스 검색을 수행하여 신속하게 장애를 복구함
• IP 주소 보존: 클라이언트 IP 주소를 원래 IP 주소로 보존할 수 있음. 이것은 클라이언트 IP 주소를 유지하면서 로드 밸런싱을 수행할 수 있다는 것을 의미함
• 모니터링: AWS CloudTrail, Amazon CloudWatch Logs 같은 모니터링 기능을 지원함

따라서 NLB는 대규모 네트워크 트래픽을 처리하고 대상 그룹의 대상이 IP 주소로 식별될 때 유용하다. 또한 AWS에서 제공하는 다른 로드 밸런서보다 높은 처리량과 빠른 응답 시간을 보장하므로 게임 서버, VoIP 서비스, 미디어 스트리밍 등에서 사용된다.

GWLB

GWLB(Gateway Load Balancer)는 네트워크 트래픽을 서드 파티의 방화벽/어플라이언스 장비로 부하분산 처리하는 로드밸런서이다. GWLB를 사용하면 서드 파티의 방화벽/어플라이언스 장비를 쉽게 배포하고 확장 및 관리할 수 있다. 요청에 따라 트래픽을 확장하거나 축소하면서 다수의 서드 파티 장비에 로드 밸런싱을 처리한다. GWLB는 VPC 내에서 실행되는 애플리케이션의 가용성과 확장성을 향상시키는 데 사용되며, TCP 및 UDP 프로토콜을 지원하여 다양한 유형의 애플리케이션에 유연하게 적용할 수 있다.

각 로드밸런서 종류는 고유한 기능을 제공하며, 사용자 요구 사항에 따라 적절한 로드 밸런서를 선택하는 것이 중요하다.

클라우드 컴퓨팅

클라우드 컴퓨팅이란

IT 자원을 구축하는 전통적인 방법에 온프레미스 구축 방법이 있다. 프레미스(premise)는 기본, 건물, 토지라는 뜻이므로 온프레미스는 자체적인 공간과 자원을 이용하여 사용자가 직접 구축 및 운영하는 방식을 의미한다고 볼 수 있다. 사용자 입장에서 이런 구축 방식은 모든 것을 수행해야 하기 때문에 부담이 클 수 밖에 없으며, 비용 또한 만만치 않다.

이런 문제점을 고려하여 효율적으로 IT 자원을 구축하는 방법으로 클라우드 구축 방법이 떠오르고 있으며, 많은 비즈니스 환경에서 이 방식을 도입하자는 요구가 있다. 클라우드가 '구름'을 뜻한다는 것은 쉽게 알 수 있지만, 과연 IT 영역에서 클라우드는 어떤 의미일까? 일반적으로 IT 자원 구성도를 그릴 때, 인터넷에 있는 다양한 자원을 구름 형태로 표현하곤 한다. 이에 클라우드는 구름처럼 눈에 보이지 않는 형태로 집합되어 있는 IT 자원들이라고 생각할 수 있다.

클라우드 컴퓨팅은 인터넷을 통해 요구가 있을 때 즉시(온디맨드) IT 자원을 제공하며, 사용한 만큼 비용을 지불하는 서비스이다. 좀 더 이해하기 쉽게 앞서 설명한 클라우드 단어 의미와 연결하여 생각하면, 인터넷 구간 어딘가에 구름 형태로 쌓여 실제 물리적인 자원은 보이지 않지만 IT 자원을 원하는 대로 가져다 사용할 수 있는 컴퓨팅 서비스를 의미한다. AWS와 같은 클라우드 공급자에게 필요에 따라 다양한 IT 자원을 공급받을 수 있다.

온프레미스와 클라우드 정의

• 온프레미스(on-premises): 사용자 입장에서 공간, 자원 등 모든 것을 자체적으로 구축 및 운영하는 방식
• 클라우드(cloud): 인터넷 구간 어딘가에 눈에 보이지 않는 형태로 구성된 IT 자원 집합
• 클라우드 컴퓨팅(cloud computing): 인터넷을 통해 IT 자원 요구에 따라 사용한 만큼 비용을 지불하는 서비스

클라우드 컴퓨팅 이점

민첩성

클라우드를 통해 광범위한 기술에 쉽게 접근할 수 있어 거의 모든 것을 빠르고 혁신적으로 구축할 수 있다.

탄력성

클라우드 컴퓨팅을 사용하면 기존 온프레미스 환경처럼 향후 비즈니스 확장을 고려한 IT 자원을 사전에 과하게 구성할 필요가 없다.

비용 절감

클라우드 컴퓨팅은 Pay Per Use로, IT 자원을 사용한 만큼 비용을 지불하면 된다.

클라우드 컴퓨팅 서비스 유형

IaaS(Infrastructure as a Service)

말 그대로 인프라에 대한 클라우드 서비스 유형을 의미한다. 여기에서 인프라는 서버, 네트워크, 스토리지 등 하드웨어 영역과 가상화 기능이 해당된다. 클라우드 공급자는 해당 인프라 영역을 관리하고 서비스를 제공하며, 클라우드 사용자가 나머지 영역을 직접 고나리하는 구조이다.

PaaS(Platform as a Service)

플랫폼 형태로 제공되는 클라우드 서비스 유형을 의미한다. 클라우드 공급자가 자체적으로 구축한 플랫폼을 제공하며, 클라우드 사용자는 별도의 플랫폼을 구축하지 않고 애플리케이션을 개발 및 관리만 하면 된다. 즉, 클라우드 사용자는 애플리케이션 영역만 담당하고 나머지는 클라우드 공급자가 관리 및 제공하는 구조이다.

SaaS(Software as a Service)

SaaS는 소프트웨어 영역까지 클라우드 공급자가 관리 및 제공하는 유형을 의미한다. 클라우드 사용자는 별도의 애플리케이션을 설치하거나 운영할 필요 없이 클라우드 서비스를 제공받을 수 있다. 즉, 클라우드 공급자가 모든 것을 제공하고 클라우드 사용자는 서비스만 받는 구조이다.

클라우드 구축 모델

퍼블릭 클라우드 구축 모델

일반적으로 사용자가 클라우드 자원을 소유하지 않으며, 자체적인 공간에 위치하지 않고 클라우드 공급자가 서비스를 제공하는 환경이다. 확장성이 우수하며, 글로벌 서비스 제공에도 유리하다.

프라이빗 클라우드 구축 모델

사용자 전용 클라우드 환경으로, 자원 소유권은 사용자에게 있고 프라이빗 클라우드는 온프레미스 환경에 구축되어 서비스를 받는 환경이다. 즉, 서비스 주체가 '사용자'이다. 보안이 우수하지만, 퍼블릭 클라우드보다 서비스 확장성이 떨어진다.

하이브리드 클라우드 구축 모델

퍼블릭 클라우드와 프라이빗 클라우드의 단점을 보완하려고 등장한 클라우드 모델이다. 다수의 클라우드 시스템이 혼합되어 있는 형태로, 클라우드 시스템이 서로 연결된 모델이다.

AWS 서비스

AWS 소개

AWS는 다양한 퍼블릭 클라우드 컴퓨팅 리소스를 제공하고 있으며 직접 장비를 구매하거나 임대하지 않고 인터넷 환경을 통해 필요한 만큼의 리소스를 제공하는 클라우드 서비스 제공자이다. 현재 aws는 200개 이상의 클라우드 서비를 제공하는 것으로 알려져 있다. AWS는 32개의 리전(클라우드 서비스를 위해 자원이 집적되어 있는 물리적 데이터 센터의 지리적 위치)과 102개의 가용 영역(리전 내 구성되는 하나 이상의 개별적 데이터 센터)을 운영하여 글로벌 클라우드 인프라를 제공하고 있다.

리전과 가용 영역

• 리전(region): 데이터 센터가 집합된 물리적 위치(지역)
• 가용 영역(availability zone): 리전 내 구성된 하나 이상의 개별 데이터 센터

AWS 서비스 라인업

각 분류별로 200개 이상의 세부 서비스가 있다.

AWS 컴퓨팅

퍼블릭 클라우드의 서버 자원에 대해 가상 머신을 생성하고 비용 및 용량을 관리하는 서비스로 구성되어 있다.

AWS 네트워킹 및 콘텐츠 전송

퍼블릭 클라우드에 생성한 다양한 자원으로 내/외부 통신을 하는 네트워크 서비스들로 구성되어 있다.

AWS 스토리지

퍼블릭 클라우드에 안정적이고 확장성이 높은 스토리지 서비스들로 구성되어 있다.

AWS 데이터베이스

데이터베이스 목적과 용도에 따라 퍼블릭 클라우드에 다양한 데이터베이스 엔진을 제공하여 완전 관리형 데이터베이스 서비스를 하고 있다.

AWS 보안 자격 증명 및 규격 준수

퍼블릭 클라우드 자원과 사용자 자격 증명 및 접근 관리, 데이터/네트워크/애플리케이션 보호와 위협 탐지 및 모니터링을 위한 다양한 서비스로 구성되어 있다.

AWS 과금 체계

AWS는 Pay Per Use로, IT 자원을 사용한 만큼 비용을 지불하는 형태로 서비스를 제공한다. 물론 무료 서비스도 있지만, AWS 서비스 과금은 서비스마다 책정하는 방식과 기준이 다르다. 클라우드 서비스를 도입하기에 앞서 비용 검토가 선행되어야 하고 필요 자원을 산정해야 한다. 항상 과금은 시간과 사용량에 비례하여 사용한 만큼 부여한다는 점을 유의해야 한다.

AWS 컴퓨팅 서비스

컴퓨팅 정의

특정 부분을 계산해서 답을 구하고 추정하는 행위 자체를 Computing(컴퓨팅)이라고 정의하고 있다. 컴퓨팅을 전문적으로 수행하기 위해 인간이 아닌 컴퓨팅을 목적으로 하는 장비가 존재한다. 대표적으로 서버가 컴퓨팅을 위한 장비에 해당된다.

AWS 컴퓨팅 서비스

AWS Computing Service는 퍼블릭 클라우드에서 컴퓨팅 자원을 활용해서 다양한 워크로드를 수행할 수있는 서비스를 의미한다.

• 워크로드(Workload) :클라우드 환경에서 워크로드는 특정 작업이나 서비스를 수행하기 위해 클라우드 인프라에서 실행되는 애플리케이션, 프로세스, 또는 작업 집합을 의미한다. 이 워크로드는 웹 애플리케이션, 데이터베이스, 머신러닝 모델, 데이터 처리 작업 등 다양한 형태로 존재한다.

컴퓨팅 리소스를 사용할 수 있는 만큼 비용을 지불하면 수분 내로 가상의 서버 자원을 생성하고 관리할 수 있다.

• EC2(Elastic Compute Cloud) : 클라우드 환경에서 서버 자원을 인스턴스라는 가상 머신의 형태로 제공하는 가장 기본적인 AWS Computing Service

• Lambda : Serverless 컴퓨팅 서비스로, 별도의 서버 설정 없이 환경을 제공해서 코드만 실행해 주는 서비를 의미

• Lightsail : 독립적인 환경을 제공한다. 최소한의 설정만으로도 바로 사용 가능한 컴퓨팅 서비스

• ECS(Elastic Container Service) : EC2 기반 관리형 클러스터에서 실행되는 컨테이너 형태의 자원에 대해 배포, Scheduling, scaling 등을 관리하는 서비스

Amazon EC2 소개

Amazon EC2란 퍼블릭 클라우드 환경에서 확장 가능한 컴퓨팅 리소스를 제공하여 가상의 서버 인스턴스를 운영할 수 있도록 하는 서비스를 의미한다. EC2 인스턴스는 가상 컴퓨팅 환경을 기반으로 하고 AMI(Amazon Machine Image)를 사용해서 인스턴스에서 필요한 소프트웨어 정보를 정의한다.

Amazon EC2 인스턴스

EC2 인스턴스는 가상의 컴퓨팅 환경으로 프로세서, 메모리, 스토리지, 네트워크 용량을 결정하는 다양한 인스턴스 유형을 제공한다. 인스턴스가 실행 중인 임의의 프로세스로 해석된다는 점과 클라우드 컴퓨팅이 가상의 환경에서 필요한 자원을 임대해서 사용하다는 점이 서로 일맥상통한 의미를 갖는다.EC2는 500개가 넘는 인스턴스 유형을 제공해서 사용자의 목적과 비즈니스 환경에 맞게 인스턴스를 선택할 수 있다.

인스턴스 유형

인스턴스 상태

인스턴스 상태는 일반적으로 7가지로 분류할 수 있으며, 어떤 행위에 최종적으로 도달하는 상태와 진행 과정에 따른 상태로 나눌 수 있다.

인스턴스 수명 주기

• 최초 인스턴스를 시작하는 작업 : 대기 중 → 실행 중
• 실행 중인 인스턴스를 중지하는 작업 : 실행 중 → 중지 중 → 중지됨(인스턴스 종료 상태가 아님)
• 중지된 인스턴스를 종료 : 중지됨 → 종료 중 → 종료 됨
• 실행 중인 인스턴스의 종료 : 실행 중 → 종료 중 → 종료됨

AMI(Amazon Machine Image)

AMI는 인스턴스를 시작할 때 필요한 정보를 제공하는 것으로 운영 체제의 이미지 등 EC2 인스턴스에 대한 전반적인 메타데이터를 제공하는 템플릿을 의미한다.

AWS에서 자체적으로 제공하는 기본 AMI를 활용해서 인스턴스를 생성하고 사용자 요구에 따라 변경하거나 구성하여 사용자 정의 AMI를 생성할 수 있다. 이렇게 만들어진 사용자 정의 AMI를 통해 다른 인스턴스를 생성할 수 있다.

Amazon EC2 스토리지

AMI를 통해 인스턴스 환경을 설정했다면 다음으로 어떤 저장소를 사용할지 결정해야 한다. EC2는 유연하고 효율적인 스토리지 환경을 제공하고 아래와 같이 두 종류로 나뉜다.

EC2 인스턴스용 스토리지 유형은 인스턴스 스토어와 블록 스토리지인 Amazon EBS로 나뉜다.

인스턴스 스토어

인스턴스에 바로 붙어 있는 저장소로, Amazon EC2 인스턴스를 생성하면 기본적으로 존재하는 스토리지이다. 다만 일부 인스턴스 유형은 인스턴스 스토어를 지원하지 않는다. 아무래도 직접 붙어 있는 구조 덕분에 매우 빠른 I/O를 보장한다는 장점이 있지만, 인스턴스 스토어는 Amazon EC2 인스턴스를 중지하거나 종료하면 인스턴스 스토어에 저장된 데이터가 모두 손실된다는 단점이 있다. 따라서 임시적인 데이터 저장소로 생각할 수 있으며, 장기적으로 보존해야 하는 데이터는 인스턴스 스토어에 저장하지 않는 것이 좋다.

Amazon EBS

Amazon EBS는 AWS에서 제공하는 블록 스토리지 서비스로 EC2 인스턴스와 함께 사용되며 데이터의 지속성과 가용성을 보장한다. 디스크 형태로 작동하며 EC2 인스턴스에 네트워크로 연결하여 데이터를 저장하고 관리할 수 있다. 영구 보존이 가능하다. EC2 인스턴스가 중지되거나 종료되어도 Amazon EBS에 보존하는 데이터는 그대로 유지할 수 있다. EBS는 관리 콘솔을 통해 스냅샷을 생성해 백업하거나 EBS 연결을 해제한 후 다른 인스턴스에 연결 가능하다는 특징이 있다.

Amazon EC2 네트워킹

Amazon EC2 인스턴스는 어떤 서비스를 수행하기 위해 특수한 목적으로 만들어진 가상 서버 머신이다. 서비스를 제공하기 위해 자연스럽게 통신이 가능한 환경으로 구성될 필요가 있다. 이때 EC2 네트워킹을 통해 통신이 가능한 환경을 구성할 수 있다.

EC2 인스턴스 통신을 위한 네트워킹 요소

Amazon VPC

Amazon VPC는 AWS 퍼블릭 클라우드 내부에서 논리적으로 격리된 가상의 클라우드 네트워크 환경이다. 생성된 EC2 인스턴스는 별도로 구성된 하나의 Amazon VPC 내부에 생성되어 네트워킹된다.

네트워크 인터페이스

AWS에서는 ENI(Elastic Network Interface)라는 논리적 네트워크 인터페이스가 VPC 내 생성되며, ENI를 EC2 인스턴스에 연결해서 네트워킹을 수행한다.

IP 주소

네트워크 인터페이스에는 별도의 IP 주소가 존재하고 IP 주소로 각 인스턴스나 호스트를 구분하고 통신을 수행한다 이러한 IP 주소는 사설, 공인 IP 주소로 구분된다.

Amazon EC2 보안

AWS에서도 클라우드 내부의 보안 요소들을 중요하게 인식하고 있으므로 EC2의 안정적인 운영을 위해 EC2 보안 기능을 제공하고 있다.

보안 그룹

보안 그룹의 경우 EC2 인스턴스의 트래픽을 송수신 트래픽을 제어하기 위해 설계된 가상의 방화벽 환경이다. EC2 인스턴스를 기준으로 인바운드/아웃바운드 트래픽에 대한 규칙을 제어하게 된다. 트래픽 제어를 위해 IP 주소, 포트 번호, 프로토콜 등의 정보가 사용된다.

키 페어

EC2 인스턴스에 연결할 때 사용자 자격을 증명하기 위한 보안 키다. 키 페어는 Public, Private로 구분되며 퍼블릭 키는 Amazon EC2 인스턴스에 저장되고 프라이빗 키는 사용자 로컬 환경에 저장된다.

Amazon EC2 모니터링

EC2의 모니터링 기능은 서비스의 안정성, 가용성, 성능 유지에 반드시 필요한 기능이다. 불특정 다수에게 서비스되는 의미 있는 비즈니스 아키텍처의 경우 언제 어느 시점, 또는 특정 시점에 트래픽이 몰려서 서버가 다운될지 모른다. EC2의 리소스는 유한하기 때문에 자원에 대한 부하를 컨트롤하고 모니터링할 필요성이 있다.

아래와 같은 모니터링 계획을 정의해서 관리하는 것이 중요하다.

• 모니터링 목표
• 모니터링 대상 자원
• 모니터링 빈도
• 모니터링 수행 도구
• 모니터링 작업을 수행할 사람
• 문제가 발생할 때 정보를 알려야 할 대상

수동 모니터링 도구

말 그대로 관리자가 직접 관리 콘솔을 이용하여 모니터링을 수행하는 것이다. Amazon EC2 대시보드에서 간단한 통계 정보를 확인하거나 Amazon CloudWatch라는 모니터링 전용 서비스를 이용하여 상세한 통계 정보를 모니터링할 수 있다.

자동 모니터링 도구

오토 모니터링의 경우 대상 리소스에 대해 임계값을 지정하고 임계값을 초과하게 되면 Alert Message를 관리자에게 보여주는 형식으로 동적인 모니터링을 진행하게 된다. 다양한 도구가 있지만 대표적으로 Amazon CloudWatch가 있다.

CloudWatch의 경보 시스템을 통해서 동적으로 단일 리소스를 모니터링하고 지정된 임계값을 초과하는 경고 메시지를 생성하는 등의 방법으로 모니터링이 가능하다. 경고 메시지 등의 경우 Amazon SNS(Simple Notificationi Service)를 통해 관리자 이메일로 메일을 보내거나 EC2 자원을 동적으로 컨트롤할 수 있게 된다.

EC2 인스턴스 구입 옵션

• 온디맨드 인스턴스: 시작하는 인스턴스에 대한 비용을 초 단위로 지불
• Savings Plans: 1년 또는 3년 동안 시간당 비용을 약정하여 일관된 컴퓨팅 사용량을 제공
• 예약 인스턴스: 1년 또는 3년 동안 인스턴스 유형과 리전을 약정하여 일관된 인스턴스를 제공
• 스팟 인스턴스: 미사용 중인 인스턴스에 대해 경매 방식 형태로 할당

SSL Certificate and HTTPS Setup

본 프로젝트에서는 웹 서비스의 기본 보안을 강화하기 위해 Let's Encrypt 인증서와 Apache의 mod_ssl 모듈을 활용한 HTTPS 환경을 구축하였다. 초기에 mod_ssl 패키지를 설치하고 기본 SSL 설정 파일(/etc/httpd/conf.d/ssl.conf)을 검토하여 불필요하거나 충돌 가능성이 있는 설정을 제거한 후, WordPress 사이트에 적합한 별도 SSL 설정 파일(wordpress-ssl.conf)을 생성하였다.

Let's Encrypt를 활용한 인증서는 무료이면서도 브라우저와의 호환성이 높아 실무 환경에서도 널리 사용된다. 인증서를 수동 발급하기 위해 openssl 명령어를 사용해 자체 서명된 인증서(localhost.crt, localhost.key)를 /etc/pki/tls/경로에 생성하였고, Apache 설정에서 해당 경로를 명시했다.

설정 완료 후 apachectl configtest로 문법 오류를 검증하고 Apache를 재시작하여 HTTPS 접속이 가능함을 확인했다. 접속 시 브라우저에서 "주의: 보안 연결이 완전하지 않을 수 있음" 메시지가 출력되더라도, 자체 서명 인증서 기반의 HTTPS 연결이 정상적으로 동작하는 것은 실무에서도 초기에 테스트 및 내부 망에 유용하게 쓰일 수 있다.

특히, HTTPS 적용을 통해 WordPress 관리자 페이지와 사용자 로그인 정보 전송이 암호화되었으며, 이후 Wordfence 및 DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS 설정과 함께 다중 보안 계층을 형성하여 외부 공격으로부터의 방어 체계를 마련하였다.

https://localhost 접속

"Warning: Potential Security Risk Ahead" → "Advanced → Accept the Risk and Continue"

ls -l /etc/pki/tls/certs/localhost.crt 파일 정상적으로 생성됨

ls -l /etc/pki/tls/private/localhost.key 파일 정상적으로 생성됨

Apache 구문 오류 검사 통과

Monitoring with Prometheus and Grafana

본 단계에서는 Prometheus와 Grafana를 활용하여 WordPress 서버의 시스템 상태를 실시간으로 수집, 시각화하는 모니터링 환경을 구축했다. Prometheus는 Node Exporter로부터 수집한 메트릭 데이터를 주기적으로 스크래핑하며, Grafana는 해당 데이터를 기반으로 대시보드를 구성해 직관적인 시각 정보를 제공한다.

구성 요소

• Node Exporter: CPU, 메모리, 디스크, 네트워크 등의 시스템 메트릭 제공
• Prometheus: /metrics 엔드포인트 수집 및 시계열 DB 저장
• Grafana: Prometheus 데이터 시각화 및 대시보드 구성

구현한 주요 패널 구성

1. CPU Usage (%) 시각화 방식: Gauge 쿼리: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

2. Memory Usage (%) 시각화 방식: Gauge 쿼리: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

3. Disk Usage (%) 시각화 방식: Bar Gauge 쿼리: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100

4. CPU Load Average 시각화 방식: Stat 쿼리: node_load1

5. Network Inbound 시각화 방식: Time Series 쿼리: rate(node_network_receive_bytes_total[5m])

6. Network Outbound 시각화 방식: Time Series 쿼리: rate(node_network_transmit_bytes_total[5m])

Prometheus Target 상태 확인

Node_Exporter와 Prometheus가 모두 UP인 것을 확인

Grafana Data Sources default는 Prometheus

Grafana - Data Source 설정에서 Prometheus 연결 확인

Grafana 대시보드 전체 뷰

Network Inbound 설정 화면

Troubleshooting & Real-world Challenges

이번 프로젝트를 진행하며 여러 시스템 환경 변수와 충돌하는 문제를 직접 마주하고 해결해가는 과정을 통해 실무에서 발생 가능한 고급 이슈에 대한 감각을 키울 수 있었다.

가장 먼저 마주한 문제는 Apache + PHP-FPM 연동 과정에서의 500 Internal Server Error였다. 단순 설정 오류로 치부하지 않고 /var/log/httpd/error_log, PHP-FPM 서비스 로그까지 함께 확인하며 문제 원인을 추적했고, PHP를 proxy_fcgi 방식으로 처리하는 구조를 명확히 이해한 뒤 해결에 성공했다.

또한, 대부분 실습 환경에서는 비활성화하는 SELinux를 enforcing 모드로 유지한 채 작업을 진행했다. 이 과정에서 Apache와 PHP의 모듈 동작 권한, 인증서 파일 접근 권한이 충돌하는 부분을 restorecon, semanage, 로그 분석 등을 통해 해결해나갔다. SELinux 설정을 우회하지 않고 정책 안에서 문제를 풀어낸 점은, 보안을 고려한 시스템 운영 관점에서 특히 주목할 부분이다.

Grafana 설치에서도 yum 저장소가 닫힌 상황에서 포기하지 않고, 공식 .rpm 파일을 직접 다운로드하고 수동으로 설치하여 서비스 등록 및 실행까지 완료했으며, systemd 등록 후 상태 확인, 활성화까지 모든 과정이 자동화될 수 있게 구성했다.

마지막으로, Grafana 대시보드 구성에서도 단순 시각화가 아닌 실제 운영에 적합한 가로 3열 패널 구성, CPU 사용률, 메모리 사용률, 디스크 사용률, Load Average, 네트워크 트래픽까지 핵심 지표들을 시계열 + 게이지 방식으로 정리했다. 데이터 자체를 보여주는 것을 넘어서, 실시간 상황 판단이 가능한 구조로 시각화했다.

이러한 경험을 통해 단순히 설정을 따라 하기보다는, 문제가 발생했을 때 이를 분석하고 실무 환경에서도 적용 가능한 방식으로 직접 해결해보는 사고력과 기술 실천력을 갖추게 되었다고 느꼈다.

(자세한 트러블 슈팅 항목 -> Troubleshooting Details)

System Architecture Diagram

Strengths of the System

이번 프로젝트에서 구축한 시스템은 단순한 WordPress 설치를 넘어, 보안성, 확장성, 자동화, 가시성을 모두 고려한 종합적인 인프라 환경이다. 실무에 바로 적용 가능한 구조로 구성했으며, 다음과 같은 강점을 갖고 있다.

1. 보안성 중심의 구성 SELinux를 Enforcing 모드로 유지한 채 모든 설정을 적용함으로써, 시스템 단에서의 정책 기반 보안을 실현했다. 또한, firewalld로 포트 접근 제어, ModSecurity(WAF)를 통한 웹 공격 차단 설정까지 적용하여 실제 서비스 수준의 보안 레벨을 구현했다. 이외에도, WordPress 내부 코드 수정을 막는 DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS 설정으로 내부 보안 취약점도 방어했다.

2. 운영 관점에서 강력한 가시성 확보 Prometheus + Node Exporter + Grafana 조합을 통해 실시간으로 CPU, 메모리, 디스크, 네트워크 사용량을 대시보드로 시각화했다. 이를 통해 시스템 과부하나 자원 병목 현상을 사전에 탐지하고 대응할 수 있는 운영 가시성을 갖추었다.

3. 자동화 기반의 효율적 구성 Ansible을 활용하여 Apache, PHP, MariaDB, WordPress, 모니터링 도구 설치 및 설정을 자동화하여 반복적인 수동 작업을 줄이고 재현 가능하고 일관된 인프라 구축이 가능해졌다. 추후 백업/복구, 배포 자동화까지 확장할 수 있는 기반을 마련했다.

4. 실무 환경과 유사한 구조 Rocky Linux, php-fpm, mod_ssl, systemctl, VirtualBox, Shell Script, logrotate 등 실제 현업에서 사용하는 기술들로만 구성했다. 단순 학습용이 아닌 실무자가 바로 이해하고 유지보수할 수 있는 구조와 표준 설정 방식을 따랐다.

5. 문제 해결 경험 기반 SSL 인증서 오류, SELinux 충돌, 500/503 에러, php-fpm 연동 실패, Grafana 수동 설치 등 다양한 이슈를 직접 해결하며 실제 운영 상황에 대응할 수 있는 실무 역량을 체득했다.

Troubleshooting Details

Apache 초기 페이지에서 WordPress 화면이 출력되지 않음

• 원인: 기본 Apache 설정 상태로 /var/www/html/index.html만 표시됨
• 해결: index.html 제거 후 index.php가 로드되도록 설정

Grafana repository 접근 불가 (404 오류)

• 원인: https://rpm.grafana.com/oss/rpm/repodata/repomd.xml 접근 실패
• 해결: dnf 저장소 설정을 통한 설치 대신, .rpm 파일을 수동으로 다운로드 후 dnf install로 설치하도록 플레이북 수정

php-fpm 및 WordPress 권한 오류 (SELinux)

• 원인: SELinux enforcing 상태에서 /var/www/html/wordpress 디렉토리 접근 권한 부족
• 해결: audit.log에서 denied 메시지를 grep하여 문제 위치 확인 후, semanage fcontext 및 restorecon 명령어로 context 재설정

화면: ls -Z /var/www/html/wordpress

semanage 명령어가 작동하지 않음

• 원인: policycoreutils-python-utils 패키지 미설치
• 해결: dnf install -y policycoreutils-python-utils로 설치 시도 (단, Grafana 저장소 오류로 이 역시 실패함 → 수동 설치 고려 필요)

getenforce로 SELinux 상태 확인 시 enforcing 상태 유지

• 대응: 강제적으로 permissive 모드로 바꾸지 않고, SELinux 정책 수정을 통한 설정 유지 및 실무 친화적인 대응 방식으로 유지

WordPress 테마 편집/플러그인 설치 불가 상태로 유지

• 의도: wp-config.php 내 DISALLOW_FILE_EDIT 및 DISALLOW_FILE_MODS 설정 적용
• 결과: 보안 상 WordPress 관리자 UI에서 직접 코드/플러그인 수정 불가, 보안 강화를 위한 설정 완료

Grafana 대시보드 레이아웃 불편

• 문제: 모든 패널이 세로로만 정렬되어 시각적 불편함 발생
• 해결: 각 패널 편집 → Panel options → Width 비율 수동 조절을 통해 가로 3개 배치로 개선

Prometheus 접속 시 SSL 오류 (SSL_ERROR_RX_RECORD_TOO_LONG)

• 원인: https://로 접속했으나 Prometheus는 기본적으로 http:// 프로토콜 사용
• 해결: 브라우저 주소를 http://localhost:9090으로 변경하여 정상 접근

Apache 설정 구문 오류 발생 여부 확인

• 조치: apachectl configtest 명령어로 구문 확인
• 출력: "Syntax OK" 메시지로 설정 정상 여부 확인

WordPress 내부 플러그인 관련 오류 처리

• 원인: Wordfence 설치 후 관리자 패널이 작동하지 않거나 로그인 차단 이슈 발생 가능성
• 조치: 2FA 설정 및 경고 이메일 확인, 로그인 제한 조건 재설정하여 정상 복구

Conclusion & What I Learned

이번 SecureWP 프로젝트를 통해 시스템 인프라의 계획-구축-보안 강화-모니터링-문제 해결에 이르는 전 과정을 실습하며, 현업에서도 필요한 기술 역량을 종합적으로 익힐 수 있었다. 단순히 워드프레스를 설치하는 것을 넘어, 보안 강화를 위한 Wordfence 설정, 2FA 인증, SELinux 설정, 방화벽 규칙 구성 등 실무에서 반드시 필요한 절차들을 직접 수행했다.

특히 Ansible을 활용한 자동화 구성 관리는 서버 세팅의 일관성과 반복 가능성을 확보하는 데 큰 도움이 되었고, 문제가 발생했을 때 로그 분석, SELinux 트러블슈팅, 서비스 상태 확인, 포트 상태 점검 등 다양한 디버깅 스킬을 통해 실시간 문제 해결 경험을 쌓을 수 있었다. 또한 Prometheus + Node Exporter + Grafana 연동을 통해 시스템 자원(CPU, 메모리, 디스크, 네트워크)의 사용 현황을 시각화하여 시스템 상태를 한눈에 파악할 수 있는 모니터링 환경을 구현한 점은 큰 성과였다.

이 과정을 통해 단순한 기능 구현을 넘어 "보안", "운영", "가시성", "자동화", "유지보수"를 고려하는 인프라 마인드셋을 기를 수 있었고, 실무 환경에서 예기치 못한 이슈가 발생하더라도 원인을 빠르게 파악하고 대응할 수 있는 기반 지식과 경험을 확보할 수 있었다.

또한 기록 중심의 작업 방식으로, 모든 설정 및 트러블슈팅 과정을 문서화하고, 스크린샷 등 시각적 증거까지 확보함으로써 신뢰도 높은 기술 포트폴리오를 완성할 수 있었다. 이 프로젝트는 단지 기술 스택을 나열하는 것을 넘어서, 직접 경험하고 해결한 실전 중심의 프로젝트였기에 그 의미가 더욱 크다고 느껴진다.

SecureWP Infra: Automated WordPress System

Infrastructure Hardening with Ansible, Grafana, and Wordfence on Rocky

Project Overview

이 프로젝트는 실무 환경 수준의 보안성과 운영 자동화를 목표로, Rocky Linux 기반의 WordPress 인프라를 직접 구축한 경험을 담고 있다.

단순 설치가 아닌, 보안 강화, 자동화 구성, 실시간 모니터링 체계 구축이라는 세 가지 핵심을 중심으로 설계했다.

Ansible을 활용해 Apache, PHP-FPM, MariaDB, WordPress, 방화벽, 로그 분석 도구까지 자동화 구성하였으며, SELinux는 enforcing 모드로 운영하여 보안 정책을 강제 적용했다. 또한, Wordfence 보안 플러그인을 통해 로그인 보호, 2단계 인증, 웹 방화벽을 설정하고, Prometheus + Grafana를 통해 시스템의 CPU, 메모리, 디스크, 네트워크 등의 상태를 시각화하여 실시간 운영 가시성을 확보했다.

진행 과정에서는 실제 장애 상황과 유사한 문제들(php-fpm 503 오류, SELinux 접근 차단, 인증서 발급 실패 등)을 직접 해결하며, 문제 분석 및 구조적인 운영 능력을 체득했다.

단순히 돌아가는 시스템이 아닌, 보안과 안정성을 모두 갖춘 실전형 인프라 환경을 자동화 방식으로 완성한 것이 이 프로젝트의 핵심이다.

Technology Stack & Justification

운영체제 및 가상환경

Rocky Linux 9.5

RHEL 계열의 오픈소스 OS로, 기업 실무 환경에서 CentOS 대체로 널리 사용되고 있다. SELinux, systemd, firewalld 등 실무에서 자주 접하는 구성 요소들이 탑재되어 있어 실제 서비스 환경과 유사한 조건을 제공한다.

VirtualBox

독립된 테스트 환경 구축을 위해 사용. 네트워크 설정, 스냅샷 복원 등을 통해 장애 테스트와 복구 실습이 가능하다.

웹/애플리케이션 및 데이터베이스

Apache(httpd)

WordPress와의 호환성과 설정 유연성이 높아 선택했다.

PHP-FPM(FastCGI Process Manager)

성능 및 보안 향상을 위해 Apache와 연동하여 사용한다. socket 및 TCP 방식 모두 테스트하며 실무 연동 방식으로 학습했다.

MariaDB

MySQL 호환 오픈소스 DBMS이다. mysqldump를 활용한 백업 및 복구 자동화가 가능하다.

인프라 자동화 및 관리

Ansible

모든 구성 과정을 role 기반으로 자동화한다. . Apache, PHP, DB, WordPress 설치부터 보안 설정, 백업까지 반복 가능하고 관리가 쉬운 코드 형태로 관리할 수 있다.

Shell Script

일부 로컬 설정 및 수동 작업을 위한 보조 자동화 수단으로 사용한다.

PowerShell

Windows 기반 서버 환경 연동 및 향후 확장성을 고려해 연습, 적용 예정이다.

보안 및 방화벽

SELinux (Enforcing 모드)

서비스 접근 제어 및 시스템 내부 권한을 관리한다. 운영 중 발생하는 차단 로그를 바탕으로 보안 예외 정책을 적용한다.

Firewalld

포트 기반으로 접근을 제어한다. HTTPS 443, SSH 22 등 필요한 포트만 열어 실무 수준의 제어를 학습했다.

ModSecurity (WAF)

웹 애플리케이션 방화벽이다. Apache와 연동하여, OWASP Core Rule Set을 적용, 테스트한다.

Wordfence

WordPress 환경 전용 보안 플러그인이다. 관리자 로그인 제한, 이중 인증, 실시간 공격 탐지 기능으로 실무에서 가장 널리 사용된다.

모니터링 및 시각화

Prometheus

Node Exporter를 통해 시스템 지표를 수집한다. YAML 기반 설정으로 exporter을 연동한다.

Grafana

Prometheus에서 수집한 데이터를 시각화한다. CPU, 메모리, 디스크, 네트워크 트래픽 등을 Stat, Bar Gauge, Table 등의 시각 도구로 표현한다.

logrotate, journalctl

로그 순환 및 시스템 로그 분석을 담당한다. 주기적인 로그 정리를 통한 운영 안정성을 확보한다.

이 스택들은 실제 운영 환경에서 널리 사용되는 구성 요소들로, 단순한 구축이 아닌 실무 수준의 문제 해결 경험을 쌓기 위한 목적으로 선정했다.

프로젝트는 VirtualBox 가상머신을 기반으로 진행되었으며, 테스트와 장애 복구 연습을 고려해 스냅샷 기능을 적극 활용했다.

기본 운영체제는 Rocky Linux 9.5 Minimal ISO를 사용하였고, 설치 시 GUI 없이 CLI 환경을 선택하여 리눅스 시스템 관리 능력 향상에 초점을 맞췄다.

Environment Setup

가상머신 구성

VirtualBox Version

7.0.10

설정 사양

CPU 2코어, RAM 4GB, 저장공간 40GB

네트워크 어댑터

브리지 어댑터로 설정하여 외부 인터넷 접근 및 내부 IP 고정이 가능하게 구성했다.

초기 설정 항목

• 사용자 계정: root, jm 일반 사용자 구성
• Hostname: securewp.local 설정
• SELinux 설정: 설치 후 enforcing 상태 확인 및 정책 적용 준비
• 패키지 캐시 클리어: dnf clean all 수행 후 dnf update로 최신화
• EPEL 및 Remi 저장소 추가: 최신 PHP, MariaDB 패키지 설치를 위한 저장소 구성
• timezone 설정: Asia/Seoul 설정 및 시간 동기화 chronyd 구성
• 방화벽 초기 설정: firewalld zone 확인 및 HTTP, HTTPS, SSH 포트 개방

getenforce 출력

스냅샷 관리 전략

• Snapshot 1 (Wordfence 설치 전): Apache, PHP, DB, WordPress 설치 완료
• Snapshot 2 (PHP 보안 설정 완료 시점)
• Snapshot 3 (Grafana 대시보드 구성 완료)

실습 중 오류 발생 시 지점 복구 후 재진행 가능하도록 설계, 실무에서 시스템 복구/운영 경험까지 학습할 수 있도록 구성했다.

Infrastructure Automation with Ansible

WordPress 인프라 전체 구성은 수동 설정이 아닌, Ansible 역할 기반(Role-based) 자동화로 설계했습니다. 각 컴포넌트(Apache, PHP, MariaDB, WordPress 등)를 독립된 Role로 나누고, playbook 하나만 실행하면 시스템이 일관되게 설정되도록 구성하였습니다.

디렉토리 구조

주요 Role 및 구성 목적

• Apache: httpd 설치 및 가상호스트 설정(wordpress-ssl.conf)
• PHP: PHP 8.1 설치 및 FPM 연동 (Remi repo 활용)
• MariaDB: DB설치, root 계정 설정, WordPress용 DB/user 생성
• Wordpress: Wordpress 압축 해제, wp-config.php 자동 구성
• Firewall: firewalld 포트 개방 (80, 443, 22) 및 서비스 등록
• SELinux: enforcing 유지, Wordpress 디렉토리 보안 context 설정
• PHP_Hardening: php.ini 파일 보안 설정 적용 (expose.php, disable_functions 등)
• Logwatch: 시스템 로그 리포트 자동화 (메일 발송도 구성 가능)

실행 방법

systemctl status httpd 출력화면

자동화 구성 예시 (apache role 내 tasks/main.yml)

• Role 분리: 각 서비스 단위로 역할이 구분되어 있어 유지보수, 재사용, 확장이 용이함
• 재현 가능성: 스냅샷 없이도 ansible-playbook 한 번으로 환경 구성 가능
• 실제 정책 반영: SELinux context, 파일 권한, php.ini 보안 설정 등 실제 운영환경에서 요구되는 설정 반영

Security Hardening & Firewall Configuration

이 단계에서는 시스템 접근 제어, 파일 권한 보호, 웹 애플리케이션 공격 방어를 중심으로 기초 보안 설정을 강화했다. 보안 강화를 위한 핵심 요소는 SELinux, firewalld, ModSecurity, Wordfence 네 가지이다.

SELinux 정책 적용(enforcing 유지)

상태 확인

getenforce 명령어로 SELinux 상태를 Enforcing으로 유지함으로써 비정상 접근을 정책 기반으로 차단한다.

Context 설정

웹 서버 디렉토리(/var/www/html/wordpress)에 대해 httpd_sys_rw_content_t context를 부여했다.

오류 해결 경험

php-fpm 연동 중 SELinux 차단 로그(avc: denied)를 journalctl -xe, ausearch -m avc로 분석해 해결

방화벽 구성 (firewalld)

firewalld 서비스 상태 확인 및 활성화

HTTP, HTTPS, SSH 포트 개방

zone 확인

웹방화벽 구성 (ModSecurity)

설치 및 활성화

기본 룰셋 확인 및 적용

OWASP CRS 연동 가능하며, /etc/httpd/conf.d/mod_security.conf에서 설정을 변경한다.

기능

SQL Injection, XSS, 파일 포함 공격 등을 탐지하고 차단한다.

워드프레스 보안 플러그인 설정 (Wordfence)

• 2FA, 로그인 제한, 관리자 알림 이메일 활성화
• Advanced Protection 모드: 모든 PHP 요청을 방화벽이 사전 처리
• 실시간 공격 탐지 대시보드 구성 완료

실무 관점에서의 강점

• SELinux: Enforcing 유지 -> 시스템 내 비인가 접근 제어 정책
• Firewalld: 80/443/22 포트 제한 개방 -> 외부 접근 최소화
• ModSecurity: 활성화 -> 공격 유형 탐지 및 대응
• Wordfence: 로그인 보안 + 실시간 탐지 -> WordPress 특화 보호 기능

Wordpress 내부 메뉴 접근 제어

Appearance의 Theme Editor와 Plugin의 Add New Plugin이 차단된 모습을 볼 수 있다.

Wordfence Dashboard

Wordfence 2FA(2중 잠금) 설정

다음 날에 이어서..

https://school.programmers.co.kr/learn/courses/30/lessons/299305 Level: 3

[문제 설명]

대장균들은 일정 주기로 분화하며, 분화를 시작한 개체를 부모 개체, 분화가 되어 나온 개체를 자식 개체라고 한다. 다음은 실험실에서 배양한 대장균들의 정보를 담은 ECOLI_DATA 테이블이다. ECOLI_DATA 테이블의 구조는 다음과 같으며, ID, PARENT_ID, SIZE_OF_COLONY, DIFFERENTIATION_DATE, GENOTYPE 은 각각 대장균 개체의 ID, 부모 개체의 ID, 개체의 크기, 분화되어 나온 날짜, 개체의 형질을 나타낸다.

최초의 대장균 개체의 PARENT_ID 는 NULL 값이다.

[문제]

대장균 개체의 ID(ID)와 자식의 수(CHILD_COUNT)를 출력하는 SQL 문을 작성해주세요. 자식이 없다면 자식의 수는 0으로 출력해주세요. 이때 결과는 개체의 ID 에 대해 오름차순 정렬해주세요.

SELECT A.ID, COUNT(B.ID) AS CHILD_COUNT
FROM ECOLI_DATA A
LEFT JOIN ECOLI_DATA B
ON A.ID = B.PARENT_ID
GROUP BY A.ID
ORDER BY A.ID ASC;

테이블을 둘로 나눠 풀이하는 것에 점점 익숙해져가는 것 같다.

자식의 수가 0인 ID들도 출력해줘야 하기 때문에, INNER JOIN이 아닌 LEFT JOIN을 써줘야만 한다.

그 외에 딱히 어려운 부분은 없다.

DNS Zone & Zone File 정리

DNS Zone 이란?

• DNS 정보를 관리하기 위한 논리적인 단위
• 계층적으로 구성 (root → TLD → subdomain)
• Zone = 하나의 도메인에 대한 DNS 관리 범위
• 각 Zone은 다른 관리자가 관리 가능
• 하나의 도메인 안에서도 Zone을 나누어 관리 가능

Zone 파일이란?

• 텍스트 형식의 설정 파일
• 해당 Zone에 대한 DNS 레코드(RR)를 포함함
• DNS 서버가 이를 데이터베이스처럼 참조

Zone 파일 구성 요소

시작: SOA (Start of Authority) 레코드

• Zone의 시작을 알림
• 마스터/슬레이브 서버 간 Zone Transfer 기준 정보 제공

@   IN  SOA ns1.example.com. admin.example.com. (
        2025042801 ; serial
        3600       ; refresh (1시간)
        1800       ; retry (30분)
        604800     ; expire (7일)
        86400 )    ; minimum TTL (1일)

serial: 변경 시마다 증가 (슬레이브는 이걸 기준으로 동기화 여부 판단) refresh: 슬레이브가 마스터에게 변경 확인 주기 retry: 실패했을 경우 재시도 주기 expire: 마스터와의 연결이 끊긴 후 슬레이브가 데이터를 폐기할 시간 minimum TTL: 캐시 수명

그 외 레코드들

NS(Name Server): 권한 있는 네임서버

A: IPv4 주소

AAAA: IPv6 주소

MX: 메일 서버

CNAME: 별칭

PTR: 역방향 주소 매핑

TXT: 인증 및 설명 정보 (ex. SPF, DKIM)

Zone 파일 취득 방법

자체 운영 중인 DNS 서버

• 경로: /var/named/도메인명.zone

호스팅 제공 업체 이용 시

• 관리자 웹페이지에서 Zone File Export 기능 사용

SOA 레코드 & 실습 예시

SOA 레코드란?

• Start of Authority
• DNS Zone의 시작점을 알리는 레코드
• Zone 파일 내 가장 먼저 위치
• Primary(마스터) DNS 서버의 정보와 슬레이브 DNS의 동기화 기준을 포함

SOA 레코드 구조

$TTL 3H
@  3600 IN  SOA  ns.icann.org. noc.dns.icann.org. (
           2020080302  ; Serial
           7200        ; Refresh
           3600        ; Retry
           1209600     ; Expire
           3600 )      ; Minimum TTL

ns.icann.org.: Primary 네임서버 noc.dns.icann.org.: 관리자 이메일 → noc@dns.icann.org 2020080302: 시리얼 번호 (slave 서버가 최신 Zone 정보를 갖고 있는지 판단 기준) 7200 (2시간): Refresh – 슬레이브가 마스터에 변경사항 확인 주기 3600 (1시간): Retry – 마스터 응답 실패 시 재시도 시간 1209600 (14일): Expire – 슬레이브가 마스터로부터 응답 못 받을 경우 zone 폐기 시간 3600 (1시간): Minimum TTL – 레코드를 캐시하는 기본 시간

실습: dig 명령으로 SOA 조회

blog.naver.com 의 SOA 레코드

$ dig blog.naver.com SOA

결과

;; AUTHORITY SECTION:
nheos.com. 180 IN SOA gns1.nheos.com. hostmaster.nheos.com. 2021081901 10800 3600 604800 180

gns1.nheos.com.: Primary DNS hostmaster.nheos.com.: 관리자 이메일 → hostmaster@nheos.com 10800: Refresh → 3시간 3600: Retry → 1시간 604800: Expire → 7일 180: TTL → 180초 (캐시 유지 시간)

naver.com 의 SOA 레코드

$ dig naver.com SOA

결과

;; ANSWER SECTION:
naver.com. 300 IN SOA ns1.naver.com. webmaster.naver.com. 2021082001 21600 1800 1209600 180

ns1.naver.com.: Primary DNS webmaster.naver.com.: 관리자 이메일 → webmaster@naver.com 21600: Refresh → 6시간 1800: Retry → 30분 1209600: Expire → 14일 180: TTL → 180초

DNS 레코드 종류 및 설명

A :IPv4 주소를 도메인에 매핑 (예: example.com → 123.45.67.89) AAAA: IPv6 주소를 도메인에 매핑 (예: example.com → 2001:0db8::1) CNAME: 도메인의 별칭 설정 (예: www.example.com → example.com) MX: 메일 서버 주소 지정 (@example.com 이메일을 어떤 서버로 전달할지 정의) PTR: IP → 도메인 역방향 질의용 (메일 수신 측에서 발신 서버의 신뢰 검증용) TXT: 도메인 관련 정보 텍스트로 저장 (예: SPF, DKIM, DMARC 정책 등) NS: 도메인을 관리하는 네임서버 지정 (example.com → ns1.example.com) URL: 도메인을 특정 URL로 리디렉션 (HTTP 리디렉션 방식) Framed URL: URL 리디렉션 + 주소창에 원래 도메인 그대로 유지 (프레임 내 로딩)

DNS 서버 구성 순서

패키지 설치

yum -y install bind bind-utils

네트워크 설정

• 고정 IP 주소 설정 (예: 192.168.56.100)
• DNS 서버 주소는 /etc/resolv.conf 또는 nmcli로 설정
• hostnamectl set-hostname dns-server.cccr.org

설정 파일 편집

• 메인 설정: /etc/named.conf
• Zone 파일 경로: /var/named/도메인.zone

서비스 시작 및 활성화

systemctl start named systemctl enable named

방화벽 포트 오픈

firewall-cmd --add-service=dns --permanent firewall-cmd --reload

DNS 도메인 확인 명령어

nslookup www.naver.com: 도메인 이름 → IP 주소 확인 nslookup 후 > 10.0.2.100: IP 주소 → 도메인 확인 host www.naver.com: 도메인 정보 요약 출력 host -t A www.naver.com: A 레코드 정보 조회 host -t PTR 10.0.2.100: PTR 레코드 조회 (역방향 DNS) dig www.naver.com: 상세 DNS 질의 결과 출력 dig -x 10.0.2.100: 역방향 질의

DNS 서버 구성 실습

초기 세팅

패키지 설치

dnf -y install bind bind-utils

방화벽 포트 오픈

firewall-cmd --add-service=dns --permanent firewall-cmd --reload

네트워크 설정

ip addr add 10.0.2.10/24 dev ethX hostnamectl set-hostname dns.test.example.com

named.conf 설정 (정방향)

vi /etc/named.conf

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { none; };
    directory       "/var/named";
    allow-query     { any; };
};

zone "test.example.com" IN {
    type master;
    file "test.example.com.zone";
};

정방향 zone 파일 생성

cd /var/named cp named.empty test.example.com.zone vi test.example.com.zone

$TTL 3H
@   IN  SOA test.example.com. root.test.example.com. (
            0       ; serial
            1D      ; refresh
            1H      ; retry
            1W      ; expire
            3H )    ; minimum

    NS      dns.test.example.com.
    A       10.0.2.2
dns     A   10.0.2.10
www     A   10.0.2.20
ftp     A   10.0.2.30
mail    A   10.0.2.40
blog    A   10.0.2.50

chmod 660 test.example.com.zone chown :named test.example.com.zone

역방향 zone 구성

vi /etc/named.conf

zone "2.0.10.in-addr.arpa" IN {
    type master;
    file "10.0.2.0.zone";
};

cp test.example.com.zone 10.0.2.0.zone vi 10.0.2.0.zone

$TTL 3H
@   IN  SOA test.example.com. root.test.example.com. (
            0       ; serial
            1D      ; refresh
            1H      ; retry
            1W      ; expire
            3H )    ; minimum

    NS      dns.test.example.com.
    A       10.0.2.2

10  PTR dns.test.example.com.
20  PTR www.test.example.com.
30  PTR ftp.test.example.com.
40  PTR mail.test.example.com.
50  PTR blog.test.example.com.

chmod 660 10.0.2.0.zone chown :named 10.0.2.0.zone

서비스 시작

systemctl enable named --now

Master / Slave 구성

마스터 DNS 설정 변경

vi /etc/named.conf

zone "test.example.com" IN {
    type master;
    file "test.example.com.zone";
    allow-transfer { 10.0.2.101; };
};

zone "2.0.10.in-addr.arpa" IN {
    type master;
    file "10.0.2.0.zone";
    allow-transfer { 10.0.2.101; };
};

zone 파일 변경

vi /var/named/test.example.com.zone

    NS  dns.test.example.com.
    NS  slave.test.example.com.
    ...
slave   A   10.0.2.101

vi /var/named/10.0.2.0.zone

    NS  dns.test.example.com.
    NS  slave.test.example.com.
    ...
101 PTR slave.test.example.com.

Slave DNS 서버 구성 실습

패키지 설치

dnf -y install bind bind-utils

네트워크 및 호스트 설정

nmcli con mod ethX ipv4.addresses 10.0.2.101/24 nmcli con mod ethX ipv4.method manual nmcli con mod ethX ipv4.gateway "" nmcli con mod ethX ipv4.dns 10.0.2.10 nmcli con up ethX

hostnamectl set-hostname slave.test.example.com

named.conf 설정 (Slave DNS)

vi /etc/named.conf

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { none; };
    directory       "/var/named";
    dump-file       "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    recursing-file  "/var/named/data/named.recursing";
    secroots-file   "/var/named/data/named.secroots";
    allow-query     { any; };
};

zone "test.example.com" IN {
    type slave;
    masters { 10.0.2.10; };
    file "slaves/test.example.com.zone";
    notify no;
};

zone "2.0.10.in-addr.arpa" IN {
    type slave;
    masters { 10.0.2.10; };
    file "slaves/10.0.2.0.zone";
    notify no;
};

서비스 실행 및 방화벽

systemctl enable named --now

firewall-cmd --add-service=dns --permanent firewall-cmd --reload

슬레이브 zone 파일 복사 확인

ls /var/named/slaves/

• 마스터에서 allow-transfer 설정이 되어 있고 연결이 잘 되었으면 test.example.com.zone, 10.0.2.0.zone 파일이 자동으로 생성됨

클라이언트 테스트

nmcli con mod static +ipv4.dns 10.0.2.101

host dns.test.example.com 10.0.2.101

MySQL 기본 실습

MySQL 접속

mysql -u root -p

• -u root: root 사용자로 접속
• -p: 비밀번호 입력을 위한 옵션

데이터베이스 목록 확인

SHOW DATABASES;

• 현재 MySQL 서버에 존재하는 데이터베이스 목록을 출력함

특정 데이터베이스 사용

USE test;

• test라는 데이터베이스를 사용하겠다는 의미
• 이후의 모든 쿼리는 이 데이터베이스에 적용됨

현재 사용 중인 데이터베이스 안의 테이블 목록 확인

SHOW TABLES;

• 현재 선택한 데이터베이스(USE 명령어로 선택한 DB) 안에 존재하는 테이블을 보여줌

시스템 데이터베이스 접근

USE mysql;

• mysql 데이터베이스는 사용자 계정 및 권한 정보 등이 저장된 시스템 DB
• 사용자 관련 설정을 변경하거나 확인할 때 사용됨

시스템 테이블 목록 확인

SHOW TABLES;

• mysql 데이터베이스 내부의 모든 시스템 테이블을 나열함

사용자 정보 테이블 구조 확인

DESCRIBE user;

• user 테이블의 컬럼(열) 정보 출력
• 각 필드의 이름, 타입, NULL 허용 여부, 기본값 등을 확인할 수 있음

SELECT / WHERE 실습

SELECT 기본 구문

기본 형식

SELECT column1, column2, ... FROM table;

예제

SELECT host FROM user; SELECT host, user, password FROM user;

WHERE 조건절

숫자 조건 검색

비교 연산자 사용

SELECT host, user, password, max_updates FROM user WHERE max_updates = 0; SELECT host, user, password, max_updates FROM user WHERE max_updates > 0; SELECT host, user, password, max_updates FROM user WHERE max_updates >= 0; SELECT host, user, password, max_updates FROM user WHERE max_updates != 1; SELECT host, user, password, max_updates FROM user WHERE max_updates <> 1;

범위 검색

SELECT host, user, password, max_updates FROM user WHERE max_updates BETWEEN -1 AND 1; SELECT host, user, password, max_updates FROM user WHERE max_updates BETWEEN 0 AND 1; SELECT host, user, password, max_updates FROM user WHERE max_updates BETWEEN 1 AND 2;

여러 값 중 하나

SELECT host, user, password, max_updates FROM user WHERE max_updates IN (1, 2, 3, 4); SELECT host, user, password, max_updates FROM user WHERE max_updates IN (1, 2, 3, 0);

NULL 여부 검사

SELECT host, user, password, max_updates FROM user WHERE max_updates IS NULL; SELECT host, user, password, max_updates FROM user WHERE max_updates IS NOT NULL;

문자열 조건 검색

같음 (=)

SELECT host, user FROM user WHERE host = 'localhost';

LIKE (패턴 매칭)

정확히 일치

SELECT host, user FROM user WHERE host LIKE 'localhost';

local 뒤에 한 글자

SELECT host, user FROM user WHERE host LIKE 'local_';

local로 시작하는 문자열

SELECT host, user FROM user WHERE host LIKE 'local_%';

두 번째 글자가 o인 패턴

SELECT host, user FROM user WHERE host LIKE '_ocal%';

ocal로 시작

SELECT host, user FROM user WHERE host LIKE 'ocal%';

localhost로 시작

SELECT host, user FROM user WHERE host LIKE 'localhost%';

앞에 글자 5개 + host로 시작

SELECT host, user FROM user WHERE host LIKE '_____host%';

특정 포맷 패턴

SELECT host, user FROM user WHERE host LIKE '_o___host%';

논리 연산자와 LIKE

SELECT host, user FROM user WHERE host LIKE '%local%' AND user LIKE 'root'; SELECT host, user FROM user WHERE host LIKE '%local%' OR user LIKE 'root';

DML 실습: INSERT / UPDATE / DELETE

준비 작업: 테이블 생성

USE test;

CREATE TABLE user (
  name VARCHAR(10),
  uid INT,
  locate VARCHAR(10),
  email VARCHAR(20)
);

• VARCHAR(n) : 실제 입력된 글자 수만큼 저장.
• CHAR(n) : 항상 고정된 길이(n)만큼 공간 차지.
• INT : 정수 타입

DESCRIBE user;
SELECT * FROM user;

INSERT 구문

컬럼 순서를 지정하여 삽입

INSERT INTO user (name, uid, locate, email)
VALUES ('Lee', 1, 'seoul', 'lee@test.example.com');
INSERT INTO user (uid, name, email, locate)
VALUES (2, 'KIM', 'kim@test.example.com', 'daegu');

컬럼 순서 생략 (모든 컬럼 순서대로 입력)

INSERT INTO user
VALUES ('Lim', 3, 'kyunggi', 'lim@test.example.com');

컬럼 순서 생략 시, 순서가 다르면 오류 발생 가능

INSERT INTO user
VALUES (4, 'kyunggi', 'park@test.example.com', 'Park');

입력 결과 확인

SELECT * FROM user;

UPDATE 구문

특정 조건의 행 데이터 변경

UPDATE user
SET name = 'Park'
WHERE uid = 0;

DELETE 구문

특정 조건의 행 삭제

DELETE FROM user
WHERE uid = 0;

WHERE 절 누락 주의

UPDATE 구문 – 전체 레코드 변경됨

UPDATE user
SET locate = 'busan';

• WHERE 조건이 없기 때문에 user 테이블의 모든 행의 locate 컬럼이 'busan'으로 변경됨

결과

SELECT * FROM user;

• 모든 사용자 데이터의 locate가 'busan' 으로 동일하게 설정됨

DELETE 구문 – 전체 레코드 삭제됨

DELETE FROM user;

• WHERE 조건이 없으면 user 테이블의 모든 행이 삭제됨

결과

SELECT * FROM user;

• 결과 없음 (빈 테이블)

실무에서 반드시 기억해야 할 안전 수칙

1. UPDATE / DELETE 사용 시 항상 WHERE 조건부터 작성하는 습관을 들이기

2. 실수로 실행하지 않도록 SELECT로 먼저 조건 테스트하고, 조건이 맞는지 확인한 후에 UPDATE/DELETE 실행

3. 트랜잭션 사용이 가능한 환경이라면 꼭 BEGIN, ROLLBACK, COMMIT 구조로 안전하게 작업

트랜잭션(Transaction) 설정 및 확인 실습

현재 트랜잭션 자동 커밋 설정 확인

SHOW VARIABLES LIKE 'auto%';

• autocommit = ON 이면 각 SQL 실행 시 자동으로 커밋됨
• autocommit = OFF 이면 명시적인 COMMIT 없이는 반영되지 않음

트랜잭션 수동 커밋 모드 설정

SET autocommit = OFF;

• 이 설정은 현재 세션에만 적용됨
• 여러 쿼리를 하나의 트랜잭션처럼 묶어서 실행할 수 있음

INSERT 실습

INSERT INTO user
VALUES ('Lim',3,'kyunggi','lim@test.example.com');

SELECT * FROM user;

• 입력된 데이터 확인 가능
• 하지만 아직 COMMIT 하지 않았으므로 확정된 것은 아님

ROLLBACK 수행

ROLLBACK;

SELECT * FROM user;

• 방금 넣은 데이터는 되돌려짐 (롤백됨)

세션 종료 및 재접속 후 확인

exit

mysql -u root -p

SHOW VARIABLES LIKE 'autocommit';

• autocommit = ON (기본값으로 복귀됨)

TIP

autocommit = OFF 상태에서 실수 없이 작업하려면 다음 흐름 추천

START TRANSACTION;
-- SQL 작업들 실행
COMMIT; -- 저장
-- 또는 ROLLBACK; -- 취소

MySQL autocommit 영구 OFF 설정

설정 파일 편집

vi /etc/my.cnf

[mysqld]
autocommit = 0

• [mysqld] 섹션 아래에 autocommit = 0 추가
• 이는 MySQL 서버가 시작될 때 autocommit을 OFF 상태로 유지하게 만듦

MySQL 서비스 재시작

systemctl restart mysql

• 변경된 설정이 반영되도록 MySQL 서비스를 재시작함

MySQL 접속 후 확인

mysql -u root -p

SHOW VARIABLES LIKE 'autocommit';

• Value가 OFF로 표시되면 성공적으로 영구 설정 완료

참고

• SET autocommit = OFF; 는 현재 세션에만 일시적 적용
• my.cnf의 autocommit = 0 설정은 모든 사용자의 기본값 변경

MySQL 테이블 수정 실습 정리

테이블에 컬럼 추가

age 정수형 컬럼 추가

ALTER TABLE user ADD age INT;

level 숫자 자리수 제한(표현) 포함 컬럼 추가

ALTER TABLE user ADD level INT(5);

컬럼 삭제

ALTER TABLE user DROP level;

• level 컬럼 삭제

컬럼 타입 수정

ALTER TABLE user MODIFY email INT;

• email을 INT로 수정 (기존 값이 문자열이라면 데이터 변환 주의)

기본 키 지정

ALTER TABLE user ADD PRIMARY KEY(uid);

• uid를 기본 키로 지정

NOT NULL 제약 조건 추가

ALTER TABLE user MODIFY name VARCHAR(10) NOT NULL;

• name에 NOT NULL 제약조건 추가

UNIQUE 제약 조건 추가 시도

ALTER TABLE user MODIFY locate VARCHAR(10) UNIQUE;

• 에러 발생: 기존 데이터에 중복된 값이 존재함

해결 팁

• 중복 데이터 제거 또는 정리 후 다시 시도해야 UNIQUE 제약 조건을 적용할 수 있음

SELECT locate, COUNT(*) FROM user GROUP BY locate HAVING COUNT(*) > 1;

• 위 쿼리로 중복된 locate 확인 가능

MySQL 사용자 계정 및 권한 관리 실습

mysql 시스템 DB 사용

USE mysql;
SHOW TABLES;
DESCRIBE user;
SELECT host, user FROM user;

• mysql.user 테이블 구조 확인
• 현재 등록된 사용자 계정 리스트 확인

사용자 계정 생성

CREATE USER user01@localhost IDENTIFIED BY '123';

• user01 이라는 사용자 계정 생성 (접속 호스트는 localhost)
• 호스트는 IP 형식, %, 127.0.0.1 등으로도 지정 가능

권한 확인

DESCRIBE user;
SELECT Select_priv, user FROM user;

• 사용자의 권한 필드 확인 가능 (Select_priv, Create_priv 등)

사용자 권한 확인

SHOW GRANTS FOR user01@localhost;
SHOW GRANTS FOR root@localhost;

• 특정 사용자가 가진 권한 리스트 확인

권한 부여

• test DB의 user 테이블에 대해 SELECT, CREATE, DROP 권한 부여

GRANT SELECT, CREATE, DROP ON test.user TO user01@localhost;

SHOW GRANTS FOR user01@localhost;

권한 회수 (REVOKE)

지정한 권한만 회수 가능 (전체 회수 아님)

REVOKE CREATE, DROP ON test.user FROM user01@localhost;

SELECT 권한만 남았는지 확인

SHOW GRANTS FOR user01@localhost;

MySQL 데이터베이스 백업 & 복원

백업 (Dump)

mysqldump -u root -p test > test.dump

• test 데이터베이스를 백업하여 test.dump 파일로 저장

• -u root -p : root 사용자로 비밀번호 입력 후 접속

테이블 삭제 테스트

mysql -u root -p

USE test;
SHOW TABLES;

DROP TABLE user;

SHOW TABLES;
exit;

• 백업 테스트를 위해 user 테이블 삭제

백업 파일로 복원

mysql -u root -p test < test.dump

• test.dump 파일을 test 데이터베이스에 덮어쓰기
• 삭제되었던 user 테이블이 복구됨

복원 확인

mysql -u root -p

USE test;
SHOW TABLES;

• user 테이블이 다시 존재하는지 확인

통합 시스템 설정 실습

1. root 비밀번호 설정

passwd root

• 비밀번호로 cccr1234 입력

2. GRUB 타이머 10초 설정

vim /etc/default/grub

• GRUB_TIMEOUT=10 으로 수정

grub2-mkconfig -o /boot/grub2/grub.cfg

3. eth1 고정 IP 설정

nmcli con add con-name static1 ifname eth1 type ethernet ip4 192.168.56.211/24 nmcli con up static1

4. 인터넷 repo 설정

cd /etc/yum.repos.d/ mkdir backup mv *.repo backup/

vim net.repo

[NET_BaseOS]
name=BaseOS
baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

[NET_AppStream]
name=AppStream
baseurl=http://dl.rockylinux.org/$contentdir/$releasever/AppStream/$basearch/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

dnf makecache

5. /dev/sdb 파티션 (4,4,6,6)

fdisk /dev/sdb

• n → primary → +4G, +4G, +6G, +6G
• w로 저장

partprobe lsblk

6. 포맷 및 마운트

mkfs.xfs /dev/sdb1 mkdir /mnt1 mount /dev/sdb1 /mnt1 vim /etc/fstab /dev/sdb1 /mnt1 xfs defaults 0 0

mkswap /dev/sdb2 swapon /dev/sdb2 echo "/dev/sdb2 swap swap defaults 0 0" >> /etc/fstab

7. LVM 설정

pvcreate /dev/sdb3 /dev/sdb4 vgcreate vg0 /dev/sdb3 /dev/sdb4 lvcreate -n lv01 -L 4G vg0 mkfs.xfs /dev/vg0/lv01 mkdir /home1 echo "/dev/vg0/lv01 /home1 xfs defaults 0 0" >> /etc/fstab mount -a

8. lv01 확장

lvextend -L +2G /dev/vg0/lv01 xfs_growfs /home1

9. 사용자 default home 디렉토리 변경

vim /etc/default/useradd

• HOME=/home1 으로 변경

10. user01 생성 + sudo 권한

useradd user01 passwd user01 usermod -aG wheel user01

11. 그룹 및 디렉토리 설정

groupadd sggroup mkdir -p /ptest/dir01 /ptest/dir02 chgrp sggroup /ptest/dir01 chmod 2775 /ptest/dir01

12. cron 등록

crontab -e -u user01 0 17 31 1 * date >> /ptest/dir02/datefile

13. httpd 설치 및 활성화

dnf install -y httpd systemctl enable httpd --now

web 실습

Apache 가상 호스트 설정 (HTTP 기반)

설정 파일 위치

/etc/httpd/conf.d/

가상 호스트 vhost0

vi /etc/httpd/conf.d/00-vhost.conf

<VirtualHost *:80>
    DocumentRoot /var/www/html0
    ServerName vhost0.cccr1.org
    ServerAlias vhost0
</VirtualHost>

<Directory /var/www/html0>
    AllowOverride None
    Require all granted
</Directory>

mkdir /var/www/html0 echo vhost0 > /var/www/html0/index.html

가상 호스트 vhost1

vi /etc/httpd/conf.d/01-vhost.conf

<VirtualHost *:80>
    DocumentRoot /var/www/html1
    ServerName vhost1.cccr1.org
    ServerAlias vhost1
</VirtualHost>

<Directory /var/www/html1>
    AllowOverride None
    Require all granted
</Directory>

mkdir /var/www/html1 echo vhost1 > /var/www/html1/index.html

/etc/hosts 에 가상호스트 도메인 매핑

vi /etc/hosts

192.168.56.100    server.cccr1.org  vhost0.cccr1.org  vhost0  vhost1.cccr1.org  vhost1

httpd 서비스 시작 및 방화벽 설정

systemctl start httpd

firewall-cmd --add-service=http --permanent firewall-cmd --reload

정상 동작 확인

curl server.cccr1.org curl vhost0 curl vhost1

HTTPS 리다이렉션 설정

방법 1: 간단한 리다이렉트

RewriteEngine on RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]

방법 2: 다양한 조건에 따른 리다이렉트

RewriteEngine on RewriteMap lowercase int:tolower

RewriteCond "${lowercase:%{HTTPS}}" !on RewriteCond "${lowercase:%{REQUEST_SCHEME}}" !https RewriteCond "${lowercase:%{SERVER_PORT}}" !443

RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]

• 위 조건이 하나라도 만족되면, HTTPS로 강제 리다이렉션이 수행됨

HTTPS 실습

SSL 관련 패키지 설치 및 인증서 생성

yum -y install mod_ssl

openssl genrsa -out private.key 2048 openssl req -new -key private.key -out cert.csr openssl x509 -req -signkey private.key -in cert.csr -out cert.crt

chmod 600 private.key cert.crt mv private.key /etc/pki/tls/private/ mv cert.* /etc/pki/tls/certs/

Apache SSL 설정 수정 (/etc/httpd/conf.d/ssl.conf)

vi /etc/httpd/conf.d/ssl.conf

수정 포인트

• DocumentRoot "/var/www/html" → 제거
• ServerName server.cccr1.org:443 → 추가 또는 수정
• SSLCertificateFile → /etc/pki/tls/certs/cert.crt
• SSLCertificateKeyFile → /etc/pki/tls/private/private.key

HTTP → HTTPS 리다이렉션 설정 (가상호스트)

/etc/httpd/conf.d/00-vhost.conf

<VirtualHost *:80>
    DocumentRoot /var/www/html0
    ServerName vhost0.cccr1.org
    ServerAlias vhost0
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<Directory /var/www/html0>
    AllowOverride None
    Require all granted
</Directory>

/etc/httpd/conf.d/01-vhost.conf

<VirtualHost *:80>
    DocumentRoot /var/www/html1
    ServerName vhost1.cccr1.org
    ServerAlias vhost1
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<Directory /var/www/html1>
    AllowOverride None
    Require all granted
</Directory>

Apache 서비스 재시작 및 방화벽 설정

systemctl restart httpd

firewall-cmd --add-service=https --permanent firewall-cmd --reload

안정적인 점수로 합격했다.

케이블은 귀찮아서 하지 않았다.

단답형의 경우, 85%정도 기존에 알고있었던 지식에서 나왔다.

라우터 문제는 show명령, telnet 관련 문제, ip add 관련 문제가 나와 쉽게 풀었다.

25-1회 윈도우 설정 문제에서는 세부 조건들이 많이 나왔기 때문에, 애뮬레이터로 연습할 때 꼼꼼하게 살펴보며 연습하면 좋을 것 같다.

패키지 실습

DVD 마운트 및 repo 설정

umount /dev/cdrom mkdir /media/cdrom mount /dev/cdrom /media/cdrom

기존 .repo 파일들 백업

cd /etc/yum.repos.d/ mkdir backup mv *.repo backup/

DVD와 인터넷 repo 동시 사용을 위한 test.repo 구성 예시

[DVD_BaseOS]
name=dvd-baseos
baseurl=file:///media/cdrom/BaseOS/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

[DVD_AppStream]
name=dvd-appstream
baseurl=file:///media/cdrom/AppStream/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

[NET_BaseOS]
name=network-baseos
baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

dnf makecache dnf repolist all

패키지 설치/삭제

zsh 설치/삭제 (RPM 직접 설치)

rpm -ivh /media/cdrom/BaseOS/Packages/z/zsh-5.8-9.el9.x86_64.rpm rpm -e zsh

ksh 설치/삭제 (YUM 사용)

dnf install ksh -y dnf remove ksh -y

zsh 설치 (YUM + ISO rpm)

dnf localinstall /media/cdrom/BaseOS/Packages/z/zsh-5.8-9.el9.x86_64.rpm

Security Tools & httpd

그룹 패키지 확인/설치/삭제

dnf group list dnf group info "Security Tools" dnf group install "Security Tools" dnf group remove "Security Tools"

/var/www 디렉토리 생성한 패키지 확인

dnf provides /var/www

httpd 관련 실습

dnf install httpd -y rpm -qc httpd # 설정 파일 확인 rpm -qd httpd # 문서 파일 확인 dnf info httpd # 패키지 정보 확인

httpd 서비스 제어

systemctl start httpd systemctl enable httpd

systemctl stop httpd systemctl disable httpd

httpd 삭제 및 재설치 (무응답 설치)

dnf remove httpd -y dnf install httpd -y

네트워크 실습

초기 설정 및 IP 확인

모든 인터페이스 IP 확인

ip addr ifconfig

특정 인터페이스만 확인 (예: eth0 또는 enp0s3)

ip addr show eth0 ifconfig eth0

연결 생성

유동 IP 연결 생성 (DHCP)

nmcli con add con-name dhcp1 ifname eth0 type ethernet

고정 IP 연결 생성 (STATIC)

nmcli con add con-name static1 ifname eth0 type ethernet ip4 192.168.56.200/24 gw4 192.168.56.1 ipv4.method manual

• ipv4.method manual을 꼭 추가해야 고정 IP로 설정됨

연결 수정

dhcp1 → static100 변경 + 고정 IP로 수정

nmcli con mod dhcp1 \
connection.id static100 \
ipv4.addresses 192.168.56.150/24 \
ipv4.gateway 192.168.56.1 \
ipv4.dns 8.8.8.8 \
connection.autoconnect no \
ipv4.method manual

static1 → dhcp2 변경 + 유동 IP로 수정

nmcli con mod static1 \
connection.id dhcp2 \
ipv4.method auto \
ipv4.addresses "" \
ipv4.gateway ""

호스트네임 변경

hostnamectl hostname servera.cccr.org

변경 확인

hostname

SSH(Secure Shell)

SSH란?

• 원격 서버에 암호화된 통신으로 접속할 수 있도록 해주는 보안 프로토콜
• telnet은 평문 전송 (보안 없음)
• ssh는 암호화 전송 (보안 있음)

암호화 방식

대칭키 (Symmetric Key)

• 같은 키로 암호화/복호화
• 빠르지만, 키가 노출되면 위험

비대칭키 (Asymmetric Key)

• 공개키(암호화) + 개인키(복호화) 한 쌍
• 공개키는 누구나 공유 가능
• 개인키는 나만 보관

SSH 접속 원리

1. 클라이언트가 서버에 접속 요청
2. 서버가 공개키 전달
3. 클라이언트가 대칭키(비밀키) 생성
4. 클라이언트는 이 대칭키를 서버의 공개키로 암호화하여 전송
5. 서버는 개인키로 복호화하여 대칭키 획득
6. 이후 통신은 대칭키로 암호화된 채 전송됨

• 접속 후 통신은 대칭키 방식 → 빠르고 보안 유지 가능

SSH 인증 방식

일반 인증 (ID + PW 입력)

• 원격 접속 시 매번 패스워드 입력 필요

키 기반 인증 (더 안전 & 자동화 가능)

• 클라이언트에서 해야 할 작업 ssh-keygen

• 공개키 (id_rsa.pub) + 개인키 (id_rsa) 생성됨 ssh-copy-id 사용자명@서버IP

• 서버에 공개키 등록 (~/.ssh/authorized_keys)

-> 이제 비밀번호 없이 SSH 접속 가능

기억하면 좋은 명령어

ssh 접속

ssh 사용자명@서버IP

키 생성

ssh-keygen

공개키 복사

ssh-copy-id 사용자명@서버IP

SSH 실습

네트워크 설정

클라이언트 (Client)

nmcli con add con-name static-client type ethernet ifname eth1 ip4 192.168.56.200/24 ipv4.method manual

서버 (Server)

nmcli con add con-name static-server type ethernet ifname eth1 ip4 192.168.56.150/24 ipv4.method manual

사용자 생성 및 활성화

클라이언트

useradd cuser passwd cuser

서버

useradd suser passwd suser

일반 SSH 접속 테스트

클라이언트(cuser)에서 서버(suser)로 SSH 접속

ssh suser@192.168.56.150 exit

공개키/개인키 관련 확인

클라이언트

vim ~/.ssh/known_hosts

서버

vim /etc/ssh/ssh_host_rsa_key.pub

• 두 파일의 fingerprint는 일치해야 정상 상태

서버 공개키 제거 & 재생성

rm -rf /etc/ssh/ssh_host* systemctl restart sshd ls /etc/ssh/

• 공개키가 재생성되면서 클라이언트와 fingerprint가 불일치하게 됨

클라이언트에서 등록된 키 제거 후 재접속

rm -rf ~/.ssh/known_host* ssh suser@192.168.56.150 exit

• 새 서버 공개키를 다시 등록하게 됨

암호 없이 로그인 (키 기반 인증 설정)

클라이언트 (cuser)

ssh-keygen # 엔터 3번 ssh-copy-id suser@192.168.56.150

• 이제부터는 cuser → suser 접속 시 암호 없이 로그인 가능

root 계정 SSH 접속 차단

서버

vim /etc/ssh/sshd_config

PermitRootLogin no # 설정 확인 또는 추가

systemctl restart sshd

• 이제 root는 SSH로 접속할 수 없음

요약

연결 상태 확인: nmcli con show IP 설정 확인: ip addr show eth1 서버 공개키: cat /etc/ssh/ssh_host_rsa_key.pub 클라 서버 키 등록: cat ~/.ssh/known_hosts 암호 없이 로그인 테스트: ssh suser@192.168.56.150

firewalld

firewalld 개요

• 리눅스 방화벽 서비스
• 동적(Dynamic) 구성 가능
• iptables보다 현대적이며 유연함

구성 흐름

Netfilter(Kernel)
  ↳ iptables → iptables.service
  ↳ firewalld → firewall-cmd / firewall-config (GUI)

구성 요소

Zone: 네트워크 신뢰 수준 Service: 허용할 서비스 (ssh, http 등) Port: 포트 기반 접근 허용 IP(Source): 접근 가능한 IP 제한 Interface: 네트워크 장치를 특정 Zone에 연결

Zone 종류 (사전 정의됨)

drop: 모든 수신 DROP (ICMP 응답도 없음) block: 모든 수신 REJECT (ICMP 거절) external: 외부에서 SSH만 허용 internal / home: 내부망 접근 허용 (SSH, DHCP 등) public(기본): SSH만 허용된 공개망 trusted: 모든 트래픽 허용 work: 제한적 허용 (SSH, DHCPv4 등)

주요 명령어 (firewall-cmd)

--state firewalld: 상태 확인 --get-default-zone: 현재 기본 zone 확인 --set-default-zone=ZONE: 기본 zone 변경 --get-zones: 사용 가능한 zone 전체 보기 --get-active-zones: 활성화된 zone + 인터페이스 확인 --get-services: 등록된 서비스 목록 보기 --list-all --zone=ZONE: zone에 구성된 모든 규칙 보기

설정 예시

IP 소스 추가

firewall-cmd --zone=public --add-source=192.168.56.0/24

인터페이스 추가

firewall-cmd --zone=internal --add-interface=eth1

서비스 허용

firewall-cmd --zone=public --add-service=http

포트 허용

firewall-cmd --zone=public --add-port=8080/tcp

영구 설정

--permanent

변경사항 적용

firewall-cmd --reload

런타임 설정을 영구 설정으로 저장

firewall-cmd --runtime-to-permanent

Firewalld 실습 (NFS + HTTP 구성)

서버 초기화 후 필수 패키지 설치

dnf -y install nfs-utils dnf -y install httpd

서비스 시작 & 활성화

systemctl enable nfs-server --now systemctl enable httpd --now systemctl status nfs-server

홈 zone에 포트 / 프로토콜 / 서비스 추가 (영구 설정)

포트 허용 (NFS, HTTP 관련) firewall-cmd --add-port=80/tcp --add-port=111/tcp --add-port=2049/udp --add-port=20048/tcp --permanent --zone=home

프로토콜 허용 (ICMP 허용) firewall-cmd --add-protocol=icmp --permanent --zone=home

** 서비스 허용 (NFS)** firewall-cmd --add-service=nfs --permanent --zone=home

변경사항 적용 firewall-cmd --reload

zone 확인 및 default zone 변경

firewall-cmd --list-all --zone=home firewall-cmd --set-default-zone=home

웹서버 구성

고정 IP 설정 nmcli con add con-name xxx ifname eth1 type ethernet ip4 "192.168.56.100/24" nmcli con up xxx

확인 nmcli con show nmcli con show xxx ip addr show eth1

테스트용 페이지 생성

echo "this is Rocky" > /var/www/html/index.html

클라이언트 접속 테스트

브라우저 or curl 사용

http://192.168.56.100/index.html

→ "this is Rocky" 출력 확인

systemd 실습(sshd 서비스)

1. sshd 서비스 상태 확인

systemctl status sshd

• 서비스 활성 상태 / 실행 상태 / PID / 로그 정보 확인

2. sshd 서비스 시작

systemctl start sshd systemctl status sshd

• 실제 프로세스가 실행되는지 확인 (PID 발생)

3. sshd 서비스 부팅 시 자동 시작 설정 (활성화)

systemctl enable sshd systemctl list-unit-files | grep sshd

• enabled로 바뀌었는지 확인

4. sshd 서비스 중지

systemctl stop sshd systemctl status sshd

• Active: inactive (dead) 상태로 전환되는지 확인

5. sshd 서비스 비활성화 (부팅 시 자동 실행 해제)

systemctl disable sshd systemctl list-unit-files | grep sshd

• 상태가 disabled로 바뀌는지 확인

6. sshd 서비스 잠금 (mask)

systemctl mask sshd systemctl status sshd

• 상태: masked
• 이제 start 명령어로도 실행 불가

7. sshd 서비스 잠금 해제 (unmask)

systemctl unmask sshd systemctl status sshd

• 다시 start 가능

8. sshd 서비스 시작 후 PID 확인

systemctl start sshd systemctl status sshd

• Main PID: xxxx → PID 기억해두기

9. sshd 서비스 리로드 후 PID 확인 (변화 없음)

systemctl reload sshd systemctl status sshd

• PID 변화 없어야 정상

10. sshd 서비스 재시작 후 PID 확인 (변화 있음)

systemctl restart sshd systemctl status sshd

• PID 변화해야 정상 (프로세스 재시작)

추가

• reload: 설정 파일만 다시 읽음 (프로세스 그대로 유지)
• restart: 완전 재시작 (PID 변경)
• mask: 완전 실행 금지 → /dev/null로 링크

log 실습

목표

1. auth 기능에서 crit 이상 로그만 /var/log/securetest에 기록 2. logger로 auth.error, auth.crit 메시지 테스트 3. journalctl에서 notice 이상 + err 이상 로그 보기

*1. rsyslog 설정 변경 *

vim /etc/rsyslog.conf

#### RULES #### 아래에 다음 한 줄 추가

auth.crit /var/log/securetest

의미

• auth facility에서 crit 이상인 로그만 /var/log/securetest에 기록됨
• auth.error는 기록되지 않음, auth.crit은 기록됨

설정 적용

systemctl restart rsyslog

2. logger 명령어로 로그 발생 테스트

logger -p auth.error "auth.error 메시지입니다" logger -p auth.crit "auth.critical 메시지입니다"

로그 확인

tail -n 5 /var/log/secure → 둘 다 기록됨 (auth.error, auth.crit)

tail -n 5 /var/log/securetest → 오직 auth.crit만 기록됨

3. journalctl 우선순위 필터링

• notice(5) 이상 (즉, notice, warn, err, crit, alert, emerg) journalctl -p notice

• err(3) 이상 (즉, err, crit, alert, emerg) journalctl -p err

실시간으로 모니터링하려면?

journalctl -p err -f

RPM 패키지 관리

1. 패키지 정보 확인

rpm -q [옵션] [패키지명]

-a: 시스템에 설치된 모든 패키지 -i: 패키지의 상세 정보 (설명, 버전, 설치일 등) -c: 설정 파일 목록 -d: 문서 목록 -l: 설치된 파일 목록 -f 파일명: 해당 파일이 어떤 패키지에 속하는지

2. 패키지 설치 / 업데이트 / 삭제

• 설치 또는 업그레이드 rpm -Uvh 패키지파일.rpm

• 삭제 rpm -e 패키지명

• .rpm 파일은 로컬에 있어야 함

YUM (또는 DNF) – 의존성 자동 처리

1. 기본 명령어

yum install 패키지명 yum remove 패키지명 yum update 패키지명 yum info 패키지명 yum list yum provides /경로/파일명

yum repolist all # 사용 가능한 저장소 목록 보기

2. 그룹 패키지 관리

yum group list yum group install "개발 도구" yum group remove "서버 플랫폼 개발" yum group info "보안 도구"

3. 로컬 패키지 설치 (의존성 포함)

yum localinstall 패키지.rpm

YUM Repository 설정

예시 /etc/yum.repos.d/base.repo

# 예시 /etc/yum.repos.d/base.repo

[BaseOS]
name=RockLinux BaseOS
baseurl=http://mirror.rocklinux.com/BaseOS/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-RockLinux

metadata_expire=6h

[ID명]: 저장소 식별자 name: 저장소 설명 baseurl: 저장소 주소 (http, ftp, file://) enabled: 1=활성화 / 0=비활성화 gpgcheck: 패키지 인증 여부 gpgkey: 인증 키 경로 metadata_expire: 메타데이터 만료시간

AppStream vs BaseOS

BaseOS: 핵심 시스템 구성 (커널, 부트 등) AppStream: DB, 웹서버, 개발도구 등 자주 업데이트되는 앱들

캐시 다시 만들기

dnf makecache

패키지 실습

1. DVD 마운트 & 준비

umount /dev/cdrom mkdir -p /media/cdrom mount /dev/cdrom /media/cdrom lsblk # 마운트 확인

2. Repository 설정

cd /etc/yum.repos.d/ mkdir backup mv rocky* backup/

vim test.repo

[NET_BaseOs]
name=network-baseos
baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/os/`
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

[NET_AppStream]
name=network-appstream
baseurl=http://dl.rockylinux.org/$contentdir/$releasever/AppStream/$basearch/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

3. 캐시 재생성 & 저장소 확인

dnf makecache dnf repolist all

4. NET_AppStream 비활성화

vim test.repo

[NET_AppStream]
...
enabled=0

dnf repolist all # 비활성화 확인

5. telnet 관련 패키지 검색

dnf list | grep telnet

6. telnet 패키지 설치 & socket 활성화

dnf install telnet* systemctl enable telnet.socket --now

텔넷이 다운되어있지 않다면? vim test.repo

[NET_AppStream]
...
enabled=1

dnf install telnet-server

[NET_AppStream]
...
enabled=0

7. telnet 설정파일 & 문서 확인

rpm -qc telnet # config files rpm -qd telnet # doc files

8. rsyslog.conf가 어떤 패키지에서 나왔는지 확인

rpm -qf /etc/rsyslog.conf dnf provides /etc/rsyslog.conf

9. rsyslog 패키지 정보 확인

rpm -qi rsyslog dnf info rsyslog

10. Security 관련 그룹 패키지 찾기

dnf group list | grep -i security

→ 예시 결과: Security Tools or 보안 도구

11. 해당 그룹의 상세 정보 확인

dnf group info "Security Tools"

12. zsh RPM 파일 yum으로 설치

dnf localinstall /media/cdrom/BaseOS/Packages/z/zsh-5.8-9.el9.x86_64.rpm

네트워크 설정

네트워크 상태 확인

ip addr
ip addr show 인터페이스명 ifconfig
ifconfig 인터페이스명

nmcli 명령어 정리

기본 명령

nmcli device: 장치(device) 목록 확인 nmcli con show: 현재 연결 목록 확인 nmcli con show 연결명: 연결 상세 설정 보기 nmcli con add ...: 연결 생성 nmcli con mod ...: 연결 수정 nmcli con delete ...: 연결 삭제 nmcli con up 연결명: 연결 활성화 nmcli con down 연결명: 연결 비활성화 nmcli con reload: 연결 설정 재적용

연결 생성 실습

유동 IP 설정 (DHCP 방식)

nmcli con add \ con-name dhcp7 \ ifname enp0s7 \ type ethernet \ autoconnect yes

• ipv4.method 자동 설정 → auto

고정 IP 설정 (Static 방식)

nmcli con add \ con-name static7 \ ifname enp0s7 \ type ethernet \ autoconnect no \ ip4 10.100.5.100/24 \ gw4 10.100.5.2 \ ipv4.method manual

• 주의: ipv4.method manual 반드시 포함

연결 상태 확인

nmcli con show static7

• 주요 항목 예시
• connection.autoconnect: yes / no
• ipv4.method: auto / manual
• ipv4.addresses, ipv4.gateway

연결 수정 실습

DHCP → 고정 IP 변경

nmcli con mod dhcp7 \ connection.id static7-1 \ ipv4.method manual \ ipv4.addresses 10.100.5.200/24 \ ipv4.gateway 10.100.5.2 \ ipv4.dns 10.100.5.100

고정 IP → DHCP 변경

nmcli con mod static7 \ connection.id dhcp7-1 \ ipv4.method auto \ ipv4.addresses "" \ ipv4.gateway "" \ ipv4.dns "8.8.8.8 10.100.5.100" \ connection.autoconnect yes

호스트명 설정

hostname: 현재 호스트명 확인 cat /etc/hostname: 설정된 호스트명 파일 확인 hostnamectl set-hostname 새이름: 호스트명 변경

추가

• 연결 이름 바꿀 때는 connection.id 사용
• 연결 삭제는 nmcli con delete 연결명
• 설정 후 nmcli con up 연결명 으로 적용

기억하면 좋은 포인트

• ipv4.method manual → 꼭 고정 IP 설정에 필요
• ip4, gw4 → IP와 게이트웨이 주소 설정
• 연결 수정 시 DNS 추가는 ipv4.dns
• 연결 비활성화 상태라도 수동 up 가능
• nmcli con reload로 설정 리로드

네트워크 실습

현재 IP 주소 확인 (2가지 방법)

전체 IP 확인

ifconfig ip addr

특정 인터페이스(eth2) 확인

ifconfig eth2 ip addr show eth2

연결 생성 with nmcli con add

1. 유동 IP 연결 생성 (DHCP 방식)

nmcli con add con-name dhcp type ethernet ifname eth2

2. 고정 IP 연결 생성 (Static 방식)

nmcli con add \ con-name static2 \ type ethernet \ ifname eth2 \ ip4 192.168.56.200/24 \ gw4 192.168.56.1

연결 수정 with nmcli con mod

기존 dhcp 연결을 다음과 같이 수정

• 이름: static으로 변경
• IP: 192.168.56.120/24 설정
• 추가 IP: 192.168.56.30/24
• DNS: 8.8.8.8
• 자동 연결 해제
• method: manual로 변경

nmcli con mod dhcp \ connection.id static \ ipv4.addresses 192.168.56.120/24 \ ipv4.gateway 192.168.56.1 \ +ipv4.addresses 192.168.56.30/24 \ ipv4.dns 8.8.8.8 \ connection.autoconnect no \ ipv4.method manual

특정 주소 제거 (예: 192.168.56.120/24)

nmcli con mod static -ipv4.addresses 192.168.56.120/24

호스트명 변경

hostnamectl hostname nobreak.com

변경확인

hostname

요약

IP 전체 확인: ip addr / ifconfig eth2 확인: ip addr show eth2 DHCP 연결 생성: nmcli con add con-name dhcp ... Static 연결 생성: nmcli con add con-name static2 ... 연결 이름/속성 변경: nmcli con mod ... 주소 제거: nmcli con mod static -ipv4.addresses 주소/넷마스크 호스트명 설정: hostnamectl hostname 호스트명