あらゆるシステムでは、いつかは障害が発生します。しかし、考え抜かれたサイト信頼性エンジニアリングと健全なDevOpsを実践すれば、障害を適切に処理し、間違いから学び、ITシステムの耐障害性を高めることができます。

時として、システムの稼働時間は何よりも重要です。これは、ビジネスのWebサイト、企業ネットワーク、エンタープライズアプリケーションのいずれにもあてはまります。実際には、稼働時間はいつでも最優先の事柄だと言えるかもしれません。ビジネスのサーバーがクラッシュすると、真夜中に電話が鳴り、翌日CTOの部屋でデータ転送のランプがすべて消えてしまった理由を説明することになるからです。

何百万もの人々が会社のWebサイトやプラットフォームに依存している場合、稼働時間の要件とシステムの信頼性はさらに差し迫ったものになります。障害が発生すると国中がパニックに陥ってしまう恐れがあるからです。あらゆる物事を行うのにオンラインのアプリケーションや組織のデータセットに頼っている場合、ほとんどの人は、長時間インターネットにアクセスできない状況に耐えられないでしょう。

Grace Hopper Celebrationの『When 99.9 Percent Isn’t Good Enough (99.9%では十分でない場合)』というセッションで、パネリスト達は「私たちはインターネットをオンラインに保つコードを記述しています」と説明しました。また、サイト信頼性エンジニア (SRE) でモデレーターであるAnne Cesa Klein氏は「私たちはマシンが人の手を借りなくても済むようにしています」と説明しました。

そのような役割をSREやDevOpsと呼ぶとしても、役割の内容は同じです。ただし、SREとDevOpsの区別についての議論と、その区別が重要なのかどうかという議論は今も続いています。SREの仕事は、ソフトウェアエンジニアの原則を、大規模システムの設計、構築、展開、監視、保守に適用することです。最近開かれたこのカンファレンスのセッション中に、経験豊富なSREは苦労して手に入れた知恵を共有しました。その内容は、サービスレベル目標の定義、監視するメトリックの特定、正常にデグレードされるシステムの設計、壊滅的な障害の後に過ちから学んだ内容などです。

 

「稼働」とはどのようなものか?

IT部門で検討すべき最初の項目は、サービスレベル目標です。どの程度のダウンタイムなら許容できるのでしょうか? サーバーの稼働時間が99.9%の場合、サービスを利用できない時間は、1日あたり1分26.4秒、あるいは1週間あたり10分ほどになります。通常のビジネスサーバーでは、これで十分でしょう。しかし、要求が厳しく、10分のダウンタイムが長すぎる場合、稼働時間が99.99%のシステムや、場合によっては99.999%のシステムを構築する必要があります。稼働時間の単位に9を1つ追加するのは、非常に困難でコストのかかる作業です。

ユーザーがいくつの9を期待しているかという点で合意を得ることは、チームにとって不可欠だとJennifer Petoff氏は言います。彼はGoogle社のサイト信頼性エンジニアリングチームのプログラムマネージャーで、『Site Reliability Engineering: How Google Runs Production Systems (サイト信頼性エンジニアリング: Googleの本番環境システムの運営方法)』の著者です。この議論は、どちらかと言えばテクノロジーではなく人のモチベーションに関するものかもしれません。開発者は新機能を何としても実稼働環境に送り出したいと考えており、そのために信頼性を軽視するかもしれません。一方、運用チームはどちらかと言えば物事を先送りするほうを好みます。「自分の感情に従うのではなく、ユーザーの視点で考えましょう」とPetoff氏は主張します。

信頼性は重要ですが、それが唯一の設計基準とは限りません。「場合によっては、コスト削減のために、なにかの信頼性を最大限に高めることはしないという決断を下す必要があります」とQuip社のエンジニアリングマネージャーであるLeslie Carr氏は言います。すべては物事のバランスです。うまくいかない場合は、最終的に3倍のコストがかかったり、3人のエンジニアを余分に雇うことになったりする可能性もあると彼女は言います。

失敗を恐れないでください。大切なのは、同じ失敗を2度と繰り返さないことです。

 

Leslie Carr

システムの信頼性を予測するのは簡単ではないとEmily Burns氏は指摘しています。彼女はNetflix社の上級ソフトウェアエンジニアで、オープンソース開発ツールSpinnakerにも携わっています。市場で予想外の成功を収めると、負荷分散やその他のベストプラクティスを使用している場合でも、需要がアプリケーションの性能を超えてしまうことがあります。ソフトウェアをどのように更新すればよいでしょうか? 「小規模な企業であれば、毎週日曜日に20分のダウンタイムを設定してシステムを更新できますが、大規模で重要なアプリケーションでは、そういうわけにはいきません」と彼女は言います。

それだけに一層、稼働時間の目標を慎重に設定しなくてはならないという点で、パネリスト達の意見は一致していました。システムを監視し、コードの変更をロールバックし、異常に対応することで、システムを長く稼働させることができます。このプロセスを、技術と人の両面からしっかりと考えてみてください。たとえば、Netflix社のSREチームでは、問題の診断と適任者への連絡を行っています。

 

正常なデグレード

障害は避けられません。それでも、慎重に設計して適切なエンジニアリングを行っていれば、ITスタッフが根本的な問題を修正する間も、システムの最重要エレメントは稼働し続けることができます。たとえば、システムの一部のコンポーネントをシャットダウンして、大部分の基本コンポーネントは稼働し続けるようにすることも可能です。

「ユーザーが気付くことなくアプリケーションをデグレードする方法を考えてみましょう」とCarr氏は言います。「たとえば、Wikipediaでは、編集機能を無効にしていました」。

Netflixでは、ストリーミングサービスはダウンせずにデグレードするように設計されています。「1つのAWSリージョン全体が停止しても、ストリーミングのトラフィックに影響はありません」とBurns氏は言います。顧客が観ている映画をストリーミングするサーバーは10分以内に移行され、顧客はそれに気付くこともありません。

このような対処が可能になるのは、SREが設計プロセスの早期から関与しており、彼らがソフトウェア開発チームに属している場合に限られるとPetoff氏は指摘します。Klein氏によれば、少なくとも、ITプロジェクトを開始する際にはSREを参加させるべきです。そうすれば、彼らは信頼性の設計目標について質問できます。「バックエンドでの時間を節約することにもなります」とKlein氏は付け加えます。

設計段階の話し合いでは、新しいものを作り出す開発者と、システムの信頼性を重視する運用スタッフの間に緊張や対立が生じることがあります。パネリスト達によれば、その対処法は、プロジェクトプランナーがエラーバジェットを組み込むことです。

「エラーバジェットがあれば、開発者は計画的にリスクを冒すことができます」とPetoff氏は言います。「彼らは新機能を取り入れて革新を楽しむことができるようになります」。つまり、プロジェクトの計画で、新しい物事を試す時間をあらかじめ確保しておくのです。

ただし、エラーバジェットを使い果たしたら、再び「プロジェクトを完了させる」ために集中する必要があります。これは、(退屈ではあっても) 安全な選択をするということです。

 

自動化、メトリック、ツールによるサポート

ソフトウェアシステムに発生している問題を追跡するために、SREは、メトリックやログファイル、断片的な情報を1つにまとめるツールに注目します。「何かが壊れたときには、修理するためにできる限り多くの情報が欲しいと思うでしょう」とCarr氏は言います。

メトリックとログファイルは、チームのロードマップにも情報を提供します。たとえば、エラーログはSREが入手できる有利な情報です。ソフトウェアの改良よりも見栄えの良い新機能を求めるバイスプレジデントを説き伏せる材料になるからです。また、顧客サポートチケットから、うまく構成されたログ収集システムがあれば問題解決に役立つ場合があるということがわかります。客観的なシステム障害数から、新機能を追加する前にバグを修正する重要性を伝えることもできます。

さらに、「社内ハックデー」のようなチームプロジェクトの開催にもつながります。「木曜日に、ログ収集システムをみんなで修正して、アイスクリームを食べましょう」とCarr氏は提案します。

可能ならいつでも「他人のツールに頼るべきです。そうすれば自分で作成しなくても済みます」と彼女はアドバイスします。パネリスト達はいくつかの例を挙げました。PagerDuty、Netflixが開発した各種のオープンソースツール、Chaos Monkeyなどです。Burns氏は、SREがカナリアテストを実施してシステムの脆弱性をテストすることを強く推奨しています。

最終的には、自己回復するサービスという理想主義的な目標に向かって進んでいくことになるでしょう。「真夜中に呼び出されるとき、そこには、今すぐ起きて問題に対応しなくてはならないという人的要素があります」とKlein氏は言います。私たちが本当に求めているのは、問題を認識し、有用なデータを収集し、自ら再起動するようなシステムだと彼女は付け加えます。

 

同じ過ちを繰り返さない

パネリストの誰もが強調していたのは、個人を非難しないやり方でレビューミーティングを行うことの重要性です。

「個人を非難しない事後検証はソフトウェアエンジニアリングの原則です」とPetoff氏は言います。このミーティングの間、チームは「うまくいったこと、いかなかったこと、幸運だった点」について議論すべきです。発生したすべての問題について、「再発を防ぐには何をすべきか?」という問いにベストな回答を導き出します。

「失敗を恐れないでください」とCarr氏は言います。「ただし、同じ過ちを繰り返さないようにします」。

自分の経験からそれが分かっているのでしょう。「私は2010年にTwitterを20分間ダウンさせました」とCarr氏は語ります。彼女は、あるルーターにちょっとした変更を行うはずでした。「コマンドの入力中、"<"のかわりに">"を使ってしまったのです」と彼女は説明しました。「問題ないように思えたので、すべてのルーターに変更を反映しようとしました」。結果として、すべてのTwitterユーザーが、システム障害を示すクジラの画像を目にすることになりました。

当時は、このような状況に対応した自動テストは実施できませんでした。「ピアレビューはありませんでした」とCarr氏は言います。「試験用の環境もありませんでした」。この事件が起こるまでは。

「個人を非難しないことは重要です」とKlein氏は強調します。「もし上司が三つまたを手にして追ってきたら、あなたは問題をもみ消して間違いを隠そうとするでしょう」。個人を非難しないカルチャーは、組織の隅々まで行き渡っている必要があると彼女は言います。

たとえば、LinkedInのあるSREがサイトをダウンさせたとき、個人を非難しない同社のカルチャーのおかげで、そのスタッフは複雑なシステムでの避けられない障害について語ることができました。「ある人物がサイトをダウンさせられる場合、他の問題が数多く関わっているに違いないということを誰もが理解しています。そのため、私に責任を負わせるのではなく、エンジニアリング部門はシステムに変更を加えて、この出来事が二度と起こらないようにしました」と、このSREは述べています。

パネリスト達は、最近発生したハワイでの「核ミサイル警告」をケーススタディとして取り上げました。この警告はテストのはずでしたが、オペレーターが本物だと思い込んだのです。オペレーターを非難するのは簡単ですが、SREの原則が適用されたかどうかは明らかではありませんとPetoff氏は指摘します。事後検証では「オペレーターが間違いを犯して警告を送信できたシステムは、どのような仕組みだったのか?」という質問をすべきだったと彼女は言います。その質問は、個人に関係しない答えが出るまで問われるべきです。

Petoff氏は、サイト信頼性エンジニアリングの新人にとって役立つと考えられる全般的なガイドラインを提案しました。ソフトウェアで解決する問題について考えてみましょうと彼女は言います。そして、以下のような質問に答えていきます。

• それは実現可能か?
• これまでより低コストで高速かつ効果的に行えるか?
• 制約がある状況でスケールアップしたときに何が起こるか? (一部のGoogleシステムには10億人ものユーザーがいます。) 許容できるコストと遅延で、あるいはその他の関連するパラメーターに基づいてスケールアップできるか?
• どのようにして耐障害性を実現できるか? すべてのシステムがダウンした場合、どれほど大変なことになるか? どれほど正常に収めることができるか?もっとうまくできることはないか?