アジェンダ

AWS のコンテナ関連サービス

EC2 インスタンスがクラスタに登録されるまで

登録の流れ

Amazon ECS-optimized AMI と ECS コンテナエージェント

AWS Fargate

概要と EC2 クラスタと何が異なるか

before: ECS with Amazon EC2 仮想マシン上でコンテナが実行されている

after: ECS with AWS Fargate

仮想マシンの運用（OS パッチ当てなど）がなくなる

料金体系

割り当て CPU、メモリ設定で料金体系が決まり、稼働時間によって従量課金される。

ミニマムは CPU 256、Memory 512 GB

この値をめちゃくちゃ小さくしたら、ecspresso deploy を実行したときにエラーになった。タスク定義が間違っており、Fargate にはそんな組み合わせの設定ないでって怒られた。

• AWS 公式ドキュメント：Amazon ECS タスク定義の無効な CPU またはメモリエラーをトラブルシューティングする

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-cpu-memory-error.html

コンテナでの機密情報の扱い

コンテナから機密情報にどうアクセスするか

awsvpc ネットワークモード

ボリューム

EC2, EFS

タスクサイズ：cpu, memory のハード制限の設定

タスクのライフサイクル

サービスの Auto Scaling

タスクの起動に失敗したときの動作：サーキットブレイカーとロールバック

Q. タスクが起動に一定回数以上失敗したら再起動を止めることはできる？

（Claude 3.5 Sonnet の回答めっちゃ分かりやすかった）

はい、ECS サービスで一定回数以上タスクの起動に失敗した場合に再起動を停止する方法があります。これは「サービス自動スケーリング」の設定を使用して実現できます。具体的には、deployment circuit breaker と rollback の機能を組み合わせて使用します。

現在のサービス定義には既に deploymentCircuitBreaker が含まれていますが、これをより詳細に設定することで、望む動作を実現できます。

サービス定義を以下のように修正することで、タスクの起動失敗に対応できます：

{
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true,
            "rollback": true
        },
        "maximumPercent": 100,
        "minimumHealthyPercent": 0
    },
    "deploymentController": {
        "type": "ECS"
    },
    "desiredCount": 1,
    "enableECSManagedTags": true,
    "enableExecuteCommand": false,
    "launchType": "FARGATE",
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "assignPublicIp": "ENABLED",
            "securityGroups": null,
            "subnets": [
                "{{ must_env `SUBNETS` }}"
            ]
        }
    },
    "platformFamily": "Linux",
    "platformVersion": "LATEST",
    "propagateTags": "NONE",
    "schedulingStrategy": "REPLICA",
    "serviceRegistries": [],
    "healthCheckGracePeriodSeconds": 60
}

主な変更点と説明：

1. deploymentCircuitBreaker:

   • enable: true: Circuit Breaker を有効にします。
   • rollback: true: 失敗時に前のバージョンに戻します。

2. healthCheckGracePeriodSeconds:

   • これを追加することで、タスクの起動後、指定された秒数の間はヘルスチェックの失敗を無視します。これにより、アプリケーションの起動に時間がかかる場合でも、過早に失敗と判断されることを防ぎます。

3. maximumPercent と minimumHealthyPercent:

   • これらの値により、デプロイメント中のタスクの動作を制御します。現在の設定では、すべてのタスクを一度に更新することができます。

この設定により、以下のような動作が期待できます：

• タスクの起動に失敗すると、ECS は自動的に再試行します。
• 一定回数（デフォルトでは 10 分間で 10 回）失敗すると、Circuit Breaker が発動します。
• Circuit Breaker が発動すると、rollback: true の設定により、前のバージョンのタスク定義に戻ります。
• もし前のバージョンも失敗する場合、サービスは最終的にタスクの起動を停止します。

注意点：

1. 完全な停止を避けるため、少なくとも 1 つの健全なタスクを維持することを検討してください。
2. ログとモニタリングを適切に設定し、失敗の原因を迅速に特定できるようにしてください。
3. healthCheckGracePeriodSeconds の値は、アプリケーションの起動時間に応じて適切に調整してください。

これらの設定により、タスクの起動に繰り返し失敗した場合でも、サービスが無限にリソースを消費し続けることを防ぎ、前の安定したバージョンにロールバックすることができます。

healthCheckGracePeriodSeconds はロードバランサの設定をしているときのみ使用できるパラメータ

Error: /06 22:08:40 [ERROR] FAILED. failed to update service attributes: operation error ECS: UpdateService, https response error StatusCode: 400, RequestID: 1776c504-4f0a-45f4-b02a-a26b0927bd47, InvalidParameterException: Health check grace period is only valid for services configured to use load balancers

• ecs-service-def.json

{
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true,
            "rollback": true
        },
        "maximumPercent": 100,
        "minimumHealthyPercent": 0
    },
    "deploymentController": {
        "type": "ECS"
    },
    "desiredCount": 1,
    "enableECSManagedTags": true,
    "enableExecuteCommand": false,
    "launchType": "FARGATE",
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "assignPublicIp": "ENABLED",
            "securityGroups": null,
            "subnets": [
                "{{ must_env `SUBNETS` }}"
            ]
        }
    },
    "pendingCount": 0,
    "platformFamily": "Linux",
    "platformVersion": "LATEST",
    "propagateTags": "NONE",
    "runningCount": 0,
    "schedulingStrategy": "REPLICA",
    "healthCheckGracePeriodSeconds": 30
}