#はじめに
Azure App ServiceでPaaSのWebアプリを作成する際に、クラウドのコストを最小限に抑えるためにDBにSQLiteを採用したら後で困ったことになったので、気を付けたほうがいいことを記事にしておきます。
App Service＋SQLiteの組み合わせが絶対にダメというわけではないのですが、採用するにあたって注意が必要な点を記載します。
他にも発見したら更新するかもしれません。
#App ServiceでSQLiteを採用するときの確認事項
##ステージングスロットは使用しないか？
App Serviceにはステージングスロットという便利な環境があります。
運用環境とは異なる環境（ステージングスロット）を用意することができ、Azureのポータル画面からスワップという操作を行うことで、事前にステージングスロットで起動しておいたアプリを運用環境に起動した状態でデプロイすることができます。
それまで運用環境で動いていたアプリはデプロイスロットに移されます。
ダウンタイムが発生せず簡単にアプリをデプロイできる便利な機能ですが、SQLiteを使用しているとSQLiteのDBファイルも運用環境とステージングスロットで置き換わってしまいます。
ステージングスロットはスワップするまではテスト環境として使用するケースが多いと思いますが、スワップによって運用環境のDBがテスト環境のDBに置き換わってしまったら大きな影響を及ぼす恐れがあります。
##Zipファイルでアプリをデプロイすることはないか？
App Serviceにアプリをデプロイする方法として、発行プロファイルを使用してVisual Studioからビルド＆デプロイする方法、WinSCPなどのクライアントからFTPで送信する方法などがありますが、Zipファイルのアップロードによるデプロイも可能となっています。
Zipファイルのアップロードでは、既にデプロイされているファイルは上書きされるため、運用環境のSQLiteの内容が失われてしまいます。
また、Zipデプロイでは前回デプロイと比較して存在しないファイルは自動で削除されるため、SQLiteのファイルを含んでいないZipファイルをデプロイしても運用環境のSQLiteの内容は失われてしまいます。
##DBの性能をスケールアップする可能性はないか？
DBの処理時間がボトルネックになっているとわかり、DBの性能をスケールアップしたくなったとしても、SQLiteを採用しているとDBだけをスケールアップすることはできません。
SQLiteはApp Serviceと同じ環境で動作するため、App Serviceのプランを変更すれば性能が向上するかもしれませんが、どの程度向上するかわかりません。
#おわりに
クラウドサービスの利用自体が初めてで、右も左もわからずにAzureのApp Serviceを利用したときの失敗体験からこの記事を書きました。
お金に余裕があるならAzureのSQLデータベースのサービスを利用するのが確実です。
ただ、無料利用枠でちょっと試したいだけというときにDBのサービスを利用するとお金がかかってしまうため、DBは無料で済ませたいと考える中でSQLiteを思い浮かべる方もいるのではないでしょうか。
SQLiteは手軽に採用できて便利ですが、PaaSのサービスとはあまり相性が良くないみたいので、デメリットを考慮しつつ採用を検討していただけたらと思います。