엄지오(32기) 디도스 사건 (비교)

r6 ➤ r7
9	[[엄지오(32기)]]는 영구 밴을 '''또''' 먹을 예정이다.
10
11	==반박==
12	애초에 내가 아침에 요청 보낸건 상관없고 내가 요청 끝냈을때 서버 멀쩡했음
13	몇시간 후에 1면때 희진쌤이 실수로 정보실에 있는 서버컴 꺼서 꺼진거임
14	증인: 김규원 김도훈 희진쌤
15	그리고 그 다음 꺼진건 김준서랑 이도혜가 동시에 커밋하다가 충돌난거임
16
17	===기술적인 반박===
18	인곽위키의 조회수 증가 로직을 보면, 내가 그때 초당 1~2회 수준의 /api/v2/page_view 요청을 계속 보냈는데, 디도스라고 하는 것은 개쌉오바를 떠는거라고 볼 수 밖에 없음ㅇㅇ
19	디도스는 말 그대로 서비스 거부를 일으킬 정도의 과도한 트래픽이나 분산된 요청을 뜻하는데, 애초에 디도스 할거면 초당 몇천개씩 보냈겠지
20	그리고 내가 보낸 요청은 애초에 일반적으로 문서 보는것처럼 전체 문서 페이지(/w/...)를 계속 새로고침하는 것도 아님.
21	그냥 문서 페이지를 열면 서버는 먼저 문서 원문을 가져오고, 렌더링을 수행한 뒤, 마지막에 별도로 조회수 증가 API를 호출함.
22	근거: route/view_w.py의 320행, route/view_w.py의 336행. 코드는 깃허브에서 알아서 보셈 ㅇ
23	다시 말해 /w/... 전체 요청은 “문서 조회 + 렌더 + HTML 생성 + 조회수 증가”까지 모두 포함하고 있음.
24
25	근데 나는 /api/v2/page_view/... 를 직접 호출해서 그보다 훨씬 좁은 처리 경로만 이용했음.
26	따라서 /api/v2/page_view 2 req/s를 /w/... 전체 페이지 2 req/s와 같은 무게로 보는 것도 오바임...
27	그리고 애초에 1초에 2번 요청도 못받으면 그게 서버임??
28
29	그리고 Python 레이어의 구현도 이를 뒷받침한다고 볼수있음ㅇ. 조회수 API는 Python에서 자체적으로 무거운 비즈니스 로직을 처리하는 것이 아니라, 문서명을 받아 내부 Go 프로세스로 전달하는 브리지 역할임.
30	근거: route/go_api_w_page_view.py의 3행, route/tool/func.py의 150행.
31	그러니까 이 경로는 구조적으로 내부 서비스에 넘겨서 카운트만 갱신하는 단순 경로라고 할 수 있음.
32	내가 매 요청마다 권한 계산이나 대규모 데이터 가공을 수행같이 복잡한거 시킨것도 아니고 단순한 요청만 보냈는데 진짜 뭐가문제임??
33
34	추가로 데이터베이스 부분도 함께 보자면, 인곽위키는 SQLite를 사용하지만, 초기화 시 WAL 모드를 설정함. 근거: route/tool/func.py의 258행, app.py의 130행.
35	여기서 WAL은 Write-Ahead Logging의 약자인데 이게 뭐냐면 데이터를 곧바로 원본 파일에 덮어쓰는 대신 먼저 “변경 내역을 별도의 로그 파일에 기록한 뒤 나중에 반영하는 방식”인데 이 방식의 장점은 읽기와 쓰기가 동시에 일어날 때 충돌을 줄여 준다는 점임. 일반적인 SQLite 기본 모드보다 동시 접근에 더 유리해가지고, 반복 요청이 곧바로 치명적인 DB 장애로 이어지는 가능성을 낮춰 줌...
36	물론 WAL이 모든 문제를 해결하는 것은 아니긴해도 인곽위키가 WAL을 쓰고있는데, 그리고 2 req/s 수준의 저속 요청 밖에 안보냈는데, 이것때문에 사이트 다운됐다고 하기엔 좀 양심이..
37	애초에 2 req/s로 한시간 반 정도밖에 안했음
38
39	그리고 위키 스파게티 코드문제 한두번 터지는 것도 아니고 실검 로직 이상하대서 실검 띄워지는지 해본건데
40	갑자기 몇시간 후에 책임 나한테 돌리는거부터 어이가 없음 ㄹㅇ
41
42	===결론 및 요약===
43	내 탓 아님 밴이나 푸셈
44
45	첫째, 내가 요청을 마쳤을 당시 서버는 정상 동작 중이었다.
46	둘째, 요청량 자체도 디도스라고 부를 수준의 폭주성 트래픽과는 거리가 있었다.
47	셋째, 희진쌤이 서버컴을 껐다.