サーバレスアーキテクチャ概論

Size: px

Start display at page:

Download "サーバレスアーキテクチャ概論"

さみひでやま
5 years ago
Views:

1 Internet Week 2017 S7 IoT もおまかせ! サーバーレスで変わるインフラとの関わり方サーバーレスアーキテクチャ概論株式会社 WHERE IoT 基盤センター仲山昌宏

2 自己紹介株式会社 WHERE IoT 基盤センターサービスプロデューサー (2016-) セキュリティキャンプ (2015-) 講師プロデューサー SecHack365 実施協議会 (2017-) 技術系同人誌サークルめもおきば ProjectDIVA Arcade LV.624

3 本セッションについてサーバーレスと呼ばれる技術ムーブメントについて 1. ぶっちゃけ何を指しているのか 2. エンジニアにとってどんな変化をもたらすのか 3. 活用するにはどのような視点が必要になるのかこれらを紹介します

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

5 サーバーレスアーキテクチャの歴史 2008 年 2012 年 2014 年 2015 年 2016 年 2017 年 Google App Engine プレビューリリースサーバーレスな PaaS として一つの完成形 Serverlessというテクニカルターム登場 Why The Future Of Software And Apps Is Serverless AWS Lambda リリース日本語圏で広く知られるきっかけとなる記事サーバーレスアーキテクチャという技術分野についての簡単な調査 Azure Functions Bluemix OpenWhisk 正式リリース Google Cloud Functions ベータ公開各社から継続的な機能拡張

6 サーバーレスアーキテクチャ自分で管理するサーバを無くすための二つの方針 1. フルマネージドなアプリケーション実行環境を活用することで開発や運用におけるサーバという単位を廃する 2. クラウド上のコンポーネントをイベント駆動で結びつけて最大限活用していくシステムアーキテクチャ ( そもそも自分で用意する機能そのものを減らす )

7 1. フルマネージドなアプリケーション実行環境いわゆる FaaS(Function as a Service) 関数と呼ばれる小さなコードを動かすマネージドサービス様々な呼び出し方法を用意 HTTP リクエスト ( 同期呼び出し ) メッセージキューやストレージ等からのトリガー ( 非同期呼び出し ) 各社サーバーレスの中心人物 AWS Lambda Azure Functions Google Cloud Functions Bluemix OpenWhisk FaaS 以外の形態もあるが今回は割愛

8 1. フルマネージドなアプリケーション実行環境 IaaS PaaS FaaS アプリケーションアプリケーションアプリケーション ( 関数 ) セルフサービスフレームワークミドルウェアフレームワークミドルウェアイベント連携フレームワークミドルウェア OS OS OS 物理 / 仮想マシン物理 / 仮想マシン物理 / 仮想マシン

9 1. フルマネージドなアプリケーション実行環境自分のコードを持ち込む (Bring Your Own Code) だけ = サーバの面倒を自分で見なくてよい実際のマシン上にコードや依存ライブラリを展開権限に紐づくアクセスキー等の設定配布コードを動かすアプリケーションプロセスの起動呼び出し元からのデータ受け取りログを外部ストレージに転送保存需要に応じたマシンの追加削除とロードバランシング実際の使用リソースに基づいた課金

10 1. フルマネージドなアプリケーション実行環境確保した量から使用した量へのシフト所有から利用の次の段階確保したサーバ台数 ( 箱の大きさ ) に課金するのでは無く実際に使用した実行時間 ( 中身の大きさ ) に課金をする ( 勝手に ) クラウド側が自動でスケールさせるサーバ内にファイル置いたりすると消える The twelve-factor app などステートレスなアプリケーションのためのベストプラクティスな制約の普及メガクラウドの物量作戦

11 参考 :The Twelve-Factor App I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルドリリース実行 VI. プロセス VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発 / 本番一致 XI. ログ XII. 管理プロセス 12

12 1. フルマネージドなアプリケーション実行環境いわゆる PaaS(Heroku 等 ) との違い明確な定義の違いは無くスケールのしやすさで区別個人的には 1 秒ぐらいで上がってくるならいいのでは?

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

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

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

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

17 AWS Lambda 主なイベントソース単独では AWS API からのみ実行可能手動実行定期実行 HTTP API:API Gateway データストア :S3 DynamoDB Cognito メッセージ配信 :Kinesis Streams Simple Notification Service 外部連携 :Simple Service Echo 管理 :CloudFormation CloudWatch Logs/Events AWS Config 実行権限とアクセスコントロール IAM Role による権限管理とリソース側での認可 Cognito Identity で AWS 側の一次トークンに紐付け

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

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

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

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

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

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

24 サーバーレス時代の指針 : 全てを分散システムの流儀で考えるリアクティブシステム ID 管理とリソースへのアクセス制御

25 リアクティブシステム分散システムのベストプラクティス素早くかつ安定した応答時間を保つ (= リアクティブな ) システムを設計するためのベストプラクティスいわば The Twelve Factor App のレイヤー高い版 4 つの特徴を定義目的 : 即応性要件 1: 耐障害性要件 2: 弾力性手段 : メッセージ駆動

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

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

28 ID 管理とリソースのアクセス制御外部サービスこれまで : 全ての権限を持つアプリケーションが入口で認証アプリケーション内部で認可制御 A さんは管理者だからとが可能 App マイクロサービス DB これから認証システムがトークンを発行各サブシステム ( マイクロサービス ) が個別に認可トークンに管理者という属性があるのでという操作を許可マイクロサービス A さんに管理者という属性を入れたトークンを送信認証システム DB 外部サービス

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

30 クライアントアプリからの 2-tier 構成クライアントアプリを経由した ID 連携 mbaas(cognito や Firebase) 等がすでに確立しているそもそも高レベルのデータストア等があり ID 基盤のうえで細かいアクセス制御 ( 認可 ) が可能 Facebook から連携した ID があれば書き込みを許可 ID=A なら階層 A の下の領域だけ読み書き可能

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

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

33 サーバーレス時代のエンジニア像餅は餅屋戦略への転換が必要自分が所有するべき得意分野である技術領域は何かその領域を最大化するためには何が必要か所有する必要が無い技術の放棄時間は有限人も有限選択と集中が求められているだいたいのことはクラウドベンダーの方が自分より上手くできるクラウドベンダーのかんがえたベストプラクティスとはいえ抑えている方がつぶしはきく

34 いわゆるサーバ系技術の今後サーバの設計構築運用系の技術純粋に必要が無くなる領域もある例 : ディスク障害時の迅速なベンダー連絡方法形が変わるだけの領域もある例 : システムの監視プライベートクラウドの需要は当面続く自らが組織内クラウドベンダーとしてパブリッククラウドと闘う当然全てのスキルセットが必要となる

35 Infrastructure as Code 普及期準備は整っている API 経由で全てが制御できる Hashicorp Terraform などのツールエコシステムの整備オンプレミス環境でも十分に採用可能もはや手作業が許されなくなる時代サーバ環境の変更履歴を残すことの重要性が増している人間は必ずミスをする手作業の余地を減らすのは義務働き方改革同じ場所から作業するわけですらない

36 これからの付加価値クラウドベンダー特化の知識膨大に存在するクラウド上のコンポーネントの知識実際にその構成でどれくらいいけるのかという実績ノウハウ一般的なシステムアーキテクチャの知識クラウドの背後に存在するシステムへの理解を踏まえた最適化例 :DB やネットワークなど高い品質のサービスを安価にリスク少なく実現できる技術選択方針

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

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション NEC モバイルバックエンド基盤入門応用編 ver 7.5.0 2018 年 10 月 1 日日本電気株式会社 Push 通知クライアントへの Push 通知 : APNs / FCM Android / ios で使用可能ユーザがアプリを起動していなくてもサービス提供側からスマートフォンやタブレットにメッセージを送る仕組みモバイル機器はプラットフォーム毎に Push 通知の仕組みが提供されています