カテゴリー
Uncategorized

AWSでWeb3層アーキテクチャを組んだ

今までなんとなくでやっていたことを理解しながらモヤっとした部分をクリアにするために改めて取り組んでみました。

今回はVPCの作成から行い、プライベートサブネットにアプリケーションを展開し、ブラウザからアクセスできるようになることを目標としました。

やることの洗い出し

なにかに取り組むとき、以前はとりあえず手を動かせというノリでやっていましたが、なにか躓くとその度調査に時間がかかり、結果的にものすごい時間がかかってしまいます。なので最近はある程度事前にやることをまとめておくようにしています。するとより効率的に進めることができると思うからです。

  • VPCの作成
    • CIDRは10.1.0.0/16とします。CIDRで気をつけることは、オンプレ等のネットワークとVPCを繋ぐ場合に既存のネットワークで利用できるIPであるかという観点になるそうですが、今回は気にしなくていいでしょう。
    • 利用できるIP数とかの計算は正直よく分かっていませんが、/16なら大体枯渇するようなこともないですし、今回はそこまでIPを使うことも想定していません。
  • サブネットの作成
    • パブリック用にサブネットを1aと1cに配置します。
    • パブリックのサブネットはLBの配置に利用するのと、プライベートサブネットに配置したサーバーがインターネットに出ていくためのNATゲートウェイの配置に利用します。
    • プライベート用にサブネットを1aと1cに配置します。
    • プライベートサブネットに立てるEC2インスタンス内でRailsアプリケーションを動かす想定です。
  • インターネットゲートウェイの作成
    • 作成したVPCのインターネットへの出入り口として、IGWを一つ作成します。パブリック用サブネットを紐付けると、そのサブネットに出入りできるようになる認識です。
  • NATゲートウェイの作成
    • プライベート用サブネットはIGWを紐付けません。つまりインターネットへの出入りが出来ない環境になります。サーバー管理上、出ていく通信は必要なため、この場合パブリックサブネットに配置したNATゲートウェイを経由して出ていくよう設定します。
    • 料金が高いので、1a用のみ作成しました。
  • ルートテーブルの作成
    • ルートテーブルは新たに3つ作成します。
    • パブリック用サブネットのルートテーブルは、パブリックに設置したEC2インスタンスがVPCのインターネットゲートウェイ(IGW)を経由するよう0.0.0.0/0の通信をIGWに向けます。
    • プライベート1a用サブネットのルートテーブルでは、0.0.0.0/0の通信をパブリック1aのNATゲートウェイに向けます。
    • プライベート1c用サブネットのルートテーブルでは、0.0.0.0/0の通信をパブリック1cのNATゲートウェイに向けます。
  • セキュリティグループ
    • 基本はリソースの作成と同時に作成しますが、最終的には下記の通りに作成されています。
    • パブリックに配置するEC2用SG
      • インバウンドはpingを通すためのICMPを開放、SSH接続するための22番ポートを開放。
    • プライベートに配置するEC2用SG
      • インバウンドはpingを通すためのICMPを開放、SSH接続するための22番ポートを開放。
      • LBからのhttp通信を許可するための3000番ポートの開放。(LB→Nginxは3000番で公開するため)
    • ロードバランサ用のSG
      • 80番と443番を開放。80番は443番にリダイレクトするために受け入れています。
    • RDS用のSG
      • RDSの作成と同時に作成されるSG。MySQLなので3306を接続元であるプライベートサブネットのSGのみに絞り開放。

ここまででVPC周りの環境が整いました。

パブリックネットワーク

プライベートネットワーク

次にアプリケーション関係を整理していきます。

  • まずはRailsアプリケーションを動かすために必要なものを整理
    • そういえばRDS必要だなと考えたり
    • EC2の作成
    • Gitインストール
    • Rubyインストール
    • Nginxインストール
    • curlコマンドでPumaおよびNginx経由でアクセスできることの確認
  • RDSの作成
    • 今回はMySQLを使用します。
    • パブリックIPは設定しません。パブリックアクセス不可。
  • ブラウザからのアクセスに必要なものを整理
    • ドメインの用意
    • SSL証明書はACMで取得(簡単だし)
    • ネームサーバーはRoute53を使う
    • Route53からLBに向けてAレコード作成
    • LBの準備
      • EC2インスタンスをターゲットグループに追加
      • ヘルスチェックの確認

諸々設定してブラウザからのアクセスができるようになりました!しかし、問題を孕んでいました。

ブラウザでアクセスすると、レスポンスに10秒かかるときと即帰ってくるときがある問題

これにはハマりました。自分では解決できず2,3日経過したとことでチームメンバー(取引先ですが…)の方に聞いてみたところ原因が発覚…。

結論、LBはパブリックサブネットを2つ指定する必要がありますが、片方プライベートサブネットを指定していたためでした。

10秒かかっていた理由は、DNSからプライベートのサブネットのほうにトラフィックが流れ、レスポンスが帰ってこないのでパブリックのサブネットにトラフィックがリダイレクト(?)されるようです。運良くパブリックのサブネットにトラフィックが流れたときは即時帰ってきていたんですね。

まとめ!

躓きポイントはあったものの、なんとか3層アーキテクチャのインフラ環境を構築することができました。初めてまともにVPCを触ったので、調べつつではありましたが、CIDRであったりサブネット、ルートテーブルの概念の理解が進み、もやもやを払拭できた気がします。

あと、割とインフラ方面の概念の理解が思ったより出来ていることに驚きました。インフラ方面でも手応えを感じられたのは自信にも繋がった気がします。

やっぱりマインクラフトサーバを運用していただけあるかも知れません。笑

今度はECSにデプロイを試してみようと思います。
その後はサーバレス関連かなあ。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です