Serverless Conf Tokyo 2018 に来ている記事1 : AWS Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

今年も場所が変わって、東京タワースタジオなのですが、例年よりこじんまりしています。周りにお店が少しはあるので、今までよりいいかも? (会場は古めですがこういうのでいい)

冒頭の吉田さんの挨拶のあと、AWSセッションで。これもAWSセッションのみ。

引用は私のコメントです。

Speaker

Keisuke Nishitani

@Keisuke69

Serverless の価値

ビジネスを生み出すこと。このビジネスの創出により集中するために、開発者が必要としているのは、より効率的、俊敏、スケーラビリティの高いサービス。

Undifferentiated Heavy Lifting

付加価値にならない、重い作業は小さくしたい。ビジネスロジックに集中したい。

Undifferentiated Heavy Lifting が大きいと価値が低い。(ランタイムや環境のセットアップ、プロダクションシステムのキャパシティの見積、モニタリング、スケーラビリティ確保、冗長化、認証認可、スロットリング)

Lambda がデてきた2014年

AWS の価値に、Working Backward (お客様の課題に向き合い)というのがあり、課題に対して検討して開発されたのがAWS Lambda。

Function
Event Driven
Never Pay for Idle
No Servers to manage

157機能が4年間でリリースされている。(非公開の改善はもっとある)

38% : すでに使っている (+7%) 37% : 今使っていない (-4%) 26% : 今後1年で使う

利用者のうち、69% がLamnda を使っている。

Customer Serverless

Quator ベースだと、ここ1-2年で利用が大きくなっている。はじめは、Web/Game などのアーリーアダプターが使っていたが、エンタープライズも使い始めている印象がある。

実際、ここ1-2年で事例の発表がエンタープライズからが多い感じ?

サーバーレスの効果

いわゆる Undifferentiated Heavy Lifting なことから解放されますよ。

サーバー管理が不要
- とはいえ、warmup だるいんだが....
スケーリング
- Consumption にするべきだよねー
組み込まれた高可用性
- ここはS3 障害などが無い限り、可用性はかなり高いのでよさある。
アイドル時のリソース確保不要
- Azure の Service Plan や Always On の違和感はこれ...
- 0円スタートが可能、かつシームレスに秒間x0000 req までスケールする

Try and Error がしやすいのは良い環境ではある。

サーバーレスの流れ

基本構成はイベント起点。

Event Source -> Funcrion > Service

OS のネイティブ機能もFunction で利用できて、各種言語が利用できるので、Lamnbda のための特殊な事情を考える必要はない。

TCP通信なら何でもok、UDP はだめよ。

Event Driven Service	Event Sources	Lambda Inside
AWS La,nda	S3	IoT
Amazon API Gateway	DynamoDB	....
AWS Step Functions	Kinesis Stream
AWS X-Ray	SNS

Dev Tools としての Cloud9 や Amplify、SAM、SAM CLIでのローカルテスト、Code Star、CodeCommit、CodeBuild、Code Deploy などの開発ツールも多く用意されている。

これに加えて、各種コミュニティのフレームワークがある。

Serverless とかあるけど、言語依存が厳しい.... Cloud Formation 嫌いだしやだなぁというのがおおい、このあたりはAzure Functions のほうが妥当感ある。Zipデプロイはかなりいいよね。

Use Case

アダストリア

WebAPI -> 新API Interface -> 旧API Interface -> API Server

Web API のこの流れは結構いいですね。開発上かなり柔軟になるし仕組みもシンプル。

Kinesis -> Lambda -> DynamoDB

ログやIoT でよく使われるやつ。

Web -> Stream -> Lambda -> DynamiDB/RDS/StepFunctions

こんなパターン

Lambda -> Lamnda (分類) -> S3 -> Lamnda -> RedShift
                           |                    
                         Athena

Firehorse 使っておけ感もあるけどね、

Firehorse -> S3 -> Lamnda -> RedShift
             |                    
           Athena

ライフサイクルマネージメント

Console : Cloud9がLambda のコンソールに埋め込まれているので、手動で書くのもあり
IDE : Eclipse/Visual Studio への統合
Cloud9 (Cloud IDE) 上でテスト、デプロイまでできるので、まぁ便利
コーティングを自分のエディタで + SAM CLI -> AWS Serverless Application Model

SAM CLI : ローカル環境にコンテナデプロいされてテストできるので、ローカルテストに便利。

基本的には、手動はCI/CDが厳しい。そこで、他のツールでパイプラインを組むのがいい。

まぁ実際ね、そしてこのパイプラインがめんどくさいはめんどくさい。

パイプライン

よくあるAWSの流れでいくと、Code Pipeline でCode Commit -> Code Build -> AWS SAMあたりが繋がれる。

現場、AWSはテストサービスは(Device Farm以外)ないので、3rd party 使うしか無い。

Source	Build	Beta	Test	Prodiction
GitHub / CodeCommit	Code Build	Cloud Formation (AWS SAM)	3rd Party	Cloud Formation (AWS SAM)

tech.guitarrapc.cóm

Technical updates