AWS Fargate
AWS Fargate:
■AWS Fargateって？
Amazon EC2を利用した場合、インスタンスの管理もしなければいけない。
コンテナ、アプリケーションのことだけを考えたい。
そのために、開発されたのが、AWS Fargate！
なので、
インスタンスの管理が不要になる。
そして、EC2の場合はリソースが余っていた場合も課金されていたが、本当に利用した分のみの課金となり、コスト削減へと繋がります。
要するにサーバレスの考え方です。
■EC2とのイメージの違い
事前にEC2インスタンスを起動し、ECSのタスクを起動していました。
Fargateではフルマネージドのフレーム転送など単純な処理をする（データプレーン）が提供されます。
そのため、事前にEC2インスタンスを起動する必要がありません。
インスタンスを気にせず、集中できるようになります。
■Fargateではできないもの
・Windowsはサポートされていない。
・GPUは提供していない。
・docker execなどを使った双方向（インタラクティブ）なデバッグ。
・EC2でいうスポットインスタンスや、リザーブドインスタンスのような価格モデル。
■Fargateのベストプラクティス
1.ストレージ
消えては困るデータは外部ストレージに残し、内部のコンテナには残さない！
では、なぜ内部に残さないほうがいいのか？
EBSやEFSをマウントすることはできないので、
書き込み可能なストレージは、
レイヤーストレージ
ボリュームストレージ
の２種類です。
これらは、停止したら消えてしまうため、アプリケーションをステートレスな作りにすることが重要。
2.ログ
Dockerコンテナ全般のこととなりますが、コンテナ内で動かすアプリケーションが吐き出すログのうち、後から参照する必要があるものを全て、標準出力、標準エラー出力に送ること。
FargateはネイティブにCloudWatch Logsへのログ書き出しをサポートしているため、これを利用しましょう！
CloudWatch Logsを使うための注意は２つ。
・タスク実行ロールに
logs:CreateLogStream
logs:PutLogStream
を追加する。
・CloudWatch Logs のロググループは、事前に作成しておくこと。
3.メトリクス
CloudWatch でネイティブに確認できるFargateのメトリクスはサービスレベルのCPU/メモリ/使用率。
なので、
以下のような情報をとりたい場合は、”タスクメタデータエンドポイント”を使う。
・タスクメタデータ：タスクについての情報が取れる。
・統計データ：CloudWatchの標準より詳細な情報が取得できる。
4.分散トレーシング
そもそも分散トレーシングて？
分散トレーシングとは、分散されたシステム間でやり取りされる処理を追跡するための考え方やそれを実現された仕組みのこと。
なので、
アプリケーションで発生したエラーや障害の原因特定。
パフォーマンス問題の原因特定
がしやすくなる。
5.スケーリング
”Target Tracking”を利用する！
設定そのものはメトリクスに対してターゲットとなる値を設定するだけです。
↓
この指定した値に近づくように Application Auto Scalling が自動的にサービスの DesiredCount（クラスターで実行する同時タスクの数）を調整してくれます。
6.サービスディスカバリ
サービス間の連携にELBとECSサービスディスカバリを利用する。
そもそもサービス間の連携て？
名前によって解決されたIPアドレスやポートをもつタスク間通信のことを指します。
2種類のサービスディスカバリがある。
・ロードバランサベース
ECSサービスがタスクを起動したうえで、ターゲットグループに登録し、停止時は登録を解除します。
呼び出し元のサービスは、ロードバランサのDNS名で宛先を解決する。
・DNSベース
ECSサービスがタスクを起動したうえで、レコードを追加し、停止時は削除します。
呼び出し元のサービスは、相手方の名前を使って宛先を解決する。
例として、
ユーザーからのアクセスがあるサービスはロードバランサベース、
VPN間のサービスについてはDNSベース
を使うなど。。。
更にセキュリティグループの設定が、ロードバランサベースとDNSベースで異なるので次の項目で見ていきましょう。
7.サービス間のアクセス制御
上記の通り、
DNSベースの場合は、相互のサービスを直接意識した設計となります。
ロードバランサベースの場合は、トラフィックを送受信するのが、ロードバランサになるため、ロードバランサのセキュリティグループで考慮する必要があります。。
■AWS Fargateって？
Amazon EC2を利用した場合、インスタンスの管理もしなければいけない。
コンテナ、アプリケーションのことだけを考えたい。
そのために、開発されたのが、AWS Fargate！
なので、
インスタンスの管理が不要になる。
そして、EC2の場合はリソースが余っていた場合も課金されていたが、本当に利用した分のみの課金となり、コスト削減へと繋がります。
要するにサーバレスの考え方です。
■EC2とのイメージの違い
事前にEC2インスタンスを起動し、ECSのタスクを起動していました。
Fargateではフルマネージドのフレーム転送など単純な処理をする（データプレーン）が提供されます。
そのため、事前にEC2インスタンスを起動する必要がありません。
インスタンスを気にせず、集中できるようになります。
■Fargateではできないもの
・Windowsはサポートされていない。
・GPUは提供していない。
・docker execなどを使った双方向（インタラクティブ）なデバッグ。
・EC2でいうスポットインスタンスや、リザーブドインスタンスのような価格モデル。
■Fargateのベストプラクティス
1.ストレージ
消えては困るデータは外部ストレージに残し、内部のコンテナには残さない！
では、なぜ内部に残さないほうがいいのか？
EBSやEFSをマウントすることはできないので、
書き込み可能なストレージは、
レイヤーストレージ
ボリュームストレージ
の２種類です。
これらは、停止したら消えてしまうため、アプリケーションをステートレスな作りにすることが重要。
2.ログ
Dockerコンテナ全般のこととなりますが、コンテナ内で動かすアプリケーションが吐き出すログのうち、後から参照する必要があるものを全て、標準出力、標準エラー出力に送ること。
FargateはネイティブにCloudWatch Logsへのログ書き出しをサポートしているため、これを利用しましょう！
CloudWatch Logsを使うための注意は２つ。
・タスク実行ロールに
logs:CreateLogStream
logs:PutLogStream
を追加する。
・CloudWatch Logs のロググループは、事前に作成しておくこと。
3.メトリクス
CloudWatch でネイティブに確認できるFargateのメトリクスはサービスレベルのCPU/メモリ/使用率。
なので、
以下のような情報をとりたい場合は、”タスクメタデータエンドポイント”を使う。
・タスクメタデータ：タスクについての情報が取れる。
・統計データ：CloudWatchの標準より詳細な情報が取得できる。
4.分散トレーシング
そもそも分散トレーシングて？
分散トレーシングとは、分散されたシステム間でやり取りされる処理を追跡するための考え方やそれを実現された仕組みのこと。
なので、
アプリケーションで発生したエラーや障害の原因特定。
パフォーマンス問題の原因特定
がしやすくなる。
5.スケーリング
”Target Tracking”を利用する！
設定そのものはメトリクスに対してターゲットとなる値を設定するだけです。
↓
この指定した値に近づくように Application Auto Scalling が自動的にサービスの DesiredCount（クラスターで実行する同時タスクの数）を調整してくれます。
6.サービスディスカバリ
サービス間の連携にELBとECSサービスディスカバリを利用する。
そもそもサービス間の連携て？
名前によって解決されたIPアドレスやポートをもつタスク間通信のことを指します。
2種類のサービスディスカバリがある。
・ロードバランサベース
ECSサービスがタスクを起動したうえで、ターゲットグループに登録し、停止時は登録を解除します。
呼び出し元のサービスは、ロードバランサのDNS名で宛先を解決する。
・DNSベース
ECSサービスがタスクを起動したうえで、レコードを追加し、停止時は削除します。
呼び出し元のサービスは、相手方の名前を使って宛先を解決する。
例として、
ユーザーからのアクセスがあるサービスはロードバランサベース、
VPN間のサービスについてはDNSベース
を使うなど。。。
更にセキュリティグループの設定が、ロードバランサベースとDNSベースで異なるので次の項目で見ていきましょう。
7.サービス間のアクセス制御
上記の通り、
DNSベースの場合は、相互のサービスを直接意識した設計となります。
ロードバランサベースの場合は、トラフィックを送受信するのが、ロードバランサになるため、ロードバランサのセキュリティグループで考慮する必要があります。。
コメント
コメントを投稿