Operate：利用者視点でのサービス改善を前提に運用する【第11回】

　IBM Garageのコンポーネントの1つである「Operate」は、「Co-Operate（共同運用）フェーズ」に位置し、サービスの安定運用と改善を担う。Operateの実践に向けてIBM Garageでは、グループごとの取り組みを定義している。「Ensure your app is running when your need it（必要なタイミングで実行）」「Ensure operational excellence（運用・保守の効率化）」「Data, AI and analytics」などだ。

　Operateの実践で目指す姿の1つが「DevOps（開発と運用の融合）」である。例えば、ビジネス責任者にとっての成果の1つは、より多くの機能を開発することであり、開発担当者の成果は、その要求にできる限り応じることだ。

　しかし実際のサービスの運用・保守場面では、安定性と回復性が求められる。運用担当者にすれば、いざ障害が発生した時のことを考えれば、心理的なストレスにもなる。テストも不十分なプロダクトの維持を無制限に押し付けられているといった感覚も生まれ「リリースしたくない」など保守的なマインドに陥ってしまう。開発担当者が「運用・保守担当者は保守的だ」と評する理由は、こういったとこにもあると考えられている。

　こうした状況を生まないための取り組みを定義しているのがOperateなのだ。以下ではOperateにおいて特に重要なポイントを説明する。

Cloudは“落ちる”ことを前提に設計する

　一般的なパブリッククラウドでは、仮に一部のサーバーやデータセンターが停止しても利用者に対するサービスが停止しないように設計することを推奨している。「Design for Failure」とも言われ、費用をかけてでも可用性を極限まで高めサーバーが絶対に落ちないようにするという考え方はとっていない。

　ハードウェアやノードが停止してもサービスを継続できるようにするためには、ハードウェアやノード、インスタンスといったコンポーネントのトポロジーや、アプリケーションの設計が重要になる。

　最も多用されている対策は、「あるノードのインスタンスが停止しても異なるインスタンスへ要求を転送する」という設計だ。サービスの単位を細分する「マイクロサービス」の仕組みなどを適用する場合は、様々なデザインパターンが提唱されている。またパブリッククラウドのマネージドサービスは大抵、自動でスケール（拡張）できるように設計されている。アプリケーションの側でも、クラウドの自動スケールに対応した設計をすることで、急なビジネス拡大に備えた準備が可能になる。

　一方で、制限なく自動スケールする仕組みを採用すると、クラウドの利用料が無制限に課金されてしまう場合がある。夜間に悪意のあるDoS／DDoS攻撃などを受けてクラウドが自動スケールしてしまうと、攻撃が収束した後に高額課金で青ざめるということにもなりかねない。自動スケールに対応した設計も大事だが、スケールの上限値や課金の通知に対応する責任者を決定しておくなど運用に対する設計も重要だ。