어떤 상황을 만들었는가

대상은 주문 서비스가 의존하는 내부 인증 서비스였다. 인증 서비스의 Deployment를 0으로 스케일해 완전히 사라진 상황을 만들었다. 트래픽은 실제 트래픽의 30%를 미러링한 스테이징 클러스터에서 받았다. 훈련 참가자는 SRE 두 명, 주문 서비스 개발자 한 명. 복구 문서 외에 다른 자료는 보지 않기로 했다.

kubectl -n auth scale deployment auth-api –replicas=0

무엇을 측정했는가

측정 항목은 셋이었다. 첫 알림이 뜨기까지의 시간, 원인을 특정하기까지의 시간, 서비스가 정상으로 돌아오기까지의 시간. 각각 감지·진단·복구로 부르기로 했다. 문서에는 복구 절차만 있고 감지와 진단은 없었다. 이것이 첫 발견이었다.

문서와 현실이 어긋난 지점

복구 문서의 3단계는 "인증 서비스를 재시작한다"였다. 재시작할 대상이 없으니 이 단계는 성립하지 않았다. 참가자는 Deployment가 사라진 것인지 Pod가 죽은 것인지 구분하는 데 4분을 썼다. 문서는 "죽어 있다"는 상황만 가정했고 "없다"는 상황은 가정하지 않았다.

두 번째 어긋남은 권한이었다. 복구 명령을 실행할 계정이 훈련 참가자에게 없었다. 실제 장애에서는 온콜 담당자가 권한을 갖고 있었겠지만, 훈련에서는 그 담당자가 참가하지 않았다. 문서에 "누가" 실행하는지가 빠져 있었다.

WARNING

시도한 방법과 버린 방법

처음에는 문서를 더 자세히 쓰는 방향으로 갔다. 분기점마다 "만약 ~라면" 절을 추가했다. 두 번째 훈련에서 이 문서는 너무 길어 읽는 데 시간이 더 걸렸다. 버렸다.

대신 문서를 진단 표와 복구 절차로 나눴다. 진단 표는 증상별로 확인할 명령 하나와 예상 출력을 적은 두 줄짜리 항목의 목록이다. 복구 절차는 진단 표의 결과에 따라 하나만 고른다.

yaml

복구 문서가 길어질수록 장애 중 읽기 어렵고, 짧을수록 분기 상황을 놓친다. — 문서를 진단 표(증상→확인 명령→예상 출력)와 복구 절차로 분리하고, 모든 절차에 실행 주체를 명시한다. — 문서 유지 비용이 두 배가 된다. 분기마다 훈련으로 검증하지 않으면 진단 표가 먼저 낡는다.

결과와 부작용

합계는 42분에서 16분으로 줄었다. 부작용도 있었다. 진단 표에 없는 증상이 나오면 참가자가 표를 뒤지느라 오히려 늦어졌다. 표의 마지막 항목을 "위에 없으면 온콜 리드 호출"로 고정했다.

다른 환경에 적용할 때의 조건

• 실제 트래픽의 일부를 미러링할 수 있는 스테이징이 있어야 한다. 없다면 훈련은 문서 읽기 연습에 그친다.
• 훈련 참가자에 온콜 권한 보유자를 반드시 포함한다.
• 한 번에 의존성 하나만 끊는다. 둘 이상 끊으면 원인은 추측으로 남는다.

최종 판단과 남은 과제

장애 훈련이 드러낸 것은 시스템의 약점이 아니라 문서의 가정이었다. 문서는 "죽는다"만 가정했고 "사라진다", "느려진다", "잘못 응답한다"는 가정하지 않았다. 다음 훈련은 인증 서비스가 살아 있지만 200ms 늦게 응답하는 상황이다. 아마 문서는 다시 어긋날 것이다.

평균이 감춘 것

요청 100건 중 99건이 40ms, 1건이 3,000ms면 평균은 약 70ms다. 대시보드에서 70ms는 정상 범위였다. p99를 함께 그리자 그래프는 완전히 다른 모양이 됐다. 매 시간 정각 부근에 p99가 2,800ms까지 올라갔다.

가설 세 개

• 정각에 도는 배치 작업이 같은 DB에 부하를 준다.
• 캐시가 정각에 일괄 만료되어 DB 조회가 몰린다.
• 특정 사용자 그룹의 요청만 느리다.

세 가설은 각각 확인 방법이 달랐다. 첫 번째는 배치 스케줄 확인, 두 번째는 캐시 TTL 분포, 세 번째는 사용자별 지연 분포. 셋 다 확인하는 데 하루가 걸렸고, 셋 다 아니었다.

분산 추적으로 좁히기

요청 하나가 거치는 경로를 스팬 단위로 기록하는 분산 추적을 켰다. 샘플링은 p99 이상 요청만 100% 저장하도록 조건을 걸었다. 느린 요청 200건을 모아 스팬별 소요 시간을 합쳤다.

python

느린 요청의 시간은 거의 전부 한 DB 쿼리에 있었다. 그런데 같은 쿼리가 빠른 요청에서는 6ms였다. 쿼리가 문제가 아니라 쿼리가 실행되는 조건이 문제였다.

병목의 실제 위치

DB 쪽 로그를 정각 전후로 좁혔다. 정각마다 통계 수집 작업이 같은 테이블에 잠금을 잡고 있었다. 범인은 DB 내부의 자동 통계 갱신이었다. 첫 가설이 절반은 맞았던 셈이다. 다만 우리가 만든 배치가 아니어서 스케줄 목록에 없었다.

NOTE

시도한 방법과 버린 방법

통계 갱신을 끄는 방법은 버렸다. 통계가 낡으면 쿼리 계획이 나빠져 전체 지연이 오른다. 대신 통계 갱신 시각을 트래픽이 가장 적은 새벽 3시 20분으로 옮기고, 갱신 중에는 읽기 요청을 복제본으로 보내도록 라우팅을 바꿨다.

정각마다 DB 자동 통계 갱신이 주 테이블 잠금을 잡아 p99가 급증한다. — 통계 갱신을 저트래픽 시간으로 고정하고, 갱신 시간대의 읽기 요청은 복제본으로 라우팅한다. — 복제 지연(최대 400ms) 동안 갱신 직후 데이터가 조회에 반영되지 않을 수 있다. 결제 확인 화면은 예외로 주 DB를 읽는다.

결과

p50은 변하지 않았다. 평균만 보고 있었다면 이 변경은 아무 효과가 없는 것처럼 보였을 것이다.

최종 판단

평균은 대다수 사용자의 경험을 말하고, p99는 가장 불행한 사용자의 경험을 말한다. 문의는 불행한 사용자에게서 온다. 대시보드의 기본 그래프를 평균에서 p50·p99 두 줄로 바꿨다.

공기의 한계는 어디인가

공기의 비열은 물의 약 1/4이고 밀도는 1/800이다. 같은 열을 옮기려면 공기는 물보다 부피로 3,000배 이상 흘러야 한다. 팬 속도를 올리면 소음과 전력이 급격히 늘고, 서버 내부 유속에는 물리적 상한이 있다. 실측에서 랙당 30kW를 넘으면 흡입 공기 온도를 18℃로 낮춰도 GPU 접합부 온도가 목표를 넘기기 시작했다.

세 가지 액체 냉각 방식

콜드플레이트 (Direct-to-Chip)

CPU·GPU 위에 금속판을 밀착시키고 그 안으로 물을 흘린다. 열의 70~80%를 액체가 가져가고 나머지 메모리·전원부는 여전히 공기가 식힌다. 기존 랙과 서버 폼팩터를 대부분 유지할 수 있어 가장 빠르게 도입된다.

침지 (Immersion)

서버 전체를 유전성 냉각유에 담근다. 팬이 필요 없고 열의 거의 100%를 액체가 가져간다. 대신 서버를 꺼낼 때 기름이 묻고, 광 모듈 등 일부 부품은 침지 호환 부품으로 바꿔야 한다.

후면 도어 열교환기

랙 뒷문에 물이 흐르는 열교환기를 달아 서버에서 나온 뜨거운 공기를 바로 식힌다. 서버는 그대로 공랭이지만 데이터센터 전체의 공조 부담이 줄어든다. 과도기 방식이다.

설계가 달라지는 지점

• 배관이 전력선과 같은 등급의 인프라가 된다. 누수 감지, 밸브, 이중화가 필요하다.
• 냉각수 온도가 높아도 된다. 콜드플레이트는 40℃ 입수로도 작동하므로 냉동기 없이 외기로 식히는 시간이 늘어난다.
• 서버 교체 절차에 배관 분리가 추가된다. 물이 새지 않는(드립리스) 커플러가 표준이 되었다.
• PUE(전력 사용 효율)가 1.5대에서 1.1대로 내려간다. 냉각 전력이 IT 전력의 절반에서 10% 수준으로 준다.

실측: 같은 랙, 두 방식

성능 차이는 스로틀링에서 나왔다. 공랭 랙은 6시간 중 세 번 클럭을 낮췄고, 총 처리량이 7% 낮았다.

도입 조건과 한계

WARNING

랙당 20kW 아래라면 공랭이 여전히 싸다. 30kW를 넘으면 콜드플레이트가 총비용에서 역전한다. 침지는 60kW 이상 또는 신규 건설에서 유리하다.

최종 판단

액체 냉각은 유행이 아니라 물리의 결과다. 칩의 발열 밀도가 공기의 열용량을 넘어선 시점에 선택지가 사라졌다. 남은 질문은 "어느 방식으로, 언제"다.

패스키가 바꾸는 것

패스키는 비밀번호 대신 기기에 저장된 공개키 쌍으로 인증한다. 서버에는 공개키만 있으므로 유출되어도 쓸 수 없고, 사이트마다 다른 키가 만들어져 피싱이 성립하지 않는다. 등록과 로그인은 WebAuthn 표준 API 두 개로 끝난다.

javascript

경로 1: 기기를 잃었을 때

동기화 패스키(iCloud 키체인, Google 비밀번호 관리자)는 같은 계정의 새 기기에서 복구된다. 그러나 플랫폼 계정 자체를 잃은 사용자, 또는 동기화를 끈 사용자는 복구할 길이 없다. 테스트 사용자 12명 중 3명이 여기에 해당했다.

설계 결정: 패스키를 등록할 때 반드시 두 번째 인증 수단(다른 기기의 패스키 또는 하드웨어 키)을 함께 등록하도록 강제했다. 하나만 등록한 상태로는 비밀번호 삭제를 허용하지 않는다.

경로 2: 회사 기기를 반납할 때

관리형 기기에서는 동기화가 조직 정책으로 꺼져 있는 경우가 많다. 기기 반납과 함께 패스키가 사라진다. 사용자는 로그인이 안 되는 이유를 모르고, 지원팀은 "비밀번호를 재설정하세요"라고 답하지만 비밀번호는 이미 없다.

관리형 기기의 기기 종속 패스키는 반납 시 함께 사라지며, 사용자와 지원팀 모두 이를 예상하지 못한다. — 계정에 등록된 패스키 목록을 사용자에게 항상 보여 주고, 마지막 사용 기기 외 인증 수단이 없으면 로그인마다 경고를 띄운다. 지원팀 도구에 "인증 수단 목록"을 첫 화면으로 추가한다. — 경고가 잦으면 무시된다. 30일에 한 번으로 빈도를 제한했고, 이 값은 운영 데이터로 조정한다.

경로 3: 공유 단말

매장 태블릿처럼 여러 사람이 쓰는 기기에서는 패스키를 기기에 저장하면 안 된다. 다음 사람이 생체 인증만으로 앞사람 계정에 들어갈 수 있다. 여기서는 휴대폰의 패스키를 QR로 연결하는 크로스 디바이스 인증을 쓰되, 태블릿에 저장하는 옵션은 서버가 거절해야 한다.

DEPRECATED

검증 결과

적용 조건

• 비밀번호를 완전히 없애기 전에 최소 90일간 두 방식을 병행한다.
• 지원팀 도구가 먼저 준비되어야 한다. 사용자 문의는 기능 출시 첫 주에 몰린다.
• 공유 단말이 있는 서비스는 서버 측에서 저장 옵션을 거절하는 정책을 먼저 구현한다.

최종 판단

패스키의 어려움은 암호학이 아니라 운영이다. 등록은 표준이 해결했고, 복구와 지원은 서비스가 해결해야 한다. 세 경로를 미리 검증하지 않았다면 출시 첫 주에 지원 문의로 알게 되었을 것이다.

왜 다이를 나누는가

웨이퍼의 결함 밀도가 일정하다면, 다이 면적이 두 배가 되면 양품률은 두 배 이상 떨어진다. 800mm² 다이의 양품률이 30%일 때 같은 공정으로 200mm² 다이를 만들면 양품률은 75%를 넘는다. 네 개를 이어 붙이는 비용이 추가되지만 버리는 실리콘이 훨씬 줄어든다.

공정을 섞을 수 있다

연산 코어는 최신 3nm 공정이 필요하지만 I/O와 메모리 컨트롤러는 7nm로 충분하다. 단일 다이에서는 전부 3nm로 만들어야 했다. 칩렛은 기능마다 알맞은 공정을 고른다. 비용의 절반 이상이 여기서 절감된다.

연결이 새 병목이 된다

칩 사이의 신호는 다이 내부 배선보다 느리고 전력을 더 쓴다. 인터커넥트 규격(UCIe 등)은 mm당 대역폭과 비트당 에너지로 평가된다. 패키지 기판 위에 실리콘 브리지를 놓는 2.5D, 다이를 수직으로 쌓는 3D 방식이 이 병목을 줄이려는 시도다.

설계 흐름이 달라진다

• 다이 하나를 설계하는 대신 칩렛 조합을 설계한다. 같은 I/O 칩렛을 여러 제품에 재사용한다.
• 열 설계가 어려워진다. 뜨거운 코어 칩렛 옆에 온도에 민감한 메모리 칩렛이 놓인다.
• 테스트가 두 단계가 된다. 칩렛 단위 테스트를 통과한 것만 패키지로 올린다(Known Good Die).
• 소프트웨어는 균일하지 않은 메모리 접근 시간(NUMA)을 더 세밀하게 다뤄야 한다.

제조 현장에서 어려운 것

NOTE

정렬 정밀도, 열팽창 계수 차이로 생기는 휨, 마이크로 범프의 접합 신뢰성. 이 세 가지가 패키징 라인의 주요 불량 원인이다. 연구실 사진의 현미경 정렬 작업은 양산에서는 자동화되지만, 공정 조건을 잡는 단계에서는 여전히 사람이 한다.

최종 판단

칩렛은 무어의 법칙을 연장하는 기술이 아니라 우회하는 기술이다. 한 장의 실리콘에서 얻을 수 있는 것이 줄어들자 여러 장을 잘 붙이는 것이 새 경쟁력이 되었다. 반도체 설계의 중심이 트랜지스터에서 연결로 옮겨 가고 있다.

왜 한 번에 바꿀 수 없는가

큰 테이블에 컬럼을 추가하거나 제약을 걸면 잠금이 걸리고, 그 시간 동안 쓰기가 멈춘다. 1억 행이면 몇 분에서 몇십 분이다. 애플리케이션 코드도 옛 스키마와 새 스키마 중 하나만 알고 있어서, 배포 순서가 조금만 어긋나도 오류가 난다. 그래서 변경을 단계로 나누고, 각 단계에서 옛것과 새것이 공존하게 한다.

1단계: 새 구조를 옆에 만든다

기존 테이블은 건드리지 않고 새 테이블을 만든다. 제약과 인덱스는 나중에 붙인다. 이 시점에 새 테이블은 비어 있고 아무도 읽지 않는다.

sql

2단계: 이중 쓰기

애플리케이션이 주문을 저장할 때 옛 컬럼과 새 테이블에 동시에 쓰도록 배포한다. 읽기는 여전히 옛 컬럼에서 한다. 이 배포 이후 생기는 데이터는 양쪽에 모두 있다. 이중 쓰기 실패는 로그만 남기고 요청을 실패시키지 않는다. 새 테이블은 아직 진실의 원본이 아니다.

3단계: 백필

이중 쓰기 시작 이전의 데이터를 새 테이블로 복사한다. 1억 행을 한 번에 옮기면 복제 지연과 잠금이 생긴다. 5,000행씩 끊어 옮기고, 각 배치 사이에 복제 지연을 확인해 200ms를 넘으면 잠시 멈춘다.

python backfill.py –batch 5000 –max-lag-ms 200 –table orders

4단계: 검증

두 저장소가 같은지 확인한다. 전체 행 수 비교, 무작위 1만 행의 값 비교, 그리고 이중 쓰기 시작 시점 전후 1시간 구간의 전수 비교. 여기서 3,200건의 불일치를 찾았다. 이중 쓰기 배포와 백필 시작 사이의 12분 동안 갱신된 행이었다. 그 구간만 다시 백필했다.

WARNING

5단계: 읽기 전환과 정리

읽기를 새 테이블로 옮긴다. 기능 플래그로 1%부터 시작해 하루에 걸쳐 100%로 올렸다. 일주일 동안 옛 컬럼에도 계속 썼다. 문제가 없어 이중 쓰기를 끄고, 다시 일주일 뒤 옛 컬럼을 삭제했다.

단계마다 되돌릴 수 있어야 하지만, 단계가 많을수록 기간이 길어지고 이중 쓰기 코드가 오래 남는다. — 읽기 전환 후 일주일, 이중 쓰기 중단 후 일주일의 관찰 기간을 두고, 각 단계 종료 조건을 수치로 미리 정한다(불일치 0건, 오류율 변화 없음). — 전체 6주가 걸렸다. 한 번에 바꾸면 하루면 되지만 30분 이상의 쓰기 중단을 감수해야 한다.

결과

최종 판단과 남은 과제

무중단 마이그레이션은 기술이 아니라 순서다. 다섯 단계 어느 것도 어렵지 않지만, 순서를 바꾸거나 하나를 건너뛰면 데이터가 어긋난다. 남은 과제는 이 순서를 코드로 만드는 것이다. 다음 마이그레이션에서는 단계 전환 조건을 자동 검증하는 도구를 먼저 만들 것이다.

두 장의 프로파일

직후 프로파일은 180MB, 직전은 1.9GB였다. 차이의 92%가 한 곳에 있었다. 요청마다 만든 HTTP 클라이언트가 닫히지 않고 연결 풀에 남아 있었다.

go

결과

배운 것

재시작으로 덮어 둔 문제는 시간이 갈수록 원인 추적이 어려워진다. 프로파일 두 장은 30분이면 찍는다.

측정

토크나이저가 CPU 한 코어에서 순차 실행되고 있었다. 병렬화하자 GPU 대기 시간이 절반으로 줄었다.

전력 제한

두 번째 병목은 서버 전원이었다. GPU 4장이 동시에 부하를 받으면 전원 공급 한계로 클럭이 내려갔다. 열화상으로 확인한 전원부 온도는 91℃였다.

판단

모델은 바꾸지 않았다. 병목은 모델 밖에 있었다.

측정 장비

• 3년 전에 나온 보급형 안드로이드 기기 2대
• 240fps 카메라로 탭 시점과 화면 변화 시점을 프레임 단위로 비교
• 프로그래머블 입력 장치로 동일 지점을 100회 탭

원인

탭 이후 240ms 동안 메인 스레드가 한 작업에 묶여 있었다. 목록 필터링이 한 번에 3,000개 항목을 처리했다.

javascript

판단

실험실은 사용자 기기를 닮아야 한다. 개발 노트북은 사용자 기기가 아니다.

현장에서 하는 일

팬 없는 산업용 컴퓨터에서 진동 스펙트럼을 계산하고 이상 점수만 1분에 한 번 올린다. 원본은 현지 디스크에 7일 보관하고, 이상이 감지된 구간만 요청 시 올린다.

NOTE

끊김 처리

통신이 끊기면 요약을 로컬 큐에 쌓고 복구되면 순서대로 올린다. 큐는 72시간분을 감당한다. 실제 최장 단절은 31시간이었다.

판단

엣지는 클라우드의 축소판이 아니다. 끊김이 예외가 아닌 정상 상태인 곳을 위한 다른 설계다.