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