【新サービス】AWS Fargate のネットワークについて考察してみた #reinvent

チャットボット特集

#AWS Fargate

#AWS

下田祐士

2017.11.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWS Fargate を利用することで、コンテナを実行するために必要だった EC2 (ECS) インスタンスの管理作業から解放されます。なお本サービスは、現状 US East (バージニア北部) リージョンのみで利用可能となります。

弊社の速報記事および ECS CLI からのデプロイ検証記事については、以下のリンクからご参照ください。

公式ドキュメントは、以下のリンクからご参照頂けます。

考察してみる

AWS Fargate のサービス概要については、AWS ブログにて既に日本語記事がございます。

AWS Fargate: サービス概要 | Amazon Web Services ブログ

本記事では、ネットワーク視点で考察を行うためサービス概要のネットワーキングに記載された内容を引用します。

全てのFargateタスクはお客様のVPCで稼働します。Fargateは、最近リリースされたネットワークキングのawsvpcモードをサポートし、タスクが起動しているsubnet内にそのタスク用のElastic Network Interfaceが確認できます。この機能により、下回りの基盤について心配する必要を無くしながらも、セキュリティグループ、ルーティングやNACLといったVPCの機能を通じてアプリケーションのネットワークポリシーについて全権限を持つことできるという、責任の分解が実現されます。

また、FargateはパブリックIP アドレスをサポートします。

まずはこちらをご覧ください。

Fargate にて、コンテナ（タスク）を１つ起動した状態です。

当然、EC2 (ECS)インスタンスは起動されておりません。

しかしながら、ENI が１つ利用（in-use）されている状況が確認できます。

既にご存知の方もおられるかと思われますが、これは最近リリースされた awsvpc モードによる ECS のタスクネットワーキング機能と同様のネットワーク構成に見受けられます。

参考として AWS ブログに掲載されている図を、お借りします。

ざっくり説明すると、コンテナ（タスク）内で起動されるプロセスのネットワークネームスペースに対してプライマリ ENI とは異なる ENI を構成し利用しています。これまでだと、以下のような問題点がありました。

bridge モードの場合、タスク専用のネットワークネームスペースを作成し Veth Pair および Linux ブリッジを介してコンテナに通信を転送していたためオーバーヘッドが発生する。
host モードの場合、ネットワークネームスペースを作成しないためオーバーヘッドの心配はない代わりに同一 ECS インスタンス内で同じタスクを稼働させることができない。(ポートが競合するため)

ECS のタスクネットワーキング機能を利用することで、これらの問題を解決するだけではなくタスク毎のセキュリティグループを構成することも可能になります。まさに、仮想環境を前提として稼働しているクラウド的な発想だと感じました。

さいごに

AWS に移行することで、物理サーバの管理作業が無くなりました。これからは、AWS Fargate を利用することでコンテナを稼働させるためのサーバーやクラスタの管理作業が無くなります。これまで、インフラ管理に必要だったリソースはアプリケーション開発等の有意義なリソースに利用することができるものと期待しています。

ではでは