feat(pipeline): keycloak-session-store 25편·virtualization 59편을 S3→S5→S6 으로 돌린다

기록 84편을 계약 에이전트로 다시 썼다. 기존 71편(kss 25 · virt 46)과, 계약에만 있고 안 쓰여 있던 새 글감 13편이다. 원장 84개를 열어 단계마다 스킬 영수증과 관문 종료 코드를 적었고 verify-pipeline-run.py 가 error 0 으로 닫는다. SSOT 결함 둘을 고쳤다. - kss 의 `약 58일` 이 반입 중 `약 59일` 로 바뀌어 있었다. 원 증거 파일이 「남은 일수: 88일 … 실제 갱신까지 약 58일」로 산수를 직접 적는다. D-4a 쪽 `약 59일` 은 강제 갱신 뒤(`VALID: 89 days`)라 맞는 값이라 그대로 뒀다. - virt §198 의 `11.6GB` 는 §178 의 원 측정 `Mem: 11648`(MiB)과 어긋나는데 원 가이드의 표기 그대로라 고치지 않고 쓰이는 자리에 대조를 적었다. 기록의 수치 오류 셋을 고쳤다 — CASE 요약의 「게스트 셋에 8240MB」(5120+3120 은 둘이다), k3s 편이 같은 것을 여섯·일곱·여덟로 세던 것, no-docker 편의 「셋을 더 든다」(§281 의 표는 네 행이고 디스크 행이 빠져 있었다). 계약을 셋 고쳤다. - kss 의 sourceRepository 리비전이 cdac9b8 이었는데 그 커밋에는 docs/guides/** 28개가 아예 없다. 9465582b 로 바꾸고, 반입한 바이트가 어느 커밋과도 같지 않다는 것을 측정값과 함께 적었다 — 반입은 커밋이 아니라 그 시점의 작업 트리에서 떠 온 것이다(kss 297/306 · virt 12/14 가 작업 트리와 같고, 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 커밋도 28개가 어긋났다). - virt 계약이 「2026-09-11 재배분」이라고 적는데 SSOT 는 재배분 날짜를 적지 않고 재배분 뒤 값은 이미 2026-09-10 측정에 찍혀 있다. - kss 후보 대장이 지나친 절 아홉에 처분을 적었다(warn 9 → 0). 새 글감은 0건이고 넷은 앵커가 h3 슬러그의 접두가 아니라 중간 토막이라 검사기가 못 본 것이었다. style_profile.mjs 의 결함 둘을 고쳤다 — frontmatter 가 문장으로 세어져 (실측 398자짜리 「문장」 하나) 평균 길이를 기준 안으로 밀어 올리고 있었고, engPerSent 의 분자는 목록을 포함한 글에서, 분모는 목록을 걷어낸 글에서 세고 있었다(Question 기록에서 11.94 → 3.86). verify-pipeline.py 전 항목 PASS · error 0 · unittest 334건 OK. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 11:01:55 +09:00
parent d473609e0a
commit 2109f726fe
574 changed files with 159654 additions and 1551 deletions
@@ -164,7 +164,7 @@ cat /sys/kernel/mm/transparent_hugepage/enabled

 ## 이 글이 확정하지 않는 것

-이 호스트에서 잰 값은 하나도 없다. THP 정책도 `HugePages_Total` 도 읽지 않았고 가상 머신의 메모리 backing 설정도 확인하지 않았다. 원문 제2부는 개념 서술이고 실제 서버에 딸린 값은 OQ(Open Question) 번호가 붙은 확인 목록 열넷으로 미뤄져 있다.
+이 호스트에서 huge page 를 잰 값은 하나도 없다. THP 정책도 `HugePages_Total` 도 읽지 않았고 가상 머신의 메모리 backing 설정도 확인하지 않았다. 원문 제2부는 개념 서술이고 실제 서버에 딸린 값은 OQ(Open Question) 번호가 붙은 확인 목록 열넷으로 미뤄져 있다.

 호스트 쪽 값은 OQ-4 가 받는다. THP 정책과 함께 `AnonHugePages`, `HugePages_Total`, `HugePages_Free`, `Hugepagesize` 를 읽어 이 서버가 어느 방식을 쓰고 있는지 확정하는 확인이다.

@@ -174,6 +174,6 @@ cat /sys/kernel/mm/transparent_hugepage/enabled
 virsh dumpxml <VM_NAME>
 ```

-두 확인이 끝나기 전에는 이 글의 세 질문 가운데 어느 것도 이 서버에 대해 답이 없다. 그리고 두 확인이 끝나도 셋째 질문은 남는다. EPT 매핑에서 큰 매핑을 쓰는가를 이 호스트에서 재라고 적은 항목은 그 열넷에 없다. 원문이 커널·QEMU·libvirt 버전을 적지 않아 이 글도 특정 버전에 고정하지 않았고, THP 정책의 기본값이 배포판마다 다르다는 점도 원문이 확인하라고만 적었다.
+두 확인이 끝나기 전에는 이 글의 세 질문 가운데 어느 것도 이 서버에 대해 답이 없다. 그리고 두 확인이 끝나도 셋째 질문은 남는다. EPT 매핑에서 큰 매핑을 쓰는가를 이 호스트에서 재라고 적은 항목은 그 열넷에 없다. 원문 제2부가 THP 와 HugeTLB 를 서술하면서 커널·QEMU·libvirt 버전을 적지 않아 이 글도 특정 버전에 고정하지 않았다. 이 실험대의 커널 `7.2.2-arch1-1` 과 QEMU 11.1.1, libvirt 12.7.0 은 §197 이 적어 두었다. 그 위에서 huge page 값을 읽은 기록은 없다. THP 정책의 기본값이 배포판마다 다르다는 점도 원문이 확인하라고만 적었다.

 <!-- body:end -->
@@ -62,7 +62,11 @@ VM3 configured = 16 GiB
 Total configured = 48 GiB
 ```

-이 숫자는 개념을 보이려고 든 예시이고 이 테스트 서버에서 잰 값이 아니다. 설정한 용량과, 그 가상 머신이 실제로 쓰고 있는 메모리(working set)나 호스트에서 그 몫으로 붙잡고 있는 메모리(resident memory)가 같지 않을 수 있기 때문에 이런 구성이 가능할 수 있다. 같은 예시에서 세 가상 머신이 실제로 쓰는 양을 각각 약 5G, 4G, 3G 로 잡으면 합이 약 12G 라 32 GiB 안에 들어간다. 세 대의 수요가 동시에 증가하면 그때부터 문제가 발생한다. 이 호스트의 값은 근거 문서 어디에도 없다. 물리 RAM 도 스왑 설정도 가상 머신들에 설정한 메모리의 합도 적혀 있지 않아서, 아래에 적는 경로가 이 환경에서 지금 돌고 있는지는 이 글이 정하지 못한다.
+이 숫자는 개념을 보이려고 든 예시이고 이 테스트 서버에서 잰 값이 아니다. 설정한 용량과, 그 가상 머신이 실제로 쓰고 있는 메모리(working set)나 호스트에서 그 몫으로 붙잡고 있는 메모리(resident memory)가 같지 않을 수 있기 때문에 이런 구성이 가능할 수 있다. 같은 예시에서 세 가상 머신이 실제로 쓰는 양을 각각 약 5G, 4G, 3G 로 잡으면 합이 약 12G 라 32 GiB 안에 들어간다. 세 대의 수요가 동시에 증가하면 그때부터 문제가 발생한다.
+
+이 실험대는 그 구성이 아니다. 호스트 물리 RAM 은 §178 이 `free -m` 으로 실측한 11,648MiB 다. 게스트 세 대에 배정한 메모리는 §187 이 `kc-lab-1` 5120MB, `kc-lab-2` 4096MB, `kc-lab-edge` 1024MB 로 적었고 합이 10,240MB 다. 배정 합이 호스트 RAM 보다 작다. 배정률은 10240/11648 = 87.9% 이고, 배정하지 않고 남은 것이 1,408MiB 다. 그래서 이 배치는 메모리 초과 할당이 아니다. 호스트의 스왑 설정은 아직 근거 문서에 없다.
+
+그 배정이 처음부터 이 숫자였던 것은 아니다. §187 은 게스트를 만들 때 메모리가 3584MB 였고 실험을 늘리며 5120/4096 으로 재배분했다고 적었다. 왜 그때 늘릴 수 있었는지는 §332 에 있다 — 「호스트에서 8GB→12GB로 물리 증설한 뒤 이 방법으로 재배분했다.」 그 방법은 `virsh setmaxmem` 으로 상한을 올리고 `virsh setmem` 으로 현재 할당을 맞추는 두 줄인데, 현재 할당을 상한보다 크게 줄 수 없어 순서가 정해져 있다. 게스트를 다시 만들거나 디스크를 건드리지 않아도 되는 대신 `setmaxmem --live` 는 대개 거부되므로, 상한을 바꾸려면 게스트를 껐다 켠다.

 CPU 가 모자랄 때와 RAM 이 모자랄 때 Linux 가 하는 일이 다르다. CPU 가 모자라면 스케줄러가 실행 시간을 나누고 실행 가능한 작업은 자기 차례를 기다리는데, 시간은 잘라서 뒤로 미룰 수 있기 때문이다. RAM 이 모자랄 때는 미룰 것이 없어서 지금 존재해야 하는 페이지를 어디에 둘 것인가만 남는다. 그래서 메모리 압박에서는 회수와 스왑, ballooning, OOM 같은 메커니즘이 추가로 개입한다. 메모리 초과 할당은 CPU 초과 할당과 동일한 성격의 자원 공유가 아니다.

@@ -109,10 +113,10 @@ cgroup 메모리 상한이 걸린 환경에서는 호스트 전체 RAM 에 여

 ## 이 문서가 확정하지 않는 것

-이 글이 확정하는 것은 구조가 어떻게 동작하는가까지다. 이 테스트 서버에서 잰 값은 하나도 없다.
+이 글이 확정하는 것은 구조가 어떻게 동작하는가까지다. 이 테스트 서버에서 잰 값 가운데 여기 쓴 것은 호스트 물리 RAM 과 게스트 배정, §198 의 할당·실사용뿐이고, 압박 경로 자체를 이 서버에서 재현한 적은 없다.

-이 호스트의 물리 RAM 도, 스왑 설정도, 가상 머신들에 설정한 메모리의 합도 근거 문서에 적혀 있지 않다. 그래서 이 환경이 초과 할당 상태인지조차 아직 사실이 아니다. 설정한 메모리와 게스트가 실제로 쓰는 메모리, 호스트에서 그 몫으로 붙잡고 있는 메모리를 가상 머신마다 적으면 그 답이 나온다.
+호스트 물리 RAM 11,648MiB 와 게스트 배정 합 10,240MB 는 앞 절에 실측으로 적었고, 배정 합이 더 작아 이 배치는 초과 할당이 아니다. 남은 것은 호스트의 스왑 설정과, 가상 머신마다의 실제 사용량 그리고 호스트에서 그 몫으로 붙잡고 있는 메모리다. §198 이 `virsh dommemstat` 으로 k3s 두 대를 재서 `kc-lab-1` 은 할당 5120MB 에 실사용 353MB, `kc-lab-2` 는 할당 3120MB 에 실사용 301MB 였다고 적었다. `kc-lab-2` 의 할당이 배정한 4096MB 보다 작은데, 같은 절은 그것을 virtio-balloon 이 회수해 간 것으로 보인다고 적고 단정하지 않았다. 그 측정은 k3s 만 떠 있고 Keycloak 은 올리기 전이라 나머지가 올라간 뒤의 값은 미측정이다. `kc-lab-edge` 는 그 측정에 들어 있지 않다.

-스왑이 지금 오가고 있는지도 재지 않았다. `Swap Used` 값 하나로는 진행 중인 활동인지 과거에 내려간 뒤 남아 있는 cold page 인지 갈리지 않으니 게스트와 호스트를 같은 시각에 관측해야 한다. 호스트 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는지는 압박이 없는 구간과 있는 구간을 나눠 재야 알 수 있고, 그 구간에서 스토리지 지연과 CPU 도 같이 기록해야 원인을 메모리 쪽으로 좁힐 수 있다. 세 확인은 각각 열린 질문으로 두었고 관계에 걸어 두었다.
+스왑이 지금 오가고 있는지도 재지 않았다. §178 과 §197 에 있는 호스트 `free -m` 출력은 `head -2` 로 잘려 `Mem:` 줄까지만 남아 스왑 줄이 없다. `Swap Used` 값 하나로는 진행 중인 활동인지 과거에 내려간 뒤 남아 있는 cold page 인지 갈리지 않으니 게스트와 호스트를 같은 시각에 관측해야 한다. 호스트 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는지는 압박이 없는 구간과 있는 구간을 나눠 재야 알 수 있다. 그 구간에서 스토리지 지연과 CPU 도 같이 기록해야 원인을 메모리 쪽으로 좁힐 수 있다. 세 확인은 각각 열린 질문으로 두었고 관계에 걸어 두었다.

 <!-- body:end -->
@@ -67,7 +67,7 @@ vCPU 를 특정 CPU 집합에 묶는 설정을 pinning 이라고 한다. 어떤

 ![QEMU vCPU Thread, VM1 Memory Backing, Node 0 CPU, Node 0 RAM, Node 1 RAM 다섯 참여자 사이의 순서도. 1번에서 vCPU thread 가 Node 0 CPU 에 pinning 되고 2번에서 VM1 의 memory backing 이 Node 1 에 놓이면 3번의 접근이 점선으로 Node 1 RAM 까지 간다. 4번에서 memory 를 Node 0 에 묶은 구성에서는 5번의 같은 접근이 Node 0 RAM 에서 끝난다.](../../../final/assets/diagrams/numa-vcpu-and-memory-placement/numa-vcpu-and-memory-placement.svg)

-이 호스트가 노드 몇 개인지는 근거 문서에 없다. 하나로 나오면 지금 말한 어긋남은 이 환경에 성립하지 않는다.
+이 호스트가 노드 몇 개인지는 근거 문서에 없다. §197 이 논리 코어를 8 로 적었지만 NUMA 노드 수는 읽지 않았다. 그 절은 `lscpu | grep -E "^Model name|^CPU\(s\):|^Thread|^Core"` 로 네 줄만 걸러 받았고, 거기 남은 `Core(s) per socket` 4 와 `Thread(s) per core` 2 로 논리 코어 8 이 나온다. `Socket(s)` 줄과 `NUMA node(s)` 줄은 그 네 패턴에 걸리지 않아 실측에 없다. 그 출력을 다시 읽어도 노드 수가 나오지 않으므로 아래 절의 `lscpu` 를 거르지 않고 한 번 더 친다. 노드가 하나로 나오면 지금 말한 어긋남은 이 환경에 성립하지 않는다.

 ## 큰 가상 머신에서는 게스트에게 토폴로지를 보여 준다

@@ -75,7 +75,7 @@ vCPU 를 특정 CPU 집합에 묶는 설정을 pinning 이라고 한다. 어떤

 노출한 뒤에는 게스트가 인식하는 토폴로지와 실제 호스트 배치가 합리적으로 대응되도록 구성한다. 게스트 NUMA 0 이 호스트 NUMA 0 에, 게스트 NUMA 1 이 호스트 NUMA 1 에 대응하지 않으면, 게스트가 로컬이라고 판단해 고른 메모리가 호스트에서는 원격이 된다.

-이 프로젝트의 가상 머신이 그런 크기인지는 근거 문서에 적혀 있지 않다. vCPU 수도 설정한 RAM 도 나오지 않아서, 이 절이 이 환경에 걸리는 이야기인지는 그 값을 적은 뒤에 정해진다.
+이 실험대의 가상 머신은 그 크기가 아니다. §187 이 적은 게스트 세 대는 vCPU 가 한 개나 두 개이고 배정한 메모리가 1024MB 에서 5120MB 사이다. §197 은 그 vCPU 합을 `2 + 2 + 1 = 5` 로 적었다.

 ## 이 장비의 토폴로지부터 읽는다

@@ -114,7 +114,7 @@ virsh vcpuinfo <VM_NAME>

 ## 이 문서가 확정하지 않는 것

-이 글이 확정하는 것은 배치가 어긋나면 무엇이 원격 접근이 되는가까지다. 이 테스트 서버에서 잰 값은 하나도 없다.
+이 글이 확정하는 것은 배치가 어긋나면 무엇이 원격 접근이 되는가까지다. 이 테스트 서버에서 NUMA 를 잰 값은 하나도 없다.

 이 호스트가 노드 하나인지 여럿인지가 정해지지 않았다. 노드 하나로 나오면 앞 절의 어긋남이 이 환경에 성립하지 않으므로 NUMA 를 현재 실험에서 뒤로 미룬다. 여럿으로 나와야 QEMU 프로세스의 노드별 메모리 분포와 vCPU 배치를 나란히 적는 확인이 의미를 갖는다. 토폴로지 확인은 CPU 가상화 쪽 질문이 받고 있다.

@@ -203,11 +203,11 @@ Host Kernel
      └─ Host OOM
 ```

-원문의 분류에는 Dynamic Memory 와 NUMA(Non-Uniform Memory Access) 가지가 더 있고, 위에 옮긴 셋이 fault 가 걸리는 가지다. 게스트 쪽 fault 가 늘었으면 게스트의 reclaim 과 swap 을 같이 보고, 호스트 쪽 major fault 가 늘었으면 호스트의 reclaim 과 swap 을 같이 본다. 어느 쪽 지표를 먼저 여느냐가 이 구분에서 정해진다. 다만 이 호스트에서는 어느 쪽도 아직 열지 않았다. 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 읽은 적이 없어서, 이 분류는 아직 어느 지표부터 열지 정하는 데만 쓰인다.
+원문의 분류에는 Dynamic Memory 와 NUMA(Non-Uniform Memory Access) 가지가 더 있고, 위에 옮긴 셋이 fault 가 걸리는 가지다. 게스트 쪽 fault 가 늘었으면 게스트의 reclaim 과 swap 을 같이 보고, 호스트 쪽 major fault 가 늘었으면 호스트의 reclaim 과 swap 을 같이 본다. 어느 쪽 지표를 먼저 여느냐가 이 구분에서 정해진다. 다만 이 호스트에서는 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 아직 열지 않았다. 그래서 이 분류는 지금 어느 지표부터 열지 정하는 데만 쓰인다.

 ## 이 글이 확정하지 않는 것

-이 호스트에서 잰 값은 하나도 없다. 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 읽지 않았고, 앞의 다섯 원인 가운데 무엇이 이 환경에서 실제로 일어나는지도 세지 않았다. 원문 제2부는 개념 서술이고 실제 서버에 딸린 값은 OQ(Open Question) 번호가 붙은 확인 목록 열넷으로 미뤄져 있다.
+이 호스트에서 fault 를 잰 값은 하나도 없다. 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 읽지 않았고, 앞의 다섯 원인 가운데 무엇이 이 환경에서 실제로 일어나는지도 세지 않았다. 원문 제2부는 개념 서술이고 실제 서버에 딸린 값은 OQ(Open Question) 번호가 붙은 확인 목록 열넷으로 미뤄져 있다.

 게스트 쪽은 OQ-13 이 받는다. page-fault 관련 지표를 관측한 뒤 그 증가가 무엇에서 왔는지를 네 갈래로 갈라 보는 확인이고, 증가 자체를 오류로 읽지 않는 것이 조건이다.

@@ -232,6 +232,6 @@ Guest application latency

 가운데 계층은 그 목록이 받지 않는다. 위 분류에는 EPT 관련 사건과 TLB 압박이 한 가지로 들어 있는데, 그것을 이 호스트에서 재라고 적은 항목은 열넷 가운데 없다. 이 글이 갈라 놓은 세 계층에서 확인 계획이 붙은 것은 게스트 쪽과 호스트 쪽 둘이다.

-원문이 커널 버전을 적지 않아 이 글도 특정 버전에 고정하지 않았다. 여기 적은 것은 그 문서가 서술한 처리 구조이고, 이 서버에서 어떤 값이 나오는지는 위 두 확인을 돌려야 안다.
+원문 제2부가 fault 처리를 서술하면서 커널 버전을 적지 않아 이 글도 특정 버전에 고정하지 않았다. 이 실험대의 커널은 §197 이 `7.2.2-arch1-1` 로 적었다. 그 위에서 fault 지표를 읽은 기록은 없다. 여기 적은 것은 그 문서가 서술한 처리 구조이고, 이 서버에서 어떤 값이 나오는지는 위 두 확인을 돌려야 안다.

 <!-- body:end -->
@@ -55,13 +55,13 @@ source:

 이 장치는 게스트 RAM 자체를 제공하지 않는다. 이미 존재하는 게스트 RAM 을 호스트와 게스트가 협력해 회수하고 반환하는 데 쓰는 가상 장치다.

-이 프로젝트의 가상 머신에 이 장치가 붙어 있는지는 근거 문서에 없다. 아래 두 절이 적는 것은 장치가 있을 때 어느 방향으로 움직이는가다.
+이 프로젝트의 가상 머신에 이 장치가 붙어 있는지는 libvirt 설정을 읽어야 정해지고 그 기록이 아직 없다. 아래 두 절이 적는 것은 장치가 있을 때 어느 방향으로 움직이는가다.

 ## Inflate — 게스트 안의 balloon 이 커진다

 호스트가 게스트 메모리를 회수하려고 하면 balloon target 을 조정해 balloon 을 부풀린다. 이 동작을 inflate 라고 한다. 그 요청이 `virtio-balloon` 을 지나 게스트 안의 balloon 드라이버에 닿으면 드라이버가 게스트 페이지를 확보한다. 게스트 안의 balloon 이 커지기 때문에 게스트가 쓸 수 있는 RAM 이 그만큼 줄고, 호스트 쪽에서는 회수할 수 있는 메모리가 는다.

-드라이버가 하는 일은 확보한 페이지를 일반적인 게스트 작업이 쓰지 못하도록 붙잡아 두고 그 사실을 호스트 쪽에 알리는 것까지다. 그 뒤 호스트가 그 메모리를 실제로 언제 어떻게 놓아주는지는 QEMU/KVM 버전과 backing 종류 및 설정에 따라 달라질 수 있다. 근거 문서는 그 동작을 하나로 단정하지 않았고 이 환경에서도 확인하지 않았다. 그 문서는 이 호스트의 QEMU/KVM 버전을 한 번도 적지 않았다. 버전과 설정이 갈라 놓는 동작이라 버전을 적기 전에는 이 환경이 어느 쪽인지 말할 수 없다.
+드라이버가 하는 일은 확보한 페이지를 일반적인 게스트 작업이 쓰지 못하도록 붙잡아 두고 그 사실을 호스트 쪽에 알리는 것까지다. 그 뒤 호스트가 그 메모리를 실제로 언제 어떻게 놓아주는지는 QEMU/KVM 버전과 backing 종류 및 설정에 따라 달라질 수 있다. 근거 문서는 그 동작을 하나로 단정하지 않았고 이 환경에서도 확인하지 않았다. 이 실험대의 버전은 §197 이 적어 두었다 — QEMU 11.1.1 과 libvirt 12.7.0, 커널 `7.2.2-arch1-1` 이다. 버전은 정해졌지만 그 위에서 호스트가 언제 놓아주는지를 잰 기록도, backing 설정을 읽은 기록도 없다.

 ![virtio-balloon Driver 와 virtqueue, QEMU virtio-balloon Device, Host Memory Management 네 참여자 사이를 여섯 개의 메시지가 오가는 순서도. 1번부터 3번까지는 Host 쪽에서 정한 balloon target 조정이 QEMU device 와 virtqueue 를 지나 VM Boundary 를 넘어 Guest kernel 의 driver 에 닿는 방향이고, 4번부터 6번까지는 driver 가 확보한 Guest page 가 같은 경계를 반대로 건너 Host 의 회수 가능 backing 이 되는 방향이다.](../../../final/assets/diagrams/virtio-balloon-inflate-deflate/virtio-balloon-inflate-deflate.svg)

@@ -86,6 +86,21 @@ ballooning 은 게스트에 이미 설정된 메모리 용량 안에서 호스

 현대 가상화에는 `virtio-mem` 같은 다른 동적 메모리 관리 방식도 있어서, 가상 머신의 동적 메모리 관리를 ballooning 하나로 일반화하지 않는다. 근거 문서에 있는 것은 그런 방식이 존재한다는 사실까지다.

+## 이 실험대에서 할당이 줄어 있던 값 하나
+
+앞에서 적었듯 balloon 장치가 붙어 있는지를 설정으로 확인한 기록은 아직 없다. 대신 값이 하나 나와 있다 — §198 이 k3s 게스트 두 대에 `virsh dommemstat` 을 돌려 받은 출력이다.
+
+```text label="§198 의 실측 — k3s 만 떠 있고 Keycloak 은 올리기 전"
+kc-lab-1   할당 5120MB  실사용 353MB
+kc-lab-2   할당 3120MB  실사용 301MB
+```
+
+`kc-lab-2` 는 `virt-install --memory 4096` 으로 만들었는데 현재 할당이 3120MB 로 나왔다. §198 은 이것을 virtio-balloon 이 회수해 간 것으로 보인다고 적고 거기서 멈췄다. 같은 절은 `dommemstat` 의 `actual` 이 현재 할당이지 선언한 상한이 아니라고 덧붙였다. 상한은 `virsh dominfo` 의 `Max memory` 에 있는데, 이 실험대는 그 두 값을 나란히 찍어 보지 않았다.
+
+§198 은 이 값이 언제의 값인지도 함께 적었다 — 「다만 이것은 지금 k3s 만 떠 있어서다」이고, Keycloak 2 파드와 PostgreSQL, Redis, Prometheus 가 올라간 뒤의 값은 미측정이다. 게스트 세 대 가운데 `kc-lab-edge` 는 이 측정에 들어 있지 않다.
+
+이 숫자로 알 수 있는 것은 `kc-lab-2` 의 현재 할당이 선언값보다 작다는 것까지다. 그 차이가 balloon 회수 때문인지와 이 가상 머신들에 장치가 실제로 붙어 있는지는 설정과 게스트 쪽 드라이버 상태를 읽어야 갈린다.
+
 ## 근거 문서가 번호를 붙여 둔 문장

 근거 문서는 이 장치에서 고정한 문장에 번호를 붙여 두었다. 실험 기록에서 어느 문장을 확인했는지 가리킬 때 이 번호를 쓴다.
@@ -97,10 +112,10 @@ ballooning 은 게스트에 이미 설정된 메모리 용량 안에서 호스

 ## 이 문서가 확정하지 않는 것

-이 글이 확정하는 것은 balloon 이 어떤 구조로 어느 방향으로 동작하는가까지다. 이 테스트 서버에서 잰 값은 하나도 없다.
+이 글이 확정하는 것은 balloon 이 어떤 구조로 어느 방향으로 동작하는가까지다. 이 테스트 서버에서 잰 값 가운데 여기 쓴 것은 §198 의 할당과 실사용뿐이고, balloon 을 움직여 본 적은 없다.

-이 프로젝트의 가상 머신에 `virtio-balloon` 이 붙어 있는지조차 근거 문서에 적혀 있지 않다. libvirt 설정에 balloon 관련 요소가 있는지, 있다면 게스트 안에서 그 드라이버가 어떤 이름으로 올라와 있는지를 먼저 확인해야 한다. 장치가 없으면 balloon target 실험은 성립하지 않는다.
+이 프로젝트의 가상 머신에 `virtio-balloon` 이 붙어 있는지를 설정으로 확인한 기록이 없다. 앞 절의 §198 실측은 inflate 방향과 들어맞지만 근거 문서도 그것을 단정하지 않았다. libvirt 설정에 balloon 관련 요소가 있는지, 있다면 게스트 안에서 그 드라이버가 어떤 이름으로 올라와 있는지를 먼저 확인해야 한다. 장치가 없으면 balloon target 실험은 성립하지 않는다.

-값을 한 단계 바꿨을 때 게스트가 쓸 수 있는 메모리가 얼마나 움직이는지, 그 반영이 즉시인지 늦는지, 어느 값부터 게스트 안에서 회수와 스왑이 시작되는지도 재지 않았다. 호스트가 그 메모리를 언제 놓아주는지가 이 QEMU 버전과 이 backing 설정에서 어떻게 되는지도 마찬가지다. 두 확인은 각각 열린 질문으로 두었고 관계에 걸어 두었다.
+값을 한 단계 바꿨을 때 게스트가 쓸 수 있는 메모리가 얼마나 움직이는지, 그 반영이 즉시인지 늦는지, 어느 값부터 게스트 안에서 회수와 스왑이 시작되는지도 재지 않았다. 호스트가 그 메모리를 언제 놓아주는지가 QEMU 11.1.1 과 이 backing 설정에서 어떻게 되는지도 마찬가지다. 두 확인은 각각 열린 질문으로 두었고 관계에 걸어 두었다.

 <!-- body:end -->