플랫폼 아키텍처는 무엇을 먼저 정하는가

한 줄 요약

플랫폼 아키텍처의 결정은 세 층에서 나옵니다. 되돌리기 어려운 것부터 먼저 정하고, 되돌리기 쉬운 것은 나중에 정합니다. 네트워킹과 스토리지는 앞이고, 컴퓨트 형태는 뒤입니다.

왜 이 순서가 중요한가

플랫폼을 새로 세울 때 사람들이 가장 먼저 고르는 것은 대개 컴퓨트입니다. 노드 크기, 오토스케일러, 배포 도구. 그런데 실제로 나중에 못 바꾸는 것은 그쪽이 아닙니다.

| 결정 | 바꾸는 비용 | 이유 |
| --- | --- | --- |
| 파드·서비스 CIDR | 클러스터 재구축 | 실행 중에 바꿀 수 없습니다 |
| CNI 와 정책 모델 | 전면 교체 | 워크로드 전체가 잠깐 끊깁니다 |
| 스토리지 클래스와 접근 모드 | 데이터 이관 | 볼륨을 새로 만들고 복사해야 합니다 |
| 노드 인스턴스 타입 | 노드 풀 교체 | 롤링으로 무중단 처리가 됩니다 |
| 배포 전략 | 매니페스트 수정 | 커밋 하나입니다 |

위 두 줄을 잘못 잡으면 나중에 "클러스터를 새로 만들자" 가 유일한 답이 됩니다. 아래 두 줄은 화요일 오후에 바꿀 수 있습니다. 그래서 설계 회의의 시간을 위쪽에 써야 합니다.

어떻게 동작하나

네트워킹: 주소 공간이 먼저입니다

파드 CIDR 은 클러스터가 자랄 수 있는 한계를 정합니다. /16 을 잡고 노드당 /24 를 나눠 주면 노드 상한이 256 대가 됩니다. 이것은 성능 문제가 아니라 산수 문제라서, 계산을 안 하면 반드시 나중에 벽에 부딪힙니다.

그다음이 정책 모델입니다. NetworkPolicy 는 기본이 허용이고, 한 파드에 정책이 하나라도 붙는 순간 그 파드는 그 방향에서 거부가 기본이 됩니다. 그래서 "일단 아무 정책도 안 걸어 두면 안전하다" 는 반대이고, "네임스페이스마다 기본 거부를 먼저 깔고 필요한 것만 연다" 가 시작점입니다.

스토리지: 접근 모드가 설계를 가릅니다

ReadWriteOnce 볼륨은 노드 하나에만 붙습니다. 이 사실 하나가 배포 전략을 결정합니다. RWO 볼륨을 쓰는 워크로드에 카나리를 걸면 새 파드가 볼륨을 못 잡고 기다리다가 배포가 멈춥니다. 그래서 상태를 가진 서비스는 블루/그린으로 가거나, 볼륨을 공유하지 않는 형태로 쪼개야 합니다.

컴퓨트: 노드 풀은 요구사항의 이름입니다

노드 풀을 나누는 기준은 "GPU 가 있다" 가 아니라 "이 워크로드가 요구하는 것이 다르다" 입니다. 그리고 그 요구는 nodeSelector·taints·tolerations 로 매니페스트에 적힙니다. 여기서 자주 나는 사고가 하나 있습니다. 워크로드는 pool: gpu 를 요구하는데 노드 어디에도 그 라벨이 없으면, 파드는 오류를 내지 않고 그냥 Pending 으로 남습니다. 컨트롤 플레인은 멀쩡하고 이벤트에만 한 줄이 남습니다.

현장에서 만나는 모습

한 팀이 노드를 세 대 늘리고 나서 "용량을 늘렸는데 파드가 여전히 안 뜬다" 고 했습니다. 새 노드에 풀 라벨을 안 붙였고, 그 워크로드는 라벨을 요구하고 있었습니다. 용량은 늘었지만 후보 노드는 0 대 그대로였습니다. 이런 종류의 사고는 "몇 코어가 남았나" 를 보면 절대 안 보이고, "이 선택자를 만족하는 노드가 몇 대인가" 를 세어야 보입니다.

그래서 분류(triage)의 첫 질문은 언제나 자원의 양이 아니라 후보의 수입니다. 후보가 0 이면 용량은 무의미합니다.

그다음 읽을 것

같은 클러스터를 여러 팀이 나눠 쓸 때, 그 나눔을 숫자로 다루는 방법을 이어서 봅니다.