ソフトウェアのバージョンアップの価値¶

ソフトウェアのバージョンアップにはセキュリティの向上、新機能の追加、バグの修正など多くのメリットがある。 外部のユーザーがいるようなシステムであれば、セキュリティ上の取り組みは重要である。 脆弱性を悪用されることで、とてつもなく大きな損害を被ることもあるがバージョンアップを行うことで防げる問題も多々ある。 ソフトウェアを通じてユーザーに価値提供を続けるのであれば、バージョンアップは避けて通れない作業となる。

更新を怠るとセキュリティリスクが高まるだけでなく、新機能の利用やバグ修正がいつまでもできない。 バージョンアップをすれば将来的に置き換わるであろう古い API であっても、更新ができないばかりにその古い API を使って新たに開発をしなければならないこともある。 このような状況は開発者体験が悪く、いずれ使わなくなることがわかっている API を新たに使うのは将来的なメンテナンスコストを増やすことになる。

OSS などで公開されているソフトウェアを活用することで、開発にかかる時間の短縮が期待できる。 各ソフトウェアのメンテナが数ヶ月から数年かけて開発したものを、数時間から数週間の作業で導入できることを考えると、バージョンアップのコストは安いと言える。

バージョンアップの負荷が大きいと、あらゆるソフトウェアをまとめて一度のタイミングで大きく更新しようとする力が働く。 これは影響範囲の大きいビッグバンリリースとなり、システムが壊れる可能性が高い。 壊れた後の原因調査でも影響範囲が広く、原因の特定が難しい。 バージョンアップを安定して行いたいのであれば、影響範囲を小さく限定した更新を繰り返すことが重要となる。 昨今のソフトウェア開発では更新の対象が多岐にわたる。コンテナイメージやアプリケーション利用のライブラリ、OS、DB やネットワーク周りのミドルウェアなど様々である。 依存するソフトウェアが増えるほど更新の負荷が大きくなる。 対象のソフトウェアが多いと、更新があるかどうかを人が把握するのは難しく、一つ一つの更新によって影響が出るか確認するのも困難である。 このような状況に陥らないためには、そもそも、更新の負荷が大きいソフトウェアへの依存を避けられるのであれば避けることが望ましい。 もう一つ重要な点として機械的に更新を検知する仕組みを導入し、更新によってクリティカルな影響が出ないことを確認する自動テストを行うことが挙げられる。 事前のテスト自動化だけで影響範囲の特定が難しい場合は、カナリア、ブルーグリーン、シャドウなどのデプロイ戦略を活用することで更新の影響範囲を限定したり、問題を検知できる。

機械的に更新を検知する仕組みを導入する際には、検索性と走査性が重要である。 古いソフトウェアを使っていることを検索したり、スキャンすることで更新が必要なソフトウェアを特定できる。 検索性や走査性が悪い例として、複数ブランチでの運用が挙げられる。GitHub なんかでは検索対象がデフォルトのブランチに限定されるため、他のブランチを対象として検索できない。 スキャンを行うためのツールでも、デフォルトのブランチしか対象としていないものがあり、複数ブランチでの運用はスキャン性が悪い。

メンテナンスや運用に関連する話として、技術選定の際にメンテナンス性を考慮せずに「おもしろそうだから」という理由で選定すると、後々のバージョンアップのコストが高くなることがある。 運用経験が浅いと、運用を考慮できずに、運用できない技術を採用してしまうこともある。 運用できない技術を採用してしまうと中長期的には運用コストが高くなるため、組織としての価値提供を最大化できない。 自ら開発したものを自ら運用する DevOps の考え方に立ち返り、短期的にも中長期的にもソフトウェアの価値が高まるような選択が重要である。

まとめ

• ソフトウェアのバージョンアップはセキュリティの向上、新機能の追加、バグの修正など多くのメリットがある。
• バージョンアップを怠るとセキュリティリスクが高まるだけでなく、新機能や修正されたバグを利用できなくなる。
• バージョンアップの負荷が大きいと、ビッグバンリリースとなり、システムが壊れる可能性が高まる。
• バージョンアップを安定して行いたいのであれば、影響範囲を小さく限定した更新を繰り返すことが重要である。
• 機械的に更新を検知する仕組みを導入し、更新によってクリティカルな影響が出ないことを確認する自動テストを行うことが重要である。
• 技術選定の際にはメンテナンス性を考慮し、運用できる技術を選定することが重要である。