サーバレスの薄い本 ダイジェスト #serverlesstokyo

617 views

Published on

20161109 Serverless Meetup Tokyo
サーバレスの薄い本 ダイジェスト

薄い本電子版はこちら!
https://gumroad.com/l/memotr201608

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
617
On SlideShare
0
From Embeds
0
Number of Embeds
243
Actions
Shares
0
Downloads
1
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • 出力バインド、引数でハンドラが渡されてくる
  • 良く紹介される「The Twelve Factor App」がアプリケーション開発におけるベストプラクティスならば、このリアクティブ宣言はシステム全体のアーキテクチャを考えるときのベストプラクティスです。
  • サーバレスの薄い本 ダイジェスト #serverlesstokyo

    1. 1. サーバレスの薄い本 ダイジェスト 2016-11-09 Serverless Meetup Tokyo Aki@nekoruri
    2. 2. で、誰? • あき • ねこるり etc.
    3. 3. 「サーバレスの薄い本」 #とは • 流行キーワード「サーバレスアーキテクチャ」を 簡潔に解説した同人誌 • 同人サークル「めもおきば」の同人誌 「めもおきば TechReport」の2016.08号 • コミックマーケット90および ServerlessConf Tokyoにて頒布 • Special thanks to 5472v3 (編集、装丁、表紙イラスト) • 今日も頒布します!(限定20部) • 電子版も本日リリース!
    4. 4. サーバレスアーキテクチャ • ふたつの「サーバレスアーキテクチャ」 1. 管理運用における「サーバ」という粒度を廃した、 フルマネージドなアプリケーション実行環境 2. クラウド上のコンポーネントを、FaaSで「のり付け」する 中央集権的な「サーバ」を廃したシステムアーキテクチャ
    5. 5. 1. フルマネージドなアプリケーション実行環境 • 「確保した量」から「使用した量」へのシフト • 確保したサーバ台数(箱の大きさ)に課金するのでは無く、 実際に使用した実行時間(中身の大きさ)に課金をする (現実的には、メモリ使用量などはまだ確保分になっている) • アプリケーションPaaSの最終形 • 実現方法 • 「いわゆるオートスケーリング」の粒度を「サーバ」より縮小 • 最初から「薄く広く」分散させた分散システム • 背景 • The twelve-factor appなど、ステートレスなアプリケーションという 「ベストプラクティスな制約」の普及
    6. 6. 2. コンポーネントを「のり付け」するアーキテクチャ • クラウド時代の「制御の反転」 • アプリケーションサーバが各コンポーネントを呼び出すのではなく、 各コンポーネントを小さな関数が接続する • システムアーキテクチャの設計手法の変化 • マイクロサービス化、コレオグラフィ化の流れの一部 • 背景 • 高水準なクラウド上のコンポーネントの登場 • 様々な「イベントトリガ」の整備 • ID基盤のうえでコンポーネント側だけで細かいアクセス認可 • そもそも「餅は餅屋」、自分で作らなくて良い部分が増えている。
    7. 7. 「サーバレスアーキテクチャ」の広まり • 2008年 Google App Engineプレビューリリース サーバレスなPaaSとしての完成形 • 2012年 Serverlessというテクニカルターム誕生 「Why The Future Of Software And Apps Is Serverless」 • 2014年 AWS Lambdaリリース • 2015年 日本語圏で広く知られるきっかけとなる記事 「サーバーレスアーキテクチャという技術分野についての簡単な調査」 • 2016年 ServerlessConf等の盛り上がり http://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/ http://qiita.com/zerobase/items/3bc0d15980b472af841d
    8. 8. 大手クラウドにおけるサーバレスアーキテクチャ • Amazon Web Services • AWS Lambda • Microsoft Azure • Azure Functions • Service Fabric • Google Cloud Platform • Google App Engine • Google Cloud Functions
    9. 9. AWS Lambda • 主な特徴 • 2014年末にリリース • JavaScript、Python、Java8に対応 • Amazon Linuxベースのコンテナで、Goバイナリなども実行可能 • 実行プロセスは「良い感じ」に使い回される • 課金モデル • 確保メモリ×実行時間+実行回数 • 確保メモリは128MB~1.5GBの範囲で64MB単位であらかじめ指定 • 実行時間は100ms単位で計測 • (スケールに伴う起動時間などは、一定時間までは無料)
    10. 10. AWS Lambda • 主なイベントソース • 単独ではAWS APIからのみ実行可能 • 手動実行、定期実行 • HTTP API:API Gateway • データストア:S3、DynamoDB、Cognito • メッセージ配信:Kinesis Streams、Simple Notification Service • 外部連携:Simple Email Service、Echo • 管理:CloudFormation、CloudWatch Logs/Events、AWS Config • 実行権限とアクセスコントロール • IAM Roleによる権限管理と、リソース側での認可 • Cognito IdentityでAWS側の一次トークンに紐付け
    11. 11. Azure Functions • 主な特徴 • 2016年3月にプレビューリリース • C#、JavaScript(Node)、Python、F#、PHP、BAT、Bash、Java • 良い感じにスケールする「動的サービスプラン」のほか、 App Serviceとして確保したVM上で動かすプランも設置 • 実行ランタイムがGitHubにてオープンソース化 • 課金モデル • 確保メモリ×実行時間+実行回数 • 確保メモリは128MB~1.5GBの範囲で128MB単位であらかじめ指定 • 実行時間は100ms単位で計測
    12. 12. Azure Functions • 主なイベントソース(入力バインド) • 単独でもHTTP APIとして呼び出し可能 • タイマー • HTTPリクエスト(API Management)、Webhook • データストア:Storage BLOB、Storage テーブル、DocumentDB、 Mobile Apps • メッセージ配信:Storage キュー、Service Bus キュー、Event Hub • 出力バインド:関数の出力をコンポーネントに接続 • 実行権限とアクセスコントロール • Azure全体のRBAC準拠 • Shared Access Signatureでリソースに直接アクセス可能
    13. 13. Google App Engine • 主な特徴 • 2008年にプレビューリリースされた元祖サーバレス • ……だったはずが、 正式リリースでは、インスタンス単位課金の一般的なPaaSに…… • 基本的にはHTTPで呼び出される普通のPaaS
    14. 14. Google Cloud Functions • 主な特徴 • 2016年2月にアルファリリース • JavaScript(Node)が実行可能 • 主なイベントソース • HTTP リクエスト • データストア:Cloud Storage • 非同期メッセージング:Cloud Pub/Sub • 最低限必要な物は一通り揃った、という段階
    15. 15. サーバレス時代の考え方 • リアクティブシステム • 素早く、かつ安定した応答時間を保つシステムのベストプラクティス • The Twelve Factor Appのレイヤー高い版 • ID管理とリソースへのアクセス制御
    16. 16. リアクティブシステム • 目的:即応性 • システム全体として、素早く、かつ安定した応答時間を保つ • 要件1:耐障害性 • 障害が発生しても、それをコンポーネント内部に影響を隔離すること で、システム全体としての即応性を保つ。 • 要件2:弾力性 • 負荷の増減があっても、ボトルネックを排除し、割り当てるリソース を調整することで、即応性を保つ。 • 手段:メッセージ駆動 • 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。
    17. 17. ID管理とリソースのアクセス制御 • クライアントアプリを経由したID連携 • mBaaS(CognitoやFirebase)等がすでに確立している • つまりFaaSによる「のり付け」すら不要な場合も • そもそも高レベルのデータストア等があり、 ID基盤のうえで、細かいアクセス制御(認可)が可能 • 「Facebookから連携したIDがあれば、書き込みを許可」 • 「ID=Aなら、階層Aの下の領域だけ読み書き可能」 • サーバレス時代のマルチクラウド連携はID連携が基本 • IDを連携し、それに対するリソース側で細かい認可を制御 • プログラムは「整合性」のための最小限に留まるのでは
    18. 18. 主なパターン • ウェブアプリ・モバイルアプリのバックエンド • いわゆるBaaSの発展系 • サーバ側ロジックが不要ならデータストアに直接アクセス • クラウド基盤のイベント処理 • 「ピタゴラ装置」的に動画共有サイトを実現する事例など • AWS Lambdaは「イベント」をたくさん用意したのが勝利の鍵 • イベントのストリーミング処理 • さいきんはやりのLINE Botを手軽に実現する事例など
    19. 19. サーバレスアーキテクチャの今と未来 • 今 • 基本機能は揃い始め、既に適用しやすい領域ではメリット大 • 管理ツールやフレームワークの黎明期 • 祝!Serverless Framework正式リリース! • (当初、随分デカい主語だなオイとか思っていてごめんなさい) • 未来 • ID管理とリソース側の認可だけでできることが増え、 「サーバが全ての面倒を見る設計じたいが陳腐化していくのでは • FaaSがエッジコンピューティング側にも拡がっていく第一歩 「次の集中から分散への波」
    20. 20. 「サーバレスの薄い本」まとめ • ふたつのサーバレスアーキテクチャ • ステートレスなソフトウェアを前提としたフルマネージドな実行環境 • クラウドコンポーネントをのり付けするアーキテクチャ設計 • どちらも良いシステムを導くための「良い制約」 • 大手クラウドの提供する「サーバレス」の比較 • サーバレスなシステムを作るための考え方 • リアクティブシステム • ID管理とリソース側での細かい認可
    21. 21. 「サーバレスの薄い本」よろしくね! • 流行キーワード「サーバレスアーキテクチャ」を 簡潔に解説した同人誌 • 同人サークル「めもおきば」の同人誌 「めもおきば TechReport」の2016.08号 • コミックマーケット90および ServerlessConf Tokyoにて頒布 • Special thanks to 5472v3 (編集、装丁、表紙イラスト) • 今日も頒布します!(限定20部) • 電子版も本日リリース! https://gumroad.com/l/memotr201608

    ×