# Amazon ECS Express Mode サービスのベストプラクティス
実稼働環境で Express Mode サービスを効果的に使用するためのベストプラクティスと推奨事項について説明します。
## セキュリティのベストプラクティス
### シークレットの管理
+ **シークレットに Secrets Manager を使用する** – Secrets Manager に機密データ (プライベートリポジトリやデータベース認証情報など) を保存します。
Secrets Manager のベストプラクティスの詳細については、「*Secrets Manager ユーザーガイド*」の「[Secrets Manager のベストプラクティス](secretsmanager/latest/userguide/best-practices.html)」を参照してください。
+ **保管時の暗号化を有効にする** – AWS サービスに保存されているときにシークレットが暗号化されていることを確認します。
Secrets Manager などのサービスを使用すると、AWS マネージドキーまたはお客様提供のキーを使用して暗号化できます。
+ **シークレットローテーションを実装する** – データベースパスワードと API キーの自動ローテーションを使用します。
Secrets Manager などのサービスを使用すると、Amazon Aurora や Amazon RDS などのサービスのシークレットローテーションを管理できます。
Express Mode サービスでのシークレットの使用例:
```
aws ecs update-express-gateway-service \
--primary-container \
‘{“environment”=[{“name”=“DB_PASSWORD”,”value”=“arn:aws:secretsmanager:us-west-2:123456789012:secret:prod/db/password”}, \
{“name”=“API_KEY”,”value”=“arn:aws:ssm:us-west-2:123456789012:parameter/prod/api-key”}]}’ \
```
### ネットワークセキュリティ
+ **機密アプリケーションにプライベートサブネットを使用する** – 直接的なインターネットアクセスを必要としないアプリケーションをプライベートサブネットにデプロイします。
推奨されるアーキテクチャの詳細については、「[Amazon ECS アプリケーションをインターネットに接続する](AmazonECS/latest/developerguide/networking-outbound.html)」を参照してください。
+ **セキュリティグループに最小限のアクセス許可を設定する** – インバウンドトラフィックとアウトバウンドトラフィックを必要なポートとソースのみに制限します。
Express Mode サービスのセキュリティグループのアウトバウンドトラフィックを制限するには、アウトバウンドルールを変更するか、次のコマンドを使用して、Amazon EC2 セキュリティグループコンソールでこれを直接編集できます。
```
aws ec2 authorize-security-group-egress
--group-id sg-xxxxxxxx \
--protocol tcp \
--port 443 \
--cidr 0.0.0.0/0
aws ec2 revoke-security-group-egress
--group-id sg-xxxxxxxx \
--protocol tcp \
--port 443 \
--cidr 0.0.0.0/0
```
+ **Amazon VPC フローログを有効にする** – セキュリティ分析とトラブルシューティングのためにネットワークトラフィックをモニタリングします。
VPC サブネットコンソールの Express Mode アプリケーションで使用中の各サブネットで有効にすることも、` aws ec2 create-flow-logs --resource-ids subnet-xxx` を使用することもできます。
+ **ウェブアプリケーションに AWS WAF を使用する** – 一般的なウェブエクスプロイトや攻撃から保護します。
これを有効にするには、ウェブ ACL を作成し、それを Express Mode サービスで使用される Application Load Balancer に関連付けます。コンソールで、WAF & Shield Service にウェブ ACL を作成し、Application Load Balancer に関連付けます。または、`aws wafv2 create-web-acl` と `aws wafv2 associate-web-acl --resource-arn ` を使用します。
## パフォーマンスとコンピューティングの最適化
### リソースのサイズ設定
+ **適切なサイズの CPU とメモリ** – アプリケーションのパフォーマンスをモニタリングし、実際の使用パターンに基づいて CPU とメモリの割り当てを調整します。
AWS Compute Optimizer は、Amazon ECS のタスクとコンテナのサイズに関する推奨事項を生成します。詳細については、「*AWS Compute Optimizer ユーザーガイド*」の「[What is AWS Compute Optimizer?](https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html)」を参照してください。
+ **アプリケーションのパフォーマンステスト** – アプリケーションが大規模かつ、指定されたスケーリングしきい値とリソース割り当てで動作することを確認するには、負荷テストを実行します。
### 自動スケーリング設定
+ **適切なスケーリングしきい値を設定する** – パフォーマンスが低下する前にスケーリングをトリガーする CPU またはメモリのしきい値を設定します。
サービスメトリクスのターゲット値は、Express Mode サービスコンソールで変更できます。
特にトラフィックに時間ベースのパターンが見られる場合は、予測的なスケーリングポリシーを追加することを検討してください。詳細については、「[Predictive Auto Scaling](AWSEC2ContainerServiceDocs/latest/shared/predictive-auto-scaling.html)」を参照してください。
+ **複数のスケーリングメトリクスを使用する** – CPU またはメモリとリクエストベースのスケーリング両方を使用して、より応答性の高いスケーリングを行うことを検討してください。
サービスに複数のポリシーを追加できます。Express Mode はデフォルトで 1 つを追加しますが、追加のポリシーをサービスに直接アタッチできます。
+ **タスクの最小数と最大数の制限を設定する** – コストを制御し、可用性を確保するために合理的な制限を設定します。
本稼働ワークロードの場合、初期テストが完了したら、3 つのアベイラビリティーゾーンで実行して、アベイラビリティーのベストプラクティスに従うことをお勧めします。Express Mode コンソールで**タスクの最小数**を更新するか、`update-express-gateway-service --scaling-target '{“minTaskCount”=3}'` を使用します。
### ヘルスチェック
+ **有意義なヘルスチェックを実装する** – 重要なアプリケーションの依存関係を検証するヘルスチェックエンドポイントを作成します。
**ヘルスチェックパス**は、Express Mode コンソールで更新できます。または、`update-express-gateway-service --health-check-path "/health"` を使用します。
アプリケーションのヘルスチェック形成の詳細については、「[ヘルスチェックの実装](https://d1.awsstatic.com/builderslibrary/pdfs/implementing-health-checks.pdf)」を参照してください。
+ **ヘルスチェックを軽量に保つ** – ヘルスチェックエンドポイントでの高価な操作を回避します。
例としては、外部 API コール、CPU またはメモリを大量に消費する操作、タイムアウトになる可能性がある長時間実行される操作などがあります。
+ **適切なタイムアウトを使用する** – 障害をすばやく検出しながら正常な応答時間を実現するヘルスチェックタイムアウトを設定します。
Express Mode のヘルスチェックタイムアウトは、Application Load Balancer ターゲットグループで設定できます。Amazon EC2 コンソールで、**[ターゲットグループ]** セクションに移動し、Express Mode ターゲットグループを選択します。**[ヘルスチェック]** タブを選択し、**[編集]** をクリックします。**[ヘルスチェックの詳細設定]** でタイムアウトを調整できます。または、`aws elbv2 modify-target-group --target-group-arn --health-check-timeout` を使用します。
+ **適切な HTTP ステータスコードを返す** – 正常な状態では 200、異常な状態では 4xx/5xx を使用します。
## 運用のベストプラクティス
### モニタリングとログ記録
+ **強化された Container Insights を有効にする** – CloudWatch の強化された Container Insights を使用して、Express Mode サービスアプリケーションを包括的にモニタリングします。
詳細については、「[Amazon ECS での Container Insights のセットアップ](AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS-cluster.html)」を参照してください。
+ **カスタムメトリクスを設定する** – ビジネスロジックのモニタリングのために、アプリケーション固有のメトリクスを CloudWatch に発行します。
詳細については、「*CloudWatch ユーザーガイド*」の「[カスタムメトリクスをパブリッシュする](AmazonCloudWatch/latest/monitoring/publishingMetrics.html)」を参照してください。
+ **ログの保持を設定する** – 適切なログ保持期間を設定し、コストとコンプライアンス要件のバランスを取ります。
Express Mode によって作成された CloudWatch ロググループは、有効期限が切れないように設定され、Express Mode サービスが削除されても保持されます。この設定は CloudWatch ロググループで調整できます。
+ **ダッシュボードとアラートを作成する** – CloudWatch のダッシュボードとアラームをプロアクティブなモニタリング用に設定します。
### デプロイ戦略
+ **ベイク時間を実装する** – Express Mode は Canary ベイク時間を実装して、問題のあるデプロイの影響範囲を減らしながらデプロイを安定させる時間を確保します。アプリケーションの安定化にさらに時間が必要な場合は、Express Mode サービスの Amazon ECS Service 定義で設定できます。詳細については、「[Creating an Amazon ECS canary deployment](AmazonECS/latest/developerguide/deploy-canary-service.html)」を参照してください。
+ **ロールバック手順を実装する** – 問題が発生した場合は、以前のバージョンにすばやく戻す計画を立てます。
有意義なヘルスチェックとアラームベースのロールバックはどちらもロールバックに役立ちます。Express Mode のカナリアデプロイ戦略を 4xx および 5xx トラフィックのアラームベースのロールバックと組み合わせると、アプリケーションコードまたは設定に障害が発生した場合に迅速にロールバックするようにデプロイをセットアップできます。