[SW 정글 98일차] 나만의 무기 6일차 (나의 1차 역할)

어제 일찍 잠에 들어 오늘은 강의실에 6시에 나오는 것이 목표였지만 늦잠을 자서 8시에 나왔다.

알람을 듣고 눈은 떴지만 몸에 피로감이 너무 쌓여 있다는 것을 느꼈고 '1시간만 더 자자'한 것이 시간이 더 흘러버렸다.

일단은 빠르게 씻고 강의실에 나왔다.

 

강의실에 나와서 한 것은 Nginx의 사용이유를 알아보았다.

처음에 조장님께 web server는 아파치보다 NginX가 현업에서 많이 쓰이는 추세를 보이는 그래프와 성능 상 좋다는 것을 알려주며 NginX를 사용하자고 했다.

하지만, 그 때 당시에는 유튜브 영상 하나를 근거로 말했고 아파치가 왜 NginX보다 밀리는 것인지를 알아보지 않았다.

그래서 우리가 Web Server로 어떠한 것을 선택해야하나를 알아보았다.

이것을 정리하기 이전에 일단은 우리가 만드는 프로젝트 규모에서는 사실 NginX가 필요는 없다.

그 만큼 유저 수가 나오지 않을 것이고 그렇게 많은 기능과 여러 대의 server를 관리할 필요가 없어서 Demo로는 NodeJS 실행환경을 기반으로 한 웹서버를 사용하면 된다.

하지만 우리의 고민이 여기서 끝나는 것이 아니라 서비스가 더 커지고 유저 수가 많아지면 어떻게 서버단을 설계할까를 고민하고 싶어했다.

일단은 초기단계여서 어떻게 설정하고 어떻게 설계를 할지는 고민하는 것은 너무 이르지만 어떠한 소프트웨어가 있는 정도는 알아보려고 했다.

 

Web Sever 생태계에서의 양대산맥은 아파치와 NginX이다.

이 둘의 차이점을 알기 위해서는 둘의 탄생배경을 알면 더 잘 이해할 수 있고 특성을 파악할 수 있어 둘 중 우리에게 어느 것이 더 적합한지를 알 수 있다.

일단 둘의 큰 차이점은 connection이 생성되었을 때 어떻게 동작하는지가 다른데 아파치는 MPM(Muti Processing Module)이고 NginX는 event driven방식이다.

 

먼저 MPM은 2가지로 나뉠 수 있는 하나는 connection마다 프로세스가 하나 생성되어 관리되는 것이고 하나는 connection마다 worker 스레드가 생성되어 관리되는 것이다.

그리고 event driven방식은 기본적으로 master process가 존재하고 실제로 connection을 관리하거나 요청을 처리하는 일을 worker process라는 놈이 한다.

worker process는 우리(개발자)가 설정한 설정파일을 읽고 설정에 맞게 생성된다.

(보통은 core수에 동일하게 생성한다고 한다.)

worker process는 여러 connection을 관리할 수 있는데 하나의 connection이 keep-alive되어있지만 요청이 들어오지 않을 때 다른 connection을 생성하거나 다른 connection에 온 request를 처리하거나 할 수 있다.

여기서, connection을 생성, 삭제, request 처리등이 하나의 event가 될 수 있고 이 event들은 커널에 의해 queue형식으로 worker process에게 전달된다.

queue에는 다양한 작업이 있을 수 있는데 I/O작업같은 경우에는 시간이 오래 걸리는 작업이여서 뒤에 존재하는 작업들이 오랜기간동안 기다려야하는 현상이 생길 수 있기 때문에 이렇게 오래 걸리는 작업은 thread pool을 만들어 thread pool에서 작업이 이루어지도록 해준다.

 

다음으로 둘의 차이점은 아파치는 확장성와 안정성이 좋다는 것이고 NginX는 다수의 connection을 관리하기 용이하다는 것이다.

아파치가 개발된 이유는 처음으로 개발된 NCSA라는 웹 서버의 잦은 버그로 인해 개발자들이 새로운 웹 서버를 개발하려고 계획했고 그렇게 해서 아파치가 개발된 것이다.

그래서 아파치는 NginX에 비해 역사가 조금 더 길기 때문에 더 안정성이 있는 웹서버이고 다양한 모듈을 만들어 서버에 기능을 추가하여 확장할 수 있는 확장성이 장점이다.

 

반면 NginX는 개발된 이유가 아파치의 구조 상의 이유로 다수의 커넥션(C10K)을 받는 것의 한계가 발생하여 나온 것으로 동시 커넥션 양이 크고 동적 설정 변경이 가능하다는 장점이 있다.

하지만, 아파치가 가지고 있는 확장성의 장점은 NginX에서 모듈을 설치하는 것이 worker process에 영향을 줄 수 있기 때문에 NginX가 장점으로는 가져갈 수 없다.

 

결론은 일단은 Demo로 우리가 기획한 것을 nodejs 실행환경으로 만든 웹 서버로 개발을 하고 서비스가 더 커진다고 가정했을 때 웹 서버의 안정성과 확장성이 더 중요한지 혹은 동시 커넥션 수가 더 중요한지에 따라 아파치와 NginX를 선택하는 것이 달라질 것이다.

 

 

그 다음으로 ORM을 사용할 것인가?에 대한 논의가 나와서 한 번도 사용하지 않은 ORM에 대해 조사를 해봤는데 다양한 장점들이 있었지만 내가 생각했을 때에는 ORM을 도입했을 때 우리가 얻을 수 있는 장점보다는 우리가 챙길 수 없는 단점이 더 클 것같다는 생각이 들었다.

아직 SQL에 대해 어느정도 알고 있는 상태가 아니여서 ORM을 사용한다고 해서 편리함이나 개발에서 코드 재사용성, 코드 디자인 패턴적인 측면에서의 장점을 누리는 것은 힘들 것같았다.

그리고 ORM을 사용한다고  SQL에 대한 지식이 아예 없어도 되는 것이 아니기에 일단은 SQL을 사용하는 것이 더 좋겠다는 생각을 했다.

이 부분은 백엔드 팀원들과 다시 논의를 해봐야할 것같다.

 

 

이렇게 공부를 하고나서 저녁을 먹기전에 KPT 회의를 했다.

https://brunch.co.kr/@jinha0802/35

KPT 회고란 무엇인가?

KPT회의는 Keep, Problem, Try 세 단어의 앞 글자를 딴 것으로 K는 현재 만족하고 있는 부분과 계속 이어갔으면 하는 부분을 얘기하는 것이고 P는 불편하게 느끼는 부분과 개선이 필요하다는 부분을 얘기하고 T는 문제에 대한 해결책과 다음 회고 때 판별가능한 것을 얘기하는 것이다.

 

오늘 처음 진행되는 것이고 KPT회의라는 것을 경험해 본 사람이 조장님 이외에는 없어서 처음에는 어떻게 진행하는지 감이 안왔지만 일단은 돌아가면서 KPT 중 K를 시작으로 하여 얘기를 진행했다.

 

회의 결과로는 프론트엔드는 하루 더 공부를 진행하고 실제 프로젝트 구현을 위한 작업을 들어가기로 했고 백엔드는 1차적으로 할 일이 나왔다.

로그인 기능 구현과 백엔드 단에서의 데이터베이스를 어떻게 관리하는지이다.

지금은 local환경에서 데이터베이스(mysql)을 설치하고 SQL 쿼리를 던져서 데이터베이스를 관리하는 것만 했다.

하지만, 실제 프로젝트에서는 데이터베이스서버가 따로 있을 것이고 웹 서버와 WAS가 따로 있을 것이다.

그래서 그 환경을 AWS에 설정해보고 웹 서버(AWS EC2)에서 SQL문을 던지면 데이터베이스서버에 전달되어 데이터를 받아오는 것을 테스트해보려고 한다.

그리고 우리가 RDBMS를 쓰면서 테이블 설계가 중요한 포인트로 집었는데 그 작업을 나 혼자서 하는 것이 아니라 내가 먼저 고민을 해보고 초안을 만드는 것이다.

 

처음에 EC2 ubuntu에 mysql을 설치했는데 조장님이 데이터베이스서버가 AWS에 따로 있다는 것을 알려주었고 다시 그 환경에 대해 알아보고 설정을 하기 시작했다.

 

데이터베이스 생성(AWS RDS)을 위해 참고한 것은 아래의 사이트이다.

https://aws.amazon.com/ko/getting-started/hands-on/create-mysql-db/

MySQL 데이터베이스를 생성하는 방법 – Amazon Web Services

여기서 자주 보이는 단어는 Virtual Private Cloud (VPC)이였다.

AWS에서 말하는 VPC는 사용자의 AWS 계정 전용 가상 네트워크라는 것인데 내가 인스턴스들을 생성하면 내가 생성한 나만의 네트워크 생태계가 만들어진다고 받아들였다.

 

위 사이트와 현재 양식이 달라져서 일단은 연습이라고 하더라도 신중하게 하나하나 읽으며 설정에 들어갔다.

데이터베이스서버를 열면서 많은 설정값들을 일단은 하라는대로 했는데 더 자세히 알고 싶다...AWS에서 제공하는 정보로는 이것이 무엇을 하는구나라는 것을 제대로 알 수 없다....AWS도 시간이 있으면 제대로 공부해서 마스터하고 싶다.