Jackson ファンたちが Web を軋ませた

The Web Creaks as Jackson Fans Mourn
June 25th, 2009 : Rich Miller
Datacenter Knowldge より

Keynote Systems が Michael Jackson が死んだ夕刻の、インタネット･レスポンスにおける需要／供給バランスに関するレポートを発表した。 調査対象は、ABC、AOL、CBS、 MSNBC、NBC、SF Chronicle、Yahoo! News とのこと。

赤い線が供給を示し、青い線が需要を示している。ピークへと転ずる最初のクロスが17:45 で、平常へと戻る二番目のクロスが 18:45。

Google と、Yahoo と、Bing に、マイケルがくれたもの

SEARCH ENGINE JOURNAL より

Google News は Michael の死をキャッチできなかった。ただ、Google News Universal Search Onebox に1行だけ、そのことを示すヘッドラインがあったとか。

Yahoo は、見事にキャッチした。。。

Bing は、ずっとスクロールしたところでキャッチしているが、リンクは Fail だったという。

Database Sharding _1

Database Sharding とは、"Shared-Nothing" のアプローチである

http://www.codefutures.com/database-sharding/

David Chappell さんの Blog に、Sharding という言葉があり、ずっと気になっていましたが、それを説明してくれるドキュメントを見つけましたので、4~5 回に分けて抄訳を連載していきます。

Hadoop のときもそうでしたが、Azure を正しく理解するためには、Microsoft 以外から提供される情報にも、目を通さなければならないのだなぁ、、、と感じてしまいますね。

端的に言って、Database Sharding とは、"Shared-Nothing" のアプローチだそうです。今回の訳にも ”割れたガラス" の例えありますが、従来からのパーティショニングのテクニックとは一線を画した、思い切った分割が Sharding なのでしょう。

――― A.C.

ーーーーーーーーーーーーーー

The Rise of Database Sharding

Database Sharding のコンセプトとは、ビジネス･アプリケーション･データベースにおける、膨大なトランザクション量とサイズのに対応するためものであり、この数年の間に利用されるケースが増えてきている。そして、オンライン･サービス･プロバイダーのビジネスや、Software as a Service (SaaS) 、SNS Web サイトなどを成功させるものとして評価されている。

Database Sharding は、数多くのサーバーをまたぐ大規模データベースのための、"shared-nothing" パーティション･スキーマであるとシンプルに定義できる。それにより、データベースのパフォーマンスとスケーラビリティを、新しいレベルで達成可能にしていくことになる。 Sharding のコンセプトを理解したいなら、割れたガラスについて考えるべきである。つまり、データベースを “shards” と呼ばれる小さなチャンクに分解し、分散された多数のサーバー上に、それらをばら撒くことである。

用語としての "sharding" は、Google のエンジニアたちが造り出したものであり、彼らの Big Table アーキテクチャ･パブリケーションを介しての普及してきた。 ただし、"shared-nothing" データベース･パーティショニングの概念は、10年前あるいは、それ以前から存在していた。そして、それ以降の何年かで数多くのサービスに実装されてきたわけだが、eBay や、Amazon、Digg、Flickr、Skype、YouTube、Facebook、Friendster、Wikipedia といったインターネット･リーダーたちによる、高度なプロファイル構築ソリューションにおける利用が顕著である。

このドキュメントは、Database Sharding の必要性および、データベース･パーティショニングで利用可能な選択枝、そして、Sharding 実装を成功させるための主要な考察ポイントにフォーカスしている。

What Drives the Need for Database Sharding?

Database Sharding は、膨大なトランザクションにおけるスループットとパフォーマンスを改善し、大規模なデータベースを中心とするビジネス･アプリケーションを構築するための、きわめてスケーラブルなアプローチである。リレーショナル･データベースの初めから、アプリケーションのエンジニアとアーキテクトは、長い時間をかけてビジネス･データベースが成長していくという単純な観点に基づき、パフォーマンスとキャパシティが、とめどもなく増大していくことを要求してきた。そして、インターネット経済と、情報時代、イーコマースの高まりによる、ビジネス･データの急速な膨張が、その傾向を加速している。

経験豊かなデータベース･アドミニストレータやアプリケーション･デベロッパーが、その全てを理解しているように、データベース層のサイズ(GBs)とトランザクション(Tx)のボリュームがリニアに成長するににつれて、その応答時間(Rt)が対数的に増大する傾向にあることは明白である。それを、以下の図で示す：

Figure 1. The growth in database transactions and volumes has a large impact on response times.

パフォーマンスとスケーラビリティに取り組まなければならない理由は、データベース管理システム自身の、基本的なデザインからもたらされるものである。あらゆるコンピュータ上のデータベースが、以下の 3つのコンポーネントに大きく依存している：

• CPU
• Memory
• Disk

私たちが実施したベンチマーク･テストを介して、それらの要素は、シングル･サーバーにおいてのみスケールするものであり、他の基準を取り込まなければならないことが分かった。ディスク I/O が主要なボトルネックであることが明確になった一方で、データベース管理システムが改善されるにつれて、CPUとメモリのアドバンテージについても、さらに高いものが求められる。現実において、最大の性能を決定するものは、それたの 3つの要素と一致するものであることが観察されたわけである。 言い換えれば、無限の CPU（コア）を加えることは不可能であり、また、メモリ容量とディスク･ドライブ･サブシステムのパフォーマンスを改善することなく、通信におけるパフォーマンスを高めることはできない。つまり、シングル･データベース･サーバーにリソースを追加していくにつれて、そこから得られるリターンは減少していく。この傾向は、膨大な Read/Write トランザクションを実行するシステムにおいて、つまり、複雑なビジネス･トランザクションにおいて顕著である。 そして、ビジネス･レポート･タスクのサポートにおいても、それは同様である。

それ故に、ビジネス･アプリケーションが洗練され、需要にしたがって成長するにつれて、アーキテクトと、デベロッパー、データベース･アドミニストレータに、継続的な課題が与え続けられてきた。それは、ミッション･クリティカル･システムにおいて、データベース･パフォーマンスを維持することである。 こうした背景が、Database Sharding の必要性を促進している。

＜続く＞

 

Database Sharding _1
Database Sharding _2
Database Sharding _3
Database Sharding _4
Database Sharding _5

最期まで Michael はスーパーだった

空前のトラフィック by Michael

アメリカの各サイトは、Michael に関連するニュースやメッセージで、空前のトラフィックだったそうです。
以下は、Alexa の Hot URLs （6/27/2009, 12:40 PM）です。③ と ⑦ 以外は、すべて Michael 関連です。

以下は、Long Tail World からです。。。

Google:  自動攻撃と勘違いし、約25分間エラーページを出してしまった
Yahoo：「マイケル・ジャクソン病院に急行」は10分でクリック80万回、訃報も10分でクリック56万回
Flickr： マイケル・ジャクソン関連の写真が、1日で4000枚投稿された
Twitter： マイケル・ジャクソン関連のつぶやきは、ピーク時で5000件／1分を記録した
AOL： インスタントメッセージAIMは、木曜午後に約40分間のダウン

最期までスーパーだった  Michael に合掌です。。。

初めての New SQL Data Services

Eugenio Pace – Cloud Computing Guidance

Windows Azure のセールス･ポイントとして注目される New SDS ですが、Eugenio さんのブログで新しいポストを見つけました。 それと、以前の Eugenio さんの LitwareHR ですが、カテゴリ Eugenio Tracker に整理しましたので、そちらもご覧ください。   －－－ A.C.

Clouds: one thing we really know about here in Redmond, WA, USA
Published Friday, June 12, 2009 12:03 PM by eugeniop

Pasted from <http://blogs.msdn.com/eugeniop/archive/2009/06/12/first-experiments-with-new-sql-data-services.aspx>

First experiments with (new) SQL Data Services

 
Last week I got my new login to the new SQL Data Services. As a reminder for all readers:
SDS accelerates its plans to offer relational capabilities

May 11, 2009 – Based on customer feedback, SDS has accelerated its plans and will be offering true relational capabilities through SQL Server’s existing network protocol, Tabular Data Stream (TDS) and existing query language Transact-SQL (T-SQL). This will provide customers direct access to the familiar relational model, T-SQL programming language and the existing development and management tools, while continuing to deliver on our key value props of fault tolerance, high availability, friction free provisioning and pay as you grow scaling. For more information, see the SDS product site and the MSDN Library.

May 11, 2009 – カスタマー･フィードバックに基づき、SQL Server における既存のネットワーク･プロトコルである Tabular Data Stream（TDS）を介して、また、既存のクエリー言語である Transact-SQL（T-SQL）を介して、SDS の計画を加速し、本当のリレーショナル機能を実現していく。 そこで顧客に提供されるのは、T-SQL プログラミング言語と、開発と管理のための既存のツールで構成される、親しみのあるリレーショナル･モデルへのダイレクトなアクセスであるが、フォールト･トレランスと、高可用性、スケールの成長に応じたプロビジョニングと支払いなどへの、支援に関する提供は継続される。 詳細な情報については、SDS プロダクト･サイトと MSDN Library を見てほしい。

 

————————-

What I’ve done? After some initial “hello world-ish” tests, I wanted to try something more interesting so I decided to port IssueTracker into SDS.

私がしたことについて、説明しよう。 最初に行った何パターンかの “hello world-ish”  テストの後に、もっと面白いことをやりたいと思った。 そして、SDS で IssueTracker をポートすることに決めた。

As you know, IssueTracker was originally designed for SDS’ previous ACE model (Authority, Container, Entity), so my first task was to re-write the data access layer to use SQL Server.

皆が知っているように、IssueTracker は以前の SDS が提供していた、ACE モデル（Authority、Container、Entit）のためにデザインされたため、最初の作業は SQL Server をように、そのデータ･アクセスレイヤをリライトすることだった。

One of my goals in this experiment was to test SDS “impedance match” with on-premises SQL Server. Also, I wanted to develop independently of the availability of SDS. Not that SDS is unreliable, but currently it is available only inside Microsoft’s corporate network. I didn’t want to VPN into corpnet for this when working from home.

この実験における目的にひとつは、オンプレミスの SQL Server を用いた、SDS の  “impedance match”をテストすることにあった。また、SDS の可用性とは切り離されたところで、開発を行いたいと望んだ。 SDS が信頼できないということではないが、現時点においては、Microsoft のコーポレート･ネットワークの中だけで利用できるというものである。 そして、コーポレート･ネットワークに依存したくなかったのは、家でも仕事をするからだ。

So I chose to develop exclusively against my local SQL Express instance first and then make a switch to the real SDS.

そこで私が選んだのは、ローカルな SQL Express インスタンスで最初に作業した後に、本物の SDS にスイッチする形態である。

Fortunately, the app was designed with a couple of layers that isolated the persistence details, so writing the new data tier was a fairly mechanical process.

幸いなことに、このアプリケーションは永続的に分離される、2 つの層の組み合わせを用いてデザインされていたため、新しいデータ層の記述は、機械的なプロセスで進んだ。

This diagram roughly captures the architecture:

そのアーキテクチャについて、以下の図に示す：

The repository classes implement a common interface the app uses, the Model is just a collection of rather simple C# objects with no knowledge of the database being used. The Mappers are responsible for the transformations between the application model and the entities that do have knowledge of the database.

そのリポジトリ･クラスはアプリケーションが使う普通のインターフェイスを実装する。そして、この Model は単純な C# オブジェクトというより、単なるコレクションであり、データベースの知識は必要ない。 また、Mappers に課せられた責任は、アプリケーション･モデルと、データベースの知識を持つエンティティの間での変換となる。

In the diagram, classes marked with * are new, the numbers indicate variability points in the implementation, meaning that I can switch between one implementation and the other. Because I used LINQ to SQL, the types in the box labeled as “SQL Model” were generated automatically by the LINQ to SQL designer.

この図で、* マークが付いているのは新しいクラスであり、また、数が記されているのは、実装を切り替えられる可変のポイントである。 SQL に対して LINQ を使用したため、ボックス内に記された “SQL Model” であるというラベルは、LINQ to SQL デザイナーにより自動的に生成された。

When my unit tests compiled again, I switched the connection string to point from the “.\SQLEXPRESS” to the SDS instance in our network and…it worked! First attempt! 

単体テストのために再コンパイルしたとき、接続文字列のポイントを、 “.\SQLEXPRESS” から、ネットワーク上の SDS インスタンスに切り替えた。それが、そのまま動いた。 それが、最初のトライである！

Overall, it was a rather painless and pleasant experience. Of course the data model in the app is simple and I’m not using any advanced queries or any sophisticated features in SQL yet.

もちろん、アプリケーションのデータモデルはシンプルであり、また、SQL の洗練されたクエリーや、先進的なキューは使っていない。

Things missing and Possible next steps:

The original implementation had 2 requirements that leveraged features in SDS previous ACE model:

1- Multi-tenant isolation: achieved through containers. Each tenant got its own container.

2- Schema flexibility: tenants could customize the application, extending the schema of some core entities. Flexible entities made this very easy, because they are essentially property bags.

このオリジナルの実装は、以前の SDS ACE モデルにおける 2つの機能を活用するという用件を持っていた：

1- Multi-tenant isolation: コンテナを介して達成されるものであり、それぞれのテナントが自身のコンテナを持つ。

2- Schema flexibility: いくつかのコア･エンティティを拡張することで、テナントによるアプリケーションのカスタマイズを実現する。柔軟なエンティティにより実現可能な理由は、それらが、本質的にプロパティ･バッグだからである。

For #1, I considered two options:

1- Partitioning by tenant
2- Do not partition at all and have all tenants on the same database (single-instance, multi-tenant)

#1 については、2つのオプションを検討した：

1-  テナントによるパーティショニング
2- パーティショニングは全く行わずに、すべてのテナントを同一のデータベース上に持つ（single-instance, multi-tenant） The first option is fairly straight forward. Each tenant gets its own database that is created at provisioning time. The “tenant id” is part of the calling context in the application, so I dynamically connect to each database as needed. Two advantages of this approach: there’s high isolation between tenants (no data from one can leak into another), and the application code is simpler, because from the data perspective, the application is “single-tenant”.

最初のオプションは、かなり単刀直入なものである。 それぞれのテナントが、プロビジョニング時に作成される。自身のデータベースを取得する。 その “tenant id” が、アプリケーションにおけるコール･コンテキストの一部となるため、個々のデータベースとの動的な接続が、必要に応じて実現される。 このアプローチにおける のアドバンテージは、テナント間の分離が強化されることである。 また、アプリケーション･コードもシンプルになる。 その理由は、データの視点から見ると、対象となるアプリケーションが “single-tenant” になる点にある。

I haven’t implemented the extensibility feature yet, but I’m planning on reusing some techniques we did some research on in the past, probably through extension tables.

拡張された機能については、まだ実装していないが、いくつかのテクニックを再利用したいと考えている。それは、おそらく、過去において研究してきた、拡張テーブルを介したものとなるだろう。

There’re other interesting areas for research such as:

そのほかの、研究すべき領域としては、以下のような面白い分野がある：

1- Strategies for partitioning: in discussions with Ryan, he suggested I should consider more sophisticated ways of partitioning the information: by tenant, by tenant + project, etc. and I agree this would be interesting .

1- Strategies for partitioning:  Ryan とのディスカッションにおいて、情報のパーティショニングについて、もっと洗練された方式を考えるべきだとの示唆があった。それは、 by tenant や by tenant + project などであり、それらが興味深いものであることに、私は同意している。

2- Unit of Work: currently I’m simply reusing the original ACE implicit UoW that comes with each interaction. This is, each time you called Create, Delete or Update on SDS, the operation was completed in the context of a unit of work. You could not logically group multiple operation (say, 2 creates and 1 delete). This is suboptimal with the SQL implementation, because the new SDS supports transactions and I would like to leverage that.

2- Unit of Work: 現時点では、それぞれの相互作用に伴って生じる、オリジナルの ACE における暗黙の UoW を再利用しているだけである。 それは、SDS 上で Create／Delete／Update がコールされるたびに、unit of work のコンテキストの中で、オペレーションが完了するというものだ。 多数のオペレーションを、論理的にまとめることはできない（たとえば、2つの create と、1つの delete）。 それが、SQL 実装における次善である。なぜなら、新しい SDS がサポートするトランザクションを、活用したいと思っているからだ。

3- Performance and scalability issues: I haven’t spent any time looking at the application’s “chattiness” with the database that might lead to degraded performance, or any other data access optimizations. This is a whole area in itself, but not very different from “regular” application development. The only exception perhaps is that, in theory at least, the app and the database can be hosted in different datacenters (say the app in Amazon and the data in SDS). I’m not sure that would be a good idea anyway, probably not for this scenario. If the app was hosted in Windows Azure and used SDS, then they would be close in terms of network distance (low latency & high bandwidth). 

3- Performance and scalability issues: このアプリケーションとデータベースの間での “chattiness” については、時間を割いてこなかった。そのため、パフォーマンスの低下を招いているかもしれないし、データアクセスの最適化が必要かもしれない。 それは、アプリケーションの全域におよぶものであるが、“regular”  なアプリケーション開発と、そう変わるものでもない。 唯一の例外と思われるのは、少なくとも理論上において、アプリケーションとデータベースが別のデータセンターにホストされる可能性があることだ（たとえば、アプリケーションは Amazonで、データは SDS）。 それが適切な考え方だとは、確信していない。そして、このシナリオのためのものでもない。 このアプリケーションが Windows Azure 上にホストされ SDS を使うなら、ネットワーク･ディスタンスの観点から、両者の距離は近いものとなる（low latency & high bandwidth）。

Published Friday, June 12, 2009 12:03 PM by eugeniop

Pasted from <http://blogs.msdn.com/eugeniop/archive/2009/06/12/first-experiments-with-new-sql-data-services.aspx>