FC2ブログ

ノックエア@FC2

とあるカラスの邁進記

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

CP>仕組み>応用>SaaS

http://japan.internet.com/webtech/20090116/11.html


クラウドや仮想化などの新技術が攻撃目標になるおそれ
著者Richard Adhikariオリジナル版を読むプリンター用記事を転送
海外海外internet.com発の記事


仮想化やクラウド コンピューティングなど、新技術の人気が急激に高まっている。いずれ分かることだが、その人気の高まり故に、マルウェアの作成者は手を出さずにいられなくなるおそれがある。セキュリティ会社の AppRiver によると、こうした新技術の人気により、2009年はサイバー攻撃が大幅に増加する可能性があるという。

AppRiver の上級セキュリティ アナリスト Fred Touchette 氏は取材に対し、特に企業は、コストを削減して今の不況を乗り切ろうと、これら技術に目を向けているため、危険にさらされる可能性がある、と指摘した。

IT 支出全体の展望は明るくないが、これら技術については2009年に大きく成長する見込みで、その結果、クラッカーにとってもチャンスが巡ってくるかもしれない。

「単に仮想化を用いる企業が増えているという理由だけでも、仮想化に対する脅威は単一の危険要因になる。ウイルスは、仮想マシンに侵入でき、防御壁をくぐり抜けるようになりつつある」と、Touchette 氏は語った。

Touchette 氏によると、一部のウイルスには、仮想環境での存在を表わす捕捉可能な兆候を示すものもあるが、その後実行を停止するか、自らを完全に除去してしまうため、追跡できないという。それは調査アナリストが、ウイルスの分析時に仮想マシンを使っているためで、マルウェアの作者もそのことを知っているからだと Touchette 氏は話す。

クラウド コンピューティングも同様で、採用する企業が増えている。そして企業にとってクラウドは勝手の分からない分野なので、セキュリティを脅かす脆弱性に遭遇する場面が出始める、と Touchette 氏は予測する。

先進機能を搭載したスマートフォンの普及についても、同じことが言えるかもしれない。これらスマートフォンは、開発者にとって、ユーザーが自分の端末にダウンロードできる新たなアプリケーションを作成しやすくなっている。

Touchette 氏によると、企業環境における『iPhone』の人気と、Google が推すプラットフォーム『Android』でのアプリケーション開発の容易さを考えれば、iPhone や Android 端末が大きな攻撃目標として浮上するかもしれないという。






http://www.infoq.com/jp/news/2009/01/virtualization-saas

企業とSaaSの仮想化がもたらすのは、迅速性(アップ)だけではない

作者 Matthew Porter, 翻訳者 編集部 投稿日 2009年1月7日 午前12時56分

コミュニティ
Architecture
トピック
仮想化
タグ
仮想マシン,
Xen,
VMWare

Amazon EC2などのクラウドサービスにより、ITでは仮想化が非常に注目を集めるようになりました。こうしたサービスは利用可能なハードウェア上で新規のバーチャルマシンを迅速に供給するという、仮想化で最も人気のある特徴を土台に築かれてきました。クラウドコンピューティングの核心にある前提は、「極端な容量を備えた大規模インフラ」であり、必要とする組織にそれを販売するのです。小規模システムに必要な個々の断片を顧客に切り売りすることにより、大規模インフラの柔軟性と構造を提供できるのです。
関連情報

セキュアなIT基盤と付帯運用サービス”SecureOnline”

仮想化は人気がある上、プロバイダの容量上で利用可能な余剰部分を使って、ほとんど即時に新規の(仮想)サーバーを供給する能力がありますが、その能力以上に多数のメリットを提供します。仮想化の全体的な価値は、高度の可用性や災害時のリカバリ、アプリケーションの高速供給といった、いっそう複雑なメリットにあります。簡単に言うと、ハイパーバイザー自体がコモディティ〔日用品〕化したのです。ほとんどすべての仮想化プロバイダがコモディティ化の実現を証明しています。Xenハイパーバイザーはオープンソースの自由なコミュニティで開発されました。VMwareがESXiを作り上げたのはつい先ごろ、今月のことですが、ESXiはフットプリントが最小限のエンタープライズ級ハイパーバイザーであり、無料でダウンロードできます。けれども、両製品ラインの複雑な機能は依然として販売用に確保してあります。

この論文では、こうした複雑なメリットと実世界における応用を検討します。さらに重要なこととして、Contegixが複雑な問題の解決に仮想化を実装している方法や、仮想化を使うべきではないケースについて詳細を提供します。


企業:原動力は仮想化

企業を対象とした仮想化の価値を引き上げるのは、迅速な供給というポイントを越えたところに存在する多数の特徴です。最も重要なのはリソースの最大活用、アプリケーションの高い可用性、災害時におけるビジネス継続性です。こうしたトピックはあらゆるCIO(最高情報責任者)やCTO(最高技術責任者)にとって、要件の中心になっています。仮想化の真の力はこうした特徴にあるのです。

クラウドコンピューティングは依然として、あらゆる企業向けに普及している技術デプロイメントプラットフォームというわけではありません。決してそうならない可能性もあります。多数の組織が、そうならないような厳格なガバナンス下に置かれています。コンプライアンスに対する懸念とクラウドプロバイダに対する信頼の欠如が、制限要素として働いています。HIPAA法(Health Insurance Portability and Accountability Act:医療保険の相互運用性と説明責任に関する法律)やサーベンス・オクスリー法(SOX)のような法律の解釈では、法律に準拠しないことによってもたらされる潜在的な負の影響を、ライアビリティとみなすことが多いのです。この件が確実に対処されるまで、クラウドへの全移行は企業にとって難しいでしょう。

だからと言ってそうした組織では、全コンピューティングリソースを完全活用することによる、スケールの柔軟性というメリットを利用してはならない、というわけではありません。その核心にあるのが、専用ネットワークインフラを備えた専用コンピューティングリソース上の仮想化です。要するにこうした企業は、私用のクラウド(もっと正確に言えば、私用のクラウド様式のアーキテクチャ)を構築し、活用しているのです。

VMWareとCitrix XenServerには、利用可能な物理ハードウェアの全リソースを最大化する能力があります。バーチャルマシンのリソース要件と仮想化クラスタ内の物理サーバーの能力との間で、動的にバランスを保つことができます。バーチャルマシンが起動すると、仮想化スタックはバーチャルマシンをリソースとともに、物理サーバーに割り振ります。

ほとんどの仮想化スタックには、アプリケーションの高い可用性を促進させる機能が組み込まれています。この組み込み機能は、Oracle CoherenceやMicrosoft Cluster Serverなどのクラスタ化技術を完全に補完するものではありません。ハードウェアレイヤで発生する障害に対処し、また、こうした機能を持たないアプリケーション向けに高度の可用性を促進するよう意図されたものです。

こうしたアプリケーション向けの高度な可用性は一般に、アクティブ-パッシブ設定の複数ノードを使ってもたらされます。プライマリ-アクティブのノードにサービスの要求を送信することにより、機能します。プライマリ-アクティブのノードが反応しないと、セカンダリノードがプライマリ-アクティブに格上げされ、そこへ要求が送られます。 依然として問題があります -- 元々のプライマリ-アクティブ・ノードに保持されていたインメモリのデータがすでに使えなくなってしまったことです。

この問題は、VMWareのVMotionやCitrix XenServer XenMotionなど、ライブのマイグレーション機能を使って解決できます。VMotionやXenMotionにより、実行中のバーチャルマシンを基本的な物理マシンから別のマシンへと、ディスク上であろうが、メモリ内であろうが、データ損失なしにマイグレーション可能で、ネットワーク接続性やクライアントの損失もありません。こうしたことがなぜ可能かというと、バーチャルマシンの全メモリステートと、正確な実行ステートを、物理マシンから別のマシンへ複製しているからです。バーチャルマシンの設定と全体的なステートは、共有記憶装置スペース上に保存されます。

実行中のバーチャルマシンを搭載している物理サーバーに停電が起こると、仮想化スタックが停電を検知し、2番目の物理ハードウェア上に複製されたバーチャルマシンを起動します。バーチャルマシンのマイグレーションは、実行中のマシンのコア状態(正確な実行ステート、ネットワークID、動作中のネットワーク接続)を保存します。これにより、ダウンタイムゼロのマイグレーションが可能になり、ユーザーへのマイナス影響もありません。

リソーススケジューリングやバーチャルマシンのライブ・マイグレーション、企業ストレージシステムの複製といった機能を組み合わせることにより、ビジネスを継続する能力がもたらされます。バーチャルマシンは、ひとつのバーチャルクラスタから別のクラスタへと、物理的な距離はほとんど関係なく、そして基本的なハードウェアに左右されることもなく、複製可能です。


SaaS:原動力は仮想化

SaaS(Software-as-a-Service)への注目度は高いのですが、市場はまだ完全に成熟していません。これには多数の要因が働いています。いたるところで見られる要因には、開発以外のインフラにかかる立ち上げ費用が、不釣り合いなほど大きな割合を占めるという事実があります。それにもかかわらず、収入を生み出すまでには複数年かかります。それゆえ、最初の顧客で結果を出すには多額の費用を要しますが、その後の顧客については費用がずっと少なくなるはずです。SaaSをデプロイするには一定レベルの一貫性も必要ですが、それと同時に、顧客レベルで修正がきくように十分な柔軟性を保っておくことも必要です。

一般的なSaaSの顧客は、インフラの費用や懸案事項を気にかけません。典型的なSaaSの販売に使用されるのは、どちらかと言えばアメリカン・エクスプレスの法人カードですが、企業内部のソフトウェア購入にはCレベルの重役(編集部注:CEOやCIOなど、頭にC〔Chief〕がつく役職)の承認が多数必要になります。そのため、SaaSベンダーは値頃感を越えない価格に留めておく必要がありますが、それは初期インフラ費用の素早い相殺とは反対の行為に当たります。ハードウェア機器の購入だけにとどまらず、インフラには提供中のアプリケーションのデプロイメントやサポート、管理、メンテナンスに関わる長期的に継続する費用が含まれます。

インフラとデプロイメントを越えたところに焦点を合わせると、SaaSアプリケーションプラットフォームでは再現性を中心に考えるべきです。 SaaSによって提供されたアプリケーションのあらゆるインスタンスは、他のインスタンスとほぼ同一である必要があります。顧客毎のアプリケーション・インスタンスの振る舞いに一貫性を持たせるため、さらに、同一のトラブルシューティング基盤からサポートを始められるようにするためには、相違を最小限にとどめる必要があります。そうしないと、次のようなことがあり得ます。単一の顧客インスタンスにApacheモジュールが欠けていたことが問題の原因だった -- こんなことを発見したいサポート・エンジニアなどいるでしょうか。あるいは -- SaaS企業が全オーダーの各段階を正確に再生できないため、注文したアプリケーションの各インスタンスに問題が発生する可能性がある -- 顧客にしてみれば、いい迷惑です。最後にきてさらに複雑性を追加するのは、一貫性と費用の理由から、全プロセスを自動化する必要性です。

(重要な例外があり、その中にはアプリケーションデータ、デプロイメント・インスタンスデータ、スケーラビリティ用の潜在パラメータなどがあります。しかしながら、こうしたものはアプリケーション向けのメタデータやユーザーデータに過ぎません。別の顧客にアプリケーションを再供給したい場合は、こうしたデータはほとんどの場合削除され、白紙の状態からのスタートになります。)

それでは、こうした一貫性が問題となるのはなぜでしょう。SaaSアプリケーションでも従来のアプリケーションでも、現在のアプリケーションにおけるデプロイメントの複雑性を理解することが肝要です。最も単純なWebアプリケーションでさえ、裏に潜むデータストア・レイヤの管理は、もはやアプリケーションの責任ではありません。この責任はデータベース、一般にはMySQL、PostgreSQL、Oracle、SQLサーバーなどのRDBMSに委譲されたのです。JavaやRailsなどの典型的なWebスタックと組み合わせると、スケーラブルなデプロイメントが必要な多層のアーキテクチャがもたらされます。たとえば、RailsアプリケーションにはApacheやMongrelクラスタ、memcache、MySQLが必要かもしれないのです。

対処すべきデプロイメント問題は、アプリケーションの初期インストレーションならびに、アプリケーション・インフラを全体的に接続することだけではありません。アプリケーションコンポーネントに異なるリソースが必要なことが多々あります。様々なコンポーネント専用に特別なリソースを提供し、その可用性や一貫した振る舞い、枯渇の阻止を確実にすれば、有益なことがしばしばあります。たとえば、MongrelクラスタもしくはTomcatのインスタンスには決まった量のCPUとRAMの割り当てが可能ですが、依存しているデータベースには別の要件があります。これは、1つのサービスが別のサービスを枯渇させてしまうことを阻止する上で役立つでしょう。

さらに、アプリケーションのアジャイルな特性により、簡単に拡張できますが、その際はプラグインやマクロ、マッシュアップを介することがよくあります。より小さなインスタンス向けに開発されたエクステンションは、あらゆる組織のレベルに応じてスケールしない可能性があります。一顧客(もしくは、アプリケーション・インフラのスタックを共有している顧客グループ)のアプリケーションスタック内で問題が発生すると、目標は、違反システムを回避して、他に対する潜在的な影響を最小限にとどめることです。SaaSの顧客は、他の顧客が原因でリソースを制限する状況が起こり、そのせいで自分の問題が発生したなどとは、聞きたくもありません。

この要件を満たす方法はいくつかあります。インフラに関しては、クラウドコンピューティング的な見地からハードウェアの問題に取り組むことであり、仮想化技術を使用したインクリメンタルなスケールが可能になります。同時に、デプロイメント、サポート、メンテナンスを管理する上でも、役立つことが分かります。物理ハードウェア側のデプロイメントの一貫性については、CfengineやPuppetのようなツールを利用できます。リソースの制約は、 /etc/security/limits.confを介して、Solaris zonesやLinux PAMなど、動作中の特定機能を使って適用できます。非常に素晴らしいツールです。それでも、仮想化を利用してこうした問題に取り組めばもっと良い方法があり、固有のメリットを多数もたらします。仮想化により、コンピュータサイエンスに「関心の分離」というコア概念を実装することができるのです。

関心の分離は、アプリケーションを「機能面において可能な限り重複がない、複数の明確な機構」(Wikipediaから引用)に分割する前提となります。仮想化を使えば、この概念をインフラに適用できます。各アプリケーション、各顧客、各クラスタベースで、関心の分離を適用可能です。ですから、水平および垂直にスケールする能力を提供しながら、それと同時に基礎をなしているハードウェアの限界まで、依然としてフル活用しているのです。これはSaaS 市場へ参入させたいと思っているシングルテナント・アプリケーションに特に有益です。ほとんどコードを変更することなく、基礎をなしているハードウェア上で即時にマルチテナント化できます。

ContegixのSaaSプラットフォーム上では、デプロイされた一般的なデプロイメントモデルが2つあります。両者を区別する要因は、アプリケーションの開発方法がらみであることが多く、デプロイメント毎に一顧客をサポートするか、あるいは単一デプロイメント上で複数の顧客をサポートするかということです(シングルテナンシー対マルチテナンシー)。

単一顧客のSaaSデリバリでは、限定数のバーチャルマシンを利用して顧客アプリケーション・インスタンスをデリバーします。わずか1基か2基のバーチャルマシンに限定されることが多々あります。たとえば、1基のバーチャルマシンがWeb階層からデータベース階層を介してアプリケーション全体をデリバリ可能ですし、あるいは、別々のマシン2基に分け、各自のレベルでスケーリングすることも可能です。仮想化のリソース割り振り能力を使えば、追加の CPUコアをPostgreSQLバーチャルマシンに素早く追加できます。動的リソース配分により、必要とされるリソースを持っている物理マシンに、バーチャルマシンを素早く移動することができます。

もう一つの一般的なデプロイメントモデルは、より高度の分離を提供するものです。基礎をなしているインフラ・アプリケーションは複数のバーチャルマシンに分離され、各自必要なレベルにそれぞれスケールされます。たとえば、 PostgreSQLデータベース、Javaの様々なWebアプリケーション向けのTomcatコンテナ2個、 Rails Webアプリケーション用のMongrelクラスタという構成のアプリケーションは、各コンポーネントに別のバーチャルマシンを用意するように設定することも可能です。シングルテナントの例を越えたところでは、バーチャルマシンのリソースとインスタンス数という点から見て、個々のコンポーネントのスケーリング以上のことが可能になります。nginx(もしくはApache)によるプロキシを介してラッピングされたWeb階層はすべて、フロントエンドの顧客に見える変更は皆無で、シームレスな移行を提供します。多数のマシンによるファイルレベルのデータアクセスは、ネットワークの共有か、クラスタ化されたファイルシステムを介したブロックレベルの機器で実現します。再度申し上げますが、このモデルは大量のインスタンス、あるいは複数顧客のアプリケーションに大変有用です。

デプロイメントモデルに関係なく、OSとアプリケーションのインストールをアプリケーションデータから分離させることが非常に重要です。次は、アップグレードのプロセスや処理方法が話題になります。OSとアプリケーションのインストールは、いつでも新しいコピーや新バージョンで置き換えられる、揮発性のデータとみなすべきです。アップグレードではまさにこの方法を使って処理します。こうしたパーティションの新バージョンは、アップデートされたOS、アプリケーション、コンフィギュレーションによってオーバーレイされます。デリバリする成果物はアプリケーションですが、デリバリのメカニズムの方がずっと大規模であることをさらに物語っています。

アプリケーションをデリバリする力として、仮想化を活用することには、本質的なメリットがあります。バーチャルマシンを1つの物理マシンから別の物理マシンに移動するという仮想化の特徴について前述しましたが、これは重要なメリットです。PAMなどの物理ハードウェアソリューションでは、ユーザーデータの移動と、ホストのOSレベルにおけるコンフィギュレーション・ファイルの同期が必要になるでしょう。さらに、サンドボックスとしてバーチャルマシンを素早く構築、展開、テストし、また、標準ツールを使って比較することも可能です。UNIXコマンドの「diff -r」とMF5のチェックサムを2つの異なる画像で実行する様を想像してみてください。


仮想化がニーズを満たさないケース

新しい流行語がついたあらゆる概念がそうであるように、仮想化についても人々は、新旧ひとくくりにしたあらゆる問題を仮想化が解決してくれる、と考える傾向にあります。現実はというと、仮想化がすべてのシステムとアプリケーションに有効というわけではありません。アプリケーションによっては、必要とするリソースが高度すぎることもあります。大規模なデータベースサーバーや集中的なUDPネットワークのような、高度のI/O環境で最もよく見られるケースです。

簡単に言うと、何度も繰り返しテストすることです。

著者について:

Matthew E. Porter氏はContegix LLC社の最高経営責任者です。Contegix設立前は、Contegixの親会社であるMetissian LLC社を共同経営していました。セントルイス大卒(コンピュータサイエンスの理学士号を取得)。



原文はこちらです:http://www.infoq.com/articles/virtualization-saas
(このArticleは2008年8月31日に原文が掲載されました)
スポンサーサイト
  1. 2009/01/24(土) 06:56:51|
  2. CP>仕組み>応用>
  3. | トラックバック:0
  4. | コメント:0

CP>仕組み>基礎>SaaS

■SaaSは無視できない動向

 「SaaS」(Software as a Service:「サース」あるいは「サーズ」と発音されます)が注目を集めています。SaaSとは、ソフトウェアをユーザー側に導入するのではなく、ベンダ(プロバイダ)側で稼働し、ソフトウェアの機能をユーザーがネットワーク経由で活用する形態を指します。米セールスフォース・ドットコムなどの SaaS専業ベンダが急成長しており、さらに、SAPやオラクルなどの従来型のソフトウェア・ベンダもSaaS型のビジネスに乗り出しています。ほとんどの企業にとってSaaSは無視できない動向といえるでしょう。

SaaSの定義:ASPとはどこが違う?

 簡単にいってしまえば、SaaSとは「ソフトウェアの機能をネットワーク経由で利用する」という形態です。下図に示すように、IT機能のうちどこまでを自社で行い、どこまでを社外に任せるかという観点でSaaSを位置付けてみると分かりやすいでしょう。過去においてはすべてのIT機能を社内で実行する「インハウス型」のモデルが通常でしたが、今日においては必要に応じて特定機能を社外の専門家に任せるモデルが一般化しています。例えば、施設からビジネスプロセスまでをすべて社外に任せるモデルは「BPO」(Business Process Outsourcing)と呼ばれます。SaaSはソフトウェアの稼働までを社外に任せるモデルであるといえます。

 通常、SaaSでは、ユーザー数に応じた従量制の課金モデルが採用されます。電気や水道などと類似の課金モデルであることから、「ユーティリティ型料金」と呼ばれることもあります。

 ここでよく聞かれる質問に、SaaSと「ASP」(Application Service Provider)のモデルとどこが違うのかというものがあります。ベンダ側ではさまざまな説明をしているようですが、あまり本質的な相違はないというのが正直なところでしょう。両者の違いを厳密に議論しても実りは少ないと思います。「SaaSは過去におけるASPと本質的には同じではあるが、その重要性が飛躍的に大きくなっていることから、マーケティング的な観点で新しい名称で呼ぶことにしました」というのが妥当なところでしょう。

ユーティリティ


SaaSとSOA:「サービス」という言葉の意味

 SaaSと「SOA」(Service- Oriented Architecture:サービス指向アーキテクチャ)は、どちらも「サービス」という言葉が使用されていることから、その位置付けが混同されることがあります。しかし、実際には両者は関連してはいますが、全く独立した概念です。一般に、ITの世界では「サービス」という言葉はさまざまな意味で使われていますので注意が必要です。

 SaaSにおける「サービス」とは「ソフトウェアの機能」というニュアンスの言葉です。ソフトウェアそのものではなく、機能を(ネットワーク経由で)提供するというイメージです。一方、SOAにおけるサービスとは「業務上のサービス(労務)を実現するためのソフトウェア部品」というニュアンスの言葉です。サービスと呼ぶよりもビジネス・コンポーネントと呼んだ方が分かりやすいかもしれません。

 SaaSとSOAは異なる概念ですが、両者が将来的に融合していくことは十分考えられるシナリオです。現時点のSaaSではアプリケーション・ソフトウェアの機能が丸ごとネットワーク経由で提供されるのが普通です。しかし、アプリケーション内の特定機能をネットワーク経由で提供し、ユーザーのインハウスのシステムと統合して使用したり、複数のSaaSプロバイダが提供するソフトウェア部品をユーザーが自由に組み合わせて使用することが当然考えられます。このような形態はSOA的なSaaSと呼ぶことができるでしょう。

 今日においても、SaaSベンダが自社のソフトウェアに対する外部インターフェイス(外部との接続)の切り口を用意することが多くなっており、SOA的なSaaSが一般化の兆しを見せています。

5min_saas_02.gif


SaaSのメリット:最大の利点は俊敏性にあり

- PR -

 SaaS採用の最大のメリットは俊敏性にあるといえるでしょう。つまり、スピードです。極端なことをいえば、申し込んだその日からシステムの機能を利用することができます。これに対して、インハウス型のシステムでは実装までに少なくとも数カ月の期間を要することがよくあります。

 また、SaaSではシステムが稼働開始した後の環境の変化にも迅速に対応することができます。業務拡大によりユーザー数が増加した場合、あるいは、予測よりも需要が低くユーザー数が減少した場合にも迅速に対応することができます。料金は通常従量制なので使用した分だけ支払えばよいわけです(ただし、ユーザー数が減少した場合は契約上何らかの制限があることもあります)。インハウス型のシステムでは、マシンの調達などの点で処理能力の急増に迅速に答えることは難しいですし、需要が予測より小さかった場合にはハードウェア料金の無駄が発生することになってしまいます。

 コストについてはどうでしょうか? SaaSの方が有利なケースが多いですが、場合によるといっていいでしょう。SaaSでは通常、初期コストは安価に済みますが、その後は継続的に料金を支払う必要が生じます。一方、インハウスのシステムは導入までには多額の費用が掛かりますが、サービスイン後のコストは比較的低く済みます。故に、システムのライフサイクルを考えた総合的なコストの比較が必要です。なお、インハウス型のシステムではシステムの運用コストや設置スペース、電源、空調などの環境コストも含めてSaaSとの比較を行うべきなのはいうまでもありません 。

5min_saas_03.gif


SaaSの考慮点:大幅なカスタマイズは無理

 もちろん、SaaS採用のうえでの考慮点はあります。SaaSでは、ベンダが提供するソフトウェアを基本的にはそのままで利用することになります。ベンダの開発努力により、過去と比較してSaaSのカスタマイズ機能は大きく向上していますが、それでもインハウスの形態と同じように自由な機能拡張を行えるわけではありません。また、自社内の既存システムとの連携という点でもインハウス型のシステムが有利です。これは当然のことでしょう。

 本当に自社独自のソリューションが必要なのであれば、SaaSは不向きです。ただし、ここで、本当に自社独自のソリューションが必要なのか(無理に他社と違うことをやろうとしているだけではないのか)という点については、十分に検討を行う必要があるでしょう。

 もう1つ、サービスレベルに関する考慮点があります。この場合、サービスレベルとは主に性能と可用性(アップタイム)のことを指します。もちろん、 SaaSベンダは問題がない性能と可用性を提供するために努力はしているのですが、実際にどのレベルまで保証してくれるのか、また、万一障害が発生した場合にはどのように補償されるのかについては十分に検討を行っておく必要があるでしょう。もちろん、インハウスのシステムにおいてもサービスレベルの検討は必要です。しかし、SaaSの場合には社外との検討が必要であるという点に留意しておくべきです。


SaaSは将来どうなる?

 SaaSが今後順調に拡大していくことは間違いありません。これは、ITに限らずすべてを自社でやるのではなく、必要に応じて外部の専門家に任せるという考え方が常識化していることから、当然のことといえます。

 しかし、前述のようにSaaS方式と自社内にシステムを抱えるインハウス方式にはそれぞれ一長一短があります。故に、ほとんどの企業ではSaaS方式とインハウス方式が共存していくことになるでしょう。それほど差別化が必要でないシステム、迅速な立ち上げが必要な短期戦術的システム、試験的に稼働してみるシステムにおいてはSaaS方式が中心となることが多いでしょう。また、企業の差別化に直接結び付くシステムや絶対的な安定稼働が要求されるシステムでは、インハウス方式が今後も利用されていくことになるでしょう。

 具体的にどのシステムをSaaS化すべきかは、企業により異なります。これは、どのシステムを差別化要素とするかは企業の経営戦略に直結する問題であり、1つの定まったやり方があるわけではないからです。


  1. 2009/01/24(土) 06:51:05|
  2. CP>仕組み>基礎
  3. | トラックバック:0
  4. | コメント:0

ニコニコ動画の強み

動画の強み
1番目はチュートリアル、2番目は機能紹介、3番目は完全なプロモーションですが、やっぱり動画だとわかりやすいですね。僕も初めてブログに動画を張ってみましたw(今までやり方を知らなかった)。ちなみにこのエントリ、touchで見ると、ちゃんとページ上に動画が表示されて、タッチするとそのままプレイヤーが起動して、動画が見られるのねw いやー21世紀って感じです。今は写真ですが、そのうちウェブのニュース記者がビデオカメラを持って、切り替えながら取材する時代が来るかもしれないですねー。写真は一覧性が高くて、動画は内容がよくわかるという、互いの長所/短所がありますから。はっ! そのためのデジカメの動画撮影機能かw 端から見てると写真を撮ってるのか、動画を撮ってるのか、ホントにわからないですよね。

>記者の衰退>素人とでもできるようになってしまった>個の知識を増やす必要性
>個のモラル>世間で身につけてゆくもの
         >個の立ち位置をはっきりさせてやること←インターネットの世界は
          地に足がつきづらいのかもしれない。
>個の立場の安全を保障

>音が聞こえなくても、点字などでそれを表記してゆくことでニュースを読んでもらえる。









“ギャルゲー3D仮想世界”を生活の拠点に――ドワンゴの戦略 (1-2)
- ITmedia News


http://ameblo.jp/secondlife2/entry-10087593046.html

secod lifeが失敗したのは、「社会参加」の敷居が高い点である。
そして、心理的に重要な事は、

インターネットで「大勢力」である、
男性のオタクを取り入れる事に失敗した点である。
また、2ちゃんねるユーザーのような
「変態ロリコン気質」や「引きこもり社会不適切者」を
取り入れていない。


現在のsecond lifeでは、非常にまともな人達が運営・管理しているし、楽しんでいる人の多くは、若いまともな女性が大半を占め、情報は、ファッション情報がほとんどでる。一部には、面白い「変態」も多く参加しているが、とうてい「カオス」という状態はゼロに近く、男性オタクが満足する仮想世界ではない。


そんな中、ニコニコ動画を運営するドワンゴが、美少女ゲームやアキバ系を主体とした仮想世界構築を展開する予定だ。

まず、優れている点が、オープンID戦略である。

引用
-----
ドワンゴが「ニコニコ動画」で培ってきたコミュニティー運営のノウハウを投入。ユーザーがコミュニティーに参加しながら、その世界を“創る”感覚を持てるよう配慮する。IDはニコニコ動画と共通にし、ネットに“住む”ユーザーに、ニコニコと3D仮想空間という、性質の異なる2つの居場所を提供する。
-----

ニコニコ動画のIDを共通化し、参加の敷居を低くする。
そのため、構築した時点で、数十万人の参加が「約束」されている状態となる。
ニコニコ動画で培った「変態コミュニケーション力」を参加時点で発揮させるかをポイントにおいている。



そして、そのキャラクター世界観として、

引用
-----
ゲームメーカーを子会社に持ち、「ニコニコ動画」などでPCサイト運営のノウハウも身につけてきたドワンゴと、MMORPGなど多くのオンラインゲームを開発してきたヘッドロック、美少女ゲームメーカーのビジュアルアーツ、サーカス、美少女ゲームのカードなどを販売してきたブシロードが製作委員会に参加した。

 ドワンゴがインフラを、ヘッドロックがゲームシステムを、ビジュアルアーツ、サーカスが元となるゲームの世界観を提供し、ブシロードが美少女ゲームの版権獲得や、プロモーションのプロデュースなどを行い、5社で収益を配分する。オメガビジョンはライセンサーとしてコンテンツを提供する。
-----

とても優れた判断である。
初音ミクや、その他のアキバ系ロリコンアニメや、変態美少女ゲームを分析すれば、何がネットユーザーの中で期待されているかわかる。そして、2ちゃんねるユーザーやニコニコ動画ユーザーが、どんな指向性があるかを分析した時点、何がブレークするかも自然とわかる。

second lifeの悪い点は、参加した時点で、まともな「社会人」が上位を占めた点である。
そのため、企業参加(上場企業級)は「安心」して参加出来たが、真のユーザーであるネットユーザーの取り込みには失敗した。その点、今でも、この傾向は強く、参加している人が
・まともな常識人
・ファッションに関心が高い女性ユーザー
・男性でも、ちゃんと挨拶が出来るユーザー
など、コミュニケーションとしての敷居が高い。


この点についても、ドワンゴ側の太田副社長が、

引用
-----
ai sp@ceのSecond Lifeとの違いは「徹底したセグメント化に尽きる」と太田副社長は言う。美少女ゲームファンに特化することでユーザー層を細かく限定。結果的に女性を切り捨て、マーケットも30万人程度とみるが、それだけ濃いコミュニティーが構成できると展望する。
-----

2ちゃんねるユーザーやニコニコ動画ユーザーのような
・変態ロリコン気質
・引きこもり社会不適切者
をメインターゲットとして「成功」を目指す戦略である。
そうなると、当然、「女性は切り捨てる」という表現が出てくる。
とても優れた判断である。
どう考えても、ファッションに強い興味があるような若い女性と「リンク」するような感じはない。
実際にsecond lifeでも、この傾向は顕著であり、全くリンクが無い。



さて、仮想世界構築であるから、方向性は同じ

引用
----
・それぞれのゲームの世界観を1つの「島」で再現する仕様。島は、1つ当たり2000万円程度で構築
・ユーザーが美少女キャラ(「キャラドル」と呼ばれる)の動きやせりふを自由に作ったり、キャラを使った動画やゲームを作成することも可能
・衣装やアイテム、モーション(キャラドルのしぐさ)の販売も行う。価格は1つ100~500円程度にする予定
・好みのモーション(しぐさ)を、購入したり自分で設定したりできる
----

second lifeユーザーからすれば、「入門編」であり、レベル3程度の仮想世界。
当たり前すぎて、逆に笑える低レベル。



しかし。
問題は、この点ではない。
問題があるとすれば、いかに広めるかである。
その点は、second lifeの何億倍の速度で広まる可能性が高い。
その例として、ニコニコ動画でアップされたsecond life動画を紹介。






どちらも、だいぶ昔であるが、完成度は、ニコニコ動画の「職人」と比べると低すぎる。
このため、あっという間に追いつかれ、あっという間に先に進むであろう。



ただ、将来的な事を言えば、小学校を卒業した中学生が、また小学校に行かないように、ドワンゴの仮想世界で慣れたユーザーが、そのまま「低レベルな仮想世界」でいるとは限らない。そうなると、もう少しレベルが高く、自由度が高い仮想空間へと流れるのは、とても自然である。

そうなると、second lifeのような本当の意味での競争空間が、断然有利となり、second lifeの価値を飛躍的に上げる事にもつながる。

  1. 2009/01/24(土) 02:46:10|
  2. 未分類
  3. | トラックバック:0
  4. | コメント:0

<仕組み>IZAにおける多角性補助機能

インターネットとニュースの可能性。

新聞社やニュースの広告サイト
IZA
ニュースサイト側は記事というコンテンツの提供をする。

ユーザー
ニュースサイト側から与えられた情報をもとにしてブログ等の記事を書け、意見を交換できる。

ここから活発なコミュニケーションを生み出すわけだが、
はたしてこれだけでいいのだろうか。
文面や

クライアントが産経新聞だっただけにこの壁を越えることはできなかったようだが、
実際にはニュースの形にしても様々なファクターがある。

映像、音声、文面等だ。

IZAで扱われているのは記事とそれを個々に書いたブログの記事のみ。
しかもそのニュースサイトは、さながら今までのものとは変わらない。
トラックバック機能などで人は他人の記事と比較したりする事を簡単にすることを覚えた。
その周りの背後関係や、他紙、外国からの見方など様々に他の方法があるはずである。

ニュースサイトの意味は何だろうか。

人間は現在起こっていることや、新しい物事を覚えることで快感を覚えたり、更に貪欲に知識を埋め込んでゆこうとする。他人とのコミュニケーションをする上でも重要な要素ではある。
明るいニュースや暗いニュースといったものに対する人の考え方を反映させた、個々人向けのれレコメンド。
例えば、明るいニュースならば、その明るい話題に対応するものをレコメンドとして与えたり。
暗いニュースを深く掘り下げてゆきたいのであれば、それに関連することを挙げてゆく。
専門知識を知りたい人もいるだろう。そのために必要なホームページや動画へ飛ぶことを許す事ができれば、人は多角的に物事を見ることができると思う。

必要なことは、

現在は文面だけではあるが、
もっと単純に図式化
    A
    ↓
D→ニュース←B
    ↑
    C

といった具合に、何が何を支えていそうなのかという積み上げ式のイメージ。

または

ニュース→ニュースB

のような具合に連動させてゆくことが必要だと思われる。
  1. 2009/01/24(土) 02:26:24|
  2. <アイディア>web関連
  3. | トラックバック:0
  4. | コメント:0

公取委がアニメ産業の実態調査報告、「製作委員会方式」にも言及

 公正取引委員会は23日、「アニメーション産業に関する実態調査報告書」を公表した。アニメ作品の企画・制作は転々と再委託が行われる多層構造であるとともに、小規模事業者が多いことから、独占禁止法(優越的地位の濫用等)や下請法の観点から取り引き慣行に問題がないか調査し、課題の指摘と提言を行っている。

 調査は、2007年11月から2008年12月まで実施。制作会社553社に対してアンケートを送付し、114社から有効回答を得たほか、テレビ局やDVD販売会社、関連団体など44社・4団体にもヒアリングを行った。


● 取り引き条件への認識、発注者側と受託者側で大きな差
 アンケートに回答した制作会社のうち62.8%が資本金1000万円以下の小規模事業者だった。同じくアンケートに回答した制作会社のうち、専ら元請け受注のみ行っているのは28.9%で、専ら下請けの立場の会社が39.5%、元請け・下請け両方の立場の会社が31.6%だった。制作会社の約7割が、アニメ作品の制作を他から再受託していることがわかった。

 さらに、十分に協議することなく発注者から低い制作費を押し付けられた経験があると回答した制作会社が4割を超えたという。一方で、テレビ局へのヒアリングでは、「制作会社から見積りを取って十分な話し合いを行い、制作費を全額支払うようにしている」「アニメ制作にかかる経費は全額負担している」といった回答のほか、一部には「制作者側に制作委託をしているのではなく、放映権を購入しているにすぎない。したがって、当社が支払う費用は、放映権に対する対価であって、制作費に対する対価ではなく、制作費がいくらかかるかは知らないし、DVDの販売促進を期待する制作者側からどうしてもテレビ放映してほしいとお願いされる場合には、交渉次第では、支払う対価がゼロになることもある」との回答もあったという。

 公正取引委員会では、発注者と受託制作会社の間には、取り引き条件について十分な協議を行ったかどうかの認識に大きな差があるとし、取り引き条件の改善のために十分な協議を行う努力を求めている。

 なお、元請け制作会社に対するヒアリングでは、制作費が安すぎることへの不満が目立ったというが、後述する「製作委員会方式」の受託については、「作品の制作に当たって、赤字で受注することはない。必要な制作費は全額製作委員会から支払われている」「製作委員会に出資した経験などから得た印象として、現在の制作費は上限に近いと感じている」など、満足している回答が目立ったという。

jftc1.jpg

■ 下請け制作会社からは「二次使用料の話はタブー」との声も

 著作権の帰属や二次利用のあり方についても言及しており、制作会社へのアンケート調査では、収益の配分方法について元請け制作会社の不満が目立ったという。

 報告書によれば、アニメ制作の発注方法は、

1)テレビ局が元請け制作会社に直接委託する「従来方式」、
2)テレビ局やDVD販売会社、玩具会社、出版社、元請け制作会社などの関係者が出資して「製作委員会」を組織し、製作委員会から元請け制作会社に発注する「製作委員会方式」

――があり、現在は「製作委員会方式」が主流だという。

 まず、著作権の帰属については、発注者(テレビ局)が単独で所有し、受託制作会社側が全く著作権を有しない割合は、「従来方式」が53.7%、「製作委員会方式」が76.5%、制作会社からの再受託が92.6%だった。再受託では、受託制作会社が著作権を有しない場合がほとんどであり、「製作委員会方式」や「従来方式」の元請けでさえ、受託制作会社に権利が残らない場合があることもわかった。

 二次利用収益の配分については、「製作委員会方式」では元請け制作会社の88.2%が配分を受けていると回答したが、「従来方式」では 46.3%にとどまり、さらに制作会社からの再受託においては、配分を受けているのはわずか6.2%だった。特に再受託では、配分に関して「全く交渉していない」とする制作会社が64.2%あり、「制作会社からの下請けの場合、二次使用の話はタブーとされており、要求することすらできない」との回答もあったという。

 このほか、二次利用の許諾や二次利用料の徴収を行う窓口業務の主体をテレビ局が行うことを一方的に要求したり、二次利用料の中からテレビ局が受け取る「局印税」が高額であることなどの指摘もあったとしている。

 公正取引委員会では、著作権の帰属などを協議するにあたっては、「アニメ制作者のアニメ作品に対する創作意欲を刺激し、質の高いアニメ作品を生み出すインセンティブがもたらされるとともに、二次利用が活発に行われるようになるかどうかという視点が重要」とコメント。また、「アニメ制作の委託取り引きが適正に行われるよう、引き続きその取り引き実態について注視していく」と述べてる。

http://internet.watch.impress.co.jp/cda/news/2009/01/23/22196.html


テーマ:これでいいのか日本 - ジャンル:政治・経済

  1. 2009/01/24(土) 01:53:17|
  2. <仕組み>アニメーション
  3. | トラックバック:0
  4. | コメント:0

語句デカルト的な

創発
還元主義

様々なものは階層構造を持ち、(還元主義によって得られる)下層要素の情報だけでは、上層や全体の振る舞いが予想できないことが後にはっきりと認識されるようになった。そのような現象は「創発」と呼ばれている。

  1. 2009/01/08(木) 18:02:22|
  2. 語彙
  3. | トラックバック:0
  4. | コメント:0