심심한 개발공부

Palworld(이하 팔월드) Dedeicated 서버를 운영하고 있다면, 가장 신경 쓰이는 부분은 게임 서버의 퀄리티일 것이다. 특히, 현재 팔월드 게임은 콘텐츠는 알차나 게임의 기술적인 완성도를 보면 만들어졌다고 보기 어렵기 때문에 더더욱 그렇다. 메모리 누수는 기본에, 멀티쓰레딩도 제대로 처리되고 있는지 확신이 들지 않을 정도이다. 이런 상황이지만, 게임을 잘 만들어서 즐기고 싶으니, 그리고 또 내 서버에 온 플레이어들이 재미있게 즐길 수 있게 하기 위해서 여러가지 최적화 방법을 고민해 봤고, 그 과정을 공유해보고자 한다. 아래 내용은 모두 리눅스(정확히는 우분투)를 기준으로 구성되어 있다. 윈도우도 파일 위치나 큰 내용적인 부분에서 차이가 없기 때문에 OS 간 차이를 이해하고 있다면 쉽게 따라 할..

컨테이너가 안올라가진다.. 평화롭던 어느날 언제나와같이 쿠버네티스를 파드를 만들고 있었는데, 내가 방금 만든 컨테이너가 지속적으로 FAIL하는 문제가 발생했다. 분명 내가 바로 앞에서 MAC으로 빌드하고, 그것을 바로 Docker Repository에 push하고 해당 이미지로 실행시켰는데도 안되는 문제였다. 1시간정도 고민 끝에 모든 것을 다 해결하고도 혹시나 싶어서 한 부분이 맞아서 해당 해결방법을 서술하기 위해서 작성해본다. 해결의 실마리 이번 문제의 실마리는 kubectl logs 이 작동하지 않는 것이었다. 어떻게든 문제 원인을 찾고싶어서 kubectl logs를 사용하는데 지속적으로 entrypoint를 잡지 못했다. 이런 경우는 거의 없기에 혹시나 이런 가능성을 야기할 수 있는 시스템적인 차..

백, 인프라, 프론트 엔드 개발자로서 다양한 프로젝트를 경험한 이후, 나는 인프라 특히 클라우드 엔지니어가 되어야겠다고 판단했다. 하지만, 이 판단에는 한 가지 문제점이 있었으니, 바로 클라우드 직군은 신입을 잘 안 뽑는다는 것이었다. 실제로, 여러 프로젝트를 기반으로 6개 정도의 회사에 서류를 넣었으나 결과는 바로 광탈.. DevOps 직군으로 넣었지만 모두 회사의 기준에 나는 알맞지 않았다. 운이 좋게도 내가 어떤 부분이 부족해서 탈락했는지 알 수 있는 기회가 있었는데, 결국은 내가 신입이라서 불가능하다는 이야기였다. 여러 프로젝트 리딩 및 개발 경험은 높게 평가하지만, 내가 신입으로 지원을 했기 때문에 당장 프로젝트에 투입할 수 있을지 의문이 들고 회사로서는 현재 시장 상황상 모험을 할 수 없기 때..

1. AWS는 너무나도 시장 지배적이었고, 구글은 클라우드 시장에서 자신들만의 차별점을 만들어내고 싶어했다. 2. 구글은 자신들만의 정교한 인프라 전문지식을 가지고 있었고, 이를 클라우드에 적용하는 과정을 지속적으로 진행하고 있었다. 3. 컨테이너 기술은 도커 이전에도 존재했었고, 대부분의 개발자들은 몰랐지만 소수의 개발자들은 컨테이너 기술을 사용해왔다. 4. 컨테이너 기술이 도커에 와서야 대중화된 것은 도커가 컨테이너 기술을 매우 쉽게 추상화하는 것에 성공했기 때문이다. 5. '누구나 도커를 사용할 수 있다'라는 점 그리고 소프트웨어 패키징 개념은 도커가 컨테이너 기술의 표준이 될 수 있도록 도와줬다. 6. 도커 이전에도 대규모 트래픽 처리를 위한 좋은 프레임워크는 많았지만, 이들 대부분은 대기업들만이..

상용 서비스에 크롤러가 포함되어있다면 늘 주목하자 내가 서비스하고 있는 프로그램 중에서 42Noti가 오늘 갑자기 에러를 뿜어내기 시작했다. 나는 내 프로그램들에 문제가 발생하면 즉각적으로 알 수 있도록 Slack WebHook을 걸어두는데, 이 웹 훅에 401에러가 지속적으로 발생하기 시작한 것이다. 401 코드를 보아하니 권한에서 문제가 생긴 것 같은데.. 도대체 무엇이 문제일까 직접 한번 확인을 해봐야만 했다. 그러면서 머리를 스치고 지나가는 것이 최근에 내가 크롤링하는 부분이 문제가 되었나 싶었다. 최근에 크롤링 하는 사이트의 UI가 변경되면서 문제가 되었을 것이라는 추측을 했다. 401에러의 원인 결과적으로 예상은 적중했다. 내 42Noti는 3주마다 갱신해야되는 Secret를 셀레니움으로 제작..

사용방법 1. 일단 Sumy를 사용하기 위해서는 JDK가 필요하다 먼저 JDK를 설치하도록 하자 sudo apt install openjdk-17-jdk java -version # 잘 설치되었는지 확인하자 2. 필요한 라이브러리를 설치하자 #반드시 python과 pip은 설치되어있어야한다 pip3 install sumy # pip3 혹은 pip pip3 install konlpy # konlpy는 한국어를 사용하기 위한 형태소분석기이다. 3. 예제 코드 작성 from sumy.summarizers.lex_rank import LexRankSummarizer from sumy.nlp.tokenizers import Tokenizer from sumy.parsers.plaintext import Plain..

어느날 언제와 같이 로컬에서 개발을 한 후, Develop에서 확인을 하고 그 다음에 릴리즈 브랜치로 내 프론트 코드를 옮겼는데 위와 같은 오류가 나타나 버렸다.. Develop도 아니고 Release에서 오류라니.. 식은땀이 나고 온 몸이 저려온다. 일단, 가장 먼저 한 행동은 git revert를 한 후 commit을 진행했다. 하지만, 동일한 문제가 또 발생하였고 그때가 되어서야 문제를 확인하고 해결해야겠다고 생각했다. 그래서 문제는? 결론은 내 코드의 문제는 아니었다.(괜히 겁 집어먹고 revert시켰는데.. 다시 돌려야겠다..) 문제는 마침 오늘부터 Github에서 build 에서 18.04 버전을 제공하지 않았기 때문이었다. (23.4.3부터..) 그래서 아래와 같은 에러가 찍힌 것이었다. d..

프로젝트를 진행하다보면, 내 계정에서 프로젝트를 진행하는 경우도 많지만 어쩔 수 없이 여러 IAM 계정을 이용하게 된다. 특히 IAM 계정이 가지고 있는 권한 제어에 대해 이해하면 할 수록 ROOT는 초기에만 사용하는 계정이 되고 내가 해야되는 역할에 따라서 각기 다른 IAM 계정을 이용하게 되는 것 같다. 하지만, 큰 문제점 저기에 있는 계정 ID를 외우기가 너무 어렵다. 숫자 12개로 구성되어있다보니까, 외우기도 어렵고 크롬 자동완성에 의존하자니 다양한 계정이 어떤 ROOT에 대응하는지 확인할 방도가 없다. 그래서 AWS에서 제공하는 서비스가 계정 별칭이다. 그러면 어떻게 설정하는지 알아보자 1. IAM 계정으로 로그인한다.(이 때 해당 계정은 반드시 IAM설정할 수 있는 권한이 있어야된다. 2. I..

가끔 서버에서 빌드를 하다가 서버가 죽어버리는 경우가 있다. 이런 경우 대부분의 케이스는 메모리가 부족해서 벌어지는 일인데, 평소에 우리가 사용하는 OS들에서는 메모리가 부족한 경험을 하기도 어려울 뿐더러 가상메모리가 설정되어있어서 부족하다고 멈추는 경우는 없다. 하지만, 우리가 EC2를 사용하는 경우에는 1기가 혹은 많아야 2기가의 렘으로 사용하게 되는데, 이런 경우에 평소 서비스할 때에는 서비스 볼륨에 따라 문제가 없는 경우가 많지만 빌드나 특정 초기작업에서 문제가 생길 수 있다. 나 같은 경우에는 EC2를 마이크로 혹은 small을 자주 사용하는데, 그렇기 때문에 서비스를 시작할 때는 꼭 아래와 같은 과정을 거친다. 1. EC2 Instance를 제작할 때 용량을 조금 더 추가한다 - 많이는 필요없..

사용하고 있는 아파치 서버 배포 직전, 과연 이 서버가 얼마나 버텨줄지 궁금해졌다. 현재 배포중인 서비스는 얼만큼의 스트레스를 버텨줄 것인가? 1. apaceh2-utils를 설치한다. sudo apt install apache2-utils 2. 원하는 스트레스 테스트 양을 설정후 던진다 ab -n 1000 -c 100 http://evaluation.42seoul.link/ // 100개의 클라이언트에서 1000개의 요청을 던져라! 라는 뜻 3. 결과를 확인한다.(프론트 요청) [알 수 있는 정보] 1. 99% 요청이 451ms안에 처리되었으니 엣지케이스에서도 성능이 준수하게 나옴을 알 수 있다(가장 긴 요청시간은 749ms으로 특수케이스임을 감안했을 때 인내할 수 있다고 판단된다) 2. 평균 요청 처..

최근에 42서울에 있는 모든 사람들의 유저 데이터를 가져와야되는 이유가 생겼다. 그래서 42API로 전체를 가져오는 로직을 제작하고 있었는데, 이 과정에서 너무 많은 시간이 걸리는 것을 인지하고 최적화에 나섰다. 처음 시도한 방법은 기본적인 API요청을 기반으로 요청을 작성하였는데, 기본적인 페이지 사이즈는 30이었다. 즉, 한번 GET요청을 던지면 서버에서는 30명의 정보를 내게 리턴해주는 방식으로 작동하였다. 사실 30명이라는 사이즈가 그렇게 크지는 않았지만 전체인원(42를 그만두거나 블랙홀에 빠진 인원)을 포함하여 모두를 가져오다보니, 총 요청이 270번 정도 작동하는 문제가 있었다. 컴퓨터에서 비용은 레지스터