• KT PC대수 제한 경험기(?)  (추가단말 검사로 인한 웹소켓 장애 체험기)

    KT PC대수 제한 경험기(?) (추가단말 검사로 인한 웹소켓 장애 체험기)

    최근에 웹소켓 서비스쪽 작업중에 이상한 문제가 발생했다. 문제가 없던 웹소켓 서버에 접속이 안되는 문제가 발생한 것이다. 새로고침도 여러번 하고 브라우저도 바꾸어보아도 여전히 접속이 불가능했다. 지인분들을 통해 나에게만 발생하는 문제임을 확인했다. 그제서야 뭔가 문제가 있음을 느끼고 무슨일이 일어나고 있는지 살펴 보았다. WS 요청을 했는데 200이 온다고? 가장 먼저 개발자 도구를 열어보았다. 개발자 도구에서 네트워크 패널을 보면 브라우저가 어떻게 통신을 했는지 간단하게 볼 수 있다. 네트워크 패널을 이용하여 웹소켓 요청을 찍어봤는데, 응답 코드로 101이 아닌 200이 오는것을 확인하였다. WS upgrade를 요청하면 101이 나와야 함이 정상인데 200이 온 것이다. 해당 웹소켓 서버는 내가 제작을 한 것이었는데, 기억에 분명 200을 리턴하는 코드는 작성한 적이 없었다. 혹시 특정 상황에서 내가 200을 리턴하도록 한 것이 있나? 해서 살펴 봤는데 전혀 없었다. 또한 저런 응답헤더를 찍어내는 코드는 전혀 없었다. 웹소켓 백엔드 서버에서 발생하는 문제는 아닌것으로 판단하고, 그 앞단을 살펴 보기로 했다. 이 서버는 [유저 -> CDN -> WS서버] 의 접속 구조를 가지고 있다. WS서버의 문제는 아닌것을 확인했으니 CDN을 파 보아야 할 차례였다. 빠르게 해당 CDN을 경유하여 WS를 접속하는 다른 사이트를 찾아보았다.  결과는 정상이었다. 몇번을 시도해 보았고, 수신지 IP가 동일함 까지 확인해 보았다. 테스트 도중 위의 요청 헤더가 이상함을 한번 더 확인하였다. CDN 에서 요청을 내려줬으면 CDN 특유의 헤더가 찍혀야 하는데, 그런것이 전혀 없다. 일단 Response가 나온다는거면 아무리 CDN이 꼬여도 특정 헤더 하나정도는 찍혀야 마땅하다. 즉, 하나 정도는 묻혀 나와야 할 헤더가 없던 것이다. (예를 들어, Cloudflare라면 server: cloudflare 등의 헤더가 있어야 한다) 사실 처음에는 CDN 내부에서 오류가 발생했거나, GET / 요청이 캐싱되어서 GET…

  • (단일) 실패지점

     서버를 운영하다 보면 서버 장에 대응에 대한 고민이 생긴다. 서버란 어찌되었건 “끊김이 없어야 하는 것”이다. 단 몇분이라도 서버에 장애가 발생하면 사용자는 불편을 느낄 뿐더러 신뢰성을 잃을수 조차 있다. 쇼핑몰 서버에서 피크 타임시 발생하는 장애는 하루 매출의 반 이상을 잃게 할 수도 있다. 특정 목적의 서비스 중이라면 SLA에 따라 보상금까지 물어야 할 수도 있다. 이해가 쉽도록 “서버”를 “방송”으로 바꾸어보자. 방송사의 장비에 불량이 생겨서 몇 분 동안 검은 화면만 송출되었다고 생각하면 얼마나 큰 일인지 생각할 수 있을거다. 자체 방송중에 검은화면만 나와도 큰 일인데, 광고 타임에 검은 화면만 나왔다면 (계약에 따라) 손해배상을 해야 할 수도 있다. 증상을 조기에 알아낸다고 해도 수정·패치 작업에는 또 긴 시간이 필요하다. IT운영 인력이 부족할 경우 ‘증상이 있음’을 알아내는것 조차 어려울 수 있다. 그렇기에 가장 중요한것은 애초에 장애가 나지 않도록 하는 것이다. 어느 호스팅사에서 월 1만원짜리 웹 호스팅을 받고있다고 하자. 당장 보이는건 해당 호스팅 업체에 있는 내 사이트밖에 없다. 하지만 그 아래에는 서버의 위치 (가정집, 사내, IDC)와 회선 정보, 그리고 서버 관리능력과 안정성이 깔려있다. 사실 이런 걱정을 모두 호스팅사에 넘기기 위해 (Managed) 웹 호스팅을 쓰는것은 맞지만, 어쨋든 장애가 나면 손해는 내가 보는것이다. 단순한 웹서버라고 해도 안을 까보면 상당히 많은 구성요소가 깔려있다. 당장 글을 쓰면서 생각나는것만 해도 서버의 지리적 위치, 인터넷(회선·대역폭), 내부 장비(스위치등 일체), 전기, 무정전 시스템, 네임 시스템 서버, 물리적인 서버, 그리고 그 안에 설치된 소프트웨어 Nginx·Apache등 웹 서버 프로그램, DBMS…

  • 유챗 봇 제작 #2 – 접속정보 처리

     이전까지의 글에서는 유챗 서버와의 통신에 필요한 맨 아랫 부분을 다루어 보았다. 여기서 부터는 밑바닥에 대한 부분에서 벗어나서 실질적으로 봇을 이용하기 위한 (일종의) 클래스를 구현해 볼 것이다.  글을 쓰는 도중에 tokio가 1.0으로 버전이 올라갔다. 아직 종속된 라이브러리들이 1.0을 지원하지 않아서 0.3버전을 바탕으로 글을 작성하였다. 1.0 버전으로 올리는 과정에 대해서는 따로 글을 쓸 것 같지는 않으니, 필요가 있으면 직접 Github의 리포를 확인해야 할 것이다.  이전글에서는 아래와 같은 코드를 이용해서 직접적으로 접속 정보를 전송하였다:  하지만 위의 코드로는 접속정보를 바꾸기가 쉽지 않다. 여러개의 방에 접속하기 위해서는 매번 접속정보를 생성 해 줘야 하며, 인증 토큰을 필요로 하는 방에 접속하려면 해줄것이 너무 많아진다. 물론 안될 것은 없겠지만 이것들을 직접 구워먹고자 하면 상당히 번거롭고 귀찮은 방법이다. 그러므로 앞으로 접속정보를 관리하는 구조체를 만들어서 관련된 작업은 모두 거기서 이루어 지게 한다.  우선 접속정보를 담아낼 수 있는 구조체를 만든다. cache_token과 profile_image는 uchat.js를 뜯어보면서 ‘이런게 있는구나~’ 를 알아냈다. 실제로는 어떻게 사용되는지 까지는 모르겠다. 겉으로는 드러나지 않지만 계속해서 내부에선 업데이트가 진행되는듯 한 것으로 보아, 언젠가 기능 구현에 쓰일지도 모르겠다. uchat.js를 뜯어봤더니, 무조건 있어야 하는 값은 방 ID 하나 뿐이었다. 접속 인증을 사용하지 않는 방은 token이 필요 없다. nick이 없으면 알아서 손님1234 같은 닉네임을 만들어 준다. auth 또한 Option으로 뺄려면 뺄 수 있으나 구현에 있어서 한단계 추가 할 것이 생겨서 UChatAuthLevel이라는 enum에 None을 추가해 놓는것으로 타협하였다. 값을 설정하는 방식으로는 builder 패턴을 이용하였다. getter / setter를 만들 필요도 없을것 같아서 저 수준에서 마감을 했다. (어짜피 필요하면 구조체 내에 접근 가능하기도 하다)  Builder 패턴을 모르는 사람을 위해 설명하자면, 값을 설정하는 함수를 실행하면 자신을 리턴하여 계속 이어서 값 설정을 가능하도록 하는 패턴이다. 아래와 같이 setter를 사용할 수도 있지만, 빌더 페턴에 비해서는 해야 할 것이 더 많다: 빌더 패턴을 이용하면 위의 코드를 더 간단하게 호출할 수 있다. nick()은 닉네임 설정후 빌더(자신)를 그대로 돌려주고, id()도 마찬가지로 자신을 돌려주고 하기 때문에 가능하다. 값이 설정된 빌더를 계속 주고 받고 한다고 생각하면 된다. 이제 필요한 데이터는 모두 모았다. 이제 이것을 실제 접속 정보로 바꾸는 부분이 필요하다. 우선 유챗에서 채팅방 접속 토큰을 어떻게 생성하는지 보자: 여기서 우리가 봐야할 부분은 uchat_array2data() 이다. 한줄한줄 해석해 보자. $arr[‘time’] = time();– 접속토큰 변조 방지를 위해…

  • 2020년 정리

    1~4월  군대에 박혀 있었다. 원래 전역일자는 5월 중순이었다. 그러나 코로나 때문에 4월 말 즈음에 현지전역 제도로 집에 갔다. 코로나로 인한 출타제한 때문에 거의 20일? 정도 일찍 나오게 되었다. 대대급 내에서는 인사를 다 드리고 나왔으나, 불교 군종장교님께는 인사를 못드린게 못내 아쉽다. 나름 불교 군종병으로 활동 했었는데 아쉽게 되었다.  19년 말 부터 리눅스용 사지방 접속기를 만들고 배포하였다. 병영내 사지방 개선 사업이 진행되면서 하모니카 OS가 설치된 PC들이 보급되기 시작했었다. 사업 초기에 여러 문제가 쌓여 있었다. 그중 병사로서 가장 크게 다가온 것은 구글 및 유튜브 접속장애 문제였다. 구글·유튜브 접속에 2~3분 걸리다가 끝내 타임아웃까지 발생하는 문제였다. 이로인해 사지방의 목적인 “인터넷 검색”을 할 수 없는 환경이 된 것이다.  네트워크 장비상의 문제를 우회하지 않고서는 해결할 방법이 없었다. 윈도우 상에서는 익히 알려진 우회방법이 있었으나, 하모니카에서는 불가능한 방법이었다. (루트 권한이 없는게 가장 크다) 그래서 유저 레벨에서 사용 가능한 우회 접속기를 만들어서 사용했었다. 그 과정속에서 사지방 운영 업체측에서 파이어폭스를 전체 차단하는 병맛 가득한 수를 두어서 충격 먹기도 하였다.  네트워크 장비에서 특정 IP대역을 필터링 하는 문제가 원인이었기에, 이 대역만 피해서 접속을 하면 해결되는 문제였다. 처음에는 파이어폭스의 Dns Over…

  • 유챗 봇 만들기 #1 – Tokio 적용

    이전 글에서 유챗이 어떤 프로토콜·구조를 가지고 통신을 하는지 알아 보았다. 이번 글에서는 Tokio를 이용해서 프로그램의 기본적인 구조를 짜 볼 것이다. 또한 tokio-tungstenite 라이브러리까지 결합하여 웹소켓 접속까지 다루어 볼 것이다. Rust 프로젝트 생성 가장 먼저 Rust를 설치해야 한다. Rust는 rustup으로 간단한게 설치 할 수 있다. rustup은 Rust를 사용하기 위해 필요한 툴체인들을 설치하도록 도와주는 공식 프로그램이다. rustup은 https://rustup.rs/ 에서 다운로드 및 설치 할 수 있다. 설치가 완료되었다면 cargo, rustup 등의 프로그램을 사용 할 수 있게 된다. cargo나 rustup가 바로 실행되지 않는다면 쉘(터미널)을 재시작 해야 한다. /usr/bin등이 아닌 /root/.cargo/bin 와 같은 별도의 폴더에 프로그램이 설치되기 때문에 $PATH를 업데이트 해야 하기 때문이다. 쉘을 재시작 하면 정상적으로 $PATH가 다시 읽혀저서 사용이 가능할 것이다. 그래도 안된다면 폴더를 $PATH에 집어넣든 ln -s $/.cargo/bin /usr/local/bin 등으로 적절하게 기존 $PATH에 집어넣든 해서 조치를 취하자. rustup까지 설정이 완료되었으면 Rust 프로젝트를 위한 작업공간을 만들어야 한다. Rust 프로젝트는 Cargo 라는 패키지 관리 프로그램으로 생성 할 수 있다. (npm 같은것이라고 생각하면 된다) cargo new 또는 cargo init를 사용하면 된다. cargo new 이름 을 실행하면 현재 위치 아래에 새로 이름에 해당하는 폴더가 생길것이다. 이미 있는 폴더에 프로젝트를 만들고 싶다면 해당 폴더안에서 바로 cargo init를 실행해도 된다. 정상적으로 실행 됐다면 위와 같은 파일 구조를 가질것이다. 여기서 Cargo.toml은 프로젝트의 설정 및 의존 라이브러리 지정에 사용된다. 실제 프로그램의 코드는 src/ 폴더 아래에 들어가게 된다. 이미 src/ 폴더 아래에는 main.rs가 존재하는데, src/main.rs 파일이 프로그램의 진입점이 된다. Tokio 라이브러리 사용 Tokio는 비동기 작업 스케줄링 라이브러리이다. tokio를 이용하면 빠르고 간편하게 프로그램을 비동기로 짤 수 있다. 우선 우리 프로젝트에 tokio를 적용해 보자. 먼저 Cargo.toml을 열어서 [dependencies] 하단에 tokio = { version = “0.3”, features = [“full”, “io-util”, “net”]…

  • 유챗 봇 만들기 #0 – 프로토콜 분석

    유챗 봇 만들기 #0 – 프로토콜 분석

     유챗에서 작동하는 간단한 봇을 만드려는 중에, 관련된 자료가 검색해도 보이지 안길레 적어본다. 어디까지나 내가 코드를 분석하면서 찾은것을 기반으로 작성한 글이기에 부정확한 내용이 있을 수도 있다. 우선 유챗의 통신 내용을 들여다보면 아래와 같이 나온다: 모든 통신은 웹소켓을 기반으로 동작하고 있음을 볼 수 있다. 특히 웹소켓중 바이너리 타입으로 데이터를 송수신 함을 볼 수 있다. 하나의 웹소켓 패킷(바이너리 타입 메세지) 안에서는 \n을 기준으로 여러개의 메세지를 담을 수 있다. 메세지는 중간에 끊어짐이 없다. 각 줄의 메세지는 다시 \x02, \x03, \x04, \x05, \x06, \x07 등으로 내용 구분된다.   다시 말하자면, 우선 바이너리 타입의 웹소켓 패킷으로 메세지의 덩어리가 온다. 들어온 메세지 덩어리는 우선 \n 단위로 나눠진다. 그렇게 나눠진 한줄 한줄 나눠진 메세지는 다시 \x02~\x07을 구분자로 해서 내용이 나뉘어진다. 맨 앞에는 메세지의 타입(기능)을 구분해 놓은것 인 것 같고, 나머지는 자신의 데이터 맨 앞에 있는 구분자에 의해 해당 내용(데이터)의 타입이 정해지는 것 같았다. 메세지1에 \x03 ESukmean 이라고 있으면, 이는 문자열 “ESukmean”임을 뜻한다. \x04 1이 있으면 이는 true를 의미한다. 내용들이 구분자로 (\x03 ~ \x07, \n등) 쪼개지기에 프로그램이 구분자와 일반 데이터를 구분하는것이 매우 중요하다. 누군가의 채팅 내용에 \n이 있었는데, 그것을 메세지의 분리로 인식하면 프로그램의 버그가 발생할 것이다. 이를 방지하기 위해 혹시라도 구분자에 해당되는 데이터가 들어온다면 그 앞에 \을  붙여서 escape하는 것 같았다. 예를 들어, 채팅 내용이 “가나다라 \n 아자차카” 라면, 우리가 받는 메세지는 “가나다라\\\n아자차카”가 되는것이다. “1234 \x06 5678″ 이라는 데이터는 “1234 \\\x06 5678″로 들어올 것이다. UChat.js를 보면 아래와 같은 구분자 타입이 존재함을 알 수 있다.…

  • 부산진구 부암동 용사촌

     부암동 롯데캐슬을 짓고있는 영역이 원래는 부암동 “용사촌”으로 불리던 곳이었다. 지금은 아파트 공사때문에 주변 부지들이 모두 철거되고 그저 공사장밖에 보이지 않는다. 원래 가지고 있던 쿠키폰(LG-SU910)에 그 이전 사진도 있을텐데… 그 까지는 찾아보지 않고, 여기서는가지고 있는 철거 공사전 용사촌 사진을 몇장 올려본다. 여기서 부터는 ’17년도에 당감천 지류를 찾아본다고 혼자 용사촌-(구)당감4동 주민센터-무궁화아파트를 다녔었던 때 찍었던 사진들이다. 사진에 나온 부분 모두가 아파트 건설로 인해 사라졌다. ’17년도는 한창 동천을 살리자는 이야기가 나왔던 시기였다. 그때 당감천도 고치자며 생태하천으로 바꾸겠다고 말이 나왔었는데 (http://web.archive.org/web/20201023160731/http://www.busan.com/view/busan/view.php?code=20160304000116) 아파트의 공사와 맞물려서 어떻게 결정이 됐는지는 모르겠다. 대신 아파트 공사 초기에 복개 부분을 다 보수한다고는 했던것 같다. 짜피 다 뜯어내야 하니까.. 이번에 안하면 아파트가 들어선 뒤로는 어떻게 손 댈 방법이 없으니.. 지금은 공사중이어서 뭘 어떻게 했는지는 모르겠다. 내 바람으로는 복개를 어느정도 걷어내어 물줄기를 보이게 했으면 좋겠긴 하다. 당감천으로 이야기가 잠시 세어 나왔는데, 여기까지가 내가 가지고 있는 용사촌의 사진들이다. 난 여기에 살지는 않았지만, 종종 답사처럼 갔었다. 기억상에서는 나름 조용하지만 활기찬 동네였는데… 어떻게 보면 안타깝고, 어떻게 보면 시대의 변화로 느껴진다. 혹시라도 미래를 위해.. 로드뷰 링크를 몇장 추가한다. 철거 될때에도 복개 부분은 건들지 못한것으로 보인다. http://naver.me/FZg35yX5 http://naver.me/xVKiMUEf http://naver.me/5rLWiUuu http://naver.me/F55tQpeA http://naver.me/Fxz7DbNF 당감동 자체가 재개발의 열풍을 띄고 있어서.. 올릴 사진이 더 많아질 수도 있을것 같다. 당감천 답사 사진은 나중에 따로 올리던가, 해당 구역이 재개발되어 사라지면 그때 올리도록 하겠다..

  • 내원사 옆 지류 계곡(?) – 2020.08.03

    내원사 옆 지류 계곡(?) – 2020.08.03

    태풍이 오고 이틀 뒤 정도에 가서 그런지 생각보다 물줄기가 많았다. 월요일이어서 그런지 이쪽은 사람이 거의 없었다. 비록 내원사쪽은 사람이 꽉 차서 못갔지만 말이다. 들어갈 때 입장료가 있으니 참고할 것!

  • 프로그램을 조금더 빠르게 – AoS vs SoA 프로그램 비교

    프로그램을 조금더 빠르게 – AoS vs SoA 프로그램 비교

    저번 글에서 AoS와 SoA의 개념에 대해 글을 써 보았다. AoS와 SoA 이야기를 논하려면 데이터가 메모리에 가지런히 모여있다는 전재를 해야한다. 배열을 만들었으나 실제로는 데이터가 연속적으로 모여있지 않고 뿔뿔히 흩어저 있으면 메모리 캐싱이 될 리가 만무하다. 즉, AoS와 SoA는 메모리 구조가 시스템적일수록 더욱 효율적으로 동작한다. 배열의 저장과 그 외 기능의 동작이 군더더기 없이 딱 필요한 기능만 동작될…

  • 프로그램을 조금 더 빠르게 #1 – AoS와 SoA

    프로그램을 조금 더 빠르게 #1 – AoS와 SoA

    메모리 속도는 CPU에 비해 훨 느리다. 이것을 극복하려면 CPU 캐시 메모리를 잘 써야한다. 이를 위해서는 SoA와 AoS (Struct of Array, Array of Struct)을 알 필요가 있다. 메모리 속도에 따른 프로그램 동작 속도를 알아보자.