NoOpsを実現できる時が来た。「NoOps」とは運用の“嬉しくない”ことをなくすこと。NoOps Meetup Tokyo #1

2018年9月18日

9月12日に都内で「NoOps Meetup Tokyo」の第一回が開催されました。

この「NoOps」は運用そのものをなくしてしまう「No Ops」ではなく、運用の嬉しくないことをなくす「No "Uncomfortable" Ops」だと、NoOps Japan発起人の岡大勝(おか ひろまさ)氏は説明します。

NoOpsの具体的な意義と、それをどのように実現するのかを説明した岡氏のセッション「15分で分かる NoOps」をダイジェストで紹介しましょう。

fig

参考:「NoOps? よろしい、ならば戦争だ」。NoOpsコミュニティに異議申し立てた「Opsの味方」。決裂か? 和解か? NoOps Meetup Tokyo #1

NoOpsの目指すもの

今日お伝えしたいことは3つです。「NoOpsの目指すもの」「なぜいまNoOpsなのか」「NoOpsのつくりかた」

fig

「NoOps」とは、「No Uncomfortable Ops」つまりシステム運用の嬉しくないことをなくそう、ということ。

fig

嬉しくないこととは、おもに3つあげられます。

1つ目はユーザーの体験を妨げないということ。例えば障害時のダウン、計画停止、負荷集中時の性能低下などはユーザーの体験を妨げます。

2つ目は運用保守の現場での「トイル」です。トイルとは、リリース手続きやパッチの適用など、人間がやるべきでないような作業、これを最小化しましょうと。

3つ目はシステム運用保守におけるリソースとコスト。これは忘れられがちですが、実は1つ目や2つ目はサーバリソースにお金をかけたりヒューマンリソースを豊富に投入すれば問題にならないかもしれません。でもそうではなく、リソースやコストの最適化をしましょうと。

いまならすべてが改善できる、という時が来た

こうしたことを目指したNoOpsのためにOpsを改善しようとすると、ジレンマが立ちはだかります。

利用者の体験を向上させようと24時間365日運用、負荷が集中しても安定して稼働し、可用性も高めようとすると、運用の現場の負担は増し、コストもかかる。

fig

一方、運用の現場の負担を軽減しようとして、例えば待機人員をなくすとするとサービスが落ちても対応できなくなってサービスの低下につながります。また現場の負担を軽減するための設備投資やツールの導入、アウトソースの採用などはコストがかかります。

fig

サービスのオーナーはコスト削減しようとすると、サービスの低下や運用の現場の負担増につながります。

fig

こうして「結局何をやってもあまり効果がでないね」というループになって、これまで同じようなやり方で運用の現場を何年も回してきたんじゃないかと思います。

fig

しかしいまなら、すべてが同時に改善できる、という時が来たと思っています。

(それがNoOpsへの取り組みです)

NoOpsの鍵は高い復元力

10年前あるいは20年前は、システムの「堅牢性」が信頼性でした。MTBF至上主義で、多重化や高度なエラー検知と訂正機能などを持つサーバが作られ、その高価な機器を10年保守や20年保守で大切に使っていました。

その価値観がこの10年で大転換して、十分な性能や帯域を持つシステムが安価に手に入るようになって、これらを入れ替えながら、信頼性はソフトウェアで構成しましょうという世界になりました。「Design for Failure」です。

技術の変化とともに設計思想も変化していきます。堅牢性を設計する「Design for Robustness」から、障害を前提とする設計の「Design for Failure」になったわけです。

そしていま、ここから進化して「Design for Resiliency」、回復性設計の時代に来ています。これは障害から回復して動作を続行する能力を持つシステムを設計するものです。

fig

NoOpsの鍵は、高い復元力です。

fig

別の言葉で言うと、取り回しの軽さ。

例えば、ChefでWordPress環境を構築する時間が240秒、これがコンテナでWordPress環境を構築する時間が14秒。

fig

アプリケーションのタイムアウトはだいたい30秒くらいですから、アプリケーションが壊れても30秒以内に検知して再構築してReadyになるのなら、ユーザーから見れば壊れていない、サービスが続いている、ということが実現できます。

コンテナやOSをできるだけ小さくしようというのは、こういうところを目指しているのです。

「壊れない」システムから、「いつでも回復できる」システムへの価値観の転換です。

fig

いままで、復元力は低いけれど高い可用性が欲しい場合、冗長構成が必要でした。

しかしいまは高い復元力が手に入る。

fig

つまりひとりでも「高い可用性」が手に入るようになったのです。

fig

しかもそれだけじゃなくて、高い復元力を持つことで、障害発生時の自己回復だったり、オンザフライでのインスタンス変更、秒単位のスケールアウトやスケールインなどができる。

fig

NoOpsの作り方

NoOpsの実現には「復元力」(Resiliencability)だけでなく、障害が起きたときにそれをいかに早く検知する観察力「Observability」も必要です。ログを見て検知するのでは遅い。

そして障害を検知したら、システムを再構成する能力「Cofigurability」も必要です。

例えば、クラウドのあるリージョンが死にましたと。それを検知してオンタイムで別のリージョンで同じシステムを構成して復元します、ということも現在では可能です。データさえ同期させておけば、検知して、構成して、復元できるのです。

fig

こうしたことを実現する上でいちばん大事なのは、仕様には書かれていないこの観察力、構成力、復元力を兼ね備えたシステムやサービスを採用することで、これには目利きが必要です。

fig

ミドルウェアやインフラが回復力を持っていても、例えばバッチ処理を回しているときに落ちました、というときにはインフラだけ復元させてもだめで、バッチ処理のどこで落ちたか、どこから再実行するかといった人の手が処理の回復に必要です。

だからアプリケーション側にも回復力を持たせる必要があります。

fig

そのための原則として、粒度はできるだけ小さく。例えば1時間もかかる処理は復元が難しくなります。

処理はステートレスで。ステートを持たせても消えてしまいます。

非同期処理。同期処理だとすべてのプロセスが連鎖していくので、途中で落ちたら最初からやり直しです。

いちばん大事なのが処理の冪等性を担保すること。どのサーバで何回リトライしても、正常終了したら結果は同じ場所に同じ値が書き込まれる。この冪等性をすべての処理で担保する。

さらに追跡可能性という意味で処理結果を記録します。

fig

目指すところは、シンプルなリトライです。落ちました、そしたらリトライする。それでだめなら別サーバでリトライする、それでもだめなら別リージョンでリトライする。それで大丈夫な設計にしていきたい。

NoOpsを実現するチームとは

最後に、NoOpsを実現するチームについて。

運用のアプローチ、設計のアプローチが合わさって、いまちょうどDesign for ResiliencyとSREが出会って、NoOpsが実現できるタイミングになりました。

fig

それを次のようなライフサイクルで回していきたい。

まず、回復性はあとから手に入るものではなくて、最初から設計しておかなくてはいけません。ですのでアーキテクトはシステム設計では最初から回復性設計をします。

そこから最初は手動運用も入れつつ、SREチームは運用保守エンジニアリングで自動化をして、自律運用を実現していきます。

その中で、プロダクトはDevOpsで日々リリースされて進化しますので、機能の追加や変更、アーキテクチャの変更などがあります。すると運用に手動の部分が増えてくる。それをまた運用保守エンジニアリングで自律運用へ近づけていく。

こういうサイクルを目指していきたいなと。

fig

NoOpsは待っていても来てくれません。

システム運用の嬉しくないことをなくして、ユーザーも運用現場の人も開発者もオーナーも、みんな「このシステムいいよね、もっとやっていきたいよね」ということを実現するために、NoOpsのコミュニティを始めました。ぜひみんなで、これからも情報交換などしていきたいと思います。

fig

下記が公開されているスライドです。

15分で分かる NoOps from Hiromasa Oka

NoOps Meetup Tokyo #1

あわせて読みたい

DevOps 運用・監視 NoOps




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本