Movable Type を AWS で利用する方法
AWS 環境に Movable Type をデプロイする方法は、大きく分けて3つ考えられます。
- Movable Type AMI 版
- Amazon EC2 上に自前で展開
- Amazon EC2 または、Amazon ECS 経由で Docker コンテナとして展開
Movable Type AMI 版は、AWS Marketplace で販売されている Movable Type のパッケージやデータベース、必要なライブラリなど実行環境が整った状態でパッケージなので、10分も掛からずに使い始めることができます。また、yum や dnf などのパッケージ管理ツールに対応しているのでアップデートも比較的容易なのが特徴です。
2つ目の Movable Type を自前で EC2 インスタンスに展開する方法は、Movable Type ソフトウェア版のパッケージを入手して自分で環境を構築する方法です。Perl の実行環境から必要なモジュールのインストール、データベースなどについても自前で設定する必要があるため手間はかかりますが、最も自由度が高いです（その分、管理責任範囲も大きいです）。
Docker コンテナとして Movable Type をイメージ化する方法もあります。自前でイメージの作成が必要なので、手順としては2つ目の自前で展開する方法とさほど変わりません。ECS を使えば、Docker 環境の自動構築が可能な点と、Fargate タイプを利用すれば起動した EC2 インスタンスをサーバーレス化できる点で2つ目の方法よりは管理運用が楽になります。
このシリーズでは、まずはコンテナ以外の方法で EC2 にデプロイした環境を利用したアーキテクチャ設計を考えていきます。
コンテナでのアーキテクチャ設計は気が向いたらするかもしれない。
1台の Movable Type によるシンプルな構成
まず最初に紹介するアーキテクチャは、1台の EC2 インスタンスだけで構成された最もシンプルな構成です。
個人ブログや、開発環境など限定的な利用に適しています。
特徴
1台の EC2 インスタンスに、アプリケーション、データベース、公開コンテンツをすべて含んでいる構成です。最もシンプルな構成さなので、管理運用する必要があるリソースが EC2 インスタンス1台だけで済むのが最大の特徴です。
サイトの開発環境や、個人で利用する程度のブログサイトなどであれば大きな問題は起きにくいですが、可用性や耐障害性に大きな課題を残しているアーキテクチャと言えます。
利点
- 公開コンテンツ、データベース、アプリケーションを含めて1つの AMI でバックアップが完了する
考慮点
- EC2 インスタンスが単一障害点となるため、EC2 インスタンスの障害や内部のアプリケーションの動作不良により簡単にアクセス不可になってしまう
- サーバーのログやデータベースなどを考慮すると AMI のバックアップのタイミング次第ではデータのロストが大きい
- Web サーバー、データベースサーバーの負荷次第ではインスタンスタイプを大きなものにしないとパフォーマンスが維持できない可能性がある
まとめ
Design for Failure の考え方からみても、Well-Architected の観点から見ても、プロダクション環境でやるべきではない構成の最有力です。なにしろ、EC2 のメリットである使い捨てできることが殺されてます。
（とはいえ、世の中にこの構成多いんですよね）
次回は、少しだけマシにします。