Downloaded 72 times
![[Japan Tech summit 2017] CLD 013](https://cdn.slidesharecdn.com/ss_thumbnails/techsummit2017pdfcld013-171115032120-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Japan Tech summit 2017] CLD 007](https://cdn.slidesharecdn.com/ss_thumbnails/techsummit2017pdfcld007-171115032107-thumbnail.jpg?width=640&height=640&fit=bounds)
![[旧版] ゼンアーキテクツ「ものづくり」五つの掟](https://cdn.slidesharecdn.com/ss_thumbnails/zen-no-okite-five-things-180603232029-thumbnail.jpg?width=640&height=640&fit=bounds)
NoOpsへ舵を切れ
- 1. NoOps へ舵を切れ - Azureで実践するサーバレス自律運用システム AD15
- 2. 岡 大勝 @okahiromasa 株式会社ゼンアーキテクツ 代表取締役CEO アーキテクト DKIS ⇒DEC ⇒ HP ⇒ Rational Software 金融SE ⇒ オブジェクト指向＆RUP の導入支援 2003年にゼンアーキテクツを設立 先端技術による”企業のIT投資の最適化”がミッション 2013年 日経BP「日本のトップITアーキテクト」の 一人として選出
- 3.
- 4.
- 5. NoOps = NoOperations
- 6.
- 7. NoOps = NoOperations ?
- 8.
- 9.
- 10.
- 11. NoOps とは？ 1. 利用者の体験を妨げないシステム運用保守の実現 •障害時のダウン、計画停止、負荷集中時の性能低下、etc.. 2. システム運用保守で発生する「トイル」の最小化 • リリース手続き、パッチの適用、リソース監視、待機、etc.. 3. システム運用保守コストの最適化 • 余剰資源を持たない、適正品質、人材活用、働き方改革、etc.. システム運用保守に関する「嬉しくないもの」を取り除く活動 BE HAPPY !!
- 12. Google “Site ReliabilityEngineering”より
- 13.
- 14. 人間は以下に専念 • 障害の原因究明 • システムの「設計」改善 •より良いサービスに向けた活動 障害発生 初期対応 切り分けと 原因究明 サービス停止期間 不具合修正 正常稼働 復旧作業 正常稼働 障害発生 システムが 障害検知 回復処理 サービス無停止 一般的な障害発生時の作業 NoOpsで目指すシステム運用保守 NoOps で目指すシステム運用保守の姿 システムが 自律的に行う 人間による 作業
- 15.
- 16.
- 17. Securing Azure customersfrom CPU vulnerability CPU の脆弱性から Azure のお客様を保護するために Azure App Service upgrade to Windows Server 2016 #63 Azure App Service、Azure FunctionsのWindows Server 2016へのアップグレード
- 18.
- 23.
- 24.
- 25. Robustness から Resiliencyへの 価値観の転換 「壊れない」 「いつでも回復できる」
- 26. 復元力 構成要素の一部が一時的に利用できない状態に なったとしても、サービスの稼働に影響を与えること なく元の状態に回復できる能力。 オートヒーリングやスロットリングなどの回復性設計 パターンによって実装される。 Monitor Automation 回復メカニズム 故障や過負荷などのイベントを識別するための監 視（Monitor）と、イベント発生時にリトライなど の回復処理を実行する自動化スクリプト （Automation）によって構成され、復元力を持 つサービスを正常な状態に回復させる役割を担う。 (Resiliencability) (Mechanism ofresilience) 「回復性」 (Resiliency) サービスに影響を 与えそうな事象 サービスは 問題なく稼働継続
- 27.
- 28. 回復性パターン（Resiliency Patterns） 【復元力のパターン】 リトライ スワップ フェールオーバー オートヒーリング デグレード バルクヘッド サーキットブレーカー スロットリング スケールアウト キューによる負荷平準化（QLL） 補償トランザクション リーダー選択 【回復メカニズムのパターン】 イベント通知 正常性モニター ログ検知 https://docs.microsoft.com/ja-jp/azure/architecture/resiliency/ 【参考】 回復性に優れた Azure 用アプリケーションの設計 「高い復元力」を持つサービスのみ可能
- 29. App Service Functions AzureDB for MySQL SQL Database Azure DB for PostgreSQL SQL Data Warehouse Azure Data Factory Event Hub Service Fabric Azure Kubernetes Service (AKS) Azure Container Instances Virtual Machine Virtual Network Blob Storage Search Redis HD Insight Service Bus Media Service Application Gateway Load Balancer Managed Disks Cosmos DB
- 30. App Service Functions AzureDB for MySQL SQL Database Azure DB for PostgreSQL Cosmos DB SQL Data Warehouse Azure Data Factory Event Hub Service Fabric Azure Kubernetes Service (AKS) Azure Container Instances Virtual Machine Virtual Network Blob Storage Search Redis HD Insight Service Bus Media Service Application Gateway Load Balancer Managed Disks コンテナ上で稼働コンテナエンジン VM上で稼働
- 31.
- 33. RTO とターンアラウンドタイム の違いは？ 分散保持により データ復旧の必要がないなら？
- 35.
- 36.
- 37. Azure Regions Datacenters (Zone) … ScaleUnits (Stamps) …
- 38.
- 39. Scale Unit … Upgrade Domain(UD)x 20 1 UDはSU全体の約5％ のVMに相当 Container Registry CRUD API Publishing HTTP
- 40.
- 42. In-Flight Renewing 1. アップグレード対象UDのアプリをHotPoolの空きVMに 移動させ、移動後アプリをサービス管理下に投入。全て のアプリを他にオフロード 2. 対象UDでアップグレードを実行 • 3インスタンス• 3インスタンス
- 43. Self Healing 1. 監視システムが障害ロールを検知し、サービス管理下よ り障害ロールを切り離す 2.Appサービスプランに基づき足りないロールをHot Poolよ り割り当て、サービス管理下に投入 • 3インスタンス
- 44. Adaptive Scale 1. メータリングシステムが負荷を測定し、ユーザ指定のメト リックが閾値を超えたことを検知 2.プランに基づきHot Poolよりスケール用のVMを割り当て、 サービス管理下に投入 • 通常３インスタンス • 最大5インスタンス
- 46. Data Azure Storage LRS ペアリージョン（西日本） プライマリリージョン（東日本） GEOバックアップ 接続エンドポイント VM ServiceFabric Azure Database Service Platform コンテナ化された MySQL/PostgreSQL エンジン MySQL /PgSQL GEOリストア Service Fabric クラスター 選択した価格レベルの クラスターのノードを確保し コンテナ化されたデータベースエンジン をデプロイ Gateway node node MySQL /PgSQL ノード障害を検出すると クラスタ上の別ノードに 再デプロイして処理を継続 ストレージはLRS冗長構成 （ローカル(同一DC)三重化） バックアップデータは ペアリージョンへの GEO冗長構成とともに ペアリージョン上への リストア（GEOリストア）も可能 Backup 5分間隔で自動バックアップ （最大35日分）
- 47. Service Fabric クラスター MySQLコンテナMy PG SQL PostgreSQLコンテナ SQL Databaseコンテナ MyPG SQL MySQLなどのAzure Databaseのインスタンスは、 Service Fabricクラスター上の軽量コンテナとして稼働する。 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5 東日本リージョン
- 48. Service Fabric クラスター MySQLコンテナMy PG SQL PostgreSQLコンテナ SQL Databaseコンテナ MyPG SQL My PG SQL My ノード障害が発生すると、Service Fabricクラスター上の 別ノードにコンテナをデプロイし、フェールオーバーを行う。 MySQLなどのAzure Databaseのインスタンスは、 Service Fabricクラスター上の軽量コンテナとして稼働する。 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5 Service Fabric クラスター GP-Gen5 空きノードへの コンテナのデプロイと構成 エンドポイントの切替 東日本リージョン 東日本リージョン
- 49. Service Fabric クラスター MySQLコンテナMy PG SQL PostgreSQLコンテナ SQL Databaseコンテナ MyPG SQL My PG SQL My ノード障害が発生すると、Service Fabricクラスター上の 別ノードにコンテナをデプロイし、フェールオーバーを行う。 MySQLなどのAzure Databaseのインスタンスは、 Service Fabricクラスター上の軽量コンテナとして稼働する。 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5 Service Fabric クラスター GP-Gen5 空きノードへの コンテナのデプロイと構成 エンドポイントの切替 東日本リージョン 東日本リージョン
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57. ① 処理データの リクエスト Database Serverless ② 100万件のデータ ④Jobを1件ずつ キューに投入 ⑤（可能であれば） Jobの並列実行 Serverless ファーム Monitor Automation カスタム回復メカニズム Jobとキューの監視と回復処理 ③ 10万件の個別処理に分離 ⑥ 処理結果の書き込み
- 58.
- 59. Blob1 Akamai SE1 SE2 SE3 SEN Blob2 Blob3 BlobN State Monitor AMS Blob1 SE1 SE2 SE3 SEN Blob2 Blob3 BlobN AMS State Monitor JapanEast Region Japan West Region State Monitor 1. 自律動作するスケジュール実行アプリケーション 2. 動画配信サービス内の各構成要素（Storageなど）の正常性を確認 3. 東西+国外リージョンの3箇所に配置。等間隔（1〜5分）でローテーション実行 4. モニタリング結果は、同様に3箇所に分散配置されたCosmosDBにState Logと して格納 5. 障害を検知した時点でTMのAPIより該当リージョンへのルーティングを切断。同時 にState Logに「リージョン切断」を記録 6. Logの切断を確認した以降のモニターは、モニタリングは継続するが、該当リージョ ンの障害によるアクションは行わない。 7. 障害回復によるリージョンの再接続（フェールバック）は手動で実施 Routing Change Request State Monitor State Log Cosmos DB State Log Cosmos DB Southeast Region (Singapore) その他 • Traffic ManagerのProbeも有効。Monitorの動作との整合性を保つため、 TMの状態もMonitorが監視する。 • 障害検知時は、Event Grid経由でリアルタイム通知 • State Logの内容を常時確認できるようなフロントエンドを用意 State Log Cosmos DB API Call Traffic Manager failure Failure Message メール SMS Chat DNS TTL < 10s SGP JP-E JP-W 3リージョンに分散配置された State Monitorが数分間隔で巡回監視 監視結果のステートはGlobal GEO Replされた Cosmos DBで一元保持 障害発生時はAPIからTMをスケールイン 実装方式 Event Grid
- 60.
- 61. DevOps 伝統的運用保守 （ITIL型） Design for Robustness （堅牢さを前提とした設計） Designfor Failure （故障を前提とした設計） NoOps Design for Resiliency （回復性設計） SRE （信頼性エンジニアリング） アジャイルによる 価値観の転換 クラウドによる 価値観の転換 しっかりと計画され、厳密に 管理された運用保守業務。 正常稼働していることが通常状態。 故障や不具合は例外処理として設計。 故障や不具合も通常状態として扱い、 発生時を想定して設計する。 開発と運用保守を一体として扱い、 状況の変化に柔軟に対応できる組織。 1990年代～ 2008年 運用保守アプローチ 運用保守もエンジニアリング業務として扱う。 ヒューマンエラーを最小化し、システムの信頼性 を維持するための継続的改善活動。 復旧作業時のヒューマンエラーを最小化する ため、障害の発生から正常稼働状態への復旧 まで想定して設計する。 システム設計アプローチ 2014年 現在
- 62. Design for ResiliencySRE NoOps = DevOps
- 63.
- 66.
- 67.
- 71.
- 72.