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