일단 어떤 서버든, 아키텍처든, 기술이든 선택할 때에는 기획, 서비스에 맞춰 선정하는 것은 기본중에 기본이다.
웹서비스를 운영하기 위해서 고려해야할 사항은 정말 많다.
생각나는 것만 추려보자면
1. 어떤 웹서버를 사용할 것인가
2. 동적 웹서비스를 위해 서버사이드 스크립트 언어는 어떤 것을 사용할 것인가
3. 프레임워크를 사용할 것인가
모든 결정은 기획, 서비스에 맞춰서 결정해야하고 가장 기초가 되는 웹서버의 기본적인 역할이나 정의에 대해 알아보았다.
웹서버는 하드웨어적인 측면과 소프트웨어적인 측면으로 정의할 수 있다.
하드웨어 측면
- 웹사이트의 컴포넌트 파일(image, html 문서, css, js 등)을 저장하는 컴퓨터
소프트웨어 측면
- 이 컴포넌트 파일들을 요청하는 클라이언트에게 전달하는 프로그램
정의가 이렇듯 웹서버는 철저하게 Server - Client 구조를 취하고 있다.
클라이언트가 요청하지 않으면 서버는 어떠한 응답이나, 파일도 반환하지 않는다.
정적과 동적
정적은 있는 그대로 제공되는 것(served as-is)를 의미한다. 어떤 접속자에게든 동일한 데이터를 반환한다. (HTML, CSS, JS)
정적 웹 서버 - HTTP 서버가 있는 컴퓨터(하드웨어)로 구성되어 있다. 서버는 파일이 요청되면 브라우저에 전송하기 때문에 이것을 "정적"이라고 부른다.
동적은 서버가 컨텐츠를 처리하는 것, 심지어는 컨텐츠를 데이터베이스로부터 생성하는 것을 의미한다. 누가, 언제, 어떻게 요청했는지에 따라 결과값을 다르게 보여주는 형식
동적 웹 서버 - 정적 웹 서버와 추가적인 소프트웨어(대부분 애플리케이션 서버와 데이터베이스)로 구성되어 있다. 애플리케이션 서버가 HTTP 서버를 통해 당신의 브라우저에게 불려진 파일들을 전송하기 전에, 애플리케이션 서버가 업데이트 하기 때문에 이것을 "동적"이라고 부른다.
초창기의 웹서비스는 정적파일만 제공했다.
index.html을 요청하면 index.html만 반환하는..
웹에 연결된 컴퓨터는 클라이언트와 서버라고 한다. 클라이언트는 일반적으로 firefox 또는 chrome 같은 웹 브라우저 이고 서버는 웹페이지, 사이트, 또는 앱을 저장하는 컴퓨터이다. 클라이언트의 장비가 웹 페이지에 접근하길 원할 때, 서버로부터 클라이언트의 장치로 사용자의 웹 브라우저에서 보여지기 위한 웹페이지의 사본이 다운로드 된다.
- 브라우저는 DNS 서버로 가서 웹사이트가 있는 서버의 진짜 주소(ip주소)를 찾습니다.
- 그 다음 브라우저는 서버에게 웹사이트의 사본을 클라이언트에게 보내달라는 HTTP 요청 메세지를 서버로 전송합니다. 이 메세지, 그리고 클라이언트와 서버 사이에 전송된 모든 데이터는 TCP/IP 연결을 통해서 전송됩니다.
- 이 메세지를 받은 서버는 클라이언트의 요청을 승인하고, "200 OK" 메세지를 클라이언트에게 전송합니다. "200 OK"는 "물론이죠. 당신은 웹 사이트를 볼 수 있어요! 여기 있어요" 라는 의미입니다. 그 다음 서버는 웹사이트의 파일들을 데이터 패킷이라 불리는 작은 일련의 덩어리들로 브라우저에 전송하기 시작합니다.
- 브라우저는 이 작은 덩어리들을 완전한 웹 사이트로 조립하고, 당신에게 보여줍니다.
여기서 웹서버는 들어오는 요청을 기다리고, 응답하는 역할까지 하고있다.
자 이제 실제로 '웹서버'를 선정을 해야하는데.. 어떤 것이 중요할까 떠올려봤다.
기준을 선정하기전 우리 기획의 특징
1. api 요청이 굉장히 잦다.
2. 요청중에서는 DB의 request 요청이 많고 받아온 값을 json으로 변환하여 response한다.
3. 읽기 요청의 속도가 중요하다.
웹서버의 기본 고려사항 (이라고 생각되는 것들)
1. 무료, 소스코드 공개 의무
2. 클라이언트가 가장 많이 요청하는 우리 서비스의 데이터는? ex)이미지, 텍스트, 동영상 등
3. 동일한 성능의 CPU,메모리와 많이 요청하는 데이터의 최대 처리량 & 처리속도
4. 서버사이드 스크립트 언어와의 호환성
5. 레퍼런스
웹서버의 기본적인 역할말고 부가기능으로는
1. 인증
2. 정적 콘텐츠 관리
3. HTTPS 지원
4. 대용량 파일 전송 지원
5. 콘텐츠 압축
등등이 있다.
웹서버에서 제공하는 기능 리스트(수행할 수 있는 일부 작업에 대한 제한된 예시)
https://en.wikipedia.org/wiki/Web_server
- 비용이 들지 않는가?
- 운영체제와 상관없이 플랫폼 구축이 가능한가?(Linux)
- 높은 처리량(high throughput)
- 짧은 대기시간(low latency)
- https적용에 대한 reference가 충분한지 또는 가능한지
- http2이상을 제공하는지
대기 시간 은 논의에서 데이터가 사용자와 서버 사이를 이동하는 데 걸리는 시간과 서버가 데이터를 처리하는 데 걸리는 시간을 합하여 얼마나 빨리 작업을 수행할 수 있는지를 나타냅니다.
대역폭 은 네트워크의 최대 용량으로, 전송 네트워크의 크기뿐만 아니라 서버의 처리 용량과도 관련이 있습니다.
처리량 은 주어진 기간 동안 사용자와 서버 간에 교환되는 데이터의 양을 측정한 것입니다. 처리량을 최적화하는 것이 올바른 방법이지만 대역폭과 대기 시간만 제어할 수 있습니다.
위와 같은 기준을 선정한 이유
1. 우리는 Linux를 사용하고 최대한 비용 지출을 줄이길 희망함
2. 웹사이트가 로드되는 시간에서 3초 이하에 나가버리는 사람의 비율은 40%이며, 이 비율은 대부분의 사람들은 웹사이트가 빠르게 로드되길 원하기 때문에 높은 처리량과 짧은 대기시간이 주요한 기준이 될 수 있다.(다만 우리가 하는 요청의 특징을 잘 살펴봐야 한다. 우리의 주된 요청은 정적컨텐츠보다는 쿼리를 날려서, 동적컨텐츠로 변환한 데이터가 대부분임)
3. https적용 가능하며, 적용 reference가 충분히 있는가
구글 검색센터
- 구글과 같은 브라우저에서 https를 사용하지 않으면 안전하지 않은 사이트라고 표기되며, https를 사용하는것을 권장하고 있다.
- SEO(Search Engine Optimization)혜택을 제공한다.
- http2이상을 사용가능하게 한다.
- 사용자의 신뢰도가 올라간다.
4. HTTP2이상 지원
HTTP/0.9 - 원라인 프로토콜
- 요청 메서드 GET만 존재, 응답도 파일 자체로만 구성되어 있다. (HTML)
<html>
A very simple HTML page
</html>HTTP/1.0 - 확장성 구축
- 버전 정보가 각 요청 내에서 전송되었다.
- 응답 시작 시 상태 코드라인 (성공 또는 실패를 인식 가능)
- Content-type 헤더가 생기면서 HTML파일 이외의 문서를 전송 가능
HTTP/0.9와 HTTP/1.0 모두의 주요 문제는 각 요청에 대해 새 연결을 시작하고 응답이 전송된 직후 연결을 닫았다는 것이다. 새 연결이 설정될 때마다 TCP 3 way handshake가 발생한다. 더 나은 성능을 위해서 서버와 클라이언트간의 왕복을 줄이는것이 중요해졌다.
HTTP/1.1 - 표준화된 프로토콜
프로토콜 모호성을 해결하고 keep-alive, chunked encoding transfers, byte-range requests, 추가 캐싱 메커니즘, 전송 인코딩 및 요청 파이프라이닝과 같은 성능 최적화를 도입했다.
1. persistent connection(keep-alive) - 달리 선언하지 않는 한 모든 연결은 영구적인 것으로 간주한다. HTTP 영구 연결은 별도의 연결 유지 메시지를 사용하지 않고 여러 요청이 단일 연결을 사용하도록 허용한다. 기본 연결 제한시간이 있다.
2.chunked transfer - keep-alive의 사용으로 한 응답이 끝나고 다음 응답이 시작되는 위치를 결정하기 어렵다. Contnet-length 헤더는 콘텐츠 크기가 아직 알려지지 않았기 때문에 콘텐츠와 다음 HTTP 요청/응답을 구분하는데 사용할수 없다. 청크 인코딩은 헤더를 쓰기 전에 전체 콘텐츠를 생성할 필요가 없다는 이점이 있다.
3. pipelining - 하나의 커넥션에서 응답을 기다리지 않고, 순차적인 요청을 연속적으로 보내 그 순서에 맞춰 응답을 바든 방식으로, 지연시간을 줄이는 방법(지원이 열악하여 잘 사용하지 않음)
4. 여러개의 커넥션 연결(보통 4~6개를 연결함)
http1.xx 버전에서 발생하는 문제
문제1 : Head Of Line Blocking, 앞 요청의 시간이 오래걸리면 뒤에 오는 요청도 해당 요청이 처리될 때까지 기다려야 하는 현상(TCP는 순서가 보장되어야 하고, 보내는 동기가 되어야 하므로)
문제2 : Header 구조의 중복, 연속된 요청의 경우 Header 값이 같은 경우가 많음에도 불구하고 중복된 값을 그대로 전송하는 현상이다.
문제3 : 원하는 요청의 순서를 지정할 수가 없다.
HTTP/2
전송 성능을 개선하고 대기 시간을 줄이고 처리량을 높이는 것이다. SPDY의 사용사례를 모두 흡수하였다
1. 헤더필드 압축
2. 동일한 연결에서 여러 개의 동시 교환을 허용
3. 요청의 우선 순위를 지정할 수 있어 더 중요한 요청이 더 빨리 완료된다.
http2 수준에서 발생하는 문제
문제1. TCP 수준에서의 어려움 TCP 스트림에서 패킷이 하나 손실되면 그 패킷을 찾을때까지 모든 스트림을 대기한다.
HTTP/3
1. QUIC(UDP) 프로토콜을 사용
2. 3 way handshake 생략
QUIC의 작동방식
HOL블록킹 TCP와 UDP수준
그러나 벤치마크 결과로 http3가 http2보다 일반적으로 빠르다는 결과값이 없기 때문에 http2이상이면 high throughput과 low latency를 처리할 수 있을것이라 생각하여 http2 이상을 지원하는 웹서버를 선정하는것이 좋겠다.
4. 기존에 잘나가는 웹서버의 아키텍처
1. apache
1995년 12월 1일 APache 버전 1.0이 출시되었으며 이전에 널리 사용되었던 NCSA 서버보다 더 대중적이고 널리 사용되는데 1년밖에 걸리지 않았다. 설치하기 쉽고, 무료이면서도 광범위한 기능을 가졌다. 서버를 중지하지 않고도 서버를 재구성할 수 있으며, 모듈화로 인해 특수 응용 프로그램 도메인 내에서 필요한 많은 기능을 추가 모듈로 구현하고 서버에 연결할 수 있다.
요청을 관리할 때 하나의 프로세스를 생성하거나 스레드를 할당한다.
2. nginx
2004년 공개 출시 이후 고성능, 높은 동시성 및 낮은 메모리 사용량에 중점을 두었다. 모듈식, 이벤트 중심, 비동기식, 단일 스레드, 비차단 아키텍처
https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/
Inside NGINX: Designed for Performance & Scalability
Take a deep dive inside NGINX and learn why NGINX is perfectly suited for applications and servers that require high performance and scalability
www.nginx.com
최근 웹서버의 아키텍처
1. caddy
Go로 작성되었기 때문에 외부 의존성이 전혀 없고, single, self-contained, static binary이다. 이러한 부분들은 배포를 간단하게 하고 프로덕션 환경에서 트러블슈팅을 감소시킨다.
lects-encrypt가 자동으로 연결되어 https를 따로 하지 않아도 됨
2. h2o
C로 작성, library로도 사용 가능
참고
1. OSI 7계층 - 컴퓨터 시스템이 네트워크를 사용해서 통신할때 사용하는 7개의 계층을 의미한다. 1980년대 초 모든 주요 컴퓨터 및 통신 회사에서 채태한 네트워크 통신의 첫 번째 표준 모델이다.
2. 패킷(packet) - 정보 기술에서 패킷 방식의 컴퓨터 네트워크가 전달하는 데이터의 형식화된 블록이다. 패킷은 제어 정보와 사용자 데이터로 구성된다. 후자는 페이로드라고도 한다. 제어 정보는 페이로드를 전달하기 위한 데이터(예: 소스 및 목적지 네트워크 주소, 오류 감지 또는 시퀀싱 정보)를 제공한다. 일반적으로 제어 정보는 패킷 헤더 및 트레일러에서 찾을 수 있다.
3. HTTP 메시지 - 서버와 클라이언트 간에 데이터가 교환되는 방식입니다. 메시지 타입은 두 가지가 있습니다. 요청(request)은 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지고, 응답(response)은 요청에 대한 서버의 답변입니다.
4. SPDY - google에서 2009년 말에 발표하고 2010년에 배포했다. 웹 페이지 로드 대기시간을 줄이고, 웹 보안을 개선하는 특정 목표를 가지고 HTTP 트래픽을 조작한다. SPDY는 압축, 다중화 및 우선 순위 지정을 통해 대기시간을 줄인다.
5. HTTP/1.1 과 HTTP/2 의 이미지 로드를 비교해 볼 수 있는 사이트
https://http2.akamai.com/demo/index_demo_html-h1h2mix_vs_h2.html
그래서 결론적으로 웹서버는 프로세스를 재생성하는게 아니라 쓰레드를 할당하는 방식이어서 속도도 빠른 Nginx를 선택했다.
알다시피 html은 프로그래밍 언어가 아니다. 여기서 생각이 발전해 프로그래밍적인 부분(함수, 변수 등 )들을 추가해서 동적으로 요청을 처리한다면 좀 더 다양한 경험(동적 처리)을 줄 수 있을 것 같다는 결론에 이르러서 나온게 CGI라는 통신규약이다.
CGI 는 common gateway interface의 줄임말로 말그대로 인터페이스이다.
**인터페이스 : 상호간의 소통을 위해 만들어진 물리적 매개체나 프로토콜
어떤 프로그램도 아니고, 웹서버와 외부 프로그램 사이에서 정보를 주고받는 방법이나 규약이다.
웹서버도 종류가 여러가지이고, 외부 프로그램도 엄청나게 많기 때문에 서로 입출력을 주고받을 규약이 필요해서 만들어졌다. (초창기에 CGI를 C나 Perl로 작성해서 CGI script라고 부르기도 했다.)
하지만 이런 CGI의 방식들에 문제가 많아 나오게 된 것이 Servlet인데 그럼 어떤 문제가 있었는지 알아봤다.
CGI 장점
- 언어, 플랫폼 독립적이다
- 매우 단순하고 다른 server-side 프로그래밍 언어에 비해 advanced task를 훨씬 쉽게 수행할 수 있다.
- 재사용할 수 있는 CGI 코드 라이브러리가 풍부하다.
- CGI가 웹서버에서 실행될 때 안전하다.
- CGI 코드를 수행하는데 특정 라이브러리가 필요하지 않기 때문에 매우 가볍다.
CGI 단점
- 느리다(요청이 올 때마다 DB connection을 새로 열어야 한다).
- HTTP 요청마다 새로운 프로세스를 만들기 때문에 서버 메모리를 많이 잡아먹는다.
(servlet은 요청마다 스레드를 만든다.) - 페이지 로드 사이에 데이터가 메모리에 캐시될 수 없다.
단점들을 봤을 때 'HTTP 요청마다 새로운 프로세스를 만들기 때문에 서버 메모리를 많이 잡아먹는다.' 이부분이 이해가 잘 되지 않아 찾아봤다.
- 프로세스와 스레드
프로그램(Program) 이란
사전적 의미
“어떤 작업을 위해 실행할 수 있는 파일”
프로세스(Process) 란
사전적 의미
“컴퓨터에서 연속적으로 실행되고 있는 컴퓨터 프로그램”
메모리에 올라와 실행되고 있는 프로그램의 인스턴스(독립적인 개체)
운영체제로부터 시스템 자원을 할당받는 작업의 단위
즉, 동적인 개념으로는 실행된 프로그램을 의미한다.
참고 할당받는 시스템 자원의 예
CPU 시간
운영되기 위해 필요한 주소 공간
Code, Data, Stack, Heap의 구조로 되어 있는 독립된 메모리 영역
특징
프로세스는 각각 독립된 메모리 영역(Code, Data, Stack, Heap의 구조)을 할당받는다.
기본적으로 프로세스당 최소 1개의 스레드(메인 스레드)를 가지고 있다.
각 프로세스는 별도의 주소 공간에서 실행되며, 한 프로세스는 다른 프로세스의 변수나 자료구조에 접근할 수 없다.
한 프로세스가 다른 프로세스의 자원에 접근하려면 프로세스 간의 통신(IPC, inter-process communication)을 사용해야 한다.
Ex. 파이프, 파일, 소켓 등을 이용한 통신 방법 이용
스레드(Thread) 란
사전적 의미
“프로세스 내에서 실행되는 여러 흐름의 단위”
프로세스의 특정한 수행 경로
프로세스가 할당받은 자원을 이용하는 실행의 단위
특징
스레드는 프로세스 내에서 각각 Stack만 따로 할당받고 Code, Data, Heap 영역은 공유한다.
스레드는 한 프로세스 내에서 동작되는 여러 실행의 흐름으로, 프로세스 내의 주소 공간이나 자원들(힙 공간 등)을 같은 프로세스 내에 스레드끼리 공유하면서 실행된다.
같은 프로세스 안에 있는 여러 스레드들은 같은 힙 공간을 공유한다. 반면에 프로세스는 다른 프로세스의 메모리에 직접 접근할 수 없다.
각각의 스레드는 별도의 레지스터와 스택을 갖고 있지만, 힙 메모리는 서로 읽고 쓸 수 있다.
한 스레드가 프로세스 자원을 변경하면, 다른 이웃 스레드(sibling thread)도 그 변경 결과를 즉시 볼 수 있다.
출처
https://gmlwjd9405.github.io/2018/09/14/process-vs-thread.html
이처럼 프로세스가 스레드보다 큰 개념이고, 프로세스 안에 스레드가 존재하는데 CGI는 이 프로세스를 계속 재할당 하는 방식이므로 서버에 부하가 크게간다. 그래서 프로세스로서 인터프리터를 상주시키고, CGI로부터 프로그램을 호출 (= 스레드 단위로 실행) 해 부하를 줄임으로써 성능을 개선한 것을 'Fast CGI' 라고 부른다.
자바언어로 예를 들어보자면 CGI의 단점을 보완해 나온게 Servlet(Fast CGI)이다.
Servlet은 Tomcat이 이해할 수 있는 순수 Java 코드로만 이루어져 있는 웹서버용 '클래스'이다.
Java에서는 Servlet을 이용하여 CGI 프로그래밍을 할 수 있으며 Servlet은 프로그램이 실행될 때 스레드 단위로 실행되어 서버의 부하를 줄이고 CGI프로그래밍시 직접 코드에 설정을 추가해 줘야했던것을 없애줘 CGI프로그래밍을 쉽게 만들었다.
하지만 Java를 사용하여 웹페이지를 동적으로 생성하기 위해 코드안에 HTML 이 포함하는데 HTML형태로 출력하기 위해서는 print() 메소드를 사용하여 일일이 String으로 태그들을 양식에 맞춰 써야하므로 다른 서버사이드 언어에 비해 불편 하다. 또한 Java클래스 이기 때문에 테스트 하기위해서는 항상 빌드를 다시 하여 확인하여야 했고 이런 단점을 보완하기 위해 등장한것이 아래에 설명할 jsp이다.
JSP(JavaServerPage)
jsp는 html안에 자바 코드가 포함된 것으로 서버사이드 스크립트를 말한다. jsp는 실행시에는 Java Servlet 으로 변환된 후 실행되므로 서블릿과 거의 유사하다고 볼 수 있다. 하지만, 서블릿과는 달리 HTML 표준에 따라 작성되므로 웹페이지 작성이 편리해졌다. 클라이언트에서 서비스가 요청되면, JSP의 실행을 요구하고, JSP는 웹어플리케이션 서버(Tomcat)의 서블릿 컨테이너에서 서블릿 원시코드로 변환된다, 그후에 서블릿 원시코드는 바로 컴파일된 후 실행되어 결과를 HTML 형태로 클라이언트에 돌려준다. 이렇게 서블릿과 달리 JSP는 코드를 변경할 때마다 WAS에서 자동으로 빌드하고 클라이언트에 화면을 동적으로 보여주기 때문에 개발이 많이 편리해 졌다
java를 기준으로 설명한 것이며, 다양한 언어들이 CGI의 단점을 개선했다.
이렇게 애플리케이션단에서 동적 처리를 할 수 있게 해주는 것을 Web Container라고 부르며 Web server와 Web container를 합친 것을 우리는 WAS라고 부른다.
우선 기본적으로 web application server 앞에 web server를 두는 방식을 선정했는데 이러한 설계방식을 왜 많이 사용하는지에 대해서부터 먼저 알아보면 좋을 것 같다.
웹서버를 앞에 두는 이유?/ 프록시를 앞에두는 이유?
공통
1. HTTPS적용에 유리
2. ReverseProxy를 사용해서 실제 비즈니스로직이 이뤄지는 서버의 ip를 숨길 수 있음
3. 캐싱
4. 확장성
5. 고가용성
사진 2번에서처럼 보통은 webserver와 web application server를 같은 서버 내에 두는것이 그렇게 큰 이점이 있는것 같지는 않다. 정확한 벤치마크 테스트가 있으면 좋겠지만 이러한 테스트는 없기도 하고, 같은 서버에 뒀을때 큰 이점이라고 할 만한게 없다.
보통 ws와 was를 나누는것은 보안과 고가용성이라고 생각되는데, 같은서버에 두게 됐을 때 ip가 같고 포트가 똑같이 다 뚫려 있어 비즈니스 로직을 보호할 수 없고, 서버자원을 같이 공유하기 때문에 ws가 문제가 생기면 was도 문제가 생길 것이다.
WAS 선정에 대한 기준
1. 요청에 대한 응답이 빠른것이 좋다.
1-1. DB request 속도가 빨라야 한다.
1-2. JSON 직렬화 속도
2. 안정성 - 특별한 이슈가 있지 않은지
3. 개발 편의성 및 유지관리를 편하게 하기위한 기능(cors, method(post, get, delete, put), router...)제공
4. 러닝커브(팀원들이 사용해봤거나 금방 익힐 수 있는 언어, 직관적인 프레임워크 구조)
5. 개발 레퍼런스
6. 활발한 커밋
러닝커브, 언어별 이슈, 언어 레퍼런스(커뮤니티), 라이브러리(써야하는것)
웹서버나 WAS를 모두 비교하고 고른다는 것은 시간이 부족하다고 판단하여, 먼저 언어부터 고르기로 결정했다.
techempower benchmark를 참고하여 자주쓰이고 상위권에 있는 언어들의 벤치마크 결과는 전적으로 신뢰하기 어렵지만 자주 쓰이는 언어들은 뽑아올만 하다고 생각했다. 실제로 벤치마크 테스트를 진행한것이기도 하고, 상위권에 많이 올라온 언어는 웹프레임워크 언어로 많이 사용된다고 생각해 어느정도 필터링을 해도 괜찮겠다 생각했다.
1. rust
2. java
3. c++
4. go
5. scala
6. js or python or php
"우리 서비스에서 사용할 기술이나 서비스 내용에서 어떤게 장점이다 하면 더 좋을듯 "
해당 언어들의 번호는 벤치마크에서 응답속도가 빨랐던 순서이다.
여기서 팀이 익숙한 언어는 총 3가지이다.
세 종류의 언어 모두 편의성도 훌륭하고 개발 레퍼런스도 많고 커밋도 활발했다.
1. Java
- 플랫폼 독립적
- OOP
- 높은 안정성
2. python
- 타사 모듈 지원 가능
- 뛰어난 가독성
- 조직화된 데이터구조
- 빠른 개발
3. php
- 가장 많이 사용하는 언어
- 레퍼런스 가장 많음
- python보다는 아니더라도 배우기 쉬움
언어를 고를 때 가장 주목한 점은 '린 스타트업' 프로세스를 지향하는 우리 서비스는 팀원이 자주 바뀔 수도 있고 팀원 모두 프론트, 백엔드 모두 가능한 개발자로 구성되어 있었기 때문에 어느 누구라도 API 서버 작업에 투입되어야 할 수도 있다고 판단했다. 또한 그로스해킹을 통해 사용자들의 반응을 보고 빠르게 대응하고, 없앨 기능은 없애고 새로 만들 기능들은 빠르게 만들어야 한다. 그래서 데이터구조가 정형화 되어있고, 코드 가독성이 뛰어나고 레퍼런스가 활발한 python으로 언어를 선정했다.
Python Async (ASGI) Web Frameworks Benchmark
Python frameworks benchmarks
klen.github.io
- fullstack , micro 체크 (우리 기획에서 적합한 형태의 프레임워크로 선정)
-> FAST API
웹서버와 WAS 선정 완료!
참고
https://coresumo.com/difference-between-python-vs-php-vs-java/
https://www.thirdrocktechkno.com/blog/top-5-picks-for-backend-development-in-2021/
https://mitrodigitalmarketing.com/top-5-programming-languages-web-development/
https://inveritasoft.com/blog/the-best-web-application-development-languages
https://www.orangemantra.com/blog/java-vs-python/
https://live-everyday.tistory.com/197
https://velog.io/@seanlion/cgi
https://en.wikipedia.org/wiki/Web_server
https://jooona.tistory.com/135
https://m.blog.naver.com/goddlaek/220901890910
https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview
'Server' 카테고리의 다른 글
| S3 client SDK - Delete 403 access denied error (0) | 2022.08.10 |
|---|---|
| WebRTC란? (1) | 2022.08.09 |
| Docker - EFK 환경구축 과정 (0) | 2022.08.04 |
| 시스템 로그 수집 툴 - Fluented vs LogStash (0) | 2022.08.03 |
| 클라우드 서비스 - AWS 를 선택한 이유 (0) | 2022.07.18 |
댓글