프로젝트(2)기술스택 선정(feat. NginX, Redis...)

기술스택 선정

---

시작전, 기술스택에 관하여 알아보던중 django, AWS정도만 결정했음 된거 아냐? 라고 생각했는데 구글링을 하다보니 그게 아니였다... 클라우드 서버, 웹 서버, 웹 프레임워크, 데이터베이스 이렇게 크게 4가지를 결정해야 했다.

-클라우드 서버

AWS vs GCP 여기서 결정을 해야했다. 전세계적으로 인지도 AWS승! 서버다운 시간 AWS승! 성능은 무승부!(성능의 판단요소가 너무 많다.) 사실상 뭐든 클라우드 서버 특성상 비슷하기 때문에 많이쓰는 AWS를 써보자 라고 결정했다. GCP같은경우는 나중에 경험해 보기로ㅎㅎ

AWS와 GCP 클라우드 상품 비교

 

-웹 서버

사실 이부분이 가장 어려웠다. 왜냐! 장고는 python manage.py runserver만 입력하게 되면 이미 웹서버를 구동시켰고 따로 웹서버가 필요 한걸까? 라는 생각을했다. 자세히 알아보니 장고 github를 통해 힌트를 얻을수 있었다.

HTTP server that implements the Python WSGI protocol (PEP 333, rev 1.21).
Based on wsgiref.simple_server which is part of the standard library since 2.5.
This is a simple server for use in testing or debugging Django apps. It hasn't
been reviewed for security issues. DON'T USE IT FOR PRODUCTION USE!

해당 runserver는 보안 이슈에 대해 체크 하지 않았으면 배포용으로 사용하지 말라고 경고 하고 있습니다. 즉, runserver를 통해 실행되는것은 테스트 용으로만 사용하라는 뜻이였습니다.

 

그래서 알아본 결과 apache, NginX를 알게 되었습니다.

 

-apache

아파치는 가장 전톡적인 웹서버이며, 이에따라 웹서버 점유율또한 다른것들과 비교불가능한 독보적인 프로그램입니다. 클라이언트의 요청하나당 스레드 하나가 처리하는 구조이기 때문에 메모리와 cpu소비량이 많습니다. 하지만 점유율과 역사가 있다보니 제공되는 모듈도 많고 호환성과 안정성이 뛰어납니다.

 

-NginX(엔진엑스)

만년 2등의 포지션이지만 현재 신흥강자로 취급받고 있습니다. 비동기 이벤트 기반으로 요청을 처리하며 무엇보다 아파치보다 효율적으로 요청을 처리할 수 있는 아키텍쳐입니다. 

 

-웹 프레임워크

Django, Django restfreamwork를 사용하기로 하였습니다. spring, express.js와 같은 프레임워크이 선택지또한 있긴하지만 현재로서는 저 포함 팀원이 익숙하게 사용가능한 웹프레임워크는 django라서 선택하게 되었습니다.

 

-데이터베이스

ORM을 사용하는 django의 특성상 RDMS를 사용하는것이 적절한데 선택지는 크게 Postgersql, Mysql 2가지였다. 

-Postgresql

• 오픈소스로 무료로 사용 가능하다.
• 다양한 join방법을 제공한다.
  • nested loop join, hash join, sort merge join등
• update를 할때 과거행 삭제후 변경된 데이터를 가진 새로운 행을 추가하는 형태라서 update가 느리다.
• 처리속도를 빠르게 하기 위해 여러 cpu를 활용한 쿼리를 실행한다.

-MYSQL

• update기능이 postgresql보다 우수하다.
• nested loop join기능이 postgre보다 우수하다.
• 문자열 비교에서 대소 문자를 구분하지 않는다.
• 간단한 처리 속도를 향상시키는것을 추구한다.

등의 2가지 sql의 특장점이 있는데 결론적으로 간단한 동작을 구현하는 서비스- mysql, 복잡한 쿼리를 요구하고 insert위주의 대규모 서비스인 경우 Postgresql이라는 결론이다. 우리가 만들 서비스가 복잡하지는 않겠지만 새로운것에 대한 초점을 맞췄을때 Postgresql을 사용하여 프로젝트를 진행하기로 결정하였다.

Oracle, MySQL, PostgreSQL 차이점은?

+) redis

-캐시의 필요성

캐시는 필수가 아닌 선택이다. 기본적으로 서비스는 WEB-WAS-DB의 3구조를 띄고 있는데 사용자가 늘어나게 되면 DB에 무리가 가기 시작한다. 데이터베이스는 물리 디스크를 직접 쓰기 때문에 서버에문제가 발생하여 죽더라도 데이터가 손상되지는 않지만 매 요청마다 물리 디스크에 접근해야 하기 대문에 부하가 상당히 많아진다.

 

이때, DB서버의 부담을 덜어주기위해 등장한것이 캐시서버의 도입인데 캐시는 한번 읽어온 데이터를 임의의 공간에 저장하여 다음에 읽을 때는 빠르게 결과값을 받을 수 있도록 도와주는 공간이다. 같은 요청이 여러번 들어오면 캐시서버에서 바로 결과 값을 반환해주기 때문에 DB부하를 줄일수 있음과 동시에 속도또한 빨라지게된다.

 

물론, 캐시서버는 물리디스크가 아닌 주로 메모리를 사용하기 때문에 속도가 빨라지는 장점의 이면에 서버에 장애가 날경우 메모리가 날아갈수 있는 단점이 존재한다. 그렇더라도 캐시는 거의 필수적으로 알아야하는 개념이기와 캐시서버로 널리 쓰이고 있는 redis에 대해 알아봐야한다.

 

-redis란?

redis는 키-값으로 이뤄진 캐시시스템으로

• List, Set, Sorted Set, Hash등과 같은 collection지원
• Race Condition에 빠질수 있는것을 방지
  • Single Thred기때문에 Atomic보장
• 캐시의 단점을 커버할수 있는 persistance를 지원하여 서버가 꺼지더라도 다시 데이터를 불러들일수 있음

위와 같은 기능과 장점이 있다. 즉, redis는 다시말해 하나의 캐시시스템이며 우리가 사용할 postgre를 도와주는 역할 정도로 이해할수 있다. 캐싱을 전체에 적용하기보단 간단한 로직에 선택적으로 도입하는것이 적절할것으로 판단된다.

 

django-redis 사용법

Django에서 Redis를 이용해 Caching하기

 

-firebase

firebase는 채팅앱을 구현할때 사용하려고 한다. socket형식의 realtime db로 구현을 해야하는것인데 이러한 어려움을 쉽게 해결해주는것이 firebase이다. 기본적으로 서버에 채팅서버db만 따로 빼놨다고 생각할수 있는것 같은데 이것같은경우는 백엔드단에서 처리도 가능하겠지만 프론트단에서 전부 처리하는것이 편리해보인다. 

Firebase를 이용하여 채팅창 만들기 – CodersHigh