4. BaaSサーバ運用¶

4.1. SSL証明書の取得は必須でしょうか？¶

必須ではありませんが、通信路が暗号化されないため原則取得することを強くおすすめします。

なお、Proxy サーバで GET/POST 以外のメソッドが遮断されている場合は、HTTPS を使用することが必須となります。

4.2. 自己署名SSL証明書を使用していますが、接続できません¶

ブラウザを使用している場合は、証明書をブラウザにインストールするか、一度 URL をブラウザから入力して安全でない接続を受け入れる処理を行ってください。

クライアント SDK を使用する場合は、アプリケーション側に修正が必要です。以下 SDK については、各 SDK のマニュアルに自己署名証明書を使う場合の注意点などを記載していますので、そちらを参照してください。

JavaScript SDK
Java / Android SDK
iOS SDK

上記以外の SDK については自己署名証明書は使用できません。

4.3. 各サーバ(API/Console/SSE Push/Cloud Functions) は別々のサーバにインストールしなければなりませんか？¶

別々のサーバにインストールすることを推奨しますが、1台のサーバに混載することも可能です。

4.4. Webアプリを配置するサーバは別途用意する必要がありますか？¶

モバイルバックエンド基盤サーバ(APIサーバ)とは別途設置することを推奨します (Apache などを構築し、その上に HTML や JavaScript ファイルを配置)。

4.5. 静止画などのコンテンツはどこに配置すればよいですか？¶

静的リソースの場合は別途 Web サーバ上に配置してください。

BaaS のファイルストレージに格納することも可能です。ただし、HTML の a タグなどから参照したい場合は、ファイルを公開状態にする必要があります。

4.6. バージョンアップはどのように行えばよいですか？¶

バージョンアップの前に、各サーバの「マイグレーションガイド」を参照し、注意事項が無いか確認ください。

APIサーバ/デベロッパーコンソールサーバについては、WAR ファイルを差し替えて Tomcat を再起動するだけでバージョンアップできます。データベースのマイグレーションは自動で実行されます。 (一時的に複数バージョンが混在しても問題ありませんが、混在したまま運用し続けることは避けてください)
SSE Push サーバについても WAR ファイルを差し替えて Tomcat を再起動するだけです。ただし、全サーバを一斉に停止するとクラスタのメモリ上に記録されている端末の情報が消えてしまいますので、順次再起動するようにしてください。
Cloud Functionsサーバについては必要なファイルを差し替えてサービスを再起動してください。なお、再起動時に実行中の Function はキャンセルされます。
Cloud Functions の Java コードについては、そのままでは動作しない場合があります。この場合は、最新版の SDK で再ビルドしてコードを再登録する必要があります。

4.7. APサーバ(Tomcat)が起動しません¶

下記のコマンドで Tomcatの動作状況を確認できます。

# RHEL7系の場合
$ sudo systemctl status tomcat8

Tomcatが起動していなかった場合、下記のコマンドで起動してください。

# RHEL7系の場合
$sudo systemctl start tomcat8

4.8. cloudfn-server-manager サービスの停止後、systemd のログに exit code 143 エラーが出力されてしまう¶

下記コマンドで cloudfn-server-manager を停止した後、systemd のログに exit code 143 エラーが出力されることがあります。

$ sudo systemctl stop cloudfn-server-manager

この場合は、cloudfn-server-manager の Unit ファイルに "SuccessExitStatus=143" を追記してください。記載方法は、リリース物件内にある Unit ファイル(cloudfn-server-manager.service) を参照してください。

なお、exit code 143 は、アプリケーションが SIGTERM シグナルで終了された場合に発生する終了コードです。本終了コードが発生した場合でも、cloudfn-server-manager は正常に停止しています。

4.9. SELinux のEnforcing 動作モードでは、RabbitMQ Serverのサービスが起動しない¶

設定ファイル（/etc/sysconfig/selinux）を開き、「SELINUX=」の設定値を Permissive に変更した後、マシンを再起動すれば、RabbitMQ Server のサービスの起動ができます。

また、以下のコマンドでマシンのSELinux 動作モードを確認できます。

$ getenforce

4.10. 各サーバ（BaaS/SSE Push/Cloud Functions）のミドルウェアとそれらの使用ポート一覧はありますか¶

各サーバのミドルウェア・使用ポートを参照ください。

4.11. 各サーバ（BaaS/SSE Push/Cloud Functions）のアンインストール手順はありますか¶

各サーバの運用停止時の削除手順は用意しておりません。

OSS (Tomcat, MongoDB など) の削除手順は、各 OSS のマニュアルを参照してください。

各サーバのデータ（バイナリ／設定ファイル／ログ／DBデータ）の削除については各サーバのデータとその格納先を参照し、関連データを削除してください。

4.12. リバースプロキシで HTTPS 終端している場合に、コンソールサーバにアクセスできない¶

https から http にリダイレクトされるなどの問題が発生する場合は、Tomcat に設定の追加が必要です。

具体的には Connector 設定に、proxyPort, scheme, secure の3つの属性を指定する必要があります。

詳細は、サーバ利用手順書のロードバランサ/リバースプロキシとHTTP通信の設定を参照してください。

4.13. Tomcat サーバが突然クラッシュする¶

Tomcat サーバがクラッシュするのは、ほとんどの場合メモリが不足しているのが原因です。実メモリが不足すると、OS の OOM Killer により Tomcat のプロセスが殺されてしまう場合があります。特に AWS や NECCI などの VM は、デフォルトで swap 領域が設定されていないため、物理メモリが足りなくなると即プロセスが強制終了となりますのでご注意ください。

Tomcat 起動時のヒープメモリサイズ指定 (-Xmx オプション)を確認ください。実メモリサイズから、カーネル(バッファキャッシュ含む)や他プロセスの稼働に必要なメモリを引いたサイズ以下に設定する必要があります。

また、Docker コンテナ上で動作させる場合は、ホストOSではなくコンテナに割り当てたメモリ容量以下に設定しなければなりません。

4.14. BaaSサーバのバージョンはどこを見れば分かりますか¶

デベロッパーコンソールにログイン後、「管理」⇒「バージョン情報」で確認できます。