AWS에 Parse를 Migration하는 절차

저번 시간 AWS instance를 생성하는 것까지 했습니다.

이제 본격적으로 스타트업 수준의 서버를 구축을 하고 서비스를 할 수 있게 해야하는데 

저희 서비스는 As A Service가 BaaS형식인 parse.com의 API를 이용해서 구현을 했기때문에 단기간에 기술을 개발하기에는 무리가 있다고 생각이 되어서 parse에서 서비스 종료와 동시에 아주 친절하게도!? opensource로 소스를 열어준 것을 이용해서 parse server를 migration하기로 결정하였습니다.

여기서 느낀 교훈은 얼마 전까지 parse를 찬양하시던 분들을 믿고 parse를 사용했다가 갑작스런 서비스 종료로 이제는 대기업도 완전히 믿으면 안되겠다 생각을 했습니다.

그리고 스타트업도 frontend든 backend든 스스로 무엇을 개발할 수 있게끔 부단히 노력을 해서 모든 부분의 기술력을 갖추어야한다는 생각을 했습니다.

제가 앞서 쓴 "Parse Server Migration 과 aaS" 라는 글에도 언급했다시피 SaaS > BaaS > PaaS > IaaS 순으로 기술적 의존도가 낮아집니다. 즉, IaaS가 현재 aaS에서 가장 기술적 의존도가 낮은 것이죠.

그래서 저희 스타트업은 결심 했습니다. PaaS 인 Heroku도 고려를 했지만 그만큼 개발이 쉽지만 이왕 개발할 거면 IaaS로 기술적 의존도를 낮추고 우리 스타트업의 기술력을 축적시키기 위해 IaaS를 선택했습니다.

더 살펴보시면 아시겠지만 각자 aaS이 장단점을 가지기 때문에 현재 기술적인 수준을 고려해서 서비스를 사용해야합니다.

저는 이 글 부터 AWS에 parse를 마이그레이션하는 방법을 기술하려고 합니다.

그리고 일단은 AWS에 parse를 옮기는 개념적 절차부터 살펴보겠습니다.

---------------------------- Step 구분선 ----------------------------

현재 Parce.com에서 서비스를 제공하고 계신 분들의 현재 상태가 Step O: 입니다. 

모든 개발자들이 현재 Step O:에서 서비스를 계속 제공할 수 있다는 생각과 초당 30 Request까지는 무료이기 때문에 사용을 했었죠.

아무튼 현재 Migration을 하지 않았다면 현재 상태를 나타내는 것이 Step O: 입니다.

Client : 현재 우리 parse service를 사용하는 모바일 사용자들

api.parse.com : 현재 서비스를 제공하는 Parse 서버

Parse Hosted DB : 현재 서비스를 제공하는 Parse 서버에서 제공하는 Host를 위한 DB

---------------------------- Step 구분선 ----------------------------

Step 1: 단계에서는 기존에 사용하던 Parse에서 제공하여 사용하던 DB를 내가 가지고 있는 저장소에 MongoDB의 응용프로그램에 사용할 수 있는 형태로 옮기는 작업을 말한다.

이 작업에서 MongoDB의 저장소는 개인의 PC가 될 수도 있고 아니면 다른 웹 저장소가 될 수도 있다. 다른 웹 저장소라고 하면 몽고랩(MongoLab)이라는 500MB라는 샌드박스를 받아서 DB Storage를 만들 수도 있고 아니면 AWS같은 서버를 받아서 데이터를 저장할 공간으로 사용할 수도 있습니다.

옮기려고 하는 저장소의 사이즈는 현재 parse에서 사용하고 있는 data 저장량의 3배이상은 가지고 migration하는 것을 추천합니다.

저희 스타트업은 여기서 AWS에 저장하는 방식으로 DB를 저장하도록 할 것입니다. 왜냐하면 다른 샌드박스를 써보니 latency가 엄청나게 발생해서 이미지를 전송하는 서비스에는 적합하지 않다는 생각을 했기 때문입니다.

서버를 선택하는 방식은 Price와 Performance의 균형점을 찾아서 결정해야 합니다. 막상 migration해서 서비스를 해보면 가격은 싸고 쓰기는 편리하지만 Performance가 안좋은 경우가 있어서 서비스에는 적합하지 않을 수 있기 때문입니다.

그리고 DB를 옮겼다고 해서 DB서비스가 종료되는 것이 아니고 계속적으로 연결을 되어있는 구조이기 때문에 지속적인 parse 서비스 이용이 가능합니다.

즉 DB 미러링과 같은 방식으로 옮겨서 서비스가 제공된다고 생각하시면 됩니다.

---------------------------- Step 구분선 ----------------------------

2단계에서 8단계입니다. 

여기서 Database는 일단 다음과 같은 조건이 만족되어야합니다.

1) MongoDB version 2.6.X or 3.0.X 가 만족되어야 합니다.

저희는 여기서 3.0.X로 MongoDB를 최신에 가까운 버전을 이용해서 구현을 하려고 합니다.

2) The failIndexKeyTooLong parameter 를 무조건 false로 setting하고 MongoDB를 절차를 진행하여야 합니다.




* 여기서 false로 두는 이유는 기존의 MongoDB는 field에 value를 저장하는데에 있어서 1024byte를 넘으면 error가 발생하게끔 기본 설정이 되어있습니다. 그래서 그것을 미리 일단 migration 작업은 해야하기 때문에 바꾸어 주어서 1024bytes를 넘게 만드는 것입니다.

물론 모든 DB migration이 끝나고 나면 다시 true로 바꾸어 줍니다.




3) SSL(Secure Socket Layer)을 사용하여 인터넷상의 정보를 암호화하여 전달하고 전달 받을 수 있다.( 추천하지만 필수는 아니다.)

우리는 SSL을 사용하여 정보를 보안할 것입니다.




* 여기서 SSL이란 넷스케이프사에서 개발한 인터넷 상에서 정보를 암호화하여 송/수신하는 프로토콜입니다. 인터넷 상에 사용되고 있는 데이터를 암호화하여 개인정보에 관한 민감한 부분을 안전하게 송수신 하도록 도와줍니다.




4) Latency가 오래걸리게 되면 Request와 Response가 제대로 안되어서 서비스가 안되는 경우가 생기니 서비스를 요소인 서버나 DB를 접근하는데에 너무 오랜 시간이 걸리지 않게 만들어야 합니다.

이렇게 4가지가 만족을 해야지 DB를 Migration 할 수 있습니다. 여기서는 절차만 알아보는 것이기 때문에 이 정도도 디테일하다고 생각이 됩니다.

여기서 다른 것은 AWS를 이용하여 Parse를 Migration 하는 것이기 때문에 MongoDB와 Local Parse Server는 분리 시키는게 원칙상 맞는데 저희는 서버와 DB를 같이 두려고 하고 같이 두는 곳은 AWS로 하려고 합니다.

* 나중에 서비스를 하려면 사용자의 DB가 있는 곳과 데이터를 처리해주는 로직이 있는 서버를 구분해서 두어야겠습니다. 아주 중요한 이야기 입니다.

***************이제 migration에 필요한 조건은 설명했고, 이제 Step: 2-8 절차에 대해서 AWS migration에 맞게 이야기 해보겠습니다.

Step 2: Local Parse Server를 셋팅해보고 확인 할 수 있는 확인 query를 던져 보고 서버가 작동하는지 일단 확인한다.

Step 3: Parse Server에 Cloud Code를 다루는 방법

* https://parse.com/migration parse migration guide를 참고하세요. 기존에 구현해 둔 Cloud Code가 없으면 그냥 넘어갑니다.

Step 4: Hosting

* 이 과정은 기존에 가지고 있는 Web endpoints 소스를 옮겨지는 웹 환경인 "도메인/parse"에서 사용할 수 있는 겁니다.

app.get을 이용해서 미들웨어로 사용할 수 있습니다.

Step 5: Files

서버에서 사용자를 위해서 저장하는 DB와 같은 data를 저장하기 위해서 MongoDB를 사용하기도 하고 S3를 사용하기도 합니다.

이 부분은 다음에 하도록 합니다. 서버가 구축되고 나서 고려해도 되는 부분이기 때문입니다.

Step 6: App Settings

이제 서버에 대한 전반적인 환경 셋팅은 마무리가 되었습니다. 물론 서버의 세부적인 서비스를 하기에는 보안이나 Latency를 고려해야하지만,

일단 이 단계에서 하는 것은 일단 기존에 Parse Service가 다른 IDC에 가서 똑같이 기능적으로만 작동을 하는지를 보는 것이기 때문입니다.

즉, 모든 endPoint(간단하게 client쪽이라 생각하면 된다.)에서 기존에 parse를 가리켰는데, 그 방향을 바꾸어서 migration하는 서버를 가리킬 수 있게 만드는 과정이다.

앱을 개발하고 Parse Server와 연동 사용하신다면 다음과 같은 고려는 해줍니다.

Step 7: Point Client to Local Parse Server

다음에 써있는 것처럼 최신 Parse SDK로 바꾸어 줍니다.

그리고 다음 사이트를 참고하여 Code Setting을 해줍니다.

https://github.com/ParsePlatform/parse-server/wiki/Parse-Server-Guide#using-parse-sdks-with-parse-server

예를 들어 Android는 다음과 같이 앱에 Code Settings를 합니다. 아마 기존에 initialize method가 있을 겁니다. 그 메소드의 방향은 기존의 Parse Server 입니다.

지금 쓰려고 하는 method는 최신 Parse SDK 에 들어있는 parameter 구성이 다른 오버로딩 메소드 입니다.

자세히 보시면 server를 가리키려는 IP가 세부 설정으로 가능하게 되어있습니다.

물론 지금은 localhost라고 되어있지만 이것을 현재 서버의 ip나 도메인으로 바꾸어 줍니다.

기본적으로 parse는 port사용을 1337로 하고 있습니다.

Step 8. checkPoint : Test Your App

이제 migration도 기능적으로 완료 되었습니다. 이 단계에서 해야할 것은 테스트 입니다.

여기서 테스트는 반드시 더미로 된 DB아니면 스냅샷을 이용해서 진행하셔야 합니다.

테스트하다 잘못되면 DB가 오류가 나는 수가 있습니다.

그냥 간단하게 어플리케이션용으로 parse를 사용한다면 그냥 앱이 정상 작동하는지 보면 됩니다.

일전에도 언급했다시피 여기서의 migration은 전적으로 기능적인 migration입니다.

---------------------------- Step 구분선 ----------------------------

이전 단계에서 local을 이용하지 않고 그냥 AWS를 이용했기 때문에 Step 8:에서 모든게 다 끝났습니다.

하지만 나머지 절차도 살펴보겠습니다. 

Step 9. Set Up Parse Server on Heroku or another infrastructure provider.

이미 지정해 두었던 AWS로 Parse-server를 설치하고 서버를 실행 시켜주면 끝나게 됩니다. Server가 Client를 받아들일 준비가 끝나게 됩니다.

AWS 외에도 Heroku, NodeChef, Digital Ocean, Google Cloud Platform, Azure

등이 있습니다.

Step 10. Point Client to Parse Server

앞서 한 것처럼 App의 방향을 기존에 Parse.com이 아닌 이제는 서비스를 하고 있는 Server를 가리키게 합니다.

Step 7:에 한 작업을 생각 하시면 됩니다.

11. Checkpoint: Test Your App

마찬가지로 Backend인 현재 AWS에서 parse-server가 App작동을 정상적으로 유지시키는 지를 봅니다.

---------------------------- Step 구분선 ----------------------------

12. Publish Your App

이제 Parse로 부터 migration을 완료하게 됩니다. 이제 parse.com에게 물리적인 Server의 dependency 없는 서비스를 개발을 완료하게 되었습니다.

* 다음 시간부터는 이번 시간에 설계해둔 절차를 따라서 서버를 직접 AWS에 migration하는 작업을 진행하도록 하겠습니다.