諸事情でParseServerを構築する必要にせまられた際のメモ。ParseServerが立ち上げ当初の混乱から時間が経過し当初よりモダン化しており、モダン化に伴いこちらの知識もアップデートする必要があった。ParseServerの構築は2017年ごろにBitnami が提供するParseServerを使ったのが最後で、一から構築サーバーを一から構築することになった。
作業を列挙すると、
- データベースの修復
- セキュア接続の確保
- Blobデータ格納先の修復
- CloudCodeの復元
- プッシュ通知の復元
- 外部との接続
となる。
今回は、1および2について。
1) データベースの修復
構築に取り組んだ当初、困った点としてはMongoDBのdumpの復元に失敗するというもの)ParseServerは原初のサービスであるParse.com のころからMongoDBをデータ保持に用いている)、2017年に作成したdumpがリストアに失敗する、具体的にはリストア直前は動作しているように見えるが、MongoDBの再起動やサーバーの再起動後にデータベースの多揚に失敗するというもの。
こちらの問題で1週間ほど作業が止まってしまう。原因を探すためにBitnamiが提供するエラー確認コマンドを呼び出すもMongoDBを使用するParseサーバーが終了した旨の内容しか読み取ることができない。
原因を解く糸口としては、ParseServerのLogに格納されていた。ParseServer内のフォルダに含まれるLogを確認するとindexingに失敗している旨のエラーが出力されていた。
indexingとMongoDBのキーワードで英文のWebを探っていくと、あった。ここ数年でMongoDBのバージョン間で使用変更があったらしくdumpに残っているindexing情報は過去の遺産でありdumpをrestoreするタイイングで破棄ないし変換する必要があるとのこと。
Webで見つけた解決方法をもとに、dumpをリストアする方法を、a)indexingをリストア中に変換、とb)indexingをリストア中に破棄を試してみた。結果としてはbが正解でindexing を吐きすることでリストア直後は動くがしばらくすると動かなくなるといった切り分け不明な問題は対応できた。
sudo mongorestore -h 127.0.0.1:27017 -u DBユーザー名 -p パスワード --db bitnami_parse --drop --noIndexRestore /home/bitnami/dump/bitnami_parse2) セキュア接続の確保
サーバーを配置しているのがAWSで、証明書もAWS Certificate Manager(ACM)で発行したものを使用するが、ドメイン名は他レンタルサービス(さくらインターネット)経由なので、ドメイン所有権の確認に一手間ある。さくらインターネットはAWSから発行されるCNAME(TXT属性)を管理画面で入力できない問題(2020年7月現在)があるので、管理者へのメール送信しか選べないのが多少もどかしい。とはいえ、このあたりの手続きは継続して実施しているのでそこまで困るという事はなかった。
ACMで発行した証明書をAWS ECのLoad Balancerに渡してセキュア通信を確保し、Load BalancerとEC間ではhttp通信でやり取りする(SSLターミネーション)持っていくのだがここでトラブルが発生。Load Balancerで外部にオープンする通信をhttpsではなくsslにしてしまったためサーバーの接続を確認できない間抜けをしでかす。Load Balancerの設定で、外部に開ける接続を正しい設定(ssl->https)修正することで問題が解決した。
MongoDBの採用例が2010年前半の花盛りし頃からひと段落し日本語リソースが少ないのがこころもとない。その中でもBitnamiのParseServerのやり取りは問題解決の手助けとなった。
MongoDBの近況というとNoSQLの筆頭だったサービスではあるが内部的にはリレーショナルデータベースの構造をなし速度高以上をはかっているというが2010年前半のアピールはなんだったのかという話である。Parse.comはMongoDBの機能をほぼ使っていたのでMongoDBの性能がParse.com の寿命を決めたといっても過言ではないのではないか。
