【Parse移行手順】DB:mLab, Web:さくらVPSの構成で移行を行いました
以前Parseの移行先はどこがいいのかという記事を書きました。
色々試行錯誤してきたのですが、一通り対応が完了したので手順を公開していこうと思います。なお、私はDBにmLabを使い、WebサーバはさくらVPSで構築という構成を採用しました。
このような方におすすめしています：
- Parseを使ったアプリの運営をしているが、具体的な移行方法がわからず困っている人
- サーバサイドの構築もそこそこできる人
- 他のBaaSに移行するリスクを感じている、もしくはこれを機に自前で運用しようと思っている人
目次：
- Parse移行についての概要
- DBの移行
- Parse Serverの移行
- SDKの更新
- Parse Dashboardの移行
- 最後に
Parse移行についての概要
まず前提として、Parseのサービス自体は2017年1月をもって終了します。いままでParseに依存してきた人はこのタイムリミットまでにデータを他のサービスに移行するか自前で環境を構築する必要が出てきます。なお、公式からは下記のようなスケジュールが推奨されていますが、基本的にこのくらい余裕をもって対応することをおすすめしています。理由としてはParse Serverの存在があります。今までSDK経由でアプリからParse ServerにアクセスしてDBからデータを取得していましたが、このParse Serverが2017/01をもって使えなくなる関係で、この時までにユーザサイドのアプリの接続先が新しいものになっていないとアプリが存続不可能になる可能性があるためです。
簡単な概要図を作りました。イメージとしてはこんな感じです。
では具体的な手順を見ていきましょう。
DBの移行
今回の作業で一番重要かつ慎重にやらないとならないのはここではないでしょうか。今までのアプリ運営で得た様々な重要データが含まれるわけでここを失敗すると大変なことになります。ガイドではmongoDBのインフラプロバイダであるmLabとObjectRocketsへの移行が推奨されています。もちろん自前でmongoDBを構築しても構いませんが、今回私はmLabを使うことにしました。理由としてはリスクとコストのバランスでしょうか。DBは自分で構築することもできますが、なかなか運用コストが高くかつトラブルがそこそこ起こりうるので、外のインフラに頼ることにしました。mongoDBに詳しいエンジニアがいるチーム以外は外出しをおすすめします。
では早速mLabにアクセスしてサインアップしましょう。既にアカウントがある人はログインして画面右上にCreate newをクリックし、DBを作っていきます。(私のアカウントでは既にdevと本番のDBがあるので画面のみためが多少違うと思います。)
Single-nodeのSandboxを選び、適当な名前をDBにつけて「create new MongoDB deployment」をクリックします。Cloud Providerはどこでも構いません。私はAWSにしました。もし本番で運用したい場合はもっとリッチなプランに変更してください。sharedのクラスタで月間$15くらいですね。この価格でMongoDBのプロフェッショナルを雇ったり自分で運用しなくてもよいのですから大変な安上がりだと思います。
続いて、ログイン後トップページから先ほど作成したDBをクリックし、接続に使うユーザを作成していきます。画面右の「Add database user」をクリックし使いたいユーザ名とパスワードを設定します。そして画面中段の接続先情報を作っておきます。「mongodb://<dbuser>:<dbpassword>@ds00000.mlab.com:12345/{dbname}」というやつです。基本コピペして、ユーザ名、パスワードを自分のやつに置き換えれば問題ありません。
mLabでの作業は一旦ここで完了です。続いてはParseダッシュボードにアクセスしてください。対象のプロジェクトにアクセスし、左メニューの「App Settings > General」へいき、画面中段の「App Management」から「Migrate to external database」という項目を探し、「Migrate」というボタンを押します。(新しいダッシュボードからしかこの操作はできないものと思いますのでご注意ください。)
このようなダイアログが出ると思うので、先ほどmLabで作成したDBの情報を入力し、「Begin to migraion」をクリックします。
mongodb://<dbuser>:<dbpassword>@ds00000.mlab.com:12345/{dbname}
という感じのものですね。
この時「We strongly suggest you enable SSL on your database and use the URL option 'ssl=true'.」という警告が出るかもしれませんが「Migrate anyway」を押すと続行されます。気になる方はキャンセルした上でSSLの対応を行ってください。
この作業後自動でデータの移行作業が行われます。Copy SnapshotとSyncが完了すればデータの移行は完了しています。このステータスの状態で再度mLabにアクセスし、今までParseに保存されていたデータが正しくmLabに移行されていることと、Parseと接続されているアプリでデータの登録、削除などを行い、正しくデータが反映されていることを確認してください。データの確認ができましたら「Finalize」をクリックし、移行を完了してください。
一度移行するともう差し戻しできないよ、という警告メッセージがでますが十分に確認したのちに「Okey」を押して完了します。
無事に完了しますとCongratulations!とのメッセージが出ます。お疲れさまでした。
なお、この時点ではアプリで新規に作成されたデータは、Parse内のParse Serverを経由して、先ほど構築したmLabに格納されています。この作業を通じて、DBへの接続先が変更されたということです。
Parse Serverの移行
続いてParse Serverの構築を行います。公式のガイドではHerokuを使うことが推奨されていますが、今回は自前のサーバを使うことにします。もちろんHerokuが使い易い人は使っていただいて問題ありません。私はさくらのVPSとさくらのクラウドで動作確認済みなので、それに準じた環境であればどこでも構いません。
まずParse Serverはnode.js上で稼働しますのでまだnode.jsが入っていないという方は適宜インストールしてください。実行ユーザは任意のもので大丈夫です。なお、必要に応じて最初にnvmのインストールを行います。
# nvmのインストール curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.25.4/install.sh | bash # bash_profileの設定 vi .bash_profile /////////////////////// # nvm設定 -s ~/.nvm/nvm.sh && . ~/.nvm/nvm.sh nvm use default npm_dir=${NVM_PATH}_modules export NODE_PATH=$npm_dir /////////////////////// # バージョンの確認 nvm --version
#設定の反映 source ~/.bash_profile
#(必要ならば)使えるバージョンの一覧 nvm ls-remote #最新版をインストール nvm install 6.2.0 #実行
nvm use v6.2.0 Now using node v6.2.0 (npm v3.8.9) # bash_profileの更新 vi .bash_profile /////////////////////// # nvm設定 -s ~/.nvm/nvm.sh && . ~/.nvm/nvm.sh nvm use v6.2.0 // これに変更 npm_dir=${NVM_PATH}_modules export NODE_PATH=$npm_dir ///////////////////////
Parse Serverの稼働できるバージョンがあったはずなので、node.jsは新しい安定板にしておくことをおすすめします。続いてParse Serverをインストールします。
#インストール npm install -g parse-server #接続先設定
#起動パタメータにこの辺りの情報を含むことはできますが、json形式の設定ファイルにしておくと便利です。各種key情報やpushの情報も含むことができます。 vi config.json { { "appId”:”appid”, "masterKey”:”masterkey”, "clientKey": "masterKey", "restAPIKey": "restAPIKey", "databaseURI":"mongodb://username:password@ds01111.mlab.com:35674/dbname”, "push": { "android": { "senderId":"senderId", "apiKey":"apiKey" }, "ios": { "pfx":"/home/xxxxx/parse/APNS/yourappname.p12", "bundleId":"jp.example”, "production":true } } } #起動方法 parse-server config.json #リモートデータの取得テスト curl -X GET \ -H "X-Parse-Application-Id: yourappid” \ http://localhost:1337/parse/classes/Test/aabbccdd #サーバに外からつなぐ場合はポートの開放が必要 cat /etc/sysconfig/iptables #1337ポートを開けるため、下記を追加。ポート番号は好きに変更してください。 -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1337 -j ACCEPT #再起動 /etc/init.d/iptables restart #CentOS7の場合はiptablesが使えないので下記のようにしポートを解放します firewall-cmd --add-port=1337/tcp --zone=public --permanent success firewall-cmd --reload success #外から(他のサーバやローカルPCから)つなぐ場合 curl -X GET \ -H "X-Parse-Application-Id: appid” \ http://yourhostname.co.jp:1337/parse/classes/Test/aabbccdd
これでParse Serverの構築が完了しました。ここに対して処理を行うことで、最初に構築したDBのデータの操作を行うことが可能になってきます。
SDKの更新
DBとParse Serverの構築が終わりましたのでアプリ側のSDKの更新を行っていきます。手順はこちらに記載されている通りです。
Swiftの場合はこんな感じですね。今までparse.comへ向いていたコネクションを先ほど構築した自前のParse Serverに置き換えます。
let configuration = ParseClientConfiguration { $0.applicationId = "YOUR_APP_ID" $0.clientKey = "" $0.server = "http://localhost:1337/parse" } Parse.initializeWithConfiguration(configuration)
なお、このような記法は最新のSDKにアップデートしないと使えない場合がありますのでその場合は下記より適切なバージョンをDLしアプリに組み込んでからお試しください。
最後に接続先を変更したアプリをApp Storeに申請をあげて完了です。
Parse Dashboardの移行
最後にダッシュボードを移行します。Parseにログインしたあとにデータをみるときに使うあの画面です。早速設定していきましょう。
#parse dashboardのインストール npm install -g parse-dashboard #設定ファイル
#userとpassを設定することでダッシュボードアクセス時にBasic認証を有効にすることができます。 #vi parse-dashboard-config.json { "apps": [ { "serverURL": "http://yourhostname.jp:1337/parse", "appId": “appId”, "masterKey": “masterKey”, "appName": “appName”, "production": true } ], "users": [ { "user”:”user1”, "pass”:”pass1” } ] } #設定がうまくできない場合はparse-dashboard以下のパスに配置する必要があります /home/youruser/.nvm/versions/node/v6.2.0/lib/node_modules/parse-dashboard/Parse-Dashboard/parse-dashboard-config.json #起動 parse-dashboard /home/youruser/.nvm/versions/node/v6.2.0/lib/node_modules/parse-dashboard/Parse-Dashboard/parse-dashboard-config.json --allowInsecureHTTP true & #備考 「—allowInsecureHTTP true」 を引数につけることでhttpでアクセスできるようになります。 #必要に応じて4040ポートを開放 sudo vi /etc/sysconfig/iptables #追加 -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 4040 -j ACCEPT #再起動 /etc/init.d/iptables restart
これでダッシュボードの構築が完了しました。無事にいつもような画面が表示されていれば問題ありません。
最後に
これで一通りの移行作業は完了です。断片的に見ると色々面倒なことが多いのですが、全体像を掴みつつ行うと難易度は下がりますね。とはいえ、サーバサイドのナレッジがないからParseを使っていましたという人からするとなかなか厄介なことに変わりありません。移行ドキュメントも全部英語ですし、そこそこハードルは高いはず。そう考えるとこの移行作業を機にサービスクローズしてしまうアプリもあるんだろうなと思った次第です。必要な方のお役に立てればうれしいです。
なお、現時点で私が気になっていることをこちらに記載しておきます。
1.dev版のAPNS証明書でpushが飛ばない問題
pushを行うと下記のようなエラーが表示され正しく配信が行われません。
>ERR! parse-server-push-adapter APNS cannot find vaild connection for 96f7a07515e4dda535c291b673060e80b1f196c35797e28df352d96bf593632c
本件海外でも話題になっています。
原因は不明ですがなんらかのサーバ環境依存の可能性はあります。Herokuでは問題なく飛んだなど情報がありましたらコメントいただけると困っている人が助かります。なお私の場合、本番の証明書をロードさせたところdev環境でもpush配信を行うことができました。
2.自前のParse Serverを使用したアプリのデータロードが遅い問題
これは致命的な問題かと思います。parse.comのサーバでは特にストレスなくロードされていたデータが、移行後のParse Serverを使ったバージョンでは異常にロードに時間がかかるようになりました。どこに問題があるのかわからなかったので下記検証を行いましたがいずれにせよparse.com使用時は早く、移行後のParse Serverでは遅いということには変わりありませんでした。
-DBのスペックの比較。sandboxとそうでない環境へ接続先を変更しても特に変化なし
-サーバスペックの比較。VPSサーバ、クラウドサーバ(コア数、メモリ数)など5パターンくらいで比較したところ、ハイスペックの方が極めて微妙にロード時間が短縮されたがほぼ影響なし。(下は1GBメモリ、1coreCPU、上は16GBメモリ、4coreCPU)
よって、現時点のオープンソース版のParse Serverに問題があるのではないか？というのが濃厚です。海外でも話題になっているのでこれは定期的にウォッチしておく必要がありそうです。
これだけロードに時間がかかってしまうとユーザビリティに多大な影響を与えてしまうので、Parse Serverのパフォーマンスが向上するまではparse.comサイドのサーバを接続先に使い、どこかのタイミングで切り替えるという運用が正しいのかもしれません。
2017/01/26追記
