第2回では、1台の EC2 インスタンスではなくサーバーを役割に応じて分離することことでマネージドサービスを活用することや、1台のサーバーの性能を最大限発揮させることを実現しました。
第3回の今回は、EC2 インスタンスを使い捨てにすることで、より柔軟なアーキテクチャにしていきます。
そもそも使い捨てにするとは？
EC2 インスタンスは、Amazon Machine Image (AMI) をもとに同じ構成のサーバーを簡単にコピーすることができます。これにより、サーバーが不調なときは新しいインスタンスを起動することにより回復する。という戦略を採用できます。
Web サーバーを分離し、Movable Type が生成する静的コンテンツを Elastic File System (EFS) に移すことで EC2 インスタンスとの切り離しができたので、サーバーインスタンスの入れ替えを行ってもコンテンツは消えない環境になっています。
EC2 インスタンスやデータセンター、アベイラビリティーゾーン単位でなんらかの障害が発生した場合でも、稼働可能な場所で AMI から起動すれば良いので、オンプレミス環境のようにサーバーを大事に大事に育てる必要がないです。
EC2 インスタンスを使い捨てにするということは、EC2 インスタンスはプログラムの実行と一時的なデータ保持だけにするということになります。
さて、第2回の段階でも、EC2 インスタンスにはコンテンツ以外にまだ残っているものがあります。それは、アプリケーションのログファイルです。
ログファイルを残しておかないと、いざ何かが発生したときに原因を調べることもできませんし、そもそも異常事態に事前に気がつくことも難しくなります。
ログ管理ソフトウェアを利用する
商用や OSS ベースのログ管理ソフトウェア（一般的にログ・アグリゲーターと呼ばれます）を EC2 インスタンスで管理する方法が考えられます。
利点
使い慣れたソフトウェアがある場合は、そのまま移行したり利用することができる点が利点として考えられます。
考慮点
一方で、ログを管理するためのインスタンスを管理する必要があり、ログ管理インスタンス自体の可用性を考慮する必要があるので、コストが増大する可能性が高いです。
EFS でログ管理
ログファイルを EC2 とともに消失しないようにするためには、EBS 内に残さない方法が考えられます。
EFS でコンテンツ用の他にログ用のファイルシステムを作成してログの保存場所として利用すれれば必要なときに必要なログにするアクセスして解析することができます。
利点
複数のインスタンスを起動していた場合でも、インスタンスIDなどでディレクトリ管理すれば1つのファイルシステムを共有して利用できます。
考慮点
増え続けるログファイルを適切にアーカイブしないと容量を無限に使用してしまいます。また、バックアップの仕組みも必要となるでしょう。
類似するアーキテクチャ
EFS ではなく、S3 に保存する方法も考えられます。
S3 は、イレブンナインの高耐久なストレージサービスであるため、ログファイルが消失する可能性は低いですが、S3 に保存されたオブジェクトはダウンロードしないとそのまま利用することができないのでリアルタイムにログを解析する必要がある場合には、Athena などと組み合わせて利用する必要があります。
CloudWatch Logs でログを管理
CloudWatch は、モニタリングのマネージドサービスです。リソースのメトリクスや EC2 インスタンス内の状態をモニタリングすることができます。
また、CloudWatch Logs では、ログの集約と分析に役立つ機能が提供されています。
利点
CloudWatch Logs を利用することで、ログの管理のためのインスタンスの監視や管理が不要になります。
EC2 インスタンスやオンプレミスのサーバーのログを種類ごと・インスタンスごとに管理でき、CloudWatch Logs Insight から簡易的な分析が行なえます。
CloudWatch Logs のログは、CloudWatch のダッシュボードにもログテーブルとして表示できるので、メトリクスデータと連動したログの確認ができます。
また、ログに対してメトリクスフィルターを設定すれば、ログに含まれる文字列をメトリクスとしてカウントしたり、Web サーバーのステータスコードで 400番台を返しているログの数をメトリクスとしてカウントするようなことができます。メトリクスにできるものは、CloudWatch アラームを利用したアラーム通知を受けることができます。
考慮点
CloudWatch Logs のログデータは、永続的に保存することができますがコストがそれなりに掛かります。
アクセス頻度とコストバランスを考えると、ある一定期間を過ぎたログは S3 でアーカイブ管理するほうがよいです。サブスクリプションフィルターを利用すると、Kinesis Firehose 経由で S3 にログファイルをストリーム転送することができるので、CloudWatch Logs 側は1週間程度で消えるようにしておいてもログを S3 で確認できます。
S3 でも、例えば90日経過したログは Gracier に移動してしまえばよりコスト最適化を図れます。
まとめ
ログファイルを外出しできれば、いよいよ EC2 インスタンスの中にはプログラムだけが残るだけになるので EC2 インスタンスを使い捨てにしやすくなります。
AMI の作成については、以前にまとめた EC2 Image Builder を利用すると良いです。