小幡 知弘 
こんにちは、小幡です。
前回はDockerを利用したコンテナ形式でのデプロイ方法について触れてみました。
今回は、VPCとそのSubnetなどネットワークに関連する箇所について深堀していきたいと思います。
ローカル上のDockerでNginxとGunicornを連携させたりするのと、AWS上でECSを使ってタスク管理することは似ているところがありますが、テンプレートの書き方とDockerComposeファイルの書き方はかなり違っていますし、ローカルでの動作確認用の環境と、本番の環境を近い状態に持っていくのはなかなか大変なことです。
Djangoの起動について、ローカルではrunserverで実行したいけれど、本番ではgunicornで起動させたいといった事も、IoCとしてコードでまとめておきたいものです。すべてをコードに落とし込めることがベストですが、ある程度妥協するときも必要かもしれません。
ちなみに前回使用したVPCとSubnetは最初から１つ作成されているデフォルトのもので、基本的にALBはパブリックサブネットで使用しますが、アプリケーションサーバやRDSはプライベートサブネットで使用します。
もちろんVPCとSubnet以外にも修正しているところやテンプレートに追加しているものなどが多数ありますが、割愛しているところも多数ありますのでご注意ください。
自分自身への備忘録的な記事なので、検証を行っていないところや、間違いもあると思いますのでご注意ください。
マルチAZ構成の完成図
まずは完成したイメージ図です。
一番外枠から内側に向かってリクエストが流れる形で説明します。
一番外側がVPCです。インターネットから、インターネットゲートウェイを通してリクエストが送られます。
インターネットゲートウェイからALBにリクエストが送られます。
ALBからは、２つのAZ内に作製されたパブリックサブネット内のNginx（Fagate）にリクエストが送られます。
パブリックサブネット内のNginxから、プライベートサブネット内のDjango（Fagate・Gunicorn）にリクエストが送られます。
Djangoから、必要に応じてRDSにリクエストが送られます。
レスポンスは、リクエストの道を辿って返却されます。
以上でマルチAZ構成の説明は終わりです。
今回はCSSや画像などの静的ファイルはNginxに待たせることにしています。
だんだんAWSのベストプラクティスとして表現されるイメージに近づいてきましたが、まだまだやれることはたくさんある印象です。
VPCについて
VPC (Virtual Private Cloud) は仮想のプライベートなクラウドという名前の通り、AWSのとても大きなサービスの中に、仮想的なプライベートな空間を作っているようなイメージです。
ある特定の仮想プライベート空間を用意することで、様々な構成で好きな様にサービスを展開することができます。これは、前回のパブリックサブネットしか無いような構成も可能ですので、十分な知識と検討が必要です。
この空間の中に物理的に離れたAZ（アベイラビリティーゾーン）を作成することで、１つの構成が壊れたとしても、もう１つの構成を使うことができる状態にできます。日本の場合だ１つのVPCで３つのAZ構成ができるようになりますが、次に登場してくるFagateやRDSを３つ作成すると、その分だけ費用が高くなりますので注意が必要です。
VPCという仮想的空間に物理的に離れた構成を組み込むというのは少しイメージが難しく感じますが、そういうものだと頭を切り替えます。
そしてこのAZそれぞれにサブネットを設定します。
Subnet
そして次に色々なリソースを設定する空間としてサブネットを設定します。
この時２つのタイプのサブネットを設定することにします。
１つはパブリックサブネットで、こちらにはALBによってリクエストを受け取る窓口として、Nginxを配置するためのサブネットです。動的なデータが必要ない場合は、Nginxに配置された静的データを返却するだけで終わりますので、イメージからもわかる通り、次のプライベートサブネットに行く必要もなくなりそうですね。
もう１つはプライベートサブネットで、こちらにはNginxからのリクエストが送られます。今回の場合だとDjangoが配置されており何かデータを処理する場合はここで行います。今回はRDSを作成しており同じプライベートサブネットに配置していますので、Djangoで何かデータを保存や参照したい場合はRDSとのやり取りが可能です。
このような構成はイメージ図からもわかる通り、プライベートサブネットにはパブリックサブネットを通してからではないとアクセスできない状態になっています。これにより、よりセキュアな状態を保つことができています。
このように、前回はすべてをパブリックに配置していましたが、用途に応じてパブリックに配置するのか、プライベートに配置するのかを慎重に検討する必要があります。
まとめ
今回は新しくVPCを作成し、その中ではマルチAZを実現させてみました。
マルチAZ構成を実現することで、可用性は高くなりますが、その分費用が高くなることには注意が必要です。実際に運用などを考える際は、費用を計算し要件や予算とすり合わせが必要だと考えています。
今回はインフラ学習のためにマルチAZ構成にしています。CloudFormationで作成しているので、一度作成できることを確認したらすぐに全て削除できるので、費用もそれほどかからないのは嬉しいですね。サービス運用をすることがあればその時にまた慎重に検討をしたいと思います。
次回はこの構成の状態で開発を進めた場合に継続的インテグレーションと継続的デリバリー（CI/CD）が出来る環境が整えられるよう勧めて行った時の話ができればと考えています。
以上です。