7P by before30 2달전 | favorite | 댓글 6개

## 1. Charity Majors, CTO of Honeycomb
- 특정 지역(동유럽)의 사용자에게 push noti가 가지 않음
- ASG 사이즈 변경 직후부터 발생
- Round Robin DNS record가 UDP 패킷 사이즈를 넘어가서 발생

## 2. Matthew Fornaciari, CTO of Gremlin
- 디스크가 꽉차서 로그를 쓰지 못해 장애 발생
- 로그 로테이팅 기능 개발
- 디스크 사용량 얼럿 설정
- Gremlin을 통해 테스트 가능하게 추가 (카오스엔지니어링)

## 3. Lirran Haimovitch, CTO of Rookout
"매일 특정 시간에 서버가 다운된다는 도시 전설,
몇주에 걸친 조사 끝에 보안 카메라에서 원인 발견,
청소부가 진공 청소기 연결을 위해 서버 연결을 끊었음"

## 4. Daniel "Spoons" Spoonhower, CTO of Lightstep
- 앱 로딩이 되지 않음
- 당일 배포, 인프라 변경 없었음
- 내부 사용자들만 되지 않는 것으로 확인
- 앱로드용 api 확인중 내부 사용자의 경우 추가 데이터 반환부분 확인
- 지난 몇 주 동안 천천히 payload가 증가하다 그 날 오후 최대 payload 크기를 넘기면서 앱 로딩 실패

## 5. Lee liu, CTO of LogDNA

## 6. Ting Huang, CTO of Transpoit
- 트위터 모바일에서 읽을 수 없음
- 신규라이브러리에서 세션 쿠키 파싱을 못하는 문제 발견

kunggom 2달전  [-]

내용이 요약되지 않은 5번의 경우는 인증서 만료 관련이네요.
인증서 기한이 예정대로 만료되어도 문제 없을 것이라고 생각했지만 그건 새로 개발한 시스템에만 해당하는 이야기였고, 여전히 쓰이던 레거시 시스템에서는 문제가 발생하였다는 이야기입니다. 하필이면 사용하던 CI/CD 솔루션에서도 같은 문제가 터져서 일이 더 복잡했다고.

kbumsik 2달전  [-]

"청소부가 진공 청소기 연결을 위해 서버 연결을 끊었음"
오메야...

kunggom 2달전  [-]

원문을 읽어보니 해당 내용은 운을 떼기 위한 것이었고, 실제 장애는 고객사 측 관리자가 회의할 때나 가끔 쓰는 쿼리가 테이블 전체를 잠궜기 때문에 그때마다 백엔드 서비스의 지연 시간이 한도 없이 늘어났다는 이야기네요. 의심가는 쿼리를 최적화했지만 헛다리짚은 것이라서, 고객사 측이 페이지가 너무 느리다고 새로고침을 반복할 때마다 계속 같은 현상이 발생했다고.

kunggom 2달전  [-]

비슷하다면 비슷한 개인 경험 하나. 프리랜서로 급히 들어온 쇼핑몰 관련 일 하나를 맡았을 때입니다.
새벽에 쇼핑몰에서 큰 작업(솔루션의 대대적인 버전업)을 실시하고, 상품 결제 등 주요 기능에 문제가 없는 것을 확인한 후 재개장하였습니다. 그런데 오후 들어서 갑자기 쇼핑몰 웹사이트가 너무 느려지더니, 급기야는 거의 멈출 지경이 되더군요. 알고 보니 원인은 쇼핑몰에 별도로 붙어 있던 판매자용 페이지 때문이었습니다. 쇼핑몰 솔루션에 커스텀 개발한 판매자용 관리페이지를 붙여 운영하고 있었는데, 거기 들어가는 순간 아주 무거운 쿼리가 실행되더군요. 쇼핑몰 재개장 후에 개별 판매자들이 판매 현황을 보려고 접속할 때마다 MySQL에 부하가 커져서 결국 쇼핑몰 자체가 느려진 것이었습니다. 보니까 관련 테이블에 어째서인지 인덱스가 제대로 안 걸려 있더군요. 결국 인덱스를 제대로 걸어주고 몇몇 파라미터를 튜닝하는 것으로 쇼핑몰 자체가 느려지는 것을 해결할 수 있었습니다.

kbumsik 2달전  [-]

오 경험 공유 감사합니다.
하긴 어드민이나 비즈니스 판단을 위한 자료는 aggregation을 쓰다보니 부하가 많이 가겠네요. 웹개발자가 아니라서 잘은 모르겠지만 요즘 그런건 데이터 엔지니어링이랍시고 데이터를 따로 모아두는 모양이던데요.

kunggom 2달전  [-]

말씀하신 대로 그런 데이터들은 별도로 분리시켜 처리하는 것이 정석이겠지만, 제가 작업했던 쇼핑몰은 불합리한 곳이 꽤나 많은 레거시 시스템이었는지라 그런 아키텍쳐상의 고려는 전혀 되어 있지 않았습니다. 굉장히 오래된 버전(InnoDB가 아니라 MyISAM이 기본 엔진이던 시절의 버전)의 MySQL이 역시 오래된 버전의 Apache 웹 서버와 함께 같은 VM 인스턴스 내에서 돌고 있었습니다. 쇼핑몰을 운영하기 위한 솔루션 또한 이미 레거시로 분류되어 패치만 나오고 있는 상황이었습니다. 작업 중에 느꼈던 솔루션의 구조적인 문제는 아예 처음부터 새로 개발한 신규 버전에서는 해결된 모양이었지만, 레거시 버전을 만지는 저에게 그 점은 아무런 영향도 주지 못했습니다. 그게 벌써 작년 일이네요.