Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

サーバーレス時代の システム設計ワークショップ

20180817 seccamp serverless

  • Be the first to comment

  • Be the first to like this

サーバーレス時代の システム設計ワークショップ

  1. 1. サーバーレス時代の システム設計ワークショップ 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア 仲山 昌宏 ( @nekoruri )
  2. 2. 仲山 昌宏 / @nekoruri • 株式会社WHERE IoT基盤センター サービスプロデューサー(2016-) • セキュリティ・キャンプ(2015-) 講師・プロデューサー • SecHack365 実施協議会(2017-) • 技術系同人誌サークル「めもおきば」 • #ssmjp / #qpstudy / #serverlesstokyo • ProjectDIVA Arcade LV.631 2
  3. 3. 経歴 • 2003-09~2005-03 大学院ネットワーク管理 • 2004-03~2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09〜2005-10 国際大学GLOCOM (研究アシスタント) • 2005-08〜2008-09 AIP • 2008-10〜2009-12 KBB, I&D • 2010-01〜2013-06 Xtone • 2013-07〜2016-01 CyberAgent (パシャオク⇒Ameba⇒DC運用) • 2016-02〜現職 WHERE (IoTスタートアップ) ⬅今ここ 学 生 社 会 人 1999-04 ↓ 2006-03 2006-03 ↓
  4. 4. 経歴 • 2003-09~2005-03 大学院ネットワーク管理 • 2004-03~2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09〜2005-10 国際大学GLOCOM (研究アシスタント) • 2005-08〜2008-09 AIP • 2008-10〜2009-12 KBB, I&D • 2010-01〜2013-06 Xtone • 2013-07〜2016-01 CyberAgent (パシャオク⇒Ameba⇒DC運用) • 2016-02〜現職 WHERE (測位技術スタートアップ) ⬅今ここ SNS CGM ソーシャルゲーム IoT
  5. 5. 主なスキルセット • システム設計 • クラウドとIoTデバイス組み合わせて 良い感じのシステム/ソリューション • ウェブアプリの内部アーキテクチャ • アプリケーション開発 • サーバーレス構成なサーバサイド • 普通のサーバサイド(+フロント) Perl、Ruby、Python、JS、PHP • 過去にはWindowsアプリとかも • 情報システム • 社内ITシステムの設計、運用 • 情報セキュリティマネジメント • サーバ/ネットワーク運用 • サーバHW(特にストレージ)周り • IPネットワーク • 「必要があればなんでもやる」 5
  6. 6. この講義の進め方 • アイスブレイク • サーバーレスという技術について • そもそも何? • サーバーレスっぽいシステムとは • 演習 • サーバーレスなシステムを作ってみよう • まとめ 6
  7. 7. アイスブレイク • 自己紹介 • クラウド使ってる? • サーバーレスに対する思い、感想 • ひとり1-2分くらい 7
  8. 8. 「サーバーレス」って何 • FAQ • サーバあるじゃん • 人任せにしてるだけじゃないの 8
  9. 9. 「サーバーレス」って何 • FAQ • サーバあるじゃん • 人任せにしてるだけじゃないの • まずは「クラウド」についておさらい 9
  10. 10. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら? 10
  11. 11. 経歴 • 2003-09~2005-03 大学院ネットワーク管理 • 2004-03~2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09〜2005-10 国際大学GLOCOM (研究アシスタント) • 2005-08〜2008-09 AIP • 2008-10〜2009-12 KBB, I&D • 2010-01〜2013-06 Xtone • 2013-07〜2016-01 CyberAgent (パシャオク⇒Ameba⇒DC運用) • 2016-02〜現職 WHERE ⬅今ここ 学 生 社 会 人 1999-04 ↓ 2006-03 2006-03 ↓
  12. 12. 前職某社の例 (株式会社サイバーエージェント) • メディアとゲームとネット広告の会社 • 半分が広告事業 • 広告の配信システム • 広告の代理業 • 残りの半分がゲーム+メディア • AbemaTV、AWA、アメブロ • グラブル、デレステ、ガルパ 12 https://www.cyberagent.co.jp/ir/strategy/
  13. 13. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら? • 2018年3Qのゲーム事業売上高:355億円(四半期決算) (2018/04/01~2018/06/30:91日間) 13
  14. 14. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら? • 2017年3Qのゲーム事業売上高:355億円(四半期決算) (2018/04/01~2018/06/30:91日間) • 1時間あたり1,625万円 14
  15. 15. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら? • 2017年3Qのゲーム事業売上高:355億円(四半期決算) (2018/04/01~2018/06/30:91日間) • 1時間あたり1,625万円 • 1分間あたり27万円 • ピークタイム(稼ぎどき) • 人気キャラのガチャ • イベントのラストスパート 15
  16. 16. サービスの運用とは • 目的: • ITを使って「お金を稼ぐ」 • 手段: • お客さんにサービスを提供し、その対価を受け取る (直接部門) • 従業員↑にサービスを提供し、生産性を向上させる (間接部門) 16
  17. 17. サービス運用の価値 • サービスの品質 • サービスの内容がお客さん の期待を満たすこと • サービスの稼働率 • 使いたいときに使える (落ちていない)こと 17 <時間単価> × <稼働時間>
  18. 18. サービス運用の価値 • サービスの品質 • サービスの内容がお客さん の期待を満たすこと • サービスの稼働率 • 使いたいときに使える (落ちていない)こと 18 <時間単価> × <稼働時間> • 便利、楽しい • 需要を満たす • 不具合が少ない • レスポンスが速い • 止まらない
  19. 19. 経歴 • 2003-09~2005-03 大学院ネットワーク管理 • 2004-03~2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09〜2005-10 国際大学GLOCOM (研究アシスタント) • 2005-08〜2008-09 AIP • 2008-10〜2009-12 KBB, I&D • 2010-01〜2013-06 Xtone • 2013-07〜2016-01 CyberAgent (パシャオク⇒Ameba⇒DC運用) • 2016-02〜現職 WHERE ⬅今ここ 学 生 社 会 人 1999-04 ↓ 2006-03 2006-03 ↓
  20. 20. 小規模 PoC 大規模 PoC 商用化 (量産) IoTビジネス • たくさんのPoC(概念実証・実証実験)が必要 • 徐々に大きく育てる • 目指すは商用化 20
  21. 21. 現実 • 「PoC貧乏」 • とにかく小規模PoCの数が多い • やりたいことが少しずつ違う 21
  22. 22. 現実 • 某社で1ヶ月に立ち上げたシステムの数 22 オフレコ
  23. 23. IoTビジネスの特徴 • 「何もかもが速い・早い」 • お客さんの予算内でできることを迅速に提供 • できなければ置いていかれるだけ • 「やりたい事」に応じたカスタマイズ • センサーの種類やデータの送信頻度など • 1時間ごとの生存確認と、100msごとに居場 所送信ではデータの扱い方がまったく異なる 23
  24. 24. IoTビジネスの特徴 • 「何もかもが速い・早い」 • お客さんの予算内でできることを迅速に提供 • できなければ置いていかれるだけ • 「やりたい事」に応じたカスタマイズ • センサーの種類やデータの送信頻度など • 1時間ごとの生存確認と、100msごとに居場 所送信ではデータの扱い方がまったく異なる 24 開 発 す べ き 機 能 ( カ ス タ マ イ ズ 部 分 ) へ の 注 力
  25. 25. クラウドの活用 • 安定したサービス運用 • 品質 × 稼働率 • 開発すべき機能への集中 • 運用コストの削減、障害等による割り込みリスクの排除 • これらのためにクラウドを徹底活用 25
  26. 26. 「クラウド」 26
  27. 27. クラウドコンピューティング 27 共用の構成可能なコンピューティングリソース (ネットワーク、サーバー、ストレージ、アプリケーション、サービス) の集積に、 どこからでも、簡便に、必要に応じて、 ネットワーク経由でアクセスすることを可能とするモデルであり、 最小限の利用手続きまたはサービスプロバイダとのやりとりで 速やかに割当てられ提供されるもの https://www.ipa.go.jp/files/000025366.pdf
  28. 28. クラウドコンピューティング 28 共用の構成可能なコンピューティングリソース (ネットワーク、サーバー、ストレージ、アプリケーション、サービス) の集積に、 どこからでも、簡便に、必要に応じて、 ネットワーク経由でアクセスすることを可能とするモデルであり、 最小限の利用手続きまたはサービスプロバイダとのやりとりで 速やかに割当てられ提供されるもの https://www.ipa.go.jp/files/000025366.pdf
  29. 29. クラウドコンピューティング • 要点 • 共用されたリソースプールから • いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 29
  30. 30. クラウドの特徴 NIST(米国国立標準技術研究所)による基本特徴の整理 1. オンデマンド・ セルフサービス APIでなんでもできる 2. 幅広いネットワークアクセス ネットワーク経由でできる 3. リソースの共用 共用する潤沢なリソースプールがある 4. スピーディな拡張性 すぐに利用可能 5. サービスが 計測可能であること 自らの利用量が適切に計測(されて課金される) 30
  31. 31. クラウドの分類 運用方法による分類 • パブリッククラウド • 大規模な事業者が運用して数多くの利用者が共有 • AWSとかAzureとかいろいろ • プライベートクラウド • 社内で単独で運用 • YahooとかCyberAgentとか 31
  32. 32. パブリッククラウド • 大規模な事業者 • 豊富なリソースにもとづく最適化 • 膨大な開発能力にもとづく多種多様な機能 • 責任共有モデル • ざっくりOSから下は事業者がセキュリティを担保 • 各種セキュリティガイドラインへの準拠 • むしろベストプラクティスが実装された環境 • OSとその上は利用者がセキュリティを自力で担保 32
  33. 33. プライベートクラウド • 既存の自前でデータセンタ借りてサーバ置くモデル • OpenStackなどのクラウドコントローラでクラウド化 • 基本機能はAmazon等と似たようなことができる • 多種多様な機能は少ない • プライベートでの差別化 • 既にノウハウや購買力を持つ場合 • システム間が密結合(消極的理由) • これらを維持しつつ、クラウドや仮想化のメリットを享受 • 社内の「クラウド事業者」部門 33
  34. 34. 「所有」から「利用」へ • サーバを所有しない • サービス部門は物理的なサーバを直接持たない • サーバやデータセンター、ネットワークの管理をしない • サーバは利用する • 必要な時間だけ、サーバの利用権を買う(借りる) • その道の匠が設計した素敵なサーバ環境を利用できる • 彼らの考えた「ベストプラクティス」に自分を合わせる 34
  35. 35. 「所有」から「利用」へ • そもそも所有するべき技術を絞り込む • クラウド基盤の運用は、自分たちのビジネス領域では無い • 自ら技術者を確保するコストは決して安くない • 「利用」することで、自らのコア事業に集中できる ↔「技術」があることは悪では無い • 内部を知っているほど最適な設定が導き出せる • トラブルシュート(とにかく全方位の能力が問われる) 35
  36. 36. クラウドのサービス分類 サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 • DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能(FW、LB等)も提供されたりする。 36
  37. 37. クラウド(IaaS)でサーバを確保 • 自由なサーバの追加・削除が可能になる • すぐ(数分程度)にサーバが増やせる! ↔ これまでは最大想定分だけのサーバを事前に用意 ↔ 想定を超えるとすぐに対応ができない • 要らないサーバはいつでも捨てられる! ↔ 資産の耐用年数(5年程度)を使い切れない ↔ 挑戦的なサービスをリリースできない 37
  38. 38. 「ペット」から「家畜」 • これまで:サーバ=ペット🐕🐕🐕🐕 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • いま:サーバ=家畜🐖🐖🐖🐖 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す。慈悲は無い。 38
  39. 39. 「メリハリ」を付けよう • Statelessサーバ 🐖🐖🐖🐖 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐕🐕🐕 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 39
  40. 40. 「ペット」から「家畜」、その先へ…… • これまで:サーバ=ペット🐕🐕🐕🐕 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • いま:サーバ=家畜🐖🐖🐖🐖 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す。慈悲は無い。 • これから:サーバーレス=……? 40
  41. 41. サーバーレス is 何 • クラウドの流れを踏まえて、 どんなものをイメージしますか? 41
  42. 42. サーバーレス is 何 • 権威のありそうな定義はまだ存在しない • 「サーバーレス」と呼ばれる「技術ムーブメント」は 明確に存在している • Serverless Architecture • Serverless Computing • Serverless .* • 今回は、後付けでそれを整理した考え方を紹介 42
  43. 43. サーバーレス 43 「Serverless」の本質 = 「サーバの抽象化」 <運用面> フルマネージドサービスの活用 ・FaaS ・Functional SaaS <開発面> イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
  44. 44. サーバーレス 44 「Serverless」の本質 = 「サーバの抽象化」 <運用面> フルマネージドサービスの活用 ・FaaS ・Functional SaaS <開発面> イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
  45. 45. 背景:サーバ・計算機の抽象化 • サーバ、もしくは「計算機」の抽象化 • サーバーレスという考え方の原点 • コンピュータサイエンスの進化の歴史そのもの • 抽象化して再利用性を高める • 分割して統治する 45
  46. 46. 背景:サーバ・計算機の抽象化 DSL(SQL等) プログラミング言語 アプリケーションコンテナ(Docker) Linux PCアーキテクチャ 46 抽象化の度合い 自由度・制約の緩さ
  47. 47. 背景:サーバ・計算機の抽象化 DSL(SQL等) プログラミング言語 アプリケーションコンテナ(Docker) Linux PCアーキテクチャ 47 抽象化の度合い 自由度・制約の緩さ ベアメタル 開発 コンテナ SQL 設定JSON 関数 バイナリ パッケージ
  48. 48. 背景:サーバ・計算機の抽象化 DSL(SQL等) プログラミング言語 アプリケーションコンテナ(Docker) Linux PCアーキテクチャ 48 抽象化の度合い 自由度・制約の緩さ ベアメタル 開発 コンテナ SQL 設定JSON 関数 バイナリ パッケージ
  49. 49. サーバーレス 49 「Serverless」の本質 = 「サーバの抽象化」 <運用面> フルマネージドサービスの活用 ・FaaS ・Functional SaaS <開発面> イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
  50. 50. 運用面: フルマネージドサービスの活用 • 抽象化の「向こう側」をクラウドにお任せ • おさらい:「所有から利用へ」 • 「フル」マネージドサービス • スケーラビリティや冗長性の確保などまで踏み込んで、 クラウド側に運用の全てを委託 50
  51. 51. 51 Ant Stanley - Being Serverless https://www.slideshare.net/acloudguru/ant-stanley-being-serverless =クラウドサービス
  52. 52. 52 Ant Stanley - Being Serverless https://www.slideshare.net/acloudguru/ant-stanley-being-serverless =クラウドサービス
  53. 53. 背景:サーバ・計算機の抽象化 DSL(SQL等) プログラミング言語 アプリケーションコンテナ(Docker) Linux PCアーキテクチャ 53 抽象化の度合い 自由度・制約の緩さ ベアメタル 開発 コンテナ SQL 設定JSON 関数 バイナリ パッケージ
  54. 54. 運用面: フルマネージドサービスの活用 • Functional SaaS • なんらかの具体的な機能を提供 • クラウド時代のミドルウェアやライブラリに相当 • プログラムというよりは、設定やDSLで動作を決める • Function as a Service • 自分の書いたプログラムを動かす実行環境の抽象化 • 「関数」という単位でソフトウェアを管理 ※関数の代わりにコンテナを使うものもある 54
  55. 55. Functional SaaS • 個別の機能を提供 • データベース • メッセージキュー(待ち行列) • メール送信 • etc. • Backend as a Service(BaaS)と呼ばれる • 「機能の提供」に重きを置いて、ここではFunctional SaaS にて統一 55
  56. 56. AWS 56
  57. 57. Azure 57
  58. 58. Function as a Service • 自分の書いたプログラムを動かす実行環境の抽象化 • プログラムをクラウドに展開 • 決められたハンドラ関数が直接呼び出される • 実際の動作マシン台数などはクラウドが管理 • 需要に応じて増減してくれる • ステートレスなどの制約が課される 58
  59. 59. サーバーレス 59 「Serverless」の本質 = 「サーバの抽象化」 <運用面> フルマネージドサービスの活用 ・FaaS ・Functional SaaS <開発面> イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
  60. 60. 開発面: イベントドリブンなシステムアーキテクチャ • 非同期・疎結合な分散システムとして設計する 60
  61. 61. 開発面: イベントドリブンなシステムアーキテクチャ • モノリシックなアプリケーション • アプリケーションが外にあるものを呼び出す • 例:データベースサーバ、外部システム 61 Client App Server App DB 外部 システム
  62. 62. 開発面: イベントドリブンなシステムアーキテクチャ • イベントドリブンなアプリケーション • アプリケーションは外にあるものから呼び出される 62 Client App 非同期 処理 外部 システム 認証システム DBにファイル送信 非同期 処理 外部 システム
  63. 63. ピタゴラ装置的な例 •Amazon S3に動画ファイルをアップロード ⇒それをトリガにしてフォーマット変換を起動 ⇒変換が終わったら動画一覧を再生成 ⇒生成できたらCDNのキャッシュをクリア ⇒全部終わったら投稿者にメール •複雑な機能を、連鎖させて作りあげる 63
  64. 64. 開発面: イベントドリブンなシステムアーキテクチャ • クラウド時代の制御の反転(Inversion of Control) • アプリケーション開発において、ライブラリを呼ぶのでは 無く、フレームワークから呼ばれるビジネスロジックに注力 • 例:Webアプリで GET / で呼ばれるハンドラメソッド • 自分のプログラムは必要な時だけ呼ばれる存在へ 64
  65. 65. サーバーレス 65 「Serverless」の本質 = 「サーバの抽象化」 <運用面> フルマネージドサービスの活用 ・FaaS ・Functional SaaS <開発面> イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
  66. 66. • ここらで休憩 66
  67. 67. サーバーレス開発の勘所 • 全体を疎結合に保つ • リアクティブシステム • ID管理 • Function as a Service • 制約とうまく付き合っていく • Functional SaaS • 様々な性質を広く知りソムリエ力を鍛える 67
  68. 68. リアクティブシステム • 目的:即応性 • システム全体として、素早く、かつ安定した応答時間を保つ • 要件1:耐障害性 • 障害が発生しても、それをコンポーネント内部に影響を隔離すること で、システム全体としての即応性を保つ。 • 要件2:弾力性 • 負荷の増減があっても、ボトルネックを排除し、割り当てるリソース を調整することで、即応性を保つ。 • 手段:メッセージ駆動 • 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。
  69. 69. リアクティブシステム • メッセージ駆動(手段) • システム間をキューで非同期に接続する • 複数のワーカプロセスがキューから取ってきて処理 • 弾力性(要件2) • メッセージが増えてきたらワーカプロセスを増やせばよい • 横並びのワーカプロセスに相互依存はないので気軽にスケールアウト・イン • 耐障害性(要件1) • コンポーネントで異常が起きたら自爆して、別のワーカが実行 • ずっとおかしいメッセージはDead letter queueに積み替えて例外処理 • 即応性(目的) • 様々な状況に強いシステムが構築できる
  70. 70. リアクティブアーキテクチャ • ざっくり言うと、 • 小さなプログラムを • メッセージ駆動で • 繋いでいく という非同期型アーキテクチャが良い、という考え方 • もっと超ざっくり言うと • メッセージキューを挟んで繋げ 70
  71. 71. リアクティブアーキテクチャ • 「ペットから家畜へ」を踏まえたアーキテクチャ 71 メッセージ ワーカー ワーカー ワーカー ワーカー ワーカー ワーカー
  72. 72. リアクティブアーキテクチャ • 「ペットから家畜へ」を踏まえたアーキテクチャ 72 メッセージ ワーカー ワーカー ワーカー 他の誰かが実行 ワーカー ワーカー ワーカー
  73. 73. ID管理とセキュリティ • これまで • アプリケーションがその中で利用者を認証・認可 • 脆弱性はアプリケーションの実装方法によるもの 73 Client App Server App DB 外部 システム ユーザを識別・認証 そのユーザに許される操作 をアプリケーション内で 判断(認可)し実行
  74. 74. ID管理とセキュリティ • これから • 小さなアプリケーション⇒実装レベルの脆弱性は減少してほしい… • 脆弱性は設計や呼出し方法によるもの • ID管理に基づいたコンポーネント単位の認可がより重要に 74
  75. 75. ID管理とセキュリティ • 認証(ID基盤)と認可(クラウドサービス)の分離 75 Client App 非同期 処理 外部 システム 認証システム 非同期 処理 外部 システム 認証トークン 認証トークン内の 属性などを見て 操作を「認可」 IDやパスワード、証明書など を使ってユーザを「認証」 認証トークンを返す
  76. 76. Function as a Service • 関数と呼ばれる小さなコードを動かすクラウドサービス • 各社「サーバーレス」の中心人物 AWS Lambda、Azure Functions Google Cloud Functions、Bluemix OpenWhisk • アプリのプロセス起動・終了をクラウドに任せる ⇒ プロセス内にデータを保存することができない(Stateless) • 「Stateless」という制約を受け入れることで、 「フルマネージド」というメリットが得られる
  77. 77. Function as a Service • 「フルマネージドなPaaS」の発展系 • 利用者にとって「サーバ」という管理単位をなくしたい • その筋のプロである「クラウド事業者」が、それぞれの方法 で適切に管理してくれる=フルマネージド • 使う量(確保量)から使った量(使用量)へのシフト • 事前に「台数」の確保が不要 • 短時間で起動し、必要なだけ拡張 • 実際の実行時間(たとえば100ms単位)で課金される
  78. 78. Function as a Service • いわゆるPaaSとの違い • 明確な定義の違いは無く、スケールのしやすさで区別 • 実装論はGMOペパボのFastContainerあたりの議論が分かりやすい • 講義B1の資料後ろの方を参照 https://twitter.com/adrianco/status/736553530689998848
  79. 79. Function as a Service • 対応言語 79 AWS Lambda Azure Functions Google Cloud Functions IBM Cloud Functions JavaScript (Node.js) Node.js v6.10 Node.js v8.10 Node.js 6.11.2 Node.js 8.4以降のLTS[preview] Node.js 6.14.0 Node.js 8.11.1 [beta] Node.js v6.9.1 Python Python 3.6 Python 2.7 [実験的リリース] Python 2.7 Python 3.7.0 [beta] Python 3.6.1 Python 2.7.12 Java Java 8 Java [preview] Java .NET / C# .NET Core 1.0.1 .NET Core 2.0 .NET Core 2.1 .NET Framework .NET Core その他 Go 1.x [実験的リリース] F# PHP 5.6 Batch(.bat) Bash(.sh) PowerShell(.ps1) Swift 3.1 PHP Docker Node.js 6.x(一つ前のLTS)が共通言語 Pythonの対応が伸びている Java/.NET Coreが追いかけている
  80. 80. Function as a Service • AWS Lambda 80 exports.handler = (event, context, callback) => { // TODO implement callback(null, 'Hello from Lambda’); };
  81. 81. Function as a Service • AWS Lambda 81 exports.handler = (event, context, callback) => { // TODO implement callback(null, 'Hello from Lambda’); }; 処理が終わったらcallbackを呼ぶ 引数1: エラーを返す 引数2: 関数の戻り値 入力は引数1のeventとして渡ってくる。 eventの中身は、例えばHTTPリクエスト の場合、Amazon API Gatewayという 別サービス側の設定に依存
  82. 82. Function as a Service • Azure Functions 82 module.exports = function (context, req) { context.log('JavaScript HTTP trigger function processed a request.’); if (req.query.name || (req.body && req.body.name)) { context.res = { // status: 200, /* Defaults to 200 */ body: "Hello " + (req.query.name || req.body.name) }; } else { context.res = { status: 400, body: "Please pass a name on the query string or in the request body" }; } context.done(); };
  83. 83. Function as a Service • Azure Functions 83 module.exports = function (context, req) { context.log('JavaScript HTTP trigger function processed a request.’); if (req.query.name || (req.body && req.body.name)) { context.res = { // status: 200, /* Defaults to 200 */ body: "Hello " + (req.query.name || req.body.name) }; } else { context.res = { status: 400, body: "Please pass a name on the query string or in the request body" }; } context.done(); }; レスポンスをcontext.resにセットして context.done()で終わる HTTPリクエストであればreqに中身が入ってくる ログは context.log
  84. 84. Function as a Service • このように少しずつ関数のインターフェースが異なる • けど、受け渡す内容はだいたい一緒 • 自前で抽象化レイヤーを挟んでおくのがよい • 対応言語の壁もあるものの、標準化されて欲しい • ベンダーロックインを怖がる必要はあまりない 84
  85. 85. Function as a Service • AWS LambdaはHTTPを直接受けられない • Amazon API Gatewayを利用 • API Gateway側でHTTPと関数入出力を変換 • 変換の仕方を柔軟に指定できる = 一般化されていない(制約になっていない) 85
  86. 86. Function as a Service • Azure Functionsの入出力バインディング • 関数を実行する「トリガー」と別に入出力を行う • 例: • トリガーの値を元にDBクエリ • 関数の返り値を別のキューやDBに保存 • 単純な処理をより単純に実装可能 • 副作用の無い素直な「関数」として書ける • そもそも保存処理やエラーハンドリングを自分で書かなくて良い 86
  87. 87. Functional SaaS • 様々な個別の機能を提供するクラウドサービス • クラウド時代のミドルウェアやライブラリに相当 • DB、キュー、メール送信、etc. • クラウド毎の差異はここにある • 「ベンダーロックイン」と捉えるか • 「自分に向いたものを選択できる」と捉えるか 87
  88. 88. Functional SaaS • たとえばNoSQLデータベース • AWS DynamoDBやAzure CosmosDB • 共通 • 性能を数値で指定して確保 • 「パーティションキー」で複数の物理サーバに分散される • 更新時にFaaSを起動(Streams / Change Feed) • 違い • DynamoDB:KVS的インターフェースのみ、ミニマム課金額小 • CosmosDB:SQLやグラフDB等複数のデータモデルに対応 88
  89. 89. Functional SaaS • データ保存先を分散したい • パーティションキーで振り分け • 実際はハッシュ値など 89 Key: 1-10 Key: 11-20 Key: 21-30 Key: 31-40 Key: 41-50
  90. 90. Functional SaaS • データ保存先を分散したい • パーティションキーで振り分け • 実際はハッシュ値など • ホットスポット厳禁 90 Key: 1-10 Key: 11-20 Key: 21-30 Key: 31-40 Key: 41-50 Key: 15 Key: 15 Key: 15 Key: 15 Key: 15 Key: 15 Key: 11 負荷の 偏り
  91. 91. Functional SaaS • たとえばキュー • AWSで3種類 • SQS、SNS、Kinesis Data Streams • Azureで4種類 • Storageキュー、Service Bus、Event Hubs、Event Grid • 特性が異なる • メッセージキュー or PubSubキュー • at-least-once or at-most-once • 一件ずつ or 複数件取得 91
  92. 92. 92 6 5 4 3 2 1 送信側 Producer <メッセージキュー> 受信側のどれかに届く 受信側 Consumer 受信側 Consumer 受信側 Consumer 1 2 3 4 5 6 6 5 4 3 2 1 送信側 Publisher <Pub/Subキュー> 受信側全員にすべてが届く 受信側 Subscriber 受信側 Subscriber 受信側 Subscriber 6 5 4 3 2 1
  93. 93. Functional SaaS • キューも中身はデータベース • スケーラビリティの確保も同じ 93 Kinesis Data Streams Shard Shard Shard Shard パーティションキーで 別のShardに振り分け
  94. 94. Functional SaaS • FaaSとの連携も様々 • 2種類の連携方法(ポーリングとプッシュ) 94 FaaS 定期的にポーリング ※関数がDBへのアクセス権限を持つ FaaS 関数を呼び出し ※DBが関数の実行許可を持つ
  95. 95. Functional SaaS • たとえばmBaaS • Google FirebaseやAWS Cognito • モバイルアプリ向けの機能を一体化して提供 • 他のFacebookやTwitterと連携できるID基盤とか • リアルタイムでスマホ側とクラウド側を同期するDBとか • DB更新時にFaaS呼び出したりだとか • ロックインリスクと開発効率どっちを取るのか? • 当然ながらケースバイケース • でもほとんどは開発効率では……? 95
  96. 96. 96 AWS Lambda Azure Functions Google Cloud Functions IBM Cloud Functions 直接実行 単体 単体 単体 単体 HTTP API Gateway併用 CloudFront(Lambda@ Edge) 単体 Functions Proxies併用 API Management併用 単体 単体 定期実行 CloudWatch Events併 用 単体 - 単体 メッセージ キュー SQS SNS Kinesis Streams Storageキュー Service Bus Event Hubs Event Grid Cloud Pub/Sub Message Hub データストア S3 DynamoDB Streams Cognito Sync Storage BLOB Storageテーブル CosmosDB Change Feed Cloud Storage Cloudant 管理 CloudWatch Logs CloudWatch Events CloudFormation AWS Config CodeCommit Kinesis Firehose (webhook連携) (webhook連携) (webhook連携) Chat bot Amazon Lex Bot framework - - 端末/IoT AWS IoT スマートスピーカー (Alexa) IoT Button - Firebase モバイル連携 (Push Notification) その他連携 メール(SES) Office365(Graph) - -
  97. 97. サーバーレスなシステム • 部品としてはここまで • FaaS • Functional SaaS • それらを利用したリアクティブシステム • 実際に作るためにはもっと道具が必要 • 「ソースコード管理」 • 「デプロイ」 97
  98. 98. Infrastructure as Code • クラウドサービスの構成をコード(DSL)で実装し、 それをもとにAPIをたたいて展開 • JSONや独自言語、Rubyベース内部DSLが多い • プログラミング的手法で継続的改善が可能 • Git等でのリビジョン管理、レビュー • デプロイツールの活用 • 自動テスト 98
  99. 99. Infrastructure as Code • 「プログラミングの手法」をインフラ管理に適用 • Git等によるリビジョン管理、Pull-Requestレビュー • テスト駆動 • 再利用しやすいDSL(ドメイン固有言語)による記述 • 何種類かのツール • ベンダー独立のTerraformが自由度が高い • AWS自身のAWS SAM(CloudFormationベース)もある • Azureなどもそれぞれテンプレート機能を提供 99
  100. 100. Terraform • AWSやAzureの構成をコード化 • コードに合わせて必要なサーバやクラウドサービスを作成 • 不必要になったら削除 • 独自DSL(HCL) • 信頼と安定のHashicorp 100
  101. 101. HashiCorp • クラウドを管理するツールの開発会社 • OSSでツールを提供 • Vagrant、Packer、Terraform、Serf、Consul、 Vault…… • Hashicorpのビジョン「The Tao of HashiCorp」 • 原文: https://www.hashicorp.com/blog/tao-of-hashicorp.html • 日本語訳: http://pocketstudio.jp/log3/2015/03/14/the-tao-of- hashicorp/ 101
  102. 102. Terraformの設定例 102 resource "aws_lambda_function" "test_lambda" { filename = "lambda_function_payload.zip" function_name = "lambda_function_name" role = "${aws_iam_role.iam_for_lambda.arn}" handler = "exports.handler" runtime = "nodejs8.10" environment { variables = { foo = "bar" } } }
  103. 103. Terraformの設定例 103 resource "aws_instance" "bastion" { tags { Name = "bastion" } ami = "${data.aws_ami.bastion.id}" instance_type = "t2.micro" vpc_security_group_ids = [ "${aws_security_group.internal.id}", "${aws_security_group.bastion.id}“ ] subnet_id = "${aws_subnet.shared-vpc-subnet-a.id}" associate_public_ip_address = true }
  104. 104. AWS SAMによるテンプレート 104 AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: Sample Resources: GetFunction: Type: AWS::Serverless::Function Properties: Handler: index.get Runtime: nodejs8.10 Policies: AmazonDynamoDBReadOnlyAccess Environment: Variables: TABLE_NAME: !Ref Table Events: GetResource: Type: Api Properties: Path: /resource/{resourceId} Method: get
  105. 105. Infrastructure as Code • どのツールを使うか • ツールによる対応が多いのはCloudFormation等クラウド ベンダー製のテンプレート • マルチクラウド ⇒ Terraform • 構成を少しずつカスタマイズ ⇒ Terraform 105
  106. 106. • この辺で休憩 106
  107. 107. 107
  108. 108. 演習1:Slackbot作ってみよう • 今回はseccamp 非公式Slackを利用します • まだ登録していない人は以下URLから登録 • https://bit.ly/2PgOAql 108
  109. 109. • ログイン情報(会場のみ) 109
  110. 110. Azureにログイン • ログイン • https://portal.azure.com/ • ツアーはスキップ 110
  111. 111. Function Appを作成 • 左上「リソースの作成」 • 「Serverless Function App」 111
  112. 112. Function Appを作成 • アプリ名:seccamp-自分の名前 • サブスクリプション:Visual Studio Enterprise • リソースグループ:既存 seccamp2018 • OS:Windows • ホスティングプラン:従量課金プラン • 場所:米国中部 • Storage:新規作成 • Application Insights:East US • ここまで入力したら【作成】 112
  113. 113. Function Appを作成 • 右上🔔🔔をクリックすると通知欄が開きます • デプロイメントが終わるまで待ちます • 🔔🔔をもう一度クリック して通知欄を閉じる 113
  114. 114. Function Appを作成 • メニューからFunction Appを開く • 自分のFunction Appをクリック (名前に注意) 114
  115. 115. 関数を作成 • 「関数」欄の + をクリック 115
  116. 116. 関数を作成 • 以下のように選択 • webhook+API • JavaScript • この関数を作成する 116
  117. 117. HTTPトリガーの設定を変更 • Webhookを使うので、設定を調整します • 作成された関数の「統合」をクリック 117
  118. 118. HTTPトリガーの設定を変更 • 承認レベルを 「Anonymous」に変更 • 「保存」をクリック 118
  119. 119. サンプルコードを張り付け • 関数名をクリック • 入力欄に以下の内容を張り付け • https://bit.ly/2nHPr75 • 「保存」 119
  120. 120. 作成したAPIのURLを取得 • 上部の「</> 関数の URL の取得」をクリック • 関数のURLが表示されるのでコピーして手元にメモ 120
  121. 121. Slack Outgoing Webhookを作成 • 以下のURLを開く • https://bit.ly/2vReBVb • Add Configuration をクリック 121
  122. 122. Slack Outgoing Webhookを作成 • 確認画面が出るのでもう一度Add 122
  123. 123. Slack Outgoing Webhookを作成 • 受信するChannel: #2018-b7 • URLに、先ほど取得した APIのURLを入力 • Customize Name: bot-自分の名前 • 一番下の「Save Setting」 123
  124. 124. Slackでしゃべってみよう • #2018-b7 チャンネルで何か話してみよう • 自分のbotが、「Hello」を付けて返してくれるはず! 124
  125. 125. 演習2:DBに保存してみよう • 出力バインディングという仕組みを使って、 Slackの発言内容をDBに入れてみます。 125
  126. 126. CosmosDBの作成 • 左メニューからCosmosDBをクリック 126
  127. 127. CosmosDBの作成 • 「+作成」をクリック 127
  128. 128. CosmosDBの作成 • ID:seccamp-自分の名前 • API:SQL • サブスクリプション:Visual Studio Enterprise • リソースグループ:既存 seccamp2018 • 場所:東日本 • ここまで入力したら【作成】 • 終わるまで2~3分まつ • 右上🔔🔔で確認 128
  129. 129. コレクションの作成 • 通知欄からCosmosDBを開く • 「Create “Items” collection」をクリック 129
  130. 130. FunctionからDBに出力 • メニュー「Function App」から自分の関数に戻る • HttpTriggerJS1の「統合」をもう一度開く 130
  131. 131. FunctionからDBに出力 • 「出力」欄の「新しい出力」をクリック • 「Azure CosmosDB」をクリックしてから「選択」 131
  132. 132. FunctionからDBに出力 • 以下のように入力 • ドキュメント パラメーター名:outputDocument (そのまま) • データベース名:ToDoList • コレクション名:Items • 入力できたら 右下の「新規」 をクリック 132
  133. 133. FunctionからDBに出力 • 以下のように選択 • サブスクリプション:Visual Studio Enterprise • データベースアカウント:seccamp-自分の名前 • 「選択」 133
  134. 134. FunctionからDBに出力 • 内容を確認して「保存」 • これで、出力バインディングでCosmosDBに保存する ように設定できました 134
  135. 135. ソースコード修正 • 出力バインディングにテキストを保存するよう修正 • 28行目を追加 135
  136. 136. 動作確認 • Slackでちょっと発言してみる • 自分のbotから返ってくることを確認 • CosmosDBに保存されたことを確認してみよう 136
  137. 137. CosmosDBへの保存確認 • 左メニューから CosmosDBをクリック • 自分のDBをクリック 137
  138. 138. CosmosDBへの保存確認 • 「Data Explorer」をクリック • 「ToDoList」の中の「Items」をクリック • 「Documents」をクリック 138
  139. 139. CosmosDBへの保存確認 • ドキュメントが並んでいるはずなのでクリック 139
  140. 140. 演習3:GitHubからデプロイ • GitHubにレポジトリを作って、以下のようにファイル を設置(function.jsonはブラウザ上で取得) • HttpTriggerJS1/ • function.json • index.js 140
  141. 141. デプロイ設定 • Function Appの プラットフォーム 機能のタブを開く • 「展開オプション」 をクリック 141
  142. 142. デプロイ設定 • 「セットアップ」をクリック • デプロイオプションでGitHubを選択 • 自分のユーザで連携し、作成したレポジトリを指定 • 最後まで行くと、GitHubから再デプロイされる • 適当に変更をpushしてみて反映されることを確認 142
  143. 143. ポイント • 短い関数 • 「やりたいこと」に集中しやすい • 様々な連携 • DBなどとの連携 • デプロイ等の省力化 143
  144. 144. 144
  145. 145. まとめ • サーバーレス時代のシステム設計ワークショップ • クラウドとサーバーレス • サーバーレス時代の考え方 • FaaSとFunctional SaaS • 演習 145
  146. 146. 最後に • 特にこの10年のインフラ業界は動きが早いです • クラウドが登場して(まだ)10年間 • 前提が変わり、ベストプラクティスが入れ替わる • 個人的には、 ・この10年で物理サーバからクラウド上の仮想サーバに ・今後10年でサーバという枠組みから解放 と予想しています • ツールレベルの盛衰は、一々取り上げるのも切りが無い • 動きが早い=面白い! 146
  147. 147. 最後に • すぐに手を動かそう! • 無料クーポン、無料枠を活用しよう(学生はより有利!) • 大きな機能もちょっとだけなら安くお試しできる! • とにかくネタと機会を作って情報を発信しよう! • 情報は活動する人の近くに集まる • ブログ等での情報発信 • 勉強会等での発表 • 同人誌等の制作、頒布 147
  148. 148. 148

×