コンテナvsサーバレス？ どっちも取りたい！ 2024/6/14 JAWS-UG朝会 齋藤理沙子

自己紹介 齋藤理沙子 オンプレからクラウドまで、インフラまわり色々 2023 Japan AWS Jr. Champions 2023 Japan AWS All Certifications Engineers 好きなサービス：FSx for NetApp ONTAP

なぜコンテナvsサーバレスを 取り上げるのか DevOpsだったりクラウドネイティブだったり いわゆるモダンと言われるアーキテクチャを考えるとき、 どんな構成がいいんだろう、コンテナとサーバレス どちらが適している？ 違いを調べていくうちにこんがらがったり 新しいツールを発見したりした

コンテナとは • アプリケーションの実行環境をパッケージ化したもの • インフラストラクチャに依存しないため、 異なる環境間で移行が容易 • 軽量で起動が高速と言われることが多い (軽量なベースイメージを使ったり遅延読み込みを使ったり工夫は必要) • 環境を更新する場合、新しいコンテナに置き換える

AWSのコンテナサービス …といったらどんなサービスを思い浮かべるでしょうか

AWSのコンテナサービス …といったらどんなサービスを思い浮かべるでしょうか コンテナオーケストレーションのECS・EKS コンピューティングオプションのFargate・EC2 コンテナレジストリのECR クラウドリソース検出でCloud Map などなど

サーバレスとは • サーバを意識しなくてよい • AWSのサービスであれば、Lambda, SQS, API Gatewayなどが サーバレスサービス • Lambdaなどサーバを意識せずにコードを実行するサービスは FaaS(Function as a Service)と呼ばれることもある • 基本的に利用した時間分だけ課金される

コンテナやサーバレスを使った アーキテクチャの種類 モノリス(例：EC2+EBS) マイクロサービス(例：ECS+RDS) サーバレス(例：Lambda+DynamoDB) 出典：AWS「外部から AWS のバックエンドサービス利用を実現する仕組みをグラレコで解説」 https://aws.amazon.com/jp/builders-flash/202004/awsgeek-api-gateway/ VM=モノリス、コンテナ=マイクロサービスとは限りませんが、 マイクロサービス化する目的に高速な開発を実現する、があれば マイクロサービスとコンテナの相性は良いと思います

それぞれのアーキテクチャのイメージ モノリス マイクロサービス サーバレス

コンテナvsサーバレス あくまで目安ではあるが、 • Lambdaの実行時間が15分という制約があるため、 実行時間は15分に収まるか • どのくらいポータビリティにこだわるか …から考えることが多い

こんがらがったサービス1 ECS/EKS on Fargate

Fargate • コンテナ向けのサーバレスコンピューティングサービス • コンテナの実行環境にあたる部分 • ユーザがCPUとメモリを指定できる

ECSのタスク定義 Fargate起動タイプでもCPUとメモリを定義できる

ECSのタスク定義 Fargate起動タイプでもCPUとメモリを定義する

(余談)クラスターにFargateタスクとEC2タスクを 共存させることも可能 ECSクラスター作成時のキャプチャ

on EC2とon Fargateの違い キャパシティープロバイダー キャパシティープロバイダー…ECSタスクに対するインフラのスケーリング管理を行う on EC2のキャパシティプロバイダーはAuto Scaling Groupと紐づける必要がある On EC2の キャパシティプロバイダー

on EC2とon Fargateの違い キャパシティープロバイダー ECSタスクに対するインフラのスケーリング管理を行う on Fargateのキャパシティプロバイダーで、ユーザ側で作成・管理の必要なし サービス・タスク作成時に選択すればOK OnFargateの キャパシティプロバイダー

こんがらがったサービス2 コンテナイメージからLambdaデプロイ

AWSのコンテナサービス …といったらどんなサービスを思い浮かべるでしょうか コンテナオーケストレーションのECS・EKS コンピューティングオプションのFargate・EC2 コンテナレジストリのECR クラウドリソース検出でCloud Map

AWSのコンテナサービス …といったらどんなサービスを思い浮かべるでしょうか コンテナオーケストレーションのECS・EKS コンピューティングオプションのFargate・EC2 コンテナレジストリのECR クラウドリソース検出でCloud Map 関数をコンテナイメージとしてデプロイ Lambda

コンテナサービス一覧にLambdaが… 出典：AWS コンテナサービス(https://aws.amazon.com/jp/containers/)

コンテナイメージから関数デプロイ • コンテナイメージとして関数コードをデプロイできる • AlpineやDebianなど非AWSのベースイメージからのデプロイも可能 (Lambdaとの互換性のため、ランタイムインターフェイスクライアントを イメージに含める必要がある) • デプロイ可能なイメージはMax10GBであり、機械学習など 依存関係が大規模なワークロードにも対応しやすい 参考：Amazon Web Servicesブログ「AWS Lambda の新機能 – コンテナイメージのサポート」 https://aws.amazon.com/jp/blogs/news/new-for-aws-lambda-container-image-support/

コンテナイメージから関数デプロイ手順 Pythonコードの場合 • EC2にDockerを入れる • lambda_function.py(関数コード)を作成する • requirements.txt(インストールするパッケージ)を作成する • Dockerfileを作成する • イメージをbuild • ECRにpush • ECRのコンテナイメージからLambda関数を作成する

Dockerfileの例 FROM public.ecr.aws/lambda/python:3.12 COPY requirements.txt ${LAMBDA_TASK_ROOT} RUN pip install -r requirements.txt COPY lambda_function.py ${LAMBDA_TASK_ROOT} CMD [ "lambda_function.lambda_handler" ]

コンテナイメージからLambda関数を デプロイすると マネジメントコンソール上でコードを編集できない コンテナイメージからデプロイしたLambda関数をマネコンで開いたときの画面

素早いコンテナデプロイのために コンテナイメージから容量の大きい関数をデプロイできるが、 素早いスケールと起動も確保したい

素早いコンテナデプロイのために コンテナイメージから容量の大きい関数をデプロイできるが、 素早いスケールと起動も確保したい Lambdaの内部でやっていること(一部) ブロックレベルでコンテナイメージを読み込み、 チャンクに分割して重複排除 小さいチャンクはfalse-sharingを最小限に抑えることができ、 ランダムアクセスパターンに対応しやすくなる 大きいチャンクはメタデータのサイズを減らし、データロードに必要な リクエスト数を減らすことができる チャンクの大きさはユーザの使い方次第で将来的に変更されるかも Brooker,M. Danilov,M. Greenwood,C. and Piwonka,P. (2023).On-demand Container Loading in AWS Lambda https://www.usenix.org/conference/atc23/presentation/brooker

Lambdaの裏側 出典：AWS「Lambda開発者ガイド Lambda実行環境」 https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtime-environment.html 実行環境

実行環境(Execution Environment) • ステートレス • 実行が終わった瞬間即破棄ではなく、retention periodの後 破棄される • 継続的に呼び出される関数であっても数時間おきに終了され、 ランタイムのアップデートとメンテナンスが行われる 出典：AWS「Lambda開発者ガイド Lambda実行環境」 https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtime-environment.html

Lambda拡張機能 モニタリングツールを入れたり移植性を上げることができる 実行環境で独立したプロセスとして実行されるものもあれば、 ランタイムプロセスの一部として実行されるものもある 拡張機能の例：Lambda Web Adapter Lambda関数がHTTPを話せるようにする (WebアプリをLambdaに持ってきやすくなる) Dockerfileに1行COPY文を入れるだけで使える

広義だとコンテナサービスそのものも サーバレスだったり 「サーバレスは、アプリケーション実行環境がマネージドサービスと して提供されたもので、一般的には実行された分や秒といった時間だけ 課金されるオンデマンドなサービスです。 広義でのサーバレスは、コンテナサービスも含めてサーバを意識させない マネージドサービス全体を指すこともありますが、 ここではアプリケーション実行環境としてのサーバレスを指します。」 出典：デジタル庁「マネージドサービス、コンテナ、サーバレス」 https://digital-gov.note.jp/n/n9e0354fadc2d

こんがらがった先に コンテナとサーバレスはハッキリと分けられるものではなく、 排他的なものでもない サーバレスサービスの独自仕様や大規模なコードを動かせない、 といった制約がアップデートやツールで緩和されることもある インフラをあまり意識しないでコンソールポチポチで サービス使えるけど、その裏に思いを馳せるのも面白かったり