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>
6.8 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 | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2acec7d5-3eaf-4115-9d61-45647c4ec01e | QUESTION | is-production-on-a-hypervisor | 운영 서버는 CPU 가상화 계층의 영향을 받는 구조인가 | cpu-virtualization | CPU 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/2acec7d5-3eaf-4115-9d61-45647c4ec01e/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
운영 서버는 CPU 가상화 계층의 영향을 받는 구조인가
운영 서버가 bare-metal 인지 상위 하이퍼바이저나 클라우드 가상 머신 위인지는 SSOT 에 적혀 있지 않다. §25 의 진단표에는 Virtualization 과 Host 계층에만 걸리는 행이 따로 있어서, 그 구조가 정해져야 어느 행을 운영 진단에 쓸지 고를 수 있다.
관계
- KVM 에서 vCPU 가 물리 CPU 에서 실행되기까지 운영 서버가 가상 머신 위라면 무엇이 더 끼어드는지를 설명한 기록이다.
사실
§18 은 호스트 OS 에 K3s 를 직접 설치했을 때의 CPU 경로를 적었다. 컨테이너에서 도는 작업은 K3s 와 컨테이너 런타임을 지나 호스트 Linux 스케줄러로, 다시 물리 CPU 로 간다.
그 호스트 위에 별도 가상 머신이 없다면 그 작업이 QEMU 와 /dev/kvm, KVM, VMX 경로를 타지는 않는다. 컨테이너의 프로세스는 호스트 커널을 공유하고 호스트 스케줄러가 직접 스케줄링한다.
가상 머신 안에 K3s 를 구성하면 계층이 더 붙는다. §18 이 든 것은 게스트 Linux 와 K3s, vCPU, QEMU vCPU 스레드, 호스트 Linux 스케줄러, KVM / VMX 다. 그래서 같은 부하 테스트라도 가상 머신 기반 환경에서는 호스트 가상화 자원 병목을 추가로 확인해야 한다.
§20 의 OQ-6 은 두 경로를 K3s -> Host Scheduler -> Physical CPU 와 K3s -> Guest -> vCPU -> Hypervisor -> Physical CPU 로 나란히 적고, 구조에 따라 진단 지표가 달라진다고 밝혔다.
§25 의 진단표는 문제마다 주된 계층을 갈라 적었다.
vCPU 과다 할당 : VM 구성 CPU overcommit : Host 구성 CPU contention · Scheduling latency : Host Scheduler 잘못된 pinning : Host / VM 설정 과도한 VM Exit : KVM / VMX Steal time 증가 : Guest 에서 관측 Host CPU saturation : Host
§218 은 운영을 desktop 이라 부르고 그 배치를 nginx → 127.0.0.1:30080(NodePort) → Traefik 으로 적었다. 이 실험대의 배치와 다른 것은 단일 노드냐 2노드냐 하나다.
§284 는 그 desktop 이 Ubuntu 라고 적는다. 같은 절이 이 실험대가 sites-available 방식을 쓰는 이유도 적었다. 「운영(desktop)이 Ubuntu라 그 구조를 쓰고 있으므로, 설정을 운영으로 옮길 때 경로가 그대로 맞는 편이 낫다는 판단이다.」 SSOT 가 운영과 같다고 적은 것은 그 2홉 경로와 이 설정 관례 둘이다.
운영 서버가 bare-metal 인지 상위 하이퍼바이저나 클라우드 가상 머신 위인지는 SSOT 에 적혀 있지 않다.
가정
운영 서버도 K3s 로 Keycloak 을 돌린다고 전제한다. §20 이 나눈 두 경로는 둘 다 K3s 에서 시작한다.
운영 서버가 그 두 갈래 중 하나라고 전제한다. 중첩 가상화처럼 계층이 더 들어가는 구성은 이 물음에 넣지 않았다.
구조가 정해지면 §25 의 진단표를 운영 진단에도 그대로 쓴다고 전제한다. 진단표를 만든 근거는 이 테스트 환경이다.
미지수
운영 서버가 bare-metal 호스트에 직접 K3s 를 설치한 것인가, 상위 하이퍼바이저나 클라우드 가상 머신 위에 있는가.
하이퍼바이저 위라면 그 호스트의 CPU 지표를 볼 수 있는가. 클라우드 가상 머신이면 호스트 쪽 실행 대기열과 사용률을 읽을 수 없어 §25 의 Host 행을 그대로 쓰기 어려워진다.
운영 서버에 직접 붙어 명령을 돌릴 수 있는가.
제약
이 물음은 부하를 걸어 재는 것이 아니라 구성을 확인해서 닫는다.
§14.1~§14.3 은 그 장비가 가상 머신을 직접 돌리는 호스트인지를 보여 준다. 그 장비 자신이 어떤 하이퍼바이저의 게스트인지는 이 세 명령이 말해 주지 않는다.
구조가 정해지기 전에는 §25 의 어느 행을 운영 진단에 넣을지 고를 수 없다.
§25 는 그 표의 목적을 「하나의 지표로 장애 원인을 확정하는 것이 아니라, 어느 계층부터 조사해야 하는지 범위를 줄이는 것」이라고 적었다. 그래서 이 물음이 닫혀도 운영 장애의 원인이 정해지는 것은 아니다. 정해지는 것은 어느 계층부터 조사할지다.
선택지
1. 구성 기록과 도입 경로로 확인한다
서버를 어떻게 마련했는지 남은 기록으로 bare-metal 인지 하이퍼바이저나 클라우드 가상 머신 위인지 가른다. 운영 서버에 붙지 않아도 되고 부하도 걸지 않는다.
기록이 실제 구성과 어긋나 있으면 어긋난 채로 적히므로 2번과 함께 쓴다.
2. 서버에 붙어 명령으로 확인한다
§14.1~§14.3 의 grep -E 'vmx|svm' /proc/cpuinfo · lsmod | grep kvm · ls -l /dev/kvm 로 그 장비가 가상 머신을 직접 돌리는 호스트인지부터 적는다. 이어서 게스트 안에서 top 의 %st 가 관측되는지 본다.
세 명령이 모두 비어 있으면 그 장비가 가상 머신을 직접 돌리지는 않는다는 뜻이고, 그 위에 하이퍼바이저가 있는지는 1번의 구성 기록으로 가른다.
3. 제외 — 테스트 환경의 구조를 운영에 옮겨 적는다
테스트 환경이 가상 머신 위라는 것이 운영 서버의 구조를 말해 주지 않는다. 두 환경을 같다고 적으면 §25 의 Virtualization 행을 근거 없이 운영 진단에 넣게 된다.
다음 검증
- 운영 서버의 구성 기록이나 도입 경로로 bare-metal 인지 하이퍼바이저 / 클라우드 가상 머신 위인지 확인한다.
- 서버에 붙을 수 있으면 §14.1~§14.3 의 grep -E 'vmx|svm' /proc/cpuinfo · lsmod | grep kvm · ls -l /dev/kvm 으로 그 장비가 가상 머신을 직접 돌리는 호스트인지 적는다.
- 게스트 안에서 top (§14.8) 의 %st 가 관측되는지 함께 본다.
닫는 조건 : 운영 서버가 bare-metal 로 확인되면 §25 의 Virtualization · Host 행을 운영 진단에서 빼도 된다고 적고 닫는다. 하이퍼바이저나 클라우드 가상 머신 위로 확인되면 그 사실이 운영 진단의 전제가 되고, §25 의 어느 행을 운영에서 쓸지는 그 뒤 Decision 이 정한다.