システムに自律運用能力を持たせるNoOps
ゼンアーキテクツの岡氏は、2013年に日経SYSTEMSの特集「これが日本のトップアーキテクト」にて、トップアーキテクト18人の一人として選出された。Azureベースの案件も数多く手掛けており、「さまざまなプロジェクトですばらしい設計をしている」と、Azureテクノロジースペシャリストとしてクラウドベースシステムのアーキテクチャーや実装支援活動をしている川崎氏も一目置く人物だ。
セッションはまずOpsの10年戦争を振り返ることから始まった。今も続いているOpsの10年戦争の発端となったのが、2008年の「DevOps革命」である。DevOpsはインフラのソフトウェア化により、構成変更の自動化を促進するといったもの。つまり開発～運用のライフサイクルを高速に回せるようになった。2年前にGoogleが提唱したSRE（Site Reliability Engineering：信頼性エンジニアリング）はまさにDevOpsの実装例というべきもの。「詳しくは書籍を読んでほしい」と岡氏。
とはいえ「DevOpsやSREで障害がなくなるわけではない。アプリケーションのバグやアプリのVRのメモリリーク、ミドルウェアの不具合、ネットワーク障害などの部分をなんとかしないと、運用を担当する開発者が開発を行う時間が減る。そこで運用のための設計といった発想が必要になる」と岡氏は説明を続ける。これまでもシステム設計時に運用は考慮されてきていた。クラウド上で稼働するシステムの設計原則としてDesign for Failureがある。すべてが故障する前提で設計し、障害からの復旧を計画している。そしてこの発展系がNoOpsというわけだ。
NoOpsはシステムに自律運用能力を持たせることで、人間による運用を最小化すること。そのためには、次の3つの能力が必要になる。「Self Healing（故障発生時のサービス無影響＋自己修復の能力）」「In-Flight Renewing（変更・更新に対する無停止メンテナンスの能力）」「Adaptive Scale（負荷変動に弾力的に適応する自律的リソース調整の能力）」だ。
NoOpsで何が得られるのか。エンドユーザーにとってはサービス停止時間が最小化され、レスポンスタイムの安定、コストも最適化される。運用担当者は、「運用業務がなくなることはないが、障害対応作業の非同期化が実現するため、障害の原因特定や再発防止策の策定業務などに、ゆっくり後から取り組めるようになる」と岡氏はそのメリットを説明する。しかもシステムは自動で回復しているので、空いた時間で開発ができる。
NoOpsはDevOpsの発展系と説明したとおり、Design for FailureとDesign for Resiliency（回復性設計）を組み合わせて実現できるという。回復性設計では障害は起きるものとして捉え、ダウンタイムやデータ損失を回避すべく障害に対応することを目指す。最大の目的は障害発生時にもアプリケーションが完全に機能している状態を維持することだ。
「中でも一番、回復性があるとうれしいのがミドルウェアだろう。だが自分たちのプロジェクトに自前で回復性を持たせるのは難しい。だからこそ、プラットフォームとして回復性がネイティブに実装されているマネージドサービスの利用をお勧めする」と岡氏は説明する。マネージドサービスでも単純ホスティングではなく、クラウドネイティブで回復性を実装しているServerlessを選ぶことが重要だという。
Azure App Serviceが実装するNoOpsの機能
Azure App ServiceにもすでにNoOpsの機能が実装されている。その例として川崎氏は、次の2つの大規模ホストVMメンテナンスというイベントを紹介した。1つは2018年1月に実施された、CPU脆弱性対応のためのアップデート。もう1つが2017年12月～2018年1月にかけて行われたAzure App Service、Azure FunctionsのホストOSのアップグレードだ。川崎氏は、「2度、ホストOSのリスタートをかけなければならないという、大きなメンテナンスがあった」と話し、このイベントに伴う影響について「VMを利用しているお客さまから大量にクレームをいただいた。一方、NoOps基盤として実装されたPaaSのお客さまは、アップグレードされたことにすら気付いていなかった」と説明した。
Azure IaaSのVMリソースは、Fabric Controllerが可用性設定タイプ（可用性セットまたは可用性ゾーン）に基づいて異なる障害ドメインと更新ドメイン、またはゾーンにまたがってVMを配置・管理される。可用性セットとは物理的に異なるラックに配置し、可用性ゾーンはDCレベルで異なるところに配置するといった仕組み。これらの設定に応じてFabric ControllerがVMを配置していくわけだ。「しかし、これだけでは十分ではない。例えばメンテナンス前後の再起動が行われるときや、サービスの待避・投入のときどうするのか。またVMが例外やエラーを発生したとき、どうフェールオーバーするのか、障害VMの復旧、バースト前後のスケールアウト、スケールインなど、人がやらないといけないことがある」と川崎氏は説明を続ける。
先の大規模ホストVMメンテナンスの裏側で活躍していたのがApp Serviceである。App Serviceはスケールユニット単位でスケール可能なグローバルGEO分散システム。「全世界42リージョンでサービス展開をしている」と川崎氏。各リージョンで複数のDCが設置されており、スケールユニットを全世界で200以上配置している。例えば東日本リージョンの中にアカウントを作るとすると、その中のどのスケールユニットにどれだけ空きがあるか、プロビジョニングし最適なリソースを確保していく。各スケールユニットがいっぱいになると、そのリージョンで新しいスケールユニットが追加されていく、といった仕組みになっている。
スケールユニットは約5000台（2018年2月時点の数）のVMで構成されたマイクロサービスとなっており、「一通りアップサービスを動かすための機能が入っている」と川崎氏。また各スケールユニットは20個（2018年2月時点の数）の論理ユニット（Upgrade Domain）がある。アップグレードが行われる際は、このUpgrade Domainが使用される。
App Serviceは、岡氏が先程挙げた、NoOpsに必要な3つの能力を有している。1つはIn-Flight Renewingの能力。App Serviceであれば、サービスを動かしたままアップグレードをかけていくこともできる。アップグレード対象Upgrade DomainのアプリをHot Poolの空きVMに移動させ、移動後アプリをサービス管理下に投入。すべてのアプリを他にオフロードする。そして対象UDでアップグレードを実行するといった方法で実現している。「問題があるとすると、若干、リクエストに遅さを感じる程度。何事もなかったようにサービスは続行される」と川崎氏。
2つ目はSelf Healing。監視システムが障害ロールを検知し、サービス管理下より障害ロールを切り離す。Appサービスプランに基づき、足りないロールをHot Poolより割り当て、サービス管理下に投入するのである。「瞬間的にちらつきなどはあるかもしれないが、これも何事もなかったように、自動回復される」と川崎氏。
3つ目はAdaptive Scale。「App Serviceではオートスケールと呼んでいる。どのくらいのVMをバースト時に確保したいのか、宣言する。アクセスが集中したとき、メータリングシステムが負荷を検知して、自動的に空き領域に新しいVMがアサインし、準備ができたらサービスに投入される仕組みとなっている。このようにApp ServiceではNoOpsを実現するための重要な項目が実装されている」と川崎氏は力強く語る。
また裏側でどのようなことが行われているかは、App Serviceのダッシュボードの「問題の診断と解決」機能を使えば、すべて見ることができるという。
「基盤は徐々にNoOpsレディが広がりつつある。しかしサービス全体のNoOpsを実現するにはアプリケーションに回復性を持たせる必要がある」と岡氏は話し、アプリケーション回復性の設計原則として「処理は小さな粒度のステートレスで設計する」「非同期処理」「処理のべき等性を担保する」ことを挙げた。「これはサーバーレスアプリケーションの設計原則と同じ。これでミドルウェア以下はクラウドにお任せできる」と説明を続ける。これが実現すると、DevOpsからOpsがなくなり、Devし続けられるようになる。岡氏は、「人間の時間を価値創造、Devの時間に使いたい。そういった思想がNoOpsの根底にある」と語った。
Opsの自動化にはまだまだ時間がかかる。過信はしないことだという。岡氏と川崎氏は最後に次のように呼びかけ、セッションを締めた。
「業界を挙げて知見を集めていく必要がある。今、NoOpsのコミュニティの設立準備をしている。興味のある方はメンバー登録をしてほしい」
お問い合わせ
日本マイクロソフト株式会社
