Mackerelの障害報告書
はてなが、サーバー監視サービスを運営しているのは知っていました。
使い易いUIと効率的なAPIによる総合的な監視体験と、より自動化された
インフラ基盤の構築を可能にする、SaaS型サーバー監視サービスを提供します。
ビッグユーザーもたくさん抱えていて、GUIもきれいで興味はあったのですが、2018/9/26に障害が発生していてそのレポートが出ているので読んでみました。
発生時間: 2018/09/26 10:51-15:20 (JST)
発生事象: Mackerelシステム全体の不調と死活監視の停止
感想
もし、本番で今後Mackerelを使おうと企画されている方は、上記レポートを読むべきです。5時間半、監視ができない状態になったにも関わらず、その原因が不明確。仮説も再現できず、暫定対策として、トリガーとなったRedisのフェイルオーバータイミングのチューニングを実施。Redisに不要なデータを保管しないようアプリケーションの改修を実施。不適切なAPIの検出精度向上とフィルタリング、サーバーリソースのスケールアップや、スケールアウトを上げています。外堀から攻めていく方法ですが、原因不明のまま調査打ち切りというのも不安な状況です。
私もたくさんのシステムを見てきましたが、複数のシステムの監視データを１つの監視システムで監視する仕組みは、軒並み失敗しているのを知っています。平常時は全く問題ありません。問題は、複数のシステムに異常が発生した際です。1つのシステムが異常の時でも、監視サーバーが処理しなければいけない、いわゆるトリガーが100倍にも1000倍にも発生します。収集するログの量も激増します。これが複数同時発生すると、とてもとてもさばけなくなります。高負荷になってしまうと、正常なシステムの監視すら行えなくなってしまいます。したがって、全く関係ないシステムのために、正常なシステムの監視活動すらできなくなってしまうことがあるのです。
そのような事例を多数目にした後、私が設計・構築するシステムは、必ず監視サーバーを専用で設けるようにしました。副作用としては、監視サーバーの画面がシステムごとなので、複数のシステムを運用しようとすると、複数の監視サーバー管理画面を相手にしなければいけないということです。しかし、複数のシステムが一気に監視できなくなるよりは全然マシです。したがって、Mackerelは私が設計する場合において、今後も採用の予定はありません。
現状のMackerelの設計は知らないのですが、今のトレンドの構築方法で言えば、コンテナを用いて1エンドユーザー1コンテナとし、冗長構成をKubernetesでコントロールするのが素敵なのでしょう。モノリシックなデザインであれば、システム単位を複数に分け、いくつかの顧客ごとに完全分割するという方法も良いでしょう。何しろ、1つのシステムで問題が起こると全顧客がしびれる設計は監視システムとしては、私の信じる原則からは外れます。
まとめ
北海道自身の停電の際も思いましたが、1つの大きな設備に大半のユーザーがぶらさがっていると、その設備に問題が起きると、大障害につながってしまいます。小刻みに独立した小さな設備を作りユーザーを小さく振り分けると、ある設備に問題が起きても他のユーザーに飛び火しません。このようなフェイルセーフの考え方が、意外と大事にされていないと思うことがしばしばです。大きく１つにまとめると見た目上のコストや、効率・生産性が上がるように見えます。大障害を数度経験すると、このような感覚は吹っ飛んで、どう批判されてもいいので設計時は局所性を重視します。設計時が全ての勝負です。共有は禁止。占有を優先。コスト見合いで調整、と言ったところです。大きな１つの共有システムを作って、冗長性を至る所に組み込み、これで安全と言い切るようなシステム設計は危険です。冗長性すら今回のMackerelの障害のように、障害トリガーになりえます。冗長性より局所性のほうが、大障害を防ぐためには有効です。
大障害は、限られた運用リソースを麻痺させ、複数の小さな障害の顧客影響を増幅させてしまいます。電話がつながらない・・、報告がない・・、対応が遅れる・・、等々です。
システムは個別に分ける。相互に干渉しないようにする。この原則を守ることこそ、運用時に自分の命を守るような気がしてなりません。監視システムしかり、です。
