CODEOK.NET

Page history of 스타트업을 위한 기술 스택



Title: 스타트업을 위한 기술 스택 | edited by Youngrok Pak at 9 years, 2 months ago.

필자가 스타트업 개발자들에게 가장 많이 받는 질문은 기술 스택을 어떻게 구성할 것인가이다. 심지어 개발자가 아닌 창업자들도 기술 스택에 대해 자문을 구해오곤 한다. 그래서, FAQ 삼아 스타트업에게 적합한 기술 스택을 정리해보기로 했다.

본론으로 들어가기에 앞서 잠시 스타트업의 정의에 대해 합의하고 싶다. 필자는 린 스타트업의 저자 에릭 리스의 정의를 좋아한다.

A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.

쉽게 말해서 스타트업은 아주 불확실한 일을 하는 팀이라는 것이고 이 글에서 제시하는 기술 스택 역시 이런 특성을 고려할 것이다.

경고:이 글은 코덕넷의 다른 기사와 마찬가지로 객관적이고 중립적인 관점이 아니라, 필자의 경험과 지식에 따라 과감하고 단정적으로 기술을 평가할 것이다. 만일 자신이 사용하는 기술에 대한 부정적인 견해를 접했을 때 기분이 상하는 성격의 소유자라면 이 글은 더 이상 읽지 않기를 권한다.

서버 프로그래밍 언어와 프레임워크

보통 스타트업의 기술 선택에서 가장 중요한 것은 서버 프로그래밍 언어와 프레임워크다. 기술 스택의 다른 모든 것들을 합한 것보다 더 중요하다. 스타트업의 서버 프로그래밍 언어로 선택할 만한 것은 다음 세 가지 중 하나다.

  • 파이썬
  • 루비
  • 자바스크립트 (Node.js, io.js, ...)

한 때 자바도 웹 개발용으로 각광을 받았으나, 현 시점에서 자바와 위의 세 가지 대안의 생산성 차이는 몹시 크다. 자바는 이제 좀더 미션 크리티컬한 분야로 넘기도록 하자. 혹시 PHP를 생각하고 있을지 모르겠는데, PHP는 이제 미래가 없다. 간혹 간단한 웹사이트는 PHP가 가장 빠르다는 주장도 있었으나 요즘은 PHP가 간단한 웹사이트를 만드는 시간에 Rails나 Django는 제법 복잡한 웹사이트를 만들고 시간이 남아서 어드민까지 붙여놓을 수 있다.

언어를 선택하고 나면 프레임워크도 거의 결정되는 거나 마찬가지다.

  • 파이썬 - Django
  • 루비 - Ruby on Rails
  • Node.js - express.js

물론 다른 선택도 있으나, 이 세 가지 프레임워크는 널리 쓰이기도 하고, 딱히 큰 단점이 있는 것도 아니라서 다른 대안을 선택한다고 해도 특별히 나은 선택이 되기는 어려울 것이다. 

셋 중에 개발 생산성이 가장 뛰어난 것은 Ruby on Rails다. 다만, 그 높은 생산성을 얻기까지는 Rails를 깊이 파고 들어야 하고, 트렌드를 잘 따라가야 한다. 루비 언어를 깊이 아는 것보다 Rails를 깊이 아는 것이 더 중요하다. 서드 파티 코드를 넣기가 쉬워서 뭔가 구현하고 싶은 게 있을 때 찾아보면 거의 다 있고, 아주 쉽게 설치할 수 있기 때문에 얼핏 어려워 보이는 기능을 순식간에 구현하곤 한다. 그래서 이 맛에 길들여진 Rails 개발자들은 다른 프레임워크를 거부하는 경우를 흔히 볼 수 있다. 설령 여러 가지 이유로 다른 언어를 쓰더라도 웹 개발만큼은 Rails를 버리지 않는다.

반면, Django는 초기 학습 장벽은 비슷하지만 그걸 넘어서고 나면 그 다음에는 별로 학습할 게 없다. 그 다음부터는 Django보다 파이썬이 중요하다. Ruby on Rails는 문제를 Rails로 해결한다면, Django는 문제를 파이썬으로 해결한다. 그래서 중급 이상으로 올라서는 것은 Django가 더 빠르나, Django를 계속 깊이 판다고 해서 큰 이득이 있는 것은 아니다. 개발 생산성의 성장 그래프를 그린다면 다음과 같을 것이다.

Node.js는 요즘 인기를 끌고 있긴 하나, io.js의 분화 같은 일도 있고, 콜백지옥도 아직 완전히 해결된 상태가 아니다. express.js도 훌륭하지만 아직 Django나 Rails에 비하면 부족함이 있다. 그래서 일반적인 웹사이트나 API 서버를 개발한다면 Node.js는 파이썬이나 루비에 못 미친다. 그럼에도 불구하고 세 가지 권고안 중에 들어가는 이유는 전통적인 스타일의 웹과 다른, Single-page_application의 경우에는 Node.js에 유리한 점이 많기 때문이다. 특히 AngularJS 등의 자바스크립트 MVC 프레임워크와 결합하면 클라이언트와 서버의 코드를 매끄럽게 이어지게 개발할 수 있다. 그리고 웹앱 뿐 아니라 채팅처럼 실시간으로 커뮤니케이션이 일어나는 기능을 가장 손쉽게 구현할 수 있는 방법인 socket.io도 Node.js에 기반하고 있다. 타 언어도 socket.io를 지원하지만 Node.js에서 가장 사용하기 쉽다. 

단, Node.js를 사용할 때는 신경써야 할 점이 두 가지 있다. 하나는 콜백지옥에 대한 해법을 선택해야 한다는 것이다. node-fibers가 비교적 일찍 나와서 여러 라이브러리에 적용이 되어 있으나, 자바스크립트 커뮤니티에서는 generator를 더 밀고 있다. generators-vs-fibers 같은 글이 선택에 도움을 줄 것이다. 사용하려는 다른 라이브러리가 둘 중에 뭘 사용하느냐에 따라 선택하는 것도 방법이다. 참고로 step이나 promise는 대안처럼 보이지만 별 도움이 되진 않는다.

두번째 고민해야 하는 것은 자바스크립트를 그대로 쓸지, 아니면 커피스크립트 같은 자바스크립트 기반의 다른 스크립트 언어를 쓸지이다. 자바스크립트를 콜백지옥과 함께 쓰다보면 코드 가독성이 심각하게 떨어지기 쉬운데, 이럴 때 커피스크립트가 도움이 될 수 있다. 

 

셋 중에 필자의 추천은 파이썬과 Django다. 그 이유는 단점이 적기 때문이다. Rails는 최고의 생산성을 낼 수 있다는 뚜렷한 장점이 있고 진입장벽은 높지 않지만, 높은 수준에 도달하기까지는 학습 분량이 적지 않고 - 물론 자바와 스프링에 비할 바는 아니지만 - 아직도 성능 이슈가 약간 있다. Node.js는 single page application이나 채팅에서 강점을 보이지만 그 외에는 Django나 Rails보다 많이 약하다. 이에 비하면 파이썬과 Django는 엄청난 장점이 있는 것은 아니지만 단점이 별로 없어서 두루 쓸 수 있고, 비교적 짧은 시간에 학습 장벽을 넘을 수 있다.

데이터베이스

RDBMS vs NoSQL

데이터베이스는 우선 RDBMS를 쓸 것이냐 NoSQL을 쓸 것이냐부터 선택해야 한다. 물론 RDBMS가 여러 모로 유리하다. 많은 스타트업들이 자신들의 서비스가 대박이 나면 그냥 RDBMS로 버티지 못하는 건 아닐까 걱정을 하고, 처음부터 대용량을 커버할 수 있는 설계를 하고 싶어한다. 하지만 RDBMS의 한계는 생각보다 아주 멀리 있다. 우선, 리플리케이션이나 여타 RDBMS를 스케일업할 수 있는 수단을 쓰지 않고 순수하게 RDBMS 서버 한 대에 쿼리 튜닝만 잘 해놓아도 국내에서 방문자 10위권 사이트 정도는 커버가 된다. 간혹 하루 방문자 10만명 내외의 사이트인데 DB가 부하를 못 견딘다고 NoSQL로 가야하는 거 아니냐고 묻는 팀도 있는데, 이건 전적으로 쿼리 튜닝의 문제다. 쿼리 튜닝도 고난이도의 튜닝이 필요한 게 아니라, 잘 정규화가 되어 있고 기본적인 인덱스만 잘 걸려 있으면 된다. 그러면 Django나 Rails에서 사용하는 ORM을 그대로 쓰면서 성능 문제를 해결해갈 수 있는 것이다.

만약 정말로 비즈니스가 대박이 나서 저 정도로는 감당할 수 없는 상황이 되어간다고 해도 방법이 있다. 캐시를 추가하면 캐시 전략에 따라 다르지만 수 배에서 수십 배의 부하를 감당할 수 있다. 이것만으로도 많은 상황이 해결될 것이다. 그리고 read-only 리플리케이션을 붙이면 수 배 확장 가능하고, 샤딩을 하면 데이터 사이즈에서의 대용량도 커버 가능하다. 이 정도 수준까지 하면 사실상 국내 최고 수준의 트래픽도 감당할 수 있다. 그리고 여기까지 하는 것도 이미 사례들이 많아서 그리 어려운 일이 아니다.

이걸로도 해결이 안되는 스케일이 되더라도 여전히 솔루션은 존재한다. 미들웨어를 투입할 수도 있고, 테이블 설계를 단순하게 할 수도 있고, 부분적으로 NoSQL을 사용할 수도 있다. 어쨋든 용량이 커진다고 해서 RDBMS로 만든 것을 갈아엎고 NoSQL을 도입해야 하는 것은 아니고 RDBMS를 주력으로 쓰면서 계속 성능을 개선해갈 수 있다.

그렇지만 사실 RDBMS의 한계보다 스타트업에게 더 중요한 것은 그 한계를 만날 수 있게 되느냐일 것이다. 그 한계를 만나려면 어쨋든 제품이 성공해야 하는 것이고, 제품을 성공시키려면 개발 생산성을 우선할 수 밖에 없다. 그렇게 해서 비즈니스가 성공하고 나서 회사의 자원이 넉넉해지면 나중에 성능을 개선할 방법은 얼마든지 있다. 그래서 초기 단계의 스타트업이 성능을 이유로 NoSQL을 선택할 필요는 없다.

MySQL vs PostgreSQL

RDBMS 중에 선택지는 사실상 둘 뿐이다.

  • MySQL
  • PostgreSQL

둘다 나쁘지 않은 선택이다. MySQL이 관리하기는 좀더 쉽다. phpmyadmin 같은 훌륭한 관리 도구도 있고, 세계적으로 가장 널리 쓰이는 DBMS이기 때문에 문서나 각종 레퍼런스도 많다. MySQL에 문제점도 아주 많이 있지만, 그 문제점에 대한 대안조차도 검색하면 다 나올 정도다. 다만 SQL 표준을 지키지 않는 부분이 좀 있고, 개발자의 합리적인 예상을 벗어나는 동작들이 가끔 있기 때문에 간혹 어이 없는 상황을 겪기는 할 것이다. 그리고 MySQL이 오라클에 넘어갔기 때문에 오픈소스 계열은 MySQL을 fork해서 MariaDB를 쓰고 있어서 이 혼란도 부담이 될 수 있다. 한 가지 중요한 포인트는 위치정보를 다루는 기능이 부족하다는 것이다. 스토리지로 MyISAM을 쓸 때만 위치정보 인덱스가 지원되는데 요즘은 MySQL 스토리지 엔진으로 InnoDB를 쓰는 게 대세인지라 위치정보를 제대로 활용하기 어렵다. 

PostgreSQL은 좀더 순수한 오픈소스로 자리를 지켜왔고, 표준 SQL을 잘 준수하고 있으며, RDBMS로 갖춰야 할 기능들을 잘 갖추고 있다. GIS 지원이라든지, JSON type, Array type 등 여러 가지 기능 면에서도 PostgreSQL이 앞선다. 다만 사례가 부족해서 MySQL보다 좀더 정보를 찾는데 어려움을 겪을 수는 있다.

성능 면에서는 단순한 쿼리일수록 MySQL이 더 낫고, 복잡해질수록 PostgreSQL이 낫다고 하나, 최신 버전에 대해 객관적으로 비교할 수 있는 벤치마크는 드물다. 필자의 경험에서는 MySQL이 이 잘 돌아갔던 사이트보다 10배 정도 작은 규모의 사이트에서 PostgreSQL로 성능 때문에 고생했던 적이 있다.

MongoDB?

앞서 굳이 NoSQL을 쓸 필요가 없다고 했으나, 그래도 MongoDB는 한 번 검토해볼 가치가 있다. RDBMS가 전반적으로 유리함에도 불구하고 MongoDB가 괜찮을 수 있는 이유로 다음의 이유들을 꼽을 수 있다.

  • 위치정보를 다루기 쉽다.
  • 스키마와 인덱스의 자유도가 높다.
  • Node.js와 궁합이 좋다.

MongoDB는 기본으로 2차원 인덱스인 2d가 탑재되어 있고, 최근에는 구의 표면 위치를 다룰 수 있는 2dsphere 인덱스가 추가되어 더욱더 정확하게 위치정보를 처리할 수 있다. 위치정보를 다룰 때 중요한 것 중 하나가 현재 위치 주변에서 거리 순서로 정렬한 N개의 결과를 보여주는 KNN 쿼리인데 MongoDB는 이 KNN 쿼리가 문법도 편하고 성능도 가장 좋다. 그래서 데이터베이스를 MySQL로 쓰더라도 위치정보는 따로 MongoDB에 저장하기도 한다. 물론 PostgreSQL도 PostGIS로 지원하긴 하지만 MongoDB가 성능도 더 좋고 더 쉽다.

스키마의 자유도가 높다는 것은 장점일 수도 있고 단점일 수도 있는데, 필자의 경험에서는 Node.js에서 사용할 경우에 자바스크립트 객체를 그대로 데이터베이스에 넣고 쿼리할 수 있어서 상당히 편리했다. 특히 복잡한 구조의 데이터이지만 어떻게 활용할지 정책이 정해지지 않은 상황에서 데이터를 대충 밀어넣고 나중에 인덱스를 걸 수 있다는 점은 장점이다. 예를 들면 위치기반 앱을 만들 때 포스퀘어 연동을 해서 API에서 받은 장소의 데이터를 받았을 경우 RDBMS라면 나중에 이 데이터에서 어떤 부분이 필요할지 미리 예상해서 위치좌표라든가, 카테고리 분류명 등을 따로 필드로 만들어서 빼놓아야 하는데, MongoDB에서는 처음부터 고민할 필요 없이 일단 넣어놓고 나중에 필요해질 때 데이터 구조를 바꾸지 않고 인덱스를 걸 수 있다. 

다만, Django에서는 스키마 변경을 자동으로 해줄 수 있기 때문에 상대적으로 스키마 변경의 자유도는 큰 장점이 아닐 수 있다. 그리고 PostgreSQL은 최근에 JSON 타입에 인덱스를 걸 수 있는 기능을 추가해서 결과적으로 MongoDB가 할 수 있는 일은 PostgreSQL도 다 할 수 있게 되었다. 

정리하면 다음과 같이 권고할 수 있겠다.

  1. 저장하려는 데이터가 단순하고, 데이터베이스에 대한 지식이 적다면 MySQL을 사용하라.
  2. 위치정보를 많이 다루고 Node.js를 사용한다면 MongoDB가 장점이 있다.
  3. 데이터베이스를 깊이 있게 배워가면서 할 생각이 있다면 PostgreSQL이 좋다.

프론트엔드

여기서 말하는 프론트엔드는 웹의 프론트엔드로 HTML, CSS, JavaScript의 역할을 말한다. 프론트엔드에서는 다음과 같은 기술을 알고 시작하면 좋다.

jQuery는 설명이 필요하지 않을 것이다. Bootstrap은 CSS 프레임워크인데 다음과 같은 이득을 얻을 수 있다.

  • 디자인 역량이 부족한 엔지니어 중심의 팀이 그럭저럭 괜찮은 디자인의 웹사이트를 만들 수 있다.
  • 웹사이트의 UI를 컴포넌트 기반으로 설계할 수 있는 기반이 되어 디자인 및 개발 비용을 절감할 수 있다. 

https://wrapbootstrap.com/처럼 Bootstrap 테마를 판매하는 곳도 있다. http://bootsnipp.com/에서는 Bootstrap 기반의 다른 컴포넌트들도 가져다 쓸 수 있다.

Font Awesome은 다양한 아이콘을 폰트처럼 쓸 수 있는 라이브러리다. 자체적으로 아이콘을 디자인하기 어려운 경우에도 사용하지만, 디자인 역량이 풍부한 팀의 경우에도 효율성 때문에 사용하는 경우가 있다.

Bower는 위와 같은 프론트엔드 라이브러리들을 쉽게 가져다 쓸 수 있게 해주는 패키지 매니저다. 대부분의 프론트엔드 라이브러리가 이미 등록되어 있을 뿐더러, 인기순으로 정렬해볼 수도 있기 때문에 비슷한 카테고리의 라이브러리 중에서 골라야 될 때도 도움을 준다.

이외에 less나 sass처럼 CSS를 유연하게 작성할 수 있게 해주는 것도 있지만, CSS를 충분히 배우기 전까지는 쓰지 않기를 권한다.

Angular.js 등의 MVC 프레임워크는 단일 페이지에서 많은 기능을 소화하는 웹앱 스타일로 개발하는 경우를 제외하면 권하지 않는다. 그냥 전통적인 웹에 약간의 동적인 기능이 들어간 페이지를 개발할 때는 jQuery와 Ajax를 이용하는 방식에 비해 별다른 장점이 없다. 더구나 Angular.js를 잘 쓰려면 자바스크립트와 CSS, DOM을 잘 아는 걸로는 소용이 없고 Angular.js 자체를 많이 알아야 하는데, 이건 오로지 Angular.js를 쓸 때만 도움이 되는 지식인지라 ROI가 낮은 투자가 된다. 다른 MVC 프레임워크로 넘어가면 또 새로 배워야 한다. 

서버 배치(Deployment) 

OS

개발이 완료되면 다음으로 부딪히는 문제는 프로덕션(production) 환경에 애플리케이션을 배치하는 일이다. 그 중에 제일 먼저 고민하게 되는 문제는 아마도 OS일 것이다. 맥도 서버 솔루션이 있지만 아마 비싸고 가성비 낮은 맥을 프로덕션 서버로 쓰는 사람은 없을 것이고, 선택은 윈도우와 리눅스로 갈릴 것이다. 게임 서버를 만든다거나, 혹은 개발자들이 모두 윈도우에서만 개발을 할 줄 안다면 윈도우를 선택하게 될 것인데, 그게 아닌 대부분의 경우는 물론 리눅스가 좋다. 라이선스 비용도 안 들고, 서버 기술들이 모두 리눅스를 중심으로 발전하고 있기 때문이다. 리눅스 중에서 어떤 배포판을 고르느냐도 중요한데, 이건 두 가지로 이야기할 수 있겠다.

  1. 리눅스에 대해 깊이 이해하고 있는 시스템 엔지니어가 있다면 그 엔지니어에게 선택을 맡긴다.
  2. 잘 모르면 우분투를 선택한다.

아마도 리눅스를 잘 아는 SE라면 필자의 조언이 필요 없을 것인데, 이런 엔지니어를 보유하고 있는 스타트업은 거의 없다. 그러니까 아마도 대부분의 스타트업은 우분투를 고르는 게 현명할 것이다. 우분투가 가장 좋은 배포판이라는 뜻은 아니다. 그냥 제일 관리하기 편한 배포판이기 때문이다. 보안이나 성능 같은 이슈가 중요해지면 다른 배포판을 찾아야할지도 모른다. 

웹 서버 및 애플리케이션 서버

OS를 고르고 나면 다음은 웹 서버와 애플리케이션 서버를 선택하는 것이다. OS를 리눅스로 골랐다고 가정하면 웹 서버는 두 가지 선택이 있다.

  • Nginx
  • Apache

웹 서버의 역할은 요청을 애플리케이션 서버로 라우팅해주는 것과 정적인 자원을 서비스하는 것이다. 원래는 Apache가 절대 강자였으나, 이제 Nginx로 대세가 넘어간 듯 하다. Nginx는 등장 초기부터 성능이 좋았고 설정도 조금 더 간단해서 인기를 끌었다. 부하가 높은 상황에서 에러가 많다는 주장도 있었으나 지금은 충분히 안정화된 상태이다. Nginx를 추천한다.

애플리케이션 서버는 프로그래밍 언어에 따라 나뉘는데, Node.js는 별도의 애플리케이션 서버가 필요 없다. 자체적으로 내장된 http 모듈의 서버가 이미 성능과 안정성 면에서 인정을 받아서 프레임워크에서도 그대로 쓰는 경우가 많다. 파이썬은 웹 서버를 Apache로 쓰는 경우는 mod-wsgi를 사용하며 그 외의 경우는 uWSGI와 gunicorn으로 갈린다. 요즘은 성능 면에서 좀더 뛰어난 uWSGI가 대세이므로 uWSGI를 추천한다. Ruby on Rails는 최근 추세를 잘 모르지만 Passenger, Unicorn, Puma가 경합하는 듯 하고, JRuby도 간혹 쓰인다고 하며, Rails 커뮤니티에서 1옵션으로 권고하는 안은 Passenger인 듯 하다.

이미지 서버

많은 이미지를 전송하는 서비스는 이미지 서버도 중요하다. 이 문제에 대해 잘 모르는 개발자들은 흔히 다음과 같은 과정을 겪는다.

  1. 이미지 업로드하면 서버의 특정 디렉토리에 저장하도록 코딩한다.
  2. 업로드한 이미지를 저장하는 디렉토리를 웹 서버에서 연결해서 서비스한다.
  3. 서버 1대일 때는 잘 동작한다.
  4. 서버 2대가 되면 가끔 이미지가 안 뜬다.
  5. 이미지가 안 뜨는 이유는 서버 2대에 각각 업로드된 파일이 다른데 이미지 파일에 대한 요청은 두 서버에 같이 오기 때문. 서버 간 이미지 동기화가 필요하다는 점을 깨닫는다.
  6. 업로드를 하고 나면 동기화를 하도록 코드를 작성한다.
  7. 업로드 직후 동기화하기 전까지 또 이미지가 가끔 안 뜬다.
  8. 동기화 코드가 끝나야 데이터베이스에 기록하도록 변경한다.
  9. 느려진다.

물론 더 나은 방법이 있다. AWS S3에 업로드를 하는 것이다. S3는 무한대의 저장 공간과 무한대의 서비스 용량을 가졌지만 한 대의 서버처럼 다룰 수 있다. 동기화 문제는 S3가 알아서 한다. 다만 S3는 다소 비싸다. 이 문제를 해결하는 더 저렴한 방법은 CDN을 사용하는 것이다. CDN은 축약된 원어(Content Delivery Network)에서 보듯, 컨텐츠를 전송하는데 특화된 서비스다. 이미지나 동영상 같은 컨텐츠를 서비스할 때 사용하며 S3보다 저렴하고 성능도 높다. AWS에도 CloudFront가 있고, 아카마이, CDNetworks 등의 CDN 업체가 있다. 다만, S3보다는 설정이 조금 더 많이 들어가고, 별도의 계약이 필요한 경우도 있기 때문에 스케일이 크지 않을 때는 S3, 혹은 그와 유사한 서비스를 이용하는 것이 좋다. 거듭 이야기하지만, 이미지 서버를 직접 구축하는 것은 좋은 생각이 아니다. 생각보다 할 일이 많을 것이다.

작업 큐

작업 큐(Task Queue)는 비동기로 처리해야 하는 작업들을 담당한다. 예를 들어서 쇼핑몰에 주문이 접수되었을 때 확인 문자를 고객에게 보내준다고 해보자. 그럼 주문 요청이 애플리케이션 서버로 들어오면 주문을 DB에 기록하고 문자를 보내고 나서 주문 완료 페이지를 띄울 것인가? 문자를 보내려면 보통 SMS 업체의 서버에 요청을 보내게 되는데, SMS 업체 서버가 응답이 늦으면 쇼핑몰의 주문 응답도 같이 늦어지게 된다. 그래서 이런 건 일단 주문 처리를 완료하고 나서 고객에게 주문 완료 페이지를 띄우고, 문자 전송은 작업 큐에 넣어둔다. 그러면 작업 큐가 문자 전송을 처리하게 된다(이런 작업 큐를 제공하는 SMS 업체도 있긴 하다). 그 외에도 앱에 푸시를 보낸다든지, 동영상 업로드를 받고 나서 인코딩을 한다든지 하는 작업은 고객의 요청으로부터 시작되는 작업이지만, 고객에게는 일찍 응답을 주고 잠시 후에 비동기로 작업을 처리하게 된다. 이런 일을 담당하는 것이 작업 큐다.

기술 추천보다 설명이 길었는데, 아무튼 작업 큐로 쓸만한 것의 목록은 queues.io에서 볼 수 있다. 파이썬을 사용한다면 celery가 좋다. 다른 언어도 언어마다 있으니 검색해보기 바란다. 어쨋든 중요한 건 시간이 오래 걸릴 수 있는 작업은 사용자의 요청 시점에 바로 처리하지 말고 작업 큐에 넘겨서 비동기로 처리해야 한다는 것이다.

간혹 rabbitmq나 activemq 등의 메세지 큐로 이런 기능을 구현하기도 하는데, 이것도 가능하긴 하지만 작업의 상태를 직접 관리해야 해서 다소 번거롭다. celery처럼 메세지 큐를 래핑한 작업 큐를 쓰는 것이 보다 편리하다. 

주기적인 작업

호스팅

호스팅은 크게 세 가지로 나눌 수 있다. 

IaaS와 PaaS의 차이에 대해서는 IaaS, PaaS, SaaS란 무엇인가요?를 참조하기 바란다. 

비용은 국내 호스팅 업체가 비교가 안될 정도로 저렴하다. 하지만 서버를 자유롭게 추가하거나 빼거나 하기는 어렵다. AWS는 가장 안정적이고 사용하기 편리하지만 비싸다. 초기에는 AWS를 사용하다가 비즈니스가 궤도에 오르고 서버 비용이 중요해지기 시작하면 국내 호스팅으로 옮기는 것도 방법이다. PaaS는 추천하지 않는다. 상당히 편리하긴 하지만 여러 가지 제약 때문에 자유도도 떨어지고 비싸다. 클라우드 중에서는 가격 대 성능비를 열심히 따져보고 고르...지 말고 그냥 AWS를 쓰는 게 좋을 것이다. 레퍼런스도 많고 한국 담당자도 있기 때문에 한국어로 질문의 답변을 받을 수도 있다.

물론 자금은 부족한데 수익이 나기 전까지 트래픽이 많이 발생할 가능성이 높다면 무조건 국내 호스팅이 좋다. 

모니터링

데이터 분석

기초적인 성능 관리 

 

 

 

 

Wiki at WikiNamu