はじめに

この記事は、無料のウェブサービスを公開しようと思っている方に向けた、先輩運営者からのアドバイス記事です(偉そうですんません)。
学生時代に作ったウェブサービスを、社会人になってからも複数運営し続けている私が、自分の後悔や反省を基に、長く安定して運営していくための参考になりそうなことをお伝えします。

前提と対象読者

下記をすべて満たす方を対象とします。

儲からないウェブサービスをできるだけ低コストで運営し続けたい
個人または法人格のない小規模クループで運営を行う
これから開発に着手する

ドメイン

TLDは自ら所有せねばならない

世の中には、無償でサブドメイン(任意文字列.●●サーバ.jpなど)を貸してくれるホスティング業者やドメイン業者が多数存在しますが、それに依存することは非常に危険です。これは大変ありがたく、我々お金にならないサービスの運営者の強い味方であるとも言えます。しかし、ほんのちょっと立ち止まって見てください。誰かに借りるということは、その貸主に依存するということです。

インターネットの歴史はまだ短いですが、これまでに数多くのホスティング業者が消滅してきました。検索大手のY社、サーバ専業の会社、ISPなど、規模も業種も関係なく、数えきれないほどたくさんの会社が、サービスを終了させてきた歴史があります。

そんな時、ドメインだけでも自分で所有していれば、サーバの引っ越しはどうにかなります。ドメインが自分のものではない場合、元のサイトとの同一性を証明することが非常に困難になるとともに、検索エンジンやメールの送受信先と築いてきた信頼関係まで一瞬にして失うことになります。一定期間リダイレクトをすればよい…。なんて考えてはなりません。何の予告もなくサーバが停止するなんてこと、決して珍しくはありません。私は２社経験しました。

そして、時間的余裕があったとしても、ドメインの変更というのはかなりの労力を要します。SNSアカウントや連携ログインをはじめとする各種外部接続、アクセス解析やGitHubなどの管理系ツール、メール関連や自身のプロフィールを書いた様々な媒体に至るまで、変更対象をリストアップするだけで憂鬱になってしまうことでしょう。

年間2000円前後でドメインを買うという選択は、もったいない気持ちがしてくるかもしれませんが、ここだけはお金で解決することを強く推奨します。お金をかけない解決策をご存じの方がいれば、コメントをお待ちしています。

TLDは注意して選ばねばならない

TLDには、それぞれ意味や歴史があります。国を表す.jpのようなCCTLD、.comや.orgなど、実質的に世界中で使われているもの、.bizや.infoのような昔からある特定用途…といえるか微妙なもの、.newや.tokyoのような新しいものなど、どんどん増え続けています。

基本的には作るサイトの内容と語呂合わせや覚えやすさ、使いたい文字列の空き状況で選べばよいのですが、下記のようなドメインは避けることを推奨します。

昔からあるがあまり使われていないドメイン(bizやinfoなど)
治安が良くない国や、日本との外交関係が良くない国に関係のあるドメイン
他者の商標・サービス名や、それと類似するドメイン

これらのドメインを避けていただきたい理由は、「システム的にブロックされる場合がある」ためです。最初の二つは、当該ドメインのウェブサイトを閲覧したり、当該ドメインとメールを送受信することは少ないにもかかわらず、迷惑メールやフィッシングサイトにはよく使われるドメインということで、企業や組織において一律にブロックされてしまうことがあるようです。三つめは、権利者からの申し立てによるドメインの停止リスクがあります。

ということで、ドメイン選びの際には、これらを避けて選んでいただくことを推奨します。

開発・公開環境の選定と構築

長く安定して公開できる環境で開発を始める

開発を始めるにあたり、「使おうとしている環境(言語・フレームワーク・連携サービス・ホスティング業者など)の5年前」を調べてみてください。例えば、PHPであれば当時は7.2とかでした。GAは3でした。そして、そこから今までの更新の履歴を追いながら、破壊的変更がどの程度の頻度で行われているかを調査してみてください。

活動していれば、運営サービスはどんどん増えていきます。5～10年に一度はまとめてバージョンアップ対応を迫られるのは避けようがないのですが、その際の自分の負担をできるだけ減らしてくれそうな言語やフレームワーク、長く稼働し、放置プレイを許してくれそうなサーバを選ぶことが重要です。

今流行っているからと選んだものの、10年後にはメンテナンスされていなかった…。という事態を完全に避けることは不可能ですが、その可能性が低そうな環境を選ぶことは、未来の自分を助けてくれます。特に、フロントエンド技術はまだ歴史が浅く、技術の移り変わりが激しいので、ご注意ください。

当然、その言語・環境で作った成果物を無償で公開できるホスティングサービスが多数存在するというのは最低要件です。サーバ側言語やコンテナ技術の選択はホスティング業者の選定に直結します。選択肢が少なすぎないことを確認したうえで選択するようにしてください。

SSHできるホストで公開しなければならない

FTPログインはできてもSSHログインはできないというサーバを目にすることがあります。これ、セキュリティ的にはほぼ意味がない(PHPなどの言語を通じてexecすればよいため)にも関わらず、メンテナンス性を大きく低下させます。DBのダンプを取得する、各ファイルのパーミッション設定とメールデータを含めたサーバのバックアップを取得する、gitHubでmasterマージしたら自動でデプロイする、アプリケーションログを定期的に掃除する、一時的に固定のメンテナンスページに切り替える………。どれもsshが必須ではなく、確かに代替策はあるのですが、コマンドを組み立てるなどして開発・デバッグをする際を中心に、sshできると作業効率が格段に上がります。

メールの発信方法を検討し、早めに準備せねばならない

今日、メールを「送る」ことは簡単でも、宛先に「届ける」ことは簡単ではありません。フィッシングに代表される迷惑メールが無数に送信されている情勢のため、世界中のメールプロバイダがあらゆる方法で不正なメールをブロックしようとしています。

ウェブサービスを運営していくにあたり、会員登録やお知らせの送付、問い合わせ対応など、何らかのシーンでメールの活用を考えているのであれば、相手にメールを「届ける」ことは一つの重要なテーマとなります。
メールを届けるにあたり、小規模なウェブサービスがドメインの信頼を高めていくことは容易ではありませんので、せめて「マイナスを食らわない」ことが重要になります。

メールの送信元として、最初に思い浮かぶのはホスティングサービスでしょう。多くのホスティングサービスが、メールサービスを提供してくれています。しかし、無料のホスティングサービスのサーバでは多くの利用者とIPアドレスを共有し、無審査で簡単にアカウント開設ができることが一般的なため、サーバのIPアドレス自体が各所のブラックリストに入ってしまっている、もしくは今後入ってしまうことが多いことに注意を要します。また、DKIMなどのセキュリティ技術に対応していないサーバが多いのが現状です。

次に考えられるのは、Gmailに代表されるフリーメールの活用です。送信通数が多くないのであれば、候補としてなしではないです。ただし、独自ドメインが使えないため利用者に不信感を与えてしまう点がネックと言えるでしょう。

もし、団体での運営であれば、法人向けソリューションの提供者に連絡するという手もあります。ダメ元にはなりますが、審査を通過できる場合もあるようです。手間はかかるうえに確実性がないのが難点ですが、もし利用できれば、小規模サービスにとって最強の送信元であることは間違いありません。

小規模であれることを活かして、従量課金の送信サービス（例えばAWSのSESなど)を使うという手もあります。うまく使えば、課金額の下限(0.01ドルなど)以下で利用できることもあるようです。ただし、ウェブ上の操作(例えば新規登録フォームにて多数のアドレスを記入して送信し続ける)によって課金額が大きくなってしまわぬよう、対策を念入りに行うとともに、サービス提供元でのリミッターの設定も必ず行ってください。

また、外部ツールの利用にあたっては、申し込みや審査に日数がかかるサービスも多いため、日数に余裕を持った計画が必要です。もし任意団体での利用を考えている場合には、数週間かかりますが、国税庁に法人番号(こういう名前ですが法人格がなくても取得可能です)の申請をしておくと、「団体の存在と住所」が書かれた通知書(あくまで証明書ではない)が貰えます。これが審査で使える場合もあるようなので、参考にしてください。

ここについては筆者も何を勧めればよいのか、迷っている状況です。もしよい方法をご存じの方がいましたら、コメントいただけると嬉しいです。

運営

RFC2142対応したメールアドレスの設定をせねばならない

インターネットの技術標準を定めるRFCには、2142において下記のような記述があります。

「インターネット上で電子メールの交換を行う組織は"少なくとも"組織内に存在する各機能に関しては対応するメールボックスを利用できるようにすることがとても望ましい」(JPNICの参考日本語訳より引用)

そのため、自身のドメインでメールを運用するのであれば、infoやpostmaster、webmasterなどこのRFCで指定されている各メールボックスを設置することを忘れないようにしましょう。RFCの推奨は、「MUSTにしたいが歴史的経緯でできない」場合が多く、事実上MUSTだと思っていただきたいのです。あなたのドメインのabuse@にメールが来ないことを祈っています。

なお、それなりの数になるため、実際にボックスを設置するのは1つだけにして、その他のアドレスはエイリアスにしておくと、運用の手間やメールの見落としを減らすことができます。自身のメーラーに当該アドレスを設定することも忘れないようにしてください。

死活監視とバックアップは必ず行わねばならない

無料のホスティングサービスには、急なメンテナンスやサービス終了がどうしても付きまといます。そこで、運用開始の時点でそれらに対策しておくことはMUSTであると言ってよいでしょう。

まず、無償で利用できる死活監視サービスは複数あるので、状況把握のためにどこかで設定しておくべきです。忘れたころに通知が鳴って、青ざめるなんて日が来ないことを祈っています。

サーバがいつ飛んでもよいように、定期的なバックアップを設定することも重要です。Google DriveやDropoxなどの外部ストレージへ、定期的にバックアップを行うとよいでしょう。サーバのファイル、メールに加えて、DBのダンプを忘れずに取得することが重要です。

なお、cronを使えるホスティングサービスは少ないようです。この点で困った場合には、IFTTTなどの外部ツールから特定のエンドポイントを定期的にたたく(ウェブフック)ことでcronの代わりにする方法があります。ベーシック認証や、カスタムのAuthorizationヘッダなどを入れて、勝手にたたかれないように対策をすれば、十分にCronの代わりを務めてくれます。ただし、多くのレンタルサーバではスクリプトの実行時間に限度があります。この点だけには十分に注意してください。

開発時の考慮点

ログの取得とローテーション

何らかのエラーに備えて、ログの取得は必ず行いたいものです。通常、どんな環境(言語・フレームワーク・サーバなど)を利用したとしても、初期設定でいい感じにログを取得・保存してくれるものですが、コストをかけずにサービスを運営する場合には注意が必要な点があります。

コンテナ型の場合は容量に注意してください。使える容量が少ないサービスが多いため、コンテナ内のログが肥大化して空き容量を圧迫してしまう事例があります。

それ以外のレンタルサーバの場合、必ずカスタムでログの保存先を変更してください。サーバ標準のログは全利用者で共有となっており、一般利用者では取得できないことが多いです。その際、併せてローテーションも考慮しないと容量があふれてしまうのは、コンテナ型のサーバと共通です。

ファイルの公開には外部サービスを活用する

サーバの容量や通信量の制限・課金に対策するため、ダウンロードコンテンツは可能な限り外のサーバに任せたいものです。この時、動画ならYoutubeなどの共有サービス、それ以外の場合はGitHubの利用がおすすめです。

GitHubについては意外と知られていないようですが、「趣旨が逸脱していなければ、コンテンツへの直リンクOK」という規定になっています。公式に直リンクの説明ページも存在します。フリーソフトやツール類の配布には、とても便利なストレージサービスなのです。

おわりに

儲からないけれど、あると便利なウェブサービスはたくさんあることと思います。学生を中心に、儲からないサービスを開発している人もたくさんいることでしょう。しかし、儲からないものの運営ノウハウの共有は、なかなか進んでいないように思い、この記事を書きました。ノウハウの共有が進み、作ったものを低コストで維持し続けられるようになれば、ニッチな名ツールがたくさん生まれるのではないかと思います。

この記事が、何かのツールを長持ちさせるお役に立てば幸いです。記事で取り上げていない考慮点についても、ぜひコメント欄にお寄せください。みんなで無料の和を広げていきましょう！