Read a part of “Practical Monitoring”

I was interested in the book for a long time. The O’Reilly has published a part of the book and I also read it to know the book.

Practical Monitoring

Just I read only one section. I couldn’t more monitoring stuff in this book, but I got some antipatterns.

  • Anti-Pattern #1: Tool Obsession
  • Anti-Pattern #2: Monitoring-as-a-Job
  • Anti-Pattern #3: Checkbox Monitoring
  • Anti-Pattern #4: Using Monitoring as a Crutch
  • Anti-Pattern #5: Manual Configuration

When I read the above sections, I can imagine why they are the antipatterns. Some of them have similar issues creating the autonomous team.

In short, to scale the system, we must make the system automate. And the book should have many practices of the monitoring.

Anyway, we should take care monitoring stuff as well.

Advertisements

Bugsnagを使ってみたが、良さそうだ

主にはモバイルアプリのクラッシュログなどのログ管理に関して、最近の流れを知りたいと思いいろいろ物色してみました。類似サービスとしてはCrashlyticsなんかがありますが、いろいろ使っていると機能的に柔軟性が足りなかったりして目的に沿った利用ができないことが増えてきて、他に手頃なサービスあるのかなと思ったことも要因です。

Crashlytics以外にもいくつか調べた中で、最終的に良さそうと思ったのはBugsnag

Bugsnagは以前どこかで見たか聞いたことあったのですが、そのときはCrashlyticsのように整ったGUIがある方が使い勝手が良かったのでそこまで調べてませんでした。一方、最近ではGitHubとの連携など、サービス間の連携に対して価値を置くようになりました。そのため、ここでちょっとちゃんと使おうと思って使ってみることにしました。

Bugsnagが良かったところ

多くのプラットフォームに対応したログ収集サービス

ログ収集サービスに特化していることもあり、多くの言語、プラットフォームをサポートしていました。

リファレンスが書いてあったものでRuby、Python、PHP、Laravel、WordPress、Android、Cocoa、Node.js、JavaScript、Unity、Java、EventMachine、Go、.NET。

私は今回はおもにAndroidのリファレンスを読んだだけなのですが、ログのフィルタリングやビルドの種類ごとにログに対してプレフィックスを変えるなど、よくできたSDKなように見えます。

ログを取得するときはBagsnag上で見ることもできますし、BagsnagからStreamとしてログを自分たち絵取得することもできるなど、APIの連携もちゃんと整っていました。参考になる。

Bugsnagの方々、ログ収集の知見、深そう。

豊富なAPI

ドキュメントを眺めるとわかるのですが、ログを取得するためのAPIを豊富に提供しています。

例えばCrashlyticsのようなサービスだと、ある程度まとまった情報を1つの画面で見ることができますが、求める情報だけでフィルタリングするといった細かいところまでは手が届きません。そのため一時期はWebhookを使おうと思いましたが、WebhookにはCrshlyticsへのURLが含まれているだけなど、ログを取得するにはCrashlyticsのGUIを最終的に見るしかないし画面のカスタマイズがそこまで柔軟ではないので欲しい情報だけ絞って見ることが難しい状態でした。

なので、豊富なAPIは自分たちのみたい情報でフィルタリングするWebアプリを作ればそれらが見る事できるし、便利そう。

GitHubとのissue連携

GitHubとだけではないのですが、バグトラッキングシステムとの連携もちゃんとしていました。GitHubを例にとると、Bugsnagからissueの作成はサポートされているのは当然なのですが、ちゃんと連携しているissueが閉じられたらBugsnagのエラーも解決済みにマークされるのです。また、すでにGitHubにissueとして作られている場合、そのissueをBugsnagと別途連携させることができます。連携したら、やはり閉じられると閉じられる。

こういう流れができるわけですね。

クラッシュなどの不具合、特定のログが一定数発生 => issueを作成 => issueベースで作業

連携済みならBugsnagにマークがつくので、issueとして対応されているものかすぐ判断できます。また、issue作成時になんらかの形で再現性確認を自動化できればさらにハッピーになりそう。(モバイルアプリでは難しそうですが。。。)

以下、GUIと連携の例。

一覧。

Screen Shot 2015-02-11 at 17.45.45

エラーの詳細画面です。

Screen Shot 2015-02-11 at 17.46.01

GitHub issueとの連携箇所。
GHEとの連携もすでに用意されていることろがなかなかいけてますね。

Screen Shot 2015-02-11 at 17.46.28

こんな感じで投稿されます。

Screen Shot 2015-02-11 at 18.26.26

issueとの相互連携もできます。関連付けておくと、issueをCloseした時点で、Bugsnagのエラーも解決済みのマークがつきます。

Screen Shot 2015-02-11 at 22.40.21

よくなかったところ

良かったところ以外でいうと、GUIは他の類似サービスよりも劣ってるとみられる気がします。ただ、GUIを優先したいという要求は私にはないので、そこはさほどマイナスではないです。(むしろ、ログ収集ツールとして気軽に組み込める体裁を維持しているところがすごいと思いました)

他は、Android以外使ってないのでなんとも言えないです。。。なんかすみません。

締め

Trialが14日間で、それが終われば制限化でFreeで利用することもできるようです。私自身の個人利用はFreeで大丈夫なので、今後も使っていきたい。

こういうログ収集システム、サービスの拡大につれて自社で作る状態に落ち着きそうですが、そこまでなる前の段階ではかなり良さそうなサービスに思えます。Crashlyticsなんかは、少数のアプリを監視すれば十分な状態ではほぼ満足いきますが、監視すべきアプリが増えたりしてくると物足りない。その中間がBugsnagで、そこからさらに拡大すると自社、という流れになるのかなと思ったりしました。

これで、私のAndroidアプリの開発環境は以下の形で落ち着きそう。

Circle CI + Bugsnag + Deploygate

Bugsnagだ!

NetflixのHystrixにも使われるCircuit Breaker patternを調べてみた

Testing Strategies In A Microservice Architectureを読んだを読んでいる途中に出てきた、Circuit Breakerと呼ばれる機構を調べてみました。Martin Fowler氏がこの記事で言及しているものでした。

このCircuit Breaker patternは、Release It! 本番用ソフトウェア製品の設計とデプロイのためにで描かれているような、本番環境化において発生する、複数システムが関係するからこそ発生する障害を抑えることも目的としたデザインパターンのようです。「複数システムが関係するからこそ発生する障害」とは、一部システムの負荷が高まりタイムアウトするといったことを含みます。

内容自体は、 障害検出のための共有のオブジェクト(Circuit Breacker)を用意して、監視・検出できるようにする ということらしいです。NetflixのHystrixがその実装としてこのパターンを含んでいます。ちなみに、RubyだとここなんかがOSSの実装例として上がっていました。

Circuit Breacker Pattern

Circuit Breaker patternの考え方は単純で、以下の図のようにClientとSupplierの間にCircuit Breakder Objectを配置し、そのオブジェクトが障害のモニタリングを行いエラーを制御する、というものです。以下の図では、Circuit Breadker Objectが、Supplierのエラーを複数回検出すると、以降は復帰するまで必要以上にリクエストしないように制御します。

サンプルプログラムも置いていています。それを見ると、@failure_countのインスタンス変数にエラーの回数を足していき、一定数超えるとCircuit Openな状態にする。意図的にリセットされるとそのインスタンス変数がゼロになる、という処理で単純に書けますね。

Circuitの状態遷移は以下と定義されています。以下ではClose/Openの2値からさらにHalf Openというものも加え、Openな状態からresetされた後の復帰確認の状態を作っています。

この実装には、並列プログラムのデザインパターンであるFutures and promisesが良い知見を持っているそう。

Circuit Breakersのオブジェクトを設置することは、失敗するであろうオペレーションを抑制することができるところに価値があります。例えば、HTTPリクエストが30秒タイムアウトを繰り返す間、関連するサービスはそれを待たないといけないですが、そもそもCircuit Openな状態が既知であれば失敗することがわかっている処理に30秒も待つ必要がなくなるわけです。

締め

Breacker自体が障害になることもあるので、ClientはCircuit openな状態含めて適切な処理を実施する必要があります。一方で、Microservicesのような複数システムが連携する場合、監視・検出はシステムの品質を高めるために非常に重要な役割を担います。その仕組みを共通化してライブラリとして用意しておくことは価値が高そうです。

Spring Cloud Netflixを読んだ

Springが、Netflixが公開している彼らのOSS群を説明している記事を読みました。ちょっと、記憶に止めておきたい内容を探っているのでそのメモがてら。

記事: http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html

これは、Netflixのmicroservicesを構成するツール群を説明していました。

  • Service Discovery
    • Eureka Clients
  • Circuit Breaker
    • Hystrix
  • Intelligent Routing
    • Zuul
  • Client Side Load Balancing
    • Ribbon

Service Discovery: Eureka Clients

  • Service Discoveryはmicsoservicesベースのアーキテクチャとして大事な要素

Circuit Breaker

Hystrix Clients

  • Netflixは、CircuitBreakerを実装したもの。Microservicesでは、複数のサービスコールのレイヤを持っている。

  • 低レベルのサービス障害が発生すると、障害がユーザまで伝っていくので、障害のあったサービスをフォールバックすることで障害の伝搬を抑制することが目的

  • ↑の状態になるサービスは、例えば /health の応答として “CIRCUIT_OPEN”というstatusを返す

Dashboard

  • circuitがOpenかCloseかを知ったり、応答速度を監視するためのダッシュボードですね

Turbin

  • すべての /hystrix.stream エンドポイントを、Dashboardの /turbin.streadm エンドポイントに統合するアプリケーション。アプリのインスタンスはEurekaにある。

Declarative REST Client

Feign

  • Feignは、Web serviceクライアント

この記事では、Spring frameworkとして使える方法も紹介してました。

Client Side Load Balancer

Ribbon

  • クライアント側でのロードバランサ。HTTP、TCPベース。
  • Feignは常にRibbonを使うようになっている。

External Configuration

Archaius

  • クライアント側の設定ライブラリ
  • NetflixのすべてのOSSコンポーネントの設定で使われているらしい

Router and Filter

Zuul

  • microservice architectureにおけるサービスのルーティングを行う
  • JVMベースの、ルーティング + サーバ側ロードバランサを備えたライブラリ
  • 以下の機能を提供する
    • Authentication
    • Insights
    • Stress Testing
    • Canary Testing
    • Dynamic Routing
    • Service Migration
    • Load Shedding
    • Security
    • Static Response handling
    • Active/Active traffic management

以上。

Microservicesは基盤技術やツールや体制が充実していないと破綻することがよく言われるようになりました。今回のツール群をみるだけでも、保守や不具合解析以外にも、サービス間のつながりをどうするかとか、障害発生時もサービス全体として正しく振る舞うにはとか、そういう設計も重要な位置を占めていることが容易に想像できます。

事業に対するシステム構成上、Monolithicで十分であればそれに越したことは無いですね。。。