当社ではWebサービスの開発と運用をしていることもあり、企業様からWebサービスの構築をご依頼いただくことが多々あります。

Webサービスを運用するうえで、ランニングコストとして必ずかかってくるのがサーバ費用です。
サーバについては、最初にきちんと選んでおかないと、後々に移行しないといけない、いきなりアクセスが増えた時に落ちたりするのではないか。
こういったリスクから、最初に高性能、拡張性の高いサーバを選ぼうとされるご担当者様が多いように思います。
もちろん、企業としてリリースするわけですから、最初に考えられるリスクなどをきっちち見込んで良いサーバを選んでおくのは重要です。

しかし、実際にWebサービスを作って運用していると、必ずしも最初から高いランニングコストで運用していくのは得策ではないのではないかと思います。

例えば、人気のあるAmazonWebService(AWS)なんかは確かに拡張性の面で優れていますし、運用でも安定感があります。しかし、重量課金制なのでユーザー投稿画像を多く扱うようなサービスの場合、大したアクセスもない割には料金が跳ね上がってしまったり、アタックをうけて一時的に費用が跳ね上がってしまったりすることもあります。
運用を始めて、思っていたよりランニングコストがかかってしまった、などというお話も伺います。

実は多くのサービスはレンタルサーバや最近安いVPSサーバなどでも全然大丈夫だったりします。

派手にお金かけて広告を打っているようなサービスとか知名度の高い企業がリリースしたサービスでもない限り、最初の一年から数年は期待したアクセスなどはほとんど見込めないのが現実です。
正直なところ、サーバに最初から冗長化とか拡張性を求められるご担当者が多いのですが、最初にそこにお金をかけないで、その分を広告などのプロモーションに充てたほうが良いのではないかと思うこともあります。

実際に企業のWebサービスの開発に携わってきて、感じたことを書いてみます。

 

企業で運営する場合はサービスを閉鎖してしまう可能性もある

最初から元も子もないようなことを書きますが、サービスを運用してみて短いスパンで閉鎖する、ということはよくあります。

企業は利益を追求する集団なので、趣味やサークルのように利益度外視してサービスの運用を続行することはあまりありません。サービスがヒットしない、利益を生み出さないのにサーバ費用や運用に携わる人の人件費などを捻出し続けることは難しいです。

1年か2年程度で閉鎖してしまうことも十分に考えられます。
ということは最初から高いランニングコストを支払うこともリスクになります。

当社で作ったサービスも1年くらいで閉鎖しているものが多くあります。
作るときの担当者の熱意が熱くても、日常業務と運用を兼ねてやるのは結構な労力です。結果的に思うように成果が出ないこともサービスでは多くあります。

その辺りのことも担当者は冷静に考えて、長期的にランニングコストの検討をすべきだと思うのです。

 

サーバ移行のリスクは大したリスクではない

最初に良いサーバを選ぶ理由として、後々サーバを拡張したりしたい場合に移行しないといけない、というリスクがあります。

動いているサービスを止める、というのは抵抗があります。移行するのにもお金がかかります。
しかし、そんな心配するほど、サーバを乗り換えないといけないようなサービスはあまりみたことないです。

最初に必要以上に高額なランニングコストをかけず、その分は来るべき移行のために積み立てていくような感覚でも良いのではないかと思います。

もちろん広告を沢山打っていたり、知名度のある企業がプレスリリースを出したりするとかなりのアクセスはあるでしょう。サービスの内容次第なので一概にはいえませんが、最初の数年のアクセスはたかが知れています。

期待した以上の効果が出た後でも、拡張性の高いサーバに移行するのは遅くないのではないかと思います。

 

サーバの前に考えておきたいサービス設計

当社もそうなのですが、Webサービスを作る時はまずは表示負荷がかからないような設計をエンジニアを話合ってきちんとすべきだと思います。
Webサービスを作る時はどうしても企画やインターフェイスの見た目を最重要に考えてしまい、エンジニアが渋い顔していても、見た目優先で強引に進めてしまうケースが多いです。
(これは当社もそうなのですが。。)

エンジニアの意見を無視して進めると、最終的にはかなりもっさりしたサービスになってしまったりするので、サーバの性能よりもシステム設計を考えなければなりません。

エンジニアと事前に確認しておかなければならないポイントを挙げてみます。

 

サービスで使用する容量の節約

一番容量を使うのはやっぱり画像です。
特にユーザーに画像投稿させるようなサービスの場合は特に注意が必要です。

プログラムでアップロードされた写真を保存する際に、表示サイズに合わせてある程度画像サイズを変更するなどの処置は必須です。ただ、こういう細かいところも指定しないとエンジニアの方で考慮せず、アップされた画像をそのまま保存していたりします。
(画像サイズを替えたりするのが面倒くさいので、言われなければやらないことが多かったりします。)

表示する時の速度にも画像サイズはかなり影響でますので、初期の段階できちんとエンジニアに相談しながら進めるべきです。

 

扱うデータの効率的な呼び出し

コミュニティーサービスなどの場合、ひとつのユーザーに関連するデータの種類が多いので、ユーザーに関連したデータの呼び出しに時間がかかる場合があります。

会員制であれば会員が少ない時はそうでなかったのが、会員の数が増えるにしたがって、徐々に負荷が大きくなり、表示が重くなったりします。こういう時、サーバを変えれば何とかなるのか、と思いがちですが、そもそもデータ構造が複雑だとサーバ替えたくらいでは大して変わらない場合もあります。

データベースの設計とSQLでの呼び出しが効率よくないと、いくら良いサーバでも結局重くなります。
なので、サービス設計の時点で少なくとも表示負荷のないような設計をしておくということに重点を置いて考えた方が良いでしょう。

インターフェイス設計の際に、一度に表示したい項目などをエンジニアと事前にきちんと相談して、負荷の少ないデータ呼び出しなども考慮のうえ検討したいところです。

 

外部APIやウィジェットなどの使用過多による表示の重さの軽減

Twitterやfacebookなどを使っていると、ウィジェットのレスポンスが遅くて、ページ全体の表示が重くなったりします。
最近ではかならずウィジェットなどを使って外部サービスの情報を読み込もうとする傾向にありますが、本当に有意義なものだけを採用するなど検討した方が良いです。

何でも付けたくなるという気持ちは分かりますが、表示速度が重くなるリスクまで背負って無理してウィジェットを付けなくても良いようなサービスもたくさんあります。

 

====

サーバ選びや事前設計については、人によって考え方も異なりますので、サービスを運用してみないと正直なところ、それが正解であったのかどうかは分かりません。

当社ではこのエントリーで書いたようなことを念頭に、本当にかけるべきコストや実際に運用してみて結局こうだったみたいな経験を元にサービス構築の提案をしております。

参考までに。