BEACHSIDE BLOG

Azure と GitHub と C# が好きなエンジニアの個人メモ ( ・ㅂ・)و ̑̑

C# で AWS Lambda から 別の AWS Lambda を呼ぶ

AWS Lambda から AWS Lambda を呼ぶ際の実装メモです。

(2017/10月時点 =.NET Core 1.0しかサポートしてない時点の話です)

Overview

 1 開発環境の準備 (その1)
 2 .NET Core 1.0 対応の .NET Standard 1.6 のクラスライブラリの作成(その1)
 3 簡易なクラスライブラリー実装(その1)
 4 Console プロジェクトの作成(その2)
 5 Autofac の実装(その2)
 6 AWS Labmda プロジェクトの作成(その2)
 7 AWS Labmda の環境変数を読み込む
 8 API Gateway から Lambda - プロキシ統合 の使用とか
 9 AWS Lambda から AWS Lambda の呼び出し(←今回ココ)
 10 AWS Lambda から CloudWatch Events の呼び出し

Lambda のプロジェクトを作るのはVS2017でテキトーに作っておくとして、本質的な部分にフォーカスしてメモっています。

Nuget パッケージのインストール

Lambda を呼ぶためのClientが提供されいますので、Nuget で取得します。

VSの上部メニューの ツール > Nuget パッケージマネージャー > ソリューションの Nuget パッケージの管理 を開き(クイック起動で起動した方が早いですがね..)、参照 を開いて検索で「AWSSDK.Lambda」と入力します。AWSSDK.Lambdaのパッケージが表示されるはずなので、対象のプロジェクトにインストールします(今回のバージョンは3.3.8.2)。

f:id:beachside:20171031180054p:plain


今回は、AWS Lambda のプロジェクトを作った時に生成されるエントリーポイントの FunctionHandler メソッド(Function.csの中)にだらだらとコードを書きます。

(仕事的な意味で普通に作るなら、DIを使って AmazonLambdaClient クラスに各種キーとかエンドポイントを設定したり、利用するサービスクラスに AmazonLambdaClient を登録してあげてるといい感じだと思っていますが今回は省略。)

実装

実装のイメージを雑に書くと以下の感じです。

  • リクエスト時の内容は、InvokeRequest クラスを使って設定する。
  • AmazonLambdaClient を使って AWS Lambda を呼ぶ。

サンプルとして、このLambdaで受け取った値をちょっと加工して、以前に作った Lambdaで関数名が「lambdaDemo1」を呼ぶのを簡単に書くとこんな感じ。

まず、適切なキーとかを14~16行目で入力しときましょう。

18行目で、メソッドの引数は、39行目で定義している DemoModel を使ってます。ここは用途に合わせて良しなに実装すればいいところですね。

23行目で、AmazonLambdaClientインスタンスを作っていますが、コンストラクターをたくさん持っていて色々な方法で初期化できます。使う前に見ておくと便利に活用できると思います。

f:id:beachside:20171031180708p:plain

25行目の InvokeRequet の作り方が、今回唯一メモっておきたかったこと。

  • FunctionName は、呼び出す関数名をセットします。
  • InvocationType は、何も設定しないと RequestResponse がデフォルトでセットされます。呼んだLambdaの処理が終わるのを待って戻り値を取得するようなときに使います。今回のように別の Lambda を呼ぶけど戻り値を取得する必要がない場合、つまりはFire & Forgetするときは、 Event をセットしてあげましょう。
  • Payload には、渡したいJsonを入れてあげればOKです。

ざっくりだとこれくらいで利用可能ですが、その他諸々詳しくは本家のドキュメントを...

docs.aws.amazon.com

実際にLambdaを呼ぶ部分は、32行目の AmazonLambdaClient クラスの InvokeAsync メソッドを呼ぶだけです。引数には、25~30行目で生成した InvokeRequet をセットして実行してあげればOKです。

おわりに

簡易なプログラムなら、今回のように Lambda のエントリーポイントで実装してもまぁいいと思います。

が、業務で使うようなガチなビジネスロジックがあってデバッグしたりテストコード書きたいとかなると、やはり過去の記事で書いたような、.NET Standard でサービスレイヤーのクラス作って、デバッグは ConsoleApp から実行してあげる方が格段に生産性は高いと感じます。

プロジェクトの最初から、DIや環境変数の利用をちゃんとやってサービスレイヤーも最初から分けて作ってあげることで、デバッグやテスタビリティの面で楽に開発できます(と、仕事でやってて感じました)♪

今回は、別のアカウント(AWS的にクロスアカウントっていうんですかね)の Lambda を呼ぶのは書いてないですが、Permissionsを考慮して良しなにやるとサクッとできます。