クラウド的な世界へ

「ネットワークの遅延があるから地球の裏側とかのデータセンターは使いにくい」。こんな話をよく聞きます。確かにネットワークを伝わる信号は光の速さを超えられないので、米国のデータセンターなどを使えば、軽く100ミリ秒以上の損をします。でも100ミリ秒ちがったとして、本当にアプリケーションが使いづらいのか、ほかに高速化の手立てはないのか、ちょっと調べてみました。

アプリケーションによっては確かに数ミリ秒でも命取りになるものがあるのも事実です。最近話題の証券取引所などでは、プログラムで取引をして、より有利な売買をするために、取引所のデータセンターに投資家がサーバーを置けるようにする、コロケーションサービスが出始めました。まさに光の速度との戦いです。

一方では旧来のオンライン端末と呼ばれるものの応答時間の目標は3秒というのが昔よく聞かれた数字です。さすがに3秒は、銀行ATMの出始めとは違い、今の時代、ユーザーがかなり忍耐を強いられそうな数字です。実際、あのインターネットのキャッシングをしているアカマイの調査では、応答時間が3秒を超えるeコマースのサイトは相手にされなくなり、今は2秒がひとつの目安であるという調査結果が出ています。

こう見てくると、アプリケーションによってかなり幅はあるものの、広く使われるアプリケーションの多くは、皆さんの体感からも1秒や2秒程度がひとつの応答時間の目安ではないかと思われます。そこで実際に応答時間は何の総和で決まるかといえば、大雑把には、ネットワークの往復での遅延、サーバーでの処理の遅延、そしてクライアントの処理の遅延との和であることは容易に理解できます。

では実際、国際ネットワークの遅延はどのくらいでしょう。平均的な往復での遅延の目安について、キャリアの公表データからの現時点でのまとめがありました。国内とソウルや台北までならば50ミリ秒以内。シンガポールや北京といったところだと100ミリ秒以内。さらにバンコクや米国西海岸のサンホゼあたりでは100ミリ秒を超えるくらい。そしてニューヨークやシドニー、インドのムンバイだと200ミリ秒以内とのことです。もちろんこれを改善すべく努力もされているようです。

さてサーバーの処理時間と言えば、これもアプリケーションによって違いますし、測り方もいろいろありそうですが、平均処理時間が公表されているものがあります。PaaSで有名なSalesforceではトランザクションが一日1億に達しても平均253ミリ秒が実現できたとあります。またSaaSではオービックの勘定奉行 for J-SaaSでは、目標は3秒以内ですが、実績は平均32ミリ秒と、かなり軽くつくってあるようです。

そしてクライアント処理時間ですが、これはほとんどブラウザーのスピードになるわけです。Google Chromeが高速化にこだわって開発されていることは有名です。設計ポイントの一つが、DNS解決のプリフェッチによる高速化があり、それだけで軽く100ミリ秒がかせげるという記事がありました。彼らは過去、検索結果の行数を増やして500ミリ秒遅くしたことで収益を減らした経験があるそうです。

このように見てくると、速いブラウザーを使う、近くのセンターを使う、高速なサーバーを使うという応答時間に関する3つのポイントがあることが整理でき、それぞれの改善努力がされていることが分かります。もちろん速いにこしたことはありませんが、データセンターまでの距離で左右されるのがせいぜい200ミリ秒とすれば、国際ネットワークが遅いから地球の裏側のデータセンターは使えないはず、というのは特別なアプリケーションのみではないかなと思えてきました。

いよいよ2010年ですね。クラウドブームが始まった2009年をうけて2010年には何が起きそうか。クラウドのサービス・ベンチャーAppiroの2010年の予測を、2009年の予測（レビューは前回）と同様にサマリーしてみましょう。

①オープンソースよりクラウド開発者コミニティーが早く成長する
特定ベンダーの開発コミニティーと補完しあうながらも成長するという予測です。これがPaaSにとってのまさに鍵ですよね。

②クラウドの標準化は起きないし進めるべきでない
イノベーションのスピードが速くクラウドの標準化はインフラの低いレベル以外は起きないという予測です。一見、非難を浴びそうな予測ですが、確かにイノベーションが猛烈に速い分野では標準化は過去もあまり起きなかったような気がします。

③クラウド・プロバイダーはロックインに対応する
CIOの重要な懸案はPaaSのロックインであり続けるが、プロバイダーは他の言語のサポートや、移行のフレームワークやツールキットで対応しようとするという予測です。Google AppsやAzureは確かに言語ではそう見えますね。

④クラウドのインテグレーションが企業の代表例として現れる
オンプレミスのインテグレーションからクラウドのインテグレーションへと移っていき代表的な企業の例がでるとの予測です。イメージが沸くような沸かないような。

⑤企業アプリケーションがGoogle化していく
ExchageやSharepointだけでなく、よりきっちりした企業アプリケーションのフロントエンドをGoogleが担っていくという予測です。全部Googleにのるとはさすがに言わないですね。

⑥企業コラボレーションは一つの特徴でありビジネスではない
Salesforce ChatterやGoogle Waveが企業アプリケーションをリアルタイムのコラボレーションに統合していることから、単体の企業コラボレーションのビジネスは競争としてきびしくなるという予測です。古いですがグループウェアという単体ビジネスがきびしくなった現実が一つの現象かもしれません。

⑦MicrosoftはAzureでグローバル顧客を共食いする
オンプレミスの彼らのグローバルな顧客がAzureに食われていくという予測です。Software+Serviceの戦略がどれだけこれを緩和できるかでしょうか。

⑧クラウドの統合がおきる
GoogleとSalesforceを中心に買収などでクラウド・プロバイダーの統合がおこり、 OracleはNetSuiteを買収するのではという予測です。クラウドの業界再編ですね。

⑨グローバルのSI業者はクラウドマーケティング以上のことはしない
文字通りの予測です。かなり挑発的ですね。

⑩真のイノベーションはクラウドの技術ではなく、クラウドのビジネスの中でおきる
クラウドの保険の提供業者やセキュリティーの監査人など新しいクラウドのビジネスがおき、よりクラウドが使いやすくなるという予測です。これがまさにクラウドが企業IT市場で盛り上るかの鍵なのかもしれません。

2009年の予測に比べ、旧来のITビジネススキームにかなり挑発的なメッセージもありますが、ビジネスモデル、マーケットの視点が入っていて興味ぶかいです。2010年に起こるかは分かりませんが、こういうことが起きると企業むけのパブリック・クラウドのマーケットが本格化するという前提と言えたりするかもしれません。ともあれ2010年の変化は楽しみですね。良いお年をお迎えください。

年初に、「2009年クラウドでの10の予測」というクラウドのサービス会社Apprioの記事を紹介しました。1年での予測の当否が自己評価されていましたので、ご紹介したいと思います。

①クラウドの集まりのクラウドが広がる。但し、オープンプラットフォームを中心として。
「当たり」。SalesforceとTwitter、SalesforceとGoogleとの連携をあげています。Salesforceに偏っていますが、まあ広がったことは事実でしょうかね。

②Microsoft Azureは、せいぜいExchangeのよりよいプラットフォームになる程度だろう。
「当たり」。これは評価がややむずかしいですね。11月までサービス開始が遅れたことなどを指摘しています。ただAzureへの期待は高まっているようにも思え、やや甘い当たりでしょうか。

③Google Appsが見直され企業への採用が倍加する
「当たり」。200万を超える企業が有料のGoogle Appsを使っているそうです。1万ユーザーを超える採用も、Valeo、Motorola、Johnson Diverseyをあげています。倍加かはわかりませんが、まずは当たりでしょうか。

④主要なSaaS1.0企業が行き詰る
「当たり」。QuickarrowとOpenAirがNetSuiteに買収されたことをあげてマルチテナントでないSaaSは厳しいという評価です。ただ一方でこれをSaaS統合で勢いがでるという記事もあり、評価は分かれるところです。

⑤サーバーを保持しない1000人以上の企業が現れる
「外れ」。正直にまだ知る限りではないそうです。ただ時間の問題とも。Google Appsの例から、このくらいの人数のスタートアップならこれからありえるかもと思いますが。

⑥プライベートクラウドの増加と減少
「外れ」。今のところと断って、増加というか期待が高まっていると認めています。Gartnerなんかもその役割を認める意見が多いようです。幻滅期か衰退化となるのかはこれからの評価でしょうか。

⑦Business Intelligenceが次なるSaaS化が進む分野となる
「外れ」。BIクラウドのスタートアップだったLucidEraが破綻したこともあり、まだ時期尚早とのことです。LucidEraの発表では、カストマーは単純なBIは求めていなかったとのコメントが見あたります。大量データと複雑なニーズがクラウドにとって壁でしょうか。

⑧SAPまたはOracleがPaaS競争に入ってくる
「当たり」。11月にSAPが発表したBusiness ByDesignはマルチテナントで、レベルをあげたPaaSとして評価しているようです。たしかに来年1万社新規顧客獲得と、その本気度がうかがえます。

⑨企業がソーシャルネットワークの効果的な使い方を理解する
「当たり」。Avon、Starbucks、ComcastでのFacebookやほかのソーシャルネットワークの活用を指摘しています。日本ではまだこのあたりは本格化していませんね。

⑩Force.com上で少なくとも1億ドルを稼ぐソフトウェアが現れる
「当たり」。以前からForce.com上でERPサービスをのせていたCodaがSalesforceに一部支援を得て作ったFinancialForceの例やApprio自身のサービスをあげています。ただ1億ドルの可能性の予測となっていて、ほんとうに稼いだのかどうか。BMCやCAもForce.com上での開発を発表したりしていて勢いは確かに感じますが。

7つ当りで70点でしょうが、ややあまいところがあるので差し引いて50点っていうところじゃないでしょうか。

SaaS/PaaS/IaaSを筆頭に、さまざまなクラウドが飛び交った一年だったように思えます。みなさんの1年前の頭の中のクラウドは明らかに変質して、かつ混乱してきた人も多いように思えます。かくいう私も正直、"クラウド"という一言では、とても百花繚乱のクラウドの世界を語れないことの限界を感じています。

それでもあえて、整理の前の想像を広げる段階として、今一度、"クラウドで何が変わるか"を、パブリッククラウド中心に、人の立場ごとに乱文覚悟で書いてみたいと思います。ご容赦のほど。

ユーザーにとって

ユーザーにとっては、まずはSaaSは変化が大きいですよね。やりたいことに合うSaaSがあれば、IT部門に干渉されず少額ですぐにはじめられる。ただ多少のカストマイズはできてもそれ以上はなかなかむずかしい。既存のシステムとの連携は、IT部門が最初嫌がりそう。PaaSとかIaaSだといろいろ作れるかもしれないけど、やはりハードルは高くなりそう。システムが落ちても、停電と一緒で今までのようにIT部門に八つ当たりするすることは大抵エネルギーの無駄。でも簡単に始められることから、今までのようにユーザーで予算つけて、買ったり、作ったりするという意欲は相対的に減るかも。

開発者にとって

SaaSはさておき、何か作る場合には、DBモデルも違うのがあったり、手元にマシンは置けなくなるし、なんとなく新しい世界の不安。でも、まあ開発環境そろえてほしいといえば、今日でも使えるところは魅力。作り始めると他のクラウドのサービスとマッシュアップとかどんどんして、サービスの組み合わせってところが新しい感覚かも。でも何かエラーおきてもインフラは責任とってくれないので、自分でケアしなければならないのはなんか気持ちわるい。あと、がんがん作りこんだら、PaaSの制限に引っかかったなんてこともあり、いろんなことを考えなきゃいけない。可能性も制約も広がるかな。

IT部門にとって

全体を仕切って入れれば、運用は楽だし、固定資産は減るし魅力的。ただユーザーから細かい要求とかクレームがきても、クラウドベンダーが、そう言うことは聞いてくれないから、なんか板ばさみ。とはいえ放っておけば、ユーザーが勝手に契約したりするし。それに今までのように原因追及と上から細かく迫られても、クラウドベンダーのせいにするしかない。まあ大した努力せず、まずまずのサービスレベルはえらそうだけど。それで浮いた時間で、まじめにビジネスプロセス勉強するか。

ベンダーにとって

今までハードやソフトを売っていたところは、それらが売れなくなるのではという漠然とした不安。というか明らかに一部では、顧客がクラウドベンダーに変わるということはおきる。既存のベンダーはクラウド自身に手を出すと、少額の従量制で、ユーザー数を圧倒的に増やしてスケールメリットを得るとか、売り方はもちろん、社内のプロセスやコスト構造を随分変えていかないときついかも。クラウドベンダーになれたとしても、将来の顧客にインフラ投資しないといけないリスクをマネージしなきゃいけないし、さらに海外ベンダーと直接戦う、まさに太平洋の空中戦。

業界にとって

クラウドの盛り上がりが激しくなると、ハード、ソフトなどもクラウドベンダーが中心になって業界の構図が変わりそう。とくにPaaSは、どのプラットフォームに乗るべきか、かなり迷う。IaaSも単にハードからクラウドの仮想ハードというだけではどれだけ伸びるか不安。アプリのベンダーは、世界的なプラットフォームに乗ることで、もしかしてグローバル企業になるかもという夢をみられるかも。誰と組もうか悩む。いずれにしてもピンチはチャンスか。

まだまだ書ききれないことが山積で、かつバランスもまだまだ悪そうですが、更なる議論のヒントが出てくればと思います。乱文ご容赦を。

クラウドでコスト削減は、まさにマーケのお決まりメッセージですが、もうすこし具体的に考えられないかなと思い、TCO評価でお試し思考をしてみました。

ITコスト全体の代表指標が、総所有コストのTCO(Total Cost of Ownership)ですが、もともとはガートナーが90年代に言い出したもののようです。要は見えないコストなども含めてコストを時間軸も捕らえて把握しようという訳です。で、その具体的な内訳というとシンプルに定まったものがみつからないので、ガートナーのレポートなどから引っ張ってきました。

① ハードウェア/ソフトウェアの購入と保守
② システム運用・管理
③ ユーザーサポート
④ 開発
⑤ ネットワークなど共通インフラ
⑥ ユーザーのピア/セルフサポートと開発
⑦ ダウンタイム

①から⑤までが直接的な費用で、⑥と⑦は間接的な費用といえます。で、これをベースに今までのシステムが、どのくらいそれぞれの項目がかかっているかの、データの例を探してみました。アプリケーションによっても違うし、なかなか定まったものはないですが、企業全体では、とても大雑把にですが、⑥が3割前後、①が2割前後、②と③が1割前後、その他は1割以下というのが、業界などで多少の違いはあるものの、ひとつの傾向のようです。

クラウドでどうこれを減らせるか。例えばSaaSでは、①も②も④もすべてユーザー数かなにかのサブスクリプションになるわけで、少なくなりそうです。あとはアプリの使い勝手がよければ、③と⑥でしょうか。いずれにしてもSaaSは、TCOの多くの項目に影響を与えそうで、効果の検討のしがいがあるでしょう。

パブリックのPaaSやIaaSはでうでしょう。①と②が同様にサブスクリプションになって、計3割を超えるところだけに、効果を期待したいところです。あとはPaaSでは④がどう変わるのかと、開発の変化に検討が必要でしょう。

そしてプライベート・クラウドのPaaSやIaaSですが、①は自前ですから、標準化や自動化で②がどのように効果がでるかがやはり中心になりそうです。上のデータからすると1割前後ですので、きっちり標準化、自動化の効果を出さないといけなそうです。もちろんその標準化と自動化が広く他の項目にどの程度影響を与えるか、例えば標準化によりハードウェアとソフトウェアの調達にもメリットがでるとか、などの評価も必要でしょう。

実際TCO評価をするには、クラウド化を検討しているアプリケーションでのTCOのモデルをまずは作ってみて、利用するクラウドの形態でそれぞれの項目を評価していくのが正攻法でしょうか。一つすぐ気がつくのは、今までTCO評価で集めなければならなかったコストが、パブリックのクラウドでは一気にサブスクリプションという明確な数字になりTCO評価が少し楽になるところはクラウドらしさでしょうか。

あとはコスト、コストと考えると、忘れがちになるのが効果のほうでしょう。同じコストでもどれだけクラウドでメリットが出てくるのか、スピードや品質の変化の評価、そして究極的にはそのアプリでのROI（Return of Investment）など付加価値がどう出てくるかの視点も忘れてはならないポイントでしょう。

「我が社のIT部門が、わたしのもとに100項目ものセキュリティ要件が記載されたリストを持ってきたのだが、そこでふと気づいたんだ。ちょっと待てよ、そもそも我々自身のデータセンターはこれらの要件のほとんどを満たしていないじゃないかと」。

これは、病院に緊急治療室の管理サービスを提供するSchumacher GroupのCIO、Doug Menefee氏が、クラウドプロジェクトでの経験について、今年の春行われたIDC Cloud Computing Forumで述べたことだそうです。

Schumacher Groupは専任でセキュリティのITスタッフは3名。そんな中でCIOのMenefee氏はセキュリティに関して、「大手のクラウド・プロバイダの方が信頼がおける」と考えているそうです。

また米国のHIPPA法（医療保険の相互運用性と説明責任に関する法律）を順守しているプロバイダには、機密データの保存を委託しているそうです。ただし、Googleのツールを導入するプロジェクトを開始したものの、GoogleはHIPPAの認定を受けていないので、「そこに患者データを保存することはない」とも。自社の守るべきセキュリティと現状をきっちり踏まえた上での意思決定と言えるでしょう。

一方で、CSAJ(社団法人コンピュータソフトウェア協会)が、中小企業を対象にSaaSを選ぶ上でのアンケート調査を昨年実施しています。この中で、「信頼できるベンダーであれば、自社でデータを持つよりSaaSを利用した方が情報セキュリティ面で安心である」という質問をしています。この質問と回答でユニークなのは、SaaSに対して「内容を十分理解している」と自認している企業の回答では、「そう思う」が18.9%と、「ややそう思う」が45.9%、「内容もおおよそ知っている」という企業の回答では、「そう思う」が7.6%と、「ややそう思う」が50.3%となっており、SaaSをよく知っている人ほど、セキュリティ不安が少ないという結果になっています。

このように見ていくと、クラウドのプロバイダのセキュリティに関する信頼度の理解という側面、もう一つは、自社のセキュリティの現状の理解という側面の二つの観点が、クラウドにデータを預けるかという質問に対する答えの大きな要素になっていると思われます。

以前、グリッドや仮想化のセリングをしていたときに多くのお客様から、「うちのサーバーは余っていない」とか、「100%つかっている」という反応を随分いただきました。また、一台に統合すると、それが落ちたら全滅するという信頼性への不安も聞きました。それから何年かたって、今起こっていることは、サーバーやストレージの使用率をきっちりモニターして測定し、その上で、仮想化統合などを設計、実施していくという流れです。また、一台への統合で信頼性が落ちないような設計、ないしはリカバリープランを立てられています。なにか新しい技術の信頼度の理解と、自社の現状に対する理解という二つの軸で同じ流れを感じます。

高度化してきたセキュリティ対策、加速してきたセキュリティ・ベンダーのプロダクトやサービスのリリース。これらに追いついていくのか、外部にまかせるか。いずれにしても、まずは自社のセキュリティの現状を的確に調査、理解することが、適切なクラウドの検討を進めるのに重要なステップと思えてきます。

仕事にかまけて"クラウド的"がちょっとスローダウンです。で、今日は番長の今月のお題で、「あの人にオススメしたい、この1冊」。

エンジニアとして仕事を始めて20年をはるかに超えてしまいましたが、ここ20年、何か仕事をするときに心に浮かぶ言葉がたくさん散りばめられているのが、P.F.ドラッカーの「プロフェッショナルの条件」でした。

おそらく皆さんも名前だけは聞いたことがあると思いますが、ドラッカーといえば、日本の名だたる経営者にも信奉者が多く、経営や社会の行方を大胆かつ説得力をもって著わしてきた経営学者です。著書は、いきおい経営論、マネージメント論そして社会論が多いですが、意外にも自己啓発的な内容もたくさん書いています。

実は自己啓発本はあまり好きではないのですが、紹介する「プロフェッショナルの条件」は、これからのビジネスリーダーといったような人に、どう考え、どう行動し、どう自己実現していくかを、普遍的で本質的な考え方を中心に述べたもので、ここ10年拾い読みですが繰り返し読んでいます。特に専門性の高いビジネスマン、管理職、テクニカルなりーダーにはお薦めです。

過去のドラッカーの著述の中から、自己啓発的なところを集大成したものなので、たくさんある難しそうな彼の著作を読まなくとも、専門家のリーダーシップに対する彼の考え方のエッセンスを一冊でかなり網羅できます。たとえばいくつか私の心に残っている言葉をあげてみましょう。

「上司の強みを生かすことは、部下自身が成果をあげる鍵である。」 - これは20代のときに出会った言葉で、ちょっとした衝撃でした。上司を生かして自分の成果をあげるなんて発想をしたことのない青二才でしたから。でもこれがきっかけで、新しい技術に取り組むとか、自分のチームを作るとか、その後やってこれたのは、うまく上司を使えたからと正直思っています。

「大工と話すときは、大工の言葉を使わなければならない」（ソクラテス引用） - エンジニアでない人たちと会話するとき、常に心がけたことですね。技術は自分は分かっても、相手の分野、レベルに合わせて話さないと通じないことは、みなさんも感じることだと思いますが、心にこの言葉を言い聞かせつつ、上司や役員やお客さまなどと会話しなければと思っています。

「汝の時間を知れ、その結果、誰でも成果と貢献への道をあゆめる」 - 卑近に言えばスケジュール管理。細切れな時間でなく大きな塊の時間をつくって、そこでまとまった仕事をする。それが成果につながると、30代の頃、これを言い聞かせて試行錯誤していました。

「知識ある者は、常に理解されるように努力する責任がある。」 - よく上司や役員がわかってくれない、お客さまが技術をわからない、と嘆きたくなるときもありますが、そんなときその専門知識を理解している自分が、相手に理解されるまで責任があるというのは厳しいながらも、プロの態度として必要だなと反省しきりです。

「成果をあげることは一つの習慣である」 - これは正直、40代ではじめて心底そうだなと思えた言葉です。卓越した専門家には才能がないとなれないかもしれないが、成果を出していける人には、成果を出すための習慣を身につけることでなれるというものです。もっと若いころから気づいていれば、と思う今日この頃ではあります。

ドラッカーらしく第一章が、「ポスト資本主義社会への転換」とややとっつきにくい部分はありますが、それらを飛ばして拾い読みするだけでも、リーダーとして考えさせられることが満載です。

今日は最近のインフラのトレンドに関して気づいたことについて書きたいと思います。企業の外にインフラを置くパブリック・クラウド、そしてやっぱり企業内におくプライベート・クラウド。新しいインフラと言えば、これらが最近のホットトピックではあります。

しかしこれらのトレンドに並行して、最近ハードウェアとソフトウェアを事前に組み合わせたアプライアンスも各社からいろいろ出てきているように思えます。3teraなんかはプライベートクラウドのアプライアンスと呼べそうですし、IBMのCloudBurstもその手のものでしょう。またデータベースとハードウェアの組み合わせでは、OracleのExadataが最近有名かもしれません。またアプリケーションの分野でも、手前味噌ですがIBM Smart Analytics Systemとか。

これはちょうどパブリック・クラウドのIaaS/PaaS/SaaSのようなレイヤーと同じように、ハードに近いプライベート・クラウドのアプライアンスから、ミドルウェア、そしてアプリケーションと上位レイヤーがそろい始めているとも見えるでしょう。

プライベート・クラウドは過去のシステムの、サーバーの統合化、標準化の延長線上でも設計、構築していけるかもしれませんが、その構築を外部からの調達で一気にするとなると、こういったアプライアンスは有効かもしれません。プライベートの各種アプライアンス、パブリックのIaaS/PaaS/SaaSは、ちょうど企業内か企業外かの対称的のようなものにも見えます。

で、ここでこれらのトレンドの共通点は何かといえば、アプリケーションを設計、構築する以前に単独でも動いているということではないかなと思いました。今まで内製でシステムをつくるときは、アプリケーションの設計、構築と同時に、インフラも設計、構築。それが事前にできあがった形で提供されるのが、クラウドとアプライアンスといったインフラの新しいトレンドの共通点と言えるように思えます。

これによって、アプリケーションは自分の都合でインフラの設計を変えることはかなり制約を受けることとなります。特に、インフラのアーキテクチャーや、可用性やパフォーマンスといったような非機能要件は、インフラの制約の中で決まってしまいます。あとはアプリケーションで工夫をしていくしかないでしょう。最近、Google App Engineで企業アプリケーションをつくるには彼らのRDBでないBigTableの上に、どうやって企業データを格納して使うか、という議論があるのはまさにこのポイントでしょう。

そういえば20年以上前のメインフレーム時代を振り返ると、同じようにインフラは、多くの場合、あるアプリケーションの開発以前から他のアプリケーションのために存在していて運用されていました。アプリケーションの都合でインフラを変えることは、同じインフラに同居しているアプリケーションがありますから、かなりの制約をともなったわけです。

歴史は繰り返す。アプリケーションよりインフラの設計が優先という傾向でしょうか。とはいえ、こんど迎えたインフラ設計の優先の時代は、さまざまなクラウド、さまざまなアプライアンスといった多様性のある、おもしろい時代と言えるかもしれません。もちろんアプリケーションの要件が極めてきびしいものに関しては、今までどおりアプリケーションとともにインフラを造り上げるやり方、内製が残りそうではありますが。

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

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

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

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

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

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

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

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

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

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

感覚的議論に陥りやすいパブリック・クラウドのセキュリティー議論ですが、監査役にはこう説明したらという記事を見つけたのでご紹介しましょう。

セキュリティという視点で、クラウドが今までと違うのは、データなどの所有と、そのコントロールを分けた点だというものです。確かに今までは自分のデータは自分が所有して管理することで、セキュリティーが保たれていると主張したりしていました。が、クラウドになると所有自身はクラウド・ベンダーになってしまい、ユーザーとしてはどうコントロールを維持するかが課題です。

セキュリティーが保たれている、コントロールされているということをどう担保するか。それは暗号化といったような技術、そしてSLAといったような契約の二つでそれを維持するという考え方です。

考えてみれば、今までも企業のIT部門はいろいろなものの所有を外に出してきました。給与計算といったバッチ処理などは随分昔から外部委託されていました。こういったものは技術と契約でコントロールするという立場から言えば、暗号化してデータを届け（昔はほとんどしていなかったでしょうが）、守秘義務を中心とした契約でしっかり安全を担保しています。

データセンターのアウトソーシングなども、専用線、センターのセキュリティー技術と対策、そして分厚いSLAの契約の上で、さまざまなシステムを任せるようになりました。また最近ではVPNによって、インターネット上に企業データを流すようにもなりました。これもしっかりした暗号化技術の裏づけ、そして通信キャリアの守秘義務や信頼によるところがあると思います。

こう考えてくれば、クラウドだからといってことさら騒ぎ立てることもないのでしょう。クラウドの特性であるユーザー同士のシステムでの同居によるリスク、インターネット利用のリスクといったものが、いかに技術面で防がれているか。また契約面でそのサービスのレベルと守秘義務がきちんと担保されているかをユーザーとして見極める。こういった一段階レベルの上がった外部の所有を、技術と契約で冷静に評価していけばいいのでしょう。