WEBサービスの規模を小規模・中規模・大規模と考えてみる

この記事が良ければ、ぜひシェアお願いします

先日、WordPressでのサイト構築の限界が、自分の中で見えてきた・・・ という記事を書きましたが、その中でWordPressでは中規模のサイトであれば作れるという風に述べました。

時折、WEBデザイン出身の方がWordPressで大規模サービスも構築できると書いていたりもしますが、WEBサービスで数百億単位で売上を上げるサービスのIT責任者も務めたこともある私からしたら、WordPressで大規模までやろうとするのはかなり無理があると感じていました。では、Info Architectureが言うその小規模・中規模・大規模とは何なのか、私見を述べておきたいと思います。

ちなみにWordPressは個人・少人数・用途によっては、超有用なパッケージだと考えていますので、これからも使い続けていくつもりですのであしからず(笑)ちなみに、この記事にもインスピレーションを受け、よりWordPressのようなパッケージの重要性を改めて認識しました。

参考元 : どうやったら開発のコストを少なくできるか? 答え:コードを書かない

WEBサービスの規模を小規模・中規模・大規模と考える

それぞれ、小規模・中規模・大規模を大きく分類して考えたいと思います。ちなみに、私がここで分類する規模はPVやUU数での規模ではなく、WEBサービス自体の機能性や複雑性、継続性を考慮して書きたいと思います。また、WordPress利用者を意識して書いてみたいと思います。

小規模WEBサービス

  • ブログ
  • ポートフォーリオサイト
  • 中小企業ホームページ
  • 特定カテゴリのECサイト
  • 数百人規模の会員制サイト
  • 特定カテゴリのメディアサイト など

中規模WEBサービス

  • 大企業ホームページ
  • 1万以上の商品を扱うECサイト
  • 1万人以上の会員を想定したSNSサイト
  • 数十万PV/月のアクセスがあるWEBサイト
  • 複数カテゴリのメディアサイト
  • 数千人規模のメール配信サービスを備えるサイト
  • 会員機能・入稿機能・複数条件指定で検索機能など備える広告サイト

大規模WEBサービス

  • 大量の個人情報を含む会員機能の利用を前提としたサイト
  • フロント画面・管理画面だけでなく入稿画面・別画面を備えたサイト
  • 数百万PV/月以上のWEBサイト(WEB/AP/DBなどでチューニングが必要)
  • 独自技術/先端技術をベースに重たい処理を短時間で実行するサイト
  • 数十万規模以上のメール大量配信を備えるサイト
  • Yahoo!などのような様々な機能を実装し、様々なサービスを提供しているサイト

ちょっとざっくりしてしまいましたが、このような感じで分けて私は考えています。特にプログラミング言語やサービスデーモン、フレームワークでは分けていません。

さらにサーバ性能やネットワーク速度、OSやストレージ/NASの選定とモニタリング、WEBアプリケーション/APアプリケーション/RDBMSのチューニングや投げるSQLの最適化、大量ログの処理など、大規模サイトだとやることがてんこ盛りです。

それ以外にも、負荷分散の方法やセッション管理の仕方、認証方式の決定やインスタンスの配置など、やることが結構あります。

ネットワークエンジニア時代から大規模をメインに見てきたので、個人でWordPressを使っていると新鮮でならないのですが、Javaを使ったサイトだとインフラ運用にもそれなりのお作法があったりとして、この辺は経験がものをいう世界なんだなぁと実感していました。

(おまけ)大規模サイトでの経験談

ちなみに大規模サイトでこれまであった印象深いこととしては、Tomcatのheapサイズをインフラ担当者が間違えたことでCPU100%張り付き→ダウンを繰り返していたことですね。原因究明が灯台もと暗しだったので、原因が分かるのに時間が掛かってしまい、真夜中に監視センターから電話が掛かってくることがしょっちゅうで大変だった時期があります(笑)

あとは、外部サイト連携した時にアライアンスを組んだサイトが、エンティティ定義をちゃんと見てないだろうと思うほど全然違う項目に値をPUTしてきて、大混乱したこともありましたね。

メール周りもくせ者で、モバイル向けのメールは特に気をつけなくてはいけなく、送信量の制御をちゃんとしてあげないとスパム業者扱いを受けてしまうこともあるので、メールサービスのチューニングも必要でしたね。(ASPを使うのもアリですが)

インフラ時代では、よくF5社のBIG-IPという負荷分散装置を使っていたのですが、負荷分散するための処理をiRulesという独自コードを作ることで制御可能なのですが、想定通りに動いてくれないときは悩みました。だって当時はインフラ屋だったのでプログラミングがさっぱりだったので(笑)

あとは、なぜかサーバ室のLANケーブル設計したり、サーバラッキングを手伝ったり、200台くらいのL2スイッチ(確かCisco Catalyst2560だった気が)のConfigを倉庫を借りて流れ作業で流し込んだり、貴著な現場経験をしたと思います。

サーバもLinuxとWindows Serverを簡単で設計/構築したり、Firewallも複数機種構築したり、ルータ/L3スイッチも多数設計/構築/運用したりとインフラだけでもやることは多かった気がします。

あと、大規模アプリで特に多いのが、試験中にアプリ不具合が出ると、何かとアプリケーションエンジニアがインフラのせいにすることが多かったですね(笑)まぁ疎通できないから低いレイヤから疑うのは仕方ないかもしれないですが、その度にパケットキャプチャやHTTP HEADER確認して無実を証明するのが面倒でした。

Written by Info Architecture

スポンサーリンク

この記事が良ければ、ぜひシェアお願いします

もぐ
年齢 : 30代半ばの1児の新米パパ。ITネットワークから始まり、WEBディレクター、WEBシステム系のプロマネ、データ分析など色々やってるエンジニアです。WordPress、Webサービス構築、BIツール、IoTなどがトレンド。新しくて面白い仕事募集中。
スポンサーリンク