アクセスが増えてきたwebサイトを安全に運用するために何をすればいいかを考える話

webサイトにアクセスが増えるという場合、サイト主にとっては嬉しい反面、webサーバーがダウンしてしまっては、元も子もありません。 サイト制作と運用自体を、他の制作会社などにおまかせしている場合は、改善策などを提案してもらえば良いのですが、自分の会社運用をしていて、社内開発部門がある場合、その開発部門で手に負えなくなってくるほど増えた場合、どうすればいいかを、思考してみましょう。 ちなみに、ブログ運営をしている人で、バズってアクセスが爆増してしまった場合などに参考にしてもらえるといいかもしれませんが、かなりエンジニア寄りの話になるので、単純なサイト作成しかしていなくて、フレームワークやCGIなどは、ホスティング会社におまかせしている場合は、プロの制作会社などにお願いすることになるでしょう。

アクセス爆増で起こる問題

ネットでの爆増は、リアル店舗でたくさんのお客が押し寄せてくるレベルではありません。 桁が一つあがるなんてもんじゃなく、2桁3桁当たり前の世界というのが、ネットの世界なんですね。 webサイトを立ち上げる時に、カンパニーページや、個人ブログなど、よほど大きなアクセスを目指していない場合は、サーバーを１つでできるだけ安いホスティングサーバーを使って立ち上げると思います。 B2Cでの課金型webサービスで、毎月数億円単位での売上を見込みたい場合は、始めからアクセス負荷対応を検討したサーバー構成にすると思いますが、多くの場合サーバーは１台からスタートです。 そして、アクセスが増えてくると、まず、サイトアクセススピードが遅くなり、サーバーからいろいろなアラートが出始めます。 サーバー内のアクセスログが増えるだけではなく、システムエラーなどに伴うエラーログも膨大に膨れ上がります。 次に、利用しているユーザーなどから、「繋がらない」というお問い合わせを迷惑電話バリに届くようになり、 最後に、サーバーが落ちるという結末に行き着きます。 残念なことに、アクセス爆発で落ちたサーバーは、立ち上げ直しても、すぐにまたサーバーがダウンして落っこちてしまうという繰り返しになるため、もはや１台サーバーでの運用に見切りつける決定をしなければいけませんね。 もちろん、昔から「冗長構成」という手法で、お硬い会社や、公的なサイトなどは、構成されていることが多いです。 これは、公開webページに関する機器を、全て冗長構成化という、全て２台構成にして、１台がダウンしても、もう一台がリカバリーするという仕組みで、システムを停止しない方法として、ガラケー時代には当たり前になっていましたが、 爆増するwebサイトに関しては、この方法が何の意味のなさないことは、エンジニアならピンとくるでしょう。 だって爆増によって、１台落ちてるんだから、そこにもう一台立ち上げても、同じように落ちる運命ですからね。

対応方法いろいろ

では、こうしたアクセス増加に伴うwebサーバーってどのような構成にするのがいいか、簡易な方法を２つ紹介したいと思います。 １つは、フロント対策と言って、表示されるページをキャッシュ化してしまう、CDNという（Contents-Delivery-Service）コンテンツデリバリーサービスという方法で、お値段は、劇的に高いんですが、ユーザーのアクセスによって、サーバーがダウンするという自体には陥りません。 この方法で十分じゃん！と思った人、浅はかですよ。 webサイトが動的にコンテンツ内容が変わってしまうような場合は、そんなにストレートに導入できるわけではありません。 ということで、もう一つの方法は、下半身対策とも言われることが多い、データベース・レプリケーションという手段です。 多くの場合、webサーバーというよりも、データベースにアクセス集中して、サービスダウンするケースが圧倒的に多いため、データベース・サーバーをしっかりとさせるだけで、安定運用できます。 でも、このデータベース・レプリケーションって、まあまあスキルのいる仕組みなので、できれば、サービス運用のはじめの段階で設計して、サーバー増強のタイミングですんなり移行できるようにしておくことをオススメしたいですが、そんなにうまくいかないのが、世の常ですよね。 もちろん、上記の２つ以外でも、内部プログラミングの無駄を無くして、できるだけCPU負荷を無くすというような対策はできるかと思いますが、圧倒的なアクセス爆増において、この対策はよほど負荷の高い処理を外せることが出来ない限りほぼ影響力の低い方法であることも合わせて認識しておきましょう。

コストメリットを出したい場合の策

多くのエンジニアが、webページを作るには、wordpress、PHPでサービス構築をしたければ、Laravel、流行りのポーリング系フレームワークを使いたければ、ReactやらVueなどのjs系フレームワーク、老舗のRubyOnRails、などなど、メジャー系のホームページ作りでエンジニアのモチベーションが上がる仕組みを採用しがちですが、 そうした既存の仕組みに左右されない、柔軟な設計を構築できる視点が非常に重要です。 要するに、webから送られえてきたパケットをプログラムでさばいて、適切に表示する。 必要なデータは、溜め込んで、バックアップから、レプリケーション化できる仕組み・・・ みたいな事を、自信の責任においてさばくことができるフルスタックエンジニアがいれば、こうしたアクセス爆増であたふたしなくても済むシステム作りができる安定運用が安心できる環境ができあがるでしょうね。 残念なのは、アクセス対策法を、ネットで検索した結果だけで仕組み化してしまっている事なのかもしれませんね。 効果が出なかった時に、何が悪かったのか原因究明にさらなる膨大な時間を費やしてしまうことも明確ですからね。 こうした事が考えられるエンジニアって、最近では、フリーランスになって、高給取りライフを送っていくようなので、企業が抱え込むのも難しいようですよ。 そして、そうしたエンジニアって、ライブラリばかり使っているエンジニアとは、指向性が違うので、コンフリクトが起きがちなんですって。 え？弓削田の事？ははは・・・そうかもね。