参加ServerlessConf Tokyo的备忘录

2 年 ago

雅, 悟

4 minutes

最后，根据演讲内容和现实情况进行了面板讨论，这让我头脑清晰地整理了一番，感觉很好。

主题演讲：采用无服务器计算，仅在必要时进行计算！

发展

immutable versions of functions
version / configuration, cloudwatch metrics / Per functions
alias to version: $LATEST / STABLE / TESTING

API GatewayのStagesに、それぞれに独立したendpointを指定できる

Stage Variables: ${stageVariables.lambdaVersion}でSTABLEを指定する

https://api.example.com -> STABLE

https://dev.example.com -> LATEST

亚马逊Echo

Alexa, the voice service that powers Echo
Alexa Skill Kit (ASK)
Skills can be powered by AWS Lambda

github.com/amzn/alexa-skills-kit-js
Demo: Echo -> ASK -> Lambda -> DynamoDB / Facebook Page Post

LambdaのTriggerにASKを指定

无服务器与本地应用程序的新闻服务（ニュースパス）

以《新闻通行证》为例的原生应用程序的无服务架构（链接：https://speakerdeck.com/ymatsuwitter/serverless-with-a-native-application-for-newspass）。

ニュースパス：システム間の糊付け、AWS Mobile SDK
監視：LambdaからSlackへの通知系
インターン企画：ハッカソンの評価システムをLambdaで構築

モバイル開発がなぜサーバレスに至ったか

かつてクライアントはViewだった
100台のサーバ <-> 1000万台のモバイルの世界での適切なリソース運用課題：クライアントのリソース活用（iPhone 7 Plusは数年前のMacBook Proと同等の処理能力？）

ログの加工処理など多くのCPUを要する処理がサーバサイドで行われている
処理自体はそれほど複雑ではなく、とにかく分散したい処理

プラットフォーム間の差分の吸収

概念としては共通だが、インターフェースがiOSとAndroidで異なるものの扱い
Push通知のトークンの扱いなど

サブシステムの認証認可問題
SDKを通じて、クライアントサイドのマシンリソース・ロジック実装の活用
サーバサイドはコアに集中し、多くのロジックをクライアント＋サーバレスに移してきた

Cognito

Cognito: AWSサービスへの認証認可（IAM Role）、remoteとsync可能なkey-value store
CognitoSyncとLambdaを組み合わせて設定値をElasticsearchに保存（ユーザー単位なので端末をまたがってSync可能）
Syncイベントをフック
Lambdaからイベントを後ろに渡すときは拡張性を考慮してSNSを挟んでおく

SNS

iOS/Androidのトークンの扱いの違いや配信方法の違いを吸収

Kinesis

アプリ内、すべてのイベント収集に利用
クライアントからSDKを通じて直接Kinesisへログ配送
ストリーム集計： EMR Spark Streaming -> RDS
バッチ集計： Lambda -> ログ用S3 -> Presto
Cookpad社製 Puree：クライアント向けログコレクタ（イベントをバッファリングしつつ非同期送信、OutputPluginを各自で実装できる）

陷阱与贴士

cognitoユーザとサービスユーザはイコールなのが（二重管理をすると管理が複雑）
ユーザの単位：Unauthorized Userはデバイス単位
SNSログイン
インストール・アンインストールの取り扱い

複数のSDKを初期化すると、認証が複数回叩かれ、同時にいくつもユーザが生成される

cognitoのユーザー生成が完了してから各種SDKの初期化を開始
SDKの裏にある処理の依存に気をつけ、どういった順序で扱うべきか考える

Cognito Syncの競合解決

conflictのfeedbackが発生する、conflictを解決しないと二度とsyncできない

Cognito SyncとLambdaフックの頻度

アプリ起動時にsynchronizeすると容易にLambdaの呼び出しが跳ねる（たとえばAndroidはpushを受けるとアプリが起動される） -> throttlingが発生

古いEndpointの扱い -> クライアントサイドで古いトークンに対応するEndpointを削除する

使用OpenWhisk（Bluemix）进行事件驱动和无服务器计算。

无限框架

Lamvery

使用Firebase进行无服务器Web应用程序开发。

Realtime DB
Authentication: OAuth
Hosting: SSL, HTTP/2、独自ドメインが無料で利用可能
Storage:Google Cloud Storageのバケットに格納される

mobile APP

Analytics
Notification
Test Lab
AdMob
Remote Config
Dynamic Links
Crash Reporting

bit.ly/demo-chat
Realtime database

online/offline
NoSQL database: 全データを1つのJSONに格納、データ構造がそのままREST APIに
更新系はpromiseを返す
transactionにも対応している

Hosting: dev/ staging/ prodはそれぞれ別のプロジェクトとして作成（そのための無料プラン）
メール送信： SendGrid / zapierを使えばサーバレスに

通过无服务器和微服务改变的游戏服务器开发

サーバレス：実行環境のコンテナが定期的に破棄される
システムはImmutableでStatelessであることが強制される -> スケーラビリティ・耐障害性

保守性

サーバレス化することで、インフラのマネジメントから解放される（Amazonに任せる）

価格優位性

インスタンス数の調整 -> 実際に関数が実行された時間に対して課金されるためキャパシティコントロールが不要

课题

Javaはコンテナ起動時のオーバーヘッドがとても大きい（4-8秒の起動時間、メモリ消費量も大）、コンテナが起動されていれば早いが、API Gatewayと組み合わせるのは厳しかった
ただしJavaは処理速度は圧倒的に早い
APIの受付にはpython/javascript、バッチ処理はJava

ステートフルなシステムを開発するのは難しい

コンテナはいつ破棄されるか分からないのでDB/KVSなどの外部リソースを使うことになるが、高速でコスト感がいい方法がない

DynamoDBは読み書きは高速ながらも、変数の読み書きレベルのIOを要求すると高価
Memcache/Redisはスケールしづらい
ファイルシステムを通して状態を持つと、コンテナが破棄されると一緒に消えてしまう

フレームワークが未成熟

无服务器的未来

仮想化：調達期間の短縮
IaaS：ハードウェアの管理から解放、必要なときに必要なだけサーバが手に入る
コンテナ:キャパシティの考え方がある（余剰リソースの管理が復活？？）
サーバレス：アイドルリソースが完全になくなる

无服务器环境中的可操作性

monitoring
deployment
security
networking

Cloud Foundry / Chef/ Docker
Show HN / , Inc. / Raging and Forking / Operability

使用Azure Functions的无服务器模式

App Service / WebJobs
Serverless / Binding
trigger / input / code / output

Kudu
価格体系： Dedicated / Dynamic

Dynamic 呼び出し回数、メモリ量 * 実行時間

do one thing, idempotent, finish as quickly as possible
Timer based processing： 15分ごとに不要データ削除
Azure service event processing: ファイルアップロード

Azure Logic Apps

twitter検索 -> logic apps -> azure functions -> slack

Azure stream analytics

由于IOT/GPS追踪平台采用了无服务器架构，所以我们只用了两个月就搭建完成了。

AWS IoT -> S3でもいいが、lambdaでノイズの削除などの加工を挟める（＋過去の経緯）

Publish
API + Management Console
Why Serverless

small start: ほぼ無料枠でサービスを実現 -> α版のサービスに助かる
scalability: 1,500台のデバイスからのpush成功（たとえば、都営バスの台数）
非機能要件、サーバメンテナンスが不要になり、実装に集中できた
自律的な開発
変更への柔軟な対応: Applicationベースでの疎結合化、既存のサービスに影響を与えずに機能を拡張できる

Pain Point

UIを伴うようなステートフルな機能は、割り切ってインスタンスを起動して対応（Spring Boot on Docker）
自律させすぎた結果、コードベースがバラバラに。。
1アプリの障害でサービス停止
ログのレベル感が大きい（今まではcatalina.outだけ見れば良かった感があったが）、統合的に監視・通知する仕掛けは必須（ruxit, pagerduty, slack）
ラーニングコスト：予知できない例外に対しては、Try & Errorするしかない（コンソールからパラメタを変える）

颠覆旧商业模式：一个无服务器创业公司的故事

Sam Kroonenburg and Pete Sbarski – The Story of a Serverless Startup from ServerlessConf

成本模型很好（用户只需根据自己使用的公司服务向AWS付费）

原则

Lambda is to compute, what S3 is to storage

write single-purpose stateless functions
design push-based, event-driven pipelines
create thicker, more powerful front ends

before

user interface
client side model binding
client side service layer
server side service layer
server side model binding
server side db mapping
database storage

after: Angular JS App Running in the browser across all devices

user interface
client side model binding
client side service layer
database storage
cloud functions

use third party services
How can I get started?

Book: “Serverless Architectures on AWS”

支持纸面浏览器的无服务器架构。

月間アクセス3億件、毎日約900件の記事を配信、有料会員50万会員
日経電子版 / 紙面ビューア（新聞と同じレイアウト、登録したキーワードを検索、検索可能、オフラインで読める）
認証/記事保存はElastic Beanstalkを使っている

オンプレミスからS3に書き込まれる：紙面画像、メタデータXML、座標
紙面更新は不定期、処理が多い、画像変換（リサイズ、フィルタ、WebP変換）は重め
ImageMagick
circle ciで、テストからデプロイ（node-aws-lambda）
1イベントで複数のLambdaを起動できないため、dipatcherで別のファイル名でS3に置いて各役割のLambdaを起動（スロットルを防ぐためS3経由）
cloudwatchでSchedule実行でlambdaを起動して、必要なデータが揃ってたかを確認（待ち合わせ処理）
Private Cache Distributionパターン

303（署名付きURLへのリダイレクト）

Slack連携

アプリケーションから進捗のログを通知、エラーの閾値を超えたときを通知
slash commandsでAPI GatewayからLambdaを起動
lambdaからlambdaを読んだ後に復帰できないエラーは厳禁（エラーを起こすと最低３回リトライされる・・・）

S3に書き込まれるCloudFrontのログを、Lambdaでパースシテ、Elasticsearchに投入、Kibanaで可視化
ユーザの声 -> API Gateway -> Lambda -> Backlog / Slack
Lambdaは意外に自由度はある（OSはAmazon Linuxなので、ここで動くものは大体動く）
S3などと連携してイベントベースで処理する場合、自動結合テストがしづらい
API Gateway + Lambdaは管理のコストがかかりそう、レイテンシーが大きい
サーバレスでの開発を通して

ステートレスを意識せざるを得ない -> 見通しがつきやすくなる

在云端构建无服务器机器学习模型

Data Exploration, Parameters tuning, little control, black-box

常にunder capacity / over capacityのいずれか -> 最適化
serverless machine learning

Production-ready prototypes
Offline training

clda.co/ML-Lambda: Sentiment Analysis with AWS Lambda & Python
not suitable for model training yet(5 min max execution time)
cold start time is long and hard to avoid

可以使用MQTT在Github Pages上托管类似于REST的API服务器。

WordPress转移到无服务器。〜无服务器架构解决了WordPress的哪些问题？〜（Shifter）

在Realm上实现无服务器应用程序

无服务器极客专家小组

无服务器的“server”是什么意思？

process管理しない、イベントが起きたときだけ実行される
インフラとしてのサーバの運用コストが下がるというのは副次的？

アーキテクチャの話なのか（FaaSに限定？）、オペレーションの話なのか（BaaSやGoogleAppEngineなども含むのか？）

Event-Action-Platform と呼べばいい？（キャッチーじゃないけど）

只用无服务器（Serverless）来构建业务应用程序吗？

「現時点で「サーバレスだけで業務アプリを組む」みたいなことを考える人はアーキテクチャ分かってないなと思う

性能の問題？

プロセスを立ち上げるコストが下がっていき、サービスとして提供できるようになれば実用的になる？

性能要件が足かせになっている、API Gateway / Lambdaのオーバーヘッドが大きい

エコシステムが未成熟

本質的にサーバレスでない方がいいものはないか？

日経は認証／保存はサーバレスではない、全部サーバレスにできる？ -> Cognitoを使えばいい？開発体制次第では全部できるかも（ただし複雑なドメインロジックはない）
Serverlessは、CPUリソースとprocessマネジメントを抽象化している
ドメインモデルが重たいものとサーバレスの親和性は？

Lambdaは状態を持たない小さい関数を実行するが前提になっているが・・・

現状はglue codeがメイン

画像処理、ログdispatch、

不可变的，无状态的

マルチプロセスモデル（例：Rails実行環境）はスケールしづらい
イベント駆動モデル（例：Node）はスケールやすいが、耐障害性に難がある
そこでErlang/ElixirのActorモデル（１リクエストごとに１軽量プロセス、メッセージパッシングで値はコピー：shared nothing）

microserviceのservice境界

Lambdaでやると、ドメインの境界でなく、機能の境界で切ってしまいそう

EC2 -> コンテナ -> Lambdaの流れになって、実行単位の寿命やスケーリング単位がどんどん小さくなっていく

GoogleAppEngineのGoは、数ミリsecで立ち上がる（pythonは10msec order, phpは100msec order, javaは1sec order）
Lambdaは10msecくらい、API Gatewayが挟まると100msecくらい（VPN入れても遅くなる）

定价

t2.smallを並列台数分スタンバイすると考えると、下手すると2桁違う

高めに見積もっておいて、下がる分には困らない

框架 jià)

Lamveryもdeployをしっかりやろうというコンセプトで作っている

「海外正在进步发展」

ビジネスとして成立しはじめている

服务器端和客户端

マネジドなサービスとして何があるかによる（クライアントにどこまで持たせるかはツール次第の面もある）

ユーザが持っているコンピュータリソースにもう少し寄っていくのでは