ウェブサービスを作る時に気をつけた方が良いこと
これまでいくつかウェブサービスを作って公開しましたが、運用をしてみてこれはヤバいと発覚した事などをまとめてみようと思いました。ひとまず思いついたことを書いておこうと思うので、何か追加すべきことがあれば追記していきます。
外部サービスの契約
サーバの契約
アプリケーションやフェイズによってサーバの必要スペックが変わってきますので最初からモンスターマシンを借りるとコストだけかかってしまいます。載せるアプリケーションや想定されるアクセス数によってレンタルサーバからVPS、クラウドなど検討する必要がありますが、大体のサービスでは即日使える様になりますのでいざ設定するとなればすぐに対応できますね。
メール送信サービスの契約
新規登録時のお知らせやパスワードリマインダー、その他の通知を実装するためにSendGridやAWSのSESを利用すると思います。送信アドレスとして利用したいアドレスの所有者なのかなどを確認する作業が必要となります。
SendGridは登録と認証が必要で少し手間がかかりますが、日本のSendGridだとメッセージでのやり取りがメインになるので3-4営業日は必要で、とっても急いでいる場合は本家のSendGridを使うのが良さそうです。
AWSのSESはデフォルトだとメールの送信件数に制限があります。そのため送信制限解除の申請をAWSコンソールから行う必要があり、即日反映される場合もありますが基本的には2日ほどかかる想定で登録を進めるのが良さそうです
PR
ドメイン
wwwのつけたサブドメインで運用する
CDNサービスを利用すると時にルートドメインを利用できないことがあります。
このサイトでは「 www.no8.jp 」を利用するということです。「 no8.jp 」でCNAMEを利用するとMXレコードが使えなくなるという問題があります。つまりはメールサーバ設定ができなくなってしまうということです。
AWSをインフラとして利用する場合はRoute53を利用すれば独自のエイリアスという機能を利用することでAレコードで設定したような挙動をすることができ設定をすることができます。
ユーザ
ユーザ登録ではreCAPTCHAを導入
ユーザ登録の実装が落ち着いてくるとなぜか登録をしまくってくるスパムがくるようになります。reCAPTCHAなどを使ってブロックしましょう。
視覚障害者向けのブラウザを使っているとreCAPTCHAで弾かれてしまうようです。もしユニバーサルなサイトにする必要があるのであれば導入をおすすめしません。
ただ、コンテンツによっては視覚障害者の方を対象としていない場合は有効なのではと思います。
ユーザIDの予約語問題
twitterのようにユーザページを https://twitter.com/ユーザID/ と言う形式にする場合以下のようなアドレスを取られると困るわけです。
- https://twitter.com/admin/
- https://twitter.com/settings/
- https://twitter.com/users/
- https://twitter.com/common/
- https://twitter.com/assets/
管理画面のアドレスや追加機能で使いたいURLと被ってしまったりして…。 Railsの場合はActiveStorageが使うURLがあったりするわけですが、ライブラリやフレームワークが利用しそうなURLや自分で新しい機能を実装する時に使いそうなURLを予め取得できないようにバリデーションチェックしましょう。使えないようにした方が良いリストも後日作って公開してみようと思います。
他の方法としては http://twitter.com/members/ユーザID/ と言ったアドレスにする事も有効かもしれませんが、その場合も使えるユーザIDには注意した方が良いのは変わらないです。
ユーザIDの大文字小文字の判断
ユーザIDの大文字小文字を別と判断してしまっていると結構わかりにくい設計になってしまいそうです。できれば大文字小文字は別のものと判断せず同じものであると判断した方が良いと思います
ユーザIDに連番のダミーIDをつけない方が良い
ユーザがまだIDをしっかり作っていない時に連番のIDを勝手につけてくれるようにしたことがあります。例えばuser_idが 10だった場合 profile10 などとつけたのです。あるユーザが profile11 と言うIDに自分で変更してしまい次に登録した profile11 で登録されようとしたユーザは被ってしまいエラーになってしまいました。twitterなどのようにランダムな文字列にするか被ったら次の番号を利用するなどの工夫が必要です。
ユーザの退会ができるようにした方が良い
作った時はユーザは使わなくなったらアカウントを放置するかと思っていたのですが思っていたのですが、意外に退会したいと言う声は多いようです。1週間に1-2回は来るのでユーザが自分で退会できるようにするか管理画面から1ボタンで退会できるようにしておいた方が運営が楽そうです。
DBを直接いじって退会させるのも手間なので素直に退会させるフローを用意しましょう。
お問い合わせフォームはあった方が良い
メールフォームを用意した方が良いと思います。twitterからなどでも良いですが致命的な問題をリプライでやりとりするのはよくないと思いますので詳しく説明も報告してもらうためにメールフォームは用意した方が良いかもしれません。
投稿
非公開機能はあった方が良い
ユーザが予期せぬNGワードが入った投稿などをするかもしれません。広告を掲載していたりするとアウトになる可能性があるので隠したいですが、勝手に完全削除してしまうわけにもいかない場合は非表示にできるようにしておいた方が管理画面から投稿を簡単に非公開にできるようにしましょう。
ユーザのアクション数はカウンターキャッシュすると良い
カウンターキャッシュもどこまで設定すれば良いか正直なんとも言えないですが、アクティブなユーザを把握する場合や何かアクションしてくれているユーザのみに新しい機能を表示するなどしたい場合はカウンターキャッシュされている数字を元に表示を変えるとDBへの負担が少なくできるので使う可能性があるカウンターキャッシュは設定しておいた方が良さそうです。
例えば、お気に入り数、投稿数、タグがつけられている数などですね。
PR
最後に
サービスを運営していると設計する時に盛り込んでおくべきことは結構あるのでノウハウとして共有できればと思っています。今後もこちらの投稿を更新していこうと思います。
PR
