컴퓨트·스토리지·네트워크 자원풀

가상머신·컨테이너·하이퍼바이저의 논리자원과 물리자원 구분, 입력·처리·출력·상태·피드백의 관측·조정이 선수 설명이다.

0. 서버 목록을 서비스 구조로 바꾸는 법

인프라를 서버 몇 대, 디스크 몇 테라바이트로만 보면 각 장비는 알 수 있어도 서비스가 어떻게 자원을 얻고, 어디에 배치되며, 고장 뒤 어떻게 다시 살아나는지는 설명하지 못한다. 현대 인프라는 서로 다른 컴퓨트·스토리지·네트워크 자원을 논리적인 공급능력으로 묶고, 정책에 따라 워크로드에 배분하는 시스템이다.

초보자가 먼저 잡아야 할 질문은 네 가지다. 무엇을 풀로 묶는가, 누가 원하는 상태를 결정하는가, 실제 요청과 입출력은 어디서 처리되는가, 논리적으로 약속한 양이 물리적으로 감당 가능한가다. 이 질문을 순서대로 연결하면 클라우드, 소프트웨어 정의 데이터센터, 하이퍼컨버지드 인프라처럼 이름이 다른 구조도 같은 원리로 읽을 수 있다.

인프라 아키텍처: 자원·제어·운영 결정을 서비스 요구에 묶는다

인프라 아키텍처(infrastructure architecture)는 서비스를 실행하는 컴퓨트·스토리지·네트워크·시설 자원과, 이를 연결·배치·보호·관찰·복구하는 제어구조를 품질목표에 맞게 조직한 설계다. 장비 제품명이나 구성도만을 뜻하지 않는다.

아키텍처에는 적어도 다음 결정이 들어간다.

1. 서비스와 관리영역의 경계는 어디인가.
2. CPU·메모리·저장용량·네트워크 대역을 어떤 할당 단위로 제공하는가.
3. 원하는 상태를 누가 결정하고 실제 상태를 어떻게 수렴시키는가.
4. 워크로드를 어떤 제약·용량·장애경계에 따라 배치하는가.
5. 성능·가용성·보안·비용을 어떤 지표와 한도로 검증하는가.

따라서 가상화했다는 사실만으로 좋은 인프라가 되지 않는다. 할당과 회수, 장애격리, 관측, 변경과 복구까지 연결되어 있어야 한다.

전체에서 어디인가: 요구가 실행 중 서비스가 되기까지

서비스의 성능·가용성·보안·비용·복구 요구를 경계·표준·할당단위·배치정책·장애영역으로 바꾼다. 결정·조정 경로는 요청→승인→배치→수렴이며 계산·저장·통신 공급능력에 할당을 명령한다. 실제 처리 경로는 실행·I/O·통신이다. 관측·조정·회수·복구가 실제 상태와 용량을 결정 경로에 돌려보낸다. 일곱 단계 할당, 실제 수렴 사례, 세 자원의 다른 단위를 함께 사용한다.

결정·조정 경로는 어디에 얼마를 둘지 결정하고 실제 상태가 그 결정에 가까워지도록 명령한다. 실제 처리 경로는 배치된 워크로드가 사용자 요청, 패킷, 블록·파일·객체 입출력을 실제 처리한다. 이어지는 절에서 공급능력의 묶음과 두 경로에 정식 이름을 붙이고, 네트워크 장비에서 쓰는 유사한 구분과 범위를 나눈다.

먼저 알아둘 것

이해관계자의 필요는 검증 가능한 요구로 바뀌고, 기능·품질속성·제약의 구분은 인프라가 무엇을 어느 수준으로 제공해야 하는지 정한다. 모델·관점은 계산·저장·네트워크와 운영책임을 이해관계자별로 보여 주고, 아키텍처 결정은 선택근거·절충·검증을 남긴다. 앞 절의 가상화는 물리자원을 논리 사용단위로 바꾸며, 지연·처리량·대역폭은 그 단위를 공유할 때 반드시 함께 확인할 품질 기준이다.

1. 자원풀: 장비를 할당 가능한 공급능력으로 본다

인프라 자원풀(infrastructure resource pool)은 컴퓨트·스토리지·네트워크 자원을 특정 물리장치의 이름이 아니라 요청·할당·회수할 수 있는 논리 용량의 집합으로 관리하는 구조다. 풀은 무한한 양동이가 아니다. 물리용량, 예약분, 장애조치 예비분, 성능 한도와 위치 제약을 가진다.

자원풀의 핵심은 합쳐 보인다가 아니라 할당계약이다. 계약에는 자원 종류와 양, 최소보장과 최대한도, 위치·보안·장애영역 제약, 지속시간, 우선순위, 회수조건이 포함된다. 용량 숫자가 같아도 CPU 세대, 메모리 접근거리, 저장매체 지연, 네트워크 경로가 다르면 동질적인 풀로 취급할 수 없다.

세 자원은 같은 단위로 더할 수 없다

CPU 준비시간(CPU ready time)은 실행할 수 있는 가상 CPU가 물리 CPU를 배정받지 못해 기다린 시간이다. CPU 8개와 저장공간 1TB처럼 서로 다른 차원의 자원을 하나의 총량으로 합치지 않는다. 워크로드가 요구하는 각 차원과 병목을 벡터처럼 보고, 하나라도 부족하면 배치할 수 없다고 판단한다.

저장용량·IOPS·처리량은 세 개의 다른 조건으로 계산한다. 사용 가능한 용량이 2TiB인 풀에 1TiB 자료를 두고, 입출력 상한이 10,000IOPS와 100MiB/s라고 하자. 예제에서는 모든 작업 크기가 같고 분할·병합, 캐시 적중, 메타데이터 비용을 무시한다. 작업당 8KiB라면 10,000×8/1024=78.125MiB/s로 처리량 상한 안에 있지만, 작업당 64KiB라면 같은 IOPS에 625MiB/s가 필요하다. 후자의 처리량 상한에 따른 작업 수 상한은 100×1024/64=1,600IOPS다. 따라서 이 단순 모델의 실제 작업 수는 IOPS 상한과 처리량에서 환산한 상한 중 작은 값 이하여야 한다. 용량이 남는다는 사실만으로 10,000IOPS를 달성하는 것은 아니다. 이 숫자는 제품 사양이 아닌 저자의 단위 계산 예이며, 실제 저장장치에서는 지연·대기열·호스트 경로·작업 크기와 읽기/쓰기 혼합을 측정해야 한다. AWS의 공식 저장 성능 설명도 I/O 특성과 호스트 구성에 따라 성능이 달라짐을 구분한다.

요청부터 회수까지: 자원풀의 일곱 단계

1. 요청: 워크로드가 필요한 자원량·한도·위치·보호등급을 선언한다.
2. 승인: 정책과 쿼터, 보안·비용 한도를 검사한다.
3. 선별: 요구조건을 만족할 수 없는 후보 노드를 제거한다.
4. 배치: 남은 후보를 여유용량·지역성·분산·비용 점수로 정렬한다.
5. 할당: 논리자원과 네트워크·스토리지 연결을 만들고 실행을 시작한다.
6. 관측·수렴: 실제 사용량과 상태를 보고 원하는 상태와 다르면 재시도·재배치·확장한다.
7. 회수: 종료·만료·축소 때 자원과 연결, 임시 데이터, 주소를 정리해 풀로 돌려보낸다.

중간 단계는 실패할 수 있다. 일부 자원만 만들어진 채 네트워크 연결이 실패하거나, 제어면은 성공을 기록했지만 실제 노드가 명령을 받지 못할 수 있다. 그래서 각 작업은 식별자와 상태를 가지고 반복 실행해도 결과가 중복 생성되지 않도록 설계하고, 관측된 실제 상태로 재조정해야 한다. 멱등성(idempotence)은 같은 식별자의 동일한 작업을 반복해도 한 번 수행한 것과 같은 효과를 유지하는 성질이다. 응답 유실 뒤 재시도가 새 자원을 만드는지 실제 상태로 확인한다. 앞 단계에서 이미 만든 자원은 되돌리거나 같은 효과를 상쇄하는 보상조치로 정리하고, 자동 복구가 불가능하면 남은 자원과 수동 절차를 명시한다.

같은 식별자를 보내는 것만으로 중복 방지가 완성되지는 않는다. 아래 B 생성 사례에서 재시도를 안전하게 만들려면, 서비스가 같은 호출자의 작업 식별자와 원래 매개변수·처리 상태·결과 자원 B의 대응을 보존해야 한다. 식별자 확인과 자원 생성이 따로 실패할 수 있으면 B는 생성했지만 처리 기록은 없음 상태에서 재시도가 B를 또 만들 수 있다. 따라서 중복 요청이 동시에 와도 같은 작업으로 묶이는 처리와 기록의 일관성을 설계한다. 같은 식별자로 크기 등 매개변수를 바꾸는 요청은 원래 작업의 재시도로 조용히 받아들이지 말고 불일치를 처리해야 한다. 기록 보존기간이 끝난 늦은 요청의 정책도 계약에 포함한다. AWS Builders’ Library의 멱등 API 설명은 이런 호출자 식별·기록 일관성·매개변수 불일치와 늦은 재시도 문제를 구체적으로 다룬다. 이 조건이 갖추어져야 그림의 같은 B 확인이 새로운 C 생성과 구별된다.

2. 제어면과 데이터면: 결정 경로와 실제 처리 경로를 나눈다

인프라 제어면(control plane)은 원하는 상태, 자원 할당과 배치정책을 결정·전달하고 실제 상태를 그 목표로 수렴시키는 논리 기능이다. 인프라 데이터면(data plane)은 배치된 워크로드가 사용자 요청·패킷·저장 입출력을 실제 처리하는 실행 경로다.

둘은 책임의 구분이지 반드시 서로 다른 제품이나 물리망이어야 한다는 뜻은 아니다. 제어면이 잠시 중단되어도 이미 실행 중인 데이터면이 계속 처리할 수 있는 구조가 있고, 반대로 정책 갱신·새 배치·복구는 멈출 수 있다. 따라서 두 면의 가용성 목표와 실패영향을 따로 분석한다.

원하는 상태와 실제 상태 사이를 계속 좁힌다

응답 유실 뒤 새 C를 만들지 않고 B를 확인한다 · 상태 따라가기

목표 2와 관측 1의 차이를 맞추려 한다. 모든 단계에서 목표·관측·실제 자원의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

넓은 화면과 모바일에서 같은 관계를 각각의 배치로 읽을 수 있습니다.

시간은 위에서 아래로 진행한다. 처음 선언은 2, 관측은 1이므로 B 생성을 요청한다. 실제 노드가 B를 생성했지만 응답이 유실되어 제어면은 오래된 1을 가지고 있다. 새 이름 C를 생성하면 실제 3이 되므로 같은 B 식별자로 결과를 확인하고 실제 A·B=2로 관측을 갱신한다. 점선 응답은 확인 요청의 반환이며 유실된 응답은 새로운 UML lost-message 화살표 대신 노드 상태 주석으로 표시했다. 선언→정책·승인→배치·명령, 노드·저장·망의 상태수집→관측→비교·재조정 루프가 이 사례의 근거이며 데이터면의 요청·패킷·I/O 처리는 따로 진행한다.

선언 2·관측 1에서 실제 노드는 A 한 개로 시작한다. B를 만든 뒤 완료 응답이 유실되면 실제 A·B는 2인데 제어면 관측은 여전히 1이다. 첫 상태 주석은 이 차이를 표시하며 새 lost-message 화살표를 가정하지 않는다. 제어면이 같은 B의 생성 결과를 확인하면 점선 채운 반환으로 실제 2를 알고 재관측한다. 차이 2−2=0이므로 추가 생성은 없다. 응답이 없었다는 이유만으로 새 C를 만들면 실제 3으로 늘어난다. 이 제어면의 비교·재조정 과정과 데이터면의 실제 요청·패킷·I/O 처리는 구분한다.

이 예의 조건

• 시간은 위에서 아래로 진행한다. 처음 선언은 2, 관측은 1이므로 B 생성을 요청한다. 실제 노드가 B를 생성했지만 응답이 유실되어 제어면은 오래된 1을 가지고 있다. 새 이름 C를 생성하면 실제 3이 되므로 같은 B 식별자로 결과를 확인하고 실제 A·B=2로 관측을 갱신한다. 점선 응답은 확인 요청의 반환이며 유실된 응답은 새로운 UML lost-message 화살표 대신 노드 상태 주석으로 표시했다. 선언→정책·승인→배치·명령, 노드·저장·망의 상태수집→관측→비교·재조정 루프가 이 사례의 근거이며 데이터면의 요청·패킷·I/O 처리는 따로 진행한다.
• 선언 2와 오래된 관측 1인 제어면에서 A 한 개인 실제 노드로 B 생성을 요청한다. 노드는 B 생성을 완료해 실제 2가 되지만 응답은 유실된다. 유실된 응답을 새 UML 메시지로 만들지 않고 상태 주석에 표시한다. 제어면은 같은 B의 결과를 확인하고 점선 채운 반환으로 실제 A·B=2를 받아 관측 2와 차이 0으로 갱신한다. 새 C를 생성하면 실제 3이 된다는 반례와 추가 생성 없음을 보존한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림 가로·세로 배치의 모든 라벨과 관계 설명

원 항목	설명·조건
원 항목27	설명·조건시작 A 1개
원 항목30	설명·조건응답 유실
원 항목36	설명·조건같은 B 확인 뒤 추가 생성 없음

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
차이 확인 목표 2와 관측 1의 차이를 맞추려 한다.	값·보충 정보 목표·관측: desired2·observed1 실제 자원: actual1	변화·이유 선언 수와 실제 수를 구별한다.
B 생성 B 생성이 실제로 성공해 자원은 2개지만 응답을 잃었다.	값·보충 정보 목표·관측: 관측 1·미확인 실제 자원: actual 2·B 있음	변화·이유 응답 없음이 미생성을 뜻하지 않는다.
같은 B 조회 새 C를 만들기 전에 같은 B를 확인한다.	값·보충 정보 목표·관측: B 결과 조회 실제 자원: B 존재 확인	변화·이유 요청의 의미를 유지해 중복 자원을 막는다.
관측 2 확인한 실제 2를 관측에 반영해 목표와 맞춘다.	값·보충 정보 목표·관측: desired2·observed2 실제 자원: actual 2·C 없음	변화·이유 차이가 없어 추가 생성하지 않는다.

응답 유실 뒤 새 C를 만들지 않고 B를 확인한다 · 상태 따라가기

목표 2와 관측 1의 차이를 맞추려 한다. 모든 단계에서 목표·관측·실제 자원의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

넓은 화면과 모바일에서 같은 관계를 각각의 배치로 읽을 수 있습니다.

시간은 위에서 아래로 진행한다. 처음 선언은 2, 관측은 1이므로 B 생성을 요청한다. 실제 노드가 B를 생성했지만 응답이 유실되어 제어면은 오래된 1을 가지고 있다. 새 이름 C를 생성하면 실제 3이 되므로 같은 B 식별자로 결과를 확인하고 실제 A·B=2로 관측을 갱신한다. 점선 응답은 확인 요청의 반환이며 유실된 응답은 새로운 UML lost-message 화살표 대신 노드 상태 주석으로 표시했다. 선언→정책·승인→배치·명령, 노드·저장·망의 상태수집→관측→비교·재조정 루프가 이 사례의 근거이며 데이터면의 요청·패킷·I/O 처리는 따로 진행한다.

선언 2·관측 1에서 실제 노드는 A 한 개로 시작한다. B를 만든 뒤 완료 응답이 유실되면 실제 A·B는 2인데 제어면 관측은 여전히 1이다. 첫 상태 주석은 이 차이를 표시하며 새 lost-message 화살표를 가정하지 않는다. 제어면이 같은 B의 생성 결과를 확인하면 점선 채운 반환으로 실제 2를 알고 재관측한다. 차이 2−2=0이므로 추가 생성은 없다. 응답이 없었다는 이유만으로 새 C를 만들면 실제 3으로 늘어난다. 이 제어면의 비교·재조정 과정과 데이터면의 실제 요청·패킷·I/O 처리는 구분한다.

이 예의 조건

• 시간은 위에서 아래로 진행한다. 처음 선언은 2, 관측은 1이므로 B 생성을 요청한다. 실제 노드가 B를 생성했지만 응답이 유실되어 제어면은 오래된 1을 가지고 있다. 새 이름 C를 생성하면 실제 3이 되므로 같은 B 식별자로 결과를 확인하고 실제 A·B=2로 관측을 갱신한다. 점선 응답은 확인 요청의 반환이며 유실된 응답은 새로운 UML lost-message 화살표 대신 노드 상태 주석으로 표시했다. 선언→정책·승인→배치·명령, 노드·저장·망의 상태수집→관측→비교·재조정 루프가 이 사례의 근거이며 데이터면의 요청·패킷·I/O 처리는 따로 진행한다.
• 선언 2와 오래된 관측 1인 제어면에서 A 한 개인 실제 노드로 B 생성을 요청한다. 노드는 B 생성을 완료해 실제 2가 되지만 응답은 유실된다. 유실된 응답을 새 UML 메시지로 만들지 않고 상태 주석에 표시한다. 제어면은 같은 B의 결과를 확인하고 점선 채운 반환으로 실제 A·B=2를 받아 관측 2와 차이 0으로 갱신한다. 새 C를 생성하면 실제 3이 된다는 반례와 추가 생성 없음을 보존한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림 가로·세로 배치의 모든 라벨과 관계 설명

원 항목	설명·조건
원 항목27	설명·조건시작 A 1개
원 항목30	설명·조건응답 유실
원 항목36	설명·조건같은 B 확인 뒤 추가 생성 없음

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
차이 확인 목표 2와 관측 1의 차이를 맞추려 한다.	값·보충 정보 목표·관측: desired2·observed1 실제 자원: actual1	변화·이유 선언 수와 실제 수를 구별한다.
B 생성 B 생성이 실제로 성공해 자원은 2개지만 응답을 잃었다.	값·보충 정보 목표·관측: 관측 1·미확인 실제 자원: actual 2·B 있음	변화·이유 응답 없음이 미생성을 뜻하지 않는다.
같은 B 조회 새 C를 만들기 전에 같은 B를 확인한다.	값·보충 정보 목표·관측: B 결과 조회 실제 자원: B 존재 확인	변화·이유 요청의 의미를 유지해 중복 자원을 막는다.
관측 2 확인한 실제 2를 관측에 반영해 목표와 맞춘다.	값·보충 정보 목표·관측: desired2·observed2 실제 자원: actual 2·C 없음	변화·이유 차이가 없어 추가 생성하지 않는다.

한 번 명령하고 끝내는 절차가 아니라 선언 → 관측 → 차이 계산 → 조치 → 재관측의 폐루프다. 이때 오래된 관측값, 중복 명령, 부분실패, 제어면과 노드 사이의 분할을 정상적인 가능성으로 취급한다. 제어면의 기록만 보고 실제 자원이 만들어졌다고 단정하지 않는다.

실행 인스턴스를 두 개 유지하라는 선언을 수로 따라가 보자. 첫 관측은 하나이므로 차이는 2−1=1이고 제어면은 두 번째 인스턴스 B의 생성을 요청한다. 노드가 B를 만들었지만 완료 응답이 유실되면, 제어면이 가진 오래된 관측은 여전히 하나이고 실제 노드에는 둘이 있다. 이때 새 이름 C로 무조건 재시도하면 실제 수가 셋으로 늘어난다. B의 식별자를 보존해 생성 결과를 확인하고 다시 관측하여 둘임을 확인하면 차이는 2−2=0이고 추가 생성은 필요 없다. 확인 문제는 “응답을 못 받았으니 하나를 더 만들어야 하는가?”이다. 답은 아니다. 응답 유실과 생성 실패는 서로 다른 상태이며, 실제 자원과 요청 식별자를 먼저 확인해야 한다.

3. 배치와 오버커밋: 평균이 아니라 동시 피크와 실패를 견딘다

워크로드 배치는 요청량·한도·실측 부하와 위치 제약을 바탕으로 실행 장소를 정하는 과정이다. 오버커밋(overcommit)은 물리적으로 동시에 제공할 수 있는 양보다 더 많은 논리자원을 약속하는 정책이다. 모든 워크로드가 동시에 최대치를 사용하지 않는다는 통계적 다중화 효과를 이용하지만, 잘못하면 여러 워크로드가 함께 느려지거나 중단된다.

할당 요청량의 합이 물리용량보다 큼과 실제 사용량의 합이 물리용량보다 큼을 구분한다. 앞은 정책상 오버커밋이고, 뒤는 실제 경합이다. 메모리처럼 부족할 때 프로세스 종료나 심한 교체가 생길 수 있는 자원과, CPU처럼 시간을 나눌 수 있는 자원은 같은 비율을 적용하지 않는다.

숫자로 읽기: 네 호스트의 128코어가 전부 가용한 것은 아니다

호스트 4대가 각각 CPU 32코어라면 설치용량은 128코어다. 호스트 1대 고장에도 기존 워크로드를 받아야 한다면 정상상태에서 적어도 32코어 상당의 장애조치 여유를 남겨야 하므로 단순 가용상한은 96코어 이하가 된다. 관리작업과 부하변동용 12코어를 더 남기면 계획상 사용한도는 84코어다.

논리 CPU 요청 합계를 168로 허용하면 계획한도 84 대비 요청 오버커밋 비율은 168/84=2다. 이 숫자는 성능을 두 배 보장한다는 뜻이 아니다. 동시 피크가 84코어를 넘는 시간비율, CPU 준비 대기, 서비스 응답시간과 스로틀링(throttling), 즉 정책이나 자원한도 때문에 처리율이 강제로 낮아지는 현상을 관측해야 한다. 한 호스트에 피크가 겹치는 워크로드를 몰아넣지 않고, 실제 장애 시 재배치 가능한 메모리·스토리지·네트워크 여유도 함께 확인한다.

같은 4×32코어 환경에 호스트마다 메모리 64GiB를 두고, 분할할 수 없는 W1~W4가 각각 CPU 20코어 상당의 계획 예산과 메모리 24GiB를 필요로 한다고 하자. 여기의 20은 앞의 vCPU 요청 수와 다른 배치 예산이며 시간공유로 자동 축소할 수 없다고 가정한다. 정상에는 각 호스트에 하나씩 놓아 총 CPU 80≤84로 계획 총량은 만족한다.

H4를 잃어도 살아 있는 잔여 합계는 CPU 36코어·메모리 120GiB여서 W4보다 크다. 그러나 어느 단일 호스트에도 CPU 20코어가 남지 않으므로 그대로 재배치할 수 없다. 총량 비교는 필요조건이고 호스트별 맞춤 검사는 별도다.

업무가 독립 실행단위로 분할 가능하다면 각 W를 10코어·12GiB인 두 단위로 바꾸는 대안을 시험할 수 있다. 정상에는 호스트별 두 단위씩 놓고 H4 고장 뒤 그 두 단위를 H1·H2에 하나씩 옮기면 H1·H2는 각각 30코어·36GiB, H3는 20코어·24GiB가 된다. 세 호스트 모두 상한 안이고 CPU 잔여 총량은 96−80=16코어다. 분할이 불가능하거나 통신·상태·복제본 분산 제약을 어기면 이 대안은 기각하고 더 큰 호스트나 별도 예비 호스트를 선택해야 한다.

이제 CPU 요구는 그대로 두고 각 W의 메모리만 44GiB로 바꿔 같은 분할 대안을 판정해 보자. 각 실행단위가 10코어·22GiB를 쓴다고 가정한다. 자체 조건 변경 연습이므로 먼저 계산·판정을 적는다.

단계 풀이와 잘못된 추론 교정 보기

정상 배치에서 호스트별 두 단위는 20코어·44GiB를 쓰고, 잔여는 12코어·20GiB다. H4 고장 뒤 옮길 한 단위의 CPU 10코어는 들어가지만 메모리 22GiB는 들어가지 않는다. 받아들이면 44+22=66GiB>64GiB가 되어 모든 후보 호스트에서 거절된다. 살아 있는 메모리 잔여 합계 3×20=60GiB가 잃은 W4의 44GiB보다 커도 결론은 같다. 앞의 성공 답을 그대로 재사용하는 오답은 CPU만 확인한 결과다. CPU와 메모리를 각각 호스트별로 확인하는 배치 절차로 돌아가 조건을 다시 대조해야 한다.

복습: 4호스트의 총량과 호스트별 잔여 벡터. CPU뿐 아니라 메모리의 단위와 단일 호스트 수용조건을 다시 확인한다.

배치 판단은 필수조건 → 분산 → 최적화 순서다

1. 필수조건: 자원 종류·최소량, 운영체제·가속기, 데이터 위치, 보안경계, 허용 지역을 만족하지 못하면 후보에서 제외한다.
2. 충돌 방지: 같은 서비스 복제본, 동일 피크 워크로드, 같은 관리역할이 한 고장경계에 몰리지 않게 한다.
3. 지역성: 계산과 데이터, 빈번히 통신하는 구성요소를 가까이 두어 불필요한 지연과 전송비용을 줄인다.
4. 균형·비용: 남은 후보에서 여유용량과 실제 사용량, 전력·라이선스·이동비용을 비교한다.

모든 목표를 동시에 최대로 만들 수 없다. 지역성을 높이려 한곳에 모으면 장애격리가 약해지고, 지나치게 분산하면 통신지연과 비용이 커질 수 있다. 함께 고장 날 수 있는 장애영역과 대체자원 배치는 다음 절에서 설명한다.

저장 자원풀: 연결방식과 접근모델을 섞지 않는다

공식 분류의 첫 축은 저장자원이 호스트에 직접 붙는 DAS인지 네트워크를 거치는 networked storage인지이고, 둘째 축은 클라이언트에 block/file/object 중 어떤 서비스 인터페이스를 제공하는지다. NAS와 SAN은 각각 네트워크 파일 접근과 네트워크 블록 접근의 대표 구현 사례이지, DAS/NAS/SAN과 block/file/object를 보편적으로 일대일 대응시키는 별도 축이 아니다. 스토리지 가상화는 여러 장치나 경로를 논리 볼륨·공유·객체공간으로 보이게 할 수 있지만, 지연·내구성·일관성·복구책임까지 사라지게 하지는 않는다.

CI·HCI·SDDC는 서로 다른 질문에 답한다

다음은 특정 표준의 공식 분류표가 아니라 기출에 등장한 용어를 물리 구성단위와 소프트웨어 제어원리라는 축으로 읽기 위한 교재용 비교다.

CI와 HCI는 물리·제품 구성방식에 더 가깝고, SDDC는 제어·운영 원리에 더 가깝다. 서로 배타적인 삼분법이 아니며 특정 제품 목록을 정의로 쓰지 않는다.

4. 실패와 설계 절차

자원은 남아 있는데도 서비스가 실패할 수 있다

아래 표의 분위수(percentile)는 측정값을 작은 순서로 놓았을 때 누적비율의 경계다. 예를 들어 99번째 백분위 지연은 요청의 99%가 그 값 이하였다는 뜻이므로 평균에 가려진 느린 꼬리를 드러낸다.

여덟 단계로 설계하고 증명한다

1. 서비스 계약: 업무량, 응답시간·처리량, 중단·데이터손실 허용, 보안·비용 한도를 수치화한다.
2. 경계와 의존성: 사용자 요청에서 컴퓨트·저장·망·외부서비스까지 경로와 소유자를 그린다.
3. 자원모델: 평균이 아니라 피크·변동·성장률과 자원별 병목을 측정한다.
4. 풀과 할당계약: 자원단위, 최소보장·한도·쿼터, 이질성, 위치·보안 제약을 정한다.
5. 제어와 상태: 선언·관측·조정 주체, 상태저장소, 부분실패·중복명령 처리와 수동복구를 설계한다.
6. 배치와 예비분: 필수조건, 지역성·분산, 오버커밋 상한, 관리·장애조치 여유를 함께 둔다.
7. 관측과 시험: 서비스 수준과 자원지표, 배치·변경 사건을 연결하고 과부하·노드·제어면 장애를 시험한다.
8. 증거 기반 조정: 가정 대비 측정값, 비용과 실패결과로 풀 크기·정책·확장단위를 갱신한다.

자원풀에서 회복성 설계로 이어진다

이 절에서는 인프라 아키텍처, 세 자원풀, 제어면·데이터면과 배치·오버커밋을 살펴보았다. 앞 절의 격리 원리 위에 자원을 배치하고, 다음 절의 장애영역·용량·복구구조로 고장 뒤에도 그 배치를 유지할 수 있는지 확인한다.

Kubernetes 제품·API와 클라우드 서비스모델, 네트워크 제어·전달 평면과 프로토콜, 데이터베이스 복제·고가용성은 각 주제의 상세 설명과 연결한다. 이 절의 예시는 공통 인프라 원리를 보여 주기 위한 것이며 특정 제품 선택을 보증하지 않는다.

인프라 아키텍처의 핵심 학습 논점

인프라 아키텍처를 설명할 때는 제품 구성도에 머물지 않고 다음 네 논점을 모두 연결한다.

1. 인프라 아키텍처의 정의·목적·범위를 서비스 요구와 컴퓨트·스토리지·네트워크 경계로 설명한다.
2. 자원풀, 제어면·데이터면, 요청·배치·관측·수렴의 구조와 작동원리를 설명한다.
3. 자원조각·경합·오버커밋·부분실패·관측지연의 징후와 예약·한도·멱등조정·시험 통제를 연결한다.
4. 워크로드·품질목표·장애경계·확장단위·비용으로 CI·HCI·SDDC와 배치대안을 비교하고 결론을 낸다.

다음 절에서는 같은 자원·배치 구조에 용량·확장, 장애영역·중복, 고가용성·장애조치와 RTO·RPO를 적용한다. 설치총량만 충분한 구조와 고장 후에도 서비스 목표를 지키는 구조를 구별하는 단계다.

5. 기출 후보와 답안 전환

기출은 군집 제목이 아니라 문항 원문으로 연결한다

각 문항은 AI가 PDF 텍스트와 시각 위치를 대조한 후보이지만 사람 원문 검증과 출제 적합성 승인은 아직 수행하지 않았다. 따라서 현재 연결은 candidate / human-review-pending / not-approved다.

자동 군집과 범위 오염을 격리한다

IM-0140-P02-Q04의 AI 슈퍼컴퓨팅 플랫폼 문항은 이 장의 확장 주제가 될 수 있지만 자동 군집 TOP-01498에는 멀티모달 LLM·RAG·보안 문항이 섞여 있다. 사용한다면 문항 자체만 direct_question_contaminated_cluster_quarantined로 연결하고 군집 제목·빈도·구성원을 근거로 쓰지 않는다.

Kubernetes 군집, VLAN·VPN·NFV, DBMS 고가용성은 각각 오케스트레이션·네트워크·데이터베이스의 상세 주제로 이어진다. 코드형 인프라스트럭처는 선언·멱등성·드리프트를 보여 주는 보조 예로 사용한다.

시험에서는 어떻게 묻는가: 10점

다음은 본문을 답안으로 전환하기 위한 자체 제작 문제다. 실제 기출 원문이나 출제 사실을 뜻하지 않는다.

인프라 자원풀과 제어면·데이터면의 개념, 작동원리 및 실패 통제를 설명하시오.

자원풀을 여러 장비를 묶은 것으로 끝내지 않는다. 할당계약, 요청부터 회수까지의 상태수렴, 실제 처리경로, 부분실패와 오버커밋 위험을 연결해야 한다.

답안 목차·풀이·교정 근거 보기

10점 답안 목차

1. 정의와 목적
   • 물리장치가 아닌 할당 가능한 논리 공급능력
   • 표준화·공유·회수와 서비스 품질 연결
2. 구성
   • 컴퓨트·스토리지·네트워크 풀과 할당계약
   • 제어면의 결정·수렴 / 데이터면의 실제 처리
3. 작동원리
   • 요청→승인→선별·배치→할당→관측·조정→회수
4. 실패와 통제
   • 자원조각·제약충돌·부분실패·오버커밋·관측지연
   • 예약·한도·예비분·멱등조정·서비스 지표 검증

10점 답안 도식

요구·쿼터·정책은 제어면의 승인→선별→배치→명령을 거쳐 컴퓨트·스토리지·네트워크 풀에 할당된다. 데이터면은 실제 요청·I/O·통신을 처리하고 관측·재조정, 회수·확장·재배치·실패복구가 상태와 용량을 관리한다. 기존 할당 절차와 같은 B 식별자의 수렴 도식을 답안 근거로 재사용한다.

10점 모범답안

인프라 자원풀은 계산·저장·네트워크 자원을 특정 장비가 아니라 요청·할당·회수할 수 있는 논리 공급능력으로 관리하는 구조다. 풀에는 물리총량뿐 아니라 이질성, 최소보장·한도, 위치·보안 제약, 관리와 장애조치 예비분이 포함된다.

제어면은 원하는 상태와 정책을 받아 요청을 승인하고 후보를 선별·배치하며, 명령 뒤 실제 상태를 관측해 차이를 재조정한다. 데이터면은 배치된 워크로드가 사용자 요청·패킷·저장 I/O를 실제 처리하는 경로다. 두 면은 논리적 책임 구분이며 물리적으로 반드시 분리된다는 뜻은 아니다.

작동은 요청→정책·쿼터 승인→후보 선별→배치→할당→관측·수렴→회수 순서다. 총량이 남아도 제약과 자원조각 때문에 배치가 실패할 수 있고, 오버커밋은 동시 피크에서 시끄러운 이웃과 지연을 만든다. 그러므로 자원별 예약·한도와 오버커밋 상한, 실패예비분, 멱등 명령과 실제상태 재조정, 서비스 지연과 자원 경합의 공동 관측으로 통제한다.

시험에서는 어떻게 묻는가: 25점

다음도 이 절 전체를 답안으로 전환하기 위한 자체 제작 문제다.

서비스 품질목표를 만족하는 컴퓨트·스토리지·네트워크 통합 인프라 아키텍처의 자원모델, 제어·배치 구조, 오버커밋 위험 및 검증방안을 설명하시오.

제품명을 나열하지 않고 요구→자원풀→제어/데이터면→배치→관측·실패시험으로 폐루프를 만든다. 용량과 성능, 설치총량과 장애 후 가용량, 논리요청과 실사용을 구분하는 것이 핵심이다.

답안 목차·풀이·교정 근거 보기

25점 답안 목차

1. 목표와 아키텍처 원칙
   • 부하·성능·가용성·보안·비용·복구 계약
   • 경계·표준단위·자동화·관측·격리 원칙
2. 자원풀 모델
   • compute: CPU·메모리·가속기
   • storage: block/file/object, 용량·IOPS·지연·내구성
   • network: 주소·연결·대역·경로, 지연·손실·정책
3. 제어와 상태수렴
   • 선언·승인·배치·명령과 실제상태 관측·재조정
   • 부분실패·중복명령·제어면 중단 통제
4. 배치와 오버커밋
   • 필수조건→분산·지역성→균형·비용
   • 요청/한도/실사용, 자원별 상한, 관리·장애 예비분
5. 구성 대안과 선택
   • CI·HCI·SDDC의 다른 관점과 확장단위·제어책임
   • 지역성·장애격리·비용의 절충
6. 검증과 개선
   • 서비스·자원·배치·변경 지표 연결
   • 피크·고장·제어면 분할·복구 시험과 용량 재조정

25점 답안 도식

서비스 수준 목표·부하·보안·비용·복구에서 CPU/메모리/가속기, block/file/object, 대역폭/경로의 자원모델을 만들고 제어면에서 선언→승인→선별→배치→명령한다. compute·storage·network 풀 위 데이터면이 요청·I/O·통신을 처리하며 관측·재조정이 제어면으로 환류한다. 지연·처리량·경합·비용·배치가능량을 검증하고 피크/노드 고장/제어 분할 시험으로 정책·용량을 갱신한다. 기존 여덟 단계 설계와 실제 수렴 도식을 재사용하고, 아래 도식은 이 답안에서 자주 놓치는 호스트별 배치 가능량의 실제 반례다.

넓은 화면과 모바일에서 같은 관계를 각각의 배치로 읽을 수 있습니다.

원문의 H4 고장 시 각 생존 호스트는 32코어 중 W1/W2/W3에 20을 사용하고 12가 남는다. 같은 축의 막대 길이는 실제 코어 수에 비례한다. H4의 막대는 원래 호스트 규모를 비교하기 위한 외곽선이며 가용 용량 0이다. 살아 있는 CPU 잔여 합계 36과 메모리 잔여 120GiB가 W4(20코어·24GiB)보다 커도 분할 불가능한 작업은 단일 호스트에 맞지 않는다. 메모리 44GiB로 바꾼 실패 사례와 분할 가능한 10코어 대안의 원문 계산은 그대로 두었으며 이 그림에서 업무 분할 가능성을 가정하지 않는다.

회색 사용량과 빈 잔여량을 같은 0부터 32코어 축에 놓았다. W4 요구 막대의 80px는 각 호스트의 잔여 48px보다 길다. H4 점선 외곽은 명목 규모이며 사용 가능한 자원이 아니다. 분할 가능성이나 메모리 조건을 바꾸는 대안의 계산은 원문 별도 사례를 따른다.

25점 모범답안

인프라 아키텍처는 서비스 실행자원과 연결·배치·보호·관찰·복구 제어를 품질목표에 맞게 조직하는 설계다. 먼저 업무량의 평균·피크·성장률, 응답시간·처리량, 허용중단과 데이터손실, 보안경계와 비용한도를 수치화하고 사용자 요청에서 계산·저장·망·외부의존까지 경계를 그린다.

자원은 장비 목록이 아니라 할당 가능한 풀로 모델링한다. 컴퓨트는 CPU·메모리·가속기의 세대·지역성·공유비율, 스토리지는 block/file/object 접근과 용량·IOPS·지연·내구성, 네트워크는 주소·연결·경로·대역과 지연·손실을 함께 적는다. 최소보장·최대한도·쿼터·지속시간·위치·보안 제약을 할당계약으로 정한다.

제어면은 선언한 상태를 정책·쿼터로 승인하고, 필수조건에 맞는 후보를 선별한 뒤 분산·지역성·균형·비용으로 배치한다. 명령 후 실제 상태를 관측해 차이를 재조정한다. 데이터면은 실행된 서비스가 요청·패킷·저장 I/O를 처리한다. 오래된 관측, 중복명령, 제어면 분할과 일부 자원만 생성되는 부분실패를 전제로 작업 식별자·버전과 멱등 조치, 재시도·보상·수동복구를 둔다.

배치는 설치총량이 아니라 고장 뒤에도 배치 가능한 자원벡터로 판단한다. 관리·유지보수·장애조치 예비분을 먼저 빼고 요청량과 실사용량을 분리한다. CPU의 시간공유와 메모리·저장의 고갈 영향이 다르므로 하나의 오버커밋 비율을 모든 자원에 적용하지 않는다. 같은 피크와 복제본을 분산하되 데이터 지역성과 장애격리, 통신비용의 절충을 기록한다.

CI는 검증된 구성 통합, HCI는 계산·저장을 범용 노드와 소프트웨어로 묶는 확장단위, SDDC는 API·정책 기반 추상화와 제어라는 다른 관점이므로 배타적인 제품분류로 보지 않는다. 워크로드의 계산/저장 성장비, 지역성, 장애경계, 기존 기술과 운영역량으로 선택한다.

검증은 평균 사용률이 아니라 서비스 지연 분위수·처리량·오류, CPU 준비·메모리 압박·I/O 대기열·망 혼잡, 배치 실패사유와 비용을 변경사건에 연결한다. 피크, 노드·경로·제어면 장애와 재구축 중 부하를 시험하고 실제 결과로 풀 크기, 예비분, 배치정책과 오버커밋 상한을 갱신한다.

예를 들어 본문의 4호스트·20코어 작업 사례는 총량 80≤84만으로 승인하지 않는다. H4 고장 시 각 생존 호스트의 잔여가 12코어라 20코어 작업을 넣지 못하므로 원안을 기각한다. 업무가 분할 가능함을 확인한 경우에만 10코어 단위로 나누어 H1·H2·H3에 30·30·20코어로 재배치하는 안을 선택하고, 상태·통신·복제본 분산 제약 및 고장 후 지연을 다시 시험한다.

근거와 현행성

클라우드 인프라의 행위자·구성요소·서비스 관리 경계는 NIST SP 500-292, NIST Cloud Computing Reference Architecture의 공식 모델을 대조했다. 저장 인프라의 연결·접근 경계는 NIST SP 800-209, Security Guidelines for Storage Infrastructure의 2020년 최종본을 대조하고, 2026년 Revision 1 초기 공개초안은 초안으로 구분한다. 컨테이너 오케스트레이션을 인프라 제어의 현행 예로 사용할 때는 Kubernetes 공식 문서의 Components, Resource Management for Pods and Containers, Horizontal Pod Autoscaling, Topology Spread Constraints를 2026-09-01 기준으로 확인하되, Kubernetes 자체의 제품 구조와 운영 절차는 별도 상세 주제다.

본문의 요청→승인→배치→수렴→회수 절차, 자원벡터, 128코어 예제, CI·HCI·SDDC 비교표와 모든 도식은 여러 공식 원리에서 한정해 저자가 구성한 설명이며 특정 표준의 의무절차나 제품 성능 보증이 아니다. 벤더 그림·표·화면은 복제하지 않았다. 학습용 계산·답안과 실제 기출 원문·공식 배점을 구별한다.

30초 정리

1. 인프라 아키텍처는 장비목록이 아니라 서비스 요구를 자원·제어·배치·관측·복구 결정으로 바꾸는 설계다.
2. 자원풀은 물리총량이 아니라 품질·제약·예비분을 가진 할당 가능한 논리 공급능력이다.
3. 제어면은 원하는 상태와 실제 상태를 수렴시키고, 데이터면은 실제 요청·패킷·I/O를 처리한다.
4. 배치는 필수조건, 분산·지역성, 균형·비용 순서로 판단하며 오버커밋은 자원별로 따로 통제한다.
5. 좋은 설계는 피크·고장·분할을 시험하고 서비스 지표와 자원·배치 사건을 연결해 정책을 다시 조정한다.

다시 읽을 때는 요구 → 풀 → 제어/데이터면 → 배치 → 관측·재조정 한 줄만 먼저 떠올린다. 제품명이 바뀌어도 이 구조는 인프라 문항의 목차를 유지해 준다.

추가 확인 문제: 용량과 재시도의 계약을 검산한다. 다음은 자체 연습이다. (1) 사용 가능 2TiB, 입출력 상한 10,000IOPS·100MiB/s인 풀에 1TiB 자료를 저장한다. 모든 작업이 32KiB이며 분할·병합·캐시·메타데이터 비용을 무시할 때, 단위 계산으로 허용되는 작업 수 상한은 얼마인가? 이 계산만으로 그 성능을 실제 보장할 수 있는가? (2) B 생성 요청 request-7의 응답을 못 받았다. 서비스가 호출자와 식별자·매개변수·결과를 일관되게 보존하는 멱등 계약을 제공한다면, 같은 작업의 재시도에 새 식별자 request-8을 붙여야 하는가? 같은 request-7로 메모리 크기까지 바꾸면 어떤 문제가 생기는가?

입출력 단위와 멱등 재시도 풀이 보기

(1) 처리량에서 계산한 상한은 100×1024/32=3,200IOPS다. min(10,000,3,200)=3,200IOPS 이하이어야 하며, 1TiB가 용량 2TiB 안에 들어간다는 사실과 별도 조건이다. 이 값은 주어진 두 상한과 단순 가정에서 얻은 상한이다. 실제 달성 여부와 지연은 호스트 경로·대기열·부하 등으로 검증해야 한다.

(2) 같은 작업을 확인·재시도하려면 원래 호출자와 request-7 및 같은 매개변수를 유지한다. 새 식별자 request-8은 서비스가 별도 생성 의도로 받아들여 중복 자원을 만들 수 있다. 같은 식별자로 크기를 바꾸는 것은 이전 작업과 다른 요구이므로 매개변수 불일치를 처리하고, 새 작업을 원한다면 별도 작업으로 명시해야 한다. 응답 유실은 B 생성 실패의 증거가 아니므로 기존 실제 상태도 확인한다.