タグ

cloudに関するmarblejenkaのブックマーク (87)

  • Google Code Archive - Long-term storage for Google Code Project Hosting.

    Code Archive Skip to content Google About Google Privacy Terms

  • 【クラウドコンピューティング】 2009年振り返りとクラウド事例と記事のまとめ

    今年はクラウドが普及した1年だった 2009年もあとわずか、ということで、今年一年を振り返ってみたい。まずは年初に書いた「クラウド予想2009」についてから。 このなかでいえば、「クラウドを利用したWebサービス」は思ったほど出なかった。「Google Appsの一人勝ちだが一般的には広がらない」は、4月にGAE/Jが登場してからは圧倒的だったと思う。(まあ、まだ開発者中心ではあるが) 予想外だったのは、事例が出てくるのが非常に早かったこと。クラウドが流行るのはまだ先の話で、事例は当分出ないだろうと思っていたので、正直、そのスピード感には驚かされた。私自身、最初にクラウドに衝撃を受けたのが2008年の5月頃(※)だったので、それからまだ2年も経っていないことを考えると、当にもの凄い広がり方であった。どれくらい凄かったか、以下の事例を見ていただくとよくわかるだろう。 (※ 私はこの記事を見

    【クラウドコンピューティング】 2009年振り返りとクラウド事例と記事のまとめ
  • GridGain — Extreme Speed and Scale for Data-Intensive Apps

    GridGain is a Unified Real-Time Data Platform by the original creators of Apache Ignite. It enables a simplified and optimized data architecture for enterprises that require extreme speed, massive scale, and high availability from their data ecosystem. Flexible memory-first / disk-second architecture minimizes disk I/O to provide ultra-low latencies across transactional, streaming and analytical p

    GridGain — Extreme Speed and Scale for Data-Intensive Apps
  • ConsistentHashing - コンシステント・ハッシュ法

    ConsistentHashing - コンシステント・ハッシュ法 目次 この文書について コンシステント・ハッシュ法 実例 実装 用途 コンシステント・ハッシュ法 この文書について "Tom White's Blog: Consistent Hashing" の日語訳です. http://weblogs.java.net/blog/tomwhite/archive/2007/11/consistent_hash.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 原文のライセンス: http://creativecommons.org/licenses/by-nc-sa/2.0/ 私は今までに何度かコンシステント・ハッシュ法にとりくんだことがある。 このアイデアをあらわした論文 ( David Karger らによる Consistent Hashing and R

  • Low-Layer Hacks: P2Pアルゴリズム毎のメリット/デメリット

    2009-10-10 P2Pアルゴリズム毎のメリット/デメリット Winny裁判で金子氏に無罪判決が下り、P2Pを実装したアプリケーションは今後増えてくると予想される。そこで、技術者向けにP2P構造化オーバーレイネットワークのアルゴリズム毎におけるメリット/デメリットを簡潔にまとめ、実装にあたり必要となるであろう参考資料を示した。 ・Chord DHT(分散ハッシュテーブル)の一種であるこのアルゴリズムはConsistent Hashingをベースとしており、名前の通り、分散されたコンピュータ間にハッシュテーブルを構築する。このアルゴリズムは多くのシステムに採用されているのでとても信頼性が高く、実装も容易である。 ただ、愚直な実装では耐障害性が低くなるので注意が必要だ。UnbreakableなChordを提案した論文もあるようなので、そういう文献も参考にすると良いかもしれない。 参

  • 分散ハッシュテーブル - Wikipedia

    分散ハッシュテーブル (英: Distributed Hash Table, DHT) とは、ハッシュテーブルを複数のピアで管理する技術のこと。2001年に発表されたCAN, Chord, Pastry, Tapestryが代表的なアルゴリズムとして挙げられる。 アドホック性とスケーラビリティの両立を目指す探索 (lookup) 手法で、コンピュータネットワーク上に構築されることから、オーバレイネットワークの一つといえる。 アドレスとコンテンツのハッシュ値を空間に写像し、その空間を複数のピアで分割管理することで、特定ピアに負荷が集中することなく大規模なコンテンツ探索を実現する。 DHTはサーバの集合により構成され、主な機能はハッシュテーブルと同等である。あるキー(ビット列)をハッシュ関数、あるいは何らかの直線化関数により論理的な空間の1点に射影し、射影された点に値を関連づけることを特徴とす

  • IT news, careers, business technology, reviews

    Heads on: Apple’s Vision Pro delivers a glimpse of the future

    IT news, careers, business technology, reviews
  • Bluehost.com

  • Google社の基盤技術「MapReduce」についてエンジニアに聞く

    Google社の基盤技術MapReduce」についてエンジニアに聞く 米Google Inc. Christophe Bisciglia氏 米Google Inc.で大規模並列プログラミングの教育コース「Academic Cluster Computing Initiative(ACCI)」の立案者であるSenior Software EngineerのChristophe Bisciglia氏に,インタビューする機会を得た。Bisciglia氏は現在,中国・上海でサービスの開発に携わっている。 ――Googleのサービスを支える技術として,ACCIで教えているのは何か。 Christophe Bisciglia氏 並列処理のプログラミング/モデルである「MapReduce」と分散ファイル・システムである「GFS(Google File System)」だ。これらを実装した「Hadoop

    Google社の基盤技術「MapReduce」についてエンジニアに聞く
  • BrewersCapTheorem - ブリュワーの CAP 定理

    BrewersCapTheorem - ブリュワーの CAP 定理 目次 この文書について ブリュワーの CAP 定理 - Amazon と eBay のクールエイド ブリュワーの(CAP)定理 一貫性 (Consistency) 可用性 (Availability) 分割耐性(Partition Tolerance) 定理の重要性 図解で証明 CAP と折り合う 1. 分割耐性を諦める 2. 可用性を諦める 3. 一貫性を諦める 4. BASE に跳ぶ 5. 問題をかわして設計する まとめ 参考文献 ブリュワーの CAP 定理 この文書について "Brewer's CAP Theorem - The kool aid Amazon and Ebay have been drinking" の日語訳です. http://www.julianbrowne.com/article/view

  • 構造化オーバレイの一貫性保証 - kibayos日記

    Skip Graphの耐障害性に取り組んでいるところです。 Skip Graphに限らず構造化オーバレイの可用性を高めるためには、ネットワーク上に分散している構造化オーバレイの持つ構造についてなんらかの一貫性管理をする必要があります。構造化オーバレイは不安定なピアを含むP2P環境で動作しないといけない前提があるため、分散構造の一貫性保証は簡単ではありません。 5月に開かれた 3rd Sensor & Overlay Workshop では、クラウドコンピューティングで取り上げられる BASE(Basically Available, Soft-State and Eventual Consistency)をキーワードにこの問題が議論されました。その時の資料の改訂版をここに掲載します。(細かなSkip Graphのアルゴリズムの記述をカットして、unbreakable 構造化オーバレイを追記

    構造化オーバレイの一貫性保証 - kibayos日記
  • カラムナデータベース(列指向データベース)とデータベースの圧縮機能について、マイケル・ストーンブレイカー氏が語っていること

    カラムナデータベース(列指向データベース)とデータベースの圧縮機能について、マイケル・ストーンブレイカー氏が語っていること データベースの高速化技術の1つに、データの圧縮があります。データを圧縮して扱うことでディスクアクセスとI/Oが減少し、データへのアクセス速度が向上するのです。最近のCPUコア数の増大やメモリ単価の下落はデータ圧縮と伸長にかかるオーバーヘッドのコストを相対的に小さくしており、それもこの技術に有利に働いています。 Ingresの開発者であり、InformixのCTOなどデータベースベンダの要職を歴任、データベース研究者として大御所ともいえるマイケル・ストーンブレイカー氏が、データベースにおけるこのデータ圧縮と伸長処理について、ブログ「The Database Column」のエントリ「"Just in Time" Decompression in Analytic Dat

    カラムナデータベース(列指向データベース)とデータベースの圧縮機能について、マイケル・ストーンブレイカー氏が語っていること
  • スケーラビリティに関するベストプラクティス:eBayからの教訓

    データベース層でもほぼ同様のアプローチに従っています。eBayにはモノリシックデータベースはひとつもありません。その代わり、ユーザーデータ用のデータベースホストセット、アイテムデータ用セット、購入データ用セットなど、計1000個の論理データベースが400個の物理ホストに存在します。繰り返しますが、このアプローチによって、データタイプごとに個別にデータベースインフラがスケーリングできるのです。 ベストプラクティス#2:水平分割 機能の区分化によって光明が見えてきたわけですが、完全にスケーラブルなアーキテクチャにとってそれだけでは十分ではありません。ある機能は他の機能から分離されるかもしれませんが、1つの機能エリアの需要は時間とともに肥大し、どのような単独システムよりも大きくなってしまいます。私たちが好んで自身に言い聞かせていることですが、「分割できないなら、スケーリングもできない」のです。特

    スケーラビリティに関するベストプラクティス:eBayからの教訓
  • @IT Special:CRM以外の利用が注目される「Salesforce over VPN」

    SaaS型CRMSFAで有名な「Salesforce.com」を セキュリティと通信品質を担保して提供 CRMSFA以外の利用が注目される 「Salesforce over VPN」 市場環境や経営環境が目まぐるしく変化するこの時代に、多額の投資をしてシステム構築することのリスクが高まっている。いま、インターネットを含めた企業のネットワーク環境が整い、アプリケーション分野での技術的な成熟ともあいまって、企業の情報システムは「所有」から「利用」の流れが加速している。セキュアでかつ低価格・短期間での構築という市場のニーズに応えるものとしてNTTコミュニケーションズが提案するのは、SaaS型CRMSFAとして多くの実績を持つSalesforceを、インターネットを経由しない安全な閉域網で提供する「Salesforce over VPN」である。 基幹業務システムを自社で開発・構築するのは、

  • クラウド技術のオープンソース実装 enbug diary(2009-08-23)

    _ クラウド技術のオープンソース実装 Cloud computingという新しいbuzzwordを誰かが思いついて、しばらく時間が経ちました。 どの辺がいかにもbuzzwordなのかというと、誰もクラウドって何?というのを説明できなかったところを見ると明らかです。 しかし、buzzwordにもbuzzwordなりの効力というものがありまして、 マーケットはそれに合わせて動くわけです。 その結果、需要も動いたり動かなかったりして、それなりに技術の進展にも影響を与えます。 そんなこんなで、後付けで意味が定義されたクラウドコンピューティングなんですが、 英語WikipediaのCloud computing によると、Gartnerは次のように定義したそうです。 サービスに基づいている。 インフラを必要に応じて増強したり削減したりできる。 規模の経済を築くため、共有インフラを使う。 使用量に課

  • 「クラウド・コンピューティングのアーキテクチャ戦略」(日本語版) - S/N Ratio (by SATO Naoki)

    1ヶ月ほど前に公開された、OTNのEnterprise Architecture Centerとホワイトペーパー「クラウド・コンピューティングのアーキテクチャ戦略」の日語版ができました。 OTN > Enterprise Architecture Center http://www.oracle.com/technology/architect/entarch/ (英語) http://www.oracle.com/technology/global/jp/architect/entarch/ (日語) 「クラウド・コンピューティングのアーキテクチャ戦略」("Architectural Strategies for Cloud Computing") http://www.oracle.com/technology/architect/entarch/pdf/architectural

    「クラウド・コンピューティングのアーキテクチャ戦略」(日本語版) - S/N Ratio (by SATO Naoki)
  • 乱文、クラウドで何が変わるか:クラウド的な世界へ:オルタナティブ・ブログ

    SaaS/PaaS/IaaSを筆頭に、さまざまなクラウドが飛び交った一年だったように思えます。みなさんの1年前の頭の中のクラウドは明らかに変質して、かつ混乱してきた人も多いように思えます。かくいう私も正直、"クラウド"という一言では、とても百花繚乱のクラウドの世界を語れないことの限界を感じています。 それでもあえて、整理の前の想像を広げる段階として、今一度、"クラウドで何が変わるか"を、パブリッククラウド中心に、人の立場ごとに乱文覚悟で書いてみたいと思います。ご容赦のほど。 ユーザーにとって ユーザーにとっては、まずはSaaSは変化が大きいですよね。やりたいことに合うSaaSがあれば、IT部門に干渉されず少額ですぐにはじめられる。ただ多少のカストマイズはできてもそれ以上はなかなかむずかしい。既存のシステムとの連携は、IT部門が最初嫌がりそう。PaaSとかIaaSだといろいろ作れるかもしれな

    乱文、クラウドで何が変わるか:クラウド的な世界へ:オルタナティブ・ブログ
  • BigtableとSmalltable - スティルハウスの書庫の書庫

    App Engineによる設計手法でひとつ私が実案件で試してなかなかうまくいったと思ったのは、「Smalltable」って私が勝手に呼んでいるアーキテクチャです。簡単にいうと、「複数クライアントのローカルのSQLite間をDatastoreを介して同期する」仕組みです(こういうの一般に何パターンと言うのでしょう…教えてください!)。 クライアントはHTML5やAIR、iPhoneAndroid等のリッチクライアントで(実際に実装したのはAIRとiPhoneです)、SQLite等の小規模RDB(以下、Smalltable)をローカルに持つことが前提 Smalltableは、Datastoreが保持するすべてのデータのうち、そのユーザーが常時使用するデータのみ保持するサブセット アプリケーションの大半のロジックをリッチクライアント内のSmalltableだけで実装する すべてのレコードにはク

    BigtableとSmalltable - スティルハウスの書庫の書庫
  • クラウドコンピューティングに潜むセキュリティの“陰”と“陽”

    ラックは2009年に見られた情報セキュリティのインシデントから、クラウドコンピューティングに関するセキュリティの問題点とメリットを解説している。 セキュリティ企業のラックは12月8日、2009年に発生した情報セキュリティインシデントを解説する記者説明会を開催した。同社サイバーリスク研究所の新井悠所長がクラウドコンピューティングをキーワードに、セキュリティの問題点とメリットを取り上げた。 2009年のセキュリティインシデントには、Webサイト改ざんや偽セキュリティソフトによる詐欺など、2009年よりも前に出現した脅威が世界的に横行する傾向が見られた。2009年に顕在化した脅威が、企業を中心に導入や利用が広がるクラウドコンピューティングに関係するものである。 冒頭、新井氏はクラウドコンピューティングがサイバー攻撃者にとっても魅力的な手段になるという幾つかの事例を紹介した。例えば、米セキュリティ

    クラウドコンピューティングに潜むセキュリティの“陰”と“陽”
  • クラウドのTCO評価:クラウド的な世界へ:オルタナティブ・ブログ

    クラウドでコスト削減は、まさにマーケのお決まりメッセージですが、もうすこし具体的に考えられないかなと思い、TCO評価でお試し思考をしてみました。 ITコスト全体の代表指標が、総所有コストのTCO(Total Cost of Ownership)ですが、もともとはガートナーが90年代に言い出したもののようです。要は見えないコストなども含めてコストを時間軸も捕らえて把握しようという訳です。で、その具体的な内訳というとシンプルに定まったものがみつからないので、ガートナーのレポートなどから引っ張ってきました。 ① ハードウェア/ソフトウェアの購入と保守 ② システム運用・管理 ③ ユーザーサポート ④ 開発 ⑤ ネットワークなど共通インフラ ⑥ ユーザーのピア/セルフサポートと開発 ⑦ ダウンタイム ①から⑤までが直接的な費用で、⑥と⑦は間接的な費用といえます。で、これをベースに今までのシステムが

    クラウドのTCO評価:クラウド的な世界へ:オルタナティブ・ブログ