• HOME
  • プロローグ
  • 正解がない運用設計という「思想」:現場のプロが語ってみる(2)

正解がない運用設計という「思想」:現場のプロが語ってみる(2)

IIJの福原です。まずは運用設計の概要だけでもお分かりいただけたでしょうか?

【前回記事】運用設計って一体どんな仕事なのか?:現場のプロが語ってみる(1)
https://un4navi.com/prologue/20081/

少しでも興味を持っていただけたなら幸いです。引き続き、監視や運用についての話をしてみましょう。例えば、監視業務に注目してみてください。無駄だったり、意味のない監視をしていませんか?『何を監視するか?』は確かに重要ですが、『何を監視しないか?』を考えたことはありますか?

どこを監視すべきか?直接?間接?

監視という役割は、システム運用全体の中で非常に重要な部分を担っています。しかし、システム全体の安定を考えれば、ただ監視にだけ集中していればいいということはなく、システム全体が問題なく動いていることを、どのような点で品質を担保・保証するのか?まで考えなければなりません。それが、監視設計であり、監視を含む運用設計です。

例えば、Webサイトのようなシステムを運用していく場合を例に考えてみましょう。
Webサイトを運用する場合、どんな状態が一番困るかというと、サイトにアクセスしてもページが表示されない状態ですよね。サービスを運用している側にとっては、サーバが落ちているというが一番困ります。
そういう状態を避けるために一番最初に考えるべきは、システム運用や監視ではないんです。考える必要があるのは、システムのアーキテクチャや構成のはず。例えば、冗長化や多重化、クラスタリング、ロードバランサの導入を検討する、などです。

冗長化:障害が起きたときに備えて、予備として同じ装置を普段から運用しておくこと
多重化:一つのサーバや回線に複数をまとめ、同時に稼働させること
クラスタリング:複数のサーバを連携させ、一つのシステムとして運用すること
ロードバランサ:サーバに掛かる負荷を分散させること

ロードバランサが導入されているWebシステムの場合を考えてみましょう。URLへアクセスした場合、レスポンスはWebサーバが直接返すのではなく、ロードバランサを介して返すこともあります。ということは、ロードバランサが上手く負荷を分散させてくれているうちは、どこかのサーバに障害の兆候があっても、URLレベルで監視しているだけでは気がつきません。つまり、URLを叩いてアクセスできなくなるのは、本当にそのサーバ全体の緊急事態なので、そこだけ監視しても手遅れなんです。

<PR>どこの何を監視すれば効果的なのか?それを考えて、その通り運用するのが、運用設計という仕事。SaaS型の統合運用管理サービス「UOM」を使えば、システム運用がラクに!
詳しくはこちら

また、クラスタリングを導入しているケースも考えられます。クラスタリングとは、複数のサーバを連携させ、一つのシステムとして運用することで、どこか一部に障害が起きても切り替わることで、影響が出ないようにする仕組みです。クラスタを切り替えたことで一時的にアクセスできなくなっていたとしても、その後、システムが正常に動いているのなら、それは問題ありません。もちろん、なぜ切り替わったか理由は調査して、障害としての対応を検討しますが、復旧作業は必要ありません。
一方、多重化している環境だと、1台または2台のサーバが切り離された状態になっている可能性がありますが、これらは何らかの方法で元に戻す必要があります。多重化したサーバをロードバランサで束ねている場合だと、サーバの死活はロードバランサが把握しているので、そのログが残ります。復旧は、再起動だけでいいのか、何か部品を交換しなければならないのか、システムの構成や方式によって、必要な対処は異なります。

このように、URLを直接監視するのではなく、間接的な部分を監視した方が、最悪の状態に至る前の段階で対処する、予防保全としては的確だといえます。つまり、障害に強いシステムを稼働させるための品質担保・品質保証として、システム運用を設計する必要があるわけです。

同じ設計でも「思想の違い」をどう埋めるか

ただ、残念ながら、現場では『監視は、監視だけ』『監視して、終わり』のように、分断されていることも多いのが現実です。上がってきた障害に対して、その都度どうするか考えながら対応する、非効率な現場も珍しくありません。
そうなっている理由の一つもやはり、設計という思想の違いにあります。システムの作り方は一つしかないわけではなく、構成がすべて違うので、『必ずこうしなければならない』とはいえないのは、先に説明した通りです。インフラの設計思想はそれぞれなので、それに合わせていくしかありません。確かに、ある程度以上の組織の規模によっては、エンジニアが複数いて業務の棲み分けによる、コミュニケーション不足の影響も否定はできません。ただ、システム構成の違いによって、結果として業務がバラバラになってしまうのも、仕方ない面もあります。
とはいえ、やはり単に監視すればいいとか、監視して終わりなのではなく、監視した後に具体的に何をするかを決めておくのが、監視設計であり、運用設計です。システム運用の現場をスムーズに回し、エンジニアに過度な負担を強いないためにも、設計の段階から、可能な限りの効率化・自動化を考慮しておく必要があるでしょう。

次回は、開発と運用それぞれにおける設計という時間軸の差と、監視設計できるようになるエンジニアのキャリアについて話します。引き続きお楽しみに。

IIJ_福原亮株式会社インターネットイニシアティブ
システムクラウド本部
クラウドサービス3部 副部長 兼 M&Oサービス開発課長
福原 亮

<PR>システムの細部まで人がチェックするなんて、もう絶対無理だし無駄ですよね?だったら、SaaS型の統合運用管理サービス「UOM」で自動化・効率化です!詳しくはこちら

関連記事一覧