イントロダクション(分散アーキテクチャ時代におけるWebシステムの開発と運用) #seccamp
1.8K Views
September 30, 21
スライド概要
セキュリティ・キャンプ全国大会2021 オンライン
分散アーキテクチャ時代におけるWebシステムの開発と運用
イントロダクション
【本講義は以下の4つから構成されます】
イントロダクション
https://www.docswell.com/s/nekoruri/5WGY1K-seccamp2021b3-introduction
クラウドシステムをセキュアに開発運用する勘所
https://speakerdeck.com/azara/sekiyuriteikiyanpuquan-guo-da-hui-2021-onrain-b3-fen-san-akitekutiyashi-dai-niokeruwebsisutemufalsekai-fa-toyun-yong-shi-qian-zi-liao-kuraudosisutemuwosekiyuanikai-fa-yun-yong-surukan-suo
クラウド時代のものづくり
https://www.docswell.com/s/nekoruri/ZD3QDK-seccamp2021b3-cloudnative
ハッカソンについて
https://www.docswell.com/s/nekoruri/KRY725-seccamp2021b3-hackathon
秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア。 0と1が紡ぐ「ゆるやかなつながり」に魅せられ早20年、 SNSとCGMの力で世界を幸福にするのがライフワーク。 市民、幸福は義務です。 あなたは幸福ですか？
関連スライド
各ページのテキスト
セキュリティ・キャンプ全国大会2021 オンライン 【B3】 分散アーキテクチャ時代における Webシステムの開発と運用 イントロダクション 講師 仲山 昌宏・齋藤 徳秀
👀👀 この講義について • Webシステムを分散アーキテクチャで作るのが当たり前の 時代 ここには、補足情報を書 いていきます。 • コンテナやサーバーレス（FaaS）によるソフトウェアの開発 • SaaSの活用 • 設計の基礎 • スケーラビリティ • セキュリティ • ハッカソン 2
仲山 昌宏 / @nekoruri 株式会社WHERE（2016-） Twitterとかでも お気軽にどうぞ セキュリティ・キャンプ 講師（2015-） SecHack365 トレーナー（2017-） 📗📗技術系同人誌サークル 「めもおきば」「ssmjp同人部」 👬👬#ssmjp / #qpstudy / #serverlesstokyo 🎮🎮ProjectSEKAI Colorful Stage Rank.170 3 3
💼💼 経歴 2004～2010 WIDE Project irc.fujisawa.wide.ad.jp運用 2004〜2005 国際大学GLOCOM (研究アシスタント) 2005〜2008 AIP 2008〜2009 KBB, I&D 2010〜2013 Xtone 2013〜2016 CyberAgent (パシャオク⇒Ameba⇒DC運用) 2016〜現在 WHERE (IoTスタートアップ) ⬅今ここ 1999 ↓ 2006 Web系IT企業では転職 活動が盛んと言うことも あり、だいたい3年くら いであちこち徘徊して いる感じです。 AIPとXtoneはいわゆ るWeb開発会社で、 KBB,I&Dでは地域 SNSを開発・運用をやっ ていました。 社会人 大学院ネットワーク管理 学生 2003～2005 2006 ↓ CyberAgentでは最初 スマホ向けオークション のパシャオクのサーバイ ンフラを担当したあと、 めぐり巡って社内プライ ベートクラウドを担当し ていました。 現在の話は後ほど…… 4
💼💼 経歴と興味範囲 P2P もともとインターネット 2003～2005 大学院ネットワーク管理 2004～2010 WIDE Project irc.fujisawa.wide.ad.jp運用 2004〜2005 国際大学GLOCOM (研究アシスタント) SNS CGM 2005〜2008 AIP 2008〜2009 KBB, I&D 2010〜2013 Xtone 2013〜2016 CyberAgent 2016〜現在 WHERE (IoTスタートアップ) ⬅今ここ クラウド にまつわる様々な技術 を幅広く好きだったの ですが、特にP2Pと SNSという二つの「ネッ トワーク」技術に魅せら れた大学時代でした。 その後、各社でSNSに 関連する業務などにも 携わりながら、2010年 あたりからのクラウド全 盛期を迎え、その中でう まくクラウドを使って世 の中を楽しくすることを 目的に頑張っています。 サーバーレス IoT 5
💼💼 経歴 2003～2005 大学院ネットワーク管理 2004～2010 WIDE Project irc.fujisawa.wide.ad.jp運用 2004〜2005 国際大学GLOCOM (研究アシスタント) 2005〜2008 AIP 2008〜2009 KBB, I&D 2010〜2013 Xtone 2013〜2016 CyberAgent (パシャオク⇒Ameba⇒DC運用) 2016〜現在 WHERE (IoTスタートアップ) ⬅今ここ 6
前職での例（株式会社サイバーエージェント） • サイバーエージェントという会社 • インターネット広告とゲームの利益でメディア事業に投資 • インターネット広告事業 3本の柱でうまくバラン スを取りながら、ウマ娘 などのゲームの利益を 材料にしてABEMAへ の投資を続けています。 • 広告代理店 • 広告の配信プラットフォーム • ゲーム事業 • 自社IP：ウマ娘、プリコネ • 他社IP：デレステ、ガルパ、プロセカ • メディア事業 • ABEMA • アメブロ https://www.cyberagent.co.jp/ir/strategy/ 7
💰💰 サービス運用について考えてみよう ❓1時間サービスが止まったときの被害はおいくら？ • FY2021-2Qのゲーム事業売上高：639億円（四半期決算より） （2021/01/01～2021/03/31：90日間） CyberAgent 2021 https://pdf.cyberagent.co.jp/C4751/bxTh/MDAa/KRIL.pdf ＜ちょっとここで動画を少し止めて想像してみてください＞ 8
💰💰 サービス運用について考えてみよう ❓1時間サービスが止まったときの被害はおいくら？ • FY2021-2Qのゲーム事業売上高：639億円（四半期決算より） （2021/01/01～2021/03/31：90日間） CyberAgent 2021 https://pdf.cyberagent.co.jp/C4751/bxTh/MDAa/KRIL.pdf ❗ 答え合わせ • 1時間あたり2,958万円 9
💰💰 サービス運用について考えてみよう ❓1時間サービスが止まったときの被害はおいくら？ • FY2021-2Qのゲーム事業売上高：639億円（四半期決算より） （2021/01/01～2021/03/31：90日間） CyberAgent 2021 https://pdf.cyberagent.co.jp/C4751/bxTh/MDAa/KRIL.pdf ❗ 答え合わせ • 1時間あたり2,958万円 • 1分間あたり49万円 これはあくまでゲーム事 業全体の数字に基づい たざっくりした金額です。 実際には、サービスが止 まるのはゲーム単体ご とでしょうし、その一方 でお正月ガチャなど一 斉に売上が増える時期 もあったりと、様々な要 因でこの数字からは増 えたり減ったりします。 重要なのは、 止まるとお金稼げない、 ということです。 10
サービスの運用とは 目的： • ITを使って組織の目的を達成する 営利企業であれば「お金を稼ぐ」など 手段： • お客さんにサービスを提供し、その対価を受け取る （直接部門） • 従業員↑にサービスを提供し、生産性を向上させる （間接部門） 11
サービス運用の価値 サービスの品質 ⇒サービスの内容が お客さんの期待を満たす サービスの稼働率 ⇒使いたいときに使える （落ちていない）こと ＜時間単価＞ × ＜稼働時間＞ 12
サービス運用の価値 サービスの品質 ⇒サービスの内容が お客さんの期待を満たす • • • • 便利、楽しい 需要を満たす 不具合が少ない レスポンスが速い サービスの稼働率 ⇒使いたいときに使える （落ちていない）こと • 止まらない ＜時間単価＞ × ＜稼働時間＞ 13
サービス運用の価値 サービスの品質 ⇒サービスの内容が お客さんの期待を満たす • • • • 便利、楽しい 需要を満たす 不具合が少ない レスポンスが速い サービスの稼働率 ⇒使いたいときに使える （落ちていない）こと いわゆるDev-Ops対立 • 止まらない ＜時間単価＞ × ＜稼働時間＞ 14
SRE: Site Reliability Engineering • サービスの「信頼性」を制御するための工学 • 稼働率などによって信頼性を評価し、 • 目標とする範囲に信頼性を制御し、 • その範囲でサービスの変更（サービスデリバリ）を高速化する • 定めたサービスレベル目標の範囲内であれば 稼働率の低下を恐れずにソフトウェアをリリースできる 15
💰💰 思い出してみよう ❓1時間サービスが止まったときの被害はおいくら？ • FY2021-2Qのゲーム事業売上高：639億円（四半期決算より） （2021/01/01～2021/03/31：90日間） CyberAgent 2021 https://pdf.cyberagent.co.jp/C4751/bxTh/MDAa/KRIL.pdf ❗ 答え合わせ • 1時間あたり2,958万円 • 1分間あたり49万円 ❗❗リリースに失敗しても3分間で元に戻せるならば…… 新機能が150万円以上稼いでくれるはずならば…… 16
SRE: Site Reliability Engineering • サービスの「信頼性」を制御するための工学 • 稼働率などによって信頼性を評価し、 • 目標とする範囲に信頼性を制御し、 • その範囲でサービスの変更（サービスデリバリ）を高速化する • 定めたサービスレベル目標の範囲内であれば 稼働率の低下を恐れずにソフトウェアをリリースできる SREについては、これだ けで一つ講義ができる ほどの分野です。是非皆 さんも情報収集してくだ さい。 おすすめは、SREという 概念を提唱した Googleのエンジニアに よって書かれた書籍 「SRE サイトリライアビ リティエンジニアリング」 です。 ⇒ 信頼性を制御しながら、変更速度を高める • DevOpsなどの考え方を整理し具体化したもの 「class SRE implements DevOps」 Google 2018 https://cloud.google.com/blog/products/gcp/sre-vs-devops-competing-standards-or-close-friends 17
💼💼 経歴 2003～2005 大学院ネットワーク管理 2004～2010 WIDE Project irc.fujisawa.wide.ad.jp運用 2004〜2005 国際大学GLOCOM (研究アシスタント) 2005〜2008 AIP 2008〜2009 KBB, I&D 2010〜2013 Xtone 2013〜2016 CyberAgent (パシャオク⇒Ameba⇒DC運用) 2016〜現在 WHERE (IoTスタートアップ) ⬅今ここ 18
現職での例（株式会社WHERE） • デジタルツインによって課題を解決するIoTスタートアップ • Bluetoothメッシュネットワークで物や人の場所・状態を収集 • それらをクラウド上で再現、様々なサービスを提供 ＝デジタルツイン • 「デジタル」に集めることでソフトウェアで課題を解決 • オフィスの従業員 ⇒ 居場所確認・座席予約、濃厚接触者確認 • 工場の部品 ⇒ 作業実態の可視化、効率化 • 工事現場 ⇒ 作業員の安全管理（Safety2.0） 19
DX: Digital Transformation デジタイゼーション デジタライゼーション DX 組織が持つ情報をすべてデジタル化し、 組織の活動がソフトウェ ア化されることによって、 ソフトウェアの開発手法 を、組織の活動に適用す ることができ、自分たち の活動のやり方を現状 に会わせて素早くアップ デートできるようになっ たということです。 活動をソフトウェア化して付加価値を高め、 自己変革を回しつづける 21
DX: Digital Transformation デジタイゼーション デジタライゼーション DX 組織が持つ情報をすべてデジタル化し、 組織の活動がソフトウェ ア化されることによって、 ソフトウェアの開発手法 を、組織の活動に適用す ることができ、自分たち の活動のやり方を現状 に会わせて素早くアップ デートできるようになっ たということです。 活動をソフトウェア化して付加価値を高め、 自己変革を回しつづける 22
継続的に価値を届けつづけるために 不確実性の制御 ソフトウェア化 クラウドサービス化 変更容易性 変化するニーズ アジャイル SCRUM XP CI/CD 自らの価値への注力 DX DevOps DevSecOps SRE ソフトウェア化した組織 で、新しい価値を届け付 けるためには、様々な試 みが行われてきました。 ここではその一部をざっ くり紹介しています。 クラウドの活用 サーバーレス コンテナ IaC 23
継続的に価値を届けつづけるために 不確実性の制御 ソフトウェア化 クラウドサービス化 変更容易性 変化するニーズ アジャイル SCRUM XP CI/CD 自らの価値への注力 DX DevOps DevSecOps SRE ソフトウェア化した組織 で、新しい価値を届け付 けるためには、様々な試 みが行われてきました。 ここではその一部をざっ くり紹介しています。 クラウドの活用 サーバーレス コンテナ IaC 24
クラウドサービス クラウドサービスの普及 によって、さまざまなメ リットを得られるように なりましたが、どれも ユーザーに価値を早く 届けることに寄与します。 価値への注力 クラウドの活用によって ユーザーに 価値を早く届ける ソフトウェア化された サービスインフラ 様々な クラウドサービス 25
あらためて「クラウド」のおさらい • よく引用されている米国NISTによる定義（2011） • NIST SP800-145 The NIST Definition of Cloud Computing [ja: https://www.ipa.go.jp/files/000025366.pdf] 10年も前の、クラウドと いうものがようやく一般 化してきた当時に定め られた定義ですが、今で も良く実態を表していま す。 共用の構成可能なコンピューティングリソース（ネットワーク、 サーバー、ストレージ、アプリケーション、サービス）の集積に、 どこからでも、簡便に、必要に応じて、ネットワーク経由でアクセス することを可能とするモデルであり、最小限の利用手続きまたは サービスプロバイダとのやりとりで速やかに割当てられ提供されるもの 26
あらためて「クラウド」のおさらい • よく引用されている米国NISTによる定義（2011） • NIST SP800-145 The NIST Definition of Cloud Computing [ja: https://www.ipa.go.jp/files/000025366.pdf] 10年も前の、クラウドと いうものがようやく一般 化してきた当時に定め られた定義ですが、今で も良く実態を表していま す。 共用の構成可能なコンピューティングリソース（ネットワーク、 サーバー、ストレージ、アプリケーション、サービス）の集積に、 どこからでも、簡便に、必要に応じて、ネットワーク経由でアクセス することを可能とするモデルであり、最小限の利用手続きまたは サービスプロバイダとのやりとりで速やかに割当てられ提供されるもの 27
あらためて「クラウド」のおさらい 必要な分だけ 割り当て・利用 1. オンデマンド・セルフサービス APIでなんでもできる 共用リソースプール 5つの特徴 3つのサービスモデル SaaS 具体的なアプリ ケーションとし て提供される ・Google Workspace ・Dropbox PaaS アプリケーショ ンを動かすため の環境が提供 される ・Heroku ・Netlify ・Vercel IaaS サーバーやネット ワーク機能が提供 される ・AmazonEC2 ・Azure VM ・さくらのクラウド 実際には、 SaaS/PaaS/IaaSの 境界線は明確では無く、 グラデーションのように なっています。 2. 幅広いネットワークアクセス 様々なネットワーク経由から利用できる 3. リソースの共用 潤沢なリソースプールから割り当てる 4. スピーディな拡張性 需要に応じてすぐ伸縮自在に割り当てる 5. サービスが計測可能 使用量が細かく正確に計測し課金される 28
あらためて「クラウド」のおさらい パブリッククラウド プライベートクラウド（オンプレミス） • 大規模な事業者 • 既存の自前でデータセンタ借りて サーバ置くモデル • 潤沢なリソースによる最適化 • 膨大な開発能力が生み出す多種多様 な機能 • 責任共有モデル • ざっくりOSから下は事業者が セキュリティ等に責任を持つ • 各種セキュリティガイドラインへの 準拠 • むしろベストプラクティスが実装 された環境 • OSとその上は利用者がセキュリティ を自力で担保 • OpenStackなどのクラウドコント ローラでクラウド化 • 基本機能はAmazon等と似たような ことができる • 機能は少ない パブリッククラウド全 盛期ではありますが、 プライベートクラウド にもメリットがある場 合があり、なかなか全 てがパブリッククラウ ドで、という時代が来 るのはもう少し先で しょうね。 • プライベートでの差別化 • • • • 既にノウハウや購買力を持つ データを社外に出したくない システム間が密結合（消極的理由） これらを維持しつつ、クラウドや仮想 化のメリットを享受 29
「所有」から「利用」へ サーバを所有しない • 物理的なサーバを 持たない • サーバやデータセンター、 ネットワークを 管理しない 必要な分だけ 割り当て・利用 サーバはクラウドが所有 サーバは利用する • 必要な時間だけ、サーバの 利用権を買う（借りる） • その道の匠が設計した 素敵なサーバ環境を 利用できる • 彼らの考えた 「ベストプラクティス」 に自分を合わせる 「素敵なサーバ環境」、 使いたくないですか 私は使いたいです。 30
💸💸サーバのおねだん（一例） 格安プラン そこそこお高めプラン DELL PowerEdge R340 DELL PowerEdge R750xs • Xeon E-2224 4C/4T • Xeon Gold 5317Y 24C/48T • 16GB UDIMM×2 • 32GB RDIMM×8（256GB） • 480GB SSD×2 RAID1 • 750GB NVMe×2 RAID1 • 翌営業日オンサイト保守12ヶ月 • 10GbE 2Port NIC 皆さんが思ったより 高かったですか？ 安かったですか？ • 当日4時間オンサイト保守36ヶ月 ⇒ ざっくり30万円 ⇒ ざっくり600万円 3年間使うと1ヶ月8,333円 3年間使い倒しても1ヶ月16万円 32
🏭🏭メガクラウドのデータセンター Microsoft Azure AWSは公式写真等が見 当たらず動画だけだっ たのでここでは割愛しま した。 Google Cloud どちらも、同じ形のサー バや建物が並んでいる、 という印象を持ってもら えますでしょうか。 As datacenters grow, Microsoft’s innovative approach invests in more clean energy to power them Google Data centers マイクロソフトのバーチャルデータセンターが、 「クラウド」を現実に Google Data centers 33
34 クラウド(IaaS)でサーバを確保 • 自由なサーバの追加・削除が可能になる • すぐ（数分程度）にサーバが増やせる！ ↔ これまでは最大想定分だけのサーバを事前に用意 ↔ 想定を超えるとすぐに対応ができない • 要らないサーバはいつでも捨てられる！ ↔ 資産の耐用年数（5年程度）を使い切れない ↔ 挑戦的なサービスをリリースできない 増やすのは、儲かってい る状態なので力業（金の 弾丸）でなんとかなるこ ともあります。 減らすのは、儲かってい ない状態なので、そもそ も何をやるにもつらい 状況です。 いつでも減らせるからこ そ、サーバが増えるかも 知れない挑戦が気楽に できるという表裏一体 です。 34
35 「ペット」から「家畜」 • これまで：サーバ＝ペット🐕🐕🐈🐈 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る ペットと家畜、そろそろ 手垢が付いてきたたと え話ですが、皆さんはど れくらいきいたことがあ るでしょうか？ • いま：サーバ＝家畜🐖🐖🐓🐓 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す。慈悲は無い。 35
36 「メリハリ」を付けよう • Statelessサーバ 🐖🐖🐓🐓 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐕🐈🐈 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 36
37 「メリハリ」を付けよう • Statelessサーバ 🐖🐖🐓🐓 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ 様々なガイドラインの活用 • Statefulサーバ 🐕🐕🐈🐈 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 37
Twelve-Factor App モダンなアプリケーションの方法論（2012） https://12factor.net/ja/ 1. コードベース 7. ポートバインディング 2. 依存関係 8. 並行性 3. 設定 9. 廃棄容易性 4. バックエンドサービス 10. 開発/本番一致 5. ビルド、リリース、実行 11. ログ 6. プロセス 12. 管理プロセス 38 Docker(2012)が出 てくる直前に書かれ、後 にDockerの設計思想 に組み込まれたベストプ ラクティスがこの12項 目に詰まっています。 今となっては、少しだけ 現状と見合っていない 部分がありますが、その ういったところも踏まえ て次のガイドラインが登 場します。 38
Beyond the Twelve-Factor App クラウド時代にあわせたアップデート版（2016） https://tanzu.vmware.com/content/blog/beyond-the-twelve-factor-app 1. 1コードベース1アプリ 9. 環境の一致 2. APIファースト 10. 管理プロセス 3. 依存性の管理 11. ポートバインディング 4. 設計、ビルド、リリース、実行 12. Statelessなプロセス 5. 設定、認証情報、コード 13. 並行性 6. ログ 14. テレメトリ 7. 廃棄容易性 15. 認証と認可 クラウドとDockerが前 提となった状態をター ゲットにアップデートさ れたものです。 いくつかの概念の整理 や、Docker時代ではや や見合わない部分が見 直しされています。 認証情報や、認証と認可 などがはっきり明示さ れたことも象徴的です。 8. バックエンドサービス 39
壊れたら新しいサーバに、とは言うけれど 壊れた原因 • SSDの故障？ • ネットワーク？ • 電源設備？ • etc. 近くのサーバも 壊れているのでは？ 40
壊れたら新しいサーバに、とは言うけれど 壊れた原因 • HDDの故障？ • ネットワーク？ • 電源設備？ • etc. データセンターA 同時に壊れないようにする 近くのサーバも 壊れているのでは？ クラウドを上手く使って いくためには、 Statelessなサーバで あっても、動かすデータ センターを分けたりして 複数のサーバで同時に 障害が起きづらいよう に、可用性設計をする必 要があります。 データセンターB 41
可用性を踏まえたサーバの配置（AWS) 3つのアベイラビリティゾーン クラウドでの可用性設計 は、基本的には ・リージョン ・アベイラビリティゾーン の2段階でおこないます。 ap-northeast-1a リージョン ap-northeast-3 リージョン ap-northeast-1 ap-northeast-1c 多数決が取れるように、 3つ以上のゾーンが用意 されていることがほとん どです。 なおAWSで東京のbは、 いにしえの理由で現在 は使われていません。 a,c,dの3つです。 ap-northeast-1d 42
可用性を踏まえたサーバの配置（AWS) 3つのアベイラビリティゾーン ❌ ap-northeast-1a リージョン ap-northeast-3 リージョン ap-northeast-1 ap-northeast-1c ap-northeast-1d 43
クラウドごとのアベイラビリティゾーン ap-northeast-1 東京 AWS ap-northeast-1 東京 Azure Japan East 東日本 リージョンペア Japan West 西日本 GCP asia-northeast1 東京 asia-northeast2 大阪 ap-northeast-1a ap-northeast-1b ap-northeast-1d ap-northeast-1a ap-northeast-1b ap-northeast-1d AZ1 AZ2 AZ3 ー Azureはもともとアベ イラビリティゾーンとは 異なる可用性設計を採 用していたのですが、他 のクラウドの利用者が増 えたこともあり、リー ジョンごとに順次ゾーン を増やしている最中で す。 asia-northeast1-a asia-northeast1-b asia-northeast1-d asia-northeast2-a asia-northeast2-b asia-northeast2-c 44
クラウドはIaaSだけじゃない 必要な分だけ 割り当て・利用 1. オンデマンド・セルフサービス APIでなんでもできる 共用リソースプール 5つの特徴 3つのサービスモデル SaaS 具体的なアプリ ケーションとし て提供される ・Google Workspace ・Dropbox PaaS アプリケーショ ンを動かすため の環境が提供 される ・Heroku ・Netlify ・Vercel IaaS サーバーやネット ワーク機能が提供 される ・AmazonEC2 ・Azure VM ・さくらのクラウド 2. 幅広いネットワークアクセス 様々なネットワーク経由から利用できる ここまでは、IaaS、つま り仮想サーバ（VM）を念 頭に置きながら話を進 めてきましたが、クラウ ドで面白いのはむしろ、 それらを隠蔽してサービ スに仕上げたSaaSや PaaSです。 3. リソースの共用 潤沢なリソースプールから割り当てる 4. スピーディな拡張性 需要に応じてすぐ伸縮自在に割り当てる 5. サービスが計測可能 使用量が細かく正確に計測し課金される 45
46 「ペット」から「家畜」、その先へ…… • これまで：サーバ＝ペット🐕🐕🐈🐈 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • いま：サーバ＝家畜🐖🐖🐓🐓 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す。慈悲は無い。 • サーバを直接さわるのではなく、クラウドが提供する部品 を組み合わせてシステムを作る時代 PaaSとSaaSの境目は 曖昧（スペクトル）になっ ているので、あるクラウ ドサービスがPaaSなの かSaaSなのかを明確 に線引きすることはも はや難しいです。 これはこの後紹介してい くCaaS（Container as a Service）や FaaS(Function as a Service)なども同様 です。 ここではざっくりと、「自 分のアプリ」かどうかを 境界線としています。 • PaaS：ソースコードをpushすると自分のアプリが使える • SaaS：設定をpushするとクラウドのアプリが使える 46
次回予告：クラウド時代のものづくり • 「コンテナ」ってどうよ • 「クラウドネイティブ」とは • 「サーバーレス」っていうけどサーバあるじゃん 47