BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース マイクロサービスによる過剰なアラートを回避するには - Qcon LondonでのSarah Wells氏の講演より

マイクロサービスによる過剰なアラートを回避するには - Qcon LondonでのSarah Wells氏の講演より

原文(投稿日:2017/04/02)へのリンク

Sarah Wells氏はQCon Londonで、“Avoiding Alerts Overload from Microservices”と題した講演を行った。その中で氏は、開発者やオペレータに向かって、マイクロサービスベースの分散システムを構築するには、監視に対する考え方を根本的に変えなければならない、と警告した。重要なのは、 サポート可能なシステムを構築すること、監視およびアラート機能の開発では主要ユーザの作業工程やビジネス機能など‘重要な部分’の監視に注力すること、アラートの向上と改善を継続的かつ積極的に行なうこと、である。

Financial TimesのプリンシパルエンジニアであるWells氏の講演は、アラートは問題の発生を伝えるだけでは十分ではない、人手による介入が必要な時にのみ発せられなければならないのだ、という指摘で始まった。マイクロサービスアーキテクチャは開発チームの作業を迅速化する反面、運用コストが必要であり、マイクロサービスベースのシステムが生成するアラートの数(と複雑さ)が膨大になる危険性をはらんでいる。

FT.comのWebサイトはマイクロサービスのバックエンドで支援されている。プログラミング言語としては主にJavaとGoを使用し、DockerとCoreOSを使ってパッケージ化され、Amazon Web Services(AWS)プラットフォームにデプロイされる。データストアにはMongoDB、elastic、neo4j、Apache Kafkaなどを使用している。システムには99の機能サービス(350のインスタンスが常時動作する)と、52の非機能サービス(218インスタンスが動作)が存在する。これら568のサービスインスタンスを毎分チェックすれば、1日あたり817,820回のチェックが行なわれることになる、とWells氏は言う。共有されている仮想マシン(VM)上で動作するコンテナには92,160回のシステムレベルのチェックが必要なので、合計すると1日に910,080回のチェックが実行される計算だ。さらに、マイクロサービスベースのアプリケーションはすべて分散システムであるため、サービスは独立して実行されている訳ではない。このため、何らかの問題が発生した時には障害のカスケードが発生し、監視やアラートはさらに複雑になる。

本質的に分散システムであるマイクロサービスベースのアプリケーションでは、監視に対する考え方を改めなくてはなりません。

マイクロサービスベースのアプリケーションを監視するという課題に対応するために、Wells氏は、“サポート可能なシステムを構築する”、“‘重要なもの’に集中する”、“アラートとそれに含まれる情報を充実させる”という、3つのアプローチを提案している。

サポート可能なシステムを構築するためには、基本的なツールとして次のものが必要だ。

  • ログの集約 – サービスのボリュームや、ネットワーク通信を介することによる潜在的な遅延のため、ログが失われたり、遅延したりする可能性がある。つまり、ログベースのアラートでは(特に時間に関して)問題が発生する可能性がある、ということだ。ログを効果的に集約するには、関連するすべてのログを見つける方法が必要である。そのためFTチームでは、トランザクションIDを使用した集約を実施している。
  • 監視 –  Nagiosなど従来のツールには、‘サービスレベル’ビューがない、デフォルト(インフラストラクチャ)チェックに修正不可能なものが含まれている、などの制限がある。マイクロサービスベースのシステムでは、サービスおよびVMのレベルでの監視が必須となる。さらに、監視結果の集約化と視覚化も必要だ。そのためFTのテクニカルチームでは、SAWS(Silvano Dossan氏が開発)とDashingという独自のフレームワークを導入すると同時に、GraphiteGrafanaによるグラフ表示を広範に使用している。

FT.com microservices alert dashboard

dashing.ioフレームワークを使用したFT.comのマイクロサービスアラートダッシュボード

多言語でサービスを開発する場合には、使用するすべての言語で、ログと監視のインテグレーションが容易に行なえることが必要だ。期待値と運用上の制約を定義した上で、各サービスのオーナが責任を持ってこの要件を満足しなければならない。例えばFTのヘルスチェックに関する標準では、すべてのサービスはHTTP上で、'http://service/__health'というヘルスチェック用エンドポイントを公開する決まりとなっている。このエンドポイントは、ヘルスチェック可能であれば200と、'"ok":true' または '"ok": false'、および任意の追加情報を含む複数のチェックを記載したJSONドキュメントを返す必要がある。

監視とアラートの最終的な目標は、クライアントより先に問題の発生を知ることだ。従って、ユーザの行為を模倣する‘擬似要求(synthetic requests)’を実行するプラクティスは不可欠である。FTエディタが新たな記事を発行できないなど、ユーザの重要な操作に関する機能が故障した場合には、これを即時に修正する、すなわち“重要なものに集中する”ことが必要だ。そのためにFTのテクニカルチームは、エラー数や応答レイテンシなど、重要なユーザ統計情報を表示するダッシュボードも用意している。ただしWells氏は、“重要なのはエンドツーエンド(のビジネス機能)”であることを強調している。

マイクロサービスアーキテクチャは開発速度を向上しますが、関連する運用コストも発生します。コストに見合うメリットがあることを確認してください。

アラートは継続的に改善される必要がある。意味をなさないアラートや、オペレータの介入を必要としないアラートがあれば、修正あるいは削除しなければならない。問題が発生したにも関わらずアラートがなかった場合は、修正の一部として追加する必要がある。各アラート内にはビジネスへの影響の概要、関連する手順書のある場所、問題を発生させたトランザクションのIDなど、キーとなる情報を含めておくことが必要だ。FTチームでは専任の‘Ops Cops’(開発チームのオンコールメンバで、定期的に交代する)が監視に関する問題を担当すると同時に、チームのSlackメッセージングシステム内にアラートを統合している。問題がいつどのように処理され、解決されているかを示すためには、事前に定義された絵文字が使用される。

講演のまとめとしてWells氏は、アラートの作成を通常の開発フローの一部として、“コード、テスト、アラート”とするべきだと提案した。アラートが機能しなくなったことを開発チームが確認するためには、アラートを評価するテストを追加する必要がある。FTのテクニカルチームではカオステストの思想を採用して、NetflixのSimian ArmyとChaos Monkeyからヒントを得て、“Chaos Snail” (Snail=カタツムリ、“サルより小さく、Bash Shellで記述されている”から)を開発した。Wells氏は、重要なシステムにおいてアラートの維持と対応を行なうには事前準備が必要であることと、不要になった情報は何もないよりも始末が悪いものであることを忠告した。可能な限り更新を自動化し、何が変化したかを共有する方法を確立することが必要だ。

Sarah Wells氏がQCon Londonでの講演“Avoiding Alerts Overload From Microservices”で使用したスライドは、Speaker Deckで入手可能である。講演の録音記録に関する公開スケジュールは、QCon LondonのWebサイトで確認することが可能だ。

 
 

この記事を評価

関連性
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

BT