사례2건

2건 중 1~2번째

1. IL-0479 가속기 노드의 조용한 데이터 손상이 오류 신호 없이 LLM 학습의 계산값과 기울기와 가중치를 바꿨다

   Amazon Web Services2025

   증상

   클라우드 플랫폼의 플릿 관리 테스트가 가속기 노드 15대를 SDC 때문에 운영에서 뺐다. SDC는 조용한 데이터 손상으로, 하드웨어가 아무 오류 신호 없이 틀린 계산 결과를 내는 고장이다. 이 노드들에서 학습해도 학습 손실은 대부분 정상 노드와 똑같이 나왔다.

   학습 발산과 손실 급등

   원인

   하드웨어 고장

   구성 요소

   –

   기여 요인

   모니터링 사각지대

   감지

   클라우드 플랫폼의 플릿 관리 스트레스 테스트가 SDC를 보인 노드를 잡아 운영에서 뺐다. 이 테스트는 결정적으로 실행한 작은 LLM 학습의 결과를 미리 계산한 정답과 비교해, 정답과 다르거나 실행마다 결과가 달라지면 SDC로 본다. 학습 손실만 봐서는 SDC가 드러나지 않았다.

   조치

   • 운영 마진 스트레스 테스트에서 떨어진 노드를 운영 가용 풀에 넣지 않았다.
   • 연구를 위해 잠시 붙잡아 둔 비정상 노드를 수리에 넘겨 운영 풀로 돌려보내기 시작했다.

   교훈

   SDC는 학습 손실에 뚜렷한 신호 없이 일어날 수 있다. Node 10의 SDC는 하위 모듈 계산과 기울기를 꾸준히 흔들었지만 학습 손실은 사전 학습과 미세 조정 내내 정상 노드와 같았다. 따라서 손실이 튀기 전에 SDC가 얼마나 오래 학습에 영향을 줬는지 알 수 없다. 학습 손실만 모니터링해서는 SDC를 놓칠 수 있고, 극단적인 경우 손실이 튀며 모델이 완전히 망가진다. 체크섬을 붙인 행렬 곱셈인 ABFT로는 SDC를 높은 정밀도와 재현율로 잡지 못했다. 그래서 그림자 데이터 병렬 복제본으로 다시 계산해 기울기를 비교하는 방법이 실제로 SDC를 잡는 가장 나은 방법일 수 있다.

   사례 보기
2. IL-0282 US-East 리전의 DynamoDB 스토리지 서버들이 멤버십 정보를 받지 못해 스스로 요청 처리에서 빠지면서 고객 요청의 약 55% 가 실패했다

   Amazon Web Services2015

   증상

   2:19am PDT 에 짧은 네트워크 장애가 있은 뒤 DynamoDB 고객 요청의 오류율이 치솟았다. 2:37am PDT 에는 오류율이 지난 3년 동안 겪은 어떤 수준보다 훨씬 높아졌고, 약 55% 에서 머물렀다.

   오류율 상승데이터베이스 과부하

   촉발

   2:19am PDT 의 짧은 네트워크 장애가 DynamoDB 스토리지 서버 일부에 영향을 줬고, 이 서버들이 한꺼번에 메타데이터 서비스에 멤버십 정보를 요청했다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   용량 계획 부재모니터링 사각지대재시도 폭주순환 의존과도한 영향 범위

   감지

   주 문제를 해결한 뒤 남은 낮은 오류율은 월요일에 고객들이 테이블이 updating 이나 deleting 단계에 멈췄다거나 오류율이 높다는 지원 케이스를 열면서 드러났다.

   조치

   • 용량 추가가 여러 번 실패한 뒤 5:06am PDT 에 메타데이터 서비스로 가는 요청을 멈췄다. 재시도가 줄어 메타데이터 서비스의 부하가 크게 덜어졌다.
   • 메타데이터 서비스가 관리 요청에 다시 응답하자 용량을 크게 늘렸다.
   • 메타데이터 서비스로 가는 요청을 다시 열고 스토리지 서버를 고객 요청 경로에 되돌렸다. 7:10am PDT 에 대부분의 고객과 AWS 서비스가 정상 운영을 이어 갈 만큼 오류율이 내려갔다.
   • 받아야 할 만큼 트래픽을 받지 못하던 메타데이터 파티션 하나를 전체 트래픽으로 되돌려 남은 오류를 월요일에 정리했다.

   후속 조치

   • 메타데이터 서비스의 용량을 이미 크게 늘렸다.
   • 멤버십 크기 같은 성능 지표를 더 엄격하게 모니터링해 상태를 파악하고 알맞은 용량을 미리 계획한다.
   • 스토리지 노드가 멤버십 정보를 요청하는 빈도를 줄인다.
   • 메타데이터 서비스가 요청을 처리하는 데 쓸 수 있는 시간을 늘린다.
   • DynamoDB 서비스를 나눠 메타데이터 서비스 인스턴스를 여럿 두고, 각 인스턴스가 스토리지 서버의 일부만 맡게 한다.
   • SQS 의 메타데이터 캐싱을 고쳐 메타데이터 테이블에 오래 접근하지 못해도 메시지 보내기와 받기가 계속되게 한다.
   • Auto Scaling 서버들에 작업을 나누는 방식을 바꿔 쌓인 스케일링 작업을 더 병렬로 처리한다.
   • 더 새로운 작업으로 대체된 오래된 스케일링 작업을 걸러 내는 장치를 넣는다.
   • 스케일링 작업을 처리하는 용량을 늘린다.
   • CloudWatch 가 DynamoDB 의 그룹 멤버십 데이터를 캐싱하는 방식을 바꿔, 갱신이 필요한 지표를 가능한 한 적게 줄인다.
   • write-through 캐싱으로 지표를 더 빨리 전달하는 기능을 개발한다. 이 캐시는 지표를 저장하기 전에 바로 보여 준다.
   • 타임아웃을 줄인 콘솔 로그인 코드를 며칠 안에 배포한다. 이 코드는 이미 테스트 과정에 들어가 있다.

   교훈

   AWS 는 멤버십 크기처럼 성능에 영향을 주는 값을 자세히 보지 않아 메타데이터 서비스에 필요한 용량을 미리 잡지 못했다. 전체 오류율이 낮아도 일부 고객에게는 오류가 몰릴 수 있다. AWS 는 이를 늦게 알아채 월요일에 상태 대시보드 게시가 늦었다. 콘솔 로그인은 성공하지 않아도 되는 API 호출에 아주 긴 타임아웃이 걸려 수십 초씩 막혔다. 이런 호출은 빨리 실패하고 로그인을 이어 가게 했어야 했다.

   사례 보기

원인별2