はじめに
システム開発推進部システム開発第4グループの岩田です。
最近、CloudFormationを使用してインフラの構築を行っています。 その際、複数人で開発を進める中で、CloudFormationのスタックをどのように分割すれば管理しやすくなるのかという課題に直面しました。 しかし、調べてみるとスタックの分割方法に明確な分割基準は無く、個人の裁量に委ねられているのが現状でした。
そこで本記事では、スタック分割における判断基準を提示したいと思います。 スタックを分割する方法を決めるきっかけになればと思います。
CloudFormationとは
CloudFormationとは、インフラ構築をコードで行うIaC(Infrastructure as Code)を実現するAWSのサービスのことです。
例えば、以下のようなインフラ構成も、
下記のようなコードで実現できます。
AWSTemplateFormatVersion: "2010-09-09"
Resources:
CloudFront:
Type: AWS::CloudFront::Distribution
Properties:
S3:
Type: AWS::S3::Bucket
Properties:
EcsCluster:
Type: "AWS::ECS::Cluster"
Properties:
⋮
IaCには、手作業による設定ミスを防ぎ、同じ環境を何度でも正確に再現できるといったメリットがあります。 また、CloudFormationはリソースの依存関係を自動で解決してくれます。 そのため、開発者はテンプレートファイルに利用したいAWSリソースを定義するだけでインフラ構築が可能になります。
スタックとは
スタックとは、AWSリソースの集合体のことです。1つのスタックには1つ以上のAWSリソースが関連付けられており、スタック単位でプロビジョニングされます。 つまり、スタックが同じAWSリソースは作成・更新・削除が同じタイミングで行われるということです。
AWS公式が提示するスタック分割方法
AWS公式のドキュメントには、以下の3つのスタック分割方法が提示されています。
1. すべてのリソースを1つのスタックにまとめる
小規模のサービスに関しては、すべてのリソースを1つのスタックにまとめておくのは良い手法です。 将来、リソースの追加でスタックの規模が大きくなった際に分割を検討すると良いでしょう。
2. 所有権による分割
複数人での開発において、グループの開発範囲ごとにスタックを分割する方式です。 例えば、DBを管理するチームとその他のインフラ(フロントやAPIなど)全般を管理するチームがある場合、DB関連のリソースをまとめたスタックと、その他のインフラをまとめたスタックに分けます。 チームごとにスタックを分けることで、スタックを更新した際に、他のチームのリソースに影響を与えずに済みます。
3. ライフサイクルによる分割
リソースの更新頻度や変更タイミングが似ているリソースごとにスタックを分割する方式です。 以下の2つは、ライフサイクルで分割する際の一般的なフレームワークです。
- 多層アーキテクチャー
多層アーキテクチャーとは、アプリケーションを機能単位でレイヤーに分けて開発/保守する方法です。Web3層システムなどが有名な構成例になります。 Web、API、DBを別のライフサイクルと定義して、各々を別スタックとして管理します。 サービス指向アーキテクチャー
サービス志向アーキテクチャーとは、システムの機能を独立したマイクロサービスごとにスタックを分割し、それらを組み合わせてシステムを構築する方式です。 マイクロサービスごとにスタックを分けることで、責任を分割して管理できます。
フローチャートでスタックの分割方法を決めよう
このように様々な分割方法が提示されているため、どれを採用すべきか迷ってしまいます。 そこで、分割方法を簡単に決められるフローチャートを提示したいと思います。 使用する際には以下の点に注意していただければと思います。
岩田
