前処理の日時処理をFargateのスケジュール起動で試してみた
今回は AWS でコンテナを扱うサービスについて調べた内容をまとめます。
具体的には ECS、ECR、Fargate についてです。
調べた理由は AWS Lambda で難しい処理を行うのにコンテナを使った方法がよいと思ったからです。
やりたい処理はテキストの前処理です。最近取り組んでいるツイート分析システムで紹介した GiNZA を使った前処理を行うには Lambda では制限に引っかかって無理でした。
過去記事は以下になります。
- Python と Twitter API を利用したツイート収集方法
- AWS Lambda を使ったツイート収集システム
- Docker で GiNZA の環境構築をしてみた|SudachPy のユーザー辞書登録方法も紹介
- 前処理を行いツイートを WordCloud で可視化する方法
※ 情報が古かったり、間違い等がある場合があります。
ECS とは
ECS とはコンテナを管理するサービスです。よくコンテナオーケストレーションサービスなどとも呼ばれます。
複数のコンテナを手動で管理するのは大変なので ECS のようなオーケストレーションサービスが使われます。
ECS では以下のような構造でコンテナを管理します。
- ECS
- クラスター
- サービス
- タスク定義
- クラスター
クラスターというのは、サービスやタスク定義をまとめる単位です。
次にサービスは複数のコンテナを管理する単位です。例えば、Auto Scaling などでコンテナ数をコントールするのはサービスで管理できます。
タスク定義というのが実際のコンテナの設定部分です。 コンテナイメージは ECR にアップされているものを指定します。
Fargate とは
公式ではコンテナ向けサーバレスコンピューティングエンジンと言われています。
コンテナを使うにはコンテナをのせる場所が必要です。AWS ではコンテナをのせる場所として EC2 か Fargate を選択することができます。
EC2 の場合は EC2 の管理もしなくてはいけないというのがデメリットでしたが、Fargate の場合はホストマシンの管理が不要になります。
特別な理由がなければ EC2 より Fargate を使った方が楽です。ただし、料金については EC2 のほうがスペックあたりで比較すると割安です。
Fargate の料金は利用するメモリと CPU ごとに値段が設定されており、それらの稼働時間によって計算されます。
詳しい料金は公式サイトに記載されてます。
Fargate Spot
最近でたのがこの Faragate Spot。
EC2 のスポットインスタンスのようなものです。
なんと Fargate 価格から最大 70%割引で利用できるとのこと。
EC2 のスポットインスタンス同様に起動したタスクが中断される可能性があります。
Fargate Spot については情報が少ないですが、クラメソさんの記事が参考になります。
Fargate の使い方
コンテナを実行するまでの流れは以下になります。今回はサービスを使わずに単体のタスクを Fargate で起動することを想定しています。
図にある ECR は Docker コンテナレジストリです。DockerHub の AWS 版です。あらかじめ ECR でリポジトリで作成し、ローカルから Docker イメージを ECR に push します。
今回使用するイメージの Dockerfile は以下です。
# ベースとなるDockerイメージ指定
FROM python:3.7.7
# python package
RUN pip install --upgrade pip
RUN pip install pandas wordcloud emoji neologdn boto3
RUN pip install -U ginza
COPY ./preprocess/ /home/work
# コンテナログイン時のディレクトリ指定
WORKDIR /home/work/
CMD ["sh", "init.sh"]
この Dockerfile については、以下の記事に書いてある内容を少し変えただけなので、よければ参考にしてください。
また、公式ドキュメントにも詳しい Fargate に関する情報が記載されています。
クラスター作成
AWS コンソールから ECS を選択します。ECS ではまずクラスターを作成します。
今回は Auto Scaling を使わないので左上のネットワーキングのみを選択します。
次はクラスター名などを決めます。クラスターはこれだけで終わりです。
タスク定義
続いてタスク定義を行います。ECS からタスク定義のページにいき、新しいタスク定義の作成を選択します。
まず起動タイプは Fargate を選択します。
あとは、タスク実行ロールと必要なメモリと CPU を指定します。メモリと CPU はあとから簡単に変更できるので適当で大丈夫です。ECS のクラスターからメトリクスが見れるので、CPU の使用率などをみて調整すると無駄のない調整ができます。
そのあとは、コンテナの追加から ECR にあるイメージを指定して完了です。
注意として、タスク実行ロールにはコンテナで実行する処理に必要なロールを割り当てる必要があります。例えば、今回は S3 にアクセスする処理があるので S3 のアクセス権が必要です。
コンテナ定期実行
作成したクラスターを選択し、そこからタスクのスケジューリングを選び、作成を押下します。
まずスケジュールの実行間隔を定義します。やり方は CloudWatch Events と同じです。
その下でスケジュールで実行するターゲットを指定します。
起動タイプは Fargate で、さきほど作成したタスク定義を選択します。
セキュリティグループや VPC を選びます。新しい VPC を作成していなければデフォルトの VPC で大丈夫です。サブネットはプライベートなものを選択します。
画像ではパブリック IP が DISABLED になっていますが、ENABALED にしないとタスクが実行されませんでした。
boto3 は使える？
ローカルで boto3 を使う場合は aws cli を docker コンテナで使えるように認証を設定する必要があったので、ECS で boto3 を使う場合も必要なのか疑問でした。
結論としては、コンテナに aws cli のインストールや認証情報の設定は必要なかったです。適切なロールを作成し、タスクに設定すれば大丈夫なようです。
ただ、ローカルでの検証時には認証情報が必要になるので、コンテナに認証情報をなんらかの方法で渡す必要があります。
感想
Fargate が思っていたよりも安く使い勝手がよく驚きました。
普段から Docker を使って環境構築を行っていたので簡単に利用開始できたのもよかったです。
気になっているのは Fargate Spot がタスクのスケジュール実行で利用できているのかです。 一応キャパシティープロバイダーで Fargate spot の Base を１にして Fargate のほうを０にしてみました。 ログにはどちらのインスタンスが使われたのかが見当たらなかったので料金から逆算するしかないのかなーと考えてます。