【Web】サーバー設計について

はじめに

こんにちは。アメリカで独学でエンジニアを目指している者です。
現在Webについて勉強しており、その中でもサーバー設計と構築におけるストレージ構成、セキュリティ、およびシステム基盤テストに触れていこうと思います。
教材にはここまで詳しく書いてありませんでしたが、AIに協力してもらいある程度細かく作成しました。
後々見返すようなので少し淡々と書いてしまっていますがご了承ください

1. ストレージ構成

1-1. ストレージの種類と選定

サーバーのストレージには主に以下のような種類があります。運用目的や予算、必要なスループット／IOPSなどを考慮して選定します。

• 内蔵ストレージ(Direct Attached Storage: DAS)

  • サーバー内部に直接接続されたHDDやSSDを利用する方式。シンプルな構成で初期コストが抑えやすい一方、サーバー単位で容量や性能の拡張性が制限される場合があります。

• ネットワークストレージ(NAS)

  • ネットワーク経由でファイルアクセスを行う仕組み。CIFSやNFSなどのファイル共有プロトコルを利用します。ファイルサーバーを中央集約して管理しやすいというメリットがあります。

• SAN(Storage Area Network)

  • 専用の高速ネットワーク(FCやiSCSIなど)を介してブロックレベルでディスクを共有する仕組み。高速かつ大規模な構成にも対応できる一方、導入コストが高くなりがちです。

• クラウドストレージ

  • AWSやAzure、GCPなど、クラウドプロバイダが提供するブロックストレージ・オブジェクトストレージを利用する方法。運用負荷や初期投資を抑えつつ、大規模な拡張が可能です。

1-2. ディスク冗長構成(RAID)

サーバー内部にディスクを搭載する場合やSANを利用する場合は、RAIDで冗長化することが一般的です。RAID構成により、ディスク障害が発生してもサービスを継続できる信頼性が得られます。

• RAID 1 (ミラーリング)
  同じデータを複数のディスクに書き込み、どれか一つのディスクが故障してもデータを失わないようにする冗長構成。読み取り性能は向上しますが、書き込み性能はディスク台数によらず単一のディスクとほぼ同等です。

• RAID 5 / 6 (パリティ分散)
  パリティ(誤り訂正符号)を用いてディスク障害に耐えられるようにする構成。RAID 5は1台のディスク故障に対応でき、RAID 6は2台の故障にも対応できます。ただし、書き込み性能が若干低下することがあります。

• RAID 10 (ストライピング + ミラーリング)
  RAID 0とRAID 1を組み合わせた方式。ディスクの読み書き性能の向上と耐障害性を両立できますが、ディスクを比較的多く必要とします。

1-3. バックアップ

万全なストレージ構成を組んでもデータ消失のリスクを完全に排除することはできません。そのため、定期的なバックアップは必須です。

• フルバックアップ、差分バックアップ、増分バックアップ
  バックアップウィンドウ(処理時間やサーバー負荷)と復旧時間(リストアにかかる時間)を考慮して方式を選びます。

• オフサイト(遠隔地)バックアップ・クラウドバックアップ
  災害対策を想定し、別拠点やクラウドにバックアップを保管すると信頼性が高まります。

2. セキュリティ

2-1. ネットワークセキュリティ

• ファイアウォール設定
  外部からのアクセスは最小限に制限し、必要なポートだけを開放します。Linuxの場合はiptablesやnftables、OSやソフトウェア付属のFirewallサービスを適切に設定します。

• DMZ(DeMilitarized Zone)の活用
  Webサーバーなど外部からアクセスされるサービスはDMZに配置し、内部ネットワークと切り離します。これにより、万が一侵入を許しても被害を最小限に抑えることができます。

• VPNの利用
  リモート管理や社内ネットワークへの接続にはVPNを利用し、安全な通信経路を確保します。

2-2. OS・ミドルウェアレベルのセキュリティ

• 最小限のOSインストール
  不必要なサービスやパッケージはインストールしないことで、脆弱性のリスクを低減します。

• 定期的なパッチ適用
  OSやミドルウェアにセキュリティアップデートやバグ修正が公開されたら、テストを行った上で早めに適用します。

• アカウント管理・アクセス制御
  rootユーザーに対しては秘密鍵認証のみを許可する、sudoの権限を最小限にする、不要なユーザーを作らないなど、安全なアカウント運用を行います。

• ログ管理・監査ログの取得
  OSやアプリケーションのアクセスログ、操作ログを確実に取得・保存し、定期的に分析する仕組みを作ります。サイバー攻撃が発生した際の証跡としても重要です。

2-3. アプリケーションセキュリティ

• HTTPS/TLS通信
  外部に公開するWebアプリケーションでは、TLS証明書を利用して通信を暗号化し、ユーザーのデータを保護します。

• 入力値検証
  SQLインジェクションやXSSなどの対策として、アプリケーション側で入力されたデータを厳格に検証し、サニタイズします。

• 依存パッケージの脆弱性チェック
  Webフレームワークやライブラリに脆弱性が見つかった場合は速やかにアップデートし、脆弱性を放置しないようにします。

3. システム基盤テスト

運用開始後にサービスが不安定になったり障害が発生してしまうと大きな損失となるため、構築したサーバーおよびシステム基盤はさまざまな角度から十分にテストを行う必要があります。

3-1. 機能テスト(Functional Test)

• サーバーの基本サービス動作チェック
  OSのブートプロセス、ファイアウォールルール、SSHやRDPなどの管理サービス、DNS解決など、想定どおりに動作するかを確認します。

• アプリケーションのインストール・サービス起動テスト
  Webサーバー(Nginx、Apacheなど)、DBサーバー(MySQL、PostgreSQLなど)、その他必要なミドルウェアが問題なくインストール・起動・停止できるかテストします。

• ログ取得確認
  セキュリティログやアプリケーションログなど、設定通りにログを取得できるかチェックします。

3-2. パフォーマンステスト(Performance Test)

• 負荷テスト(Load Test)
  シナリオを作成し、想定される同時アクセス数・トランザクション数を模した負荷をかけ、CPU使用率やディスクIO、ネットワーク帯域などのリソース使用量を分析します。

• ストレステスト(Stress Test)
  負荷テストよりもさらに高い負荷をかけ、システムのボトルネックや閾値を探ります。OSやアプリケーションのパラメータ設定に問題がないか確認します。

• スケールテスト(Scale Test)
  予測される将来的な利用者数増加に耐えられる構成になっているか、拡張しやすいアーキテクチャかをテストします。

3-3. 信頼性・障害対応テスト(Availability/Failover Test)

• フェイルオーバーテスト
  冗長構成(クラスタリングやロードバランサなど)がきちんと機能するか、片系のダウンやネットワーク断でサービスが継続できるかを検証します。

• バックアップ・リストアテスト
  バックアップデータが正しく取得されているか、障害発生時にデータをリストアしても正常に動作が再開できるかを実際にテストします。

• 災害対策(DR)テスト
  別リージョンや別拠点でのシステム立ち上げ手順を確認・訓練し、予期せぬトラブル時でもサービスを復旧できるようにします。

まとめ

ストレージ構成とセキュリティについてはある程度知っておりましたが、システム基盤テストは知らないことが多かったです。
今後テストについて学ぶ予定なので上記の流れを意識しながら学習していきたいと思います。