トップ > Monitoring

マイクロサービスにおける性能異常の迅速な診断に向いた時系列データの次元削減手法

SRE Monitoring
著者 坪内 佑樹(*1), 鶴田 博文(*1), 古川 雅大(*2)
所属 (*1) さくらインターネット株式会社 さくらインターネット研究所、(*2) 株式会社はてな
研究会 第7回Webシステムアーキテクチャ研究会

2010年代のクラウド技術であるコンテナオーケストレーション、サーバーレス、マイクロサービス、さらにはエッジコンピューティングなどの普及により、分散システムとしての複雑度が高まっている。このまま複雑度が高まっていくと、人手によるルールベースの運用にいずれは限界が訪れるのではないかと考えている。そこで、最近は、このようなクラウドを中心とするSRE分野の課題に対して、機械学習やその他の数理的アプローチを適用するアプローチを模索している。特に、SREの中でも、システムに発生する異常への対応については、現場のエンジニアの経験に基づき直感に大きく依存している。

異常への対応を構成する要素を分解すると次のようになる。

https://speakerdeck.com/yuukit/slo-based-causality-discovery-in-distributed-applications?slide=12

この中でも、異常箇所の特定については、特に現場の経験に依存することが多かろうと考え、自動で異常箇所を探索する技術を研究している。その研究の第1歩が以下に述べる、性能異常を検知したときに迅速に原因を診断するためのシステムの一部品となる時系列データの次元削減手法TSifterである。異常の発生に対して、その異常を表現するための刹那的なシステムの特徴を反応的に抽出することが目的となる。次の図が最終的に実現したいシステムの全体像となる。

この次元削減手法に関するWSA研での口頭発表内容を次のスライドに公開する。

1. はじめに

ソフトウェア開発者が多数の機能を日々追加することにより、アプリケーションのコード規模が増大するため、変更を加えるときに問題があった場合の影響がアプリケーション全体に及ぶようになる。変更の影響範囲を小さくするために、昨今のクラウド上に展開されるWebアプリケーションのアーキテクチャはマイクロサービスアーキテクチャへと変遷している。マイクロサービスは、巨大な一枚岩のアプリケーションを複数の異なる小さなサービスに分解し、疎結合な状態にした上で、分解された各サービスが協調して動作するアーキテクチャをとる。

Webサービスの高信頼化のためには、サービスの性能に異常が発生したときに、異常の根本原因を迅速に特定しなければならない。しかし、そのためには次の3点の問題を解決する必要がある。

  • 依存関係の複雑化: マイクロサービスは、分散された構成要素を多数のサーバホスト上に展開するため、構成要素間のネットワーク通信関係は従来の構成よりも複雑となる。システムに異常が発生したときに、構成要素間の異常が伝搬するため、異常の伝搬経路も複雑化する。マイクロサービスにおけるサービス数は数百から数千にまで増大しているケースもあるため、それらのサービスの性質や関係性をシステム管理者が記憶することも難しい。
  • ソフトウェアの動的な変更: マイクロサービスでは、個々のサービスが頻繁に更新されることから、異常の発生確率と負荷傾向の変化頻度を増大させる。
  • メトリック数の増大: 構成要素数の増大により、システムの性能やリソース消費量を定量的に示すためのメトリックの個数が増大する。

これらの要因により、システム管理者にとってシステムを認知するための負荷が増大するため、異常の原因を診断するために時間を要するようになる。したがって、システム管理者が異常の原因を迅速に特定できる手法が必要となる。

先行手法では、まず、メトリック以外のデータソースである、各構成要素が出力するテキストログを用いたログベースのアプローチ1と、各構成要素間の呼び出し関係や応答速度を追跡する実行経路トレースベースのアプローチ2,3がある。しかし、すべての異常の動作が記録されるわけではなく、計測のためにアプリケーションのソースコードを修正する手間があることから、情報の網羅性と適用性に課題がある。次に、複数の構成要素を横断したメトリック間の因果関係を検定することにより、システム内の異常の伝播経路を自動で推論するメトリックベースのアプローチ4-9がある。しかし、このアプローチは、診断に利用するメトリックをシステム管理者が一つあるいは複数個に指定しなければならないため、より原因に近いメトリックが探索結果から除外される可能性がある。そのため、診断に有用な情報を迅速に得るためには、できる限り多くの関連するメトリックを高速に解析する必要がある。

本研究では、マイクロサービスにおいて、異常の伝播経路を自動で推論するための基盤を提供することを目的に、異常発生時に観測されたすべてのメトリックから診断に有用なメトリックを高速に抽出可能な次元削減手法であるTSifterを提案する。TSifterは、まず、各メトリックに対して、時系列データの定常性を検定し、定常性を有するメトリックを事前に除去することにより、異常発生前後で傾向が変化したメトリックを抽出する。次に、時系列グラフとして類似の形状をとるメトリックをクラスタリングしたのちに、各クラスタから代表メトリックを選出することにより、メトリックを集約する。

異常発生前後で傾向が変化したメトリックは、そうでないものと比較し、原因を示すメトリックである可能性が高いため、原因の診断に有用となる。さらに、クラスタリング処理はメトリック数が増加するにつれて、計算量が増加するため、メトリックの事前除去により、クラスタリング処理を高速化できる。また、事前除去とクラスタリングの2つの異なる次元削減法を適用することにより、単一の次元削減法と比較して、より高い次元削減性能を得られる。

TSifterを評価するために、Kubernetesクラスタ上に構築したマイクロサービスのテストベッド環境に故障を注入する実験を行った。実験の結果、TSifterは、ベースライン手法に対して、原因であるメトリック（原因メトリック）が除外されていないことを示す正確性、次元削減性能、およびメトリック数とCPUコア数に対するそれぞれの実行時間のスケーラビリティに対して、それぞれ同等程度の性能を有しながらも、270倍以上高速に動作することを確認した。

2. 関連研究

性能異常が発生したときの原因診断手法として、メトリック以外のデータソースを利用するアプローチとメトリックを自動解析するアプローチがこれまでに提案されている。

メトリックベースの自動解析アプローチは、複数の構成要素を横断したメトリック間の因果関係を検定することにより、システム内の異常の伝播経路を自動で推論する。このアプローチは、メトリックをノードとして因果関係グラフを構築した上で、システム内の最前段の構成要素を起点に因果の伝播経路を探索する。Qiuらの研究5とMicroscope8は、事前に選択した単一または複数の種類のメトリックとサービス間の呼び出し関係や複数のシステム階層の従属関係を示すシステムトポロジ情報を事前情報として利用する。AutoMAP4、MS-Rank6およびCloudRanger7は、システムトポロジー情報を必要とせず、複数種類のメトリック情報のみを用いて、因果関係グラフを構築する。これらのアプローチは、メトリックの収集のためにアプリケーションコードに修正を加える必要がないため、システムへの適用性が高い。しかし、いずれの手法もシステム管理者が単一または複数の種類のメトリックを事前に選択しておく必要がある。

Sieve10は、迅速な原因診断を目的としてはせず、オートスケールの指標などに恒常的に利用するための代表メトリックを抽出するために、メトリックの次元削減手法を提案している。Sieveは、事前の負荷テストにより、観測されたメトリックを構成要素ごとに時系列クラスタリングにより次元削減した上で、クラスタ内の代表となるメトリックを選択する。しかし、Sieveを異常発生時の迅速な原因診断に応用する場合、事前の負荷テストで顕在化できなかった異常のケースには対応できない。

3. メトリックの次元削減手法

TSifterの概要

(図1: TSifterの概要図)

図1はTSifterの概要図である。TSifterは、異なるアルゴリズムを適用してメトリックの次元削減性能を高めるために、2段階のステップに分けて、メトリックを次元削減する。

1段階目は、原因となるメトリックを除去させない範囲で次元削減性能を高めるために、異常発生前後に収集した全てのメトリックの定常性を検定し、定常性を有するメトリックを除外する。

2段階目は、1段階目で残った非定常のメトリックに対して、データの形状の類似性に着目した距離尺度を用いてクラスタリングを適用する。その後、さらなる次元削減性能向上のために、各クラスタからそのクラスタを代表するメトリックを選定する。 TSifterは、マイクロサービスにおけるサービス単位でクラスタリングすることを想定する。

ステップ1: 個々のメトリックの定常性に着目した次元削減

異常に関連するメトリックは、異常発生後にメトリックの値が増加、減少、不安定化するなど、異常発生前後でデータの傾向が変化するはずである。 そのため、異常に関連するメトリックは、データの平均および分散が時間によらず一定、かつ自己共分散が時間差のみに依存する性質である定常性を満たさず、非定常性を示す。この洞察に基づき、TSifterでは、異常に関連しないメトリックを除去するために、定常性の検定を用いてメトリックが定常性を有するかを判別し、定常性を有するメトリックを除去する。

TSifterは、収集した全メトリックに対して、定常性の検定を行い、除外するかどうかを決定する。メトリックの定常性の検定には、広く用いられている検定手法の一つであるAugmented Dickey-Fuller（ADF）検定を採用する。ADF検定は、あるメトリックから算出したp値が有意水準を下回り帰無仮説が棄却された場合、対立仮説である「データの定常性」が採択され、メトリックは定常性を有すると判定できる。TSifterは、ADF検定により定常性を有すると判定されたメトリックを全て除去する。

ステップ2: メトリック間の形状類似性に着目した次元削減

マイクロサービスにおける各サービスで収集するメトリックの中には、メトリック同士が互いに強く相関しており、時間の推移に対して同様の傾向で変動するものが存在する。例えば、単位時間あたりのネットワーク送信バイト数とネットワーク送信パケット数は、値の単位は異なるが、時間に対して概ね同様の変動傾向を示す。このようなメトリック群は、異常の診断において冗長な情報であり、メトリック群の中からどれか一つのみを抽出すれば十分である。この洞察に基づき、TSifterではクラスタリングにより同様の変動傾向をもつメトリックを集約し、その中から代表メトリックを一つ抽出して他のメトリックを除外する。代表メトリックは、クラスタ全体の特徴をよく反映するために、クラスタ内のメトリックで、それ以外のメトリックとの距離の総和が最小になるメトリックであるmedoidを選出する。また、TSifterは、マイクロサービスにおけるサービス単位でメトリックを集約してクラスタリングを実行する。

異常の診断のための有用な情報をシステム管理者に提供するためには、同様の変動傾向をもつ冗長なメトリックをなるべく多く集約、除外することでメトリックの削減数を高める必要がある。クラスタリングにおいて、どのようなデータを類似性が高いと判断し、同一クラスタに集約するかは、データ間の非類似度を表す距離の定義に依存する。時系列データであるメトリックの変動傾向の類似性を捉えるためには、メトリックの形状に着目することが有効である。メトリックの形状の類似性を考慮した距離の定義は、メトリック値の軸方向へのスケールと時間軸方向へのシフトに対する不変性を満たす必要がある。TSifterでは、メトリック値の軸方向へのスケールに対する不変性を満たすために、メトリックを平均0、分散1に標準化する。時間軸方向へのシフトに対する不変性を満たすために、標準化したメトリック間の距離をshape-based distance（SBD）11に基づき算出する。

TSifterは、マイクロサービスの性能異常時の原因診断に活用することを想定しているため、クラスタリングの処理には高速性が要求される。メトリックをクラスタリングする際に、いくつのクラスタに分けるのが適当であるかは事前に決定されておらず、その時々のメトリックの変動傾向によって変わりうる。このようにクラスタ数が事前に決定されていない場合には、最適なクラスタ数を決定するための処理が必要がある。k-means法を始めとした非階層的クラスタリングは、最適なクラスタ数を決定するためにクラスタ数を変化させて繰り返しクラスタリングを実行し、情報量基準などに基づき最適なクラスタ数を決定する。一方、階層的クラスタリングは、1回のクラスタリング実行後に、最適なクラスタ数を決定できるため、非階層的クラスタリングに比べてクラスタ数を高速に決定できる。以上の理由から、TSifterでは階層的クラスタリングを採用する。

4. 実験と評価

本章では、実験用に構築したマイクロサービス環境にて、手動で故障を注入する実験を行った結果を用いて、TSifterの次元削減の正確性、次元削減性能、および高速性を評価する。

実験の環境と設定

(表1: テストベッドにおけるハードウェアとソフトウェア構成)

テストベッド 実験のためのテストベッド環境は表1の通りである。 本実験では、Kubernetesクラスタの自動管理サービスであるGKE（Google Kubernetes Engine）上に構築したクラスタ上に、マイクロサービスのベンチマークアプリケーションであるSock Shopを構築した。 Kubernetesクラスタは5台のWorkerノードから構成されており、5台の内4台をマイクロサービスを配置するためのサービス用途、残り1台をデータ収集と負荷生成のための管理用とした。

ベンチマークアプリケーション Sock Shopは靴下を販売する電子商取引Webサイトを模したデモアプリケーションである。Sock Shopは、front-endサービス、catalogueサービス、cartsサービス、userサービス、paymentサービス、shippingサービスの計7個のマイクロサービスから構成されている。各マイクロサービスのコンテナの複製数は1に設定した。

データ収集 Prometheusにより、各コンテナからCPU利用量やメモリ使用量、ファイルシステム使用、ディスクI/O、ネットワークI/Oなどの物理資源とミドルウェアの性能や論理資源に関するコンテナレベルのメトリックを収集した。また、各マイクロサービスから平均応答時間と時間あたりの処理リクエスト数などのサービスレベルのメトリックを収集した。Prometheusのメトリック収集のインターバルを5秒に設定した。

負荷生成 Sock Shopアプリケーションに対して、擬似的な負荷を生成するために、Locustを利用した。本物の利用者がサイトのトップページからカタログ一覧を取得し、その中から商品を選び、注文するまでの典型的なフローを模倣するようなシナリオを記述し、シナリオを読み込ませて負荷を生成した。

故障注入 Locustによる負荷を生成している間に、実際のマイクロサービスにおける性能異常を模倣するために、関連研究のMicroScopeの実験で共通して採用されている故障を注入した。特定のコンテナ内のCPU負荷が100%となる故障を注入するために、stress-ngを利用した。また、特定のコンテナと通信するネットワーク遅延が増大する故障を注入するために、tc（Traffic Control）を利用した。

ベースライン手法 TSifterを評価するためのベースライン手法として、関連研究の中で唯一メトリックの次元削減手法を提案しているSieveを選択した。Sieveは、変動の少ないメトリックを除去するために、分散値の小さいものを除去したのちに、時系列クラスタリング手法を用いて、構成要素ごとにその構成要素を特徴を最もよく表す代表メトリックを抽出している。Sieveの目的は、本研究の目的とは異なるが、本研究の目的に対して有効な手法でもある可能性を評価する。

TSifterとベースライン手法の実装 両手法ともにPythonを用いて実装した。TSifterにおいて、ADF検定における有意水準は0.05、最短距離法におけるクラスタ併合の距離の閾値は0.01を用いた。CPUのマルチコアによる高速化のために、両手法ともに、全体の実行時間への寄与度が高いタスクを、互いに依存のない小さなタスクに分割し、マルチプロセスで処理するように実装した。

評価指標 TSifterの要件に、メトリックのクラスタリング後に原因メトリックが削減されないことがある。その上で、どの程度次元削減できているかを示す次元削減性能と、高速性の要件から次元削減処理の実行時間の評価が必要となる。そのためにまず、各故障注入時のメトリックを次元削減した結果、正解となるメトリックが次元削減後に残留しているかをTSifterとベースライン手法の両者で正誤を確認する。次に、次元削減率を評価するために、各故障ケースにおけるメトリックの次元削減率をベースライン手法と比較する。最後に、高速性を評価するために、特定の故障ケースにおいて、CPUコア数の増加と、メトリック数の増大に対して、次元削減処理の実行時間の変化を確認する。実行時間の計測値として、TSifterでは5回試行した結果の平均値を採用した。ベースライン手法では、実行時間の都合により、1回試行した結果の値を採用した。

microservices-demo リポジトリに、テストベッド環境の構築と実験に利用した各種設定ファイルとソースコード、およびデータセットを公開している。

実験の結果

（表2: 各故障ケースに対する代表メトリックの正誤）

表2に示す各故障ケースに対して、1メトリックあたり360個のデータ点に対して、TSifterとベースライン手法を適用することにより、マイクロサービスごとに複数の代表メトリックを選出した。故障を注入したサービスの代表メトリックが、表2に示す各故障ケースに対する代表メトリック候補のいずれかに該当することを以って、性能異常の特徴を表すメトリックを正しく抽出できたこととする。表2より、TSifterは全てのケースに対して正しく代表メトリックを抽出した一方で、ベースライン手法はshippingサービスのCPU過負荷のケースのみ正解でないメトリックを代表として抽出した。

（表3: 故障の種類ごとのメトリックの次元削減率）

表3に、userとshippingサービスへの各故障注入ケースに対するメトリックの次元削減数と削減率を示す。/で区切られた数値は左から元のメトリック数、事前除去後のメトリック数、クラスタリング後の代表メトリック数となる。いずれの手法、いずれのケースにおいても次元削減率は90\%を超えており、削減後のメトリック数は1/10以下となった。また、TSifterとベースライン手法を比較すると、shippingサービスのCPU過負荷のケースを除いて、ベースライン手法のほうが高い次元削減率を示した。

(図2: CPUコア数に対する実行時間の変化 (左)ベースライン (右)TSifter)

ハードウェアのリソース量を増加させたときに、実行時間をどの程度短縮できるかを確認するために、TSifterとベースライン手法のそれぞれについて、CPUコア数に対する実行時間の変化を確認した。メトリックの個数を1545個、メトリックあたりのデータ点数を360個で固定した上で、利用するCPUコア数を1から4まで増加させたときの実験結果を図2に示す。図2より、TSifterとベースライン手法はそれぞれコア数に反比例して実行時間が変化していた。また、TSifterの実行時間は、いずれのコア数においてもベースライン手法の270倍以上となった。

(図3: メトリック数増に対する実行時間の変化 (左)ベースライン (右)TSifter)

メトリック数を増加させたときのTSifterの実行時間の変化を図3に示す。CPUコア数を8、データ点数を360に固定した上で、横軸のメトリック数を1,000から100,000まで増加させた。メトリック数を増加させたデータを作成するために、既存の7サービスのメトリックを複製し、サービス数を擬似的に増加させた。実験の結果、メトリック数に対して実行時間が線形に増加し、メトリック数100,000において244.87秒で処理を完了できている。また、TSifterの実行時間は、いずれのデータ点数においてもベースライン手法の315倍以上となった。

実験の考察

正確性 本実験の範囲内において、ベースライン手法は誤ったメトリックを代表として選択した一方で、TSifterは全てのケースにおいて正しく代表メトリックを選択できたことから、TSifterのほうが性能異常の特徴を表したメトリックを削減させないと言える。しかし、本実験では、故障を注入したサービスの種類や故障ケースも限定的であったため、その他の故障ケースやサービスに対してTSifterが有利であるとは言えず、現時点では同等程度の正確性であると評価する。

次元削減率 次元削減率に関する実験の結果、ベースライン手法のほうが次元削減率が高い結果とはなったが、いずれもメトリック数を1/10以下に削減できたため、TSifterとの大きな差はなく、同程度の削減性能といえる。

高速性 実行時間に関する実験の結果、TSifterはメトリックの個数と実行時間は線形に増加する一方で、CPUコア数に対して実行時間が反比例した。したがって、メトリックのデータ量が増加しても同割合の計算リソースを追加することにより、実行時間を維持できる。ベースライン手法と比較し、TSifterのほうが最低でも270倍以上高速に動作したため、TSifterのほうが高速性の要件を満たすと言える。

なぜTSifterが高速なのか TSifterと比較し、ベースライン手法はクラスタリング処理のための実行時間が長い。ベースライン手法では、クラスタ数を変化させながら繰り返しk-Shapeを実行し、最適なシルエットスコアに基づき、クラスタ数を決定している。すなわち、クラスタ数を決定するために複数回クラスタリングを実行する必要がある。一方、TSifterにおける階層的クラスタリングでは、クラスタリング実行後に距離の閾値を用いてクラスタ数を決定できるため、クラスタリングの実行回数は1回のみである。このクラスタリングの実行回数の違いが、TSifterとベースライン手法の実行時間の差の主な原因となっている。

5. まとめと今後の展望

本研究では、マイクロサービスにて性能異常が発生したときの原因をシステム管理者が迅速に診断することを目的に、大量のメトリックから診断に有用なメトリックを抽出するための次元削減手法TSifterを提案した。マイクロサービスのテストベッド環境にてTSifterを評価した結果、TSifterは、ベースライン手法に対して、正確性、次元削減率、およびメトリック数とCPUコア数に対するそれぞれの実行時間のスケーラビリティでは、同等程度の性能をもち、最低でも270倍以上の高速性をもつことがわかった。TSifterは、10万メトリックのデータに対しても1分程度の時間で実行可能であり、計算リソースの追加投入によりさらに高速化可能である。

今後は、システム管理者が利用可能なシステムを実現するために、TSifterを性能異常の原因診断システムへ組み込むことを検討する。具体的には、メトリックベースの自動解析アプローチと同様に、各構成要素において、抽出された代表メトリック同士の因果関係を判定することにより、性能異常がシステム内をどのように伝搬したかを追跡可能とするといったシステムがありえる。

その他の今後の課題は次の通りとなる。

  • マイクロサービス以外にネットワーク層のシステムなどの異なる階層のシステムへの応用。
  • より広範囲の故障ケースやシステムに対するTSifterの正確性の評価は今後の課題とする。
  • 時系列データの問い合わせ処理を含めた実行時間の評価。
  • 最短距離法におけるクラスタ併合の距離の閾値を統計的根拠をもっての決定。

参考文献

  • [1]: Lin, Q., Zhang, H., Lou, J.-G., Zhang, Y. and Chen, X., Log Clustering based Problem Identification for Online Service Systems, IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C), pp.102–111 2016. ↩
  • [2]: Kaldor, J., Mace, J., Bejda, M., Gao, E., Kuropatwa, W., O’Neill, J., Ong, K. W., Schaller, B., Shan, P., Viscomi, B. et al., Canopy: An End-to-End Performance Tracing and Analysis System, the 26th Symposium on Operating Systems Principles (SOSP), pp.34–50 2017. ↩
  • [3]: Sigelman, B. H., Barroso, L. A., Burrows, M., Stephenson, P., Plakal, M., Beaver, D., Jaspan, S. and Shanbhag, C., Dapper, a Large-Scale Distributed Systems Tracing Infrastructure, Technical report, Google 2010. ↩
  • [4]: Ma, M., Xu, J., Wang, Y., Chen, P., Zhang, Z. and Wang, P., AutoMAP: Diagnose Your Microservice-based Web Applications Automatically, The Web Conference (WWW), pp. 246–258 2020. ↩
  • [5]: Qiu, J., Du, Q., Yin, K., Zhang, S.-L. and Qian, C., A Causality Mining and Knowledge Graph Based Method of Root Cause Diagnosis for Performance Anomaly in Cloud Applications, Applied Sciences, Vol. 10, No. 6, p. 2166 2020. ↩
  • [6]: Ma, M., Lin, W., Pan, D. and Wang, P., Self-Adaptive Root Cause Diagnosis for Large-Scale Microservice Ar- chitecture, IEEE Transactions on Services Computing (TSC) 2020. ↩
  • [7]: Wang, P., Xu, J., Ma, M., Lin, W., Pan, D., Wang, Y. and Chen, P., CloudRanger: Root Cause Identifi- cation for Cloud Native Systems, IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID), pp. 492–502 2018. ↩
  • [8]: Lin, J., Chen, P. and Zheng, Z., Microscope: Pinpoint Performance Issues with Causal Graphs in Micro-Service Environments, International Conference on Service-Oriented Computing (ICSOC), pp. 3–20 2018. ↩
  • [9]: Chen, P., Qi, Y., Zheng, P. and Hou, D., CauseInfer: Automatic and Distributed Performance Diagnosis with Hierarchical Causality Graph in Large Distributed Systems, IEEE Conference on Computer Communications (INFOCOM), pp. 1887–1895 2014. ↩
  • [10]: Thalheim, J., Rodrigues, A., Akkus, I. E., Bhatotia, P., Chen, R., Viswanath, B., Jiao, L. and Fetzer, C., Sieve: Actionable Insights from Monitored Metrics in Distributed Systems, the ACM/IFIP/USENIX Middleware Conference (Middleware), pp. 14–27 2017. ↩
  • [11]: Paparrizos, J. and Gravano, L., k-Shape: Efficient and Accurate Clustering of Time Series, The ACM Special Interest Group on Management of Data (SIGMOD), pp. 1855–1870 2015. ↩

WSA研での質疑

Q1. クラスタリングの処理時間がメトリック数に対して線形になるのはなぜか？

一般にはクラスタリングの処理時間は、要素数に対して線形にはならないはずなのはそのとおり。ただし、本研究では、メトリック数を増加させるために、マイクロサービスのサービス数を増加させている。現実にも単一のマイクロサービス内のメトリックが増加するというよりは、このようなメトリックの増え方になるはず。マイクロサービス内でクラスタを構成していることから、マイクロサービス内でメトリックは増加させていないため、線形増加となる。

Q2. クラスタリングにより重要なメトリックが抜け落ちるという懸念はあるか？

懸念はあるが、この次元削減手法のユースケースでは、ワークアラウンドで十分対応できると考えている。 想定ユースケースは、マイクロサービス単位の因果関係を推定することなので、マイクロサービス内でメトリックが抜け落ちたとしても、因果関係が正しければそれでよい。また抜け落ちたメトリックをみたい場合は、監視ツールのビューに、抜け落ちたメトリックを表示させるといったワークアラウンドがありえる。

Q3. 時系列データのホワイトノイズが定常性の判定やクラスタリングに影響を与えるのではないか

Q4. クラスタリングの距離とは相関か？相関であれば，時系列データのようなノイジーなデータではほとんど相関がゼロになってしまうようなことは起きないか

SBDと呼ばれる時系列の形状の類似性をクラスタリングの距離尺度として利用している。時系列の形状を荒くみることによって、ノイズ（ギザギザ）を扱っているため、相関がゼロになるようなことは起きていない。

質疑やSlack内でのコメントをみながら、既存のデータ分析手法に対しての差異を考えると、異常検知前の過去n分（実験だと30分）のみに絞って分析することにより、刹那的な（特定の異常に特化した）システムの特徴を抽出するのがやはりこの研究の要点だなと思えてきた。その他、Invariant Analysisやkmeans++、プロセスマイニングなど知らなかった用語を教えてもらった。

TCP接続の追跡による簡略化したネットワーク依存関係グラフの可視化基盤

Architecture Monitoring Tracing

はじめに

ウェブシステムは，一般的に，分散したホスト上で動作するソフトウェアが互いにネットワーク通信することにより構成される． 相互にネットワーク通信するシステムにおいて，システム管理者があるネットワーク内のノードに変更を加えた結果，ノードと通信している他のノードに変更の影響がでることがある． ネットワーク接続数が多いまたはノードが提供するサービスの種類が多くなるほど，システム管理者が個々の通信の依存関係を記憶することは難しくなる． さらに，常時接続しておらず必要なタイミングで一時的に通信するケースでは，あるタイミングの通信状況を記録するだけでは通信の依存関係を把握できない． その結果，システムを変更するときの影響範囲がわからず，変更のたびに依存関係を調査しなければならなくなるという問題がある．

先行手法では，ネットワーク内の各ノード上で動作するiptablesのようなファイアウォールのロギング機構を利用し，TCP/UDPの通信ログをログ集計サーバに転送し，ネットワークトポロジを可視化する研究[1]がある． 次に，tcpdumpのようなパケットキャプチャにより，パケットを収集し，解析することにより，ネットワーク通信の依存関係を解析できる． さらに，sFlowやNetFlowのように，ネットワークスイッチからサンプリングした統計情報を取得するツールもある． また，アプリケーションのログを解析し，依存関係を推定する研究[2]がある． マイクロサービスの文脈において，分散トレーシングは，各サービスが特定のフォーマットのリクエスト単位でのログを出力し，ログを収集することにより，リクエスト単位でのサービス依存関係の解析と性能測定を可能とする[3]．

しかし，ファイアウォールのロギング機構とパケットキャプチャには，パケット通信レイテンシにオーバーヘッドが追加されるという課題がある． さらに，サーバ間の依存関係を知るだけであれば，どのリッスンポートに対する接続であるかを知るだけで十分なため，パケット単位や接続単位で接続情報を収集すると，TCPクライアントのエフェメラルポート単位での情報も含まれ，システム管理者が取得する情報が冗長となる． 分散トレーシングには，アプリケーションの変更が必要となる課題がある．

そこで，本研究では，TCP接続に着目し，アプリケーションに変更を加えることなく，アプリケーション性能への影響が小さい手法により，ネットワーク通信の依存関係を追跡可能なシステムを提案する． 本システムは，TCP接続情報を各サーバ上のエージェントが定期的に収集し，収集した結果を接続管理データベースに保存し，システム管理者がデータベースを参照し，TCP通信の依存関係を可視化する． まず，パケット通信やアプリケーション処理に割り込まずに，netstatのような手段でOSのTCP通信状況のスナップショットを取得する． 次に，ネットワークグラフのエッジの冗長性を削減するために，TCPポート単位ではなく，リッスンポートごとにTCP接続を集約したホストフロー単位でTCP通信情報を管理する． さらに，ネットワークグラフのノードの冗長性を削減するために，ホスト単位ではなくホストの複製グループ単位で管理する． 最後に，過去の一時的な接続情報を確認できるように，接続管理データベースには時間範囲で依存関係を問い合わせ可能である．

提案システムを実現することにより，システム管理者は，アプリケーションへの変更の必要なく，アプリケーションに影響を与えずに，ネットワーク構成要素を適切に抽象化した単位でネットワーク依存関係を把握できる．

提案手法

システム概要

図1に提案手法の外観図を示す．

図1: 提案手法の外観図

提案システムの動作フローを以下に示す．

  1. 各ホスト上のエージェントが定期的にTCP接続情報を取得する．
  2. エージェントはCMDB(接続管理データベース)のホストフロー情報を送信する．
  3. システム管理者はアナライザーを通して，CMDBに格納されたホストフロー情報を取得し，解析された結果を表示する．

これらのフローにより，システム管理者が管理するシステム全体のネットワーク接続情報をリアルタイムに収集し，集中管理できる．

ホストフロー集約

個々のTCP接続情報は，通常<送信元IPアドレス，送信先IPアドレス，送信元ポート，送信先ポート>の4つの値のタプルにより表現する． ホストフローは，送信元ポートまたは送信先ポートのいずれかをリッスンポートとして，同じ送信元IPアドレスとを送信先IPアドレスをもち，同じリッスンポートに対してアクティブオープンしている接続を集約したものを指す． ホストフローの具体例は次のようになる．

Local Address:Port   <-->   Peer Address:Port     Connections
10.0.1.9:many        -->    10.0.1.10:3306        22
10.0.1.9:many        -->    10.0.1.11:3306        14
10.0.2.10:22         <--    192.168.10.10:many    1
10.0.1.9:80          <--    10.0.2.13:many        120
10.0.1.9:80          <--    10.0.2.14:many        202

接続管理データベース

CMDBは，ノードとホストフローを格納する． ノードは，ユニークなIDをもち，IPアドレスとポートが紐付けられる． ホストフローは，ユニークなID，アクティブオープンかパッシブオープンかのフラグ，送信元ノード，送信先ノードをもつ．

アナライザー

アナライザーがCMDBに対して問い合わせるパターンは次の2つである．

  • a) ある特定のノードを指定し，指定したノードからアクティブオープンで接続するノード一覧を取得する
  • b) ある特定のノードを指定し，指定したノードがパッシブオープンで接続されるノード一覧を取得する

実装

概要

提案手法を実現するプロトタイプ実装であるmftracerをGitHubに公開している．https://github.com/yuuki/mftracer mftracerの概略図を以下に示す．

+-----------+
| mftracerd |----------+
+-----------+          | INSERT or UPDATE
                       V
+-----------+         +------------+
| mftracerd |------>  | PostgreSQL |
+-----------+         +------------+
                       ^       | SELECT
+-----------+          |       |            +----------+
| mftracerd |----------+       | <--------- | Mackerel |
+-----------+                  v            +----------+
                          +--------+  
                          | mftctl |
                          +--------+

ロールと実装の対応表を以下に示す．

ロール名 実装名
agent mftracerd
CMDB PostgreSQL
analyzer mftracer

mftracerでは，予め各ホストをMackerelに登録し，サービス・ロール[4]という単位でグルーピングを設定しておくことにより，mftctlがホスト単位ではなく，サービス・ロール単位でノードを集約し，扱うことができる．

使い方

mftracerの使い方の例を以下に示す．mftracerはmftctlコマンドにより，CMDBに接続し，引数で指定した条件に応じてネットワークグラフを表示する．

$ mftctl --level 2 --dest-ipv4 10.0.0.21
10.0.0.21
└<-- 10.0.0.22:many (connections:30)
└<-- 10.0.0.23:many (connections:30)
└<-- 10.0.0.24:many (connections:30)
    └<-- 10.0.0.30:many (connections:1)
    └<-- 10.0.0.31:many (connections:1)
└<-- 10.0.0.25:many (connections:30)
...
$ mftctl --level 2 --dest-service blog --dest-roles redis --dest-roles memcached
blog:redis
└<-- 10.0.0.22:many (connections:30)
└<-- 10.0.0.23:many (connections:30)
└<-- 10.0.0.24:many (connections:30)
    └<-- 10.0.0.30:many (connections:1)
    └<-- 10.0.0.31:many (connections:1)
└<-- 10.0.0.25:many (connections:30)
blog:memcached
└<-- 10.0.0.23:many (connections:30)
└<-- 10.0.0.25:many (connections:30)
...

　ホストフロー

プロトタイプでは，netstatとssコマンドで利用されているLinuxのNetlink APIを利用して，TCP接続情報を取得している． TCP接続を集約表示するlstfでNetlinkにより実行速度が1.6倍になった - ゆううきメモ

各接続の方式がアクティブオープンかパッシブオープンかを判定する実装は次のようにになっている．

  1. Netlink APIによりTCP接続情報を取得する
  2. LISTENステートの接続のローカルポートのみ抽出
  3. 1.と2.を突き合わせ，接続先ポートがリッスンポートであればアクティブオープン，それ以外の接続はパッシブオープンと判定する．

CMDBのスキーマ

CBDBのスキーマ定義を以下に示す．

CREATE TYPE flow_direction AS ENUM ('active', 'passive');

CREATE TABLE IF NOT EXISTS nodes (
    node_id bigserial NOT NULL PRIMARY KEY,
    ipv4    inet NOT NULL,
    port    integer NOT NULL CHECK (port >= 0)
);
CREATE UNIQUE INDEX IF NOT EXISTS nodes_ipv4_port ON nodes USING btree (ipv4, port);

CREATE TABLE IF NOT EXISTS flows (
    flow_id                 bigserial NOT NULL PRIMARY KEY,
    direction               flow_direction NOT NULL,
    source_node_id          bigint NOT NULL REFERENCES nodes (node_id) ON DELETE CASCADE,
    destination_node_id     bigint NOT NULL REFERENCES nodes (node_id) ON DELETE CASCADE,
    connections             integer NOT NULL CHECK (connections > 0),
    created                 timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated                 timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

    UNIQUE (source_node_id, destination_node_id, direction)
);
CREATE UNIQUE INDEX IF NOT EXISTS flows_source_dest_direction_idx ON flows USING btree (source_node_id, destination_node_id, direction);
CREATE INDEX IF NOT EXISTS flows_dest_source_idx ON flows USING btree (destination_node_id, source_node_id);

nodesテーブルはノード情報を表現し，とflowsテーブルはホストフロー情報を表現する．

実装の課題

  • ネットワークトポロジの循環に対する考慮
  • クラウド事業者が提供するマネージドサービスを利用している場合，IPアドレスから実体をたどることの困難
  • パターンa)の実装
  • 時間範囲を指定した依存関係の取得

むすび

システムの複雑化に伴い，システム管理者が個々のネットワーク通信の依存関係を記憶することが難しくなっている． そこで，アプリケーションを変更せずに，アプリケーションに影響を与えることなく，適切な抽象度で情報を取得可能な依存関係解析システムを提案した． 実装では，Go言語で書かれたエージェントがLinuxのNetlink APIを利用し，RDBMSにホストフロー情報を格納し，Go言語で書かれたCLIから依存関係を可視化できた．

今後の課題として，問題の整理，サーベイ，評価がある． 問題の整理では，ネットワークの依存関係といっても，OSI参照モデルにおけるレイヤごとにシステム管理者が必要とする情報は異なるため，最終的にレイヤ4のTCP通信に着目する理由を明らかにする必要がある． サーベイについては，ネットワークの依存関係解析に関する先行研究は多岐に渡るため，調査し、本研究の立ち位置を明確にする必要がある． 評価については，先行手法となるファイアウォールロギングとパケットキャプチャによるレイテンシ増大による影響を定量評価し，提案手法の優位性を示す必要がある． また，実装では，すべての接続情報を取得できるわけではないため，接続情報の取得率を確認し，実運用において，十分な精度であることを確認する必要がある． さらに将来の展望として，同じような通信をしているホストをクラスタリング推定し，システム管理者がより抽象化された情報だけをみて依存関係を把握できるようにしたい． また，コンテナ型仮想化環境での依存関係の解析への発展を考えている．

参考文献

  • [1]: John K Clawson, "Service Dependency Analysis via TCP/UDP Port Tracing", Master thesis, Brigham Young University, 2015
  • [2]: Jian-Guang LOU, Qiang FU, Yi WANG, Jiang LI, "Mining dependency in distributed systems through unstructured logs analysis", ACM SIGOPS Operating Systems Review, 2010, vol 44, no 1, pp. 91
  • [3]: @itkq, "サービスのパフォーマンス数値と依存関係を用いたサービス同士の協調スケール構想", 第1回Web System Architecture研究会, https://gist.github.com/itkq/6fcdaa31e6c50df0250f765be5577b59
  • [4]: id:masayoshi, "ミドルウェア実行環境の多様化を考慮したインフラアーキテクチャの一検討", 第2回Web System Architecture研究会,https://masayoshi.hatenablog.jp/entry/2018/05/19/001806

発表スライド

質疑応答

発表時の質疑応答では，次のような議論をしました．

まず，接続が観測されたホストでも実はトラヒックはほとんど流れていなくて接続しているだけで，実際は利用していないホストであったりすることがある。提案手法は(分散トレーシングのようなより小さなリクエスト単位で追跡する手法と比較して)真の依存をみていないのではないか？という質問がありました．議論した結果の回答としては，どちらの手法が真かそうでないかというわけではなく，要件の違いにより，要件を満たす手法がかわってくるという話であると考えています．例えば，先行手法では，直接エンドユーザーへの影響のある接続を詳細に可視化することはできるが，システム管理のための接続(LDAP，SSHなど)を見落とすことがあります．

次に，UDPには対応しないのか？という質問がありました． UDPにはおそらく対応可能で，今の所はTCPのみサポートしています． ネットワーク層以下の依存関係可視化については，数多くの先行研究があります． アプリケーション層についても，ここ数年で多くの手法が提案されています． 一方で，トランスポート層に着目した依存関係の可視化の提案は少ないように思います． そこで，UDPに対応させ，トランスポート層の依存関係を満遍なく分析できる基盤という立ち位置を確保していくといいのではないかという議論をしました．

さらに，1日1回といった頻度で依存関係情報を収集するのではなく，リアルタイムに収集できるため，異常検知などに利用できるのではないかというアイデアもいただきました． あらかじめシステム管理者があるべき依存関係を設定しておき，その設定に反した通信を検知すると異常とみなすといった手法など，新しい監視手法を提案できるかもしれません．

また，Dockerのようなコンテナ環境であればリッスンポートが再起動するたびに変化していくため，ポート単位で追跡する手法は向いていないのではないかという質問もありました． 現在の提案手法では，IPアドレスとポートの組をノードとして扱っており，IPアドレスのほうはロールのようにグルーピングして扱えるようになっています． そこで，接続先のポート集合に名前をつけて管理するような仕組みが必要になってくるのではと考えています． エンドポイントの管理の課題として，他にもVIPのように実態のIPアドレスと異なるエンドポイントを利用することもあるため，仮想的には同じエンドポイントを参照していても，実態としてはエンドポイントが変化している問題を一般化して解くような提案を考えていくのが望ましいでしょう．

その他，エージェントをインストールするだけで使える導入の容易さも重要ではないかという指摘もいただきました．

あとがき

今回のWSA研も前回前々回と同様に，参加者の各種アイデアに対して，みんなで白熱した議論を展開するという流れになりました． みんな話をしたいことが多すぎて，いつも以上に，議論時間が長くなりました． 会場をご提供いただいたレピダムさんに感謝します．9人で議論するのにちょうどよいかつきれいな会議室で快適に過ごすことができました．

WSA研の特徴として，Web技術が主体でありながらも，隣接する技術領域の議論が飛び出してくることが挙げられます． 社内であったり，いつもの勉強会であれば，なんとなく要件が似通っていて，同じようなコンテキストで話をしていることが多いでしょう． 一方で，この研究会では，技術者と研究者が交わり，議論による創発を目指しているため，例えば，メールやIoTのような、いつものWebとは異なる要件をもつシステムに対しても，Webの技術を応用し，議論することにより，共通点や差異を理解し，新たなアイデアがでてくるといった場面があります． 僕自身はWSA研を開催するたびに，モチベーションがあがるということを体感しているため，これからも継続して開催していきたいと考えています．次回は4/13(土)で京都開催の予定です．

ウェブシステムの運用自律化に向けた構想 - 第3回ウェブサイエンス研究会

Monitoring Concept Experimentable

はてなエンジニア Advent Calendar 2017の2日目です。 昨日は、id:syou6162 さんによるAWS Lambda上で鯖(Mackerel)の曖昧性問題を機械学習で解決しよう - yasuhisa's blogでした。

この記事は、人工知能学会 合同研究会2017 第3回ウェブサイエンス研究会の招待講演の内容を加筆修正したものです。 講演のテーマは、「自然現象としてのウェブ」ということでそれに合わせて、「自然のごとく複雑化したウェブシステムの運用自律化に向けて」というタイトルで講演しました。 一応、他の情報科学の分野の研究者や技術者に向けて書いているつもりですが、その意図がうまく反映されているかはわかりません。

※ 2018/01/29追記: 本文中で費用を最小にすることが目的としていますが、最近では、費用も制約条件であり、変更速度を最大にする最適化問題というほうがしっくりくるようになりました。変更速度がどんどん大きくなり、そもそも人が変更するのではなく計算機が変更しはじめるのが、Experimentable Infrastructureです。これを突き詰めていくと、人間の発想をすぐ計算機に反映できる状態になります。その結果、人間の発想そのものが何か変化するではないかということが最近の興味です。)

概要

ウェブシステムの運用とは、信頼性を制約条件として、費用を最小にする最適化問題であると考えています。 費用を最小にするには、システム管理者の手を離れ、システムが自律的に動作し続けることが理想です。 クラウドやコンテナ技術の台頭により、ウェブシステム運用技術の自動化が進んでおり、自律化について考える時期になってきたと感じています。 自律化のために、観測と実験による「Experimentable Infrastructure」という構想を練っています。 Experimentable Infrastructureでは、監視を超えた観測器の発達、実験による制御理論の安全な導入を目指しています。

1. ウェブシステムの信頼性を守る仕事

ここでのウェブシステムとは、ウェブサービスを構成する要素と要素のつながりを指しており、技術要素とは「ブラウザ」「インターネットバックボーン」「ウェブサーバ」「データベース」「データセンター内ネットワーク」などのことを指します。 特に、データセンター内のサーバ・ネットワークおよびその上で動作するウェブアプリケーションを指すことがほとんどです。 総体としてのウェブというよりは、単一組織内の技術階層としてのシステムに焦点をあてています。

ウェブシステムの最も基本的な機能として、「信頼性」があります。 信頼性を守る役割は「Site Reliability Engineer(SRE)」が担います。 SREはウェブ技術者界隈で市民権を得ている概念であり、Googleのエンジニアたちによって書かれた書籍「Site Reliability Engineering」[Bet17]に詳細が記されています。

信頼性にはいくらかの定義のしようがあります。 [Bet17]では[Oco12]の定義である「システムが求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率」を採用しています。 信頼性というとつい100%を目指したくなりますが、信頼性と費用はトレードオフなため、信頼性を最大化するということはあえてしません。

さらに、信頼性をたんに担保することが仕事なのではなく、費用を最小化することが求められます。 この記事では、費用=コンピューティングリソース費用 + 人件費用 + 機会費用 *1としています。 SREは費用をエンジニアリングにより削減できます。例えば、コンピューティングリソース費用はソフトウェアの実行効率化、人件費用と機会費用はソフトウェア自動化などにより削減できます。 以上より、SREの仕事のメンタルモデルは、「目標設定された信頼性*2 *3を解くことであると言い換えられると考えます。 特にSREでは、定型作業(トイルと呼ばれる)を自動化し、スケールさせづらい人間ではなくコンピュータをスケールさせることが重要な仕事となります。

一般の人々からみれば、ウェブシステムは、十分自律動作していると言えます。 内部的に障害が発生したとしても、人々は何もせずとも、障害から回復し普段通りサービスを利用できます。 ただし、その裏では、信頼性を担保するために、数多くの人間の手作業や判断が要求されているのが現実です。 人間がなにもしなければ、およそ1週間程度*4で信頼性は損なわれることもあります。

我々のゴールは、最終的にコンピュータのみでシステムを運用可能な状態にすることです。 IOTS2016の開催趣旨が、このゴールを端的に言い表しています。

インターネット上では多種多様なサービスが提供されている。このサービスを提供し続け、ユーザに届けることを運用と呼ぶ。サービスが複雑・多様化すれば運用コストは肥大する。このコストを運用担当者の人的犠牲により「なんとか」してしまうことが「運用でカバーする」と揶揄される。日本では大規模構造物を建造する際に、破壊されないことを祈願して人身御供 (人柱) を捧げる伝統があるが、現在のインターネットの一部はこのような運用担当者の人柱の上に成立する前時代的で野蛮な構造物と言うことができる。

運用担当者を人柱となることから救う方法の一つが運用自動化である。運用の制御構造における閾値を明らかにすることにより、人は機械にその仕事を委託することができる。機械学習や深層学習により、この閾値を明らかにすることをも機械に委託することが可能となることも期待される。不快な卑しい仕事をやる必要がなくなるのは、人間にとってひじょうな福祉かもしれないが、あるいはそうでないかもしれない。しかし機械に仕事を委託することにより空いた時間を人間が他のことに使うことができるのは事実である。

本シンポジウムは、インターネットやネットワークのサービスの運用の定量的な評価を通じて、積極的に制御構造を計算機に委託することで人間の生産性を向上させ社会全体の収穫加速に結びつけることを目的とする。

IOTS2016 開催の趣旨より引用 http://www.iot.ipsj.or.jp/iots/2016/announcement

2. ウェブシステム運用の現状

国内のウェブシステムの運用技術の変遷

2010年以前は自作サーバ時代[rx709]でした。 秋葉原でパーツを購買し、組み立てたサーバをラックに手作業で配置していました。 自作だと壊れやすいこともあり、冗長化機構やスケールアウト機構など信頼性を高める基礎機能が浸透しました。[ito08] のちにベンダー製サーバやクラウドへ移行が進みます。 このころから、XenやKVMなどのハイパーバイザ型のサーバ仮想化技術の台頭により、徐々にサーバをモノからデータとして扱う流れができはじめます。

クラウド時代

2011年にAWS東京リージョンが開設され[awshis]、有名ウェブ企業が移行しはじめます[coo15]。 クラウドの利用により、必要なときにすぐにハードウェアリソースが手に入り、従来の日または月単位のリードタイムが一気に分単位になりました。 さらに、単にハードウェアリソースが手に入るだけでなく、クラウドのAPIを用いて、サーバやデータベースをプログラムから作成することが可能になりました。 これを利用し、負荷に応じて自動でサーバを増やすなどの動的なインフラストラクチャを構築できるようになってきました。

コンテナ型仮想化技術

2013年のDocker[doc13]の登場により、ソフトウェアの動作環境を丸ごとパッケージ化し、さまざまな環境に配布できるようになりました。 コンテナ型仮想化技術そのものは古くから存在しますが、Dockerはコンテナの新しい使い方を提示しました。 コンテナ環境は、ハイパーバイザ環境と比べてより高速に起動する*5ため、より動的なインフラストラクチャの構築が可能になりました。

この頃より、Immutable Infrastructure[imm13][miz13][mir13][sta13]またはDisposable Infrastructureの概念が登場し、サーバを使い捨てるという発想がでてきました。

サーバレスアーキテクチャ

2015年ごろから、サーバレスアーキテクチャ[mar16] [nek16]という概念が登場しました。 これは本当にサーバがないわけではなく、サーバの存在を意識しなくてよいような状態へもっていくためのアーキテクチャと技術選択を指します。

サーバレスアーキテクチャでは、具体的なサーバやコンテナの存在を意識することなく、抽象化された複数のサービスを組み合わせて、ビジネスロジックを実装するようになります。 ここでのサービスは、フルマネージドサービスと呼ばれることが多く、データベースサービス(Amazon DynamoDB、Google BigQueryなど)、CDNサービス(Akamai、Amazon Cloudfrontなど)、Functionサービス(AWS Lambda、Google Function)などを指します。 理想的なフルマネージドサービスは、裏側にあるサーバの個数や性能ではなく、APIの呼び出し回数や実行時間、データ転送量といったよりアプリケーションに近い単位でスケーリングし、課金されます。 ウェブサービス事業者がこれらの抽象層を実装するというよりは、クラウドベンダーがサービスとして提供しているものを利用することがほとんどです。

Site Reliability Engineering(SRE)の登場

2015年から日本のウェブ業界にSREの概念が浸透し始めました[mer15]。 SREにより、ウェブシステムの「信頼性」を担保するエンジニアリングという、何をする技術やエンジニアなのかがはっきり定義されました。 それまでは、システム管理者、インフラエンジニアや下回りといったざっくりした用語で何をする技術で何をする人なのかが曖昧な状態であることに気付かされました。 トレードオフである信頼性を損なわずに変更の速度の最大化する*6上で、ソフトウェアエンジニアリングを特に重視しているのも特徴的です。

SRE自体は技術そのものではなく、SREによりウェブシステムの運用分野に、体系的な組織開発・組織運用の概念が持ち込まれたことが、大きな変化だと考えています。

変遷まとめ

昔はハードウェアを調達し、手作業でラッキングしていました。 現在では、サーバの仮想化技術の発達とアプリケーション動作環境パッケージングの概念、さらにサーバレスアーキテクチャの考え方とサービスの浸透により、よりダイナミックで抽象的なインフラストラクチャが構築可能になりました。 このように、インフラストラクチャがソフトウェアとして扱いやすくなり、ソフトウェアエンジニアリングを重視した組織文化の浸透と合わさり、この10年でソフトウェアによる運用自動化が大幅に進んできたと言えます。

しかし、これでめでたしめでたしかというとそういうわけではありません。

3. ウェブシステム運用の課題

本当は怖いウェブシステム運用

このテーマについては、今年のIPSJ-ONEにて「高度に発達したシステムの異常は神の怒りと見分けがつかない」[yuu17]で話しました。

ウェブシステムでは、異常が発生しても原因がわからないことがあります。 原因がわからず再現させることも難しい場合、システムの振る舞いがまるで「自然現象」に感じられます。*7 自動化が進んでいるからこそ、不明であることが異常に対する「恐怖」をうみます。 これは、システムに対する変更が安全かどうかを保証することは難しいためです。 その結果、振る舞いの解明に多くの時間をとられたり、わざと自動化を避けて、人間の判断をいれようとします。

実際、異常のパターンは様々です。 講演では、以下の2つの例を話しました。

  • ハードウェアのキャパシティにはまだ余裕があるにもかかわらず、1台あたりの処理能力が頭打ちになり、自動スケールするが自動スケールしない別のコンポーネントが詰まるケース
  • データベース*8のアクティブ・スタンバイ構成*9において、ネットワーク分断により、確率的にどちらかのマスターにデータが書き込まれ、データの一貫性を損失するケース

前者は、自動化していても自動で復旧できず、後者は自動化したがゆえに新たな問題が発生したケースです。 書籍「Infrastructure As Code」[kie17]では、1.3.5節 オートメーション恐怖症にて、"オートメーションツールがどういう結果を生むかについて自信が持てないため、オートメーションツールに任せきりになるのは怖かった。"と書かれています。

ウェブシステムの複雑性

ここまできて、なぜウェブシステムは自然現象のように感じられるか、複雑さの要因はなにかについて、体系的に整理し、分析しようと真剣に考えたことはありませんでした。 そのための最初の試みとして、自分の経験を基に以下の3点を挙げてみます。

  • ソフトウェア依存関係の複雑さ
  • 分散システムとしての複雑さ
  • 入力パターンの複雑さ

ソフトウェア依存関係の複雑さ

ウェブシステムは、多数のソフトウェアの重ね合わせにより構成されます。 言語処理系、OS、ドライバ、共有ライブラリ、ミドルウェア、アプリケーションライブラリ、アプリケーションなどです。 さらに、これらがネットワーク越しに接続され、さまざまなプロトコルにより通信します。

このような状況では、ソフトウェアの依存関係や組み合わせの問題が発生します。 具体的にはバージョンアップ問題やプロトコル互換問題、依存地獄問題[yuu15]などを指します。

例えば、あるソフトウェアをバージョンアップすると、そのソフトウェアに依存したソフトウェアが動作しなくなることがあります。 データベースのバージョンアップにより、プロトコルなどの仕様変更に追従していないアプリケーションが動作しなくなるなどは典型的な例でしょう。 動作したとしても、性能が低下し障害につながるということもあります。

分散システムとしての複雑さ

信頼性のあるウェブシステムは、基本的に分散システムとして構成されています。 複数のノードが相互に通信するということは、単純にノードやリンクが増加すればするほど、システムとしては複雑になります。 さらに、分散システムは、ハードウェア故障、ネットワークの切断・遅延といった物理的制約がある中で、信頼性を担保しなければいけません。 部分的な故障を許容しつつ、自動でリカバリする仕組みは複雑です。 分散システムの難しさについて書かれた文献として、「本当は恐ろしい分散システムの話」[kum17]が非常に詳しいです。

入力パターンとしての複雑さ

ウェブシステムの入力パターン(ワークロード)は一定でもなければ、ランダムでもないことがほとんどです。 ただし、サービスの特性により、朝はアクセスは少ないが、夜に向けてアクセスが徐々に増加するといった一定の傾向はあります。 大まかな予測はできることがあるものの、むずかしい。 人間、検索クローラ、スパマーなどの活動に応じてシステムへの入力パターンは突発的に変化します。これは、制御工学でいうところの外乱に相当します。 実際、この突発的な変化が障害の原因になることはよくあります。

入力パターンの突発的変化(外乱)は、人間や社会の変化によることもあるため、システム側での予測は困難です。

システムの複雑さの度合い

複雑さを分析するのは、要因に加えて度合いの評価も必要です。 度合いについてもせいぜいサーバ台数やサービス数程度でしかみてきませんでした。

そもそも一般的に複雑さをどう定義しているかについて、複雑性科学の書籍[mel11]を参考にしました。 [mel11]には、複雑さについての一般的な定義はなく、これまでいくつかの指標が提案されたことが書かれていました。 提案された指標は、サイズ、エントロピー、アルゴリズム情報量、論理深度、熱力学深度、計算能力、統計的な複雑性、フラクタル次元、階層度がありました。 この中で、比較的ウェブシステムに当てはめやすいのは、サイズと階層度です。

前述の分散システムとしての複雑さに対して、サイズと階層度*10の概念を適応してみます。

サイズについては、例えば、はてなのシステムサイズは以下のようなものです。GoogleやAmazonであれば、おそらくこの100~1000倍の規模でしょう。

  • サービス数: 100+ (内部向け含む)
  • ロール数: 1000+
  • ホスト数: 1000+
  • プロセス/スレッド数: 10000+
  • SRE数*11: 10人弱

階層度を特に入れ子のレベルによって定義した場合、プログラム実行単位については10年前であれば例えば以下のようになります。

  • レベル1: プロセス/スレッド
  • レベル2: サーバ (複数のプロセスの集合体)
  • レベル3: ロール (クラスタやロードバランサ配下のサーバ群)
  • レベル4: サービス: (ロールまたはマイクロサービスの集合体)
  • レベル5: プラットフォーム: (複数のサービスの集合体)
  • レベル6: ウェブ

一方、現在であれば例えば以下のようになります。 ただし、サーバレスアーキテクチャを採用していれば、レベル1~3までは無視できる一方で、マイクロサービスなど層を増やす変化もあります。

  • レベル1: プロセス/スレッド
  • レベル2: コンテナ
  • レベル3: サーバ (複数のプロセスの集合体)
  • レベル4: ロール (クラスタやロードバランサ配下のサーバ群)
  • レベル5: マイクロサービス
  • レベル6: サービス: (ロールまたはマイクロサービスの集合体)
  • レベル7: プラットフォーム: (複数のサービスの集合体)
  • レベル8: ウェブ

実際には、複雑さを評価するためには、複雑さの要因ごとに複数の指標と複数の観点をもつ必要があると考えます。 ウェブシステムがどのような複雑さをもつのか、特に他分野の方に伝えるには、SREの分野では、蓄積が不足していると感じます。

4. ウェブシステムの自律運用へのアプローチ

ここまで、ウェブシステム運用技術の変遷とウェブシステムの複雑さについて書いてきました。 ここでは、これらを踏まえ、課題を解決するためのビジョンである観測と実験による「Experimentable Infrastructure」について述べます。

観測

前述の運用技術の進歩により、インフラストラクチャが抽象化され、プログマブルかつシンプルに扱えるようになってきました。 しかし、要素数を増やす方向へ技術が進んでいるため、依然としてシステム全体の挙動を人が理解することが難しいと感じます。 したがって、系全体の精緻な理解を助ける観測器が必要です。

ここでの観測とは、ウェブシステムの「過去と現在」の状況を人間またはコンピュータが自動的かつ継続的に把握することです。 20年近く前からサーバ・ネットワークを「監視」するためのツール*12が開発されてきました。

従来や現在の監視ツールは、サーバに対する定期的なpingやメトリックの時系列グラフ化をサポートしています。 しかし、これだけでシステムの振る舞いを分析できるかというとそうではありません。 監視ツールを頼りにしつつも、SREはシステムのネットワークグラフ構造を調べ、ログを眺め、アプリケーションコードをgrepし、脳内でシステムに対してどのような変更があったかを思い出すといったことをやっています。

このように、まだまだ監視ツールだけではわからないことがあるのが現状です。 従来の監視はもちろん、ログやイベントデータの収集に加えて、構成要素と要素間の関係の把握などが求められます。*13

自分が開発に関わっているサーバ監視サービスであるMackerel[mac]については、[yuu17-2]に書いています。Mackerelには世の中のウェブシステムの観測結果が集約されているデータベースとしてとらえると解析対象としておもしろいんじゃないかと思います。

制御

システムが自律的に動作し続けるためには、システムの異常を自動で制御する必要があります。

ナイーブな制御

例えば、クラウドの台頭によりサーバの生成と廃棄がプログラマ化されたため、メトリックの変動に応じてサーバの個数や性能を自動調整できます。 さらに、なんらかの理由により不調なプロセスやサーバをすぐ捨てて、新しいものを生成することも可能です。 現在では、このあたりがウェブシステムの現場で浸透中の制御になるかと思います。 しかし、制御のためのパラメータはエンジニアの経験を元に値を設定しており、制御がうまく動くかどうかはエンジニアの技芸に頼っていると言えます。 ナイーブな自律制御のままでは、すべての課題はクリアできません。

待ち行列による制御

よくあるアイデアの一つに、待ち行列理論の利用があります。情報ネットワークの分野では、よく利用されている理論です。 ウェブシステム全体と、サブシステムをそれぞれ入れ子構造の待ち行列としてモデル化できます。 待ち行列解析により、到着分布と処理分布を観測しつづけることで、必要なコンピューティングリソースを割り出し、自動的にリソースを配分し続けられます。 例えば、最も簡単なリトルの法則を応用すると、[myu16]のように中期的なキャパシティプランニングに利用できます。

しかし、待ち行列理論の課題は、仮定する分布の範囲外の予測のできない突発的な外乱に対応しづらいことです。 到着分布は、前述したように入力の複雑さにより、予測することは難しいでしょう。 さらに、到着分布が予測可能であっても、ネットワークのパケット処理とは異なり、ウェブシステムでは、処理の重たい入力とそうでない入力の差が大きい*14ため、処理分布が予測できない可能性もあります。

外乱は事業機会となることがあるため、分布から外れた異常値だからといって無視はできないという事情があります。 そこで、最近はフィードバック制御に着目しています。*15

フィードバック制御

フィードバック制御は、大規模で複雑なシステムを、たとえシステムが外乱に影響を受けようとも、あるいは、限られた資源を有効利用しつつ、その性能を保って動作させるための手法です。 [phi14]より引用

フィードバック制御に着目した理由は、制御対象はブラックボックスであり、中身は不明でよいという点です。 これは、SREがアプリケーションの中身を知らずに観測結果だけをみて障害対応する様子に似ていると感じました。 待ち行列理論ではできないダイナミクスを扱えるのも特徴です[ohs13]。 現実のウェブシステムでは、解析的にモデルを導出するのは難しいため、パラメータの決定には「実験」による計測が必要です。

ウェブシステムに対して、フィードバック制御の導入イメージは例えば、以下のようなものです。 制御入力は、明示的に変更可能なパラメータです。例えばサーバの台数やサーバのキャッシュメモリ量などがこれに相当します。 制御出力は、制御対象パラメータです。例えば、応答時間やエラーの数などになります。 制御出力を監視し続け、目標値から外れたら制御入力を変更し、元に戻すような操作を、システムモデルに基づいて行います。 具体的には、制御入力に対して伝達関数を適用し、制御出力を得ます。 ただし、伝達関数の同定やチューニングは、実システムで応答をみる必要があります。

ただし、ここで述べているのは古典的な制御理論の話であり、単一入出力しか扱えません。 実際には、複数の入力と出力を扱ったり、階層的なシステムに対する制御をやりたくなるでしょう。 そちらは、現代制御理論やポスト現代制御理論と呼ばれる発展的な理論の範疇のようです。

制御理論をウェブシステムの運用に組み込む研究には、[jen16]などがあります。 [jen16]は、データベースクラスタ内のサーバのスケーリングについて、フィードバック制御、強化学習、パーセプトロン学習の3つの手法を比較しています。 さらに、フィードバック制御(PID制御)をApache Sparkのバックプレッシャー機構に組み込む実装もあります[spapid]。

実験

待ち行列にせよ、フィードバック制御にせよ、機械学習的なアプローチにせよ、実システムの応答結果を継続的に得ることが必要です。 おそらく、統一的なモデルなどはなく、システムやサブシステムごとに異なるモデルとなると考えています。

しかし、単純に平常時のシステムを観測し続けるだけでは、良好な制御モデルが得られない可能性があるのではないかと考えています。 というのは、システムごとのモデルとなると、過去に限界値や異常値に達したデータの数が少ないため、学習データが足りない可能性があります。 *16 特に新システムであればデータはゼロなので、本番環境の蓄積データだけでは、制御パラメータを決定できません。

ワークロードのない状態では、例えば1台あたりのサーバの限界性能というのは実際に限界まで負荷をかけないとわからないことが多いでしょう。 素朴に考えると、手動で実験してデータをとることになってしまいます。

そこで、実験の自動化を考えます。 システムには日々変更が加えられるため、継続的な実験が必要であり、手作業による実験は人手が必要で結局長続きしないためです。

分散システムの自動実験の概念としてNetflixが提唱するChaos Engineering[cha17]があります。 Chaos Engineeringは、本番環境にて故意に異常を起こす逆転の発想です。 例えば、サーバダウンなどわざと異常を起こすことで、システムが異常に耐えられるのかをテストし続けます。 Chaos Engineering自体は、先に述べたように制御モデルのパラメータ推定についての言及はありませんが、ビジョンの構想に大きく影響を受けました。*17

しかし、一般に言われていることは、本番環境で異常を起こしたり、限界まで負荷をかけるのは不安であるということです。 実際、書籍「Chaos Engineering」[cas17]では、監視の環境整備、異常時の挙動の仮説構築、実験環境での手動テスト、ロールバックなどの基盤を整えた上で十分自信をもった状態で望むようにと書かれています。 したがって、実験そのものは自動化されていても、まだまだそれに至るまでに人間による判断を多く必要とするようです。

ここで、クラウドやコンテナ技術など限りなく本番に近い環境をオンデマンドに構築する技術が発達してきていることを思い出します。 自分の考えでは、実験環境を高速に作成することで安全に実験を自動化する技術を突き詰め、効率的にデータを取得し、パラメータを決定するというアプローチを考えています。*18

これら以外に手動で実験するケースについても、実験という概念に内包し扱おうしています。 動作テスト、負荷テスト、パラメータチューニング(OSやミドルウェアのパラメータ)などです。*19

Experimentable Infrastructure

以上のような観測と実験の自動化アプローチには、近代科学の手法の自動化であるというメタファーが隠されています。

書籍「科学哲学への招待」[noe15]に近代科学の歴史とともに、仮説演繹法について紹介されています。

  • (1) 観察に基づいた問題の発見 (観測)
  • (2) 問題を解決する仮説の提起
  • (3) 仮説からのテスト命題の演繹
  • (4) テスト命題の実験的検証または反証 (実験)
  • (5) テストの結果に基づく仮説の受容、修正または放棄

仮説演繹法のループを高速に回し、自律的に変化に適応し続けるシステムを「Experimentable Infrastructure」と呼んでいます。 コンピュータに仮説の提起のような発見的な手法を実行させるのはおそらく難しいと思います。 しかし、ウェブシステムの観測と実験により判明することは、世紀の大発見ということはなく、世の中的には既知のなにかであることがほとんどなので、仮説提起をある程度パターン化できるのではないかと考えています。

5. 自律運用の壁とウェブサイエンス

仮に前述のアプローチがうまくいったとしても、さらにその先には壁があります。 自律運用の壁は、「ハードウェアリソース制約」と「予想できない外乱の大きな変化」です。

前者は、予め用意したリソースプールでさばける以上の負荷には耐えられないことです。 クラウドにも上限は存在します。

後者は、サーバの増加などには必ずディレイが存在するため、外乱の大きさによっては、フィードバックが間に合わないケースもありえます。 これについては、以下のようにウェブサイエンスの研究成果である状態予測をフィードフォワード制御に利用するといったアイデアもあるかもしれません。

自発的に発展するサービスの特徴を捉え、例えば、Web サービスが今後発展していくのか、元気をなくしていくのか、そうした状態予測を目指し、自律的な人工システムのダイナミクスを捉える普遍的な方法論をつくり、自然科学としての人工システム現象という分野の確立を目指している。

106 人 工 知 能　31 巻 1 号（2016 年 1 月）「ウェブサイエンス研究会（SIG-WebSci）」 発足

自律運用

ここまでの「自律」の定義は「自動修復」「自律運用」でした。 自律運用では、与えられた制約条件=信頼性 を満たすように自律動作することを目指しています。 信頼性を自律的に満たせれば、費用のうち人件費はある程度削減できます。 しかし、信頼性の条件設定、アーキテクチャの決定、ソフトウェアの効率化などは依然として人の仕事です。

自律開発

自律運用に対して、自律開発*20という考え方があります。 これは、この記事の文脈では例えば、自律的に費用を最小化するようなシステムを指します。

自律開発には、進化・適応の概念が必要であり、分散システムアーキテクチャの設計・改善やソフトウェア効率改善の自律化などを含みます。 おそらくソフトウェア進化の研究[oom12]などで進んでいる分野だと思います。

運用から解放されたその先

ここまではウェブシステムの運用という工学的モチベーションの話でした。

IPSJ-ONEの記事[yuu17]にて、以下のような宿題がありました。

しかし、最終的に自分のやっていることが世界にとってどういう意味があるかということを加えるとよいという話もあったのですが、ここは本番では組み込めなかった部分です。自動化されて、運用から解放されて、遊んで暮らせるようになるだけなのか？という漠然とした疑念はありました。科学の歴史をみてみると、例えば未知であった電気現象を逆に利用して、今ではコンピュータのような複雑なものを動かすことができるようになっています。そこからさらにメタなレイヤで、同じようなことが起きないかといったことを考えているのですが、これはこれからの宿題ということにします。

いまだにこの宿題に対する自分の中の答えはありませんが、ウェブサイエンス研究会発足の文章を拝読して、ぼんやりと基礎科学の貢献という道もあるのだなと思いあたりました。 人の手を介さずに動き続けるウェブシステムを探究することで、複雑な系に対する統一的な法則を発見し、基礎科学へ貢献できないかどうかといったことを考えながら、老後を過ごすのも、昔からシステムが好きな自分にとってよいのかもしれません。

ネットワークの技術階層を含む Webの存在そのものを新しい「自然現象」として捉え、例えば、その「生態系」としての構造を明らかにすることで、普遍的なダイナミクスやパターンを明らかにし、従来の自然科学・人文科学の考えを発展させることを目指している。

106 人 工 知 能　31 巻 1 号（2016 年 1 月）「ウェブサイエンス研究会（SIG-WebSci）」 発足

6. 議論

講演後にいただいた質問や議論から、SREの分野は、まだまだサイエンスというより、エンジニアの技芸の上に成り立っているなと感じました。

例えば、以下のようなデータ解析の内容をSREの分野で書かれた文献を今のところ僕は知りません。

  • ウェブシステムの複雑さの定義と解析
  • ウェブシステムの階層構造の変化の解析
  • ウェブシステムの階層ごとの到着分布、処理分布の解析
  • ウェブシステムの自律度合いの定義と解析
  • 異常のパターン分析と体系化

これは、以下の2点が要因としてあると考えています。

  • SREとデータ解析の関心やスキルセットのミスマッチ
  • データ収集が困難
    • 数年前までは、自社システムを自社内で観測してデータを溜め込んでいるだけであったため、多数のウェブシステムの情報をまとめて解析することができなかった

後者については、Mackerelを持っていることは強みなので、うまく活用していきたいと思います。 このようなデータ解析の観点でみると、観測には前述した項目よりもっと先があることを想起させられます。

7. まとめ

ウェブシステムの運用は、ここ10年で自動化が進んでおり、物理的な世界からソフトウェアの世界になってきました。 ウェブシステムは複雑ではあるが、現代のところコンピュータだけで自律した系ではありません。 ウェブシステムという人工物を自然のように振る舞わせ、人間を運用から解放したいというのが最終的な目標です。

参考文献

発表スライド

あとがき

そもそも、ウェブサイエンス研究会に招待していただいたきっかけは、IPSJ-ONE 2017 高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017 - ゆううきブログ の登壇にてご一緒した鳴海先生に声をかけていただいたことです。 さすがに、場違いではとも思いました。というのも、僕が実際やっていることは、時系列データベースの開発であったり、10年前から続くウェブシステムの運用効率化などであり、技芸であって科学ではない*21からです。 しかし、はてなシステムを構想するにあたって、地に足がついてなくてもいいから、無理やり未来を考えるいい機会になると捉え、登壇を引き受けさせていただきました。 今回の研究会のテーマは、「自然現象としてのウェブ」ということで、本当に何を話したらよいかわからないテーマで相当苦戦しましたが、その結果、IPSJ-ONE登壇で考えたことの言語化を進められました。*22 途中、妄想のような話もあり、他の分野の専門家からみれば眉をひそめるような表現もあるかもしれませんが、一度考えたことを言語化しておくことでまた次のステップに進めると考えています。

普段はどうしても目の前の課題に熱中しがちで、未来のことを考えようとはなかなか思いません。 概念や思想だけではなかなかそれを取り入れようとは考えず、それを実現するソフトウェアなりハードウェアが目の前にあらわれ使える状態になってはじめて目を向けることになります。 例えば、AWSもDockerもないと仮定して、Immutable Infrastructureの考え方に触れたとしても、到達までの道筋がすぐにはみえないため、諦めて考えないようにしてしまいそうです。

発表後に、研究会の幹事である橋本先生に、技術者はどこまで先を考えているものなのか、と質問をいただきました。 少なくとも、日本のウェブの技術者界隈で、未来の技術ビジョンを設定し、それに進もうとしている様子が外からみえることはなかなかありません。 ペパボ研究所が掲げるなめらかなシステム *23が僕の知る唯一の例です。 Real Worldでは、一歩前に進むだけでも本当に様々な問題が起き、とにかく目の前のことを倒すことが求められるので、とても未来どころではなくなるというのが現状かもしれません。

未来を考えるのは、研究者の場合は当たり前に求められるという印象があります。 しかし、SREの分野では、研究者のコミュニティが他と比べて未発達なようにも思います。 近い分野である情報ネットワークに関しては、日本でも様々な研究会がありますが、僕の知る限りでは、日本では直接的にSREの分野を扱う研究会は存在しないようです。*24

そこで、ウェブシステムアーキテクチャ研究会、(#wsa研)というものを立ち上げようとしています。 第1回は京都開催にもかかわらず、全員発表型で10人以上の参加者が既に集まっています。 今回の講演の準備をするにあたって、我々の分野で未来を議論するための既存の枠組みや土台があまりないことを改めて実感しました。*25 WSA研では、未来を考えるために、現状を体系化し、そこから新規性や有用性を追求していこうと思います。

*1:発表時には機会費用を含めていませんでしたが、機会費用を大幅に増加させて前者2つを削減できるため、この記事では含めました

*2:厳密にはService Level Objective(SLO)))を制約条件として、費用を最小にする最適化問題」((信頼性と費用はトレードオフであり、信頼性を定期的に見直す必要があります。高すぎる信頼性のために想定より費用が最小化できないとなれば、例えば四半期ごとに信頼性目標を下げるといった運用が必要です

*3:[Bet17]では、「サービスのSLOを下回ることなく、変更の速度の最大化を追求する」という表現になっています。今回は、自分自身のメンタルモデルに近い、費用の最小化という表現を選択しました。

*4:これはサービスによって大きく異なります。 これまで運用してきたサービスの肌感覚では、1週間程度。運が良くて1ヶ月程度。

*5:実質OSのプロセスの起動

*6:前述の信頼性を維持し費用を最小化するという話

*7:#wakateinfraの中でも、超常現象などと呼んでいました

*8:ここではMySQLとPostgreSQLを想定

*9:ここでは、VRRPによるクラスタリングを想定

*10:書籍「システムの科学」[her99]の第8章 階層的システム

*11:実際の職種名はWebオペレーションエンジニア

*12:NagiosやZabbixなど

*13:6. 議論 にてさらなる観測の可能性について記述

*14:いわゆる地雷URLなど

*15:[yuu17-3]でも紹介した

*16:異常検知であれば平常時だけを知っておけば問題なさそうだが、その他のアプローチの場合はどうか

*17:書籍[cas17]では、奇しくもフィードバック制御の伝達関数の話が例としてでてくるが、予測モデルを構築することは困難なので、実験しましょうということが書かれているのみでした。

*18:本番環境の負荷の再現が壁になるだろうとは思います。

*19:パラメータチューニングの自動化については、おもしろい例[mir13-2]があります。

*20:おそらく一般的に使われている言葉がソフトウェア工学の世界などにあるかもしれません

*21:John Allspaw、Jesse Robbins編、角 征典訳,ウェブオペレーションーーサイト運用管理の実践テクニック,オライリージャパン より引用

*22:発表自体は、タイムコントロールに久々に大失敗して、途中スライドスキップして残念な感じになってしまいましたが、この記事で補完できればと思います。

*23:研究所なので技術者界隈とは呼ばないかもしれません

*24:海外ではUSENIXのLISAやSREconなどがあります

*25:SRE本は本当に稀有な存在

サーバ「管理」ツールとしてのMackerelの起源

Monitoring Mackerel

この記事は、SaaSのサーバ監視サービスMackerelを起源を遡り、そこから現在の姿に至った経緯をはてな社内のエンジニアに共有するためのものです。 なお、ここに書かれていることは、Mackerel開発チームの公式見解ではありません。

概要

Mackerelは、もともとは2007年ごろに開発されたはてなの社内のサーバ管理ツールであり、動的なインフラストラクチャに対応するために、現在でいうところのInfrastructure As Codeを目指したものです。 そこから2013年にSaaSのサービスとして開発され、コードベースとアーキテクチャは全く新しくなり、監視機能を備え、サーバ「監視」サービスと呼ばれるようになりました。 しかし、はてな社内では、プログラマブルなAPIを備えたサーバ「管理」サービスとして、Mackerelを中心にしたインフラストラクチャを構築しています。 Mackerelの起源は、サーバ「監視」というよりはむしろサーバ「管理」にあったということをここに書き残します。

社内Mackerelの誕生

社内Mackerelは、はてな前CTOのstanakaさんを中心に2007年ごろに開発が始まりました。 社内Mackerelのコードベースは、mackerel.ioのそれとは全く別のものであり、社内Mackerelにしかない機能もあれば、Mackerelにしかない機能もあります。 しかし、共通する思想はあり、その思想は現代のインフラストラクチャ管理にも通ずるものであると考えています。

はてなでは、2007年前後にXen Hypervisorによるサーバ仮想化技術が導入[1]され、物体としてのサーバに加えて、データとしてのサーバを管理し始め、人手による管理コストが増大しました。 具体的には、サーバの増減に合わせて、人がIPアドレス管理表を更新したり、ホスト名やIPアドレスが記載された各種設定ファイルを更新して回るとといった手間が増えたことを指します。

これらについて、全体のサーバ数が少ないかつ、個数の増減頻度が小さければ、人手による管理にもコストはかかりません。 一方で、クラウド環境のように、データとしてサーバを扱うのであれば、プログラマブルに管理するためのデータベースが必要です。 そこで、社内Mackerelが誕生しました。

このように、社内Mackerelはサーバ監視というより、プログラマブルなインフラストラクチャ管理を目指したツールでした。 実際、社内Mackerelのことをサーバ「監視」ツールではなく、サーバ「管理」ツールと呼んでいました。

社内Mackerelの特徴

構成レジストリ

社内Mackerelの主な管理単位は、「ホスト」であり、ホスト名やIPアドレスはもちろんOSの種別やCPU数、メモリ量などのソフトウェア、ハードウェア情報も含みます。 加えて、ホストは以下の属性情報を持ちます。

  • 「サービス」「ロール」
  • ホストステータス ('working', 'standby', 'maintenance', 'poweroff', 'destroyed')
  • 拠点、ラック、電源、ネットワークなど

これらはビューとして人が参照するだけでなく、REST APIにより各種ツールと連携し、インフラストラクチャ要素の情報を一元化しています。 具体的には、以下のように各種ツールのパラメータを、MackerelのAPI経由で動的取得し、ホスト名やIPアドレスの多重管理を防いでいます。

  • 1: 死活監視ツールの設定ファイルの自動生成[2]
  • 2: 内部DNSのゾーンファイルの自動生成
  • 3: デプロイツールからのデプロイ対象ホストの動的取得
  • 4: 構成管理ツール(Chef)の適用cookbookを対象ホスト名から動的解決

1について、サーバ監視のうち、死活監視についてはNagiosを利用します。同一ロールであれば、同じ監視設定を流用できることと、ホストステータスがworking以外に変更すれば監視を外すといった動的なプラットフォームに適した運用が可能になります。1 2について、ホスト単位のレコード以外に、ロール名ベースのDNSラウンドロビン用FQDNとVIP用FQDNがあり、サービスディスカバリに利用します。 3について、Capistranoでホスト名を静的に設定したところをAPIによりロール名だけ設定しておけば、対象にデプロイできます。ホストステータスをmaintenanceにしておけば、デプロイ対象から外れます。 4について、ホスト名を与えれば、ホストに紐付いたロールから適用するcookbookを自動解決できるようになります。

このようなツールは、CMDB[3]に似ていますが、資産管理機能は含みません。 どちらかといえば、書籍「Infrastructure As Code」[4] 3.4節 構成レジストリに近いものです。 構成レジストリは、インフラストラクチャ要素についての情報集積庫であり、書籍では、構成レジストリと例として、Zookeeper/Consul/etcdや、Chef Server/PuppetDB/Ansible Towerなどが挙げられています。

メトリックの時系列グラフ

社内Mackerelには、前述の構成レジストリ機能に加えて、メトリックのクローリングと、メトリックを時系列グラフ表示する機能があります。 メトリッククローリングはPrometheusなどと同様にPull型のアーキテクチャであり、クローラーがOSの基本メトリックはSNMP、MySQLなどのミドルウェアについてはミドルウェアのプロトコルでメトリックを取得し、RRDtoolに保存します。

社内Mackerelの時系列グラフ機能の実装については、過去の発表資料[5]で詳しく説明しています。

今から振り返ると、メトリックの収集、保存、可視化については、Repiarableにするために、専用のツールに任せ、ビューだけ統合したほうが良かったと考えています。 社内Mackerelの開発開始が2007年より、もう少し後であれば、Collectd[6]で収集し、Graphite[7]に保存するといった選択肢もありました。

メトリックに限らず、当時Nagiosには使いやすいAPIがなく強引な手段で統合している実装をみると、Infrastructure As Codeを志向しようには世の中が追いついていなかった様が伺えます。

SaaSとしてのMackerelへ

2013年にMackerelの開発が始まり、2014年に正式リリースされました。 SaaSとして提供するにあたって、グラフツールではないため、メトリックに着目するより、「ホスト」に着目するといった主要な思想は、社内Mackerelから引き継がれました。他にも以下の要素が引き継がれました。

  • サービス・ロールの概念
  • ホストステータスと監視のon/offとの連動
  • 統合されたホスト管理とメトリックグラフビュー

特にサービス・ロールはMackerelの中心概念であり、社内Mackerelとほとんど同じものです。 私見ですが、サービス・ロールは、人間が決定しなければいけないラベル付けだと考えています。 インフラストラクチャに紐づくラベルは多種多様ですが、大きく分類すると、自動で付与できるものと、それ以外の人が判断して付与するものがあります。 自動で付与できるものは、OS、ハードウェア、ネットワーク、インストールされたミドルウェア、クラスタ内の役割などの情報です。 一方で、どのサービスのホストなのか、どのロールなのかといったことは、人間が最初に決めて付与しなければなりません。自動で決定できるとしても、人間が与えたルールにしたがい決定することが多いと思います。2 このラベルを用いて、リポジトリのディレクトリ構成を管理していることもあります。[8]

以上のように引き継がれた機能がある一方で、ラックや仮想ホストの管理など、クラウド時代にそぐわない機能は削ぎ落とされました。 逆に、死活監視やメトリック監視、外形監視機能は統合されました。

メトリックの収集と時系列グラフについては、SaaSとして提供するために、NAT超えを意識し、Pull型ではなく、Push型のアーキテクチャになっています。 ホストにインストールされたmackerel-agentのリクエストを[9][10]に書いた時系列データベースに格納します。

このように、Mackerelは監視機能をひと通り備えているため、サーバ「監視」サービスと銘打っていますが、その起源は、サーバ「管理」サービスです。 実際、サーバ「管理」ツールとしてのMackerelをうまく活用していただいている例[11]があります。 このブログでも、AnsibleのDynamic Inventoryとの連携[12]やServerspecとの連携[13]など、サーバ「管理」ツールとしてのMackerelをいくつか紹介しています。

その他のサーバ「管理」ツール

社内Mackerelと同じサーバ管理ツールは、他にもあり、ここでは、Collins、Yabitzなどを紹介します。

Collins

Collins[14]はTumblrで開発されているインフラストラクチャ管理ツールです。

Collinsの特徴は、Assetsベースのデータモデルです。Assetsはなんでもよく、事前設定されているものはServer Node、Rack、Switch、Router、Data Centerなどです。 さらに、このAssetsオブジェクトに対して、キーバリュー形式のTagsを付与できます。Tagsはハードウェア情報などユーザが管理できないものはManaged，外部自動化プロセスから動的に設定されるものはAutomated、ユーザによって設定されるものはUnmanagedというように3種類のタイプを持ちます。

このように、Collinsは抽象的なデータ表現により各種インフラストラクチャ要素を管理しており、具体的なデータ表現をもつ社内Mackerelとは対照的です。

Yabitz

Yabitz[15]は、旧ライブドアで開発されたホスト管理アプリケーションです。READMEでは、「ユーザ(多くの場合は企業)が保有するホスト、IPアドレス、データセンタラック、サーバハードウェア、OSなどの情報を管理するためのWebアプリケーション」と説明されています。 機能一覧を見るかぎり、社内Mackerelによく似ています。

いずれのソフトウェアも、死活監視機能やメトリック可視化機能は備えておらず、構成レジストリとしての役割に専念しているという印象です。 他にも、Zabbixのホストインベントリなどがサーバ管理機能にあたると思いますが、Zabbixはあまりに機能が多いので、よく知らずに言及することを控えました。

これからのサーバ「管理」ツール

昨今のインフラストラクチャの進化は激しく、従来のサーバ・ネットワーク機器といった管理単位よりも、さらに動的な要素やそもそもサーバとしての体裁をなしていないインフラストラクチャを管理していく必要があります。

コンテナやマネージドサービスの台頭により、管理の単位はもはやサーバだけではなく、プロセス、クラスタ、Functionなどに置き換わりつつあります。 実際、[9]のアーキテクチャの管理では、Lambda FunctionやDynamoDB Tableなどがホストとして登録されています。

サーバ構築と運用コストが激減し、インフラストラクチャ要素をデータのように扱えるようになってきた結果、マイクロサービスやサーバレスアーキテクチャのような要素同士の関係がより複雑になりやすいアーキテクチャが広まってきました。このようなアーキテクチャのもとでは、1つ1つの要素を管理するというより、関係そのものを管理する必要がでてくると考えます。 ネットワークグラフをTCPコネクションを追跡して可視化する実験[16]に既に取り組んでいました。

さらに、関係性の管理というとまず可視化が思い浮かびます。しかし、人がみて判断するその先として、関係性を表現したグラフ構造をAPIで操作することにより、システムの自動化につなげられないかを考えています。例えば、自動化が難しいレイヤとしてキャパシティプランニングやコストプランニングがあります。書籍「SRE サイトリライアビリティエンジニアリング」[17]の18章「SRE におけるソフトウェアエンジニアリング」にて、サービスの依存関係とパフォーマンスメトリックなどを入力として、キャパシティプランニング計画を自動生成するソフトウェアが紹介されています。 サービスの依存関係を管理するのが普通は大変で、書籍によると執筆時点では人間が設定を書いているように読めます。しかし、関係性のグラフ構造をプログラマブルに操作できるのであれば、プランニングを自動化しやすくなると思います。

参考文献

あとがき

先日、はてなWebオペレーションチームのテックリード - Hatena Developer Blog にて、Mackerelチームとの研究会をやるという話を書きました。 モニタリング研究会では、モニタリングの過去・現在・未来をテーマに、まず過去を知ることから始めており、その一環としてMackerelの源流をまとめました。

Mackerelのサーバ監視以外の「管理」の側面と「管理」と「監視」を統合し何ができるのかという点については、まだ十分に伝えられていないと思っています。 Mackerel本について、mattnさんに書いていただいた書評(Big Sky :: 「Mackerel サーバ監視[実践]入門」を読んだ。)に

これは本書で知ったのですが、どうやら はてな社は Mackerel をホスト管理としても使っている様で、数千いるサーバのロールをうまくラベリングして運用されているとの事でした。

とあり、このような運用手法を伝えていきたいですね。

このように、人の脳やExcelでは管理しきれない未知を明らかにするという観点で、「管理」や「監視」といった概念が組み合わさって、「観測」となり、その先にどのようなインフラストラクチャをつくっていくかをこれからやっていきます。

  1. mackerel2という社内Mackerelの改良版では、タグという概念で、複数のロールをさらに集約し、同じ設定で監視できるようになっています。これは、ロールはMySQL↩

  2. 例えば、サービスごとにネットワークレンジが決まっているなど。↩

情報処理学会でウェブオペレーション技術について招待講演した話

Monitoring TSDB 日記 Architecture

情報処理学会インターネットと運用技術研究会が主催されているIOTS2016という研究会で、「サーバモニタリング向け時系列データベースの探究」というタイトルで招待講演をしてきました。

講演のきっかけ

インターネットと運用技術研究会(以下IOT研究会)というのは僕にとっては id:matsumoto_r さんが所属されている研究会です。 matsumotoryさんが、ちょうど2年前のアドベントカレンダーで書いた僕の記事に日本語だとIPSJのIOTは分野的にもインターネットの運用技術が含まれるので興味深い論文が沢山あると思う とコメントしていただいたのが最初に研究会の存在を知るきっかけだったと思います。 そのときはそんなものもあるのかと思ってちょっとプログラムを眺めた程度でした。 しかし、まさかその2年後にこうして招待していただくことになるとはもちろん思っていませんでした。 id:MIZZYさんがserverspecの論文をだされた研究会でもあります。

きっかけは、今年の6月ごろです。 やはりmatsumotoryさんに講演とは別件のとあるびっくり無茶振りを受けました。 そして、少し前にIOT研究会へいくつかの資料を提出したところ、次のIOTS2016で講演してくれという話をいただきました。 IOTSがどんなものかわかってなかったのですが、査読付きで1年で1番大きな研究会であり、matsumotoryさんがそこで招待講演できるの羨ましいとおっしゃっていたので、じゃあやります、と答えました。

講演内容

講演するにあたって、当たり前のことですが、まず伝えたいことを考えました。 IOTS2016の開催案内をみてみると、「運用でカバーする」、「運用担当者の人柱の上に成立する前時代的で野蛮な構造物」、「不快な卑しい仕事をやる必要がなくなるのは、人間にとってひじょうな福祉かもしれないが、あるいはそうでないかもしれない」といったなかなか興味深いセンテンスが散りばめられていることに気づきました。 研究者と技術者という、コンテキストが異なるものの、同じ運用技術に携わっているという前提があります。 そこで、ウェブサービスの運用の世界で実際に起きていることと生の課題を伝えようと思いました。

これを伝えるための話作りには、いくつかの案がありました。 ひとつは、そのまま「ウェブサービスの運用の世界」といったタイトルで、ウェブオペレーションを概観する話をするというもの、もうひとつは、時系列DBやコンテナ型仮想化など特定の技術の話をするというものです。

最終的には後者にしました。 ちょうど時系列DBのアーキテクチャ刷新に取り組んでいるため、成長するサービスとスケーラビリティといういかにもウェブオペレーション技術っぽい話ができます。 自分がまだ大学にいた頃から取り組んでいたことであり、時系列DBの話をすることは自分がこれまでがんばってきた技術の話をすることにもなります。 さらに、研究会なのだから、論文にできそうなテーマならなおよいはずと思って、最新の取り組みを紹介したかったというのもあります。

だいたい話すことは決まっていたものの、ストーリー化することには苦労していて、2日くらい前にインフラチームの同僚何人かに見せたら反応が芳しくなかったので、同僚の意見を取り入れて、大幅にスライドを書きかえました。 無意識に研究発表的なスライドっぽくつくってしまっていた気がします。 トップダウン視点ではなく、自分視点に置き換えていって、アーキテクチャの説明はすべて図にしました。 会社としてというよりは個人として招待されたと思っているので、結果として自分視点になってよかったと思います。

matsumotoryさんには、見事に上記の意図をすべて汲み取っていただきました。

講演の導入には、まず異なるコンテキストのすり合わせをしようと思って、開催案内を引用させていただきました。 不快な卑しい仕事というのは、書籍Site Reliability Engineeringに書かれている"toil"に相当し、Googleでさえtoilからは逃れられていないが、toilではないエンジニアリングに価値を置いていると伝えました。 toilを消すことは、最近のエンジニアのコンテキストにおいても重要であり、そのような研究活動には価値があるということを暗にお伝えしたつもりです。

発表スライド

発表スライドを以下に貼っておきます。 あとで読む資料としてはまとまりがない点についてはご容赦ください。

若いと言われるが実際若くて平成生まれとか、IOTSの開催案内を会社の全体朝会で紹介したら社員のみんなが大喜びだったとか、アルバイト時代になんか癒やしとか言われてだまされてRRDtoolのCPANモジュールつくってたとか、入社するころにはRRDtoolは若者にはふさわしくないことがわかってきたとか、いつものように調子よくしゃべってたら笑いもとれたので、話をしていて楽しかったです。 以下のスライドがハイライトです。

講演を終えて

僕のことをご存知の方は、3年前に大学院を中退したことを覚えておられるかもしれません。 単に特定の環境とあわなかっただけというだけかもしれません。しかし、自身の体験だけでなく、社会人になってからも、大学の研究室で苦しんでいる学生たちの声を何度か聞くこともありました。 このこともあって、研究活動そのものはともかくとして、大学や研究室といった環境に強いネガティブな感情を今だにもっています。

今回の件は、大学から離れ、現場のエンジニアとしてがんばってきた成果をアカデミックな場で話すよい機会でした。 幸いなことに、思った以上に「話が通じる」という感覚を得られ、うれしく思いました。 もちろん、何を言ってるのかさっぱりだと思われた方も少なくはないでしょうが。 他の発表でもAmazon RedshiftとかKibana、Graphana、Elasticsearchなど見慣れた単語がとびかっていたので、安心感があります。

一方で、大学関係のシステムの運用を対象とした話がやはり多く、それらについてそれほど興味があるわけではありませんでしたが、おもしろく聴けた発表がいくつかありました。 特に柏崎先生の発表はとにかくいきおいのあるスライドというかこれは本当に学会発表か？と思うほどでした。 @hirolovesbeer さんの異常検知の話は質問したところ、イベントネットワーク以外にもサーバのログの異常検知にも使える可能性があるとのこと。

これ使えるなーと思ったものが論文優秀賞をとられていて、エンジニアの視点でよいものがちゃんと評価されるんだなと感じました。

ウェブオペレーションやSREに関する学術研究発表があればもっとおもしろく感じるだろうなと思います。 というのは、最近のウェブエンジニア界隈を眺めていて、それは本当に有用なのか、新しいおもちゃを使わされているだけになっているんじゃないかと疑問に思うことが増えてきて、真に有用な技術ってなんだろうなと考えたりすることがあるからです。

そういった考え方、アカデミックなアプローチで技術をつくるという方向性は自分の課題意識とマッチしているのではと思うことはあります。 博士過程へのお誘いもいただいたりしたのですが、前述のネガティブなイメージを払拭するのはすぐには難しいですね。 そもそも生半可な覚悟では社会人で博士号取得なんてできるわけないので、今後、「おもしろそう」「すごいことをやっていそう」「成長できそう」といった強いポジティブなイメージに転換できるかどうかが鍵になると思っています。

帰り際に、あのゆううきブログの中の人ですよね？と話かけていただいて、大学の中の人にまでリーチしているのかとちょっとびっくりしました。 大学を去ったその後に、大学の中の人に影響を及ぼしているというのは不思議な気分ですね。

この記事は、はてなエンジニアアドベントカレンダー2016の4日目の記事です。昨日は id:wtatsuru によるセキュリティ会の取り組みでした。 明日の担当は、buildersconで発表してきたばかりの id:shiba_yu36 です。

Mackerelを支える時系列データベース技術

Graphite Mackerel Performance Kernel Monitoring Architecture Database

【追記 2018/01/06】現在Mackerelは、時系列データベースという概念をクラウドの技で再構築する - ゆううきブログの時系列データベース実装へ移行しています。

サーバモニタリングサービス Mackerel で採用している時系列データベース Graphite を用いたシステムの構築と運用事情を紹介します。Graphiteについては、プロビジョニングやアプリケーションからの使い方、Graphite自体のモニタリングなど様々なトピックがありますが、特に大規模ならではのトピックとして、Graphiteの内部アーキテクチャ、パフォーマンスチューニングおよびクラスタ構成についての知見を書きます。

続きを読む

ヘビーなGraphite運用について

Graphite Monitoring

"Monitoring Casual Talks #6"に参加して、「ヘビーなGraphite運用」についてしゃべってきた。 Graphite ここ数ヶ月ずっと運用してて、そこそこのリクエスト数さばけるようになるまでと冗長化の話をだいたいしてた。 Graphiteのパフォーマンス・チューニングで結構苦労してて、@sonots さんが発表されてた"GrowthForecast/RRDtool チューニング秘伝の書" がすごい参考になった。（Graphite(whisper) のデータ構造と RRdtool のデータ構造はよく似ている。） fadvise(2)とか知らなかった。 ぜひ試してみたい。

スライド

結構口頭で補足してた。Graphite 秘伝の書書きたい。

感想

今回の勉強会、かなり刺さる内容が揃っててよかった。 形式が30~100人くらいいて、数人の発表者がプレゼンするっていう感じじゃなくて、14人くらいで全員発表とかいう形式だったので、カジュアルに議論とかできてよかった。 あと、結構 Mackerel について言及していただいて関係者としては緊張感あった。 Nagios とか Zabbix の話は意外と少なめで Sensu とかあと、Docker のメトリクス収集とか、Auto Scale時のモニタリング方法とかの議論があって、みんなモダンなことにチャレンジにしててすごい。 また参加したい。

関係ないけど、今週 Docker 1.0 がリリースされて、Dockerそのもの + 周辺ツールが充実してきた感があるので、今回と同じような形式の Docker Casual とかあったらよさそう。

会場の提供/準備をしていただいた @takus さん、@sonotsさん ありがとうございました。