インターネットにおいて、素晴らしいサービスが沢山生まれてきている一方で、実はそれらを後ろで目立つことなく支えている人達がいます。
はい、それが皆さんご存知の所謂インフラエンジニアと呼ばれる人達です。素晴らしいサービスやアプリケーションがリリースされ、そらを開発したプログラマーが世間からの脚光を浴びている中、インフラエンジニアはその陰に身をひそめ、リリース後からこそ真の地獄が始まる、と言わんばかりに、サーバやネットワークのリソースのグラフを昼夜問わず眺めたり、監視アラートにビクビク怯えながら日々すごしています。
しかし、彼らはシステムを安定稼働させるために、自ら進んで後ろに立ち、常にシステムを最適化するためにはどうしたら良いかを考えてくれている、実は謙虚で立派な人達なのです。この「運用・保守」と呼ばれるインフラエンジニア達の行為こそが、インターネットのサービスを提供していく上で、とても重要な役割を果たしているのです。
有能なインフラエンジニアといえども
しかし、今ではインターネットが巨大になり、とんでもない量のサーバやネットワーク機器で溢れかえっています。それを、一つ一つみて正常性を保つなんてことは、彼らインフラエンジニアの高速なタイピング速度と、aliasを書きまくったり、エディタやターミナルを弄り倒して最適化された環境を持ってしても、おそらく不可能でしょう。もはや、管理すべきサーバやネットワーク台数が膨大になってしまうと、小手先の監視手法や監視サーバでは処理しきれなくなってしまいます。
大規模システムを監視するための大規模監視システムが必要
そこで、なにが重要になってくるのかというと、やはり大規模システムを監視するための、大規模監視システムなのです。
インシデント管理システムやドキュメント管理システム等、運用のための大事なシステムは沢山ありますが、全ては監視で始まり、監視で終わるといっても過言ではないほど、サービスが巨大になればなるほど、監視システムは重要になってきています。常にサービスを提供できていて、安定している状態を担保するために、監視システムは存在しているので、あえてここで言い切ってしまうと、「サービスのシステムよりも信頼性が必要である」と、僕は考えています。そのためには、どんなことがあっても機能継続できるように、しっかりと冗長構成を組んでおく必要があります。
大規模監視システムの冗長構成を設計するにあたって
今回は、監視システムの細かな設計を説明するのではなく、まずざっくりとした設計の絵を描く上で、意識すべき内容を列挙していきたいと思います。どのように冗長構成を設計すれば良いのか、さらに、冗長構成と一言でいっても、どのレベルまで冗長化するのか、が大事になってきます。そして、それを考えるのは非常に難しいことです。
そこで、以下に述べる内容を満たしていれば、「ある程度は信頼のある大規模対応の監視システムである」と言えるんじゃないかと、僕が現在考えている冗長構成の9つのポイントをインフラエンジニア目線で列挙していきたいと思います。
1．ネットワークの経路を意識した冗長構成
これは、バックボーンのネットワークの規模で考えるべきことです。ネットワークレベルで冗長構成を考える場合、2つの監視システムの拠点を置き、一つが落ちた場合は、もう一方が監視を継続するような監視システムを想定します。その場合、一見、異なるネットワークから監視しているから、冗長構成がとれていると考えたとします。しかし、例えば、以下の図のように、実はこのように監視システムネットワークBと監視対象のネットワークの間に監視ネットワークAがあるような経路は多々あります。
これだと監視システムネットワークAが落ちた場合、監視システムネットワークBからも到達できなくなってしまいます。バックボーンのネットワーク的に冗長構成を考える場合は、きちんと以下のように、それぞれが相互に接続されているバックボーンネットワークの経路であることを意識して冗長構成を設計しましょう。
2．データセンターレベルでの冗長構成
データセンターはさすがに落ちないだろー、とか思われがちですが、データセンターもサーバと一緒で落ちます。落ちる時は、何の救いもなく落ちてしまいます。僕も何回も経験があります。ですので、例えば、一つの監視システムが属するデータセンターが落ちたとしても、もう一つの監視システムが監視を継続できるような構成を取った方が良いでしょう。前項のバックボーンのネットワークの経路を意識した冗長構成において指摘した内容と同様、各ネットワークにデータセンターがあり、それぞれが監視対象と相互に接続されていれば良いでしょう。
3．ラック単位での冗長構成
サーバやネットワーク機器をデータセンターのラックに積む時に、冗長構成を組む場合は、片方のラックになんらかの理由で電気が流れなくなったとしても、もう片方のラックで機能を継続できるように、ラック単位で機能を完結させるように冗長構成を設計しておきましょう。
4．ラック内の電源系統での冗長構成
ラック内に2つの電源系統のタップが用意されている場合が多いです。その場合は、一方の電源系統のタップに電気が流れなくなったとしても、片方の電源系統のタップが流れていれば機能を継続できるように、電源系統とタップを意識したサーバやネットワーク機器の電源の配線を心がけましょう。ラック内に2台のサーバである機能の冗長構成を取る場合は、電源系統が別のタップにそれぞれさすようにすると良いでしょう。
5．L3スイッチでの冗長構成
監視システムの上位の稼働中のL3スイッチが落ちたとしても、別のL3スイッチが機能を継続できるように設計しておきましょう。また、通信の種類（サービス系やメンテナンス系等）でプライベートのネットワークを分離させておくと、ネットワークが切れた場合の影響範囲が分かりやすくなるため良いでしょう。
6．L2スイッチでの冗長構成
監視システムの上位の稼働中のL2スイッチが落ちたとしても、別のL2スイッチで機能を継続できるように設計しておきましょう。スイッチの交換は、適当にラックにマウントしていると、最悪の場合別の機器を外さないと交換できなかったりするので、それでは冗長構成している意味がありません。スイッチが安全に交換できるように、LANケーブルや電源ケーブルをきちんとまとめ、棚板等を適宜かましておいて、必ず何度か冗長構成のテストと合わせてスイッチ交換のテストをしておくと良いでしょう。
7．サーバのbondingでの冗長構成
上位のスイッチが冗長構成になっている場合は、サーバ側でも複数のNICを持ってそれぞれを上位の冗長化されたスイッチに別々にケーブルをはわすようにしておくとよいでしょう。上位のスイッチの冗長構成をうまく使えるように、Bondingの設定と配線を行うようにしましょう。
8．データのネットワークミラーリングでの冗長構成
このあたりからは、かなりテクニカルな話になってくるので、今回は簡単にしておきます。スケールするために、分散ファイルシステム等がありますが、とりあえず監視のソフトウェアをオープンソースを想定した場合は、DRBDを用いてActiveとStandbyの関係でファイルやデータベースをネットワークでのミラーリングによって同期するのが、汎用性があって現実的なアプローチと言えるでしょう。しかし、グローバルIPでのネットワークミラーリングとなると100Mbpsなんとかしないといけない場合が多いので、データベースのキャッシュやバッファーに溜めてから書き込む等のチューニングは必須となるでしょう。
9．監視システムがスケールできるように冗長構成
監視対象の拠点（データセンター）が増えた場合には、監視の負荷を分散できるように、拠点ごとに監視システムのプロキシのようなサーバを置いてやって、そのプロキシがサーバから回収したデータを収集して管理する親のノードを別に持つ、といったような構成を取るべきでしょう。
そうすると、拠点が増えればその拠点に監視システムのプロキシを置くことで、データは親のノードで一元管理できる上、負荷も分散できるといった構成が可能になります。できれば、運用者は親のノードのデータをWebブラウザで見ていれば、全ての拠点のサーバやネットワーク機器の状況が把握でき、一元管理できるようにしておいた方がよいでしょう。拠点ごとに管理するページが違うのは運用している内に誤って設定をしてしまったりと、事故の元になるのでおすすめしません。しかし、この構成では親ノードが簡単にスケールできないので、その対処法やSLAを十分に議論しておいた方がよいでしょう。
こういった構成を前提に、親ノードをデータセンター間で冗長化したり、プロキシは拠点内のラック間で冗長化したりと、各サーバや機能ごとに冗長構成にしていくという考え方で設計していくと良いと思います。
最後に注意すべき事
監視システムの設計をざっくりと考えるとまずはこれぐらいでしょうか。細かな設計は具体化していくうちに必要になってきますが、まず「冗長構成」といってもどのレベルまで考えておくか、という問題がありますので、今回の記事ぐらい考えておけばそれなりの安定した監視システムが構築できると思います。しかし、注意しなければならないのは、
稼働率99.9999・・・を意識するあまりに、複雑な冗長構成やデータの同期を緻密に行うことで、余計に負荷のかかるシステムになってしまい、結局監視システム自体のメンテナンスや障害等で稼働率が落ちてしまう
という状況は多々あります。「どこで妥協するか」を常に念頭において設計すると良いと思います。