심심한 개발공부

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

배포 고려사항 1. (해커톤 상황 고려)내가 잘 아는 기술 스텍을 이용하자 - EC2, Vercel 이용하기로 결정, Amazon RDS 이용은 고려하였으나 해커톤 기간 중에는 EC2 안에 마리아 DB사용하기로 결정 2. CORS, HTTPS문제는 최대한 간편하게 해결하자 - Nginx를 리버스 프록시로 이용, 해당 문제 편안하게 해결 - CertBot 및 nginx.conf 수정을 통해서 해당 문제 해결 3. 백 서버가 정상작동하지 않아도, 프론트서버에서 백 서버가 정상작동하지 않고있음을 알려줄 수 있도록 하자 - Front, Back 이원화(Vercel, Nginx-Tomcat) 4. 서버는 대한민국에 존재해야하며, 네트워크 응답시간은 최소화시켜야된다. 개발 고려사항 1. DB정규화는 최소화(빠른 개..

들어가면서 42 이너서클을 끝내기까지 남은 과제 단 2개! 이제 정말 끝이 다가오니, 42에 대한 생각이 많아졌다. 이 곳에서 배운 것들이 너무 많아 앞으로 할 프로젝트에 있어서 자신감도 많이 붙었고, 앞으로 무엇을 해야할지에 대해서도 확신이 생겼다. 이제 내게 남은 것은 배운 것들을 갈고 닦는 시간이라고 생각할 무렵, 42내에 코알리숑 해커톤 공지가 올라왔다. 실력을 갈고닦을 순간이 필요했던 내게 이 해커톤은 좋은 기회가 될 것 같았고 우승을 목표로 이번 해커톤에 참여하게 되었다. 조별 만남 '인사가 만사'라는 말이 있듯, 나는 해커톤에서 어떤 팀원을 만나냐가 결과물을 결정한다고 생각한다. 이번 해커톤은 내 의사가 반영되지 않는 완전한 랜덤으로 조별 매칭이 이루어졌고, gehan님과 sungwook님 ..

사용하고 있는 아파치 서버 배포 직전, 과연 이 서버가 얼마나 버텨줄지 궁금해졌다. 현재 배포중인 서비스는 얼만큼의 스트레스를 버텨줄 것인가? 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모글의 서비스 볼륨은 결코 크지 않다. 분명히 작은 간단한 출석용 사이트인데.. 비용이 너무 많이 나간다. 첫 달은 도메인 등록 비용을 고려해서 많이 나갔다고 해도 2번째 달부터는 변명의 여지가 없었다. 내 첫 배포 프로젝트라서 일단 어떻게든 서비스를 올리겠다는 일념으로 올리긴 했지만, $55는 용납할 수 있는 범위를 넘었다. 일단 서비스가 안정되었으니 어떻게든 가격을 줄이는 방법을 찾아야만했다. 42서울에서는 클라우드 공부를 독려하기 위해서 AWS크레딧을 내부 재화로 구매하게 해준다. 덕분에 나는 지금 200만원 이상의 크레딧을 보유하고 있지만, 이 속도라면 2년 후면 서비스를 내려야했다. 내가 엄청나게 크고 많은 컴퓨팅 용량을 이용하는 서비스를 하면서 2년을 유지한다면 ..

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

본 내용은 RFC7230을 기반으로 작성되었습니다. 영문판을 기반으로 해석을 통해 작성하였으며, 틀린 내용 댓글로 알려주시면, 수정할 수 있도록 하겠습니다. HTTP란? HTTP는 HyperText Transfer Protocol의 약자로, 네트워크를 기반으로 작동하는 무상태 어플리케이션 레벨 요청/응답 프로토콜을 말한다. 이 응답 프로토콜이 사용하는 것으로는 네트워크 기반 하이퍼 텍스트 정보시스템과 유연한 상호작용을 위한 확장 가능한 메시지 페이로드를 포괄하고 있다. 처음 들으면, 무엇인지 이해하기 힘든데, 중요한 키워드 2가지 무상태와 어플리케이션 레벨만 정리하고 넘어가자 첫번째로, 무상태란 무엇일까? 무상태를 설명하기 위해서는, 그 전에 Connectionless(비연결성)에 대해서 설명해야된다. ..

몽골의 자연은 상상을 뛰어넘는다 세상은 넓고 볼 것은 많다고 하지 않는가? 몽골은 그 볼 것이 너무나도 많은 곳이었다. 끝없이 펼쳐진 국토에 사람은 많이 살지 않다 보니, 몽골에 멋있는 대자연은 다른 나라의 자연과 궤를 달리하는 경우가 많았다. 이곳에서 관광지라고 이름이라도 내밀기 위해서는 다른 나라 1 티어 자연관광지는 데리고 와야 했다. 내가 2년 이상 본적을 옮겼던 단양의 자연도 이곳에서는 그저 지나가면 있는 관광지정도였다. 그 정도로 이 몽골이라는 곳의 대자연은 넓고 광활했다 아름답고 또 아름다운 모습들의 향연이 바로 이곳이다. 인간이 만들어낸 그 어떤 건축물도 대자연이 수 천년 간 빚어낸 작품에 비할 수 없다는 말을 본 적이 있었는데, 그때는 다 헛소리라고 생각했다. 인간에게 가장 감명을 줄 수..

몽골의 길에는 낭만이 있다. 낭만과 고생은 함께온다고 생각한다. 나는 20대에 몽골에 온 것을 정말 잘한 선택이라고 생각했다. 몇 년만 지나서 왔다면 허리가 아파서 저 차에 그렇게 오랜시간 앉아있지 못했을 것이다. 푸르공은 정말 재미있는 차다. 정말 작아보여서 내가 저기에 들어갈 수 있을까 싶다가도, 안에 앉아있으면 꽤 아늑해서 타고다니기 좋다. 또, 와 저런 곳을 차가 갈 수 있을까? 싶은 곳을 아무렇지도 않게 달려나간다. 이 황량한 땅에서 일어나 세계를 호령한 몽골 제국의 기병이 연상되는 차이다. 작지만, 강하다. 몽골 여행을 계획하고 있다면, 저 차 안에 최소 가는날 * 6시간 정도는 탑승한다고 생각하면 좋다. 도로의 85% 이상이 비포장 도로이기 때문에, 저 차를 타고 ATV를 버틴다고 연상하면 ..

들어가면서 터키를 다녀오고 1달이 지난 시점, 나는 아직 여행이 목말랐다. 군에서 보낸 2년 4개월의 갇혀있던 시간은 3주 정도의 터키여행으로 갈음하기에는 너무 컸고, 나는 그 여행에 대한 목마름을 충족시킬 어딘가를 찾아다녔다. 인도와 스탄 국가들을 제외하고 거의 모든 아시아 국가를 다 가본 나로서는 몽골은 아직 가보지 않은 미지의 땅이었고, 나는 이 갈증을 채워줄 곳으로 몽골을 선택했다. 몽골을 가기로 마음 먹은 후, 여러 리뷰들을 비교하며 어떻게 갈까를 생각해 봤다. 개인적으로 가장 선호하는 여행 방법은 충분한 조사를 바탕으로 한 개인여행이지만, 몽골은 그런 부분이 매우 제한적이라는 것을 조사를 통해 알 수 있었다. 실제로, 가장 유명하고 볼 것이 많은 여행지들은 수도에서 비포장 도로를 15시간 이상..

들어가면서 5서클에 올라오자마자 가장 만만한 친구를 고르자면 아마도 (내게는)이 인셉션이다. 이 과제는 내가 정한 리눅스 내에 가상머신의 꿈 속의 꿈을 구현해내는 과제인데, 이 과정에서 Docker을 통한 가상화를 깊이있게 학습하게 된다. 나는 지금도 3개 이상 팀에서 웹 서비스 배포를 담당하고 있다보니, 이러한 작업에 익숙해졌고 덕분에 편안하게 과제를 잘 마무리할 수 있었다. 과제의 총 소요기간은 약 5일정도였으며, 나는 과제에서 필수적으로 요구하는 PHP, DB, NGINX 외에도 추가적인 서비스들을 구축하여 보너스 점수를 얻을 수 있었다. 내가 총 구현한 도커 컨테이너는 10개로 각각은 다음과 같다. 필수 구현 : MariaDB, Nginx, WordPress 보너스 구현 : Redis, admin..