どうも、セクションナイン の 吉田真吾（@yoshidashingo）です。
My computer is #serverless than yours!!
ServerlessConfに参加した1日目のレポートです。
- ServerlessConf Day1 report
- Intro
- Keynote
- Building Serverless (Mobile) Applications with OpenWhisk and other Bluemix Services
- From Serverless to Servicefull: how the role of devops is evolving
- Lessons Learned and Detailed Architecture from Building Two Serverless Applications
- Disrupting old business models: the story of a serverless startup
- Changing the tires of a moving car: moving Spotify’s Data Infrastructure from on-premise to GCP
- Webtascalifragilisticexpialidocious
- Serverless architecture for the Internet of Things
- Serverlessness, NoOps and the Tooth Fairy
ServerlessConf Day1 report
Intro
- Bernard Golden (CIO Magazineのクラウドブロガーで、Wiredに「クラウドコンピューティングで最も影響力のある10人」と言われた人)の司会でスタート
Keynote
- Tim Wagner - Amazon Web Services
- AWS LambdaのGeneral Manager、最近API Gatewayのマネージャーにもなった模様
まずはバットを取りだして、、、、
サーバーをどーーーーん！！！！！サーバーよさらばーーーー！！！
Serverless Computing、そしてLambdaの話
- PaaSというのは管理的ででしゃばりでスケール単位がモノリシックでよくない
- サーバーレスがなぜ上手くいくか
- 規模の経済性：使う人が多くなれば多くなるほどコスト集約され、リソースのムラがなくなる
- リクエストがプラットフォームで可視化される
- サーバーレス（コンピューティング）・マニフェスト
- ファンクションはデプロイ単位/拡張可能単位で管理する
- 機器や仮想サーバーやコンテナがプログラミングモデルから見えてはいけない
- データを永続化するストレージは他の場所に確保する
- リクエスト単位にスケールが管理される。ユーザーはキャパシティの調達不足も超過もしない
- アイドル時間に課金されてはいけない（待機サーバー/コンテナや課金）
- ファンクションはどこでも実行できるので、暗黙的に耐障害性を持つ
- Bring your own code. コードだけ持ってくればいい
- メトリクス収集やログ取得は絶対的正義である
- Lambdaは100ms単位で買えるコンピューティング環境、安くて、ハードウェアに関する費用は一切ない
- サーバーレスコンピューティングとはなにか
- キャパシティ管理の予測可能な、目的別に構築された大規模な「プログラミング言語実行環境 as a Service」
- 世界でもっとも大規模なビンパッキングアルゴリズムとして、高速に、高度に処理を分散配置する
- サーバーレスアプリケーションかどうか
- YES
- 独立したファンクション
- RESTful APIかイベントドリブン
- BYOC(コードを持ち込むだけでよい)
- 複雑なアルゴリズムを採用
- 水平スケール
- 同期、非同期、スケジューリング
- NO
- サーバー上で稼働
- モノリシックなtarボールになっている
- モノリシックなデプロイ方法
- 重量級フレームワーク
- 分散配置されたシステムコード
- 単調作業（ログ取得など）が必要
- YES
- アプリケーション管理をもっと楽にするもの
- コード主導の場合：Serverless Framework
- デザイン主導の場合：SwaggerHub
- Flourish : ランタイムアプリケーションモデル
- Microserviceのフォーマット定義
- IDEプロジェクトとのマッピング
- ビルドをおこなったり、ZIPによるデプロイ
- 共有コンテナ上での実行
- 1箇所のダッシュボード上での監視
- 利用料金の集約
- モノリス(一枚岩)を避けるためのサーバーレスのFlourish
- Lambdaファンクションは独立したアップデート機能を備えている
- Flourishのバージョンコレクション
- コードと設定の組合せによる一貫性のあるロールバック機能
- モノリシックなデプロイ方法は不要
- サーバーレス・デザインパターン
- サーバーレスなWebアプリケーション
- 静的コンテンツをS3から配信
- 動的コンテンツをLambdaで生成
- HTTPSアクセスにAPI Gatewayを使う
- NoSQLデータストレージにDynamoDBを使う
- スケーラブルなモバイル・アプリケーションやIoTのバックエンド
- モバイルアプリ：AWS Mobile SDK + Amazon Cognito (認証)
- IoTデバイス：AWS IoT
- Lambdaの"モバイルバックエンド"の設計図
- NoSQLデータストレージにDynamoDBを使う
- S3バケットトリガ
- S3 Lambda設計図の選択
- イベント発火元のバケットを選択
- DynamoDBの動作の抽象化のためのファンクション
- イベントとイベントハンドリング
- S3のイベント発火とLambdaファンクション実行のインピーダンスマッチング：発火するイベントに応じたスケールの調整
- 既存コードの利用：ハイブリッドへの挑戦
- VPCを用いた接続性の制限
- 接続プール
- ギャップの橋渡し
- 新しいアプリケーションのエコシステム：Akexa Apps + Slack = Serverlessボット
- サーバーレスなWebアプリケーション
- サーバーレスの大衆化
- ベンダードリブンなサーバーレスコンピューティング環境とストレージの提供→エコシステムドリブンなフレームワークや開発ツールの提供→開発者ドリブンなサーバーレスアプリケーションの流行（音声アプリやチャットアプリなど）
- サーバーレスなエコシステムの構築
- 開発ツール
- CI/CD
- IDE(統合開発環境)のプラグイン
- テストフレームワーク
- Webフレームワーク
- Express
- Flask/WSGI
- React
- ドメイン
- Scipy
- R/stats
- Media
- データプロセッシング
- ビデオ
- ファイル/文書
- 散布/収集
- 監視
- ダッシュボード
- 監査ツール
- 統合フレームワーク
- ワークロード
- チャット/ボット
- IoTデバイス
- ERP/CRM
- 開発ツール
- 4つの予言(5つめはネタなので割愛)
- すべてのデータはストリームになるだろう
- 自然言語のインターフェースが、マン-マシンの対話に浸透するだろう
- サーバーレスなアプローチが競争有意をもたらすだろう
- コードはクラウドにホストされるようになるだろう：サンドボックステスト対ローカルテスト
※資料が公開されてないようなので、翌週のAWS Summit Tokyo 2016での動画を掲載しておきます。こっちはサーバーは壊してません。
Building Serverless (Mobile) Applications with OpenWhisk and other Bluemix Services
- Stephen Fink - IBM & Frederic Lavigne - IBM
- IBMのBlueMix上での画像処理/ビデオ処理のデモ
- オープンソースで提供されているOpenWhiskの紹介
https://developer.ibm.com/openwhisk/2016/06/14/conference-report-ibm-bluemix-openwhisk-serverlessconference/developer.ibm.com
Frederic Lavigne and Stephen Fink - Serverless Video Processing with IBM Bluemix OpenWhisk from ServerlessConf
www.slideshare.net
From Serverless to Servicefull: how the role of devops is evolving
- Patrick Debois - Small Town Heroes
http://www.slideshare.net/jedi4ever/from-serverless-to-service-full-how-the-role-of-devops-is-evolvingwww.slideshare.net
- サーバーレスな構成のために積極的にSaaSを使うことが増えた
- ITサポートサービス：DataDog, GitHub, CircleCIなど
- オフィスサービス：Gppgle Apps, Slack, Dropbox, Google Calendar, Skype, Trello, Google Hangoutなど
- コミュニティサービス：npm, ubuntu, coreos, NTP, Docker Registryなど
- フロントエンドサービス：jQuery, Google font api, AngularJS, Google Analytics
- モバイルサービス：AWS Device Farm, Amazon Mobile Analytics, SNS, Cognito, App Annie, AppStore, Google Play Store, fabric, New Relic, ComScore
- サービスの可用性に依存しているので、GitHubが落ちたらシゴトができない、みたいなことがよく起きる
- 文書化されてない変更が入ったりする（CircleCIの例）
- ELBは事前暖機が必要で、忘れて急にトラフィック受けると何もできずにエラーが大量に返ってしまう
- サーバーレス、というかサービスフルな状態で【SaaSがダウンしてサービスが継続できないリスクが上昇している】
- 「約束」モデルで考えてみる ※以下の「約束(Promise)」はSLOやコミットメントといったニュアンスで使われています
- (1)あなた(エージェント)はシステム内の他のエージェントに約束をする
- (2)あなたの約束は検証可能でなければならない
- (3)ただしあなたの約束は成果を保証するものではない
- (4)条件が約束の一部でないといけない
- (5)約束は言語化して共有されなければならない
- (6)しかし、あなたは他のエージェントに代わって約束をすることはできない(ボトムアップ vs トップダウン)
- (7)しかし競合は(他者の約束の責任を負うことができないように)内部的な約束に由来するかもしれない
- (8)約束を守るために選択すべきことは「Push」か「Pull」か
- (9)抽象化は選択的無知だが、コンピュータサイエンスのすべての問題は抽象化の別のレベルで解決することができる
- (10)すべての約束の結合が関係性の基本形である
- (11)同様の目的を持つエージェントは、スーパーエージェントに分類することができる
- (12)再選択のためには複数のスーパーエージェントが必要：単一スーパーエージェントはSPOFになる
- (13)約束を守るためにエージェントは違った世界観(とバージョン)で構成される必要がある
- (14)スーパーエージェントの遅延は内部通信スピードによる影響かもしれない
- (15)Lambdaのサービスの内部仕様について
- Lambdaのコンテナの再利用ルールは非決定
- スケールは常に無限というわけではない
- (16)DevOpsを採用してもらい、リモートAPIを駆使することにした
- RSSでAWSの障害を監視
- Google Scanningを用いたGoogle Appsのデータのバックアップ
- (17)Slackを用いて約束のステータス変更を素早くフィードバックできるようにする
- (18)(ポストモーテムなどを読んで)何に依存しているか、また他のサービスでも同様の期待値(依存性)を明らかにする
- (19)カンファレンスでサービスへの希望を共有する
- (20)他のエージェントに状況をフィードバックする
- (21)自分を頼りにしてくれる人たちにも聞いたことを伝えてあげる
- (22)同僚のエンジニアたちにおそれずに情報交換すべきであるということを示してあげる
- (23)要望されていることに対する責任を持つ
- (24)約束の変更を行い他のエージェントに影響をおよぼす
- DevとOpsのコラボレーションはいまや外部のサードパーティベンダーにまで広がっていることを認識する
- そして他のエージェントの約束を確認しておく
Lessons Learned and Detailed Architecture from Building Two Serverless Applications
- Joe Emison - BuildFax
- 製品がマーケットにフィットするかどうかが最も重要である
- ビジネスに関連するコードの開発時間に極力時間を使うべきである
- 顧客とまわすイテレーションを最大化すべきである
- 依存性を最小化すべきである：仕様確定待ちで開発者を待たせたり、運用やDBAやその他の開発者の影響で待たせることを極力避けるべきである
- サーバーレスアプリケーション Commercial Search の事例
- 2人の開発者で4ヶ月で作った
- 13,307行のTypeScript
- 開発者の稼働は95%以上だった(なにかに依存した待ち時間はほとんどなかった)
- コンセプトはMicroservicesだが、自分たちはコアしか書いていない
- ペインポイント
- Firebaseのダッシュボードでは大きなデータセットが扱えない（APIであればOK）
- RDBMSからFirebaseに移行する開発者のラーニングカーブは人それぞれ、非常識ってほどではないけど
- サーバーレスアプリケーション Property Tour Pro の事例
- ペインポイント
- AngularFireは使ってはいけない：トリプルバインディングはとても遅い
- CORSではサードパーティのAPIは直接叩けない、Webtaskを使おう
- Auth0は素晴らしい、ただしドキュメントにはイライラさせられる
- DocRaptorはPDFや画像の圧縮がうまくできない、Cloudinaryを使おう
- ペインポイント
- AWSを使わない理由
- AWSのサーバーレスはバックエンドプロセッシングのアウトソース。フロントエンドからまるごとアウトソースはできない
- AWSのサーバーレスは複雑：IAM + Cognito + API Gateway + Lambda
- Auth0 Webtask = Lambda + API Gateway + IAM + Cognito
- Firebase = Lambda + API Gateway + IAM + Cognito + DynamoDB
- Firebase Queues = Lambda + API Gateway + IAM + Cognito + SQS
www.slideshare.net
Disrupting old business models: the story of a serverless startup
- Sam Kroonenburg - A Cloud Guru & Peter Sbarski - A Cloud Guru
- 前日のワークショップの講師をした A Cloud Guruの二人
- サーバーレスアーキテクチャ原則
- オンデマンドなコードの実行のためにコンピュートリソースを使う
- 単一目的のステートレスなファンクションを書こう
- pushベースでイベントドリブンなパイプラインを設計しよう
- リッチでパワフルなフロントエンドを構築しよう
- サードパーティサービスを使おう
- 書籍：Serverless Architectures on AWSを執筆中
www.slideshare.net
Changing the tires of a moving car: moving Spotify’s Data Infrastructure from on-premise to GCP
- Wouter De Bie - Spotify
- すでにオンプレミスで運用しているHadoopクラスタ(30PBのデータ)をGCPに移行した話
- オンプレミス→GCPインフラ
- 2300ノードのHadoopクラスタ → 分割されたDataProcクラスタ
- 単一のHDFS上の30PBのデータ → プロジェクトごとに分割されたGCSのそれぞれのバケット
- Hiveのアドホッククエリ → BigQueryのアドホッククエリ
- Luigiを使ったスケジューリング → Dockerを使った新しいスケジューリングシステム
- Apache Kafka → Google Pub/Sub
- Cassandra → BigTable
- 30PBのデータをどう移動したか
- 自社DCとGCPをピアリングしてDistCpでHDFSからGCSにコピー
- 依存性をどう解決したか？
- オンプレミスで生成されたデータをGCPへ
- GCPで生成されたデータをオンプレミスへ（必要に応じて）
- 各チーム自身で必要な作業はやってもらった
- 移行の優先度
- 各チームの緊急度に応じて
- クラウド環境でいろいろできるという価値（とくにBigQueryは大きな牽引役だった）を各チームに提供した
Webtascalifragilisticexpialidocious
- Tomasz Janczuk - Auth0
- WebhookがSaaSの拡張性のキモ
- 2015年以降のWebhook
- 非同期
- Webtaskはサーバーレスなwebhook
- 簡単に始められて準備要らず
- フルHTTPコントロール
- スケジュールジョブが実行可能
- コンテナのプロビジョニングのリードタイムで実行時間がばらつくことを防止するために独自のプレウォーミング機構を備えている
www.slideshare.net
Serverless architecture for the Internet of Things
- Ben Kehoe - iRobot
- RoombaやBraavaなどを開発・販売するロボット企業における、サーバーレスなIoTの使い方
- iRobotは100カ国で販売しており、北米は40%程度
- 去年はロボットを240万台出荷した
- ルンバの実機、モバイルアプリ、クラウドはそれぞれAPI GatewayやAWS IoTを用いてデータ連携している
www.slideshare.net
Serverlessness, NoOps and the Tooth Fairy
- Charity Majors - Hound
- "In the glorious Future, we eill be Serverless, and there will be NoOps. - thought leaders" と言われている
- 昔、Parseというサービスを作っていて、100万以上のモバイルアプリをホストしていた
- 誰も運用をしたくない
- サービス(SaaS)は「魔法の妖精の粉」か、いやそうではない
- 来たるサーバーレスな未来では、アプリケーション開発者がもっと運用品質に対する責任を担うことになる
- 「私はソフトウェアエンジニア、インフラはすべてお金を払ってホストしてもらっているので、運用のことは考えたくない！」と考えていても、アプリは落ちているかもしれないという状況においてはどんな変更があったか、サービス側の問題か、などを切り分ける必要性がある
- 運用とはなにか？
- 運用は自分の組織の技術スキルや練習、デザイン周りの文化づくり、システムの構築やメンテナンス、ソフトウェアのデリバリー、技術的な問題の解決
- 運用エンジニアのコアコンピテンシー
- スケーラビリティ
- レジリエンシー
- 可用性
- メンテナンス性
- 複雑なシステムを簡素化する
- モニタリングの実装と可視性
- グレイスフル デグラデーション：ソフトウェアのアップグレードなど
- サーバーレス運用工学のベストプラクティス
- あなたのプロダクトの問題はあなた以上にちゃんと直せる人はいない
- クリティカルパスを理解する
- できるかぎり小さく維持する
- SaaSプロバイダの技術情報と、何にどう依存しているか理解する
- アウトソース先に問題が起きても、自身のサービスにおけるそれによる結果については依然としてあなたが責任を持たなければいけない
- トレードオフ
- 可視性が下がる
- 自分自身で問題をfixできないし、新機能を実装することもできない
- サービスはあなたの支払うお金で維持されている：※ここはParseの元エンジニアだったということですごくぐっとくる部分ですね
- 制限や制約は公開されることもあるし、公開されないこともある
- 共同利用はよくない、ツールも未熟
- 他者のプラットフォームを利用する場合
- 共同利用形態はどういうものか？
- パフォーマンスの差異はあるか？
- ベンダーロックインに対抗するあなたの対抗意欲はどうか？
- サービスに問題が合った場合の透明性はどうか？
- データ衛生
- データについてもあなたが責任を担う部分
- データ保持やリカバリーポリシーについて尋ねる
- オフサイトバックアップを取得する
- リストアを評価する - もしテストしてないならあなたのバックアップは「シュレディンガーのバックアップ」だ（※存在するかどうか蓋を開けるまで分からないという意味）
- 不思議なストレージシステムを契約してはいけない、ブラックボックス、クエリチューニング、やってられない
- 可視性とデバッグしやすさ
- 商用環境と同じ環境に載せてはいけない、リスク分散しよう
- メトリクスを集約しよう
- 動作したものはすべて即グラフ化するようにしよう、クライアントやアプリケーション、クエリなどすべて
- Opsとしてレベルアップするには
- ソフトウェアエンジニアを自分のサービスのオンコールに入れよう
- 運用やデバッグに関するすべてのことを聞かせてもらおう
- これらのスキルもパフォーマンスレビューや昇進の評価に使おう
www.slideshare.net
