좋은 개발자 되기

Kangho LEE·2021년 3월 30일
1

요새 느끼는 게 많은 것 같습니다. 진짜 좋은 개발자가 되기 위해 어떤 것이 필요한가 특히 더 많이 생각이 듭니다. 그냥 평범한 개발자가 되야하는 건지, 매일 단순히 회사에서 워라벨 챙기면서 일하는 것이 좋은 건지 스스로 질문을 많이 해보게 되는 것 같습니다.

물론 편하게 회사를 다니고 꾸준히 공부를 많이 하지 않아도 좋은 개발자가 될 수 있고 공부 말고도 취미나 인간관계에서 더 좋은 결과를 얻는 사람도 많이 본 것 같습니다. 개인이 결국 행복하면 되니까요. 하지만 요새 개발에 몰두하고 매일 빠르게 성장하는 사람들을 블로그를 통해 많이 보다보니 정말 많은게 느껴졌습니다. 정말 개발을 사랑하고 빠른 성장을 위해서 꾸준하게 노력하는 그 분들의 모습이 그렇게 멋져 보일 수 없었습니다.

그렇게 되니 자연스럽게 스스로 많은 질문을 던져보았습니다. 도대체 어떤 개발자가 되어야 하지? 난 무엇인가 1년 넘게 미친듯 집중해 결과를 이룬 것이 있나? 라는 생각이 많이 들었습니다. 매번 번아웃, 휴식을 핑계 대고 꾸준히 하지 못했던 저의 모습이 보였습니다. "인턴을 하면서 일을 하니까 괜찮아" 스스로에게 빠져나갈 구멍만 만들어주는 모습만 생각이 들어 부끄러웠습니다.

결국 나중에 후회할 것 같다는 생각에 도달했고 아주 간단한 것부터 다시 잡기로 했습니다. 그것이 바로 TIL입니다. 물론 주에 한번은 공부를 하지 않고 쉬고 있긴 하지만 그 하루를 제외하고는 매일 쓰는 것이 목표입니다. 이런 간단한 목표를 잡고 나니 다른 목표도 같이 많이 보이는 것 같습니다. 그래서 이번년도가 끝난다면 연별 회고나 월별 회고를 해보려고 합니다. 방향성을 잡고 빠르게 성장하는데에 큰 도움이 될 것 같아서 도전해보려고 합니다. 항상 늦었다고 생각했을 때에 시도조차 안하는 것은 스스로에게 비겁하다고 느껴졌습니다.

어쩌다 보니 일기 같이 시작하게 되었는데 정말 저도 많은 블로그들을 보면서 도움을 받은 것처럼 다른 분들께 작은 도움이나 마음을 정리하시는 데에 도움이 되었으면 좋겠다는 생각을 많이 들었습니다.

웹, 네트워크

nginx + gunicorn + docker (compose)를 실습 복습을 통해 많은 서버 관련 지식들을 공부 할 수 있었습니다.

전 가상화(full virtualization)와 반 가상화, 컨테이너를 통한 가상화:

전 가상화

-1. 전 가상화는 hypervisor를 통해 guest os와 hardware에 올라가있는 실제 host os가 서로 명령어가 일치 할 수 있는 통역관 같은 친구가 있다.
-2. 이 통역관(hypervisor) 때문에 하드웨어 os 종류에 상관없이 편하게 올릴 수 있지만 이 때문에 성능이 좋지 않다..

반 가상화

-1. 반 가상화는 이런 비싼 통역관 대신 직접 커널을 건드려서 하드웨어 os 와 가상 머신 os 를 통신시킨다. 
덕분에 오버헤드는 줄어들었지만 커널을 '직접' 손봐야 한다...

컨테이너 가상화

-1. 컨테이너는 반 가상화의 장점을 그대로 가져가면서 단점을 보안한 방법이다. 우리가 직접 가상 os 를 손보는 것이 아닌 host os에 도커 엔진을 올린다.
그리고 os 이미지를 통해 컨테이너를 만든다 (이 과정에서 guest os는 필요가 없어진다.)
-2. 컨테이너는 또 배포 당시 환경을 그대로 이용하기 때문에 버전차이나 os별로 설정해야 하는 것들을 안해줘도 배포 당시 환경을 그대로 사용 할 수 있게 된다.

nginx는 무엇인가?

이벤트 드리븐 프로그램

nginx는 웹서버로 이벤트 드리븐 프로그램이다. 유명한 톰캣 아파치 역시도 웹서버인데 톰캣은 멀티쓰레드 방식 프로그램이다. 

어떻게 운영 될까?
톰캣은 그래서 요청이 올때에는 미리 만들어둔 쓰레드를 클라이언트한테 제공해 요청과 응답을 처리한다.
nginx는 이벤트 루프에서 I/O bound들을 주로 받고 비동기적으로 처리한다. 

요새는 비동기가 대세인가 보다. 소켓 통신이 설계 될때 하드웨어 사양이 충분하더라도 1만개의 요청을 처리 하는데에 시간이 많이 걸리는데 이 문제를 C10K 문제라고 한다. 
이제 우리의 비동기 이벤트 트리븐 프로그램 nginx가 이걸 쉽게 해결 할 수 있는 대안으로 제시 된다.

먼저 위에서 말한 이벤트 드리븐 프로그램은 어째서 멀티스레드 보다 처리가 빠른지 궁금했다.
이벤트 트리븐 프로그램은 Node.js에서도 사용된다. 
이벤트루프로 들어오는 I/O 작업들을 멀티 스레드 프로그래밍과 달리 요청이 들어와도 새로운 프로세스나 스레드를 생성하지 않는다. 
그저 논블로킹 형식으로 계속 I/O를 받는다. 그렇기에 비동기적으로 작업이 처리가 가능하다. 그럼 막 받게된 작업들은 어떻게 되냐?

마스터 프로세스 자신은 어떤 클라이언트 요청도 처리하지 않으며 단지 그 일을 대신 수행할 작업자 프로세스를 계속해서 낳아서 증식(invoke)하는데 
이 친구들이 CPU에 작업을 받고 완료가 되면 콜백을 받고 결과를 반환한다. 
프로세스도 마스터 하나이고, 쓰레드도 하나이기 때문에 멀티스레드 프로그래밍과 다르게 context switching이 없어서 굉장히 빠르다.

하지만 이제 비동기적 처리를 잘 해줘야 하는 경우라면 애플리케이션 설계 단계에서 처리를 해야한다. 
Node.js 는 sync, await등의 라이브러리를 사용해 처리한다.

리버스 프록시

프록시: 프록시 서버는 자기 자신을 통해 간접적으로 다른 네트워크 서비스에 접근 할 수 있도록 하는 서버이다.

nginx는 리버스 프록시를 통해 로드밸런싱을 해 줄 수 있다.

로드 밸런싱: 부하 조절이다. 서버에 요청이 들어오면 한곳에만 할당을 해주는것이 아니라 같은 동작을 하는 여러 서버 애플리케이션에
부하를 적절히 조절해 준다. 즉, 하나의 도메인에 여러 사람이 마구 접속해도 실제 서버는 여러개 떠있는 것을 상상하면 된다.
upstream을 통해 연결 해 줄 수 있다. 설정을 통해 몇개의 서버에 얼만큼 트래픽을 할당할 지 조절할 수 있다.

포워드 프록시: 사용자가 직접 서버에 요청을 하는 것이 아닌 프록시 서버를 통해 인터넷에 연결하는 것이다. (클라이언트는 누군지 모르게 된다. 프록시를 통해서 인터넷에 들어가기 때문)

리버스 프록시: 클라이언트가 요청을 하면 리버스 프록시만을 통해 내부서버에 프록시가 직접 연결하고 프록시가 클라이언트에게 응답해 주는 구조이다. 

포워드 프록시는 클라이언트가 누군인지 모르는 가면이라면 리버스 프록시는 반대로 서버를 가려주는 가면이다. 
프록시를 사용해서 얻는 장점은 캐싱을 통한 빠른 응답, 리버스 프로싱을 통한 보안, 로드밸런싱을 통한 성능 유지가 되겠다.

공부한 것들은 많은데 막상 글로 쓰려니 정말 어렵습니다.. 또 이해하지 못한 부분도 많았었구나를 더 많이 느낍니다. 매일 어떻게 써야 한 눈에 들어 올까 고민해서 써봐야 겠습니다.

참고 페이지
https://my-repo.tistory.com/31
https://12bme.tistory.com/366
https://blog.naver.com/jhc9639/221108496101
https://bcp0109.tistory.com/entry/Forward-Proxy-Reverse-Proxy

profile
우유와 누텔라

0개의 댓글