Agile Cat — in the cloud

Windows Azure Platform が 21+20 で 41カ国に!

Posted in Microsoft by Agile Cat on April 13, 2010

Windows Azure Platform Expands Global Availability to 41 Countries
http://blogs.msdn.com/windowsazure/archive/2010/04/12/windows-azure-platform-expands-global-availability-to-41-countries.aspx

Windows Azure

2010年 4月 12日(アメリカ時間)に、オーストラリアやブラジルなど、20カ国への Windows Azure Platform 提供が始まったとのことです。 これで、先行する日本などの 21カ国を含めて、41カ国で Windows Azure の利用が可能になりました。

ーーーーー

Starting today, the Microsoft Windows Azure platform, including Windows Azure, SQL Azure, and Windows Azure platform AppFabric will be generally available in an additional 20 countries, making our flexible cloud services platform available to a global customer base and partner ecosystem across 41 countries. As a number of time zones apply to our customers and partners worldwide, availability of the Windows Azure platform will roll out to all 20 countries successively this week.

On Feb 1 2010, we announced the general availability of the Windows Azure platform in 21 countries and starting today our global footprint will increase to the following 20 countries and regions in the following currencies:

 
  • Australia $ AUD
  • Brazil $ USD
  • Chile $ USD
  • Colombia $ USD
  • Costa Rica $ USD
  • Cyprus € EUR
  • Czech Republic € EUR
  • Greece € EUR
  • Hong Kong $ USD
  • Hungary € EUR
  • Israel $ USD
  • Luxemburg € EUR
  • Malaysia $ USD
  • Mexico $ USD
  • Peru $USD
  • Philippines $ USD
  • Poland € EUR
  • Puerto Rico $ USD
  • Romania € EUR
  • Trinidad and Tobago $ USD
  • With the Windows Azure platform, customers can take advantage of greater choice in developing cloud-based applications by using familiar tools and leveraging on-premises investments.  Since February 1, thousands of customers have signed up for accounts and customers including OCCMatch.com and Sharpcloud have deployed cloud applications on the Windows Azure platform.  For more stories about how customers are using Windows Azure Platform to cut costs and increase agility, be sure to read the latest customer case studies.

    Partners also have the opportunity to create new revenue streams by deploying cloud applications and services on the Windows Azure platform to reach new global markets and generate new revenue opportunities.  Partners interested in building and growing their business in the cloud with the Windows Azure platform should check out the offers available to them, as well as a resource guide, and readiness resources available to help them get started.

    Developers interested in building and deploying cloud applications on the Windows Azure platform should start here for a general overview and then go to Get Started to learn how to discover, develop and deploy using Windows Azure, SQL Azure, Windows Azure platform AppFabric or Microsoft Codename ‘Dallas’. 

    Published Monday, April 12, 2010 1:04 AM by WindowsAzure

    ーーーーー

    着実に、やるべき事を、やっていますね。 現実的な運用が始まったときに、これまでの蓄積が、高い評価を得ることになるでしょうね。 ーーー A.C.

    Tagged with: , ,

    Cassandra:6つの迷信と 6つの真実

    Posted in NoSQL by Agile Cat on April 13, 2010

    Cassandra: Fact vs fiction
    Jonathan Ellis
    Wednesday, April 07, 2010
    http://spyced.blogspot.com/2010/04/cassandra-fact-vs-fiction.html

    imageCassandra has seen some impressive adoption success  over the past months, leading some to conclude that Cassandra is the frontrunner  in the highly scalable databases space (a subset of the hot NoSQL category ). Among all the attention, some misunderstandings have been propagated, which I’d like to clear up.

    この数カ月の間に、Cassandra 運用における成功を印象付ける事例が紹介され、ハイ・スケーラブルなデータベース領域(ホットな  NoSQL category  のサブセット)では、Cassandra が最先端であるという、いくつかの結論がもたらされた。こうした注目は喜ぶべきものだが、いくつかの誤解が広まっているので、以下に修正する。

    ーーーーー

    Fiction_1: "Cassandra relies on high-speed fiber between datacenters" and can’t reliably replicate between datacenters with more than a few ms of latency between them.

    Fiction_1: ”Cassandra はデータセンター間をつなぐ、高速のファイバーに依存する"。 そして、データセンター間を数ミリ秒レベルのレイテンシー接続し、信頼性のあるリプリケーションを行うことは不可能である。

    Fact_1: Cassandra’s multi-datacenter replication is one of its earliest features and is by far the most battle-tested in the NoSQL space. Facebook had Cassandra deployed on east and west coast datacenters since before open sourcing it. SimpleGeo’s Cassandra cluster spans 3 EC2 availability zones , and Digg is also deployed on both coasts. Claims that this can’t possibly work are an excellent sign that you’re reading an article by someone who doesn’t know what he’s talking about.

    Fact_1: Cassandra のマルチ・データセンター・リプリケーションは、その初期からの特徴の1つであり、NoSQL スペースでのバトルにより検証されている。 Facebook は Cassandra をオープンソースかする以前から、東海岸と西海岸のデータセンター間にディプロイしている。 SimpleGeo の Cassandra クラスタは、EC2 における 3つの利用ゾーンをまたぎ、また、Digg も東西の海岸にディプロイしている。 それが上手くいかないという主張は、意味のわからない記事を書く、筆者を探し出すための、便利なサインとなる。

    Fiction_2: "It’s impossible to tell when [Cassandra] replicas will be up-to-date."

    Fiction_2: Cassandra レプリカがアップデートされるタイミングを、知らせることができない。

    Fact_2: Cassandra provides consistency when R + W > N (read replica count + write replica count > replication factor), to use the Dynamo vocabulary . If you do writes and reads both with QUORUM, for one example, you can expect data consistency as soon as there are enough reachable nodes for a quorum. Cassandra also provides read repair  and anti-entropy , so that even reads at ConsistencyLevel.ONE  will be consistent after either of these events.

    Fact_2: Cassandra は Dynamo 用語を用いて、 R + W > N (read replica count + write replica count > replication factor) のときにコンシステンシーを提供する。たとえば、QUORUM を用いて write/read を行うとき、その最小数に到達する充分なノードがある場合には直ちに、データのコンシステンシーが可能になる。 さらに Cassandra では read repairanti-entropy を提供することで、ConsistencyLevel.ONE におけるread であっても、それらのイベントの後にコンシステンシーが行われる。

    Fiction_3: Cassandra has a small community

    Fiction_3: Cassandra は小規模なコミュニティを有している。

    Fact_3: Although popularity has never been a good metric for determining correctness, it’s true that when using bleeding edge technology, it’s good to have company. As I write this late at night (in the USA), there are 175 people in the Cassandra irc channel, 60 in the HBase one, 32 in Riak’s, and 15 in Voldemort’s. (Six months ago, the numbers were 90, 45, and 12 for Cassandra, HBase, and Voldemort. I did not hang out in #riak yet then.) Mailing list participation tells a similar story. It’s also interesting that the creators of Thrudb   and dynomite   are both using Cassandra now, indicating that the predicted NoSQL consolidation is beginning.

    Fact_3: 人気に応じて正当性を決定することは、適切な基準といえないが、最先端のテクノロジーを用いるときに、仲間を持つことが有益だというのは真実だ。 このポストを夜中に(USA 時間) に書いているときに、 Cassandra irc channel には 175人、そして HBase には 60人、Voldemort には 15人が居る。 (6カ月前には、Cassandra が 90人、HBase が 45人、Voldemort には 12人だった。 そのときには、#riak は使っていなかった) メーリング・リストへの参加も、類似のストーリーを物語っている。また、Thrudb  と dynomite のクリエーターが Cassandra を使用しており、予測されていた NoSQL コンソリデーションの、始まりを示している点も興味深い。

    Fiction_4: "Cassandra only supports one [keyspace] per install."

    Fiction_4: "Cassandra は、インストールごとに 1つの [keyspace] だけをサポートする"。

    Fact_4: This has not been true for almost a year (June of 2009 ).

    Fact_4: それは真実ではない  (June of 2009 )。

    Fiction_5: Cassandra cannot support Hadoop, or supporting tools such as Pig.

    Fiction_5: Cassandra は、Hadoop および、Pig などのサポーティング・ツールに対応できない。

    Fact_5: It has always been straightforward to send the output of Hadoop jobs to Cassandra, and Facebook, Digg, and others have been using Hadoop like this as a Cassandra bulk-loader for over a year. For 0.6, I contributed a Hadoop InputFormat and related code to let Hadoop jobs process data from Cassandra  as well, while cooperating with Hadoop to keep processing on the nodes that actually hold the data. Stu Hood then contributed a Pig LoadFunc, also in 0.6.

    Fact_5: Hadoop ジョブ出力の Cassandra への送信は簡単であり、Facebook や Digg などは、この一年の間に、 Cassandra bulk-loader のようなかたちで、Hadoop を使用している。Cassandra の 0.6 に関して、そのデータを Hadoop ジョブに処理させるために、私は Hadoop InputFormat と関連するコードをコントリビュートしている。 それらは、実際にデータを保持しているノード上で、Hadoop による処理を、協調して行わせるためのものである。0.6 において、Stu Hood も Pig LoadFunc をコントリビュートしている。

    Fiction_6: Cassandra achieves its high performance by sacrificing reliability (alternately phrased: Cassandra is only good for data you can afford to lose)

    Fiction_6: Cassandra は、その信頼性を犠牲にすることで、ハイ・パフォーマンスを得ている(言い換えれば:Cassandra は、失っても構わないデータに適している)。

    Fact_6: unlike some NoSQL databases (notably MongoDB  and HBase ), Cassandra offers full single-server durability . Relying on replication is not sufficient for can’t-afford-to-lose-data scenarios; if your data center loses power, you are highly likely to lose data if you are not syncing to disk no matter how many replicas you have, and if you run large systems in production long enough, you will realize that power outages through some combination of equipment failure and human error are not occurrences you can ignore. But with its fsync ‘d commitlog  design, Cassandra can protect you against that scenario too. What to do after your data is saved, e.g. backups and snapshots, is outside of my scope here but covered in the operations wiki page .

    Fact_6: いくつかの NoSQL データベース(とりわけ MongoDBHBase )とは異なり、Cassandra は  full single-server durability を提供する。リプリケーションへの依存は、can’t-afford-to-lose-data シナリオを完全に充たすものではない。 つまり、データセンターが停電してしまった際に、どれだけのレプリカを持っていようとも、ディスクとの同期をとっておかなければ、データを失う可能性が高い。そして、大規模システムを、きわめて長い期間で運用する場合には、いくつかの装置の故障や、人為的なミスの組み合わせによる停電が、無視できない事象だと理解するだろう。しかし、Cassandra では、その fsync ‘d commitlog デザインにより、そのようなシナリオにおいても、データを保護することができる。たとえば、backup や snapshot によりデータを保存した後に行うべきことは、ここでのスコープから外れたものとなるが、operations wiki page においてカバーされている。

    ーーーーー

    <関連>
    かなり気になる、NoSQL 関連のポスト : Cassandra や CAP Theorem など
    Cassandra ライブ情報がテンコ盛り – Jonathan Ellis @ Rackspace
    Twitter が Cassandra を選んだ理由 — MyNoSQL
    Digg が Cassandra を採用する理由 by John Quinn
    High Scalability のホット・リンク集 : Cassandra@Twitter インタビューもあるよ!
    Cassandra 分散データベースでの削除とは?
    Cassandra プロジェクトと Rackspace
    イベンチュアル・コンシステンシーはお好き? by James Hamilton

    %d bloggers like this: