DongHyeonkaandClaude Opus 5
2109f726fe
기록 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>
10 KiB
10 KiB
id, kind, slug, title, topic, topicName, project, status, questionStatus, studio, sourceRevision, source
| id | kind | slug | title | topic | topicName | project | status | questionStatus | studio | sourceRevision | source | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bded6560-dc8d-473d-966c-5b037bb84c4c | QUESTION | qemu-backend-vs-vhost-net-on-this-host | QEMU backend 와 vhost-net 의 차이가 이 호스트에서 실제로 보이는가 | network-virtualization | 네트워크 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/bded6560-dc8d-473d-966c-5b037bb84c4c/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
QEMU backend 와 vhost-net 의 차이가 이 호스트에서 실제로 보이는가
백엔드(backend)는 virtqueue 를 사이에 두고 게스트와 버퍼를 주고받는 호스트 쪽을 가리킨다. §107 은 패킷 처리를 QEMU 사용자 공간(userspace)에서 호스트 커널로 옮기면 컨텍스트 스위치와 사용자 공간 오버헤드가 줄어든다고 적었지만, 방향만 있을 뿐 이 호스트에서 두 백엔드를 나란히 재 본 값은 없다. §110 은 실제로 복사가 일어나는지가 커널 버전과 offload 를 비롯한 여러 조건에 따라 달라질 수 있다고 밝혔으니, 다른 환경의 수치를 이 호스트 값으로 옮겨 쓸 수도 없다. 이 물음은 §122 OQ-4 가 든 여섯 축을 이 호스트에서 나란히 재서 차이가 보이는지 가른다.
관계
- Guest 의 packet 이 Host Physical NIC 에 닿기까지 — virtio-net · virtqueue · vhost-net · TAP · Bridge 그 경로에서 두 백엔드가 갈리는 곳은 TAP 다음 한 칸이고, 이 물음은 거기서 무엇이 달라지는지를 잰다.
- 이 호스트에서 vhost-net 이 실제로 packet datapath 를 맡고 있는가 지금 어느 쪽으로 돌고 있는지가 정해져야 견줄 두 값 가운데 한쪽이 고정된다.
- 부하 중 network 가상화가 지연을 바꿀 만큼 호스트 CPU 를 쓰는가 두 물음이 QEMU CPU 와 Host CPU 를 같은 부하에서 읽으므로 측정을 한 번으로 묶을 수 있다.
- Keycloak 실험 결과를 애플리케이션 원인으로 읽기 전에 network 계층을 따로 검증한다 백엔드 차이가 지연에 얼마나 들어오는지를 이 물음이 재면, 그 기준이 그 값을 가져다 쓴다.
사실
- §107 은 QEMU 가 사용자 공간에서 패킷마다 I/O 를 처리하면 호스트 커널과 QEMU 사용자 공간 사이를 오가는 전환이 쌓인다고 적었다. 초당 패킷 수(packet rate)가 높아질수록 사용자 공간과 커널 사이의 전환 · 스케줄링 · 복사 · 알림 비용이 커질 수 있다.
- §107 이 적은 두 구성은 TAP 다음에 무엇이 오는지로 갈린다. QEMU userspace backend : TAP → QEMU → virtqueue vhost-net kernel backend : TAP → vhost-net → virtqueue
- §125 는 최종 기준 구조에 두 Data Path 를 나란히 그렸다. 열한 칸 가운데 다른 곳은 TAP 다음 한 칸이고, 거기에 vhost-net 이 오느냐 QEMU virtio backend 가 오느냐로 갈린다.
- §107 이 든 최적화 방향은 패킷마다 QEMU 사용자 공간이 끼어들던 처리를 커널 백엔드로 옮겨 컨텍스트 스위치와 사용자 공간 오버헤드를 줄이는 것이다.
- §110 은 virtio · virtqueue · vhost 구조가 버퍼 디스크립터(descriptor)로 불필요한 복사와 컨텍스트 스위치를 줄이도록 설계되어 있다고 적었다. 그렇다고 이를 항상 zero-copy 라고 일반화하면 안 된다고 못 박았다. 실제로 복사가 일어나는지는 아래에 따라 달라질 수 있다. Kernel version · QEMU version · vhost configuration offload · NIC capability · packet path · GSO/GRO/TSO
- §111 은 게스트와 호스트가 큐에 새 패킷이 들어왔음을 서로 알려야 한다고 적고, 패킷마다 인터럽트와 알림이 지나치게 많이 나가면 오버헤드가 커질 수 있다고 덧붙였다. 그래서 batching 과 interrupt moderation 과 queueing 이 중요하다.
- §117.4 는 초당 패킷 수가 높은 구간에서 QEMU 사용자 공간이 처리 경로를 직접 맡으면 CPU 오버헤드가 커질 수 있다고 밝혔다. 관찰할 것으로는 QEMU CPU usage · vhost thread · packet rate · latency · context switch 를 들었다.
- §122 OQ-4 는 비교할 축 여섯을 적었다. Latency Throughput QEMU CPU Host CPU Context Switch Packet rate
- §122 OQ-4 는 축의 이름만 적어 두었고, 여섯을 무슨 도구로 어떻게 재는지는 제3부에 없다. 같은 §122 에서 OQ-1 과 OQ-2 는 돌릴 명령을 그대로 적었고 OQ-3 은 lsmod | grep vhost 를 확인 후보로 들었다.
- §197 은 이 호스트의 판 번호를 실측으로 적었다. libvirt : 12.7.0 QEMU emulator version : 11.1.1 커널 : 7.2.2-arch1-1
- 그래서 §110 이 든 조건 여섯 가운데 kernel version 과 QEMU version 은 이제 적을 수 있다. vhost configuration 과 offload, NIC capability 는 이 호스트에서 읽은 값이 없다.
- §202 와 §204 는 게스트를 지우고 다시 세울 때 무엇이 사라지고 무엇이 남는지 적었다. 게스트 디스크와 시드 ISO 는 사라지고 base.qcow2 와 libvirt 의 default 네트워크 정의는 남으며, 재구축해도 IP 가 같다. 다만 백엔드를 바꿔 다시 세운 기록은 없다.
- 이 호스트에서 두 백엔드를 재 본 값은 SSOT 에 없다.
가정
- 같은 가상 머신을 다른 백엔드로 다시 구성해 띄울 수 있다고 본다. 그것이 이 실험 환경에서 되는지는 SSOT 에 적혀 있지 않다.
- 두 구성에 같은 부하를 걸 수 있다고 전제한다. 부하 도구와 요청 구성이 같아야 여섯 축을 견줄 수 있기 때문이다.
- 부하를 걸기 전 값과 부하 중 값의 차이가 백엔드 차이보다 작다고 전제하지 않는다. 그래서 부하 전 값을 먼저 찍어 둔다.
- 두 구성을 같은 시각에 나란히 돌릴 수 없다고 보고 차례로 잰다. 그 사이에 호스트의 다른 부하가 달라지면 값이 흔들릴 수 있다.
미지수
- 같은 부하를 두 백엔드로 돌렸을 때 여섯 축이 실제로 얼마나 달라지는지.
- 그 차이가 이 실험의 결과를 다르게 읽어야 할 만큼인지, 아니면 측정 흔들림 안인지.
- 이 호스트가 내는 초당 패킷 수가 §107 이 말한 「높아질수록 비용이 커지는」 구간에 들어가는지.
- 여섯 축을 이 환경에서 무엇으로 재는지. 제3부가 도구를 적지 않아 실행하는 쪽이 정한다.
제약
- 지금 백엔드가 무엇인지는 이 물음이 정하지 않는다. 그것을 확정하는 물음이 닫힌 뒤에 시작한다. §116 은 이 테스트 환경의 경로를 펼치면서 TAP 다음 칸에 vhost-net 을 적어 두었다. 그 칸이 실제로 그런지를 §122 가 OQ-3 으로 아직 묻고 있으므로 그 그림을 지금 백엔드의 근거로 쓰지 않는다.
- §110 이 든 조건들(kernel version · QEMU version · vhost configuration · offload · NIC capability · packet path · GSO/GRO/TSO)을 함께 적지 않으면 이 측정을 다른 환경에 재사용할 수 없다. 앞의 둘은 §197 이 이미 적었으므로 잴 때 나머지를 채운다.
- 이 호스트에서 잰 값이 없어 다른 장비의 백엔드 비교 수치를 근거로 삼지 않는다.
- 여기서 어느 백엔드로 실험을 고정할지는 정하지 않는다. 그것은 측정 결과가 나온 뒤의 Decision 이다.
선택지
1. 지금 백엔드만 먼저 찍어 나중에 견줄 값을 만든다
구성을 바꾸지 않고 부하 전과 부하 중의 여섯 축을 한 번씩 기록한다. 가상 머신을 다시 구성하지 않으므로 지금 돌고 있는 Keycloak 실험을 멈추지 않아도 되고, 나중에 다른 백엔드를 잴 때 견줄 값이 생긴다.
한 구성의 값만으로는 이 물음이 닫히지 않는다.
2. 두 백엔드로 바꿔 가며 같은 부하를 건다
§122 OQ-4 가 요구하는 비교가 이것이다. 같은 가상 머신을 다른 백엔드로 다시 구성하고 같은 부하를 양쪽에 걸어 여섯 축을 같은 시각에 기록한다. 차이가 나면 그 표가 그대로 Case 가 된다.
가상 머신을 다시 구성하고 재시작해야 하므로 그동안 Keycloak 실험을 멈춰야 하고, 두 측정 사이에 호스트 상태가 달라지지 않도록 관리해야 한다.
3. 문헌의 백엔드 비교 수치를 가져다 쓴다 — 제외
§110 은 실제로 복사가 일어나는지가 여러 조건에 따라 달라질 수 있다고 밝혔다. 그 조건은 kernel version · QEMU version · vhost configuration · offload · NIC capability · packet path · GSO/GRO/TSO 다. 조건이 이만큼 걸려 있으니 다른 환경에서 나온 수치는 이 호스트의 값이 되지 못한다. 이 물음은 이 호스트에서 잰 값으로만 닫힌다.
다음 검증
- 지금 백엔드가 무엇인지 먼저 확정한다. 그것을 묻는 물음이 닫히기 전에는 견줄 두 값 가운데 한쪽이 무엇인지 알 수 없다.
- 부하를 걸기 전에 여섯 축을 한 번 찍어 둔다.
- 지금 구성에 부하를 걸고 여섯 축을 같은 시각에 기록한다. Latency 와 Throughput 과 Packet rate 는 부하 도구가 내는 값을 쓰고, QEMU CPU 와 Host CPU 와 Context Switch 는 호스트에서 읽는다.
- 같은 가상 머신을 다른 백엔드로 구성하고 같은 부하를 걸어 3 을 되풀이한다.
- 두 구성의 여섯 축을 나란히 적고, §110 이 든 조건들과 실행한 명령을 함께 증거로 남긴다.
닫는 조건 : 두 구성의 여섯 축을 나란히 놓으면 닫는다. 차이가 부하 전 값의 흔들림 안이면 이 호스트가 내는 초당 패킷 수에서는 백엔드 선택이 결과를 바꾸지 않는다고 적고 닫는다. 차이가 나면 그 측정이 Case 가 되고, 어느 백엔드로 실험을 고정할지는 그 Case 뒤에 Decision 으로 넘긴다.