1761315777
2025-10-24 14:10:00
Web アプリケーションの構築は、単にコードを記述するだけではありません。それは、アプリケーションのアクセス可能性、拡張性、安全性、信頼性を高めるインフラストラクチャ全体を作成することです。
最近、Amazon EC2 インスタンス上で Web アプリケーション (従業員ディレクトリ) を実行するために必要な基盤となるネットワーク アーキテクチャを構築しました。このプロジェクトには、ネットワーク、ストレージ、データベース、負荷分散、および監視をセットアップして、運用可能な環境を作成することが含まれていました。
ここでは、私がどのようにアプローチし、何を学んだのか、そして各コンポーネントがなぜ重要なのかを説明します。
課題: 単に「アプリをデプロイする」だけではない
「Web アプリケーションをデプロイする」と聞くと、簡単そうに聞こえます。しかし実際には、システム全体を設計しているのです。
- 計算: アプリケーションはどこで実行されますか?
- ネットワーキング： ユーザーはどのようにアクセスしますか?さまざまなコンポーネントはどのように通信するのでしょうか?
- ストレージ： 画像やファイルなどの静的資産はどこに保存しますか?
- データベース: アプリケーションデータはどこに保存されますか?
- 負荷分散: トラフィックを分散して高可用性を確保するにはどうすればよいですか?
- 監視： 何かが壊れたかどうかをどうやって知ることができますか?
これらの各部分は正しく構成され、シームレスに連携する必要があります。
アプリケーション: 従業員名簿
私がデプロイした Web アプリケーションは従業員ディレクトリでした。これは、ユーザーが次のことを可能にするシンプルだが機能的なアプリです。
- 従業員一覧を見る
- 特定の従業員を検索する
- 従業員の詳細（名前、部署、連絡先、写真）を表示します。
これは一般的な社内エンタープライズ アプリケーションであり、AWS アーキテクチャのコア概念を説明するのに最適です。
ステップ 1: Amazon EC2 を使用したコンピューティングレイヤーのセットアップ
アプリケーションを実行する場所が必要だったので、 Amazon EC2 インスタンス。
主な決定事項:
- インスタンスの種類: 予想されるトラフィックとリソース要件に基づいて、適切なインスタンス サイズを選択します。
- AMI (Amazon マシンイメージ): 必要なオペレーティング システムとプリインストールされたソフトウェアを備えた AMI を選択しました。
- セキュリティグループ: インターネットからの HTTP (ポート 80) および HTTPS (ポート 443) トラフィック、および自分の IP からの管理アクセスのみに SSH (ポート 22) を許可するようにセキュリティ グループ ルールを構成しました。
EC2 インスタンスはコンピューティング エンジンであり、Web サーバーとアプリケーション コードを実行します。しかし、計算だけでは十分ではありません。ネットワーク、ストレージ、データが必要です。
ステップ 2: ネットワーク アーキテクチャの構築
AWS ネットワーキングは以下を中心に展開します 仮想プライベート クラウド (VPC) — クラウド内の独自の隔離されたネットワーク。
私が設定したのは次のとおりです。
VPC: 定義された IP アドレス範囲 (CIDR ブロック) を使用してカスタム VPC を作成しました。
サブネット: パブリック サブネット (インターネットにアクセスできるリソースが存在する場所) とプライベート サブネット (インターネットに直接公開する必要のないリソース用) を作成しました。 Web アプリを実行する EC2 インスタンスは、ユーザーがアクセスできるようにパブリック サブネットに配置されました。
インターネットゲートウェイ: VPC とインターネット間の通信を可能にするために、インターネット ゲートウェイを VPC に接続しました。
ルートテーブル: トラフィックを適切に誘導するようにルート テーブルを構成しました。
- パブリック サブネット ルート テーブルは、インターネット宛てのトラフィックをインターネット ゲートウェイにルーティングします。
- プライベート サブネット ルート テーブルは、VPC 内の内部トラフィックをルーティングします。
セキュリティグループ: EC2 インスタンスの仮想ファイアウォールとして機能し、インスタンス レベルで受信トラフィックと送信トラフィックを制御します。
このネットワーク基盤により、次のことが保証されます。
- Web アプリケーションにはインターネットからアクセスできます
- 内部コンポーネントは安全に通信できる
- トラフィックは正しく安全にルーティングされます
ステップ 3: 静的資産ストレージ用に Amazon S3 を追加する
Web アプリケーションは、画像、CSS ファイル、JavaScript、従業員の写真などの静的資産を保存する必要があります。
これらを EC2 インスタンスに直接保存する代わりに (コンピューティング リソースが無駄になり、スケーラブルではありません)、 Amazon S3 バケット。
なぜS3なのか？
- スケーラブル: 無制限の量のデータを保存できます。
- 耐久性: 99.999999999% (11 ナイン) の耐久性。データは失われません。
- 費用対効果が高い: 保存および転送したものに対してのみ料金を支払います。
- 速い： 静的コンテンツの高速取得のために最適化されています。
私が設定したのは次のとおりです。
- バケットポリシー: 誰がどのような条件でバケットにアクセスできるかを制御します。
- CORS (クロスオリジンリソース共有): Web アプリケーションが S3 バケットからアセットをロードできるようにしました。
- 静的 Web サイト ホスティング (オプション): S3 は、必要に応じてフロントエンド全体にサービスを提供することもできます。
従業員の写真やその他の静的資産が S3 に保存されるようになり、EC2 インスタンスの負荷が軽減され、パフォーマンスが向上しました。
ステップ 4: データベース用の Amazon RDS (DynamoDB) のセットアップ
従業員ディレクトリには、名前、部門、連絡先の詳細などの従業員情報を保存するデータベースが必要でした。
私が使用した Amazon DynamoDB、フルマネージド NoSQL データベース サービス。
なぜ DynamoDB なのか?
- フルマネージド: サーバーをプロビジョニングしたり、パッチを管理したり、スケーリングについて心配したりする必要はありません。
- 高速かつ柔軟: あらゆるスケールで 1 桁のミリ秒の応答時間を実現します。
- スケーラブル: 需要に基づいて自動的にスケールアップおよびスケールダウンします。
私が設定したのは次のとおりです。
- テーブル: 適切な主キーを持つ従業員データを保存するテーブルを作成しました。
- IAM の役割: EC2 インスタンスが認証情報をハードコーディングせずに DynamoDB に対して安全に読み取り/書き込みできるようにアクセス許可を設定します。
- インデックス: 効率的なクエリ (部門名または従業員名による検索など) のために二次インデックスを作成しました。
(注: プロジェクトの説明では、RDS と DynamoDB の両方について言及しています。RDS は通常、MySQL や PostgreSQL などのリレーショナル データベース用ですが、DynamoDB は NoSQL です。この場合、説明に基づいて DynamoDB を使用しましたが、リレーショナル データベースに RDS を使用する場合にも同じ原則が適用されます。)
これで、アプリケーションには、従業員情報を保存および取得するための信頼性が高く、スケーラブルなデータベース バックエンドが追加されました。
ステップ 5: Elastic Load Balancer (ELB) の起動
EC2 インスタンスがクラッシュするとどうなりますか?トラフィックが急増し、1 つのインスタンスが負荷を処理できなくなった場合はどうなりますか?
必要です 負荷分散 そして 高可用性。
を立ち上げました Elastic Load Balancer (ELB) 受信トラフィックを複数の EC2 インスタンスに分散するため (または、この場合は将来のスケーリングに備えてアーキテクチャをセットアップするため)。
主要な構成:
- アプリケーション ロード バランサー (ALB): レイヤ 7 (HTTP/HTTPS) で動作し、URL パスまたはホスト名に基づいてトラフィックをルーティングできます。
- 対象グループ: Web アプリを実行している EC2 インスタンスを含むターゲット グループを作成しました。
- ヘルスチェック: ロードバランサーが正常なインスタンスにのみトラフィックを送信するようにヘルスチェックを構成しました。インスタンスがヘルスチェックに失敗した場合、トラフィックは自動的に別の場所にルーティングされます。
- SSL/TLS 終端: ロードバランサーはHTTPS暗号化/復号化を処理できるため、アプリケーションサーバーの負荷が軽減されます。
ロードバランサを配置すると、次のようになります。
- トラフィックは効率的に分散されます
- 1 つのインスタンスに障害が発生した場合、トラフィックは自動的に正常なインスタンスにルーティングされます。
- ロードバランサーの背後にインスタンスを追加することで、アプリケーションを水平方向に拡張できます。
ステップ 6: Amazon CloudWatch によるモニタリング
測定しないものは管理できません。そこです Amazon CloudWatch AWS の監視および可観測性サービスが登場します。
以下を監視するように CloudWatch を設定しました。
- EC2 メトリクス: CPU 使用率、ネットワーク入出力、ディスク I/O。
- ELB メトリクス: リクエスト数、レイテンシ、正常/異常なインスタンスの数。
- DynamoDB メトリクス: 読み取り/書き込み容量の使用量、スロットリングされたリクエスト。
- カスタム アプリケーション ログ: Web アプリケーション自体からのログ。エラーやアクセス パターンなどが表示されます。
私も設定しました:
- アラーム: CPU 使用率が 80% を超えた場合、ロードバランサーが異常なインスタンスを検出した場合、または DynamoDB スロットルが発生した場合に通知するようにアラームを設定しました。
- ダッシュボード: アプリケーションの健全性とパフォーマンスをリアルタイムで表示するための CloudWatch ダッシュボードを作成しました。
モニタリングを導入すると、次のことが可能になります。
- ユーザーが気づく前に問題を検出
- パフォーマンスパターンを理解する
- 詳細なログを使用して問題を迅速にトラブルシューティングします。
ステップ 7: テストと検証
すべてをデプロイして構成したら、アプリケーションをテストして次のことを確認しました。
✅ アクセシビリティ: Web アプリケーションは、ロード バランサーの DNS 名を介してブラウザに正常にロードされました。
✅ 機能性: 従業員名簿を表示したり、従業員を検索したり、従業員の詳細や写真を確認したりできました。
✅ S3 からロードされる静的アセット: 画像と CSS が EC2 インスタンスではなく S3 バケットから読み込まれていることを確認しました。
✅ データベース接続: 従業員データが DynamoDB から正しく取得されていることを確認しました。
✅ ロードバランサーのヘルスチェック: ロードバランサーが EC2 インスタンスを正常であるとマークしていることを確認しました。
✅ 監視とログ: CloudWatch をチェックして、メトリクスとログが適切に収集されていることを確認しました。
すべてがうまくいきました。建築はしっかりしていました。
アーキテクチャ: すべてを統合する
最終的なアーキテクチャは次のようになります。
- ユーザー 経由で Web アプリケーションにアクセスします エラスティック・ロード・バランサー。
- の ロードバランサ トラフィックを分散します EC2インスタンス Web アプリを実行しています。
- の EC2インスタンス ～から従業員データを取得します DynamoDB。
- 静的アセット (画像、CSS、JS) は以下から提供されます。 アマゾンS3。
- クラウドウォッチ すべてのコンポーネントを監視し、問題が発生した場合はアラートを送信します。
- これらはすべて、 VPC 適切に構成されたサブネット、セキュリティ グループ、およびルーティングを使用します。
これは、実稼働対応でスケーラブルで安全な Web アプリケーションのアーキテクチャです。
#AWS #での #Web #アプリケーションの基礎となるネットワーク #アーキテクチャの構築 #あよみでトリリオンズ #年 #月