既存のコードをLambdaで走らせる際に、検討すべき項目をまとめました。
既存のコードを持っていこうとすると、「Java/Pythonだから、そのまま動くでしょ?」逆に、「既存コードは全部書き換えないとでつらい」の中間くらいの手間になります。
実際には、全体的な構成を変える必要があるので、新しく作り直す方がいいと思います。
ですので、以下は、どうしても既存コードを持っていく必要がある場合のみご参考に。
Lambdaの特徴
立ち位置
- dockerなどコンテナーは、サービス単位で起動できるが、lambdaは、プログラム単位で起動できます。
- マネージドなコンテナーの機能限定版と言えます。
コーディングはロジックに集中できる
- Pythonの実行環境設定など、すべてLambdaがやってくれるので、ロジックに集中できます。
awsのイベントベースを学ぶ必要がある
lambdaを活用するなら、awsのイベントベースのやり方を学ぶ必要があります。
プログラム上の影響
以下はJavaのバッチの例です。
既存コードを持っていくとすると、キッカーとなるshellが内部でJavaのプログラムを呼び出すような構成は割とあると思います。
cron -> kicker.sh -> java program -cp ... -> read data file write ... -> check_output.shこの場合、lambda化で影響がある箇所は、これだけあります。 コンテナ化よりも変更箇所は多いと思います。
- cron(実行タイミングを管理)
- kickerとなるシェル
- javaへ渡すデータ作成をs3などにする
- java内のread/write処理(ラップするなど)
- ログ処理の変更
- check_output.sh(エラー検知など)
開発の各工程への影響
上記のように、アーキテクチャレベルで変更がかかるので、行程のほぼ全般に影響が出ます。
導入に関しては、できるだけ初期の設計段階で検討すべきです。
Lambdaの開発・テストは、サーバベースでやっていた時とは異なるので、その準備などにかかるコストも見込んでおく必要があります。
まとめ
lambda化はプログラムの修正以外にも工数がかかります。
lambda化すれば定型的な処理がほとんどAWS上の設定にできるので、かなり簡潔になります。
上記のメリットと、コストを比較検討するとよいかと思います。
0 件のコメント:
コメントを投稿