Serverless Conf Tokyo 2018 に来ている記事1 - AWS Session

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

http://tokyo.serverlessconf.io/

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

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

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

• Speaker
• Serverless の価値
• Undifferentiated Heavy Lifting
• Lambda がデてきた2014年
• Customer Serverless
• サーバーレスの効果
• サーバーレスの流れ
• Use Case
• ライフサイクルマネジメント
• パイプライン

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)