# Amazon ECS Express Mode サービスのトラブルシューティング
このセクションは、Express Mode サービスをデプロイして管理する際に一般的な問題を特定して解決するのに役立ちます。
## デプロイに関する問題
### サービスが ACTIVE または DRAINING ステータスでスタックする
**症状:** DescribeServiceRevisions は、リソースがまだプロビジョニング中またはプロビジョニング解除中であることを示します。DescribeServices はデプロイが安定していないことを示します
**考えられる原因と解決策:**
+ **IAM アクセス許可が不十分** – タスク実行ロールとインフラストラクチャロールに、それぞれの管理ポリシーに示されているように必要なアクセス許可があることを確認します。
```
# Check if the role has the required managed policy
aws iam list-attached-role-policies --role-name ecsTaskExecutionRole
```
+ **イメージプルの失敗** – コンテナイメージが存在し、アクセス可能であることを確認します。
```
# Test image pull manually
docker pull 123456789012.dkr.ecr.us-west-2.amazonaws.com/my-app:latest
```
+ **ネットワーク接続の問題** – サブネットにインターネットアクセスまたは AWS サービスの Amazon VPC エンドポイントがあることを確認します。
+ **リソース制限** – アカウントに十分な Fargate キャパシティがあり、Service Quotas に達していないことを確認します。
**診断手順:**
1. DescribeExpressGatewayService を使用して、ServiceRevision の現在のサービスリビジョンを取得した後、DescribeServiceRevisions を使用してプロビジョニングまたはプロビジョニング解除のステータスを取得します。
1. 詳細なエラーメッセージについては、Amazon ECS コンソールのサービスイベントを確認してください。
1. コンテナポートが正しく設定されていることを確認します。
1. Amazon ECS と Fargate の AWS Service Quotas を確認します。
### タスクスタートアップの失敗
**症状:** タスクが開始に失敗する、または開始直後に停止する。
**一般的な原因:**
+ **アプリケーションエラー** – コンテナアプリケーションは、設定エラーまたはランタイムエラーにより終了します。
+ **ヘルスチェックの失敗** – アプリケーションが、予想されるポートまたはパスでのヘルスチェックに応答していません。
+ **リソース制約** – アプリケーションの CPU またはメモリの割り当てが不十分です。
+ **環境変数またはシークレットがない** – アプリケーションが必要な設定を使用できません。
**解決の手順:**
1. CloudWatch Logs でアプリケーションログを確認し、DescribeServiceRevisions からロググループ名を取得します。
```
aws logs describe-log-streams --log-group-name /ecs/express-service-my-app
aws logs get-log-events --log-group-name /ecs/express-service-my-app --log-stream-name stream-name
```
1. ヘルスチェックパスが HTTP 200 ステータスを返すことを確認します。
1. コンテナイメージをローカルでテストして、正しく起動することを確認します。
1. 必要に応じて CPU とメモリの割り当てを確認して調整します。
## 接続の問題
### ロードバランサー経由でアプリケーションにアクセスできない
**症状:** アプリケーション URL がタイムアウトまたは接続エラーを返す。
**トラブルシューティングのステップ:**
1. リソースのプロビジョニングが完了していることを確認します。
1. タスクが実行中であり、正常であることを確認します。
```
aws ecs describe-services --cluster my-cluster --services my-express-service
```
1. Application Load Balancer ターゲットグループのヘルスをチェックします。
```
aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:region:account:targetgroup/name/id
```
1. アプリケーションがコンテナ内の正しいポートでリッスンしていることを確認します。
## パフォーマンスの問題
### 応答時間が遅い
**症状:** アプリケーションの応答が想定よりも遅い。
**診断アプローチ:**
1. CPU とメモリの使用率をモニタリングします。
```
# Check CloudWatch metrics for the service
aws cloudwatch get-metric-statistics \
--namespace AWS/ECS \
--metric-name CPUUtilization \
--dimensions Name=ServiceName,Value=my-express-service Name=ClusterName,Value=my-cluster \
--start-time 2024-01-01T00:00:00Z \
--end-time 2024-01-01T01:00:00Z \
--period 300 \
--statistics Average
```
1. アプリケーションログにエラーやパフォーマンスの警告がないか確認します。
1. 自動スケーリングが負荷に適切に応答しているかどうかを確認します。
1. リクエスト分散のロードバランサーメトリクスを分析します。
**最適化戦略:**
+ リソースに制約がある場合は、CPU またはメモリの割り当てを増やします。
+ 先にスケールアウトするよう、自動スケーリングのしきい値を調整します。
+ アプリケーションコードとデータベースクエリを最適化します。
### 自動スケーリングが想定どおりに機能しない
**症状:** サービスが高負荷時にスケールアップしないか、低負荷時にスケールダウンしない。
**トラブルシューティングのステップ:**
1. 自動スケーリングポリシーとその設定を確認します。
```
aws application-autoscaling describe-scaling-policies \
--service-namespace ecs \
--resource-id service/my-cluster/my-express-service
```
1. CloudWatch メトリクスを確認して、スケーリングトリガーが満たされていることを確認します。
1. サービスにスケールする権限があることを確認します (IAM ロールを確認)。
1. スケーリングアクティビティとその結果を確認します。
## モニタリングとデバッグツール
### CloudWatch Container Insights の使用
Container Insights を有効にして包括的なモニタリングを行います。
```
aws ecs put-account-setting --name containerInsights --value enabled
```
Container Insights は以下を提供します。
+ CPU、メモリ、ディスク、ネットワークメトリクス
+ パフォーマンスモニタリングダッシュボード
+ ログの相関関係と分析
+ 異常検出