こんにちは。Opt Fitエンジニアの@KAZYPinkSaurusです。
弊社ではサービス構築にAWSを使用しています。
今回EC2インスタンスで運用しているサービスを一部ECSに移行しました。
その際インフラをTerraformを用いて構築したためご紹介したいと思います。
背景
一部サービスではGPUをもつEC2インスタンスで運用しています。
サービス拡大に伴いインスタンスが増えてデプロイ作業や管理が大変になってきました。
そこでECSに移行することにしました。
目標
運用コスト削減
- これまではEC2に直接デプロイしていたのでインスタンスごとに微妙に環境や設定が異なっていましたが、コンテナアプリケーション化を可能な限りインスタンス間の差を減らします。
可用性向上
- デプロイ時はインスタンス一つ一つに作業を行っていたため、多少のダウンタイムや作業者間で手順が異なると言ったことが起きていましたが、ECSのローリングアップデート機能を用いて最低限のダウンタイムでの更新をさせるようにします。
スケーラビリティ向上
- 1サービス1インスタンスからロードバランサーとECSのタスク数の調節で任意のインスタンス数で動くようにします。
- メトリクスからのタスク数のオートスケールは今回は行いません。
設計
要件を満たすためのインフラは以下のような構成になりました。
ECS FargateはGPU非対応のためECSのバックエンドをEC2とする構成になります。
ポイント
- キャパシティプロバイダ[1]にオートスケーリンググループを付けている。
- ローリングアップデート時に自動でインスタンスを作ったり消したりするためです。
- オートスケーリンググループに与える起動テンプレートがGPUマシンになっている。
- 運用するサービスはGPUを使います。
- 複数タスクをもつサービスに負荷分散をしたいのでロードバランサーを付けている
以下が構成図です。
オートスケーリングができるキャパシティプロバイダがサービスに紐づくことでタスク実行に必要なEC2が自動で起動したり停止したりします。
以下で3つのパートに分けて説明してきます。
実行環境
❯❯❯❯ terraform -v
Terraform v1.1.8
on darwin_amd64
+ provider registry.terraform.io/hashicorp/aws v4.25.0
マシンはM1のMacです。
詳細
ECS周り(クラスター/タスク定義/サービス)
ECSの核となる部分です。
細かいことを省けばクラスター/タスク定義/サービスがあればひとまずECSのサービスとして動くものになります[2]。
ロードバランサーを使ってリクエストをタスクごとに分散させたいのでサービスにロードバランサーのターゲットグループを紐付けています。
# ECSクラスター
resource "aws_ecs_cluster" "this" {
name = "クラスター名"
}
resource "aws_ecs_service" "this" {
name = "サービス名"
cluster = aws_ecs_cluster.this.name
task_definition = aws_ecs_task_definition.this.arn
desired_count = "希望するタスク数"
# サービスが失敗続きだったら一個前にデプロイ成功したリビジョンにロールバックする機能
deployment_circuit_breaker {
enable = true
rollback = true
}
deployment_maximum_percent = 200
deployment_minimum_healthy_percent = 100
health_check_grace_period_seconds = 30
load_balancer {
target_group_arn = "ロードバランサーのターゲットグループのARN"
container_name = "コンテナ名"
# コンテナが8000番ポートを受け付けるサービス
container_port = 8000
}
placement_constraints {
# インスタンスごとに 1 つのタスクのみを配置します
type = "distinctInstance"
}
lifecycle {
ignore_changes = [
task_definition,
desired_count,
capacity_provider_strategy,
# ブルーグリーン入れる場合はこちらを有効にする(ターゲットグループが切り替わるため)
# load_balancer,
]
}
}
resource "aws_ecs_task_definition" "this" {
family = "タスク定義の名前"
requires_compatibilities = ["EC2"]
network_mode = "bridge"
cpu = 4096
memory = 15742
execution_role_arn = "arn:aws:iam::${var.aws_account_id}:role/ecsTaskExecutionRole"
task_role_arn = "arn:aws:iam::${var.aws_account_id}:role/ecsTaskExecutionRole"
container_definitions = jsonencode([
{
# クラウドウォッチログ向けの設定
"logConfiguration" : {
"logDriver" : "awslogs",
"options" : {
"awslogs-group" : "ロググループ名",
"awslogs-region" : "リージョン",
"awslogs-stream-prefix" : "ログストリーム名に付けたいプレフィックス"
}
},
# コンテナの8000番ポートをEC2の80番ポートにマッピング
portMappings = [
{
hostPort = 80,
protocol = "tcp",
containerPort = 8000,
}
],
linuxParameters = {
capabilities = {
add = [
"SYS_ADMIN"
]
},
},
cpu = 4096,
# GPUを使うための設定
environment = [
{
name = "NVIDIA_DRIVER_CAPABILITIES",
value = "all"
}
],
resourceRequirements = [
{
type = "GPU",
value = "1"
}
],
secrets = [],
memory = 15360,
image = "イメージARN",
essential = true,
name = "コンテナ名"
},
])
}
ロードバランサー周り(ALB/リスナールール/ターゲットグループ)
サービスへのリクエストを分散するためのロードバランサー周りの設定です。
ECSのサービスをターゲットグループにひっつけて紐づくので、こちらにECSに関する設定はありません。
resource "aws_lb" "this" {
name = "ロードバランサー名"
internal = true # 内部向け
load_balancer_type = "application"
security_groups = var.security_group_ids
subnets = var.subnet_ids
enable_deletion_protection = false
}
resource "aws_lb_listener" "this" {
load_balancer_arn = aws_lb.this.arn
port = 80
protocol = "HTTP"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.this.arn
}
}
resource "aws_lb_target_group" "this" {
name = "ターゲットグループ名"
port = 80
protocol = "HTTP"
protocol_version = "HTTP1"
vpc_id = var.vpc_id
deregistration_delay = 60
load_balancing_algorithm_type = "round_robin"
health_check {
enabled = true
healthy_threshold = 5
interval = 5
# 正常なときのステータスコード
matcher = "200"
# 任意のヘルスチェックエンドポイント
path = "/health"
port = "traffic-port"
protocol = "HTTP"
timeout = 2
unhealthy_threshold = 2
}
}
背後のEC2周り(キャパシティプロバイダー/オートスケーリング/起動テンプレート)
ECSの背後で動いているEC2に関する設定です。
キャパシティプロバイダーにオートスケーリンググループをひっつけてタスク数の要求に応じて背後で動いているEC2を増減させられるようにしています。例えば新しいバージョンをデプロイする際にサービスに支障が出ないようにタスク数を維持したままローリングアップデートさせるためには新たにEC2を起動して新しいバージョンを起動して古いバージョンのEC2を止めるという流れが必要になります。その際にEC2を増減させる役割をキャパシティプロバイダーはオートスケーリンググループと協力して行います。起動テンプレートというのは増やすEC2に関するテンプレートのことです。オートスケーリンググループにAmazonECSManagedと言うタグを付与してあげないとECSはクラスターをスケールするときにタグを管理できないので注意です。更に理解を深めたい方は以下を御覧ください。
resource "aws_ecs_cluster_capacity_providers" "this" {
cluster_name = "ECSクラスター名"
capacity_providers = [aws_ecs_capacity_provider.this.name]
default_capacity_provider_strategy {
base = 0
weight = 1
capacity_provider = aws_ecs_capacity_provider.this.name
}
}
resource "aws_ecs_capacity_provider" "this" {
name = "キャパシティプロバイダー名"
auto_scaling_group_provider {
auto_scaling_group_arn = aws_autoscaling_group.this.arn
managed_scaling {
maximum_scaling_step_size = 10000
minimum_scaling_step_size = 1
status = "ENABLED"
target_capacity = 100
}
}
}
resource "aws_autoscaling_group" "this" {
name = "オートスケーリンググループ名"
max_size = var.max_size
min_size = var.min_size
health_check_grace_period = 0
health_check_type = "EC2"
desired_capacity = 1
vpc_zone_identifier = var.subnet_ids
launch_template {
id = aws_launch_template.this.id
version = "$Latest"
}
tag {
# ECSにスケーリングをお願いするために必要なタグ
# https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/cluster-auto-scaling.html#update-ecs-resources-cas
key = "AmazonECSManaged"
value = ""
propagate_at_launch = true
}
lifecycle {
ignore_changes = [
# キャパシティプロバイダが必要に応じて変更するため
desired_capacity,
]
}
}
resource "aws_launch_template" "this" {
name = "起動テンプレート名"
iam_instance_profile {
arn = var.iam_instance_profile_arn
}
image_id = "好きなami"
# GPUインスタンス
instance_type = "g4dn.xlarge"
key_name = "認証用の鍵名"
vpc_security_group_ids = var.vpc_security_group_ids
# ECS起動時に実行するスクリプト
user_data = base64encode(templatefile("<ユーザデータのパス>/user_data.sh", { cluster_name = var.cluster_name }))
}
#!/bin/bash
# EC2をECSのクラスターに紐付けるために必要な設定
echo ECS_CLUSTER=${cluster_name} >> /etc/ecs/ecs.config;
さいごに
初めてのTerraformでECS構築は覚えることが多くて大変でした。
全体像を理解するまで結構試行錯誤しましたが運用コストと特にデプロイコストが大幅に下がったので作ってよかったなと思っています。
今後はブルーグリーンデプロイやタスクのオートスケーリングも検討していけたらと思います。
参考
今回の構成と共通する部分が多く非常に参考になりました。
🔔採用情報
ジム施設向けDXソリューションGYMDXではエンジニアを積極採用中です。
ジュニア層のエンジニアからリーダー職まで幅広く募集しています。
2022年7月にプレシリーズAラウンドにて資金調達を実施しました。
リードエンジニア
バックエンドエンジニア
「AIでジム運営が180°変わる」ジム施設向けDXソリューションGYMDXを展開する、株式会社OptFitのテックブログです！エンジニアを積極採用中！カジュアル面談も歓迎！お気軽にご連絡ください！
Discussion
とても参考になりました！ありがとうございます。
varで参照しているその他のリソースのコードも見れるとより嬉しいかなと思いました！