学ぶ｜Web開発入門 #9

スケーラビリティとセキュリティの基本を独学で身につける完全ガイド｜負荷対策からSQLインジェクション対策まで

  • スケーラビリティ
  • セキュリティ
  • Web開発入門
  • プログラミング未経験
📋 この記事の目次
  1. スケーラビリティは「行列のできるラーメン店の増席戦略」だと考える
  2. Part A: スケーラビリティの基本
  3. Part B: データベースのスケーリングとキャッシング
  4. Part C: セキュリティの基本
  5. Part D: Webアプリケーションへの攻撃と対策
  6. 実践プロジェクト：ゲストブックが「バズった」想定でチェックする
  7. 🧠 理解度チェック（一部抜粋）
  8. 挫折ポイントTOP3と対処法
  9. この先、何を学べばいいか
  10. まとめ
  11. 🎓 理解度テスト

これまでの回で、自己紹介カードは見た目・データ保存・動き・テストまで揃ったWebアプリケーションになりました。連載最終回は「もしこのサイトがSNSで話題になり、アクセスが急増したら？」「悪意ある第三者に狙われたら？」を想定した、スケーラビリティ（拡張性）とセキュリティの基礎知識です。

スケーラビリティは「行列のできるラーメン店の増席戦略」だと考える

お店が繁盛して行列ができたとき、取れる対策は主に2つです。

  • 垂直スケーリング = 「厨房を広くする・スタッフの腕を上げる」（今あるサーバー1台の性能を上げる）
  • 水平スケーリング = 「支店を増やして、お客さんを振り分ける」（サーバー自体を複数台に増やす）

Part A: スケーラビリティの基本

スケーラビリティとは・サーバーホスティング・ベンチマーキング

スケーラビリティとは、「アクセスやデータ量が増えても、性能を維持し続けられる能力」のことです。まずは「今のサーバーがどこまで耐えられるか」を計測すること（ベンチマーキング）から始まります。

垂直スケーリングと水平スケーリング

垂直スケーリング: サーバー1台のCPU・メモリを増強する
水平スケーリング: 同じ処理をするサーバーを複数台に増やす

垂直スケーリングは実装がシンプルですが、1台の性能には物理的な上限があります。水平スケーリングは理論上どこまでも拡張できますが、複数台にどうアクセスを振り分けるかという新しい課題（ロードバランシング）が生まれます。

ロードバランサーとロードバランシング戦略

ユーザー → ロードバランサー → サーバーA / サーバーB / サーバーC

ロードバランサーは「受付」の役割を果たし、アクセスを複数のサーバーに均等に振り分けます。「順番に割り振る」「今いちばん空いているサーバーに割り振る」など、いくつかの振り分け戦略があります。

セッション管理とSPOF（単一障害点）

複数台構成にすると、「Aさんが最初にアクセスしたサーバー」と「次にアクセスしたサーバー」が違う可能性があり、ログイン状態などの情報（セッション）をどう共有するかが課題になります。また、ロードバランサー自体が1台しかないと、それが壊れた瞬間にサービス全体が止まる単一障害点（SPOF） になるため、ロードバランサー自体も冗長化（予備を用意）しておく必要があります。

🧓 ベテランの現場コラム 「サーバーを増やせば解決する」と思われがちですが、実際にはセッション管理やデータベースとの整合性など、台数を増やしたことで初めて表面化する課題が山ほどあります。スケーラビリティは「後からいくらでも足せる」ものではなく、ある程度は最初の設計段階から意識しておく必要があるテーマです。

Part B: データベースのスケーリングとキャッシング

データベースのスケーリングとレプリケーション

アプリのサーバーを増やしても、全員が同じ1つのデータベースに読み書きしていると、今度はデータベースがボトルネックになります。レプリケーションは、データベースの複製（コピー）を作り、「書き込みは1台（マスター）、読み込みは複数台（レプリカ）に分散する」という対策です。ゲストブックのような「投稿は少ないが閲覧が多い」機能は、この恩恵を受けやすい典型例です。

キャッシング

# 疑似コード：キャッシュがあればそれを使い、なければDBに問い合わせて保存する
def get_message_count():
    cached = cache.get("message_count")
    if cached is not None:
        return cached

    count = Message.objects.count()
    cache.set("message_count", count, timeout=60)  # 60秒だけ保持
    return count

キャッシングは「よく使う計算結果を、一時的に手元のメモに控えておく」仕組みです。ゲストブックの投稿件数のように「毎回厳密なリアルタイム性が必須ではない」情報は、キャッシュとの相性が良い代表例です。

Part C: セキュリティの基本

セキュリティの原則

  • 最小権限の原則: 必要最低限の権限だけを与える
  • 多層防御: 1つの対策だけに頼らず、複数の壁を用意する
  • 入力を信用しない: ユーザーからの入力は、悪意があるかもしれない前提で扱う

「ユーザーからの入力を信用しない」という原則は、この先に出てくる具体的な攻撃対策すべての土台になります。

Part D: Webアプリケーションへの攻撃と対策

フィッシング攻撃

本物そっくりの偽サイトに誘導し、パスワード等を盗む手口です。利用者側の注意も重要ですが、サイト運営側としては「公式ドメインを分かりやすく周知する」「なりすましメールへの注意喚起をする」といった対策が挙げられます。

SQLインジェクション（SQLi）

# 危険な例：ユーザー入力をそのままSQL文に埋め込んでいる
query = f"SELECT * FROM messages WHERE visitor_name = '{user_input}'"

# 安全な例：Djangoのようなフレームワークが提供するORMを使う
Message.objects.filter(visitor__name=user_input)

ユーザーが入力欄に'; DROP TABLE messages; --のような文字列を仕込むことで、想定外のSQL文を実行させる攻撃です。DjangoのORM（第5回で学んだfilter()等）を素直に使っていれば、内部で自動的に無害化（エスケープ）されるため、この攻撃はほぼ防げます。危険なのは、自前で文字列を直接組み立ててSQLを実行するようなコードです。

クロスサイトスクリプティング（XSS）

<!-- 危険な例：ユーザーの入力をそのままHTMLとして埋め込んでしまう -->
<p>{{ message.body|safe }}</p>

<!-- 安全な例：Djangoの標準機能に任せる（自動エスケープされる） -->
<p>{{ message.body }}</p>

第6回のJavaScriptの回で軽く触れた通り、ユーザーが入力した内容に悪意あるスクリプトが仕込まれ、それが他の訪問者のブラウザ上でそのまま実行されてしまう攻撃です。Djangoのテンプレートは標準で自動エスケープしてくれるため、|safeのように明示的に無効化しない限り、基本的な対策は最初から効いています。

クロスサイトリクエストフォージェリ（CSRF）

<form method="POST" action="/guestbook/post/">
  {% csrf_token %}
  <!-- 入力欄 -->
</form>

ユーザーが気づかないうちに、別サイト経由で意図しない操作（投稿・削除など）を実行させられる攻撃です。Djangoの{% csrf_token %}は、「このフォームが本当に自分のサイトから送信されたものか」を確認するための仕組みで、フォームには必ず含めます。

パスワードセキュリティとHTTPS/SSL・TLS

  • パスワードは平文（そのままの文字列）で保存せず、ハッシュ化（元に戻せない形に変換）して保存する。Djangoの認証機能は標準でこれを行う
  • 通信は必ずHTTPS（SSL/TLSによる暗号化通信）にする。ConoHa VPS等で証明書（Let’s Encrypt等）を設定するのはこのため

🧓 ベテランの現場コラム セキュリティ対策は「自分で全部組み立てる」よりも、「フレームワークが標準で用意している防御を無効化しない」ことの方がずっと重要です。Djangoの自動エスケープやCSRFトークンは、初期状態で有効になっています。わざわざ|safeを使ったり、CSRF保護を無効化したりしない限り、多くの攻撃は最初から防げていると考えて良いでしょう。

実践プロジェクト：ゲストブックが「バズった」想定でチェックする

  1. 投稿件数の表示にキャッシュを導入し、毎回データベースに問い合わせない構成を検討する
  2. フォームに{% csrf_token %}が入っているか確認する
  3. メッセージ表示部分で|safeのような自動エスケープの無効化をしていないか点検する
  4. パスワードを扱う機能がある場合、平文保存になっていないか確認する
  5. 本番公開時にHTTPS化されているか確認する

🧠 理解度チェック（一部抜粋）

  • Q. 垂直スケーリングと水平スケーリングの違いは？ → 垂直はサーバー1台の性能強化、水平はサーバー台数を増やして分散すること
  • Q. SQLインジェクションを防ぐ基本方針は？ → ユーザー入力を直接SQL文に埋め込まず、ORM等の安全な仕組みを使う
  • Q. CSRFトークンの役割は？ → フォーム送信が本当に自分のサイトから行われたものかを確認する仕組み

挫折ポイントTOP3と対処法

1. 「スケーラビリティの話が抽象的で実感が湧かない」問題

まずは自分のアプリの「アクセスが増えたらどこが一番先に遅くなりそうか」を考えてみるところから始めると、垂直/水平スケーリングやキャッシュの意味が自分ごとになります。

2. 「セキュリティ対策をやりすぎて機能が動かなくなる」問題

CSRFトークンの入れ忘れやエスケープの過剰な無効化解除など、設定を変えるたびに「意図した動作か」を確認しながら進めるのが安全です。

3. 「何を優先して対策すればいいか分からない」問題

個人開発の初期段階では、まず「フレームワークの標準機能を無効化しない」「HTTPS化する」「パスワードを平文で扱わない」の3点を徹底するだけで、多くの典型的な攻撃には耐えられます。

🧓 ベテランの現場コラム セキュリティは「100点を取る」ことが目的ではなく、「よくある攻撃に対する基本的な備えができているか」を継続的に点検する営みです。完璧を目指して手が止まるよりも、まずは基本の3点を押さえた上で公開し、そこから少しずつ知識を積み増していく方が、個人開発では現実的です。

この先、何を学べばいいか

これで「学ぶ｜Web開発入門」の全9回は完走です。ここから先は、実際に自分の手でポートフォリオサイトを公開してみる、あるいは本サイトの他の柱（Javaを鍛える／スクール・転職比較）に読み進めて、次のキャリアの一歩を考えてみてください。

まとめ

  • スケーラビリティは「垂直（性能強化）」と「水平（台数増加）」の2方向で考える
  • データベースのレプリケーションとキャッシングは、読み込みが多いアプリと相性が良い
  • セキュリティの土台は「ユーザーからの入力を信用しない」という原則
  • SQLインジェクション・XSS・CSRFは、フレームワークの標準機能を無効化しない限り基本的な対策が効いている
  • パスワードのハッシュ化とHTTPS化は、個人開発でも必ず押さえるべき最低ライン

参考にした学習リソースについて

本記事は、ハーバード大学が提供する人気講座「CS50’s Web Programming with Python and JavaScript」の内容を参考にしつつ、独自の題材・独自の構成・自作のサンプルで書き下ろしたオリジナル解説記事です。CS50そのものに興味を持った方は、以下の公式サイトも覗いてみてください。

🎓 理解度テスト

学んだ内容を確認しましょう。全7問。