AWS Batch では内部的に Amazon ECSを使用しつつ、キューイングされた計算処理を順次実行していくようなバッチコンピューティング環境に特化しております。そのため、このようなバッチ処理であれば AWS Batch をご利用いただき、それ以外のインタラクティブな処理を含む汎用的なワークロードではECS及びECSの機能の一部であるFargateをご利用いただければと思います。

Django

Python用フレームワーク（フロントにも使えるけど）。
EC2やコンテナ上で常駐型で展開するのが基本だと思うが、AWS LambdaでAPI開発するときのパターン集によると、Lambdaにも組み込む事が可能らしい。
が、LambdaとDjangoの相性ってどうなの？？によるとあまり推奨され無さそう。

形態素解析

転置インデックスをする上でほぼ必須。各種ライブラリがあるが、言語データ部分のサイズが大きい。

GiNZA

形態素解析を始めとして各種自然言語処理が出来るpythonライブラリ。spaCyの機能をラップしてる（はず）なのでその機能は使える。
形態素解析エンジンにSudachiを使用したりもしている。

BERT

最近流行っている言語処理技術。これをベースにして各種ライブラリや技術が派生している。

Sentense-BERT

BERTを基本（？）にした文章ベクトルライブラリ。日本語対応された方が後述記事でその紹介をしている。
【日本語モデル付き】2020年に自然言語処理をする人にお勧めしたい文ベクトルモデル

考察

まず、アプリケーション部分の構成を考察し、それからビルドやモニタリング構成を考える。

CDN

CloudFrontを使用する。そこからweb静的リソースやAPIコールのオリジンへアクセスを分ける

フロントサイド

サーバーサイドレンダリングなどもあるが、今の時点ではVue.jsをビルドしたものを静的webリソースとして使用する。

サーバーサイド（API）

選択肢としては以下の構成が考えられる。

APIGateway＋Lambda
ECSでAutoScaling（Djangoでサービス化）
自然言語処理部分だけSageMakerホスティングサービス

この部分が今回の記事のメイン。ネットの情報である程度の判断は出来るが、実際に検証してみないとその技術が使えると判断できない。
使用したいと思うライブラリが普通のPythonライブラリに比べて容量が大きい事は解っていた（辞書データがある）。いくつかの技術検証の元、APIGateway＋Lambdaを使用する方向。

LambdaLayer

拙記事LambdaLayer用zipをCodeBuildでお手軽に作ってみる。で検証。記事ではnumpyを使っているが、本来使ってみたかったのは自然言語処理ライブラリのGiNZA。しかし、記事の手法でzip化してみたらLambdaクオータに引っかかる事が判明。もちろんアプリの共通ロジックには使える事は解った。しかし、LambdaをAPIとして使えるという判断にはならない。

Lambdaコンテナイメージ

拙記事LambdaでDockerコンテナイメージ使えるってマジですか？（Python3でやってみる）で検証。GiNZAの依存ライブラリ、Sudachiでsymlnkを使用している事から、コンテナ内とはいえLambdaで使えない事が判明。別の自然言語処理ライブラリを使うという選択肢もあれど、今後機能拡張の際にライブラリが縛られるのは避けたい。一度採用したライブラリが今後VerupなどでLambdaで使えないような事になったら大変なので採用は避けたい。
この時点までは、一旦Djangoでサービス起動できるコンテナを作成する方向で考えていた。

Lambda＋EFS

拙記事Lambda+EFSで自然言語処理ライブラリ(GiNZA)使ってみるで検証。
元々EFSはモデルデータなどの共有で使用予定だった。しかし、EFSをLambdaで使う事で大きなライブラリも普通に使える事を確認。
この検証を根拠に、Lambda+APIGatewayで対応する方向を考える事にした。

サーバーサイド（バッチ処理）

主に自然言語処理のベクトル計算に使用する想定。ECSのFargeteで構成。
APIと共通部分は出てくると思うので、その共有化も課題。

共通ストレージ

テナント毎の文書ベクトルファイルはAPI処理で素早くアクセスする必要がある。また、永続化してAutoScalingなどの複数API処理コンテナから共有される必要がある。ここはEFSの出番。

図にまとめてみる

CI/CDフェーズ

ビルド

モジュールとしての生成物はweb用（Vue）の静的リソース、ECS、Fargate用のコンテナイメージとなる。（Lambda使う場合にはLambda用コンテナイメージ）。これらをCodeBuildで行う。

デプロイ

CodeBuildを使って、githubで管理しているCloudFormationを展開。その際に使うコンテナイメージやS3リソースをビルドフェーズで生成する。イメージ図書いてみた（一方通行のフロー図は縦書きにしたいのは何でだろう）。

今後課題や残検証まとめ

今後の構成変更可能性を踏まえ、LambdaでもDjangoでも流用可能（プラットフォーム切り替えが可能な）様なソース構成
API部分とFargete部分で共通処理は単一ソース管理
モニタリング構成の検証
DBのマルチテナント構成の検証
ECSでのEFSのマウントの検証
SageMakerのホスティングサービスの使い方検証（特に値段）

まとめ

全体設計を何もしないまま部分から作り始めるのも、全体設計を最初から細かく時間をかけるのもリスクがあると感じた。
前者は、いざ各部分をつなげようとすると繋がらなかったりする問題。後者は実際に実装を進めて行くと、解消できない問題に出会うかもしれない問題。もちろんこれは既存の上手く行っているシステムがあればそのリスクを回避できるので前例は探しておいた方が良い。
今回の考察でも、一旦Lambdaを使うのを諦めたのだが、最近提供された機能によりサーバーレスが実現できる見込みが立った。しかし実装を進めていくと別の問題で諦めなくてはならなくなるかもしれない。モジュールなどの機能群やレイヤーで分け、それの入れ替えを容易に出来るようにしておくのが一番重要な気がする。
それらを踏まえてまとめると、AWSに限らないと思うが、システム構成を考える時には以下の点が重要と思う（当たり前と言えば当たり前だが）

扱うデータのサイズ、更新頻度、要求レイテンシーレベルを明確にしておく
ラフな全体図を描いた上で、主要ポイントは単体で技術テストをする（出来るっぽい、と思った事でも出来ない場合対応）
無駄なやり直しを防ぐ意味でも、各技術（主にAWS）のユースケースや制限を出来る限り事前調査
検証や実際に運用してみての問題が出てきた時の為に各モジュールは疎結合を意識する
そして実際に構成の実装を進めつつ、問題点の洗い出し及び改善（場合によってはその部分設計しなおし）

その他

アドベントカレンダー用という事で、公開日の１ヵ月前ぐらいから書き始めていたが、2020年12月15日に下記記事が投稿された。

技術選定/アーキテクチャ設計で後悔しないためのガイドライン

自分が今回の考察で漠然と感じていた事をより具体的に適切な図を使って説得力のある内容をふんだんに盛り込んだような記事。レベルの違いに衝撃を受ける。でも、自分のこの記事も状況に応じて技術を変える具体例の一つとして見てもらえると有り難い。

参考にさせて頂いたサイト

AWSオフィシャル

AWS Lambda のクォータ
 AWS SageMaker

皆さんの良記事

AWS LambdaでAPI開発するときのパターン集
 LambdaとDjangoの相性ってどうなの？？
AWS Lambda Layersでライブラリを共通化
 [アップデート]Lambdaのメモリ上限が10G、vCPUの上限が6に拡張されました！！ #reinvent
EFSにセットアップしたPythonライブラリをLambdaにimportする方法
 【日本語モデル付き】2020年に自然言語処理をする人にお勧めしたい文ベクトルモデル

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up