SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2018】セッションレポート(AD)

NoOpsで高可用性・ハイスケールシステムを自律運用させよう! 実現に必要な3つのポイント【デブサミ2018】

【16-B-2】高可用性+ハイスケールシステムを自律運用させてみよう ~ Microsoft Azure による Serverless から NoOps への挑戦

  • このエントリーをはてなブックマークに追加

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でアップグレードを実行するといった方法で実現している。「問題があるとすると、若干、リクエストに遅さを感じる程度。何事もなかったようにサービスは続行される」と川崎氏。

App Serviceが実現するIn-Flight Renewingの能力
App Serviceが実現するIn-Flight Renewingの能力

 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のコミュニティの設立準備をしている。興味のある方はメンバー登録をしてほしい」

お問い合わせ

 日本マイクロソフト株式会社

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
【デブサミ2018】セッションレポート連載記事一覧

もっと読む

この記事の著者

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/10716 2018/03/26 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング