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

2021/03/26 に香川大学の学生向けに開催した講演会で喋りました．

Transcript

1. クラウドサービスのウラオモテ Naoki Hanakawa / NTT Ltd Japan @⾹川⼤学オンライン講演会 2021/03/26
2. 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
3. 注意 • 本発表中に出てくる機器の情報やアーキテクチャについては⼀般的な例であり， 明⽰されていない限り，特定のサービスについて⽰唆しているわけではありません
4. “クラウドサービス” #とは https://flic.kr/p/abCSpq
5. クラウドサービスを使ったことがある⼈? 「クラウドサービス」と聞いてどんなものをイメージしますか?
6. よくイメージされるクラウドサービス
7. 実際にクラウドサービスといわれるものたち
8. 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
9. つまるところ… 共有されたコンピューティングリソースに • どこからでも • 簡単に • 必要に応じて • ネットワーク経由で アクセスできるモデルであり， プロバイダとは最⼩限の⼿続きややり取りですぐに使える
10. 実装モデル 基本的な特徴 クラウドモデルの構成 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
11. どんな特徴があるかというと • オンデマンド・セルフサービス • プロバイダと直接やり取りすることなく， 必要に応じて⾃動的に利⽤でき，リソースを⼀⽅的に設定できる • 幅広いネットワークアクセス • ネットワークを通じて利⽤可能であり，標準的な仕組みで接続可能 • リソースの共⽤ • リソースはマルチテナントモデルとして提供される • スピーディな拡張性 • 需要に応じて即座にリソースを拡張できる • 計測可能なサービス • リソースの利⽤状況はモニタ/コントロールされ，報告・明⽰できる
12. 具体的にどんな感じで提供されているかというと • 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の組み合わせ
13. 具体的にどんなサービスがあるかというと 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はいっぱいあります
14. 責任共有モデル 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
15. 責任共有モデル 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 • ユーザが⾃由に利⽤・設計できる • ⾃分たちで設定や管理をしなければならない • 何かあっても⾃分たちの責任 • サポートは基本無い • ユーザに選択の⾃由はない • プロバイダがある程度設定済み • 何かあったらプロバイダ側の責任 • サポートなどもしてくれる
16. 責任共有モデル 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 今⽇の話はここです
17. IaaSとは 特徴 • サーバ(VM・物理)，ストレージ，ネットワークなどが使えるやつ • 構成の柔軟性が⾼い • VMの細かなスペック設定，NWの細かな設計とか 得意分野 • 既存(On-premises)からの移⾏ • ハイパフォーマンスを求められる部分 • CPU/GPU/Memoryなど • OS(Kernel)，Middlewareなどに縛りがある • 特殊なNetwork Protocolの利⽤
18. IaaSのメリット・デメリット “オンプレに⽐べて”という⽂脈が多い • メリット • 従量課⾦制のため，固定費がかからない • オンプレミスに⽐べ，HWの保守の⼿間がかからない • NWの⾃由度が⾼く，ほぼなんでもパケットを流せれる › とはいえ，ベンダーによってはある程度制約があることもある • VMスペックの⾃由度が⾼く，CPUやメモリのカスタマイズもしやすい • デメリット • 基本的なサーバ管理(運⽤・セキュリティ対策)は引き続き⾏う必要がある • ⾃由度は⾼いため，メンテナンスコストが⾼い
19. この章のまとめ • 昨今皆さんは意識せずに「クラウドサービス」というものを使っている • ⾹川⼤全体としてはMS365だったりZoomだったりGMailだったり • SLPの⼈たちはSlackを使ってるし，中にはAWSとかGCPとか使ってる⼈もいるかも • なんなら今⽇使ってるZoomもクラウドサービスの1つ • クラウドサービスは，様々な特徴や実装モデル，提供⽅式がある • 定義に従うと，⼤きく IaaS，PaaS，SaaS に分類できる • 最近では更に深化したモデルも提唱されて利⽤されつつある • IaaSは，クラウドの中では⾃由度の⾼いサービス • ハイパフォーマンスを求めるソフトウェアなどに向いたサービス • ただし，⾃分たちで管理する部分も多く必ずしも楽になりきれない
20. クラウドサービスのウラガワ “プロバイダ”としてサービスを提供するにはどんなことが必要か
21. あるサービスを運⽤しています Database Load Balancer (VM) App (VM) Internet Firewall (VM) Logical Network Storage
22. このサービスがクラウド上で動いていたとすると… Database Load Balancer (VM) App (VM) Internet Firewall (VM) Logical Network Storage
23. この部分は⼀体どうなっているんだろう Database Load Balancer (VM) App (VM) Internet Firewall (VM) Logical Network Storage
24. 中を⾒てみると Database Load Balancer (VM) App (VM) Internet Firewall (VM) Logical Network Storage
25. NW機器(物理) サーバ(物理) Storage Hypervisor z “この部分”はこんなシステムで⽀えられています Database Load Balancer (VM) App (VM) Storage NWリソース
26. NW機器(物理) サーバ(物理) Storage Hypervisor z 物理サーバの部分 Database Load Balancer (VM) App (VM) Storage NWリソース 1つの物理サーバに数⼗台の仮想マ シン(VM)を⽴ててお客様に提供 VMで性能が⾜りない部分は物理 サーバの専有メニュー(ベアメタル サーバ)も提供 また，お客様のデータを保存するス トレージサーバもある
27. NW機器(物理) サーバ(物理) Storage Hypervisor z NW機器 Database Load Balancer (VM) App (VM) Storage NWリソース スイッチとかルータと呼ばれるもの 故障するとお客様の通信が成⽴しなくなるため，様々な技術を使って冗⻑化をしている
28. NW機器(物理) サーバ(物理) Storage Hypervisor z “この部分”はこんなシステムで⽀えられています Database Load Balancer (VM) App (VM) Storage NWリソース クラウドサービスの”外”につながるネットワーク インターネットへ抜けたりVPNを使ってお客様の環境と接続したり
29. NW機器(物理) サーバ(物理) Storage Hypervisor z じゃあこの”システム"はどこで動いているか Database Load Balancer (VM) App (VM) Storage NWリソース
30. from https://www.google.com/about/datacenters/gallery/
31. from https://www.google.com/about/datacenters/gallery/ サーバルームで動いていて，こんな部屋はどこにあるかというと
32. from https://www.google.com/about/datacenters/gallery/
33. from https://www.google.com/about/datacenters/gallery/ データセンタと呼ばれる巨大な建物で動いています
34. 「結局は物理」 • クラウドサービスの裏側は，実は巨⼤な「オンプレミス」なシステム • 数百〜数千台という単位の規模の物理サーバやストレージ，NW機器が • データセンタのなかのサーバルームにて動いている • → 様々なエンジニアが影で⽀えている • ソフトウェア • ネットワーク • 運⽤保守 • 24hの監視
35. 「結局は物理」 • クラウドサービスの裏側は，実は巨⼤な「オンプレミス」なシステム • 数百〜数千台という単位の規模の物理サーバやストレージ，NW機器が • データセンタのなかのサーバルームにて動いている • → 様々なエンジニアが影で⽀えている • 開発エンジニア › ソフトウェア › ネットワーク • オペレータ › 運⽤保守 › 24hの監視 しかしそれだけではクラウドサービスは 運⽤できない!!!
36. 実装モデル 基本的な特徴 クラウドモデルの構成 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 再掲
37. 実装モデル 基本的な特徴 これどうやって実現してるん…? 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 …?
38. z NW機器(物理) サーバ(物理) Storage Hypervisor z “この部分”はこんなシステムで⽀えられています Database Load Balancer (VM) App (VM) Storage 再掲
39. z NW機器(物理) サーバ(物理) Storage Hypervisor z お前は誰だ? Database Load Balancer (VM) App (VM) Storage …?
40. サーバ(物理) Storage Hypervisor z クラウドサービスを⽀えるソフトウェア Database Load Balancer (VM) App (VM) Firewall (VM) Logical Network Storage etc… GUI SDN基盤 認証認可基盤 各サービス コントローラ 課⾦計算 バックエンド サービス
41. マイクロサービスアーキテクチャによる連携 仮想サーバ 共通機能(契約管理・認証機能・課⾦など) ベアメタル サーバ ネットワーク モニタリング リソース・ コントローラ コンピューティング (仮想サーバ) ストレージ ネットワーク コンピューティング (ベアメタル) モニタリング (リソースなど) モニタリング (監査ログなど) ユーザから⾒た 機能･サービス 共通機能 リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ ... 各コンポーネントはAPIで連携 コンポーネント化 されたソフトウェア群
42. 物理と論理を 紐付けるコントローラ ポータル (GUI) ドキュメントサイト 課⾦システム モニタリングシステム ベアメタル コントローラ ストレージ コントローラ 仮想サーバ コントローラ 認証認可システム 外部クラウド 接続 VPNサービス 問い合わせシステム 論理NW接続 インターネット接続 ネットワークコントローラ SDNコントローラ 外部クラウド 更にそのソフトウェアをレイヤに分けると… 純粋な ソフトウェア 物理世界の 制御 SDNコントローラ
43. 物理と論理を 紐付けるコントローラ ポータル (GUI) ドキュメントサイト 課⾦システム モニタリングシステム ベアメタル コントローラ ストレージ コントローラ 仮想サーバ コントローラ 認証認可システム 外部クラウド 接続 VPNサービス 問い合わせシステム 論理NW接続 インターネット接続 ネットワークコントローラ SDNコントローラ 外部クラウド 更にそのソフトウェアをレイヤに分けると… 純粋な ソフトウェア 物理世界の 制御 SDNコントローラ いわゆるWebアプリケーション • 直接ユーザ(お客様・オペレータ)が閲覧・操作するインターフェース • GUIによる⼈間からの操作 • APIや，SDKによるプログラムからのアクセス • 各コントローラから情報を収集して，ユーザに提⽰できるよう情報を整形 • 各サービスのログやトラフィックからビジュアライズ • ユーザの各サービスの利⽤量から使⽤料⾦の計算
44. 物理と論理を 紐付けるコントローラ ポータル (GUI) ドキュメントサイト 課⾦システム モニタリングシステム ベアメタル コントローラ ストレージ コントローラ 仮想サーバ コントローラ 認証認可システム 外部クラウド 接続 VPNサービス 問い合わせシステム 論理NW接続 インターネット接続 ネットワークコントローラ SDNコントローラ 外部クラウド 更にそのソフトウェアをレイヤに分けると… 純粋な ソフトウェア 物理世界の 制御 SDNコントローラ ソフトウェアを使って物理機器をコントロールし，サービスとしてお客様に提供 • GUIやAPIのリクエストを受け付ける • 実際に物理機器をソフトウェアから操作してセットアップする • 連携する他のコントローラにリクエストを出して，各種リソースと接続
45. ポータル (GUI) ドキュメントサイト 課⾦システム モニタリングシステム ベアメタル コントローラ ストレージ コントローラ 仮想サーバ コントローラ 認証認可システム 外部クラウド 接続 VPNサービス 問い合わせシステム 論理NW接続 インターネット接続 ネットワークコントローラ SDNコントローラ 外部クラウド 更にそのソフトウェアをレイヤに分けると… 純粋な ソフトウェア 物理世界の 制御 SDNコントローラ 物理機器を⾼信頼に稼働させるための設計や⾃動化の実施 • “Virtual Chassis/Virtual Switching System”といった技術で機器の冗⻑化 • ⼤規模な実験環境 (testbed)での安定試験やバグ取り • バックボーンNWの⾃動構築 物理と論理を 紐付けるコントローラ
46. この章のまとめ • クラウドサービスのウラガワは「巨⼤なオンプレミスサービス」 • 数百〜数千台規模の物理機器 • それを収容するサーバルーム • サーバルームを抱えるデータセンタ • 物理機器だけではなく，数多くのソフトウェアによってリソースを制御 • いわゆるWebアプリケーションのような部分 • ソフトウェアから物理機器を管理してサービスとして提供する部分 • サービスの⼟台を⽀える物理機器を⼿懐ける部分
47. 物理と論理を紐付けるコントローラとは ECL2.0 ベアメタルサーバのコントローラを例にして
48. 物理と論理を 紐付けるコントローラ ポータル (GUI) ドキュメントサイト 課⾦システム モニタリングシステム ベアメタル コントローラ ストレージ コントローラ 仮想サーバ コントローラ 認証認可システム 外部クラウド 接続 VPNサービス 問い合わせシステム 論理NW接続 インターネット接続 ネットワークコントローラ SDNコントローラ 外部クラウド 更にそのソフトウェアをレイヤに分けると… 純粋な ソフトウェア 物理世界の ⾃動化 SDNコントローラ 再掲 ここを例にして話をします
49. ベアメタルサーバ(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)
50. ベアメタルサーバ(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)
51. BMコントローラのウラガワ BMコントローラ API Controller Monitor Conductor A Conductor B DHCP Agent Gateway controller 他コントローラ イメージレジストリ ネットワーク コントローラ 物理サーバ SSL-VPN 認証認可サービス GUI
52. BMコントローラのウラガワ BMコントローラ API Controller Monitor Conductor A Conductor B DHCP Agent Gateway controller 他コントローラ イメージレジストリ ネットワーク コントローラ 物理サーバ SSL-VPN 認証認可サービス GUI
53. Webアプリケーションとしての側⾯ • リクエスト受付 • ユーザ向け › CRUDなどの各種操作 • 管理者・オペレータ向け › リソース管理 › 利⽤量の収集 › ライセンス管理 › リソース閉塞・開放 • DBへの情報の永続的な保存 • 物理サーバ⼀覧 • 搭載されてあるハードウェア • ユーザが作ったサーバ API Controllerのおしごと BMサービスのオーケストレータの側⾯ • 他のサービスとの連携のインタフェース • 認証認可サービス • イメージレポジトリ • ネットワークコントローラ • 各コンポーネントに対する命令 • Conductorに物理サーバ起動をリクエスト • DHCP AgentにIP Addr割当をリクエスト • リクエスト処理のトランザクション管理 • 作成フロー • 初期化フロー
54. 物理サーバの初期化処理 • ファームウェアのアップデート • ディスクの初期化 • UEFIやBMC設定の初期化 Conductorのおしごと OSインストールやセットアップ • インストールメディアのネットワークブート • PXE boot，リモートマウント • OSインストールの⾃動化 • Kickstartなど • ユーザリクエストの情報の設定 • cloudinitなど
55. Baseboard Management Controller (BMC) • サーバ向けに搭載されている管理・監視⽤のマイコン • 電源On/Offに関わらず，通電していれば常に利⽤可能 • ネットワーク経由で利⽤可能で，様々な機能が提供されている • リモートコンソール，ハードウェア監視，BIOS設定変更… • ベンダによってインターフェースが異なる • HPE: iLO • DELL: iDRAC • Fujitsu: iRMC • 標準化されたAPIとして，IPMI と Redfish というものが存在
56. 初期化処理 • ファームウェアのアップデート • ディスクの初期化 • UEFIやBMC設定の初期化 Conductorのおしごと OSインストールやセットアップ • インストールメディアのネットワークブート • PXE boot，リモートマウント • OSインストールの⾃動化 • Kickstartなど • ユーザリクエストの情報の設定 • cloudinitなど BMCのAPIを利⽤して，物理機器の状態を変えていく
57. 物理筐体の故障監視 • BMCのAPI利⽤したハードウェアの監視 • ディスク，メモリ，電源 • 故障していた場合， ECL全体の監視システムへアラート発報 Monitorのおしごと BMサービスの監視 • 各コンポーネントVMが起動しているか • プロセスが動いているか • E2Eでサービス全体の動作確認 • 定期的にCRUDリクエストを実施
58. 筐体の状態に⼤きく左右される • アクセスタイミングではタイムアウト • 予期せぬリブートによるデプロイ失敗 • たまに応答しなくなるBMC • そしてそのまま復活しないとか • BMCが⼤嘘ついてくるとか • BMC「壊れました」 → 中を⾒ると壊れてなかったり 物理結合の難しさ BMCによって実装内容が⼤きく異なる • Redfishで実装されてない • 独⾃APIでしか使えないとか • そもそも取得できませんとか • それぞれでレスポンスが違う • JSONを喋ったりXMLを喋ったり こういった部分をどこのレイヤで抽象化して統⼀的に操作できるかに ソフトウェア的な難しさとおもしろさがある
59. この章のまとめ • 処理を⾏う上で，多くのアプリケーションが連携して動作している • ベアメタルコントローラ，ネットワークコントローラ，… • 更にはベアメタルコントローラの中でも，各コンポーネントが連携して動いている • 物理を相⼿にすると，⾊々と⾟いこともおおい • なぜか応答を返さなくなるBMC • なぜか値が⽋損するAPIレスポンス • なにもしてないのに壊れるハードウェア => そこをソフトウェアの⼒でなんとかしているんだよ! えっへん!
60. おわりに
61. まとめ ⻑々と話しましたが，なんだかんだでクラウドサービスの開発は楽しいです • ⾃分たちの作ったクラウドの上で，多くのユーザがサービスを提供している • そのサービスの先に更に多くのユーザがいる • それだけ⾃分たちの作ったものに責任が出てくる 技術的なチャレンジも多く，圧倒的成⻑ができる • 障害をできるだけ発⽣させないための設計や，発⽣後に早期回復できる仕組みづくり • 物理機器など，ソフトウェアの外側にある状態を持ったものの上⼿い⼿懐け • 信頼性(エラーハンドリング)，⼀貫性(ステート遷移の安定度)を⾼めるためには…?
62. クラウドサービスに興味を持った⼈ • まずは触ってみる • GCPとかAWSとかでVM⽴てたりできるよ! • ドキュメントとか⾒ると背景とかが⾒えてきたりするよ! • ⾃宅やサークルのマシンで実験環境を作ってみる • OpenStackやOpenNebulaといったクラウドプラットフォームのOSSを触ってみる • ⾃宅にIAサーバとNW機器を置いてなんちゃってクラウドを作る(逸般の誤家庭) • API越しで連携するアプリケーションを書く • ⾃分が管理できない範囲のアプリケーションと連携するという難しさが体験できる • これをどうハンドリングするかを考えるの重要
63. 参考: 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
64. 参考: ECL2.0関連の発表 (2) 開発内容 タイトル/ カンファレンス Baremetal ベアメタルのつくりかた @ NTT Engineersʼ Festa #2 SRE Blue-Green デプロイメントを採⽤したデプロイの仕組みを実装して共通基盤として導⼊した話 @ SRE NEXT 2020 運⽤⾃動化 ⼤規模クラウドサービス故障復旧におけるゼロタッチオペレーションシステムの開発と評価 @ 情報通信学会 ICM研究会 2019
65. any questions?
66. 参考⽂献 / 素材利⽤ • 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/ • 本資料に記載されている会社名，サービス名，製品名は⼀般に各社の登録商標または商標です 本⽂中では，「™」,「®」は明記していません