tech.guitarrapc.cóm

Technical updates

Amazon Athena で S3 Access Log を分析する

re:Invent 2016 は AWS の利用が一段回上に上がる素晴らしい発表が多かったです。さて今回取り上げるのは Athena です。

すでに素晴らしい資料があるのでそちらをご参照ください。ざっくり個人的な理解は、Google BigQuery の AWS版 という雑な印象です。

www.slideshare.net

data.gunosy.io

今回は S3 を Static website hosting している場合の S3 アクセスログを Athena で分析してみましょう。ELBとか CloudTrail はあるのに、S3 Access Log の記事見つからないものですね。

なお、この記事は以下のフォーマットを対象にしているため、フォーマットが将来変更された場合に動かないことがありえます。あらかじめご了承ください。

docs.aws.amazon.com

1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd hogemogeTestTest.contoso.com [07/Dec/2016:05:59:12 +0000] 191.1.1.2 1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd 667C2B96205F407E REST.GET.VERSIONING  - "GET /hogemogeTestTest.contoso.com?tagging HTTP/1.1" 404 NoSuchTagSet 285 - 45 - "-" "S3Console/0.4" -

目次

S3 バケットの状態

Athena は US East (Virginia)US West (Oregon) のみで選択できるサービスですが、対象となるS3 はその制約がありません。当然ですね。

さて、Athena の対象となる S3 バケットを Static website hosting として用意します。

Logging を有効にしておいて事前にログが吐かれた状態にしましょう。今回は、BucketName/logs に吐くようにしました。

このような構成だと思ってください

バケット名 ログパス
hogemogeTestTest.contoso.com logs/

この状態で logs フォルダをみると.... 絶望ですね。これを手やAPI で見ようというのは人間のやることではなくなりました。Athena を使うのです。

Athenaの処理

さて分析対象が定まったので Athena にDBとテーブルを用意して分析しましょう。作成する内容は次の通りですね。

対象バケット名 Athena データベース名 Athena テーブル名
s3://hogemogeTestTest.contoso.com/logs/ s3_AccessLogsDB hogemogeTestTest_contoso_com

対象バケット名ですが、作成ウィザードではリージョンが必要そうなブランク欄の薄い灰色表示ですが、リージョンは不要です。

では早速見てみましょう。今回は パーティションを省いてクエリ (HiveQL) のみで一気に行きます。

データベースの作成

まずは、Athena でS3AccessLogに関するデータベース s3_AccessLogsDB を作成します。すでにデータベースがあるならここはスキップしていただいてok です。

gist.github.com

実行を待ってねと出て上手く作成できました。

ちなみにCREATE DATABASE 文と 後述する CREATE EXTERNAL TABLE 文は同時に投げることはできません。1つずつ投入、実行してください。

テーブル定義の作成

お次はテーブル定義です。

S3 Access Log のログ形式は次の通りです。

docs.aws.amazon.com

さてフォーマットのシリアライザはどれが使えるでしょうか。

一見 org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe がよさそうですがクォートのサポートがないので、今回は org.apache.hadoop.hive.serde2.RegexSerDe を使ってごりごりやります。

gist.github.com

2点だけ説明をした方がよさそうなので触れておきます。

  1. s3_accesslogsdb.hogemogeTestTest_contoso_com は、<データベース名>.<テーブル名> としています。お好きに書き換えてください
  2. Location にある s3://hogemogeTestTest.contoso.com/logs/ が対象の S3バケット名です

これで実行すると、上手くテーブルが作られたはずです。

テーブルプロパティをみてみます。

適当なクエリで中身を見てもうまくいっていますね。

SELECT * FROM hogemogetesttest_contoso_com limit 10;

あとは任意のクエリで分析しましょう。

dev.classmethod.jp

まとめ

Athena がきたことでようやく S3 にエコシステムが出来てよかったですね!

ちょくちょく使ったりデータ量が多いなら パーティションを貼っておいた方が精神安定上いいと思います。

.NET Core on Lambda で Github 連携をSlack に飛ばしてみよう

私の中で Serverless ななんとかネタで鉄板なのが、Github の PRやIssue などの通知連携です。日々使っているものなのでついつい。

もちろん過去にも Lambda + Node.js や Azure Functions で作っています。

tech.guitarrapc.com

では .NET Core でもやってみましょう。

目次

連携の流れ

Azure Functions では、Azure Functions の Secret と URL を直接 Github Webhook に入力して連携しました。ただ入力するだけ、簡単ですね。

AWS Lambda の場合は、Webhook を API Gateway で受けるようなことはせず、Amazon SNS を使って連携することが定番になっているように思います。Amazon SNS にするとAPI Gatewayと違ってレスポンスの受け口を作ったり管理する必要がほぼないのである意味ではとても楽です。*1

ということで今回もこの構成で行ってみましょう。Amazon SNS ではなく API Gateway で作っていたこともあったのですが余り楽しくないので推奨しません。

参考

Node.js で行われていますが、構成は同じです。

qiita.com

下準備

いきなりコードに行きたいところですが、まずは下準備からです。

Slack で Incoming Webhook を作成

Lambda の受け口となる Webhookの口を Slack に作成します。通知先の Channel を選んで適当にどうぞ。

slack.com

これで Lambda が送る先の Incoming Webhook URL が確定しました。URL は後ほどLambda の環境変数に仕込んでおくことになります。*2

SNS の Topic 作成

次にGithub が投げる先となる SNS の受け口 Topic を作成しておきます。作成する AWS Lambda と同一Region で作っておくといいでしょう。今回は ap-northeast-1 で作ります。

SNS から Create Topic を選んで

他の Topic と区別が付くようにつけておきましょう。

これで Topic を一意に示す Topic ARN が定まります。Github で入力するので把握しておきましょう。

今回は仮に arn:aws:sns:ap-northeast-1:123456789012:githublambdawebhook だったとします。

Github から SNS に投げる限定権限の IAM 作成

Github の Application Integrations を使った Amazon SNS では IAM の access key / secret key を直接入れることになります。

ということで指示に従って SNS を投げることができるsns:Publish権限だけの IAM ユーザーを作成しておきます。

ポリシーの Resource には、先ほどの Sns ARN arn:aws:sns:ap-northeast-1:123456789012:githublambdawebhook を指定します。

あとはIAM User作成時、あるいは後ほどでも Access Key / Secret Key を取得します。Secret Key は作成時の画面でしか確認できないのでお気をつけて。

仮に、Access Key を accesskey12345、Secret Key を secretkey12345 と表現します。

Github に Amazon SNS との連携を組む

では、Github の連携させたいリポジトリの Settings 画面に行きましょう。

メニューから Integrations & services を選択します。

サービス一覧から Amazon SNS を選びます。

あとは、AWS で作成した SNS Topic の情報、SNS送信専用 IAM Userの Access Key、Secret Key を入れます。

項目 入力する内容 入力値の例
Aws Key SNS 専用 IAM User の Access Key accesskey12345
Sns topic 作成した Sns の TOPIC Arn arn:aws:sns:ap-northeast-1:123456789012:githublambdawebhook
Sns region 作成した Sns の Region。SNS Topicに書いてありますが入れます ap-northeast-1
Aws secret SNS 専用 IAM User の Secret Key secretkey12345

Integrations の Event を指定する

Github の Webhook を使わない Integrations & services で連携する場合の最大のめんどくさいポイントはこれです。

Github API の hook.json にあるとおり、Amazon SNS の デフォルト Event は Push のみです。

この変更は Web request でしかできないのでしかたいので cURL でやります。*3

対象とするイベントは、Webhooks で適当に決めます。

今回はIssue 処理時Issue コメント時Pull Request 処理時Pull Request レビューサブミット時Pull Request レビューコメント時 とします。

gist.github.com

API経由で変更をかける際に利用する Application Token は、Github ユーザー プロファイルから作成できます。admin:repo_hookadmin:org_hook を有効にしておけばいいでしょう。

qiita.com

Webhook の ID は、URLに表示されています。

events が期待通りに設定されましたか? cURL の設定時のレスポンスで確認できます。

残りは Amazon SNS と Lambda のつなぎこみですが、Visual Studioから Lambda コード反映時にまとめて設定できるので後述します。

お疲れさまでした、長い下準備もおしまいです!

C# で Github Webhook を受ける

Azure Functions で書いていたコードを使って書いてみましょう。

サンプルJSON

今回サンプルで利用した、SNS から送ってくるJSON は次のフォーマットです。これは Issue のサンプルなので、コードもIssue を想定したものとします。

gist.github.com

C# コード例

Issue が書かれたらSlack に飛ばすサンプルです。ほぼ Azure Functions のコードと違いはありません。

違いは2点のみです。

  • フィールドに AWS Lambdaの環境変数から SlackWebhookUrl というキーを探して URL をstringとして取得するようにします。パスワードとかそういうのは Lambda の環境変数で KMS 使って暗号化がいいですね
  • SNS Response のデシリアライズ処理が入っています

当たり前の注意点だけ

  • X-Github-Event がプロパティ名に利用できないので JSONPropertyとして指定しておきます
  • ただし、github のイベントJSONは issue だったり PR だったりでフォーマットが変わるので、そこは AzureFunctiosn 同様に dynamic で受けておきます

gist.github.com

今回は Issue に限定しましたが、適当に他のイベント対応も switch に達せばいいでしょう。*4

xUnit テスト

ごく単純な実行テストです。様々なイベントに応じた JSON パターンをここでテストするといいでしょう。

gist.github.com

ローカル実行

ローカル実行する場合は、buildOptions に emitEntryPointを true と設定してProgram.cs を適当に書きましょう。

  "buildOptions": {
    "emitEntryPoint": true
  },

gist.github.com

これで普通のコンソールアプリケーションとして検証できます。

アップロード と 環境変数 と イベントソース設定

そろそろ CI ほしいですが、まだいったんVisual Studio でやります。適当にアップロード先 Function を作成します。

冒頭で作成した Slack Incoming Webhook のURL を環境変数に入れるのもここでできます。便利。

ついでに、Amazon SNS を起点に Lambda を実行するので、Event Sources も設定してしまいます。

もちろん Web Console 画面からやってもok です。

テスト実行

ローカル実行やテストする場合は、OSの環境変数に Lambda に設定する環境変数と同じものを仕込んでおきます。

Isssue を適当に立ててコメントしてみます。

うまく Slack に通知されましたね。

テスト中の実行グラフも出ています。

失敗や成功のログも Cloud Watch Logs に出力されています。

まとめ

Azure Functions と比べると SNS が増えてるだけなのに手間が大きく違いますね!シカタナイとは言え、Github とのつなぎこみに特化対応している Azure Functions はこの面で圧倒的に便利です。ただ、.csx でやり続けるのとどっちがいいかというと、どうでしょうかねぇ。

さて、今回のサンプルも挙げておきます。参考になれば幸いです。

github.com

*1:最高とは思いません。IAM作るのいやぽよ

*2:Azure Functions の AppSettings と同様です

*3:別に PowerShell でも C# でもいいです

*4:大半のケースはたいした処理しないでしょう。

.NET Core on Lambda で Slack Slash Command を作ってみよう

さて、前回、前々回と .NET Core on Lambda の下回りを見てきました。

tech.guitarrapc.com

tech.guitarrapc.com

大事なパッケージ周りやデプロイについては別の機会にするとして、そろそろ簡単なコマンドをWebhook で投げて返してみましょう。ついでに Lambda の環境変数も触っておきます。

目次

サンプル

今回実装のサンプルとするのは、Azure Functions の時に見かけた Slack の Slash Command を作ってみたという例です。Slack の Slash Command 入力を起点に、Slack (Post) -> Azure Functions (コード実行) -> Slack という流れです。

blog.xin9le.net

API Gateway + AWS Lambda

AWS Lambda はステートを持たないイベントドリブンなアプリケーション実行環境です。そのため、Azure Functions と異なり単体では外部Webリクエストを受け付けたり返却することはできません。

そこで、Slack -> Azure Functions / AzureFunctions -> Slack に該当する接続部分にAPI Gateway を用いるのが定石となっています。今回もそれに従いましょう。

AWS Lambda のコード作成

.NET Core on AWS Lambda の最も使いやすいポイントは、ローカル実行環境の整備 と ふつうのC# (.NET Core)を普通にかけることです。今回は、Slack Slash Command が送られてきたら、Hello from Lambda .NET Core. と返させてみます。

gist.github.com

コードはごく単純です。

Slack Slash Command で返ってくるJSON を SlackSlashCommand クラスでデシリアライズしてLambda関数に受けます。あとは、&でつながれている入力文字列を分割して、=で区切られた Key/Value から 値を取得しています。

続いて、Lambdaの環境変数に埋めたトークンと送信されてきたトークンの一致を検証しています。本来なら、処理内部ではなく前段のAPI Gateway 時点ではじきたいのですが、API Gateway の APIキー指定が Header 利用で、Slack Slash Command の送信ヘッダをいじれないためシカタナイです。

最後に、Slack に対してレスポンスを返しています。

AWS Lambda のコードをアップロードと環境変数操作

Visual Studio からのアップロードにて、Lambda関数の環境変数も併せて調整可能です。

今回は、SlackSlashCommandWebhook としてLambda関数を作成しました。

Azure Functions でもそうでしたが、環境変数を利用することでコードから機微情報を除外できるのでとてもいいです。特に AWS Lambda は KMS による暗号化もかかっていて一定の安心感があります。環境変数については参考にできるサイトがいくつもあります。より詳しく知りたい方はこちらへ。

dev.classmethod.jp

API Gateway に API を作成

続いて、Slack の Slash Command (という名の Webhook) を受けるため API Gateway で APIを作成します。Slack の Slash Command は POST でリクエストできるので、GET ではなく POST にします。

先ほど作成した、Lambda関数 をバックエンドに指定しておいてください。これで次のような API Gateway の設定ができたと思います。

さて、Slack Slash Command は JSON ではなく application/x-www-form-urlencoded としてリクエストしてくるのですが、Lambda関数は JSON で入力されることを期待しています。そこで、Integration Request を調整して、リクエストボディから JSONを抽出して Lambda 関数に渡します。具体的に、次の通り入力します。

Content-Type 処理
application/x-www-form-urlencoded { "body": $input.json("$") }

これでAPI Gateway の設定が出来ました。Deploy API でス任意の環境にデプロイしてみましょう。

デプロイすると、API のURL が定まります。

Slack の Slash Command を作成する

API Gateway の URL が定まったので、Slack に Slash Command を作成します。URL欄には、API Gateway で作成した APIのURL を入れます。

準備できましたか?

早速実行してみます。

うまくいきましたね!

まとめ

従来 Node.js や Python、Java でやっていたことは基本的に .NET Core でも同様にできるでしょう。手始めに Slackを用いましたが、別の様々なサンプルの移行が簡単にできます。当然、Azure Functions で実装していたものは、ほぼそのまま移行できます。次はそのあたりを。

今回のコードサンプルも追加しておきます。

github.com

.NET Core on Lambda で テスト、ローカル実行、async/await、ロギングについて

さて、AWS Lambda の続きです。

tech.guitarrapc.com

Lambda というか サーバーレスに限らず、ローカル実行ができるか、言語機能の対応状況、ログ確認方法は開発の基本となります。NuGetパッケージの対応状況や他を見る前にざっと確認しておきましょう。

目次

テスト

新規プロジェクトとしてSimpleAsyncFunctionという名前で、AWS Lambda Project with Tests (.NET Core)で作成します。

with Tests を選ぶことで、xUnit によるテストプロジェクトが追加されます。あくまでもローカル実行ではなく、テストプロジェクトの追加であるということに気を付けてください。

前回同様、dotnet restore をして新規プロジェクトのパッケージを復元したら、Test Explorer でテストを実行してみましょう。Empty Project なので、全部大文字になることを期待していますので、適当に絶対に通らないテストも追加してみて失敗することを確認します。

gist.github.com

通らなかったところを、Assert.NotEqual("hogemoge", upperCase); にすれば当然通りますね。*1

いたって普通の xUnit テストと分かります。TestLambdaContextAmazon.Lambda.TestUtilities 名前空間に存在しますが、いい感じで扱えそうですね。

ローカル実行

Node.js においてローカルでイベント送信を検証するときには、_testdriver.js を作っていましたね。*2

aws.typepad.com

.NET Core 版のLambda は、単純なコンソールアプリです。そこで、project.json で buildOptionsemitEntryPointtrue にした上で、エントリポイントとして、ProgramクラスのMainスタティックメソッドを用意してあげればok です。

gist.github.com

Lambda内部の関数はローカル変数の状態が見えない

Program 内はローカル変数もバッチリです。が、Lambda 本体の関数においてはブレークポイントは貼れるもののローカル変数が見えません。Watch Window で変数を見ようとすると error CS0012: The type 'ILambdaContext' is defined in an assembly that is not referenced. You must add a reference to assembly 'Amazon.Lambda.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604'. となっています。

project.json でも Amazon.Lambda.Core は参照しているのですが、何じゃろほい...。

async/await しているときの注意

AWS Lambda は、async/await な関数でも呼べます。いいですね。とても嬉しいです。Logger を組まない限りは落ちることなくローカル実行できています。

gist.github.com

ただ、後述のロガーを仕込んでおいてローカル実行で .Result で待ち受けると nullぽります。

System.NullReferenceException: Object reference not set to an instance of an object.

これはProgram.cs の ローカル実行時に null ではなく LambdaContext を渡せばokです。具体的には次の記事に書きました。

tech.guitarrapc.com

async/await

サンプルがドキュメントにあります。

時間がかかる処理があるという前提で、Task.Delay を組んだメソッドを非同期に実行させるなら次のようになります。

gist.github.com

普通ですね。何も違和感なくつかえます。

ロギング

ロギングがどれだけスムーズかは開発効率に重大な影響を及ぼします。今回は最もシンプルで既定で設定されている CloudWatch Logs へのログ出力を見てみます。

C# からのログ出力は、3つあるとドキュメントにあります。

gist.github.com

確認してみると次の動作になります。

ロガー Lambdaコンソールでの出力 CloudWatch Logs への出力 Line出力の可否
Console.Write X O X
Console.WirteLine X O O
LambdaLogger.Log O O X
ILambdaContext.Logger.LogLine O O O
ILambdaContext.Logger.Log O O X

結果、私は ILambdaContext.Logger.LogLine を使うことが多いです。AzureFunctions と似てますね。

まとめ

テスト、ローカルデバッグ、async/await、ロギングと気になるポイントを見てみました。

なかなか素直な作りなので、安心ですね。.csx と違ってローカル実行に制限がほぼないのが素晴らしいです。

今回のサンプルもリポジトリに追加しておきました。

github.com

*1:意味はありませんがただの試しです

*2:_testdriver.jsではus-west-2リージョンがデフォルト は注意ですね

.NET Core on AWS Lambda がリリースされました

今年は非常にうれしいことが Azure と AWS 両方でありました。Azure Functions と .NET Core on AWS Lambda です。

これまで多くの AWS Lambda関数 (Node.js) と Azure Functions (C#) を書いてきましたがこれでようやく AWS Lambda に完全に寄せることができます。

早速 AWS Lambda で C# (.NET Core) を触ってみましょう。

目次

Lambda 上は Java と同じく dll をアップロード

Node と違い、Java 同様のdll を zip で固めてアップロードとなります。そのため、Lambda の画面でコードを直接触ることはできません。

ここは Azure Functions と違い直接コード修正にはなりませんね。ただし大事なのは、.NET Core をビルドした結果を挙げるという点です。Azure Functions ですぐに出会って今でも困るのが、「共通コードを参照した場合にローカルビルドを通せなくなるケース」や「.csx のためインテリセンスが非常に貧弱」という問題があります。*1

DLLをビルドしてアップロードということは、ローカル挙動が安定して、コンパイル、ビルドも安定するので個人的には十分に許容、嬉しいポインとのです。*2

C# (.NET Core) でコードを書いてみる

記事作成の現時点では AWS Document がないので、手探りで見てみましょう。ドキュメントが公開されたので参考にどうぞ。

環境は Windows 10 Pro + Visual Studio 2015 Enterprise です。

.NET Core 環境を用意する

まずは .NET Core の最新版をインストールします。手順通りにやっていきましょう。

Download .NET (Linux, macOS, and Windows)

インストール中...。

5分未満で完了すると思います。

Visual Studio Integration

AWS は Visual Studio Integration がかなり進んでいます。リソース管理にとどまらず、Node.js の Lambda 関数も書いています。

Lambda を C# (.NET Core) でVisual Studio で書くため、最新版の AWS SDK for .NET をダウンロード、インストールしましょう。インストール後に新規プロジェクト > Templates > Visual C# > AWS Lambda というのが新しくできています。

4つプロジェクトがありますが、今回はシンプルに関数を作ってローカルビルド > アップロードという流れでやるため「AWS Lambda Project (.NET Core)」 を使ってみましょう。

プロジェクト種別 説明
AWS Lambda Project (.NET Core) A project for creating a AWS Lambda Functions using .NET Core
AWS Lambda Project with Tests (.NET Core) A project for creating a AWS Lambda Functions using .NET Core
AWS Serverless Project (.NET Core) An AWS Serverless application uses the power of AWS Lmabda and AWS CloudFormation to build a cloud-enabled serverless application
AWS Serverless Project with Tests (.NET Core) An AWS Serverless application uses the power of AWS Lmabda and AWS CloudFormation to build a cloud-enabled serverless application

BluePrint の選択

4つのひな形が提示されています。今回は単純な Empty Function を作ってみます。

余談ですが、もし.NET Core のセットアップを忘れて、AWS Lambda Project を作ろうとすると次のエラーが出て作れないので注意です。この場合、前述した.NET Core の最新をインストールしてから、再度 Lambda プロジェクトを作ってみましょう。

もしも project.json のパッケージ復元でエラーが生じる場合

AWS Lambda (.NET Core) のプロジェクトを作って project.json でエラーが出る場合があるようです。*3

この場合、Amazon* とつくパッケージが解決できていない場合は、直接 nuget パッケージをインストールすればok です。例えば次のproject.json なら dotnet restore でパッケージを復元しましょう。*4

{
  "version": "1.0.0-*",
  "buildOptions": {
  },

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.1"
    },
    "Amazon.Lambda.Core": "1.0.0",
    "Amazon.Lambda.Serialization.Json": "1.0.0",
    "Amazon.Lambda.Tools": "1.0.0-preview1"
  },

  "tools": {
    "Amazon.Lambda.Tools": "1.0.0-preview1"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }
}

このコマンドを Package Management Console で実行でもパッケージは復元できます。*5

Install-Package Amazon.Lambda.Tools -Pre
Install-Package Amazon.Lambda.Core
Install-Package Amazon.Lambda.Serialization.Json

解決されれば、project.json のエラーが消えて、Function.cs もエラーが出ていないはずです。

この状態で何も編集せずビルドが通れば準備完了です。

サンプルコードの記述

雑に Console.WriteLine だけ追加してちょっとだけいじってみます。


[https://gist.github.com/guitarrapc/e21578a8c777993e97dae62e7f03ac8e:embed:cite]

アップロード

残念ながら今日発表された CodeBuild はC#をサポートしていません。

Build Environment – Language / runtime environment (Android, Java, Python, Ruby, Go, Node.js, or Docker).

AWS CodeBuild – Fully Managed Build Service | AWS News Blog

CI のことは次回以降にして、ローカルでビルドしてアップロードしてみましょう。

Node.js と同様に、「アップロードする対象のプロジェクトを右クリック -> Publish to AWS Lambda」 します。

資格情報などをいい感じにして

IAM Role に 必要な権限のロールを割り当てます。今回はただの実行なので lambda_exec_role でok です。

メモリは、いったんデフォルトのままで行きますが、Java と似た傾向と予想されます。性能に関しても後日確認してみましょう。

acro-engineer.hatenablog.com

ではUploadしてみてください。うまくいくと、Lambdaの画面を AWS Console を開かずに VS でFunction画面が開いてくれます。Event Source などもここにあるので、事実上のローカルからの直接実行です。

実行

そのまま Visula Studio から Invoke するか、AWS Console で実行してみましょう。

このとき、Node.js の時のように json でイベントを記述すると自動的にデシリアライズされてしまいエラーが発生してしまいます。

{
  "errorType": "JsonReaderException",
  "errorMessage": "Unexpected character encountered while parsing value: {. Path '', line 1, position 1.",
  "stackTrace": [
    "at Newtonsoft.Json.JsonTextReader.ReadStringValue(ReadType readType)",
    "at Newtonsoft.Json.JsonTextReader.ReadAsString()",
    "at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType(JsonReader reader, JsonContract contract, Boolean hasConverter)",
    "at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)",
    "at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)",
    "at Newtonsoft.Json.JsonSerializer.Deserialize[T](JsonReader reader)",
    "at lambda_method(Closure , Stream , Stream , ContextInfo )"
  ]
}

今回は、受ける引数を string としているので、"hogemoge" というストリングを送るようにします。うまく Response にかえって来ましたね。

任意のクラスを受けて実行する

次は string ではなく任意のクラスを用意して、外部から来た JSON を受けられるようにします。

想定する JSON は次のフォーマットです。

{"Str":"hogehoge","StrArray":["hoge","huga","foo"]}

対応するクラスは次の通りです。

public class SampleClass
{
    public string Str { get; set; }
    public string[] StrArray { get; set; }
}

ということで全体

gist.github.com

実行してみるとうまく取れていますね。

まとめ

まずは Hello World でした。次は Azure Functions で書いた処理をサクサク Lambda にもってきて紹介します。

今回の実装を含めて、AWS Lambda .NET Core (C#) の実装サンプルはリポジトリにあげていくのでよろしければどうぞ。

github.com

*1:個人的に C# を好んでいるのがインテリセンス強さなので、かなり嬉しくない副作用です。

*2:もちろん直接編集できる方がうれしいですが、副作用大きすぎるしむしろこれでいいです。

*3:わたしとか

*4:Private NuGet リポジトリを登録していたりすると dotnet restore に失敗するようです

*5:こちらなら Private NuGet リポジトリを登録していても影響ありません