ENGLISH
バックエンドの選定。開発言語/WEBサーバー/Database
開発言語の選定
当チームのメンバー収益化を目指したWEBアプリは開発の経験が無い。ただし、企業内に閉じたシステムとして、WEBアプリを開発した経験はある。その際の開発言語は JAVA であった。
また、バッチ処理ではあるが python でのコーディング実績もあった。
これを踏まえて、今回のプロジェクトの言語は何にするか?以下の選択肢を検討
- JAVA
- HTML + JavaScript
- HTML + JavaScript + python
開発言語の選定に関しては、アプリ開発者を確保できるかどうかが最大の制約条件になる。
今回の候補に上げた JABA Javascript python (ほかにも PHP など) といった言語であれば、アプリ開発者を探すのにそれほど苦労はしないのではないか?
「アプリ開発者の確保」という観点では差異がないので、インフラ側の好みで選定させてもらった。
当然インフラ担当としては、リリースの作業が楽でマシンの負荷が小さいものを選択することになる。
JAVA について:
インフラ担当から見ると JAVA は評判が悪い(あくまで個人的な感想です)
- リリースが面倒。コンパイル/WARを作る/サーバーに上げる/デプロイする
- WARのサイズが大きい。企業内システムで LAN 経由であればまだ良いが今回はクラウド想定だったので転送するファイルのサイズも気になった
- デプロイの際にシステムが停止するのでリリースのタイミングに気を使う
- 開発サーバーについてはコミットされたら自動でコンパイルしてデプロイする仕組みにしたかったが、JAVA で実装するには専用のミドルウェアの導入が必要
- Tomcat が重い。再起動する度にアプリが配備されるのに時間がかかる
バックエンドを含めてJavaScriptのみで開発するということは、必然的に nodeserver で実行することになる。
nodeserver については今まで経験がなかったので、実験的に試してみた上で判断した。設定については、こちらが大いに参考になった。Nodeビギナーズブック
この方法の場合 JavaScriptをリリースする度に index.js に コールする function を加える必要が生じるので(JAVA に比べれば問題ないが)多少面倒。
また、リリースしたら nodeserver を再起動する必要があるのも運用上気を使う。少なくともシステムのメインとして使用するには使い勝手が悪いと感じた(あくまで個人の感想です)
HTML + JavaScript + python:
結局、最もオーソドックスなこの形が最もシンプルで良いというのが結論だった。
コンパイルは不要だし、デプロイと言ってもソースファイルをコピーするだけで手間いらず。再起動も不要でリリースのタイミングも(ほどんど)気にしなくて良い。
将来、アプリ担当から PHP Perl Ruby の要望が出ても、インフラ目線で言えば python 同様 cgi で実行するだけなので問題ない。
蛇足
Go 言語につても試してみた。コンパイル言語なので、JAVA と同様の面倒くささがある。世間で騒いでいるほど使いやすい言語には感じなかった。(あくまでも個人の感想です)アプリ担当から Go言語対応の要望が出た場合は「何故それが必要なのか?」確認し、「カッコいいから」といった理由だったら却下するつもり。
WEBサーバーの選択
WEBサーバーとして何を利用するのか、選択肢としては以下の候補を検討
- Firebase Hosting + Firebase Functions
- Compute Engine に apache または nginx で構築
- Compute Engine に tomcat で構築
- Compute Engine に nodeserver で構築
Firebase Hosting について:
いろいろ試してみたが、Firebase の Hosting と Functions はどちらか片方では使用せずにペアで選択したときに真価を発揮できるのではないか?と感じたので、セットで考えた。
結論としてはセキュリティのコントロールが難しいと感じた(あくまでも感想です)ので採用しなかった。
- Firebase の Hosting では /__/firebase/init.js で apikey が公開されてしまう。
- apikey の保護がHTTPリファラーだけでは心配。
- Cloud Functions ではユーザー毎に使える機能を制限するなどの制御が難しそう。
- 開発と本番の分離や環境変数によるコントロールなどが難しそうに感じた
nginx の方が新しくて高速かつ高負荷に強いという評判だったので nginx で決定。
tomcat について:
(他案件で)JAVA システムを tomcat で運用しているので app サーバーの候補は tomcat にした。アプリの開発言語に JAVA を使わない方針に決めたので、わざわざ tomcat を使う意味が無くなった。
nodeserver:
バックエンドで javascript を実行できるメリットはあるが、プログラムの本数が多くなると管理が面倒。( javascript が増えたら index.js に登録する運用にしている)
バックエンドの処理で javascript を使用する必要がある場合、例外的に nodeserver を使用している。
データベースの選定
ビジネスソフトをターゲットにしているので、バックエンドにデータベースは必須。今回の使用目的はwebアプリの新規の開発なので、アプリ再度に特別な要件は無いので、インフラ担当の好みで選んで良い。
以下の選択肢で検討をした。
- サーバーにDBMSをインストール(Oracle / PostgreSQL / MySQL / SQLite … )
- Cloud SQL( 公式ドキュメント/Google Cloud データベース 参照)
- Firebase Firestore または Firebase Realtime Database
過去のプロジェクトでは ORACLE を使用しており、構築~運用の経験があった。皆さんのシステムと同様、定期的なバックアップ、テーブルスペースやテンポラリ表領域の枯渇、REDOログが取れていないなど頻発するトラブルの対応で大変だった。
その経験を踏まえ、自前で DBMS を持ちたくなかった。アプリケーション側に特別な要件が無い限りクラウドのサービスを使用すべきと判断した。
Cloud SQL について:
Google Cloud では MySQL、PostgreSQL、SQL Server などの SQL DBMS も使用できる。今回は以下の理由から採用は見合わせた
- 固有のインスタンスを作成する必要があるなど、設定が多少面倒
- 場合によって、インスタンスの起動や停止などの運用が発生する
- 管理すべきインスタンスが増えるので、モニタリングも必要になる
- 自動運用可能ではるが、バックアップについても気にする必要がある
Firestora と Realtime Database:
今回のプロジェクトでは、極限まで運用負荷を軽減したかったので、面倒な設定が無く、ドキュメントが充実していて、メンテナンスフリーで、将来のスケールアップ対応の心配が無いという理由で、Firebase を採用することに決定した。
Firebase には、Realtime Database と Firestore の2種類のDBがあるが、今回ターゲットにしているシステムは一般的な web システムなので、Firestore を選択 ( 公式ドキュメント/データベースを選択: Cloud Firestore または Realtime Database 参照)
アプリ担当者は慣れ親しんだSQLでコーディングができないので、多少面倒だったかもしれない。ただ、ドキュメントが充実しているのですぐに慣れたようだ。
ユーザー認証基盤
すでに、データベースで Firebase を使用するという決定をしているので、検討するまでもなくユーザー認証は Firebase Authentication で決まり。
逆に Firebase Authentication 以外のユーザーアカウント管理のサービスを知らないので、他の選択肢は無かった。
Firebase Authentication について:
Firebase Authentication は新規アカウント作成時のメールでのコンファーム機能や初期パスワード設定画面への誘導、パスワード失念時の再設定の機能、Google や facebook アカウントとの連携など、必要な機能は全て備えているので大変助かった。
もし、自前でアカウント管理の仕組みを構築しなければならなかったとしたら膨大な体力を浪費したことだろう。
これは絶対にお勧めです。