執筆者プロフィール

はじめに

近年、システム障害が社会に影響を与えると、報道やSNSを通じて広く拡散され、企業の社会的信用が低下することが増えています。このような状況下では、サービス利用者や社会への影響を極力抑えることが重要であり、システム障害の早期復旧が不可欠です。

システムが障害や災害から迅速に回復する能力や特性をレジリエンシーと呼びます。この数年でクラウドやマイクロサービス化などが進展したことにより、システム構造が複雑化し、障害対応がより困難になっています。そのため、システム運用においては障害が発生することを前提とし、その影響を最小限に抑えつつ早期に復旧させる設計や考え方、すなわちシステムのレジリエンシー強化が求められています。

レジリエンシー強化には、「アーキテクチャー改善」、「体制とプロセス構築」、「人材教育」の3つの要素が重要です。仕組み（アーキテクチャー）と、それを活用する人材とプロセスが一体となってはじめて、レジリエンシーの向上が実現されると考えています。

アーキテクチャー改善では、運用プロセスの自動化と、データの収集・可視化による全体状況の俯瞰が重要です。体制とプロセス構築では、SREチームの編成、障害の原因分析と対策、障害対応の振り返りと改善点の評価サイクルの確立が求められます。人材教育では、障害対応訓練などを通じて、有事に対応できる経験・スキルを持つ人材の育成が必要です。

本コラムでは、レジリエンシー強化の3本柱の一つである「アーキテクチャー改善」に焦点を取り上げます。アーキテクチャー改善のキーとなる観点は以下4つです。

1. 可観測性を担保した監視

システムの状態やパフォーマンスをリアルタイムで把握し、分析する能力を指します。この能力の向上により、潜在的な問題を早期に発見し、迅速に対応することが可能となります。また、システムの挙動に関する深い洞察を得ることで、継続的な改善にも役立ちます。

2. 防御的実装

1か所で発生した障害が他に連鎖しないための設計をすることです。ポイントの例として、一時的な呼び出し失敗に対する「リトライ」、長時間の呼び出し失敗の場合は当該処理を切り離す「サーキットブレイカー」等があります。概念自体は従来のモノリシックアーキテクチャの時代から存在していますが、マイクロサービスアーキテクチャのような分散型システムではサービス間の連携が飛躍的に増えているため1か所の障害を連鎖的に波及させないことが重要です。

3. リリースプロセス自動化

ソフトウェアの展開や更新を自動化することで、人為的ミスを減らし、一貫性のあるデプロイメントを実現します。これにより、新機能や修正のリリース速度が向上し、問題が発生した場合の迅速なロールバックも可能になります。

4. コンテナ自動運用

アプリケーションとその依存関係を軽量なコンテナにパッケージ化し、自動的に管理する方法です。これにより、異なる環境間でのアプリケーションの一貫した動作が保証され、リソースの効率的な利用が可能になります。また、スケーリングや障害復旧などの運用タスクを自動化することで、システムの可用性と耐障害性が向上します。

今回は、これらの中でも特に注目されている「オブザーバビリティ（可観測性）」に焦点を当てて解説します。クラウドやSaaSの活用、分散アーキテクチャーの普及により、システムの複雑性が増大しています。この複雑性に対処するため、オブザーバビリティの重要性が高まっています。

オブザーバビリティとは

オブザーバビリティ（可観測性）は、一般的に「システム全体で何が起こっているのか分かるようにする」ことを指します。ここでは、従来型の監視（モニタリング）との違いに焦点を当て、オブザーバビリティの概念について解説します。

モニタリングとオブザーバビリティの目的は異なります。モニタリングは、コンポーネントやサーバ単位の死活監視やリソース監視を通じて、監視対象の状態を確認します。つまり、何かが起こったことを「検知」するための仕組みです。一方、オブザーバビリティは、何が起こっているかを「把握」することを主な目的としています。

従来のモニタリングでは、プロセスの停止やCPU使用率の上昇など、システム内部で異変が発生した際のアラート通知までが自動化され、その後、通知を受けたエンジニアが、何が起こっているのかを調査するために、各サーバから手動でログなどを取得し、人間が情報を組み合わせて判断していく必要がありました。この方法は、数台のサーバが対象であれば問題ありませんが、大規模で複雑な連携を持つシステムでは非常に時間がかかり、結果としてシステムの復旧が遅れる原因となります。

オブザーバビリティの考え方では、各種データの収集を自動化・一元管理し、関連データを紐づけることで、人間が情報を組み合わせる手間を省きます。これにより、何が起こっているのかの確認・調査に注力することが可能になり、複雑化するシステムの迅速な問題把握と解決に貢献します。

このように、システム障害発生時の対応において、オブザーバビリティはモニタリングと比較して、より素早く原因を特定できるため、早期復旧に有効であるといえます。

オブザーバビリティを高める要素として、一般的にトレース、イベント、ログ、メトリクスの4つが挙げられます。

①トレース

サービスを構成する機能を、一連の流れとして可視化することです。「どこで何が起こっているか」を特定しやすくなります。

②イベント

システム内で発生する操作やアクションを指します。「ユーザがログインした」などの事象を定義づけておくことで、障害発生時に「誰が何をした」かが分かるようになります。

③ログ

発生したイベントとタイムスタンプをセットで記録したテキスト情報です。通常、OSやミドルウェア、アプリケーション等から出力されます。

④メトリクス

システムのリソースやサービスの状況を示す数値情報です。CPU使用率やレスポンスタイムが相当します。

このような情報をまとめて可視化・表示するものがダッシュボードです。ダッシュボードには必要な情報が集約・集計されているため、情報が必要になる度に個々のシステムからの情報収集が不要になり、全員が同じ情報を確認・更新していくことで、コミュニケーションの効率化や認識齟齬の防止につながります。このため、障害対応にかかる時間を短縮でき、システム早期復旧に寄与します。

オブザーバビリティを高めるダッシュボードを構築するには

前章では、システムの早期復旧にはオブザーバビリティが重要であり、ダッシュボードの利用が有効であることを述べました。本章では、ダッシュボード構築における落とし穴とその対策について解説します。

データ項目や内容は前述のオブザーバビリティを高める要素をベースにある程度型が決まっており、ツールが自動で収集してくれるため、大きな悩みはないかもしれません。一方で、ダッシュボードでそれらのデータを可視化する際は、カスタマイズの幅が広いので、どのように集計して表示すればよいか悩まれる方も多いと思います。ダッシュボードの内容について十分な検討がされないまま導入された場合、使いづらいためにほとんど活用されないことになりかねません。

よくあるのは、「すべてのステークホルダーに配慮した結果、全要望を詰め込んでしまい、複雑で使いづらいダッシュボードになっている」というケースです。また、障害対応に関わるそれぞれのステークホルダーが求める粒度やタイミングを把握できていない場合、利用者にとって不適切な情報を表示してしまうことがあります。その場合、正しい判断ができなかったり、対応が遅れたりする原因となります。ステークホルダーごとに求める情報が異なっているにもかかわらず、そのズレをうまく調整できていないことが主な原因です。

つまり、ある人にとって適切な情報も、別の人にとっては適切ではない場合があります。何をもって適切とするのかはダッシュボードを使う人の役割によって異なります。ECサイトで障害が発生したケースを例に考えてみましょう。主なステークホルダーとして、経営層や障害発生時の意思決定者、あるいはインシデントコマンダーなどの「指示管理者」と、実際にシステム対応を行う「現場担当者」が挙げられます。

指示管理者は、ユーザ、顧客、関係者などへの報告を担います。そのため、「ECサイト全体で障害が発生しているのか、カートやログイン等一部の機能のみなのか」、「影響範囲はどこまでなのか。個別システムで完結しているのか。または、周辺システムにも影響が出ているのか」、「何が原因なのか（周辺システム起因なのか、自システム起因なのか）」、「どれくらいのユーザが影響を受けているのか」といった広範囲の情報が必要でしょう。一方、現場担当者は、「障害はどのコンポーネントやサーバで発生しているのか」、「根本原因となっている処理は何なのか」、「現状の負荷や稼働状況はどうなのか」といった問題の解決のための情報が必要です。

つまり、指示管理者は意思決定のためシステム全体の情報を浅く広く一定周期の断面を求める一方で、現場担当者はシステムの障害箇所に関する報告や対応のため、個別システムの情報を深く狭くリアルタイムで必要とするというズレが生じているのです。このズレを認識した上で情報を選定・ダッシュボードに表示しないと、指示管理者にとっては細かすぎる、現場担当者にとっては鮮度が落ちている「誤った情報」「使えない情報」になってしまいます。

このような問題が起こらないようにしつつ、ユーザにとって使いやすく障害対応にも活用できるダッシュボードを構築する際には、以下に示す4つのポイントを意識することをお奨めします。

①目的を明確にする

ダッシュボードの構築について議論し始めると、それぞれのステークホルダーから様々な要望が寄せられます。しかし、ダッシュボードの画面に表示できる情報量には限りがあります。そのため、目的を明確にしたうえで、目的を達成するために必要な情報を選定し、どういった考えに基づいてダッシュボードの画面を構成するのかを検討し、利用者間で認識を合わせることが重要です。

②UI（ユーザインターフェース）

ダッシュボードを複数のチームが利用する場合を考慮し、それぞれのユーザの作業内容や手順の違いを意識した画面設計を行いましょう。例えば、自社の障害対応プロセスと紐づける方法も有効です。また、デザイン面の工夫も重要です。極端な例ですが、とある画面ではステータスチェックの結果として「正常値を緑、異常値を赤」としているのに、別の画面では「正常値を赤、異常値を緑」としていたら、どちらの色が正常なのか一目で判断できず、現場が混乱してしまいます。デザインのガイドラインを設けることで、色合いや配置に統一感を持たせ、認識の齟齬を防止し、操作性を向上させることができます。

③データ収集

ダッシュボードに載っている情報が同一のデータソースから作成されていることが重要です。異なるデータソースに基づいてダッシュボードが構成されている場合、「重要なコンポーネントの障害がサービス影響と紐づかない」「自動復旧済にも関わらずサービス障害が継続しているように見えてしまい状況を正しく把握できない」という問題が発生する可能性があります。

④ダッシュボードの構築方法

ダッシュボードは使いながら育てていくことが好ましいです。最初から大量の要件を出して一気に作ってしまうと様々な人の立場・思惑を整理できず、前述のように目的の異なる情報が混在してしまう可能性があります。そのため、少しずつ改善していくことが望ましいです。また、平時に「これは必要だろう」と想定していた機能や項目が、いざ実際の障害対応の場面になると活用出来なかったというケースも考えられます。そのため、実際の障害対応での体験やその後の振り返りを通してダッシュボードを「育てていく」ことで、実践に則したものとなり、障害対応の早期化により貢献できるようになります。

継続的に振り返りをしながら評価・改善する取り組みは、ダッシュボードに限らず障害対応全般でレジリエンシーを高めるために重要です。こういった取り組みは冒頭で触れたレジリエンシー強化の3本柱の一つ、「体制とプロセス構築」における「運用機能の評価・改善」の具体例と言えるでしょう。

まとめ

本記事ではレジリエンシー強化の一要素であるオブザーバビリティと、オブザーバビリティ向上に有効なダッシュボードをテーマに取り上げ、障害対応に関わる方々のお悩みについて解説しました。

オブザーバビリティは近年注目されている概念であり、それに応じた製品やツールも数多く提供されています。そのため、導入は簡単に可能な時代になってきているでしょう。しかし、システムを作って終わり、ツールを入れて完成ではなく、それらが実践で利用され効果を発揮するためには、構築した仕組みを活用する体制づくりや反復的な振り返りと改善、人材教育が一体となって機能することで、初めてレジリエンシーは向上すると考えています。

NRIでは、お客様のレジリエンシー強化の取り組みを推進する「レジリエンシー強化支援サービス」をご用意しています。今回取り上げたアーキテクチャーの要素のみならず、運用・障害対応の体制構築・人材育成にご興味のある方はぜひご覧いただければ幸いです。