Serverless Architecture Overview #cdevc

Serverless Architecture Overview 2017-07-25 Cloud Developers Circle #2 - Serverless Night - Aki@nekoruri

「サーバーレスアーキテクチャ」？ • 「サーバ」が「無い」アーキテクチャ • FAQ：「でもサーバ有るんでしょ？」 • イメージは人それぞれ • いまだに明確な定義はされていない

「サーバーレスアーキテクチャ」の歴史 • 2008年 Google App Engineプレビューリリース サーバーレスなPaaSとして一つの完成形 • 2012年 Serverlessというテクニカルターム誕生 「Why The Future Of Software And Apps Is Serverless」 http://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/ • 2014年 AWS Lambdaリリース • 2015年 日本語圏で広く知られるきっかけとなる記事 「サーバーレスアーキテクチャという技術分野についての簡単な調査」 http://qiita.com/zerobase/items/3bc0d15980b472af841d • 2016年 Azure Functions、Bluemix OpenWhiskリリース • 2017年 Google Cloud Functionsベータ公開、各社から継続的な機能拡張

• http://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/
• http://qiita.com/zerobase/items/3bc0d15980b472af841d

サーバーレスアーキテクチャ • 自分で管理する「サーバ」を無くすための二つの方針 1. 管理運用における「サーバ」という粒度を廃した、 フルマネージドなアプリケーション実行環境 2. クラウド上のコンポーネントをイベント駆動で結びつけて 最大限活用していくシステムアーキテクチャ

寄り道： 「サーバレス」？「サーバーレス」？ • Server ⇒ Serverless （合成語） • 内閣告示派 • 基本的に長音はそのまま • 「サーバー」であり「サーバーレス」 • JIS規格派 • 語尾に長音符号を付けないルール • 「サーバ」 だけど「サーバーレス」 ※あくまで一単語のため • 訳語なのでどちらでもいいけど、 原則的にはサーバーレスが正式

サーバーレスアーキテクチャ • 自分で管理する「サーバ」を無くすための二つの方針 1. 管理運用における「サーバ」という粒度を廃した、 フルマネージドなアプリケーション実行環境 2. クラウド上のコンポーネントをイベント駆動で結びつけて 最大限活用していくシステムアーキテクチャ

サーバーレスアーキテクチャ • 自分で管理する「サーバ」を無くすための二つの方針 1. 管理運用における「サーバ」という粒度を廃した、 フルマネージドなアプリケーション実行環境 （FaaS等に乗っかり自分で書くコードを減らす） 2. クラウド上のコンポーネントをイベント駆動で結びつけて 最大限活用していくシステムアーキテクチャ （そもそも自分で用意する機能そのものを減らす）

1. フルマネージドなアプリケーション実行環境 • いわゆる「FaaS（Function as a Service）」 • 「関数」と呼ばれる小さなコードを動かすマネージドサービス • 基本的にはコンテナベースでコードを動かす • 自動でスケール • 他のサービスから呼び出されて動く • APIゲートウェイ（同期） • イベントストリーム、ストレージ等からのトリガー（非同期） • 各社「サーバーレス」の中心人物 AWS Lambda、Azure Functions Google Cloud Functions、Bluemix OpenWhisk

1. フルマネージドなアプリケーション実行環境 • 「確保した量」から「使用した量」へのシフト • 確保したサーバ台数（箱の大きさ）に課金するのでは無く、 実際に使用した実行時間（中身の大きさ）に課金をする （現実的には、メモリ使用量などはまだ確保分になっている） • アプリケーションPaaSの最終形 • 実現方法 • 「いわゆるオートスケーリング」の粒度を「サーバ」より縮小 • 最初から「薄く広く」分散させた分散システム • 背景 • The twelve-factor appなど、ステートレスなアプリケーションという 「ベストプラクティスな制約」の普及

1. フルマネージドなアプリケーション実行環境 • いわゆるPaaSとの違い • 明確な定義の違いは無く、スケールのしやすさで区別 https://twitter.com/adrianco/status/736553530689998848 • 実論まわりはFastContainerあたりの議論が分かりやすいです

• https://twitter.com/adrianco/status/736553530689998848

2. コンポーネントを「のり付け」するアーキテクチャ • 高機能なクラウド上のコンポーネントの活用 • Functional SaaS（Service as as Service） あるいはBaaS（Backend as a Service） • コンポーネント自身が高機能化し、様々な「イベント」を生成 • イベントからFaaSを呼び出して連携 • フロント側のネイティブアプリ化/SPA化の波 • アプリから直接データストア等にアクセスできる • 「ガチャ」のようなブラックボックスだけクラウド側に実装を持つ • アプリの一部としてクラウドとメッセージング連携

2. コンポーネントを「のり付け」するアーキテクチャ • クラウド時代の「制御の反転」 • アプリケーションサーバが各コンポーネントを呼び出すのではなく、 各コンポーネントを小さな関数が接続する • システムアーキテクチャの設計手法の変化 • マイクロサービス化、コレオグラフィ化の流れの一部 • 背景 • • • • 高水準なクラウド上のコンポーネントの登場 様々な「イベントトリガ」の整備 ID基盤のうえでコンポーネント側だけで細かいアクセス認可 そもそも「餅は餅屋」、自分で作らなくて良い部分が増えている。

大手クラウドでのサーバーレスアーキテクチャ • Amazon Web Services • AWS Lambda • Microsoft Azure • Azure Functions • Service Fabric • Google Cloud Platform • Google App Engine • Google Cloud Functions • IBM Bluemix • OpenWhisk

AWS Lambda • 主な特徴 • • • • 2014年末にリリース JavaScript(Node)、Python、Java8、C#(.NET Core)に対応 Amazon Linuxベースのコンテナで、Goバイナリなども実行可能 実行プロセスは「良い感じ」に使い回される • 課金モデル • • • • 確保メモリ×実行時間＋実行回数 確保メモリは128MB～1.5GBの範囲で64MB単位であらかじめ指定 実行時間は100ms単位で計測 （スケールに伴う起動時間などは、一定時間までは無料）

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側の一次トークンに紐付け

Azure Functions • 主な特徴 • 2016年3月にプレビューリリース • C#、JavaScript(Node)、Python、F#、PHP、BAT、Bash、Java • 良い感じにスケールする「動的サービスプラン」のほか、 App Serviceとして確保したVM上で動かすプランも設置 • 実行ランタイムがGitHubにてオープンソース化 • 課金モデル • 確保メモリ×実行時間＋実行回数 • 確保メモリは128MB～1.5GBの範囲で128MB単位であらかじめ指定 • 実行時間は100ms単位で計測

Azure Functions • 主なイベントソース（入力バインド） 単独でもHTTP APIとして呼び出し可能 タイマー HTTPリクエスト（API Management）、Webhook データストア：Storage BLOB、Storage テーブル、DocumentDB、Mobile Apps • メッセージ配信：Storage キュー、Service Bus キュー、Event Hub • • • • • 出力バインド：関数の出力をコンポーネントに接続 • 実行権限とアクセスコントロール • Azure全体のRBAC準拠 • Shared Access Signatureでリソースに直接アクセス可能

Google App Engine • 主な特徴 • 2008年にプレビューリリースされた元祖サーバレス • ……だったはずが、 正式リリースでは、インスタンス単位課金の一般的なPaaSに…… • 基本的にはHTTPで呼び出される普通のPaaS

Google Cloud Functions • 主な特徴 • 2017年3月にベータリリース • JavaScript(Node)が実行可能 • 課金モデル • 確保インスタンス単価×実行時間＋実行回数 • インスタンスは[128MB/200MHz]から[2048MB/2.4GHz]の5タイプ • 実行時間は100ms単位で計測

Google Cloud Functions • 主なイベントソース • • • • HTTP リクエスト データストア：Cloud Storage 非同期メッセージング：Cloud Pub/Sub モバイル統合：Firebase

IBM Bluemix OpenWhisk • 主な特徴 • オープンソース実装とそれに基づくパブリッククラウド基盤 • パブリッククラウドとしては2016年12月に正式リリース • JavaScript(Node)、Python、Swift、Dockerコンテナが実行可能 • 主なイベントソース • • • • HTTP リクエスト データストア：noSQL DB 非同期メッセージング：Message Hub タイマー

サーバーレス時代の指針 • リアクティブシステム • 素早く、かつ安定した応答時間を保つシステムのベストプラクティス • The Twelve Factor Appのレイヤー高い版 • ID管理とリソースへのアクセス制御

リアクティブシステム • 目的：即応性 • システム全体として、素早く、かつ安定した応答時間を保つ • 要件１：耐障害性 • 障害が発生しても、それをコンポーネント内部に影響を隔離すること で、システム全体としての即応性を保つ。 • 要件２：弾力性 • 負荷の増減があっても、ボトルネックを排除し、割り当てるリソース を調整することで、即応性を保つ。 • 手段：メッセージ駆動 • 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。

リアクティブシステム • メッセージ駆動（手段） • システム間をキューで非同期に接続する • 複数のワーカプロセスがキューから取ってきて処理 • 弾力性（要件2） • メッセージが増えてきたらワーカプロセスを増やせばよい • 横並びのワーカプロセスに相互依存はないので気軽にスケールアウト・イン • 耐障害性（要件1） • コンポーネントで異常が起きたら自爆して、別のワーカが実行 • ずっとおかしいメッセージはDead letter queueに積み替えて例外処理 • 即応性（目的） • 様々な状況に強いシステムが構築できる

ID管理とリソースのアクセス制御 • クライアントアプリを経由したID連携 • mBaaS（CognitoやFirebase）等がすでに確立している • つまりFaaSによる「のり付け」すら不要な場合も • そもそも高レベルのデータストア等があり、 ID基盤のうえで、細かいアクセス制御（認可）が可能 • 「Facebookから連携したIDがあれば、書き込みを許可」 • 「ID=Aなら、階層Aの下の領域だけ読み書き可能」

ID管理とリソースのアクセス制御 • サーバレス時代のマルチクラウド連携はID連携が基本 • IDを連携し、それに対するリソース側で細かい認可を制御 • JWT等を引き回すことで、「誰の」「どのアプリが」アクセスして きたのかをコンポーネント間で連携 • プログラムは「整合性」のための最小限に留まるのでは • 「ガチャ」 • 「複雑なトランザクション」

主なパターン • ウェブアプリ・モバイルアプリのバックエンド • いわゆるBaaSの発展系 • サーバ側ロジックが不要ならデータストアに直接アクセス • クラウド基盤のイベント処理 • 「ピタゴラ装置」的に動画共有サイトを実現する事例など • AWS Lambdaは「イベント」をたくさん用意したのが勝利の鍵 • 運用の自動化では既に多数の事例 • イベントのストリーミング処理 • さいきんはやりのLINE Botを手軽に実現する事例など

サーバーレスアーキテクチャの今と未来 •今 • • • • 基本機能は揃い始め、既に適用しやすい領域ではメリット大 「小さく始める」領域では、もうデメリットは小さい 管理ツールなどが見えてきた テスト手法、CI/CDのやり方や開発フレームワークの整備はこれから • 未来 • ID管理とリソース側の認可だけでできることが増え、 「サーバが全ての面倒を見る設計じたいが陳腐化していくのでは • FaaSがエッジコンピューティング側にも拡がっていく第一歩 「次の集中から分散への波」

まとめ • ふたつのサーバーレスアーキテクチャ • ステートレスなソフトウェアを前提としたフルマネージドな実行環境 • クラウドコンポーネントを活用するリアクティブなアーキテクチャ設計 • どちらも良いシステムを導くための「良い制約」 ＝クラウドが提供するベストプラクティスの活用 • 大手クラウドの提供する「サーバーレス」の違い • サーバーレスなシステムを設計するときの指針 • リアクティブシステム • ID管理とリソース側での細かい認可

で、誰？ • 通称Aki (@nekoruri) • BLEなIoTシステムの クラウド側担当 • ちょろっと執筆も • 「薄い本」も出しています • C92でます！(金曜) • 最近はすっかり セキュリティ教育畑に…… • セキュリティ・キャンプ プロデューサー • SecHack365 実施協議会委員 • ProjectDIVA Arcade LV.624 NEW!