Serverless Architecture

Naoya Ito 株式会社 一休 CTO

10/24 2016

先に結論

•  サーバーレスアーキテクチャとは –  単純には FaaS を使ったシステム

–  ステートレスな FaaS がリアクティブ、Microservices、コレオグラフィへと導く

•  現場感覚では「運用が楽でスケールして、安い」

•  銀の弾丸ではないが、応用領域は拡がると思われる

•  ちょっとしたタスクをこなすためや、Microservices の実現手段として、引き出しの一つに入れておいて損はない

必要になったときだけ計算

イベント駆動

Microservices Reactive オーケストレーションからコレオグラフィへ

サーバーレス

Shared Nothing

運用負担が少ない

安い

スケーラブル

得られるメリット アーキテクチャの性質

サーバーレスアーキテクチャとは

2つの「サーバーレス」

•  ハードウェア的意味での「サーバー」がない

•  常駐プロセス的な意味での「サーバー」がない –  Function as a Service (Faas) を前提に

–  今日は主にこちらの話

Function as a Service

•  AWS Lambda

•  Google Cloud Functions

•  Azure Functions

AWS Lambda

•  AWS 上で、任意の小さな関数を実行するためのサービス –  Python、Node.js、Java などで書いた関数をアップロード

–  任意のイベントを契機に、その関数を実行できる

–  イベント例 •  HTTP リクエストを受信した

•  S3 にファイルがアップロードされた

•  Kinesis のストリームのイベントが発生した

•  Amazon Simple Email にメールが届いた

•  DynamoDB に新しいアイテムが INSERT された

•  Scheduled Events (by CloudWatch)

•  ･･･

module.exports.hello=(event,context)=>{context.succeed({message:'Hello,'+event.query.username})}

#ServerlessFrameworkを利用$serverlessdeploy

Lambda ファンクションはサーバーレスで実行される

•  Lambda ファンクションはコンテナで実行される

•  コンテナは実行時に作成されて、終了時に破棄される

•  常駐プロセスではない。CGI に近いモデル –  「モダンCGI」

Lambda ファンクションはステートレスである

•  コンテナは実行時にのみ存在。状態 (ステート)を保持できない

•  ステートレス (Shared Nothing) –  何か問題が起こっても、別の実行には悪影響を与えない

–  スケールしたかったらもっと起動すればよい

AWS Lmbda はスケールするし、安い

•  イベント量に合わせて Lambda が自動でスケール –  ステートレスなので (提供者である AWS 的にも) スケールしやすい

–  気づいたら Node プロセス落ちてた ･･･ などがない。安全

•  計算した分しか費用はかからない –  Amazon EC2 ･･･ インスタンスが起動した時間分の費用

–  AWS Lambda ･･･ 実行した分のみの費用

かなりお得

「サーバーレスアーキテクチャー」

•  ごく単純化すると FaaS を利用したシステム設計アーキテクチャ

•  より本質的にはイベント駆動で系を設計した、リアクティブでコレオグラフィなマイクロサービスのこと –  なんのこっちゃ ･･･ !!

–  後述

事例

一休での事例 (1)

このサムネイルを Lambda で作成

一休の 管理画面

AWSLambda

S3bucket写真を

アップロード

イベント

サムネイル作成

S3bucket

サムネイル用

Lambda 関数はイベント駆動

AWSLambda

S3bucket

イベント

"Records":[{"eventVersion":"2.0","eventTime":"1970-01-01T00:00:00.000Z","requestParameters":{"sourceIPAddress":"127.0.0.1"},"s3":{"configurationId":"testConfigRule","object":{"eTag":"0123456789abcdef0123456789abcdef","sequencer":"0A1B2C3D4E5F678901","key":"HappyFace.jpg","size":1024},"bucket":{"arn":bucketarn,"name":"sourcebucket","ownerIdentity":{"principalId":"EXAMPLE"}},},　　...

一休での事例 (2)

採用の書類選考は Slack で Bot から依頼される

Redmine

AWSLambda

AmazonAPIGateway

以前は Heroku で Bot を動かしたりしていたがその必要がなくなった

Webhook イベント

HTTPリクエストもイベントになる

AWSLambda

AmazonAPIGateway

Webhook (HTTP) イベント

{"body":{},"method":"GET","headers":{"Accept":"*/*","CloudFront-Forwarded-Proto":"https","CloudFront-Is-Desktop-Viewer":"true","CloudFront-Is-Tablet-Viewer":"false","CloudFront-Viewer-Country":"JP","User-Agent":"curl/7.43.0","Via":"1.12d30d2b55574343a43311dd210926843.cloudfront.net(CloudFront)","X-Amz-Cf-Id":"JDBHHrMHhbxwaMfNBBTo15EICVfU8t6JHTExkGpu2W6_O4h5wBtqsg==","X-Forwarded-Port":"443","X-Forwarded-Proto":"https"},"query":{"user":"naoya","foo":"bar"},"path":{},"identity":{"accessKey":"","cognitoAuthenticationType":"","cognitoAuthenticationProvider":"","userAgent":"curl/7.43.0",}}

事例3 : 行動ログ収集基盤にも利用を進めている

AWSLambda

AmazonKinesis

GoogleBigQuery

App サーバー

S3bucket

App サーバー

AWSLambda

大規模な事例: 日経新聞社の紙面ビューアー

h(ps://speakerdeck.com/ikait/serverless-architecture-supports-nikkeis-paper-viewer

複数の Lambda がイベント連携し、システムを構成する

FaaS でイベント駆動設計を突き詰めていくと、自ずと Microservices が見えてくる

h(ps://eventdrivenapps.com/

Design and build event-driven serverless applications: distribute the logic and react to changes in your resources.

アーキテクチャ的性質を解剖する

必要になったときだけ計算

イベント駆動

Microservices Reactive オーケストレーションからコレオグラフィへ

サーバーレス

Shared Nothing

運用負担が少ない

安い

スケーラブル

得られるメリット アーキテクチャの性質

CGI はリクエスト毎に実行、終わったら破棄

•  Pros ･･･ Shared Nothing で安全、簡単

•  Cons ･･･ アプリケーション全体を毎回 fork がとても非効率

fork()HTTPRequest

HTTP

ServerWebApp

常駐プロセス prefork ･･･ プロセスを作っておいて常駐

親

子

fork()

prefork はオーバーヘッドは少なく安全だが、並行性能に難

•  例 –  アプリケーションサーバー (例: FastCGI、Puma、Jetty、IIS ...)

•  Pros –  リクエスト毎 fork() のオーバーヘッドを回避できる

–  多くは共有しないので、比較的安全

•  Cons –  スケーラビリティに難

•  メモリフットプリントが大きい。プロセス数が最大同時接続数 (C10K問題)

•  高負荷ではプロセス / スレッドのコンテキストスイッチコストが高い

イベント駆動モデルによる並行処理

時間

A B A C D B ・・・

select()/epoll()コンテキスト スイッチ

イベント駆動モデルは並行性能が高いが可用性に難

•  例 –  Node.js

•  Pros –  スケーラビリティ

•  メモリフットプリントが小さく、高い並行処理性能

•  Cons –  可用性 (耐障害性) に難

•  落ちるときは全部落ちる / メモリリーク時のリスクが大きい

起動に伴うオーバーヘッドが少なければ、毎回実行で構わないのでは･･･?

•  Pros ･･･ Shared Nothing で安全、簡単

•  Cons ･･･ アプリケーション全体を毎回 fork がとても非効率

コンテナで実行する、という発想がこれを可能にした

Shared Nothing という "制約"

•  Shared Nothing 前提 ･･･ 必要になったときだけ計算で不都合ない –  コンテナを永続化させる義務が発生しない

必要になったときだけ計算

サーバーレス

Shared Nothing

必要になったときだけ計算 → 入力をイベントとして抽象化してイベント駆動でモデル化するのは自然

必要になったときだけ計算

イベント駆動

サーバーレス

Shared Nothing

Lambda 関数 ･･･ イベントへの反応として記述する

結果、サービス間は疎結合に

反応としてのプログラミングモデル ･･･ リアクティブ

どっから来るかわからんけど、そのイベントきたらやっとくわ

h(p://www.slideshare.net/yugolf/typesafe-reacAveplaBormreacAvesystem-scalasummitkansai

必要になったときだけ計算

イベント駆動

Reactive

サーバーレス

Shared Nothing

参考: Erlang / Elixir の軽量プロセスモデル

•  Erlang VM の軽量プロセス –  Erlang/Elixir における並行処理の基盤。小さい。300ワード

–  大量に軽量プロセスを作って並行処理、で OK

–  「起動が十分に高速なら、都度実行が良い」

サーバーレスな話と似てるな～と

この手の話を突き詰めるとリアクティブに辿り着く

閑話休題、それぞれの Lambda はマイクロな関数になる

•  Lambda ファンクションは一つが一つの仕事をする

•  小さな (マイクロな) 関数をイベントで (疎結合に) 組み合わせる

ワシはこっちのイベント担当な

ワイはこっちのイベント担当や

FaaS は自然と Microservices を指向する

(それが嬉しいかどうかは別として･･･)

h(p://www.slideshare.net/danilop/building-eventdriven-serverless-apps

必要になったときだけ計算

イベント駆動

Microservices Reactive

サーバーレス

Shared Nothing

オーケストレーション vs コレオグラフィ

SOA や BPM、Microservices の文脈でビジネスプロセス構築のためにサービス間をどういうアーキテクチャで関連づけるかの議論

•  オーケストレーション (orchestration)

–  オーケストラによる演奏方法

–  中央の指揮者がサービスの呼び出しをコントロールし、ビジネスプロセスの実行を指揮する

•  コレオグラフィ (choreography) –  バレーや舞踏などのダンサーへの振り付け

–  サービスの呼び出しをコントロールしたり、ビジネスプロセスの実行を指揮する存在はいない

オーケストレーション (リクエスト・リプライ)

リクエスト

リプライ

•  自身の処理の一部を他のシステムに依頼。依頼した結果は自身の側で利用

•  サブルーチン呼び出し、メソッドインボケーションのアナロジー

–  理解しやすい。同期的なビジネスプロセスの構築に向く

コレオグラフィ (イベント駆動)

サブスクライブ

•  イベントの発生によって他の業務処理が駆動される。非同期のイベント連携

•  指揮者がいない。各サービスはイベントに駆動され、振り付けに従い、自律的に他者にイベントを送って働きかける

•  他システムが関知できないタイミングである処理が為される、予期できないタイミングである事象が発生するケースに対応するのに適する

イベント パブリッシュ

スターバックスは2フェーズコミットを使わない

•  レジの店員は注文の印をつけてキューに送る。レジ係とバリスタは分割されている –  イベント駆動、非同期

–  オーケストレーションではなく、コレオグラフィ

•  間違った飲み物を作ったら、払い戻しではなく、飲み物を捨てて作り直す

h(ps://code.google.com/archive/p/gregors-ramblings-ja/wikis/18_starbucks.wiki

コレオグラフィは疎結合でスケーラブル

•  "一般に、コレオグラフィ手法に向かう傾向が強いシステムの方が、疎結合で柔軟性があり、変更を受け入れることがわかっています。" (「マイクロサービスアーキテクチャ」, オライリー・ジャパン, P.52)

•  一方、コレオグラフィが常に正解ではない –  同期呼び出しの方が単純、適切に機能しているかがわかりやすい

•  Microservices を指向するならコレオグラフィ –  非同期のイベント連携 ･･･ 大幅に分離されたサービスを生み出せる

FaaS は自然とコレオグラフィを指向する

•  そもそもマネージドサービス間を非同期イベント連携で接続するアーキテクチャなので･･･

•  向き不向き –  オーケストレーションを前提としたビジネスプロセスの構築や置き換

えには向いてない

–  コレオグラフィ前提でモデリングできるなら、向いているかも •  「スターバックスは2フェーズコミットを使わない」を思い出そう

必要になったときだけ計算

イベント駆動

Microservices Reactive オーケストレーションからコレオグラフィへ

サーバーレス

Shared Nothing

運用負担が少ない

安い

スケーラブル

得られるメリット アーキテクチャの性質

改めて「サーバーレスアーキテクチャ」とは

•  Lambda 使ってます、というだけなら敢えて「サーバーレス・アーキテクチャ」と大仰に呼ばなくても良い気が

•  以下を自覚的に活かすのが「サーバーレス・アーキテクチャ」なのではないか? –  Microservices 実装の手段としての FaaS

–  リアクティブやコレオグラフィに向かわせる性質

サーバーレスアーキテクチャとはイベント駆動で系を設計した、リアクティブでコレオグラフィなマイクロサービスのこと •  わかりましたね!

•  こんなこと言うとバズワードおじさんと指さされること間違いなし！

雑な話

結局なくなるのはハードなのか、プロセスなのか?

•  アーキテクチャ的には常駐プロセスがなくなることが重要だけど

•  現場では、OS 的な意味でのサーバーがなくなることが重要だったりする –  メリットに直結しているため、導入の動機にしやすい

–  余剰リソースを抱えなくて済む上に安い。可用性も上がる ･･･ というインフラ側面での精神的安心感がハンパない

ぶっちゃけどうなの?

•  はまれば強い –  スケーラブル。運用工数はすごい下がる。EC2 より超安い

–  知らんうちに良いアーキテクチャに向かってたりする •  関数が小さくまとまったり、テスタビリティ高かったり

•  開発工数はそこまで削減されないかも –  FaaS 特有の (バッドなものも含む) ノウハウが必要

•  イベントがループしてサムネイルのサムネイルのサム ･･･ → ∞ とかあるある

•  同期処理したいな! 状態持ちたいな! というとき悩む

•  プログラムサイズに制限があったりする

–  ピタゴラスイッチになるのでデバッグが大変。結合テスト難しい

Microservices の具体的実現手段としての FaaS

•  Microservices の議論は実現手段を明らかにしなかった

•  FaaS を用いたサーバーレスアーキテクチャは、Microservices の具体的実現手段 (の一つ)

どういうとき使うの?

•  小さなユースケースでは積極的に使えばいい –  サムネイル作るだけ、とか、Slack 通知とか

•  大きなユースケースではいつ使うのか･･･ まだ言語化できてない –  「銀の弾丸ではない」とはみんな言う。「ここで使え！」とは言わない

–  オーバーヘッドは比較的小さいがゼロではない

–  コレオグラフィで OK なら、というのはありそう

•  サーバーレスとそうじゃないのを組み合わせる事例が増えてる –  例: 機械学習のモデル構築は普通にやって、それを利用するアプリケーショ

ンはサーバーレス

サーバーレスの今後

•  アーキテクチャ的に真っ当だし、適用範囲は拡がると思う –  特にリアルタイムなスケーラビリティが欲しいケース

•  ゲームサーバー、行動ログ収集、IoT ･･･

–  どういうときサーバーレスがいいかの議論はこれから成熟していくでしょう

–  設計方法の引き出しの一つに加えておいて損はない

•  開発環境 (フレームワーク) はもう一声欲しい。良いものは今後も出てきそう –  Serverless 1.0 が頭一つ出てるが、まだデプロイ自動化レベル

•  御三家の開発競争が盛んに。高機能化、性能向上は進む –  AWS vs GCP vs Azure

–  オーバーヘッドは技術革新でどんどん小さくなると思われる

まとめ

•  サーバーレスアーキテクチャとは –  単純には FaaS を使ったシステム

–  ステートレスな FaaS がリアクティブ、Microservices、コレオグラフィへと導く

•  現場感覚では「運用が楽でスケールして、安い」

•  銀の弾丸ではないが、応用領域は拡がると思われる

•  ちょっとしたタスクをこなすためや、Microservices の実現手段として、引き出しの一つに入れておいて損はない

参考文献 (Web)

•  サーバレスとマイクロサービスで変わるゲームサーバ開発

–  https://speakerdeck.com/kazutomo/saharesutomaikurosahisutebian-warukemusahakai-fa

•  紙面ビューワーを支えるサーバーレスアーキテクチャ

–  https://speakerdeck.com/ikait/serverless-architecture-supports-nikkeis-paper-viewer

•  Building Event-driven Serverless Apps

–  http://www.slideshare.net/danilop/building-eventdriven-serverless-apps

•  AWS Lambda in Action - Event-Driven Serverless Applications

–  https://eventdrivenapps.com/

•  Typesafe Reactive Platformで作るReactive System

–  http://www.slideshare.net/yugolf/typesafe-reactiveplatformreactivesystem-scalasummitkansai

•  コレオグラフィ vs オーケストレーション

–  http://www.fiorano.com/jp/blog/integration/integration-architecture/コレオグラフィ-vs-オーケストレーション/

•  スターバックスは2フェーズコミットを使わない

–  https://code.google.com/archive/p/gregors-ramblings-ja/wikis/18_starbucks.wiki

参考文献 (書籍)

•  Sam Newman 著, 佐藤直生 監訳, 木下哲也 訳「マイクロサービスアーキテクチャ」, オライリー・ジャパン, 2016