Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à サーバーレス時代の システム設計ワークショップ
Similaire à サーバーレス時代の システム設計ワークショップ (20)
Plus de Masahiro NAKAYAMA
Plus de Masahiro NAKAYAMA (20)
Dernier
Dernier (12)
サーバーレス時代の システム設計ワークショップ
- 1. サーバーレス時代の システム設計ワークショップ 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア 仲山 昌宏 ( @nekoruri )
- 2. 仲山 昌宏 / @nekoruri • 株式会社WHERE IoT基盤センター サービスプロデューサー（2016-） • セキュリティ・キャンプ（2015-） 講師・プロデューサー • SecHack365 実施協議会（2017-） • 技術系同人誌サークル「めもおきば」 • #ssmjp / #qpstudy / #serverlesstokyo • ProjectDIVA Arcade LV.631 2
- 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. 経歴 • 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. 主なスキルセット • システム設計 • クラウドとIoTデバイス組み合わせて 良い感じのシステム/ソリューション • ウェブアプリの内部アーキテクチャ • アプリケーション開発 • サーバーレス構成なサーバサイド • 普通のサーバサイド（＋フロント） Perl、Ruby、Python、JS、PHP • 過去にはWindowsアプリとかも • 情報システム • 社内ITシステムの設計、運用 • 情報セキュリティマネジメント • サーバ/ネットワーク運用 • サーバHW（特にストレージ）周り • IPネットワーク • 「必要があればなんでもやる」 5
- 6. この講義の進め方 • アイスブレイク • サーバーレスという技術について • そもそも何？ • サーバーレスっぽいシステムとは • 演習 • サーバーレスなシステムを作ってみよう • まとめ 6
- 7. アイスブレイク • 自己紹介 • クラウド使ってる？ • サーバーレスに対する思い、感想 • ひとり1-2分くらい 7
- 8. 「サーバーレス」って何 • FAQ • サーバあるじゃん • 人任せにしてるだけじゃないの 8
- 9. 「サーバーレス」って何 • FAQ • サーバあるじゃん • 人任せにしてるだけじゃないの • まずは「クラウド」についておさらい 9
- 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. 前職某社の例 （株式会社サイバーエージェント） • メディアとゲームとネット広告の会社 • 半分が広告事業 • 広告の配信システム • 広告の代理業 • 残りの半分がゲーム＋メディア • AbemaTV、AWA、アメブロ • グラブル、デレステ、ガルパ 12 https://www.cyberagent.co.jp/ir/strategy/
- 13. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2018年3Qのゲーム事業売上高：355億円（四半期決算） （2018/04/01～2018/06/30：91日間） 13
- 14. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2017年3Qのゲーム事業売上高：355億円（四半期決算） （2018/04/01～2018/06/30：91日間） • 1時間あたり1,625万円 14
- 15. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2017年3Qのゲーム事業売上高：355億円（四半期決算） （2018/04/01～2018/06/30：91日間） • 1時間あたり1,625万円 • 1分間あたり27万円 • ピークタイム（稼ぎどき） • 人気キャラのガチャ • イベントのラストスパート 15
- 16. サービスの運用とは • 目的： • ITを使って「お金を稼ぐ」 • 手段： • お客さんにサービスを提供し、その対価を受け取る （直接部門） • 従業員↑にサービスを提供し、生産性を向上させる （間接部門） 16
- 17. サービス運用の価値 • サービスの品質 • サービスの内容がお客さん の期待を満たすこと • サービスの稼働率 • 使いたいときに使える （落ちていない）こと 17 ＜時間単価＞ × ＜稼働時間＞
- 18. サービス運用の価値 • サービスの品質 • サービスの内容がお客さん の期待を満たすこと • サービスの稼働率 • 使いたいときに使える （落ちていない）こと 18 ＜時間単価＞ × ＜稼働時間＞ • 便利、楽しい • 需要を満たす • 不具合が少ない • レスポンスが速い • 止まらない
- 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 ↓
- 21. 現実 • 「PoC貧乏」 • とにかく小規模PoCの数が多い • やりたいことが少しずつ違う 21
- 23. IoTビジネスの特徴 • 「何もかもが速い・早い」 • お客さんの予算内でできることを迅速に提供 • できなければ置いていかれるだけ • 「やりたい事」に応じたカスタマイズ • センサーの種類やデータの送信頻度など • 1時間ごとの生存確認と、100msごとに居場 所送信ではデータの扱い方がまったく異なる 23
- 24. IoTビジネスの特徴 • 「何もかもが速い・早い」 • お客さんの予算内でできることを迅速に提供 • できなければ置いていかれるだけ • 「やりたい事」に応じたカスタマイズ • センサーの種類やデータの送信頻度など • 1時間ごとの生存確認と、100msごとに居場 所送信ではデータの扱い方がまったく異なる 24 開 発 す べ き 機 能 ( カ ス タ マ イ ズ 部 分 ) へ の 注 力
- 25. クラウドの活用 • 安定したサービス運用 • 品質 × 稼働率 • 開発すべき機能への集中 • 運用コストの削減、障害等による割り込みリスクの排除 • これらのためにクラウドを徹底活用 25
- 26. 「クラウド」 26
- 29. クラウドコンピューティング • 要点 • 共用されたリソースプールから • いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 29
- 30. クラウドの特徴 NIST（米国国立標準技術研究所）による基本特徴の整理 1. オンデマンド・ セルフサービス APIでなんでもできる 2. 幅広いネットワークアクセス ネットワーク経由でできる 3. リソースの共用 共用する潤沢なリソースプールがある 4. スピーディな拡張性 すぐに利用可能 5. サービスが 計測可能であること 自らの利用量が適切に計測（されて課金される） 30
- 31. クラウドの分類 運用方法による分類 • パブリッククラウド • 大規模な事業者が運用して数多くの利用者が共有 • AWSとかAzureとかいろいろ • プライベートクラウド • 社内で単独で運用 • YahooとかCyberAgentとか 31
- 32. パブリッククラウド • 大規模な事業者 • 豊富なリソースにもとづく最適化 • 膨大な開発能力にもとづく多種多様な機能 • 責任共有モデル • ざっくりOSから下は事業者がセキュリティを担保 • 各種セキュリティガイドラインへの準拠 • むしろベストプラクティスが実装された環境 • OSとその上は利用者がセキュリティを自力で担保 32
- 33. プライベートクラウド • 既存の自前でデータセンタ借りてサーバ置くモデル • OpenStackなどのクラウドコントローラでクラウド化 • 基本機能はAmazon等と似たようなことができる • 多種多様な機能は少ない • プライベートでの差別化 • 既にノウハウや購買力を持つ場合 • システム間が密結合（消極的理由） • これらを維持しつつ、クラウドや仮想化のメリットを享受 • 社内の「クラウド事業者」部門 33
- 34. 「所有」から「利用」へ • サーバを所有しない • サービス部門は物理的なサーバを直接持たない • サーバやデータセンター、ネットワークの管理をしない • サーバは利用する • 必要な時間だけ、サーバの利用権を買う（借りる） • その道の匠が設計した素敵なサーバ環境を利用できる • 彼らの考えた「ベストプラクティス」に自分を合わせる 34
- 35. 「所有」から「利用」へ • そもそも所有するべき技術を絞り込む • クラウド基盤の運用は、自分たちのビジネス領域では無い • 自ら技術者を確保するコストは決して安くない • 「利用」することで、自らのコア事業に集中できる ↔「技術」があることは悪では無い • 内部を知っているほど最適な設定が導き出せる • トラブルシュート（とにかく全方位の能力が問われる） 35
- 36. クラウドのサービス分類 サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 • DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能（FW、LB等）も提供されたりする。 36
- 37. クラウド(IaaS)でサーバを確保 • 自由なサーバの追加・削除が可能になる • すぐ（数分程度）にサーバが増やせる！ ↔ これまでは最大想定分だけのサーバを事前に用意 ↔ 想定を超えるとすぐに対応ができない • 要らないサーバはいつでも捨てられる！ ↔ 資産の耐用年数（5年程度）を使い切れない ↔ 挑戦的なサービスをリリースできない 37
- 38. 「ペット」から「家畜」 • これまで：サーバ＝ペット🐕🐕🐕🐕 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • いま：サーバ＝家畜🐖🐖🐖🐖 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す。慈悲は無い。 38
- 39. 「メリハリ」を付けよう • Statelessサーバ 🐖🐖🐖🐖 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐕🐕🐕 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 39
- 40. 「ペット」から「家畜」、その先へ…… • これまで：サーバ＝ペット🐕🐕🐕🐕 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • いま：サーバ＝家畜🐖🐖🐖🐖 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す。慈悲は無い。 • これから：サーバーレス＝……？ 40
- 41. サーバーレス is 何 • クラウドの流れを踏まえて、 どんなものをイメージしますか？ 41
- 42. サーバーレス is 何 • 権威のありそうな定義はまだ存在しない • 「サーバーレス」と呼ばれる「技術ムーブメント」は 明確に存在している • Serverless Architecture • Serverless Computing • Serverless .* • 今回は、後付けでそれを整理した考え方を紹介 42
- 43. サーバーレス 43 「Serverless」の本質 ＝ 「サーバの抽象化」 ＜運用面＞ フルマネージドサービスの活用 ・FaaS ・Functional SaaS ＜開発面＞ イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
- 44. サーバーレス 44 「Serverless」の本質 ＝ 「サーバの抽象化」 ＜運用面＞ フルマネージドサービスの活用 ・FaaS ・Functional SaaS ＜開発面＞ イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
- 45. 背景：サーバ・計算機の抽象化 • サーバ、もしくは「計算機」の抽象化 • サーバーレスという考え方の原点 • コンピュータサイエンスの進化の歴史そのもの • 抽象化して再利用性を高める • 分割して統治する 45
- 49. サーバーレス 49 「Serverless」の本質 ＝ 「サーバの抽象化」 ＜運用面＞ フルマネージドサービスの活用 ・FaaS ・Functional SaaS ＜開発面＞ イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
- 50. 運用面： フルマネージドサービスの活用 • 抽象化の「向こう側」をクラウドにお任せ • おさらい：「所有から利用へ」 • 「フル」マネージドサービス • スケーラビリティや冗長性の確保などまで踏み込んで、 クラウド側に運用の全てを委託 50
- 51. 51 Ant Stanley - Being Serverless https://www.slideshare.net/acloudguru/ant-stanley-being-serverless ＝クラウドサービス
- 52. 52 Ant Stanley - Being Serverless https://www.slideshare.net/acloudguru/ant-stanley-being-serverless ＝クラウドサービス
- 54. 運用面： フルマネージドサービスの活用 • Functional SaaS • なんらかの具体的な機能を提供 • クラウド時代のミドルウェアやライブラリに相当 • プログラムというよりは、設定やDSLで動作を決める • Function as a Service • 自分の書いたプログラムを動かす実行環境の抽象化 • 「関数」という単位でソフトウェアを管理 ※関数の代わりにコンテナを使うものもある 54
- 55. Functional SaaS • 個別の機能を提供 • データベース • メッセージキュー（待ち行列） • メール送信 • etc. • Backend as a Service（BaaS）と呼ばれる • 「機能の提供」に重きを置いて、ここではFunctional SaaS にて統一 55
- 56. AWS 56
- 57. Azure 57
- 58. Function as a Service • 自分の書いたプログラムを動かす実行環境の抽象化 • プログラムをクラウドに展開 • 決められたハンドラ関数が直接呼び出される • 実際の動作マシン台数などはクラウドが管理 • 需要に応じて増減してくれる • ステートレスなどの制約が課される 58
- 59. サーバーレス 59 「Serverless」の本質 ＝ 「サーバの抽象化」 ＜運用面＞ フルマネージドサービスの活用 ・FaaS ・Functional SaaS ＜開発面＞ イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
- 61. 開発面： イベントドリブンなシステムアーキテクチャ • モノリシックなアプリケーション • アプリケーションが外にあるものを呼び出す • 例：データベースサーバ、外部システム 61 Client App Server App DB 外部 システム
- 64. 開発面： イベントドリブンなシステムアーキテクチャ • クラウド時代の制御の反転（Inversion of Control） • アプリケーション開発において、ライブラリを呼ぶのでは 無く、フレームワークから呼ばれるビジネスロジックに注力 • 例：Webアプリで GET / で呼ばれるハンドラメソッド • 自分のプログラムは必要な時だけ呼ばれる存在へ 64
- 65. サーバーレス 65 「Serverless」の本質 ＝ 「サーバの抽象化」 ＜運用面＞ フルマネージドサービスの活用 ・FaaS ・Functional SaaS ＜開発面＞ イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
- 66. • ここらで休憩 66
- 67. サーバーレス開発の勘所 • 全体を疎結合に保つ • リアクティブシステム • ID管理 • Function as a Service • 制約とうまく付き合っていく • Functional SaaS • 様々な性質を広く知りソムリエ力を鍛える 67
- 68. リアクティブシステム • 目的：即応性 • システム全体として、素早く、かつ安定した応答時間を保つ • 要件１：耐障害性 • 障害が発生しても、それをコンポーネント内部に影響を隔離すること で、システム全体としての即応性を保つ。 • 要件２：弾力性 • 負荷の増減があっても、ボトルネックを排除し、割り当てるリソース を調整することで、即応性を保つ。 • 手段：メッセージ駆動 • 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。
- 69. リアクティブシステム • メッセージ駆動（手段） • システム間をキューで非同期に接続する • 複数のワーカプロセスがキューから取ってきて処理 • 弾力性（要件2） • メッセージが増えてきたらワーカプロセスを増やせばよい • 横並びのワーカプロセスに相互依存はないので気軽にスケールアウト・イン • 耐障害性（要件1） • コンポーネントで異常が起きたら自爆して、別のワーカが実行 • ずっとおかしいメッセージはDead letter queueに積み替えて例外処理 • 即応性（目的） • 様々な状況に強いシステムが構築できる
- 70. リアクティブアーキテクチャ • ざっくり言うと、 • 小さなプログラムを • メッセージ駆動で • 繋いでいく という非同期型アーキテクチャが良い、という考え方 • もっと超ざっくり言うと • メッセージキューを挟んで繋げ 70
- 73. ID管理とセキュリティ • これまで • アプリケーションがその中で利用者を認証・認可 • 脆弱性はアプリケーションの実装方法によるもの 73 Client App Server App DB 外部 システム ユーザを識別・認証 そのユーザに許される操作 をアプリケーション内で 判断（認可）し実行
- 74. ID管理とセキュリティ • これから • 小さなアプリケーション⇒実装レベルの脆弱性は減少してほしい… • 脆弱性は設計や呼出し方法によるもの • ID管理に基づいたコンポーネント単位の認可がより重要に 74
- 76. Function as a Service • 関数と呼ばれる小さなコードを動かすクラウドサービス • 各社「サーバーレス」の中心人物 AWS Lambda、Azure Functions Google Cloud Functions、Bluemix OpenWhisk • アプリのプロセス起動・終了をクラウドに任せる ⇒ プロセス内にデータを保存することができない（Stateless） • 「Stateless」という制約を受け入れることで、 「フルマネージド」というメリットが得られる
- 77. Function as a Service • 「フルマネージドなPaaS」の発展系 • 利用者にとって「サーバ」という管理単位をなくしたい • その筋のプロである「クラウド事業者」が、それぞれの方法 で適切に管理してくれる＝フルマネージド • 使う量（確保量）から使った量（使用量）へのシフト • 事前に「台数」の確保が不要 • 短時間で起動し、必要なだけ拡張 • 実際の実行時間（たとえば100ms単位）で課金される
- 78. Function as a Service • いわゆるPaaSとの違い • 明確な定義の違いは無く、スケールのしやすさで区別 • 実装論はGMOペパボのFastContainerあたりの議論が分かりやすい • 講義B1の資料後ろの方を参照 https://twitter.com/adrianco/status/736553530689998848
- 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. Function as a Service • AWS Lambda 80 exports.handler = (event, context, callback) => { // TODO implement callback(null, 'Hello from Lambda’); };
- 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. 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. 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. Function as a Service • このように少しずつ関数のインターフェースが異なる • けど、受け渡す内容はだいたい一緒 • 自前で抽象化レイヤーを挟んでおくのがよい • 対応言語の壁もあるものの、標準化されて欲しい • ベンダーロックインを怖がる必要はあまりない 84
- 85. Function as a Service • AWS LambdaはHTTPを直接受けられない • Amazon API Gatewayを利用 • API Gateway側でHTTPと関数入出力を変換 • 変換の仕方を柔軟に指定できる ＝ 一般化されていない（制約になっていない） 85
- 86. Function as a Service • Azure Functionsの入出力バインディング • 関数を実行する「トリガー」と別に入出力を行う • 例: • トリガーの値を元にDBクエリ • 関数の返り値を別のキューやDBに保存 • 単純な処理をより単純に実装可能 • 副作用の無い素直な「関数」として書ける • そもそも保存処理やエラーハンドリングを自分で書かなくて良い 86
- 87. Functional SaaS • 様々な個別の機能を提供するクラウドサービス • クラウド時代のミドルウェアやライブラリに相当 • DB、キュー、メール送信、etc. • クラウド毎の差異はここにある • 「ベンダーロックイン」と捉えるか • 「自分に向いたものを選択できる」と捉えるか 87
- 88. Functional SaaS • たとえばNoSQLデータベース • AWS DynamoDBやAzure CosmosDB • 共通 • 性能を数値で指定して確保 • 「パーティションキー」で複数の物理サーバに分散される • 更新時にFaaSを起動（Streams / Change Feed） • 違い • DynamoDB：KVS的インターフェースのみ、ミニマム課金額小 • CosmosDB：SQLやグラフDB等複数のデータモデルに対応 88
- 89. Functional SaaS • データ保存先を分散したい • パーティションキーで振り分け • 実際はハッシュ値など 89 Key: 1-10 Key: 11-20 Key: 21-30 Key: 31-40 Key: 41-50
- 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. 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 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. Functional SaaS • キューも中身はデータベース • スケーラビリティの確保も同じ 93 Kinesis Data Streams Shard Shard Shard Shard パーティションキーで 別のShardに振り分け
- 94. Functional SaaS • FaaSとの連携も様々 • 2種類の連携方法（ポーリングとプッシュ） 94 FaaS 定期的にポーリング ※関数がDBへのアクセス権限を持つ FaaS 関数を呼び出し ※DBが関数の実行許可を持つ
- 95. Functional SaaS • たとえばmBaaS • Google FirebaseやAWS Cognito • モバイルアプリ向けの機能を一体化して提供 • 他のFacebookやTwitterと連携できるID基盤とか • リアルタイムでスマホ側とクラウド側を同期するDBとか • DB更新時にFaaS呼び出したりだとか • ロックインリスクと開発効率どっちを取るのか？ • 当然ながらケースバイケース • でもほとんどは開発効率では……？ 95
- 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. サーバーレスなシステム • 部品としてはここまで • FaaS • Functional SaaS • それらを利用したリアクティブシステム • 実際に作るためにはもっと道具が必要 • 「ソースコード管理」 • 「デプロイ」 97
- 98. Infrastructure as Code • クラウドサービスの構成をコード（DSL）で実装し、 それをもとにAPIをたたいて展開 • JSONや独自言語、Rubyベース内部DSLが多い • プログラミング的手法で継続的改善が可能 • Git等でのリビジョン管理、レビュー • デプロイツールの活用 • 自動テスト 98
- 99. Infrastructure as Code • 「プログラミングの手法」をインフラ管理に適用 • Git等によるリビジョン管理、Pull-Requestレビュー • テスト駆動 • 再利用しやすいDSL（ドメイン固有言語）による記述 • 何種類かのツール • ベンダー独立のTerraformが自由度が高い • AWS自身のAWS SAM(CloudFormationベース)もある • Azureなどもそれぞれテンプレート機能を提供 99
- 100. Terraform • AWSやAzureの構成をコード化 • コードに合わせて必要なサーバやクラウドサービスを作成 • 不必要になったら削除 • 独自DSL（HCL） • 信頼と安定のHashicorp 100
- 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. 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. 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. 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. Infrastructure as Code • どのツールを使うか • ツールによる対応が多いのはCloudFormation等クラウド ベンダー製のテンプレート • マルチクラウド ⇒ Terraform • 構成を少しずつカスタマイズ ⇒ Terraform 105
- 106. • この辺で休憩 106
- 107. 107
- 108. 演習1：Slackbot作ってみよう • 今回はseccamp 非公式Slackを利用します • まだ登録していない人は以下URLから登録 • https://bit.ly/2PgOAql 108
- 109. • ログイン情報（会場のみ） 109
- 110. Azureにログイン • ログイン • https://portal.azure.com/ • ツアーはスキップ 110
- 111. Function Appを作成 • 左上「リソースの作成」 • 「Serverless Function App」 111
- 112. Function Appを作成 • アプリ名：seccamp-自分の名前 • サブスクリプション：Visual Studio Enterprise • リソースグループ：既存 seccamp2018 • OS：Windows • ホスティングプラン：従量課金プラン • 場所：米国中部 • Storage：新規作成 • Application Insights：East US • ここまで入力したら【作成】 112
- 113. Function Appを作成 • 右上🔔🔔をクリックすると通知欄が開きます • デプロイメントが終わるまで待ちます • 🔔🔔をもう一度クリック して通知欄を閉じる 113
- 114. Function Appを作成 • メニューからFunction Appを開く • 自分のFunction Appをクリック （名前に注意） 114
- 115. 関数を作成 • 「関数」欄の ＋ をクリック 115
- 116. 関数を作成 • 以下のように選択 • webhook+API • JavaScript • この関数を作成する 116
- 119. サンプルコードを張り付け • 関数名をクリック • 入力欄に以下の内容を張り付け • https://bit.ly/2nHPr75 • 「保存」 119
- 120. 作成したAPIのURLを取得 • 上部の「</> 関数の URL の取得」をクリック • 関数のURLが表示されるのでコピーして手元にメモ 120
- 121. Slack Outgoing Webhookを作成 • 以下のURLを開く • https://bit.ly/2vReBVb • Add Configuration をクリック 121
- 122. Slack Outgoing Webhookを作成 • 確認画面が出るのでもう一度Add 122
- 123. Slack Outgoing Webhookを作成 • 受信するChannel： #2018-b7 • URLに、先ほど取得した APIのURLを入力 • Customize Name： bot-自分の名前 • 一番下の「Save Setting」 123
- 124. Slackでしゃべってみよう • #2018-b7 チャンネルで何か話してみよう • 自分のbotが、「Hello」を付けて返してくれるはず！ 124
- 128. CosmosDBの作成 • ID：seccamp-自分の名前 • API：SQL • サブスクリプション：Visual Studio Enterprise • リソースグループ：既存 seccamp2018 • 場所：東日本 • ここまで入力したら【作成】 • 終わるまで2～3分まつ • 右上🔔🔔で確認 128
- 129. コレクションの作成 • 通知欄からCosmosDBを開く • 「Create “Items” collection」をクリック 129
- 130. FunctionからDBに出力 • メニュー「Function App」から自分の関数に戻る • HttpTriggerJS1の「統合」をもう一度開く 130
- 131. FunctionからDBに出力 • 「出力」欄の「新しい出力」をクリック • 「Azure CosmosDB」をクリックしてから「選択」 131
- 132. FunctionからDBに出力 • 以下のように入力 • ドキュメント パラメーター名：outputDocument （そのまま） • データベース名：ToDoList • コレクション名：Items • 入力できたら 右下の「新規」 をクリック 132
- 133. FunctionからDBに出力 • 以下のように選択 • サブスクリプション：Visual Studio Enterprise • データベースアカウント：seccamp-自分の名前 • 「選択」 133
- 136. 動作確認 • Slackでちょっと発言してみる • 自分のbotから返ってくることを確認 • CosmosDBに保存されたことを確認してみよう 136
- 138. CosmosDBへの保存確認 • 「Data Explorer」をクリック • 「ToDoList」の中の「Items」をクリック • 「Documents」をクリック 138
- 140. 演習3：GitHubからデプロイ • GitHubにレポジトリを作って、以下のようにファイル を設置（function.jsonはブラウザ上で取得） • HttpTriggerJS1/ • function.json • index.js 140
- 141. デプロイ設定 • Function Appの プラットフォーム 機能のタブを開く • 「展開オプション」 をクリック 141
- 142. デプロイ設定 • 「セットアップ」をクリック • デプロイオプションでGitHubを選択 • 自分のユーザで連携し、作成したレポジトリを指定 • 最後まで行くと、GitHubから再デプロイされる • 適当に変更をpushしてみて反映されることを確認 142
- 143. ポイント • 短い関数 • 「やりたいこと」に集中しやすい • 様々な連携 • DBなどとの連携 • デプロイ等の省力化 143
- 144. 144
- 145. まとめ • サーバーレス時代のシステム設計ワークショップ • クラウドとサーバーレス • サーバーレス時代の考え方 • FaaSとFunctional SaaS • 演習 145
- 146. 最後に • 特にこの10年のインフラ業界は動きが早いです • クラウドが登場して（まだ）10年間 • 前提が変わり、ベストプラクティスが入れ替わる • 個人的には、 ・この10年で物理サーバからクラウド上の仮想サーバに ・今後10年でサーバという枠組みから解放 と予想しています • ツールレベルの盛衰は、一々取り上げるのも切りが無い • 動きが早い＝面白い！ 146
- 147. 最後に • すぐに手を動かそう！ • 無料クーポン、無料枠を活用しよう（学生はより有利！） • 大きな機能もちょっとだけなら安くお試しできる！ • とにかくネタと機会を作って情報を発信しよう！ • 情報は活動する人の近くに集まる • ブログ等での情報発信 • 勉強会等での発表 • 同人誌等の制作、頒布 147
- 148. 148