ENGLISH

バックエンドの選定。開発言語/WEBサーバー/Database

開発言語の選定

当チームのメンバー収益化を目指したWEBアプリは開発の経験が無い。
ただし、企業内に閉じたシステムとして、WEBアプリを開発した経験はある。その際の開発言語は JAVA であった。
また、バッチ処理ではあるが python でのコーディング実績もあった。
これを踏まえて、今回のプロジェクトの言語は何にするか?以下の選択肢を検討

  1. JAVA
  2. HTML + JavaScript
  3. HTML + JavaScript + python
結論としては、HTML + Jscript + python の組み合わせにした

開発言語の選定に関しては、アプリ開発者を確保できるかどうかが最大の制約条件になる。
今回の候補に上げた JABA Javascript python (ほかにも PHP など) といった言語であれば、アプリ開発者を探すのにそれほど苦労はしないのではないか?
「アプリ開発者の確保」という観点では差異がないので、インフラ側の好みで選定させてもらった。
当然インフラ担当としては、リリースの作業が楽でマシンの負荷が小さいものを選択することになる。

JAVA について:
インフラ担当から見ると JAVA は評判が悪い(あくまで個人的な感想です)

JavaScript のみ:
バックエンドを含めてJavaScriptのみで開発するということは、必然的に nodeserver で実行することになる。
nodeserver については今まで経験がなかったので、実験的に試してみた上で判断した。設定については、こちらが大いに参考になった。Nodeビギナーズブック
この方法の場合 JavaScriptをリリースする度に index.js に コールする function を加える必要が生じるので(JAVA に比べれば問題ないが)多少面倒。
また、リリースしたら nodeserver を再起動する必要があるのも運用上気を使う。少なくともシステムのメインとして使用するには使い勝手が悪いと感じた(あくまで個人の感想です)

HTML + JavaScript + python:
結局、最もオーソドックスなこの形が最もシンプルで良いというのが結論だった。
コンパイルは不要だし、デプロイと言ってもソースファイルをコピーするだけで手間いらず。再起動も不要でリリースのタイミングも(ほどんど)気にしなくて良い。
将来、アプリ担当から PHP Perl Ruby の要望が出ても、インフラ目線で言えば python 同様 cgi で実行するだけなので問題ない。

蛇足

Go 言語につても試してみた。コンパイル言語なので、JAVA と同様の面倒くささがある。世間で騒いでいるほど使いやすい言語には感じなかった。(あくまでも個人の感想です)
アプリ担当から Go言語対応の要望が出た場合は「何故それが必要なのか?」確認し、「カッコいいから」といった理由だったら却下するつもり。

WEBサーバーの選択


WEBサーバーとして何を利用するのか、選択肢としては以下の候補を検討

  1. Firebase Hosting + Firebase Functions
  2. Compute Engine に apache または nginx で構築
  3. Compute Engine に tomcat で構築
  4. Compute Engine に nodeserver で構築
結論としては、Compute Engine + nginx の組み合わせにした

Firebase Hosting について:
いろいろ試してみたが、Firebase の Hosting と Functions はどちらか片方では使用せずにペアで選択したときに真価を発揮できるのではないか?と感じたので、セットで考えた。
結論としてはセキュリティのコントロールが難しいと感じた(あくまでも感想です)ので採用しなかった。
apache 対 nginx:
nginx の方が新しくて高速かつ高負荷に強いという評判だったので nginx で決定。

tomcat について:
(他案件で)JAVA システムを tomcat で運用しているので app サーバーの候補は tomcat にした。アプリの開発言語に JAVA を使わない方針に決めたので、わざわざ tomcat を使う意味が無くなった。

nodeserver:
バックエンドで javascript を実行できるメリットはあるが、プログラムの本数が多くなると管理が面倒。( javascript が増えたら index.js に登録する運用にしている)
バックエンドの処理で javascript を使用する必要がある場合、例外的に nodeserver を使用している。

データベースの選定

ビジネスソフトをターゲットにしているので、バックエンドにデータベースは必須。
今回の使用目的はwebアプリの新規の開発なので、アプリ再度に特別な要件は無いので、インフラ担当の好みで選んで良い。
以下の選択肢で検討をした。

  1. サーバーにDBMSをインストール(Oracle / PostgreSQL / MySQL / SQLite … )
  2. Cloud SQL( 公式ドキュメント/Google Cloud データベース 参照)
  3. Firebase Firestore または Firebase Realtime Database
DBMSをインストール:
過去のプロジェクトでは ORACLE を使用しており、構築~運用の経験があった。皆さんのシステムと同様、定期的なバックアップ、テーブルスペースやテンポラリ表領域の枯渇、REDOログが取れていないなど頻発するトラブルの対応で大変だった。
その経験を踏まえ、自前で DBMS を持ちたくなかった。アプリケーション側に特別な要件が無い限りクラウドのサービスを使用すべきと判断した。

Cloud SQL について:
Google Cloud では MySQL、PostgreSQL、SQL Server などの SQL DBMS も使用できる。今回は以下の理由から採用は見合わせた Cloud SQL は多少は運用の負荷がかかると感じた。逆に言うと細かい部分まで自分でコントロールできるということなので、そのような運用要件がある場合にはピッタリかも知れない。

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 アカウントとの連携など、必要な機能は全て備えているので大変助かった。
もし、自前でアカウント管理の仕組みを構築しなければならなかったとしたら膨大な体力を浪費したことだろう。
これは絶対にお勧めです。
次の記事:コーディング環境/テスト環境/本番環境の分離