2018/2/16 Developers Summit 2018 16-B-2 「高可用性＋ハイスケールシステムを自律運用させてみよう 　～ Microsoft Azure による Serverless から NoOps への挑戦」 講演資料です。 #devsumi

1. NoOps

2. 岡 大勝
@okahiromasa
株式会社ゼンアーキテクツ
代表取締役CEO
アーキテクト
DEC → HP → Rational Software
金融SE → オブジェクト指向＆RUPの導入支援
2003年にゼンアーキテクツを設立
先端技術による”企業のIT投資の最適化”がミッション
2013年 日経BP「日本のトップITアーキテクト」の
一人として選出
川崎 庸市
@yokawasa
日本マイクロソフト株式会社
Azureテクノロジー
スペシャリスト
Startup/Venture → ヤフー → マイクロソフト
11年間のサービス企業でのソフトウェア開発エンジニア、
4年間の検索製品のフィールドエンジニアを経験
2014年～ クラウド開発分野でお客様・パートナー様の
プリセールス技術支援、イベント・セミナー登壇を通じ
てクラウド技術の普及に従事

3. 「好きなものを好きなときにローンチしたいんだ」
「いったん動いたシステムは一切変更したくないね」
vs

4. 「好きなものを好きなときにローンチしたいんだ」
「いったん動いたシステムは一切変更したくないね」
vs
コスト
事業計画
安定性
競合
モバイル対応
バースト
固定費削減
人件費
DevOps

8. ITILによる制圧 DevOps革命 SRE
201620081989
ISO/IEC 20000 制定
2000
Ops 年表

9. • 作業計画立案
• HW保守交換
• 個別機器の導入/設定変更
• ライセンスの管理
• 手順書の作成とレビュー
• 手順書に基づくインストール/設定
• 設定変更作業リハーサル
• インシデントの管理と計画
• 予算計画と契約手続き
• 機器入替に伴う入札
• etc..

10. https://documents.tips/documents/09-q7-itil-2011-overview-diagram-english-1111071.html

12. 原因
原因
バグ・ミスの
混入
経年劣化

13. 原因
原因
「できるだけ手を入れない」ことで
システムを安定稼働させようとしてきた
“仕様凍結”
“変更要求には
高額請求”
いわゆる「塩漬け」

14. 原因
原因 ハード
保守切れ予備機
枯渇
なに！新機種では旧OS
が動かんだと！
メインボード
故障
HDDが飛んだ
しかし、ハードウェアは必ず壊れる。
保守期限は必ずやってくる。

17. 原因
原因
仮想化技術により、
ハードウェアとソフトウェアの依存関係を排除。
それぞれ独立して扱えるようになる。
仮想化 ハード
保守切れ
予備機
枯渇
ハードを入れ替えても
影響はありません！
メインボード
故障
HDDが飛んだ

18. 原因
原因クラウド
ハード？なにそれ？
クラウド（EC2）の登場により、
ハードウェアは意識しなくてよい世界に突入。
雲の向こう
（クラウドベンダー）の仕事

20. • 塩漬け促進派（保守派）
「これでアプリに一切手を入れなくて済む。最高！」
• 呪縛解放派（革新派）
「ハードの制約がなくなるなんて夢みたい。最高！」

21. 呪縛解放派による保守的運用保守からの脱却

22. https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

24. 原因
原因
ボトルネックだった
構築リードタイムを
極小化
ライフサイクルを
高速化
インフラのソフトウェア化により構成変更の自動化を促進。
開発～運用のライフサイクルを高速に回せるようになる。

25. https://landing.google.com/sre/

27. 原因
原因
運用作業の
自動化を推進
開発者が運用を担うことで、非効率な運用作業の
ソフトウェア化を進めながら運用することができる。

30. 進化

32. 価値観の転換を迫られる

33. https://www.slideshare.net/AmazonWebServices/best-practices-for-architecting-in-the-cloud-jeff-barr

34. https://www.slideshare.net/kentamagawa/aws-7991623
全てが故障する前提で設計する
障害からの復旧を計画する

35. https://github.com/awslabs/aws-refarch-wordpress

36. 代替機がいくらでも用意できるなら、
停止時間は最小化できる。
原因
原因
「故障も通常オペレーション」を前提にシステムを
設計することで、迅速な復旧が可能になる。

38. • Self Healing
• In-Flight Renewing
• Adaptive Scale
システムに自律運用能力を持たせることで、
人間による運用を最小化すること

39. • 故障発生時の「サービス無影響 ＋ 自己修復」の能力
• システム構成要素の故障が提供サービスに影響させないだけでなく、
自己修復により復旧作業が不要（運用レス）な環境が目標。
• ハードウェア障害
• OSのフリーズ
• ミドルウェアの潜在バグ
• アプリケーションの不具合
• データセンターの故障
• リージョンのダウン
Self Healing
Photo on oemupdate.com

40. • 変更・更新に対する「無停止メンテナンス」の能力
• 全てのシステム構成要素の交換・更新・変更が無停止で実行可能な環境が目標。
• ハードウェアの交換
• OSやミドルウェアのアップデート
• システム構成変更
• アプリケーションの更新
In-Flight Renewing
https://www.flickr.com/photos/usnavy/8019591466/

41. • 負荷変動に弾力的に適応する「自律的リソース調整」の能力
• トラフィックのバーストや予期せぬ大量のバッチ処理など、
予定外の事象にも自律的に適応できるシステムの弾力性。
• Webトラフィックの集中
• ECサイトへの集中アクセス
• イベントや季節行事
• 締め日の一括処理
Adaptive Scale

44. https://docs.microsoft.com/ja-jp/azure/architecture/resiliency/

45. 自前運用
マネージドサービス
（単純ホスティング）
マネージドサービス
（クラウドネイティブ）
PaaSオンプレミス/IaaS
一般的な回復性レベルの比較

46. 自前運用
マネージドサービス
（単純ホスティング）
マネージドサービス
（クラウドネイティブ）
PaaSオンプレミス/IaaS
一般的な回復性レベルの比較

47. 原因
原因
プラットフォームが回復性を備えることで
HWだけでなくOSやMWの故障やメンテナンスを意識する必要がなくなる
回復性 ＝
障害から回復して
動作を続行させる能力
回復性をうまく実装できると、
サーバーインスタンスを意識し
なくて良くなる
＝ Serverless

49. Securing Azure customers from CPU vulnerability
CPU の脆弱性から Azure のお客様を保護するために
Azure App Service upgrade to Windows Server 2016 #63
Azure App Service、Azure FunctionsのWindows Server 2016へのアップグレード

50. https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/accelerated-maintenance

51. https://docs.microsoft.com/azure/architecture/resiliency/high-availability-azure-applications
Fabric Controllerが可用性設定タイプ（可用性セット or 可用性ゾーン）に基づいて
異なるFault DomainとUpdate Domain、またはゾーンにまたがってVMを配置・管理
Fabric
Controller
Rack #1 Rack #2 Rack #N
VM (Web)
VM (DB)
VM (Web)
VM (DB)
Power
Supply
Network
Switch
Power
Supply
Network
Switch
Power
Supply
Network
Switch
Network infrastructure
Power infrastructure
…
Compute Resource Pool
Fault Domain #1 Fault Domain #2 Fault Domain #N

52. Fault Domain #1
可用性セットや可用性ゾーンを設定して物理障害やメンテナンスが行われも、どちらかの
ホストは利用可能な状態を確保する
Fault Domain #2
VM (Web)
VM (DB)
VM (Web)
VM (DB)
ただし、必要最低限の設定でありサービスの可用性を確保
するためにはまだまだやることがある・・・
Web用
可用性セット
DB用
可用性セット

55. Azure Regions Datacenters
…
Scale Units
(Stamps)
…

56. https://msdn.microsoft.com/en-us/magazine/mt793270.aspx
世界中のScale Unit
(SU)に関する情報を保持しリソース
コントロールを行う
• アプリ作成時にその要件に基づいて
Geo Masterが最適なSUを選択肢し、
そのSUに処理をフォワード

57. Scale Unit
…
Upgrade Domain(UD) x 20
1 UDはSU全体の約5％
のVMに相当
Container Registry
CRUD API
Publishing
HTTP

58. • 3インスタンス

60. In-Flight Renewing
1. アップグレード対象UDのアプリをHot Poolの
空きVMに移動させ、移動後アプリをサービス
管理下に投入。全てのアプリを他にオフロード
2. 対象UDでアップグレードを実行
• 3インスタンス

61. Self Healing
1. 監視システムが障害ロールを検知し、サービス
管理下より障害ロールを切り離す
2. Appサービスプランに基づき足りないロールを
Hot Poolより割り当て、サービス管理下に投入
• 3インスタンス

62. Adaptive Scale
1. メータリングシステムが負荷を測定し、ユーザ
指定のメトリックが閾値を超えたことを検知
2. プランに基づきHot Poolよりスケール用のVM
を割り当て、サービス管理下に投入
• 通常３インスタンス
• 最大5インスタンス

64. ここまできたら

65. 原因
原因
アプリケーションに回復性を持たせることで、
システム全体を自律的運用に近づけることができる。
回復性を備えた
アプリケーション

66. 原因
原因
人間の時間は「価値創造 = Dev」のために

67. Serverless アプリケーションの設計原則

68. ① 処理データの
リクエスト
③計算処理を100万回ループ
Database
Virtual Machine
④ 処理結果の書き込み
② 100万件のデータ

69. ① 処理データの
リクエスト
③ 100万件の個別処理に分離
Database
Serverless
② 100万件のデータ
⑥ 処理結果の書き込み
④ Jobを1件ずつキューに投入
⑤（可能であれば）
Jobの並列実行
Serverless Firm

70. https://github.com/NoOps-jp/functions-batch-handson
https://github.com/zenarchitects/functions-batchapps
ハンズオンマテリアル
サンプルコード
公開してます

71. https://docs.microsoft.com/ja-jp/azure/architecture

74. NoOps Japan Community 設立準備中
https://NoOps.connpass.com
https://github.com/NoOps-jp/
Coming Soon
NoOpsの実現に向けて、プラットフォームや技術を超えて
知見と経験を共有していくためのコミュニティです。