2016年10月5日水曜日

AWS Lambdaで既存のコードを走らせる時に検討したいこと

既存のコードを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 件のコメント:

コメントを投稿