オルタナティブ・ブログ > クラウド的な世界へ >

企業ITもクラウド的な世界に向かい始めた今日この頃を徒然に‥

勝手にパッチが当たっていく

»

以前PaaSのリリースアップについてアプリのテストなどの観点で考えてみました。では、もうすこし細やかな単位のパッチなどの適用はどうでしょうか。

GoogleやSalesforceなどの既存のクラウドベンダーをみても、さすがにパッチをいつ適用したかなどはほどんど公開していないようです。たぶん問題がおきたりしたら、その問題解決などでパッチ適用なりをしているのでしょう。大きな問題や、セキュリティーの問題などのときは、多少の事後報告は公式Blogなどであるようです。

バグの入ったパッチが適用されたら、という心配はあるにせよ、そこはそのシステムの開発、兼運用専門ベンダー。パッチによってシステムが止まったというのは、ほどんど聞かないか、あまり公表されていません。クラウドのパッチ適用は、よく言えばアプリケーションにとってほとんど透過的ということでしょう。

ところで、普通のオンプレミスのシステムではどうでしょう。システムのベンダーがパッチがある程度出てきた段階で、今度これを適用させてくださいと提案するのがよく見られる光景でしょうか。それがミッションクリティカルなシステムの場合などは特にですが、既存のシステムに影響がないか、他のお客様での実績などを求められることがよくあります。

場合によっては本番と同じような環境で事前テストを十分に行い、サービス開始時さながらのパッチ適用体制も見られます。ユーザーにとっても万一のことを考えると気の抜けない、またベンダーにとっても大仕事であり、かつ両者にとってコストのかなりかかる場面です。

おそらく、パッチを当てないほうがリスクがあるか、当てたほうがリスクがあるか、このせめぎ合いが、クラウドとオンプレミスのパッチに対する大きなアプローチの違いを表しているのだと思います。

ミッションクリティカルの分野では、パッチに対してお国柄もでるようです。日本では総じて、パッチ一つでも万一のことがあってはいけないので極めて慎重で、欧米や中国などでは問題が減る可能性があるのであればとどんどん当てていくという傾向があるようです。

クライアントPCなどはインターネットのセキュリティー課題の急激な増大から、もはや少なくともセキュリティーパッチを当てないでやりすごすという選択肢はなくなりつつあるでしょう。

身近には、携帯電話が最近では中身はよくわからないまでも、知らないうちにどんどんパッチがあたっているようです。また、最近の車では点検に出すたびに新しいファームウェアにあげるということが行われています。

ベンダーのエンジニアとしては、いっそのこと一切パッチを当てなくて塩漬けで済むようなシステムのアーキテクチャーがでてこないかと妄想にふけりたくなります。でなければパッチ適用の運用管理をきっちりプランしてお金を積んでおくか、さもなくばやっぱりクラウドで一切まかせてしまう。このあたりもクラウドとオンプレミスの選択の際の大きな考慮点の一つかもしれませんね。

Comment(6)

コメント

イチロウ

いつも拝読させて頂いております。
さてクラウド上のパッチ適用についてですが、例えば、Paas上にアプリを構築し運用していた場合、Paas業者が勝手にパッチを適用したおかげでアプリが不安定になるなんて事が起こる可能性はないでしょうか・・私が担当する金融機関ではそのリスクを鑑み、基本はパッチを適用しないのですが・・

T関

イチロウさんありがとうございます。可能性でいえばPaaSでも勝手にパッチがあたればアプリに支障がでることはありえるとおもいます。ただ、アプリがPaaSのインターフェースを深読みして作っていないとか、タイミングセンシティブに作っていない、そしてPaaSベンダーがインターフェースには影響を与えないかバグフィックスのみでパッチを当てる。この限りにおいてはその可能性は極めて小さくなると言えると思います。とはいえごりごり作りこむアプリもありますよね。PaaSでそういうアプリを作れるか、作っていいかという議論もあるでしょう。

一方、セキュリティーの課題が大きい場合はパッチでのアプリの支障の可能性以上に、当てないとリスクが大きくなることもあるでしょう。

このあたりまた整理して書いてみたいと思います。なかなか難しいテーマではありますが。適切な質問ありがとうございます。

ミッチー

自動のパッチ適用のあり方を見直すPaaSベンダーもあるようですね。SaaSのようにアプリも含めて全てベンダーで運用できる場合と異なり、PaaSを提供する上ではこの話題は避けて通れないのかもしれません。より影響があるのがユーザー企業自身が運営するプライベート・クラウドではないでしょうか。クラウド上の全てのシステムを塩漬けするわけにも行きませんので、パッチ適用ポリシーに応じた複数のクラウド環境を準備する必要がありそうです。パッチ適用による不具合への対応や影響度を確認するテスト費用にだけ目が行きがちですが、パッチを適用しなかったために生じるコスト、例えばトラブル対応の人件費、ビジネスの直接の損失、信用失墜などと比較・評価した上で、ポリシーを決定することが重要では無いかと考えています。

D.S

パッチを提供するベンダーから、リグレッション・テストの結果を公開してもらうというのはありえない話でしょうか。

ベンダーとしては、しかるべきリグレッション・テストを行って品質を確認した上でパッチを出荷していますので、本来であればお客様の方で実施すべき確認テストは限られているはずです。しかし、そのリグレッション・テストの結果が公開されていないため、お客様としては自分の信じるテストをすべて実施しなければ安心できません。そして、たいていの場合、テストの工数が莫大になるので、リスクに目をつぶってパッチを適用しない道を選択されているように思われるからです。

T関

ミッチーさん、コメントありがとうございます。SaaSでなくPaaSだと問題はまさにそうですね。またOSまで提供しているか、それより上位の抽象度の高いインターフェースを提供しているかにより、影響度も違うでしょう。抽象度が高ければ影響は少ないと期待されます。

プライベートクラウドで、ご指摘のポリシー別にプールを作るのも一つの方法かもしれませんね。ミッションクリティカルを扱うなら。理想的には同じポリシーがコストとして嬉しいですが。

T関

D.Sさん、コメントありがとうございます。いろいろ考えさせられます。

昔、メインフレームの開発にいましたが、リグレッションテストのツールがあって、アーキテクチャーブックの仕様でケースが作られていて、一晩で流していました。

ただオープンの時代になって、仕様がややぼけてきたせいか、さらに組み合わせや状態が指数関数的に増えてきて、そういった一晩でできるツールは作れない、すべてのテストケースは作れないなと思ったことがありました。またベンダーがケースを出してもローレベルのインターフェースのテストだったりして、アプリへの影響はわからないかもしれません。

アプリの視点で、基本的な機能のテストの自動化や、逆にPaaSなどである抽象度の高いインターフェースでのテストなどが、テストをするという前提では可能性のある方法かもしれませんね。

コメントを投稿する