ServerlessConf Tokyo参加メモ

最後に、発表内容と現状の実態を踏まえて議論されたパネルディスカッションがあったのが、頭の中が整理されてとてもよかった。

Keynote: Go Serverless, Compute Only When it Matters!

• Architect to be Serverless

  • Fully Managed
  • Developer Productivity
  • Scalability

• AWS Lambda: Triggered through API calls or state changes in your setup

  • Data stores
  • endpoints
  • Repositories
  • event/message services

• API Gateway -> Lambda -> Dynamo DB: これで１つのmicroservice

• API Gateway

  • provides DDoS protection and throttling capabilities
  • multiple API stages which you define(e.g. dev, test, prod)

• DEMO / Webhooks

  • facebook page -> API Gateway -> Lambda -> Slack Channel / DynamoDB

• Storage and Delivery of the App

  • S3: offers http/ https endpoint to objects
  • CloudFront: caches content
  • browser -> CloundFront -> S3 (html/css/js)
    

• Introducing Chalice

  • serverless microframework for AWS
  • deploy APIs quickly via AWS Lambda and Amazon API Gateway
  • github.com/awslabs/chalice

• Serverless UI -> HTML5 / React /Angular

development

• Versioning
  • 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

amazon Echo

• The Power of Speech: Alexa
  • 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を指定

Serverless with Native Application for Newspass(ニュースパス)

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を各自で実装できる）

罠とtips

• AWSへの認可を求めるのか、アカウント管理を求めるのか
  • cognitoユーザとサービスユーザはイコールなのが（二重管理をすると管理が複雑）
  • ユーザの単位：Unauthorized Userはデバイス単位
  • SNSログイン
  • インストール・アンインストールの取り扱い
• 複数のSDKを初期化すると、認証が複数回叩かれ、同時にいくつもユーザが生成される
  • cognitoのユーザー生成が完了してから各種SDKの初期化を開始
  • SDKの裏にある処理の依存に気をつけ、どういった順序で扱うべきか考える
• Cognito Syncの競合解決
  • conflictのfeedbackが発生する、conflictを解決しないと二度とsyncできない
• Cognito SyncとLambdaフックの頻度
  • アプリ起動時にsynchronizeすると容易にLambdaの呼び出しが跳ねる（たとえばAndroidはpushを受けるとアプリが起動される） -> throttlingが発生
• 古いEndpointの扱い -> クライアントサイドで古いトークンに対応するEndpointを削除する

Event-driven and Serverless Computing with OpenWhisk (Bluemix)

• OpenWhisk

  • イベントに応答してコードを実行するEvent Action Platform
  • オープンソース / IBM Bluemix上のマネージドサービスとして提供
  • 従来のイベント・プログラミング・モデルではロスする可能性があるため、継続的にポーリング必要
  • OpenWhisk: 要求当たり１プロセス OpenWisk EngineがPool of Actionsから取得してrun
  • OpenWhisk / Instant Runtime (Cloud Foundry) / IBM Containers(docker) / 仮想環境（oepnstack）
  • Node, Swift, Docker
    

• docker

  • isolation of action
  • wsk action invoce = docker run
  • start container(docker run) -> initialize(/init) -> Run(/run)
    • cold container
    • pre-warmed container
    • warm container

• Usecase

  • microserviceベースのアプリ・API / モバイルバックエンド / データ（ストリーム）処理 / IoT / cognitive / bot

• プログラミングモデル

  • Trigger / Rule / Action
  • Action: chain可能： Aa = A1 + A2 + A3（再利用性）
  • Rule: TriggerとActionの組み合わせ
  • Package: TriggerとActionの集合

Unlimited Frameworks

• Serverless framework
• Apex
• Chalice
• Zappa
• Lamvery

Firebaseを使ったサーバーレスWebアプリケーション開発

• Firebase: BaaS
• Web APP
  • 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：ハードウェアの管理から解放、必要なときに必要なだけサーバが手に入る
  • コンテナ:キャパシティの考え方がある（余剰リソースの管理が復活？？）
  • サーバレス：アイドルリソースが完全になくなる

Operability in Serverless Environments

• Operability without Servers
  • monitoring
  • deployment
  • security
  • networking
• Cloud Foundry / Chef/ Docker
• Show HN / , Inc. / Raging and Forking / Operability

Serverless Patterns with Azure Functions

• 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トラッキングプラットフォームがサーバレスだからこそ2ヶ月で構築できた話

• Authentication + MQTT
• Serialize: AWS IoT -> kinesis -> lambda -> S3
  • 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するしかない（コンソールからパラメタを変える）

Disrupting old business models: the story of a serverless startup

http://www.slideshare.net/ServerlessConf/sam-kroonenburg-and-pete-sbarski-the-story-of-a-serverless-startup
Cost Modelがいい（ユーザが自社サービスを使った分だけ、AWSに支払いが発生）

principles

• use a compute service to execute code on demand (aka don't run a server)
  • 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は管理のコストがかかりそう、レイテンシーが大きい
• サーバレスでの開発を通して
  • ステートレスを意識せざるを得ない -> 見通しがつきやすくなる

Building Serverless Machine Learning Models in the Cloud

• MLaaS
  • 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 Like な API サーバホスティング

WordPress shift Serverless. ~ ServerlessアーキテクチャはWordPressの何を解決したのか ~（Shifter）

Realmで実現するサーバーレスアプリケーション

Serverless Geeks Panel

serverlessの"server"とは？

• OSなどインフラとしてのサーバ、processとしてのサーバ（ex. Webサーバ）、どちらの"server"lessをイメージするか？
  • process管理しない、イベントが起きたときだけ実行される
  • インフラとしてのサーバの運用コストが下がるというのは副次的？
• アーキテクチャの話なのか（FaaSに限定？）、オペレーションの話なのか（BaaSやGoogleAppEngineなども含むのか？）
  • Event-Action-Platform と呼べばいい？（キャッチーじゃないけど）

サーバレスだけで業務アプリを組む？

• 鈴木雄介さんのツイート
  • 「現時点で「サーバレスだけで業務アプリを組む」みたいなことを考える人はアーキテクチャ分かってないなと思う
• 性能の問題？
  • プロセスを立ち上げるコストが下がっていき、サービスとして提供できるようになれば実用的になる？
    • 性能要件が足かせになっている、API Gateway / Lambdaのオーバーヘッドが大きい
  • エコシステムが未成熟
• 本質的にサーバレスでない方がいいものはないか？
  • 日経は認証／保存はサーバレスではない、全部サーバレスにできる？ -> Cognitoを使えばいい？開発体制次第では全部できるかも（ただし複雑なドメインロジックはない）
  • Serverlessは、CPUリソースとprocessマネジメントを抽象化している
  • ドメインモデルが重たいものとサーバレスの親和性は？
    • Lambdaは状態を持たない小さい関数を実行するが前提になっているが・・・
  • 現状はglue codeがメイン
    • 画像処理、ログdispatch、

immutable, stateless

• domainモデルを実行するprocessを分離 -> Actorモデルとinfrastructureが一体化
• 理想的には、CPUヘビー／メモリヘビーなfunctionごとにリソース配分を決めたい
• Web APIサーバとしてのElixirの可能性: https://speakerdeck.com/naoya/web-api-sabatositefalse-elixir-falseke-neng-xing
  • マルチプロセスモデル（例：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入れても遅くなる）

Pricing

• 事前に推定見積したが、実際の支払いは安かった（EC2で動かすよりは数倍安い印象）
• 3万ユーザの行動ログを数千万件をAuroraに入れておいて、ベンチマーカーを実行した人に投げつける
  • t2.smallを並列台数分スタンバイすると考えると、下手すると2桁違う
• 高めに見積もっておいて、下がる分には困らない

framework

• 1 lambda 1 repositoryで、circle ciで固めてアップロードしている
• serverless frameworkは、現状はデプロイ自動化ツール（プログラミングモデルを導くものではない）
• Lamveryもdeployをしっかりやろうというコンセプトで作っている

「海外が進んでいる」？

• serverless/servelessでないものの議論を乗り越え、組み合わせている
• ビジネスとして成立しはじめている

サーバサイドとクライアントサイド

• 本質的に、何をサーバにやらせて、何をクライアントにやらせるべきかが変わる？
  • マネジドなサービスとして何があるかによる（クライアントにどこまで持たせるかはツール次第の面もある）
• ユーザが持っているコンピュータリソースにもう少し寄っていくのでは