こんにちは！freeeでエンジニアをしている @toshi0607 です。アイコンよろしくnyanchuと呼ばれています。

Microsoft PlatformというチームでC#、WPF、Xamarinなどを使ってデスクトップアプリを開発しています。

この記事はfreee develpers Advent Calendar 2017の21日目です。

デスクトップアプリから送信するログファイルの処理をAWS Lambdaを使って行うようになりました。

この記事では導入の経緯や工夫したことについて紹介します。

段階的導入

最終的にLambdaを導入することを目指しつつ、ストレージへのログファイルのアップロードを非同期化することから始まりました。

まずはアーキテクチャの変遷をご覧ください。

Phase0

f:id:s_toshi0607:20171212230919p:plain

アプリからAPIサーバに複数のログをzipで固めて送信しています。

最初zipの中身をAPIサーバで1ファイルずつAmazon S3にアップロードしてからアプリにレスポンスを返していました。

そのため、ファイル数によってはタイムアウトしてしまうことがありました。

クライアント、サーバ両面から様々なアプローチを行いましたが、zip展開処理の非同期化がもっとも効果的でした。

Phase1

f:id:s_toshi0607:20171212230949p:plain

既にRailsサーバーでの一部処理でResqueを利用していたため、当面Resqueで様子を見ることにしました。

ただ、下記の理由からよりスケーラブルなサービスとして切り出したいという思いがありました。

Resqueは弊社の色々な機能での非同期処理に利用されており、優先度をつけながら運用している
アプリからに限らずログファイル展開で活用する未来がなんとなく見えていた

Phase2

f:id:s_toshi0607:20171212231007p:plain

11月末にこのアーキテクチャで本番運用を開始しました。

メインタスクではなかったので、合間時間や開発合宿などで開発してきましたがとても楽しかったです！

zipの非同期展開処理ができるのは変わりませんが、誤解を恐れずに言うとイベント駆動でスケーラブルなアーキテクチャになりました。

S3にzipファイルをアップロードするイベントでLambdaを起動させています。

Resqueでの運用にまつわる悩みもいくつか解消できていたりします。

はい。

うぇーいwww（.NET core 1.0でついに本番リリースして運用始めた2日後）
/【速報】AWS Lambdaが.NET core 2.0とGolangをサポートします #reinvent｜クラスメソッドブログ https://t.co/5nozybVPp2
— かえる氏の闘争 (@toshi0607) 2017年12月1日

なぜC#（.NET Core）か？

実はインフラ周りだけではなく、サービスでLambdaをnode.jsで運用してたりします。 Real World Serverless

それでもC#で書こうとしたのには理由があります。

メンテナンス

僕が所属しているチームはMicrosoft Platformチームです。

普段C#でクライアントアプリを開発しているので、メンテナンスやレビューの観点から極めて親和性が高いと考えました。

Visual Studio

Windows

強い。AWS Toolkit for Visual StudioをインストールすればVisual Studio上でデプロイ可能。

Lambda用のプロジェクトテンプレートを使用すればローカル実行もテスト（xUnit）を介して可能です。

環境構築にサーバーレスなフレームワークを使わずよしなにやってくれます。楽です。

Mac

Windows版ほどのサポートはありませんが、Visual Studio for Macでもローカルデバッグ環境を楽に構築することができます。

Visual Studio for Mac（エディションは注意）
.NET Core 1 系（現在VS4Macインストール時に2系がインストールされる）
xUnit.NET 2 testing framework support（拡張機能から有効化）

を使用することで、xUnitをFunctoionのドライバとしてデバッグすることができます。

弊社ではMac使いが多いため、Mac向けのLambda環境構築や.NET Coreの出自など詳しめにドキュメントを準備しました。

いざ本番運用

.NET周りのサポートが手厚いLambdaですが、心配なことがありました。

実際本番で運用されている情報はほとんどなく、リリースしたらどんなことが起こるのだろう…？というものです。

しかし、実行環境がどうであれやることは変わらないはず。基本に忠実に次のようなテストや仕組みで準備を行いました。

リトライ

処理に失敗したときはAWS側で自動的に2回リトライしてくれます。

完全に委ねました。

通知

リトライに2回失敗したとき、エンジニアはそれを知る必要があります。

これもAWS側で準備されている仕組みですが、次の図のような構成にしました。

f:id:s_toshi0607:20171219204803p:plain

2回失敗時のDLQとしてAmazon Simple Notification Service（SNS）を選択しました。

通知先はシンプルにメールです。

Lambdaのトリガーになったイベントそのものがつぎのような形式で通知されます。

{"Records":[{"eventVersion":"2.0","eventSource":"aws:s3","awsRegion":"us-east-1","eventTime":"2017-12-22","eventName":"ObjectCreated:Put","userIdentity":{"principalId":"AWS:xxx"},"requestParameters":{"sourceIPAddress":"xx.xx.xx.xx"},"responseElements":{"x-amz-request-id":"1234567","x-amz-id-2":"xxxxx"},"s3":{"s3SchemaVersion":"1.0","configurationId":"ZipUploadedEvent","bucket":{"name":"xxxxx","ownerIdentity":{"principalId":"xxxxx"},"arn":"arn:aws:s3:::xxxxx"},"object":{"key":"xx/xx/54321-xxxx.zip","size":12345,"eTag":"abcde","sequencer":"12345"}}}]}