システムメンテナンスって何？
オンラインサービスにシステムメンテナンスはつきものである。一般ユーザーにとっては、システムメンテナンスというと「たびたび夜間に利用できなくなる残念なイベント」と思われてるかもしれない。実際は、サービス停止を伴うメンテナンスもあれば、停止を伴わないメンテナンスもある。言うまでもなく、サービス停止を伴わないメンテナンスのほうが望ましいし、停止しなくていいように中の人は工夫する。
ちなみに、利用しようとしたサービスにメンテナンス中を告げられるも、そのメンテナンスの開始時間と終了予定時間（サービス再開時間）が明記されてない場合、十中八九それは計画的なメンテナンスではなくトラブルだ。この記事では扱わない。
サービス停止を伴うかどうかはさておき、最初のリリース後も更新し続けることが宿命のシステムでは、システムメンテナンスでは以下のような「アップデート」がされている。
- 機能の追加・改善
- バグの修正
- インフラやミドルウェアの載せ替え、バージョンアップ、アップグレード
これらのアップデートはどのように計画するべきだろうか。
機能の追加・改善とバグの修正について、「アップデートはいつするの？」はさして問題にはならない。機能の追加・改善は、ビジネス上の優先順位に沿ってやればいいし、バグの修正はその問題の重大度(severity)に応じて決めればいい。
では、インフラやミドルウェアの載せ替え、バージョンアップ、アップグレードはいつするべきだろうか。そもそも、それらのアップデートはなぜ必要なのだろうか。
ソフトウェアには賞味期限がある
オンラインサービスのようなソフトウェアは、いろんなものに依存して動いている。 たとえば、あるWebシステムはこんな構成で動いているかもしれない。
- ホスティングは自前のデータセンターに組まれたKubernetes
- アプリケーションはJavaとSpringboot
- データベースはMongoDB
これら使用しているソフトウェアはバージョニングされており、それぞれのバージョンにはEOL（End of Life）、いわゆるサポート期限がある。
たとえば、上の構成をすべて執筆時点（2024年5月）で最新もしくはぼちぼち新しいバージョンを使ったとして、それぞれのリリース日とEOLは以下の通り。
- Kubernetes
- 最新バージョン: 1.30
- リリース日: 2024-04-17
- EOL: 2025-06-28
- Java
- 最新バージョン: 21 (Oracle JDK の場合)
- リリース日: 2023-09-19
- EOL: 2028-09-30
- Springboot
- 最新バージョン: 3.2
- リリース日: 2023-11-23
- EOL: 2026-02-23
- MongoDB
- 最新バージョン: 7.0
- リリース日: 2023-08
- EOL: 2026-08
このように、ソフトウェアは多くものに依存しており、それらはほとんどの場合EOLがある。システムの改善のために、依存するソフトウェアのアップグレードをするのはとても前向きで喜ばしい。その一方で、サービス提供者が現状で満足していたとしても「現状維持」のためには、依存するものたちを寿命が切れる前にアップグレードしなければいけない。
EOLを過ぎるとどうなるのか？いきなり動かなくなるわけではないが、バグがあっても修正されなくなるし、有償のサポートに「助けて」とお願いしても、にべもなく「最新版にアップグレードしてください」と断られる。
プログラマーと料理人のメタファに無理やりあてはめれば、食材や調味料の賞味期限と言えるかもしれない。
自宅の冷蔵庫に賞味期限の切れた調味料はあるし、実際まだ使えるよね？家庭で使ってお腹壊しても自己責任だ。でも、それをプロの料理人として仕事で使うのはいただけない。
メンテナンスの3つの戦略
EOL対策としてのメンテナンスに限定せず、一般にシステムのアップデートを計画する際にとりうる戦略を考えてみよう。以下の3つの戦略が考えられる。
- 式年遷宮 戦略
- 車検 戦略
- ハウスキーピング 戦略
式年遷宮 戦略
式年遷宮とは、伊勢神宮が行っている、20年ごとに東と西の宮処を入れ替える仕組みだ。これによって、activeな神殿をサービス提供しながら、standbyな神殿をオフラインで建て替えられる（罰当たりですいません）。
ソフトウェアの世界で20年はいささか長すぎるけど、たとえば8年や10年に一度すっかり新しい一式に入れ替える戦略を取る場合、私はそれを式年遷宮と呼ぶ。
この手段は、実際のところ戦略的に実行されることはあまりなく、長い間メンテナンスされなかったシステムがいよいよ手がつけられなくなり、やむなく総入れ替えが計画されるタイミングが10年だったりする。
長い間メンテナンスされなかったのにはそれなりの理由があるわけで、当然リスクが高く、成功する見込みは少ない。
伊勢神宮のように、あらかじめ計画してこそ戦略といえる。
車検 戦略
自動車を持っているひとでないと馴染みがないかもしれないが、日本では自動車を所有するには2年もしくは3年に一度、法的な登録手続きをする必要がある。その際、公道を走る上で必要最低限の基準を満たしてるか（故障してないか、改造してないか）を検査される。検査をパスするために、故障があれば整備（メンテナンス）する必要がある。検査にパスできなかった車は公道を走れなくなる。
この戦略の要は、定期的であること、強い強制力があることだ。
自動車の場合は2年から3年だが、システムメンテナンスでは1年に一度のほうが（予算とか）計画しやすい組織は多いんじゃないかな。
ハウスキーピング 戦略
ハウスキーピングとは、要するに家事のこと。掃除したり、洗濯したり、皿洗ったり。毎日掃除と洗濯して毎食後皿洗う人もいれば、数日貯めちゃう一人暮らしのひともいるかもしれない。とはいえ短い間隔で行われ、さぼると家をきれいに保てなくなる。
システム開発の場合、毎日といわずとも、たとえばScrumをくんでいるチームであれば2週間のスプリントのたびにコードをきれいにできたら、ピカピカのシステムを維持できるかもしれない。
アップデートはいつするの？
先に挙げたKuberentesやMongoDBのような依存するソフトウェアのアップグレードは、どの戦略が適してるだろうか。上の例では、Kuberenetesだと1年でEOLが切れてしまう。MongoDBとSpringbootで2~3年だ。
式年遷宮戦略では、間に合わない。
ハウスキーピング戦略でできる？十分に自動テストがされていれば、ライブラリぐらいなら常に最新版にできるかもしれない。でも、データベースはリスクに見合わないだろう。
というわけで、おすすめは車検戦略だ。肝心なのは、定期的であること、強制力を持つことだ。
期間は、やはり1年に一度がいいだろう。MongoDBは2~3年もつんだから毎年やる必要ないでしょ？という意見が出るだろう。でも、どうせ今年やらなかったら来年やるんだよ。毎年やらなければいけない面倒なことは、面倒にならないような仕組みを作る動機になる。3年に一度だと「3年後は誰か他のひとがやるだろうな」と思っちゃうよね。
あとはマネージメントがリーダーシップを発揮して計画すること。要は時間と予算をあてることだ。最初はこのアップデートにかかる時間と費用を辛く感じるかもしれない。でも、毎年やるのであれば効率化する余地はきっとある。いずれ、時間も費用も気にならないレベルになるだろう。
おまけ
最後に、このアップデートの車検戦略への想定される意見についてFAQを残しておこう。
Q. そんなに何度もサービス停止できないよ
きっとデータベースあたりにオンラインで更新できない依存があるのかな。何にせよ、サービス停止しないとメンテナンスできないアーキテクチャを、サービス停止できないシステムに採用してしまっているのが問題だ。きっとサービスが使われるようになって、サービスレベルの要求が当初よりあがったのだろう。いいことじゃないか。
サービス停止しないで更新できるアーキテクチャに置き換えるいいチャンスと考えよう。
Q. アップデートでトラブル起こされるのが怖いんだけど
インフラやミドルウェアの載せ替え、バージョンアップ、アップグレードはリスクの高い作業だ。一年に一回しかやらないのであればなおさらだ。十分にテストしてもなおトラブルを起こすかもしれない。
でもね、たとえば今年アップデートしないで２年後にやることにしたとしよう。それでリスク回避できたのだろうか。
もし今年アップデートしていたら起こしていたかもしれないトラブルは、２年後にやったとしても必ず起こす。むしろ、間隔があけばあくほどリスクはあがる。
今年不幸にもトラブルを起こしてしまったとしても、事後検証して活かすことができれば、次年度からはうまくいくだろう。
まれにやるから怖いんだ。何度もやれば怖くない。
Q. やりたくないんだけど
だよね、わかるよ！私も、自宅では見えないところの掃除をなかなかできずに何年も汚れをためてしまったりする。
そういう人、というかできるだけメンテナンスをしたくない組織は、パブリッククラウドなりを最大限に使ってメンテナンスを可能な限りしなくてもすむアーキテクチャを選ぼう。クラウドのデータベースとか、ちょっとお高くても、メンテナンスコスト込みだと思えば割安だ。