| r16 ➤ r17 |
| 49 | == [[엄지오(32기)]]의 주장에 대한 반박 == |
| 50 | 저거 일단 AI 써서 자기 무관하다고 한거 같은데, 절대 아님. |
| 51 | 사실 디도스라는 표현 자체는 틀린게 맞는데[* 정확한것은 낮고 느린 공격= 개요 == |
| 52 | [[엄지오(32기)]]의 디도스로 인곽위키가 장장 1일동안 멈추었던 사건이다. |
| 53 | 희진쌤이 노트북 닫아서 그런 것이라는 말은 거짓이다. |
| 54 | |
| 55 | ==[[엄지오(32기)]]의 주장에 대한 [[최희진(교사)]]의 입장표명== |
| 56 | 그 당시 노트북을 닫지 않았다! |
| 57 | 인곽위키가 되지 않는다 노트북을 켜야 한다는 말을 듣고 노트북을 확인했다. |
| 58 | 노트북 화면이 절전모드로 들어가 까만 것을 꺼진 것으로 착각하고 전원 버튼을 눌러서 꺼졌으나, 다시 켰다... |
| 59 | |
| 60 | == 원인 == |
| 61 | |
| 62 | == 결과 == |
| 63 | [[엄지오(32기)]]는 영구 밴을 '''또''' 먹을 예정이다. |
| 64 | |
| 65 | ==[[엄지오(32기)]]의 반박== |
| 66 | > 애초에 내가 아침에 요청 보낸건 상관없고 내가 요청 끝냈을때 서버 멀쩡했음 |
| 67 | > 몇시간 후에 1면때 희진쌤이 실수로 정보실에 있는 서버컴 꺼서 꺼진거임 |
| 68 | > 증인: 김규원 김도훈 희진쌤 |
| 69 | [* '''하지만''' 그 다음 꺼진 것이 김준서랑 이도혜가 동시에 커밋하다가 충돌났다는 말은 반은 맞고 반은 틀리다. 당일 오후 7시에 바로 수정하여 커밋을 올리고 김준서의 노트북으로 잘 돌아갔으나 갑자기 김준서의 추가적인 최적화 안된 커밋으로 에러가 뜬 것이다.] |
| 70 | |
| 71 | ===기술적인 반박=== |
| 72 | 인곽위키의 조회수 증가 로직을 보면, 내가 그때 초당 1~2회 수준의 /api/v2/page_view 요청을 계속 보냈는데, 디도스라고 하는 것은 개쌉오바를 떠는거라고 볼 수 밖에 없음ㅇㅇ |
| 73 | 디도스는 말 그대로 서비스 거부를 일으킬 정도의 과도한 트래픽이나 분산된 요청을 뜻하는데, 애초에 디도스 할거면 초당 몇천개씩 보냈겠지 |
| 74 | 그리고 내가 보낸 요청은 애초에 일반적으로 문서 보는것처럼 전체 문서 페이지(/w/...)를 계속 새로고침하는 것도 아님. |
| 75 | 그냥 문서 페이지를 열면 서버는 먼저 문서 원문을 가져오고, 렌더링을 수행한 뒤, 마지막에 별도로 조회수 증가 API를 호출함. |
| 76 | 근거: route/view_w.py의 320행, route/view_w.py의 336행. 코드는 깃허브에서 알아서 보셈 ㅇ |
| 77 | 다시 말해 /w/... 전체 요청은 “문서 조회 + 렌더 + HTML 생성 + 조회수 증가”까지 모두 포함하고 있음. |
| 78 | |
| 79 | 근데 나는 /api/v2/page_view/... 를 직접 호출해서 그보다 훨씬 좁은 처리 경로만 이용했음. |
| 80 | 따라서 /api/v2/page_view 2 req/s를 /w/... 전체 페이지 2 req/s와 같은 무게로 보는 것도 오바임... |
| 81 | 그리고 애초에 1초에 2번 요청도 못받으면 그게 서버임?? |
| 82 | |
| 83 | 그리고 Python 레이어의 구현도 이를 뒷받침한다고 볼수있음ㅇ. 조회수 API는 Python에서 자체적으로 무거운 비즈니스 로직을 처리하는 것이 아니라, 문서명을 받아 내부 Go 프로세스로 전달하는 브리지 역할임. |
| 84 | 근거: route/go_api_w_page_view.py의 3행, route/tool/func.py의 150행. |
| 85 | 그러니까 이 경로는 구조적으로 내부 서비스에 넘겨서 카운트만 갱신하는 단순 경로라고 할 수 있음. |
| 86 | 내가 매 요청마다 권한 계산이나 대규모 데이터 가공을 수행같이 복잡한거 시킨것도 아니고 단순한 요청만 보냈는데 진짜 뭐가문제임?? |
| 87 | |
| 88 | 추가로 데이터베이스 부분도 함께 보자면, 인곽위키는 SQLite를 사용하지만, 초기화 시 WAL 모드를 설정함. 근거: route/tool/func.py의 258행, app.py의 130행. |
| 89 | 여기서 WAL은 Write-Ahead Logging의 약자인데 이게 뭐냐면 데이터를 곧바로 원본 파일에 덮어쓰는 대신 먼저 “변경 내역을 별도의 로그 파일에 기록한 뒤 나중에 반영하는 방식”인데 이 방식의 장점은 읽기와 쓰기가 동시에 일어날 때 충돌을 줄여 준다는 점임. 일반적인 SQLite 기본 모드보다 동시 접근에 더 유리해가지고, 반복 요청이 곧바로 치명적인 DB 장애로 이어지는 가능성을 낮춰 줌... |
| 90 | 물론 WAL이 모든 문제를 해결하는 것은 아니긴해도 인곽위키가 WAL을 쓰고있는데, 그리고 2 req/s 수준의 저속 요청 밖에 안보냈는데, 이것때문에 사이트 다운됐다고 하기엔 좀 양심이.. |
| 91 | 애초에 2 req/s로 한시간 반 정도밖에 안했음 |
| 92 | |
| 93 | 그리고 위키 스파게티 코드문제 한두번 터지는 것도 아니고 실검 로직 이상하대서 실검 띄워지는지 해본건데 |
| 94 | 갑자기 몇시간 후에 책임 나한테 돌리는거부터 어이가 없음 ㄹㅇ |
| 95 | |
| 96 | ===결론 및 요약=== |
| 97 | 내 탓 아님 밴이나 푸셈 |
| 98 | |
| 99 | 첫째, 내가 요청을 마쳤을 당시 서버는 정상 동작 중이었다. |
| 100 | 둘째, 요청량 자체도 디도스라고 부를 수준의 폭주성 트래픽과는 거리가 있었다. |
| 101 | 셋째, 희진쌤이 서버컴을 껐다[[엄지오(32기)]]의 주장에 대한 [[최희진(교사)]]의 입장표명== |
| 102 | 그 당시 노트북을 닫지 않았다! |
| 103 | 인곽위키가 되지 않는다 노트북을 켜야 한다는 말을 듣고 노트북을 확인했다. |
| 104 | 노트북 화면이 절전모드로 들어가 까만 것을 꺼진 것으로 착각하고 전원 버튼을 눌러서 꺼졌으나, 다시 켰다... |
| 107 | 저거 일단 AI 써서 자기 무관하다고 한거 같은데, 절대 아님니다. |
| 108 | 사실 디도스라는 표현 자체는 틀린게 맞는데[* 정확한것은 낮고 느린 공격이며, 사실상 느리게 한다는것 빼고는 서버에 과부하를 주는 디도스와 다를바가 없다.] 결론적으로는 엄지오 때문에 일어난 일은 맞음다. |
| 109 | 서버에서 실검 처리하는 방식이 로그를 하나하나 다 본 다음에 갯수 세는 방식[* 지금은 아님니다.]인데, 엄지오가 거기에 얼마나 많은 리퀘를 보내놓아서 터진거임이다. 추가로 에러 뜬게 524에러인데, 이게 100초 타임아웃 에러임, 즉 동기 방식의 실검을 위해 사이트를 불러오는 과정에서 엄지오의 그 많은 로그를 하나하나 서버가 보다가 100초가 넘어서 뒤진거임이다. 희진쌤이 서버컴을 꺼서 인곽위키가 닫히면 다른 에러가 떠야함한다. |
