Movable Type で 学ぶ AWS アーキテクチャ設計 - その2(サーバーの分離)

突如始まったシリーズ第二弾、前回は1台の EC2 インスタンスですべてをまかなう All-In-One な構成を考えていきましたが、実際のプロダクション環境では採用するべきではない点についても触れています。

今回は、EC2 インスタンスの負荷を軽減させることをメインに考えてみます。

データベース・サーバーの分離

一般的なシステムでは、データベースサーバーはあまりパブリックアクセスが可能なサーバーに配置しないことが多いです。これは、セキュリティ面で考えれば当たり前のことで、ファイアーウォールで守られているとはいえ、不必要なサーバーを公開することを減らすことが重要であるからです。

前回のアーキテクチャでは、Webサーバー、アプリケーション、データベースサーバーが1台のインスタンスにデプロイされているため、セキュリティ面からも性能面からも良くないです。

most-simplified.png

ということで、今回はデータベース・サーバーをまずは分離させることを考えます。

EC2 で分離

EC2 インスタンスは一般的なサーバー用途でできることは大半のことが実現可能なので、データベースを EC2 にインストールして利用することができます。

rdb-in-ec2.png

利点

データベースサーバーの構築に慣れていれば構築は容易です。また、MySQL や PostgreSQL などのデータベース以外のデータベースでもセットアップして利用できる可能性が高いです。

考慮点

データベース・サーバーが増えたので、管理運用する対象が増えます。データベース・サーバーのパフォーマンスや、資源管理などの手間も発生します。

RDS で分離

AWS で MySQL、PostgreSQL、MariaDB、Oracle、SQL Server を利用するのであれば、EC2 で自前で構築せず Amazon Relationa Database Service (RDS) を利用する方法がよりよい選択肢といえます。

ec2-with-rds.png

RDS は、マネージドサービスなので、サーバーの構築が不要です。利用したいスペックの指定をするだけでサーバーの構築を行ってくれます。また、バックアップ周期やアップデート周期など希望する運用方針を設定することで、AWS が代わりにサーバーの運用を行ってくれます。

利点

データベース・サーバーの管理運用を任せられるため、利用者が管理運用するものを減らせます。

考慮点

バックアップ周期や、サーバーのアップデート周期などの運用設計や、サーバーの性能吟味やパフォーマンスチューニングは引き続き利用者側で検討して利用する必要があります。

Web サーバーの分離

用途に応じた EC2 インスタンスを用意することで、データベース・サーバーのみならず Web サーバーも分離できます。これにより、サイトのコンテンツを公開するサーバーとアプリケーション・サーバーを分離することができます。

file-sharing-with-efs.png

Movable Type は、スタティックジェネレータなので公開するコンテンツはファイルとして生成されます。Web サーバーとアプリケーション・サーバーを分離した場合、生成されたコンテンツを各サーバー間で同期させる必要があります。

rsync などで同期する方法もありますが、Amazon Elastic File System (EFS) を利用すれば、各サーバー間で共有できるボリュームを NFS マウントして利用できます。

Movable Type から出力される先のディレクトリを EFS でマウントしたボリュームにし、Web サーバーでは、EFS のボリュームをドキュメントルートに設定すれば再構築したファイルはすぐに公開されます。

利点

EFS を利用することで複数の EC2 インスタンス間の共有ボリュームを構成できます。

考慮点

EFS は容量が実質無制限で保存されたデータ量に対して課金されます。不要なコンテンツは整理するほうがコスト的に良いです。

まとめ

サーバーのセキュリティ面やパフォーマンスの面からもサーバーは役割に応じて分離することが望ましいです。1台の大きなインスタンスよりも、小さくても多くのインスタンスで処理を検討します。

また、自前でサーバーを構築するだけではなく、AWS のマネージドサービスを利用することで運用負荷を軽減させられます。