クラウドサービスのウラオモテ / Outside and Inside of Cloud Services

by naosuke

Slide 1

Slide 1 text

クラウドサービスのウラオモテ Naoki Hanakawa / NTT Ltd Japan @⾹川⼤学オンライン講演会 2021/03/26

Slide 2

Slide 2 text

whoami Naoki Hanakawa (@naosuke|hanasuke|naosuke2dx) Software Engineer at NTT Ltd Japan • NTT Com (2018⼊社) -> NTT WT (2020年⼊社) -> NTT Ltd Japan (イマココ) ECL2.0 ベアメタルサーバ/専⽤ハイパーバイザ開発チーム • 普段はRubyを書いて⽣きています • 趣味で社内のイベントや研修の講師なども naosuke2dx

Slide 3

Slide 3 text

注意 • 本発表中に出てくる機器の情報やアーキテクチャについては⼀般的な例であり，明⽰されていない限り，特定のサービスについて⽰唆しているわけではありません

Slide 4

Slide 4 text

“クラウドサービス” #とは https://flic.kr/p/abCSpq

Slide 5

Slide 5 text

クラウドサービスを使ったことがある⼈? 「クラウドサービス」と聞いてどんなものをイメージしますか?

Slide 6

Slide 6 text

よくイメージされるクラウドサービス

Slide 7

Slide 7 text

実際にクラウドサービスといわれるものたち

Slide 8

Slide 8 text

Cloud computingの定義 NIST(⽶国標準技術研究所)によって，2011年に⾔葉が定義されている IPA(情報処理推進機構)が⽇本語訳を掲載してたりする Cloud computing is a model for enabling ubiquitous, convenient, on- demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

Slide 9

Slide 9 text

つまるところ… 共有されたコンピューティングリソースに • どこからでも • 簡単に • 必要に応じて • ネットワーク経由でアクセスできるモデルであり，プロバイダとは最⼩限の⼿続きややり取りですぐに使える

Slide 10

Slide 10 text

実装モデル基本的な特徴クラウドモデルの構成 on-demand self-service broad network service resource pooling rapid elasticity measured service Private cloud Public cloud Hybrid cloud Community cloud サービスモデル Infrastructure as a Service Platform as a Service Software as a Service

Slide 11

Slide 11 text

どんな特徴があるかというと • オンデマンド・セルフサービス • プロバイダと直接やり取りすることなく，必要に応じて⾃動的に利⽤でき，リソースを⼀⽅的に設定できる • 幅広いネットワークアクセス • ネットワークを通じて利⽤可能であり，標準的な仕組みで接続可能 • リソースの共⽤ • リソースはマルチテナントモデルとして提供される • スピーディな拡張性 • 需要に応じて即座にリソースを拡張できる • 計測可能なサービス • リソースの利⽤状況はモニタ/コントロールされ，報告・明⽰できる

Slide 12

Slide 12 text

具体的にどんな感じで提供されているかというと • Private cloud • 単⼀組織専⽤に提供される実装モデル Verda (LINE) ，Nyah (GMOペパボ) ，XFARM (NTT) • Community cloud • 共通の関⼼をもつ複数の利⽤者で使われる実装モデル⾃治体クラウド(総務省) • Public cloud • ⼀般向けに公開された実装モデル GCP (Google) ， AWS(Amazon) ， Azure(Microsoft) ， ECL2.0 (NTT Ltd) • Hybrid cloud • 2つ以上の異なるモデルを組み合わせたもの • ⼤体Public+Privateの組み合わせ

Slide 13

Slide 13 text

具体的にどんなサービスがあるかというと NISTによって定義された従来のサービスモデル IaaS Infrastructure as a Service PaaS Platform as a Service SaaS Software as a Service 従来のサービスモデルからより具体的に深化したモデル FaaS Function as a Service CaaS Containers as a Service (M)BaaS (Mobile) Backend as a Service ※これ以外にもXaaSはいっぱいあります

Slide 14

Slide 14 text

Slide 15

Slide 15 text

責任共有モデル DataCenter Network Storage Server Virtualization OS Middleware Runtime App Data On-premises DataCenter Network Storage Server Virtualization OS Middleware Runtime App Data IaaS DataCenter Network Storage Server Virtualization OS Middleware Runtime App Data CaaS DataCenter Network Storage Server Virtualization OS Middleware Runtime App Data PaaS DataCenter Network Storage Server Virtualization OS Middleware Runtime App Data FaaS DataCenter Network Storage Server Virtualization OS Middleware Runtime App Data BaaS DataCenter Network Storage Server Virtualization OS Middleware Runtime App Data SaaS • ユーザが⾃由に利⽤・設計できる • ⾃分たちで設定や管理をしなければならない • 何かあっても⾃分たちの責任 • サポートは基本無い • ユーザに選択の⾃由はない • プロバイダがある程度設定済み • 何かあったらプロバイダ側の責任 • サポートなどもしてくれる

Slide 16

Slide 16 text

Slide 17

Slide 17 text

IaaSとは特徴 • サーバ(VM・物理)，ストレージ，ネットワークなどが使えるやつ • 構成の柔軟性が⾼い • VMの細かなスペック設定，NWの細かな設計とか得意分野 • 既存(On-premises)からの移⾏ • ハイパフォーマンスを求められる部分 • CPU/GPU/Memoryなど • OS(Kernel)，Middlewareなどに縛りがある • 特殊なNetwork Protocolの利⽤

Slide 18

Slide 18 text

IaaSのメリット・デメリット “オンプレに⽐べて”という⽂脈が多い • メリット • 従量課⾦制のため，固定費がかからない • オンプレミスに⽐べ，HWの保守の⼿間がかからない • NWの⾃由度が⾼く，ほぼなんでもパケットを流せれる › とはいえ，ベンダーによってはある程度制約があることもある • VMスペックの⾃由度が⾼く，CPUやメモリのカスタマイズもしやすい • デメリット • 基本的なサーバ管理(運⽤・セキュリティ対策)は引き続き⾏う必要がある • ⾃由度は⾼いため，メンテナンスコストが⾼い

Slide 19

Slide 19 text

この章のまとめ • 昨今皆さんは意識せずに「クラウドサービス」というものを使っている • ⾹川⼤全体としてはMS365だったりZoomだったりGMailだったり • SLPの⼈たちはSlackを使ってるし，中にはAWSとかGCPとか使ってる⼈もいるかも • なんなら今⽇使ってるZoomもクラウドサービスの1つ • クラウドサービスは，様々な特徴や実装モデル，提供⽅式がある • 定義に従うと，⼤きく IaaS，PaaS，SaaS に分類できる • 最近では更に深化したモデルも提唱されて利⽤されつつある • IaaSは，クラウドの中では⾃由度の⾼いサービス • ハイパフォーマンスを求めるソフトウェアなどに向いたサービス • ただし，⾃分たちで管理する部分も多く必ずしも楽になりきれない

Slide 20

Slide 20 text

クラウドサービスのウラガワ “プロバイダ”としてサービスを提供するにはどんなことが必要か

Slide 21

Slide 21 text

あるサービスを運⽤しています Database Load Balancer (VM) App (VM) Internet Firewall (VM) Logical Network Storage

Slide 22

Slide 22 text

このサービスがクラウド上で動いていたとすると… Database Load Balancer (VM) App (VM) Internet Firewall (VM) Logical Network Storage

Slide 23

Slide 23 text

この部分は⼀体どうなっているんだろう Database Load Balancer (VM) App (VM) Internet Firewall (VM) Logical Network Storage

Slide 24

Slide 24 text

中を⾒てみると Database Load Balancer (VM) App (VM) Internet Firewall (VM) Logical Network Storage

Slide 25

Slide 25 text

NW機器(物理) サーバ(物理) Storage Hypervisor z “この部分”はこんなシステムで⽀えられています Database Load Balancer (VM) App (VM) Storage NWリソース

Slide 26

Slide 26 text

NW機器(物理) サーバ(物理) Storage Hypervisor z 物理サーバの部分 Database Load Balancer (VM) App (VM) Storage NWリソース 1つの物理サーバに数⼗台の仮想マシン(VM)を⽴ててお客様に提供 VMで性能が⾜りない部分は物理サーバの専有メニュー(ベアメタルサーバ)も提供また，お客様のデータを保存するストレージサーバもある

Slide 27

Slide 27 text

NW機器(物理) サーバ(物理) Storage Hypervisor z NW機器 Database Load Balancer (VM) App (VM) Storage NWリソーススイッチとかルータと呼ばれるもの故障するとお客様の通信が成⽴しなくなるため，様々な技術を使って冗⻑化をしている

Slide 28

Slide 28 text

NW機器(物理) サーバ(物理) Storage Hypervisor z “この部分”はこんなシステムで⽀えられています Database Load Balancer (VM) App (VM) Storage NWリソースクラウドサービスの”外”につながるネットワークインターネットへ抜けたりVPNを使ってお客様の環境と接続したり

Slide 29

Slide 29 text

NW機器(物理) サーバ(物理) Storage Hypervisor z じゃあこの”システム"はどこで動いているか Database Load Balancer (VM) App (VM) Storage NWリソース

Slide 30

Slide 30 text

from https://www.google.com/about/datacenters/gallery/

Slide 31

Slide 31 text

from https://www.google.com/about/datacenters/gallery/ サーバルームで動いていて，こんな部屋はどこにあるかというと

Slide 32

Slide 32 text

from https://www.google.com/about/datacenters/gallery/

Slide 33

Slide 33 text

from https://www.google.com/about/datacenters/gallery/ データセンタと呼ばれる巨大な建物で動いています

Slide 34

Slide 34 text

「結局は物理」 • クラウドサービスの裏側は，実は巨⼤な「オンプレミス」なシステム • 数百〜数千台という単位の規模の物理サーバやストレージ，NW機器が • データセンタのなかのサーバルームにて動いている • → 様々なエンジニアが影で⽀えている • ソフトウェア • ネットワーク • 運⽤保守 • 24hの監視

Slide 35

Slide 35 text

「結局は物理」 • クラウドサービスの裏側は，実は巨⼤な「オンプレミス」なシステム • 数百〜数千台という単位の規模の物理サーバやストレージ，NW機器が • データセンタのなかのサーバルームにて動いている • → 様々なエンジニアが影で⽀えている • 開発エンジニア › ソフトウェア › ネットワーク • オペレータ › 運⽤保守 › 24hの監視しかしそれだけではクラウドサービスは運⽤できない!!!

Slide 36

Slide 36 text

Slide 37

Slide 37 text

実装モデル基本的な特徴これどうやって実現してるん…? on-demand self-service broad network service resource pooling rapid elasticity measured service Private cloud Public cloud Hybrid cloud Community cloud サービスモデル Infrastructure as a Service Platform as a Service Software as a Service …?

Slide 38

Slide 38 text

z NW機器(物理) サーバ(物理) Storage Hypervisor z “この部分”はこんなシステムで⽀えられています Database Load Balancer (VM) App (VM) Storage 再掲

Slide 39

Slide 39 text

z NW機器(物理) サーバ(物理) Storage Hypervisor z お前は誰だ? Database Load Balancer (VM) App (VM) Storage …?

Slide 40

Slide 40 text

サーバ(物理) Storage Hypervisor z クラウドサービスを⽀えるソフトウェア Database Load Balancer (VM) App (VM) Firewall (VM) Logical Network Storage etc… GUI SDN基盤認証認可基盤各サービスコントローラ課⾦計算バックエンドサービス

Slide 41

Slide 41 text

マイクロサービスアーキテクチャによる連携仮想サーバ共通機能(契約管理・認証機能・課⾦など) ベアメタルサーバネットワークモニタリングリソース・コントローラコンピューティング (仮想サーバ) ストレージネットワークコンピューティング (ベアメタル) モニタリング (リソースなど) モニタリング (監査ログなど) ユーザから⾒た機能･サービス共通機能リソース・コントローラリソース・コントローラリソース・コントローラリソース・コントローラリソース・コントローラ ... 各コンポーネントはAPIで連携コンポーネント化されたソフトウェア群

Slide 42

Slide 42 text

Slide 43

Slide 43 text

物理と論理を紐付けるコントローラポータル (GUI) ドキュメントサイト課⾦システムモニタリングシステムベアメタルコントローラストレージコントローラ仮想サーバコントローラ認証認可システム外部クラウド接続 VPNサービス問い合わせシステム論理NW接続インターネット接続ネットワークコントローラ SDNコントローラ外部クラウド更にそのソフトウェアをレイヤに分けると… 純粋なソフトウェア物理世界の制御 SDNコントローラいわゆるWebアプリケーション • 直接ユーザ(お客様・オペレータ)が閲覧・操作するインターフェース • GUIによる⼈間からの操作 • APIや，SDKによるプログラムからのアクセス • 各コントローラから情報を収集して，ユーザに提⽰できるよう情報を整形 • 各サービスのログやトラフィックからビジュアライズ • ユーザの各サービスの利⽤量から使⽤料⾦の計算

Slide 44

Slide 44 text

物理と論理を紐付けるコントローラポータル (GUI) ドキュメントサイト課⾦システムモニタリングシステムベアメタルコントローラストレージコントローラ仮想サーバコントローラ認証認可システム外部クラウド接続 VPNサービス問い合わせシステム論理NW接続インターネット接続ネットワークコントローラ SDNコントローラ外部クラウド更にそのソフトウェアをレイヤに分けると… 純粋なソフトウェア物理世界の制御 SDNコントローラソフトウェアを使って物理機器をコントロールし，サービスとしてお客様に提供 • GUIやAPIのリクエストを受け付ける • 実際に物理機器をソフトウェアから操作してセットアップする • 連携する他のコントローラにリクエストを出して，各種リソースと接続

Slide 45

Slide 45 text

ポータル (GUI) ドキュメントサイト課⾦システムモニタリングシステムベアメタルコントローラストレージコントローラ仮想サーバコントローラ認証認可システム外部クラウド接続 VPNサービス問い合わせシステム論理NW接続インターネット接続ネットワークコントローラ SDNコントローラ外部クラウド更にそのソフトウェアをレイヤに分けると… 純粋なソフトウェア物理世界の制御 SDNコントローラ物理機器を⾼信頼に稼働させるための設計や⾃動化の実施 • “Virtual Chassis/Virtual Switching System”といった技術で機器の冗⻑化 • ⼤規模な実験環境 (testbed)での安定試験やバグ取り • バックボーンNWの⾃動構築物理と論理を紐付けるコントローラ

Slide 46

Slide 46 text

この章のまとめ • クラウドサービスのウラガワは「巨⼤なオンプレミスサービス」 • 数百〜数千台規模の物理機器 • それを収容するサーバルーム • サーバルームを抱えるデータセンタ • 物理機器だけではなく，数多くのソフトウェアによってリソースを制御 • いわゆるWebアプリケーションのような部分 • ソフトウェアから物理機器を管理してサービスとして提供する部分 • サービスの⼟台を⽀える物理機器を⼿懐ける部分

Slide 47

Slide 47 text

物理と論理を紐付けるコントローラとは ECL2.0 ベアメタルサーバのコントローラを例にして

Slide 48

Slide 48 text

Slide 49

Slide 49 text

ベアメタルサーバ(BM)サービスとは物理サーバ SSL VPN Baremetal Controller Switch (D-plane) Switch (D-plane) Switch (St-plane) Switch (St-plane) Block Storage (iSCSI) File Storage (NFS) 物理サーバ FW VM LB VM Interne t GW VPN GW Internet MPLS VPN ... Storage Plane Data Plane Collocation Inter Connect (10G/1G) Collo- cation Rack Network Controller ユーザによる操作 Tenant Logial Network IPMI IPMI (via SDN Controller) • サーバ作成/削除 • 電源操作/BootOrder変更 • メディア接続 • UEFIパラメタ変更 • BMCアクセス(over SSLVPN)

Slide 50

Slide 50 text

Slide 51

Slide 51 text

BMコントローラのウラガワ BMコントローラ API Controller Monitor Conductor A Conductor B DHCP Agent Gateway controller 他コントローライメージレジストリネットワークコントローラ物理サーバ SSL-VPN 認証認可サービス GUI

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Webアプリケーションとしての側⾯ • リクエスト受付 • ユーザ向け › CRUDなどの各種操作 • 管理者・オペレータ向け › リソース管理 › 利⽤量の収集 › ライセンス管理 › リソース閉塞・開放 • DBへの情報の永続的な保存 • 物理サーバ⼀覧 • 搭載されてあるハードウェア • ユーザが作ったサーバ API Controllerのおしごと BMサービスのオーケストレータの側⾯ • 他のサービスとの連携のインタフェース • 認証認可サービス • イメージレポジトリ • ネットワークコントローラ • 各コンポーネントに対する命令 • Conductorに物理サーバ起動をリクエスト • DHCP AgentにIP Addr割当をリクエスト • リクエスト処理のトランザクション管理 • 作成フロー • 初期化フロー

Slide 54

Slide 54 text

物理サーバの初期化処理 • ファームウェアのアップデート • ディスクの初期化 • UEFIやBMC設定の初期化 Conductorのおしごと OSインストールやセットアップ • インストールメディアのネットワークブート • PXE boot，リモートマウント • OSインストールの⾃動化 • Kickstartなど • ユーザリクエストの情報の設定 • cloudinitなど

Slide 55

Slide 55 text

Baseboard Management Controller (BMC) • サーバ向けに搭載されている管理・監視⽤のマイコン • 電源On/Offに関わらず，通電していれば常に利⽤可能 • ネットワーク経由で利⽤可能で，様々な機能が提供されている • リモートコンソール，ハードウェア監視，BIOS設定変更… • ベンダによってインターフェースが異なる • HPE: iLO • DELL: iDRAC • Fujitsu: iRMC • 標準化されたAPIとして，IPMI と Redfish というものが存在

Slide 56

Slide 56 text

初期化処理 • ファームウェアのアップデート • ディスクの初期化 • UEFIやBMC設定の初期化 Conductorのおしごと OSインストールやセットアップ • インストールメディアのネットワークブート • PXE boot，リモートマウント • OSインストールの⾃動化 • Kickstartなど • ユーザリクエストの情報の設定 • cloudinitなど BMCのAPIを利⽤して，物理機器の状態を変えていく

Slide 57

Slide 57 text

物理筐体の故障監視 • BMCのAPI利⽤したハードウェアの監視 • ディスク，メモリ，電源 • 故障していた場合， ECL全体の監視システムへアラート発報 Monitorのおしごと BMサービスの監視 • 各コンポーネントVMが起動しているか • プロセスが動いているか • E2Eでサービス全体の動作確認 • 定期的にCRUDリクエストを実施

Slide 58

Slide 58 text

筐体の状態に⼤きく左右される • アクセスタイミングではタイムアウト • 予期せぬリブートによるデプロイ失敗 • たまに応答しなくなるBMC • そしてそのまま復活しないとか • BMCが⼤嘘ついてくるとか • BMC「壊れました」 → 中を⾒ると壊れてなかったり物理結合の難しさ BMCによって実装内容が⼤きく異なる • Redfishで実装されてない • 独⾃APIでしか使えないとか • そもそも取得できませんとか • それぞれでレスポンスが違う • JSONを喋ったりXMLを喋ったりこういった部分をどこのレイヤで抽象化して統⼀的に操作できるかにソフトウェア的な難しさとおもしろさがある

Slide 59

Slide 59 text

この章のまとめ • 処理を⾏う上で，多くのアプリケーションが連携して動作している • ベアメタルコントローラ，ネットワークコントローラ，… • 更にはベアメタルコントローラの中でも，各コンポーネントが連携して動いている • 物理を相⼿にすると，⾊々と⾟いこともおおい • なぜか応答を返さなくなるBMC • なぜか値が⽋損するAPIレスポンス • なにもしてないのに壊れるハードウェア => そこをソフトウェアの⼒でなんとかしているんだよ! えっへん!

Slide 60

Slide 60 text

おわりに

Slide 61

Slide 61 text

まとめ⻑々と話しましたが，なんだかんだでクラウドサービスの開発は楽しいです • ⾃分たちの作ったクラウドの上で，多くのユーザがサービスを提供している • そのサービスの先に更に多くのユーザがいる • それだけ⾃分たちの作ったものに責任が出てくる技術的なチャレンジも多く，圧倒的成⻑ができる • 障害をできるだけ発⽣させないための設計や，発⽣後に早期回復できる仕組みづくり • 物理機器など，ソフトウェアの外側にある状態を持ったものの上⼿い⼿懐け • 信頼性(エラーハンドリング)，⼀貫性(ステート遷移の安定度)を⾼めるためには…?

Slide 62

Slide 62 text

クラウドサービスに興味を持った⼈ • まずは触ってみる • GCPとかAWSとかでVM⽴てたりできるよ! • ドキュメントとか⾒ると背景とかが⾒えてきたりするよ! • ⾃宅やサークルのマシンで実験環境を作ってみる • OpenStackやOpenNebulaといったクラウドプラットフォームのOSSを触ってみる • ⾃宅にIAサーバとNW機器を置いてなんちゃってクラウドを作る(逸般の誤家庭) • API越しで連携するアプリケーションを書く • ⾃分が管理できない範囲のアプリケーションと連携するという難しさが体験できる • これをどうハンドリングするかを考えるの重要

Slide 63

Slide 63 text

参考: ECL2.0関連の発表 (1) 開発内容タイトル/ カンファレンス全般クラウド上に堅牢なシステムを作るためのベストプラクティス @ NTT Communications Forum 2019 SDN・NWの⾃動化の賢い使い⽅ @ NTT Communications Forum 2020 SDN エンタープライズ向けクラウドのSDN基盤の安定化への挑戦 @ JANOG 44 NFV NFVサービスの試験⾃動化とCI/CD @ CNTOM 2019 OpenStack Software エンタープライズ向けクラウドサービスにおける⼤規模・商⽤環境でのOpenStackバージョンアップとVMHAの実運⽤ @ Cloud Operator Days Tokyo 2020 Practical Case of GUI and Infrastructure Development for Public Cloud Service Utilizing Horizon @ OpenStack Summit 2017 May OpenStack上の環境構築⾃動化に向けたTerraform/Pulumiの活⽤ @ Cloud Native Days Tokyo 2019

Slide 64

Slide 64 text

参考: ECL2.0関連の発表 (2) 開発内容タイトル/ カンファレンス Baremetal ベアメタルのつくりかた @ NTT Engineersʼ Festa #2 SRE Blue-Green デプロイメントを採⽤したデプロイの仕組みを実装して共通基盤として導⼊した話 @ SRE NEXT 2020 運⽤⾃動化⼤規模クラウドサービス故障復旧におけるゼロタッチオペレーションシステムの開発と評価 @ 情報通信学会 ICM研究会 2019

Slide 65

Slide 65 text

any questions?

Slide 66

Slide 66 text

参考⽂献 / 素材利⽤ • Peter Mell, and Timothy Grance, "The NIST definition of cloud computing.”, National Insutitute of Standards and Technology, Sep. 2011. • “Open Source Cloud Computing Infrastructure - OpenStack”, Open Infrastructure Foundation, https://www.openstack.org/ • ⾶岡良明, “クラウド上に堅牢なシステムを作るためのベストプラクティス〜クラウドへの移⾏で失敗しないために〜”, NTT Communications Forum 2019, Oct. 2019. • ⾶岡良明, “エンタープライズ向けクラウドの開発・運⽤最新状況 “, 信学技報, Vol.120, No.259, pp.35-36, Nov. 2020 • 森垣航太, “Blue-Green デプロイメントを採⽤したデプロイの仕組みを実装して共通基盤として導⼊した話”, SRE NEXT 2020 IN TOKYO, Jan. 2020 • “Google Data Centers”, Google Inc., https://www.google.com/about/datacenters/gallery/ • 本資料に記載されている会社名，サービス名，製品名は⼀般に各社の登録商標または商標です本⽂中では，「™」,「®」は明記していません