기본 콘텐츠로 건너뛰기

microservice 기반 meteor application 설계 /w DDP

특정 업무가 장애가 일어나도 전체가 다운되지 않는 서비스를 Meteor 로 만들 수 있지 않을까 라는 생각을 하고 있었는데 실제로 한번 해보았다.

로긴 서버와 N개의 업무서버가 하나의 DB를 바라보고 클라이언트에서 로긴 서버에 계정생성/접속 후 토큰을 꺼내와서 나머지 서버에 접속하는 그림을 그려보았다.

업무 서버의 경우 웹앱에서 접근 문제가 있기 때문에 CORS를 열어준다.

Meteor.startup ->
  WebApp.rawConnectHandlers.use (req, res, next)->
    res.setHeader "Access-Control-Allow-Origin", "*"
    next()

iOS/Android 앱의 경우는 사실 상관이 없지만 webApp인 경우엔 꼭 필요.

반대로 webApp 인 경우는 client 폴더에만 작업하면 되는데
가장 먼저 실행하는 파일(ex. client/lib) 에 DDP와 Collection 연결하는 부분을 만들어 준다.

# global namespace
@ddps =
  loginDDP : DDP.connect "http://localhost:4100"
  chatDDP : DDP.connect "http://localhost:4200"

# models
@Chats = new Mongo.Collection 'chats', ddps.chatDDP

그리고 Meteor App 이 시작하는 시점에 아래와 같이 구성한다.

Meteor.startup ->
  Meteor.connetion = ddps.loginDDP
  Tracker.autorun ->
    if Meteor.user()?
      unless Meteor.loggingIn()
        console.log Meteor.user()?.username
        ddps.chatDDP.call "login",
         resume: Accounts._storedLoginToken()
        , (e, r)->
          unless e
            console.log "chatDDP login", r
          else
            throw e
    else
      ddps.chatDDP.call "logout", (e)->
        console.log "chatDDP logout" unless e
      console.log "out"

Meteor.connection을 login의 DDP로 지정해놓으면 마치 자기 서버인것 처럼 쓸 수 있어서 편리하다.
그리고 Meteor.user() 가 Reactive Datasource 이므로 Tracker.autorun 안에서 로그인 서버에서 로그인/아웃시 다른 업무 서버도 로그인/아웃 하도록 DDP.call "login" method를 불러준다.

단,  DDP 로그인 시 Accounts 패키지의 _storedLoginToken()을 통해 token값을 꺼내서 로그인 방식과 상관없이 동일하게 처리하면 편리하다.

헬퍼나 템플릿 안에서 쓸때도 기존 방식과 거의 같다.

Template.chatroom.onCreated ->
  ddps.chatDDP.subscribe 'getChats', {}

onCreated 에선 this.subscribe (혹은 @subscribe) 대신 DDP.subscribe를 사용하고 Method.call도 같은 방식으로 ddps.chatDDP.call "addChat", params 와 같이 사용한다.

이와 같은 방식으로 개발 중인데 장단점을 따져보면
장점.
  1. 작게 나눠서 독립적인 서버를 개발하므로 단인 서비스의 복잡도가 낮다.
  2. 오류와 서버다운에 대해 독립적이고 스케일 아웃도 간편
  3. 싼 클라우드 호스팅을 여러개 나눠서 쓸 수 있다.
  4. I/O 부담을 분산한다.
단점.
  1. 개인 개발 서버 환경이 매우 무겁다.(......)
정도인데 꼭 Meteor 가 아닌 다른 프레임웍(Horizon이라던가 Phoenix라던가 혹은 기타 레거시 웹서비스등등)하고 연동도 자유로와서 꽤 연구 가치가 있다.

댓글

이 블로그의 인기 게시물

cURL로 cookie를 다루는 법

http://stackoverflow.com/questions/22252226/passport-local-strategy-and-curl 레거시 소스를 보다보면 인증 관련해서 cookie를 사용하는 경우가 있는데 가령 REST 서버인 경우 curl -H "Content-Type: application/json" -X POST -d '{"email": "aaa@bbb.com", "pw": "cccc"}' "http://localhost/login" 이렇게 로그인이 성공이 했더라도 curl -H "Content-Type: application/json" -X GET -d '' "http://localhost/accounts/" 이런 식으로 했을 때 쿠키를 사용한다면 당연히 인증 오류가 날 것이다. curl의 --cookie-jar 와 --cookie 옵션을 사용해서 cookie를 저장하고 꺼내쓰자. 각각 옵션 뒤엔 저장하고 꺼내쓸 파일이름을 임의로 지정하면 된다. 위의 과정을 다시 수정해서 적용하면 curl -H --cookie-jar jarfile "Content-Type: application/json" -X POST -d '{"email": "aaa@bbb.com", "pw": "cccc"}' "http://localhost/login" curl -H --cookie jarfile "Content-Type: application/json" -X GET -d '' "http://localhost/accounts/" 이렇게 사용하면

MQTT Broker Mosquitto 설치 후 설정

우분투 기준 $ sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa $ sudo apt-get update 하고 $ sudo apt-get install mosquitto 으로 설치하면 서비스까지 착실하게 올라간다. 설치는 간단한데 사용자를 만들어야한다. /etc/mosquitto/mosquitto.conf 파일에서 권한 설정을 변경하자. allow_anonymous false 를 추가해서 아무나 못들어오게 하자. $ service mosquitto restart 서비스를 재시작. 이제 사용자를 추가하자. mosquitto_passwd <암호파일 경로명> <사용자명> 하면 쉽게 만들 수 있다. # mosquitto_passwd /etc/mosquitto/passwd admin Password:  Reenter password:  암호 넣어준다. 두번 넣어준다. 이제 MQTT 약을 열심히 팔아서 Broker 사글세방 임대업을 하자.

OS X 터미널에서 tmux 사용시 pane 크기 조절

http://superuser.com/a/660072  글 참조. OS X 에서 tmux 사용시 나눠놓은 pane 크기 조정할 때 원래는 ctrl+b, ctrl+↑←→↓ 로 사이즈를 조정하는데 기본 터미널 키 입력이 조금 문제가 있다. 키 매핑을 다시 하자 Preferences(cmd+,) > Profile >  변경하고자 하는 Theme 선택 > Keyboards 로 들어가서 \033[1;5A \033[1;5B \033[1;5C \033[1;5D 를 순서대로 ↑↓→←순으로 매핑이 되도록 하면 된다. +를 누르고 Key에 해당 화살표키와 Modifier에 ctrl 선택 한 후 <esc>, [, 1, ;, 5 까지 한키 한키 입력 후 A,B,C,D를 써준다. 잘못 입력했을 땐 당황하지 말고 Delete on character 버튼을 눌러 수정하도록 하자. 그리고 다시 tmux에서 ctrl+b, ctrl+↑←→↓로 사이즈를 조절해보자. 잘 된다.