Microsoft decode 2018 2日目
の編集
Top
/
Microsoft decode 2018 2日目
[
トップ
] [
編集
|
凍結
|
差分
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
]
Active
Rubyチートシート
成果物リスト
勉強会ログ
↑
アイデア
Webサービス案
Androidアプリ案
電子工作案
GreaseMonkey案
contribute
編集
↑
Recent
2023-11-12
自動車保険
2023-08-04
HDDリスト
2023-08-03
docker
2023-05-17
Rubyチートシート
2023-03-30
RAID5/トラブル20230324
2023-03-25
PC/misuzu
2023-03-24
PC
2023-03-23
PC/DESKTOP-7SL5J8R
2022-12-16
Linux
2022-11-09
Linux/ディスクイメージ取得
2021-05-23
CTF
2021-03-17
PC/misumi
2020-08-31
COMP
2020-03-28
PC/misumi/ubuntu
Windows 10
2018-06-04
Microsoft decode 2018 2日目
Microsoft decode 2018 1日目
2018-04-07
カメラ
2018-01-06
電力自由化
2017-12-21
CROSS×BEATS
B
I
U
D
H
[[]]
<br>
--
* NoOps へ舵を切れ 〜 Azure で実現するサーバレス自律運用システム [#e1dec96f] - 完全自動化はほんとに可能なのか? - NoOps = No Operations…ちょっと違う -- No Uncomfortable Ops。運用の嬉しくないところをなくそう -- 利用者の体験を妨げない -- 「トイル」の最小化(リリース手続き・パッチ適用・リソース監視・夜間待機など) -- コストの最適化 - 障害時の切り分け・不具合修正・デプロイなどほとんどを人間が対応している -- 緊急対応・回復処理はシステムに任せて、人間は原因究明に集中したい -- インフラ担当の働き方改革になる - NoOpsの3つの能力 -- 自己修復 -- 無停止メンテナンス -- 自律的リソース調整 --- 予定外の負荷変動に自律的に対応 - 実例: AzureのMeltdown/Spectreへの対応 -- IaaS利用者からクレーム殺到 -- PasS利用者は気づきもしなかった -- Azureだと「問題の診断と解決」で裏で走ったメンテナンスのログが見れる -- 詳細はセッションAD38で - 自己修復は「取り回しの軽さ」 -- ChefでWordpressを構築: 240秒 -- WebApp for Containersだと14秒 -- 復元力。「壊れない」から「いつでも回復できる」への価値観の転換 -- https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/resiliency - 回復性 = 復元力 + 回復メカニズム - 30秒で復旧できれば、障害ではなく遅延で済む - 一つの目安として、復元力が高いのはコンテナやサーバレスとして扱うもの、VM や非冗長構成は復元力としては低い - 高い回復性があると、いろいろと広がる -- 秒単位のスケールアウト・スケールイン -- 障害発生時の自己回復 -- オンザフライでのインスタンス変更 - 高い回復性を備えたマネージドサービスを選択する -- 仕様にあるフェイルオーバーの時間・スケールアウトの時間から推測するといい - オンプレでもNoOpsは可能だが、クラウドに似た形に役割と組織の再編成が必要 - アプリにも回復力を持たせる必要がある -- 例: 長いバッチを走らせてるとインスタンスを移動できない -- 「大きな処理より複数の小さな処理」「ステートレス」「非同期処理」「処理の冪等性」「処理結果をすべて記録」 -- シンプルな「リトライ」で素早く回復するのを目指す - 非機能要求のハードルを上げる -- 設計が大事。回復性のレベルは後から変更できない。最初から高い目標を目指す - クラウドにお任せ → 設計がおざなりになりがち。アプリもちゃんと設計してね
タイムスタンプを更新
テキスト整形のルールを表示する
Last-modified: 2018-06-04(月) 11:44:07