Agile Cat — in the cloud

VMware の Cloud Foundry が、デベロッパーの 人気 No.1 になる理由は?

Posted in .Selected, PaaS, VMware by Agile Cat on December 7, 2011

VMware’s Cloud Foundry Ranked Top Developer Platform
By
Charles BabcockInformationWeek
November 28, 2011
http://informationweek.com/news/cloud-computing/platform/232200211

New VMware kid on the PaaS block takes “best overall” honors, while Google App Engine is best public and IBM SmartCloud best private cloud platform in Evans Data survey.

Evans Data の調査によると、VMware が新たに提供する PaaS ブロックが最高の評価を獲得した。 その一方で、パブリック部門では Google App Engine が、そして、プライベート部門では IBM SmartCloud がトップとなった。

_ Information week

Developers cite many benefits to working on cloud platforms, including speeded up projects and the ability to tap into platform-provided components, like Web servers and application servers. But it’s a surprise when the youngest platform-as-a-service offering gets the highest ratings.

デベロッパーたちは、クラウド・プラットフォーム上の作業に数多くのメリットを見出すと主張する。そして、そこには、プロジェクト効率の改善や、Web サーバーやアプリケーション・サーバーといった、プラットフォームが提供するコンポーネントを活用する能力などが含まれる。しかし、最も新しい PaaS が、最も高い評価を得るとは驚きである。

imageAs might be expected, Google’s App Engine and IBM’s Smart Cloud rated as the top pick for public cloud and private cloud platforms, respectively, given the tools and components that both provide. But the top overall pick was VMware’s young Cloud Foundry, launched in mid-April and “a very notable newcomer’s entrance into the field,” wrote Michael Rasalan, author of the Evans Data November report, “Users Choice: 2011 Cloud Services.”

予想されるように、それぞれが提供するツールとコンポーネントが決め手となり,パブリックとプライベートのクラウド・プラットフォームのトップとしては、Google の App Engine と IBM の Smart Cloud が選出された。 しかし、全体としてのトップは、4月中旬に提供が開始され、このフィールドで注目を集めている、VMware の Cloud Foundry であったと、Evans Data November である「 Users Choice: 2011 Cloud Services 」で、Michael Rasalan は報告している。

“VMware’s Cloud Foundry … brings with it a novel approach to delivering cloud services that places more control in the developers’ hands. Perhaps for this reason, developers responded favorably to its offerings and ideas,” said Rasalan in an assessment of cloud rankings by 14 factors. In addition to being tops overall, Cloud Foundry was second to Google as a public cloud platform and second to IBM as a private cloud platform.

「 VMware の Cloud Foundry は、斬新なアプローチをもたらし、より多くの制御をデベロッパーに提供するための、クラウド・サービスを実現している。 おそらく、それが理由となり、 Cloud Foundry が実現するものと、その考え方に対して、デベロッパーたちは好印象を得ている 」と、14 項目により査定されたクラウド・ランキングにおいて、Rasalan は発言している。 また、Cloud Foundry は全体のトップであることに加えて、パブリック・クラウド部門としては Google に続く 2位であり、プライベート・クラウド部門では IBM に続く 2位に選出されている。

Evans Data assembled all the ratings so that they created a score that fell between 2000 and 2700. The distance between the leaders was not that great. While Cloud Foundry came in with a score (estimated from the Evans Data bar chart in the report) of 2695, Google was close behind at 2533, and IBM at 2500. AT&T’s Synaptic Compute Cloud showed up at 2400, HP’s Enterprise Cloud Services at 2390, and Amazon Web Services at 2300, the latter three with surprisingly strong showings, since they’re best known for offering plain infrastructure services more than developer platform services.

Evans Data が組み立てた評価により、これらの高得点プラットフォームのスコアは、2000 ~ 2700 ポイントの間に収まっているが、 その際は僅かであった。 Cloud Foundry のスコアは 2695 ポイントであり( Evans Data のレポートに含まれるバー・グラフから算定すると)、Google は 2533 ポイント、そして IBM は 2500 ポイントとなる。 その後のは、AT&T の Synaptic Compute Cloud が 2400 ポイント、HP の Enterprise Cloud Services が 2390 ポイント、そして Amazon Web Services が 2300 ポイントで続いている。 この三社が強さを見せている理由は、デベロッパー・プラットフォーム・サービスとしてというより、確実なインフラストラクチャ・サービスを提供する点が、評価されていると思われる。

imageSurprisingly, Microsoft’s Azure registered only 2100, slightly behind Salesforce.com’s Force.com at 2115. Evans Data surveys historically have been addressed to a body of independent, non-vendor-specific developers who rarely score Microsoft tools or services at the top of the pack. Other surveys and market research report Microsoft offerings in a stronger position. Nonetheless, with a key developer group, Microsoft’s Azure appears to be making little headway.

驚くべきことに、 Microsoft の Azure は 2100 ポイントであり、2115 ポイントを得た Salesforce.com の Force.com よりも後ろになっている。 従来から、Evans Data の調査は、特定ベンダーとの結びつきが強いデベロッパーを対象としないため、Microsoft のツールやサービスが上位に来ることは稀である。 そのため、他の調査やマーケット・リサーチでは、もっと上位に Microsoft はランキングされる。 ただし、主要なデベロッパー・グループからのレスポンスによると、Microsoft の Azure における進歩は、ごく僅かであると思われる。

Developers often produce software in the cloud because it’s easier to coordinate a geographically distributed team there. It’s also an environment where a variety of tools and supporting plumbing, such as connections to databases or Web services, may be found.

デベロッパーたちは、クラウド上で頻繁にソフトウェアを生産するが、地理的に分散されたチームを調整しやすくすることが、その理由となっている。 さらに、データベースや Web サービスにアクセスするための、多様なツールや接続を提供するための環境もある。

Cloud Foundry offers developers a broad set of open source tools and Java middleware that came with its acquisition of SpringSource, the supplier of the Spring lightweight Java development framework. In addition to Java, however, Cloud Foundry offers the Ruby scripting language and the Ruby on Rails rapid development framework, as well as lesser-known options such as Node.js and Sinatra.

Cloud Foundry は、オープンソースのツールと Java ミドルウェアの、広範囲におよぶセットをデベロッパーに提供するが、それらの Spring Lightweight Java 開発フレームワークは、その供給元である SpringSource の買収により実現されている。 しかし、Cloud Foundry は Java に加えて、ラピッド開発のための Ruby スクリプト言語や Ruby on Rails フレームワークを提供し、さらには、Node.js や Sinatra といった、将来のためのオプションも供給している。

imageDevelopers also like producing software in the cloud because, in some cases, the development environment closely resembles the deployment environment. By developing and testing software in the same architecture to which it’s to be deployed, developers often produce more reliable applications that run better in actual operations.

さらに、開発とディプロイのための環境に、共通性と持たせたいというケースにおいて、デベロッパーがクラウド上でソフトウェアを生産するケースがある。 ソフトウェアがディプロイされる環境とアーキテクチャで、その開発/テストを行うことで、現実的な運用環境で動作する、さらに信頼性の高いアプリケーションの生産が実現される。

“The ability to use any number of services in conjunction with the Cloud Foundry platform appears to appeal greatly to its users,” Rasalan wrote, The VMware offering also competed on price with its competitors.

「 Cloud Foundry プラットフォームと関連する、多種多様なサービスを利用できる環境が、ユーザーたちの関心を集めているように思われる」と Rasalan は記述しているが、VMware は価格政策においても、そのコンペティタたちと競合している。

But perhaps more important is the fact that services developed on Cloud Foundry can be deployed to either internal servers or several public infrastructure-as-a-service providers. RightScale, a cloud workload preparer and deployment service, has illustrated that Cloud Foundry (VMware has made it open source code) can be run on top of Amazon Web Services EC2. In addition, applications placed in VMware virtual machines can be distributed to VMware’s cloud partners, such as BlueLock or Colt.

しかし、それよりも重要なことは、Cloud Foundry 上で開発されたサービスが、インターナル・サーバーと、いくつかのパブリック IaaS プロバイダにディプロイできるという事実である。 クラウド・ワークロードに対応し、また、ディプロイメント・サービスを提供する RightScale は、Cloud Foundry が Amazon Web Services EC2 上で動作することを例証している (VMware は、それをオープンソースにしている)。 それに加えて、VMware 仮想マシン上に置かれたアプリケーションを、BlueLock や Colt のような、VMware クラウド・パートナーにディストリビュートすることも可能である。

Dave McJannet, director of VMware cloud and application services, said in an interview that developer choice in deployment as well as development “was clearly a priority” to the developers attracted to Cloud Foundry. Among other options, developers may run their applications in their own environments or even on their own laptops because VMware provides Micro Cloud Foundry for individual machines.

Mware の Cloud and Application Services ディレクタである Dave McJannet は、ディプロイメントにおけるデベロッパーの選択だけではなく、Cloud Foundry 上での開発にも「明確なプライオリティがある」と、あるインタビューで答えている。 その他のオプションとして、 デベロッパーたちは自身の開発環境だけではなく、ラップトップ上においても、そのアプリケーションを実行することが可能となる。 なぜなら、VMware は、それらのマシンに対しても、Micro Cloud Foundry を提供しているからだ。

The Spring Framework in Cloud Foundry will automatically deploy an application into the Cloud Foundry infrastructure at the push of a button. The foundry also provides a command line interface that will deploy an application to whichever public cloud the developer names, he added.

Cloud Foundry における Spring Framework では、対象となるアプリケーションを Cloud Foundry のインフラへ向けて、ボタンを押すだけで自動的にディプロイする。 そして更に、デベロッパーが指定するパブリック・クラウドへ向けて、コマンドライン・インターフェイスを用いてアプリケーションをディプロイすると、彼は付け加えている。

Cloud Connect’s comprehensive cloud computing workshops are back for 2012. To attend, register now with Priority Code CPMWCC07 for $100 off a Platinum Pass or Monday Workshops pass. It happens in Santa Clara, Calif., Feb. 13-16. Sign up now.

[ Want to know who VMware's five closest cloud partners are? See VMware's Maritz Predicts Hybrid Cloud Future. ]

ーーーーー

TAG indexこのところ、Cloud Foundry の評判が良いなぁと思っていましたが、この記事を読むと、その理由が分かるような気になります。そして、感心するのが Paul Maritz の手腕です。 適切な時期に、必要な会社を買収し、確実に育てて連携させていく。 Maritz の、一連の動きを見ていると、最強 Microsoft を演出してきたのは、Bill Gates ではなく、彼なんだろうと思えてきます。 ーーー __AC Stamp 2

ーーーーー

<関連>

VMware が目指す、クラウド OS への道とは?
NYSE と EMC と VMware が、ウォール・ストリートに浮かべるクラウドとは?
VMware を分析すると、OS を持たない 新しい Microsoft に見えてくる
VMware と Verizon の 超弩級 提携 と ハイブリッド・クラウドとは?
VMware は、クラウド・アーキテクチャを根本から変革する
VMware は知っている – クラウドでは仮想化が不要になることを

 

Heroku の Java サポートと、その背景について

Posted in PaaS, Salesforce by Agile Cat on September 1, 2011

Java developers, meet Heroku
By
Derrick Harris Aug. 25, 2011
http://gigaom.com/cloud/java-developers-meet-heroku/

_ Gigaom

Heroku, the popular Platform-as-a-Service offering initially for Ruby developers only, now supports Java. Actually, Heroku has added support for both the Node.js framework and the Clojure programming language over the past few months, but Java is in a whole other league. If it’s not the world’s most popular programming language, it’s certainly among the most popular — especially among enterprise developers.

Heroku は、人気の PaaS プラットフォームであり、当初は Ruby のみをサポートしていたが、いまでは Java にも対応する。 現実に、これまでの数カ月間において、Heroku は Node.js  フレームワークClojure プログラム言語を加えてきたが、まったく別のものとして Java もサポートする。 もし Java が、世界の最も人気のプログラム言語でなくても、とりわけ、エンタープライズ・デベロッパーの間では、人気の部類に入ることは否定しようがない。

imageHeroku has been gaining credibility among enterprise developers since becoming part of Salesforce.com in December, and part of courting those developers is providing the languages, tools and capabilities that they want. Certainly, though, Java is only part of the journey to woo developers who want to launch their applications in the cloud, as Heroku’s forays into Node.js and Clojure illustrate.

Heroku に関しては、昨年の 12月に Salesforce.com の一部になってから、エンタープライズ・デベロッパーからの信頼を蓄積してきた。そして、デベロッパーたちの期待に応えるために、彼らが必要とするプログラミング言語や、ツール、機能を供給している。 しかし、Heroku の斬新な試みである Node.js と Clojure が例証するように、クラウドでアプリケーションを立ち上げたいと考えるデベロッパーにとって、Java はオールマイティではない。

Likewise, PaaS providers of all stripes have been working to expand beyond their legacy developer bases. Just this week, Engine Yard bought PHP PaaS startup Orchestra to complement its Ruby on Rails prowess, and AppFog transitioned to a Cloud Foundry foundation to add support for languages beyond its PHP roots.

それと同様に、すべての PaaS プロバイダが、それぞれのレガシーな開発環境を拡張するために努力している。今週(8月下旬)のことだが、Engine Yard は Ruby on Rails の能力を補完するために、PHP PaaS スタートアップである Orchestra を買収した。 そして AppFog は、ルーツである PHP を超えた言語サポートのために、Cloud Foundry へと基盤を移行した

For more on programming with Java on the Heroku platform, which the company says eliminates many of the problems associated with J2EE, check out co-founder Adam Wiggins’ blog on the news.

J2EE と結び付けられた数多くの問題を解決するという、同社からの説明については、co-founder である Adam Wiggins のブログを参照して欲しい。

Related research and analysis from GigaOM Pro:

ーーーーー

clip_image001この Heroku と Ruby on Rails の関係のように、当初は一点突破を売りにしていたプラットフォームも、そのビジネスが拡大するにつれて、開発環境の多様化を求められるようです。それぞれの特徴が薄れてしまい、なんとなく残念な気もしますが、ビジネスを考えれば当然の選択なのかもしれません。 この領域でも、これからは垂直統合のアラシとなるのでしょうかね。 ーーー __AC Stamp 2

ーーーーー

<関連>

Facebook のようなエンタープライズ・ソフトウェアを作りたい – Salesforce は語る
Salesforce による Heroku 買収の続報
Salesforce が Heroku を $212 Million のキャッシュで買収

GW プチ特集 – Twitter の 2011年 1月~4月

Posted in Twitter by Agile Cat on April 30, 2011

最近は クジラ さんにお目にかかれませんが ・・・

_ Twitter

なんというか、磐石の体制で突き進む Facebook と比べてしまうと、やれ金がないだとか、API で貧乏サードパーティから金を絞りとるとか、ある意味で親近感を抱かせてくれる Twitter です。 Agile_Cat の最近の悩みは、WordPress から Twitter への API が機能しないことがあるという点ですが、API の場合はダメであってもクジラが出ないのが不満です。 う~ん、やはり Twitter は API が悩みどころだし、そこにブレークスルーがあるのでしょうね。 ーーー __AC Stamp 2

ーーーーー

February 3 : TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!

February 12 : Web メールの時代は 終わってしまうのか?

February 15 : TweetDeck の 140文字以上のツイートって、OK なの? NG なの?

February 17 : バルセロナの MWC での買収話を、あらためて否定する Twitter

March 17 : ありがとう Twitter! 災害時に発揮されたキミの実力をチャートで検証する

March 21 : Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する

March 22 : Happy Birthday Twitter – 5 歳になりました!

April 1 : Twitter が、新しいデータセンターへの移行を完了

April 2 : 日本の大震災で証明された Twitter と Facebook の SOS パワー

April 13: Twitter における、Ruby から Java への回帰とは?

April 14 : Twitter サーチを 3倍速にする新アーキテクチャとは? _1

April 15 : Twitter サーチを 3倍速にする新アーキテクチャとは? _2

April 17 : Twitter サーチを 3倍速にする新アーキテクチャとは? _3

April 17 : Twitter と Facebook の、人間関係すったもんだ

April 21 : Twitter API の利用が落ち込んでいる – 心配だ!

ーーーーー

どこかに身売りって言うのだけはやめてねと、せつに願ってしまう Twitter さんです。 ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter 2010 総集編 Agile_Cat 版

 

Twitter サーチを 3倍速にする新アーキテクチャとは? _3

Posted in Big Data, Twitter by Agile Cat on April 17, 2011

Twitter Search is Now 3x Faster
Wednesday, April 6, 2011
http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html

ーーーーー

これは、三部作の最終回です。初めての方は、1 と 2 をお先に ど~ぞ。

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3

ーーー __AC Stamp 2

ーーーーー

MULTIPLEXING INCOMING REQUESTS

Because workflows are mapped to Netty pipelines in Blender, we needed to route incoming client requests to the appropriate pipeline. For this, we built a proxy layer that multiplexes and routes client requests to pipelines as follows:

このワークフローは、Brender における Netty パイプラインにマップされるため、Incoming リクエストを、適切なパイプラインに送る必要があった。 そのため、以下のようなマルチプレックスのプロキシー・レイヤを構築し、パイプラインにクライアント・リクエストをルーティングしている:

  • When a remote Thrift client opens a persistent connection to Blender, the proxy layer creates a map of local clients, one for each of the local workflow servers. Note that all local workflow servers are running inside Blender’s JVM process and are instantiated when the Blender process starts.
  • When the request arrives at the socket, the proxy layer reads it, figures out which workflow is requested, and routes it to the appropriate workflow server.
  • Similarly, when the response arrives from the local workflow server, the proxy reads it and writes the response back to the remote client.
  • リモート Thrift クライアントから Blender に、永続的なコネクションをオープンするときに、このプロキシー・レイヤがローカル・クライアントを作成し、それぞれのローカル・ワークフロー・サーバーにマップしていく。 注意すべきことは、すべてのローカル・ワークフロー・サーバーが、Bernder の JVM プロセス内で実行され、また、Brender プロセスがスタートするときにインスタンス化される点である。
  • それらのリクエストがソケットに到着するとき、プロキシー・レイヤによる読み込みが行われ、求められるワークフローの種類が理解され、適切なワークフロー・サーバーへのルーティングが行われる。
  • それと同様に、それらのローカル・ワークフロー・サーバーからレスポンスが戻ったとき、対象となるプロキシーによる読み込みが行われ、リモート・クライアントへのレスポンスの書込みが完了する。

We made use of Netty’s event-driven model to accomplish all the above tasks asynchronously so that no thread waits on I/O.

それら全てのタスクを非同期化するために、Netty のイベント駆動型モデルを利用することで、I/O の待ち時間が排除された。

imageDISPATCHING BACK-END REQUESTS

Once the query arrives at a workflow pipeline, it passes through the sequence of service handlers as defined by the workflow. Each service handler constructs the appropriate back-end request for that query and issues it to the remote server. For example, the real-time service handler constructs a realtime search request and issues it to one or more realtime index servers asynchronously. We are using the twitter commons library (recently open-sourced!) to provide connection-pool management, load-balancing, and dead host detection.

ワークフロー・パイプラインに到着したクエリーは、対象となるワークフローで定義さたとおりに、サービス・ハンドラーのシーケンスを通過していく。 続いて、それぞれのサービス・ハンドラーが、対象となるクエリーに適したバックエンド・リクエストを構成し、リモート・サーバーへ向けて送り出す。 たとえば、リアルタイム・サービス・ハンドラーは、リアルタイム・サーチ・リクエストを構成し、複数のリアルタイム・インデックス・サーバーへ向けて、そのリクエストを非同期で発行する。私たちは、コネクション・プール管理および、ロード・バランシング、デッド・ホスト検出を提供するために、 Twitter コモン・ライブラリ(最近オープンソース化された!)を使用している。

The I/O thread that is processing the query is freed when all the back-end requests have been dispatched. A timer thread checks every few milliseconds to see if any of the back-end responses have returned from remote servers and sets a flag indicating if the request succeeded, timed out, or failed. We maintain one object over the lifetime of the search query to manage this type of data.

すべてのバックエンド・リクエストがディスパッチされると、そのクエリーを処理している I/O スレッドが解放される。 タイマー・スレッドは、数ミリ秒ごとにチェックを行い、リモート・サーバーから返されたバックエンド・レスポンスを確認し、トリガーとなったリクエストに対して、succeeded/timed out/failed といったフラグをセットしていく。 私たちのシステムでは、この種のデータを管理するために、サーチ・クエリーのライフタイムをカバーするよう、そのオブジェクトを保持している。

Successful responses are aggregated and passed to the next batch of service handlers in the workflow pipeline. When all responses from the first batch have arrived, the second batch of asynchronous requests are made. This process is repeated until we have completed the workflow or the workflow’s timeout has elapsed.

成功したレスポンスはアグリゲートされ、そのワークフロー・パイプライン内におけるサービス・ハンドラーの、次のバッチに受け渡される。 最初のバッチからの、すべてのレスポンスが到着したとき、非同時性のリクエストにおける 2番目のバッチが作成される。 そのワークフローが完了するまで、あるいは、ワークフローのタイムアウトが経過するまで、このプロセスは繰り返される。

As you can see, throughout the execution of a workflow, no thread busy-waits on I/O. This allows us to efficiently use the CPU on our Blender machines and handle a large number of concurrent requests. We also save on latency as we can execute most requests to back-end services in parallel.

ここまでに確認してきたように、ワークフローの実行を通じて、 I/O 上のスレッド・ビジー待ちは発生しない。つまり、Blender マシン上での CPU 利用および、大量のコンカレント・リクエスト処理において、効率化が実現される。 そして、並列化されたバックエンド・サービスで、大半のリクエストを処理するときには、レイテンシーを抑えることができる。

BLENDER DEPLOYMENT AND FUTURE WORK

To ensure a high quality of service while introducing Blender into our system, we are using the old Ruby on Rails front-end servers as proxies for routing thrift requests to our Blender cluster. Using the old front-end servers as proxies allows us to provide a consistent user experience while making significant changes to the underlying technology. In the next phase of our deploy, we will eliminate Ruby on Rails entirely from the search stack, connecting users directly to Blender and potentially reducing latencies even further.

このシステムに Blender を導入するのと並行して、高品質のサービスを保証するために、従来からの Ruby on Rails フロントエンド・サーバーをプロキシーとして利用し、Blender クラスタへ向けて Thtift リクエストを送っている。 フロントエンド・サーバーをプロキシーとして使用することで、基礎をなすテクノロジーに相当量の変更を施す間も、一貫したユーザー・エクスペリエンスの提供が実現される。 私たちの、次のディプロイ・フェーズでは、このサーチ・スタックから Ruby on Rails を完全に取り除き、ユーザーと Blender のダイレクトな接続を実現し、また、さらなるレイテンシーの低減を目指すだろう。

—@twittersearch

ACKNOWLEDGEMENTS

The following Twitter engineers worked on Blender: Abhi Khune, Aneesh Sharma, Brian Larson, Frost Li, Gilad Mishne, Krishna Gade, Michael Busch, Mike Hayes, Patrick Lok, Raghavendra Prabhu, Sam Luckenbill, Tian Wang, Yi Zhuang, Zhenghua Li.

ーーーーー

いやぁ~~~ 面白かったです。 このポストに関しては、いろいろな方から Twitter でコメントいただきました。 おかげさまで、とても多くの方が注目するアーキテクチャなのだと、実感することができました。 ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3
ーーーーー
Blenderに近いアーキテクチャになっているMessage Pack RPCのJava版の実装
Talk about Scala – SlideShare ( @yasushia さんより)
Twitter における、Ruby から Java への回帰とは?
ーーーーー
Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

Twitter サーチを 3倍速にする新アーキテクチャとは? _2

Posted in Big Data, Twitter by Agile Cat on April 15, 2011

Twitter Search is Now 3x Faster
Wednesday, April 6, 2011
http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html

ーーーーー

初めての方は、1 をお先に ど~ぞ。三部作になっています。

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3

ーーー __AC Stamp 2

ーーーーー

BLENDER OVERVIEW

Blender is a Thrift and HTTP service built on Netty, a highly-scalable NIO client server library written in Java that enables the development of a variety of protocol servers and clients quickly and easily. We chose Netty over some of its other competitors, like Mina and Jetty, because it has a cleaner API, better documentation and, more importantly, because several other projects at Twitter are using this framework. To make Netty work with Thrift, we wrote a simple Thrift codec that decodes the incoming Thrift request from Netty’s channel buffer, when it is read from the socket and encodes the outgoing Thrift response, when it is written to the socket.

Blender とは、Netty 上に構築された Thrift と HTTP のサービスであり、Java で記述されたスケーラブルな NIO クライアント・サーバライブラリにより、多様なプロトコルを用いるサーバーとクライアントを、迅速かつ容易に開発していく。たとえば、Mina や Jetty なども提供されるコンペティションの中から Netty を選んだ理由としては、整理された API や、洗練されたドキュメントなどが挙げられるが、それらよりも重要なのは、Twitter ににおける他のプロジェクトが、このフレームワークを用いている点にある。 Netty と Thrift を組み合わせるために、Netty のチャネル・バッファからの incoming Thrift のリクエストをデコードする、シンプルな Thrift コーデックを記述した。それは、ソケットからの読み込みと、outgoing Thrift レスポンスをエンコードするとき、また、ソケットへの書き込みを行うときに機能する。

Netty defines a key abstraction, called a Channel, to encapsulate a connection to a network socket that provides an interface to do a set of I/O operations like read, write, connect, and bind. All channel I/O operations are asynchronous in nature. This means any I/O call returns immediately with a ChannelFuture instance that notifies whether the requested I/O operations succeed, fail, or are canceled.

Netty は、Channel と呼ばれる重要な抽象概念を定義する。それにより、read/write/connect/bind といった I/O オペレーションを設定する、インターフェイスのためのネットワーク・ソケットへの接続がカプセル化される。 すべての Channel I/O オペレーションは、本質的に非同期である。つまり、あらゆる I/O コールが、要求された I/O オペレーションが succeed/fail/canceled されたことを通知する、ChannelFuture インスタンスを直ちに返すことになる。

When a Netty server accepts a new connection, it creates a new channel pipeline to process it. A channel pipeline is nothing but a sequence of channel handlers that implements the business logic needed to process the request. In the next section, we show how Blender maps these pipelines to query processing workflows.

Netty サーバーが新しいコネクションを受け入れるとき、その処理のためお、新しいチャンネル・パイプラインが作成される。 このチャネル・パイプラインは、リクエストを処理するために必要なビジネス・ロジックを実装する、チャネル・ハンドラーのシーケンスに過ぎない。次のセクションでは、それらのパイプラインと、クエリー処理ワークフローを、Blender がマップする方式を説明する。

WORKFLOW FRAMEWORK

In Blender, a workflow is a set of back-end services with dependencies between them, which must be processed to serve an incoming request. Blender automatically resolves dependencies between services, for example, if service A depends on service B, A is queried first and its results are passed to B. It is convenient to represent workflows as directed acyclic graphs (see below).

Blender において、ワークフローとは総合に依存するバックエンド・サービスのセットのことであり、incoming リクエストを取り扱うために処理されるものとなる。 そして Blender は、それらのサービス間の依存性を自動的に解決する。 たとえば、Service A が Service B に依存している場合には、最初に A がクエリーされ、その結果が B に手渡される。このワークフローを、非環式の有向グラフを用いて表現すると解りやすい(以下を参照)。

Sample Blender Workflow with 6 Back-end Services

In the sample workflow above, we have 6 services {s1, s2, s3, s4, s5, s6} with dependencies between them. The directed edge from s3 to s1 means that s3 must be called before calling s1 because s1 needs the results from s3. Given such a workflow, the Blender framework performs a topological sort on the DAG to determine the total ordering of services, which is the order in which they must be called. The execution order of the above workflow would be {(s3, s4), (s1, s5, s6), (s2)}. This means s3 and s4 can be called in parallel in the first batch, and once their responses are returned, s1, s5, and s6 can be called in parallel in the next batch, before finally calling s2.

上記のサンプル・ワークフローには、相互に依存する 6つの Service  {s1, s2, s3, s4, s5, s6} がある。s3 から s1 へ向けられた方向性を持つエッジは、s1 をコールする前に s3 をホールする必要性を示している。 その理由は、s1 が s3 の結果を要求する点にある。 このようなワークフローを前提として、Blender フレームワークは、それぞれの Service がコールされる順番を決定するために、DAG 上でのトポロジカル・ソートを行なう。 上記のワークフローにおける実行の順序は、{(s3, s4), (s1, s5, s6), (s2)} となるはずだ。つまり、最初のバッチにより、s3 と s4 をパラレルにコールできる。続いて、それらからのリターンの後に、s1 と s5 と s6 をパラレルにバッチ処理し、最後に s2 をコールする。

Once Blender determines the execution order of a workflow, it is mapped to a Netty pipeline. This pipeline is a sequence of handlers that the request needs to pass through for processing.

Blender がワークフローの実行順序を決定した後に、Netty パイプラインとのマップが行われる。 このパイプラインは、全体的な処理を通じて、受け渡しが必要なリクエストを、処理するためのシーケンスとなる。

ーーーーー

昨日の、okachimachiorz1 ジェイムズ・ブッカー先生によりますれば、『 Blenderすか。非同期+DAG+Scalaですか。まさにクラウド型のアーキテクチャです。 要チェックですな 』 とのことです。 なる! ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3
ーーーーー
Blenderに近いアーキテクチャになっているMessage Pack RPCのJava版の実装
Talk about Scala – SlideShare ( @yasushia さんより)
Twitter における、Ruby から Java への回帰とは?
ーーーーー
Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!
10億人のユーザーを目指す、Twitter の 6つの戦略とは?
日本の大震災で証明された Twitter と Facebook の SOS パワー
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

Twitter サーチを 3倍速にする新アーキテクチャとは? _1

Posted in .Selected, Big Data, Twitter by Agile Cat on April 14, 2011

Twitter Search is Now 3x Faster
Wednesday, April 6, 2011
http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html

clip_image001

ーーーーー

三部作になっています。続編も ど~ぞ。

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3

ーーー __AC Stamp 2

ーーーーー

In the spring of 2010, the search team at Twitter started to rewrite our search engine in order to serve our ever-growing traffic, improve the end-user latency and availability of our service, and enable rapid development of new search features. As part of the effort, we launched a new real-time search engine, changing our back-end from MySQL to a real-time version of Lucene. Last week, we launched a replacement for our Ruby-on-Rails front-end: a Java server we call Blender. We are pleased to announce that this change has produced a 3x drop in search latencies and will enable us to rapidly iterate on search features in the coming months.

2010年の春のことだが、 Twitter におけるサーチ・チームは、そのサーチ・エンジンを書き直し始めた。 その理由は、永遠に増大していくトラフィックに対処し、エンドユーザーにおけるレイテンシーとサービスの可用性を改善し、新しいサーチ機能の迅速な開発を可能にする点にあった。 その作業の一部として、Twitter のバックエンドを、MySQL  から Lucene のリアルタイム・バージョンに変更することで新しいリアルタイム・サーチ・エンジンを立ち上げている。 そして先週、私たちは Ruby-on-Rails のフロントエンドを、Blender という Java サーバーに置き換えた。 この変更により、サーチ・レイテンシーを 1/3 に低減し、今後の数ヶ月という短い期間において、いくつかのサーチ機能を改善していけるようになった。 このような発表ができて、とても嬉しく思う。

PERFORMANCE GAINS

Twitter search is one of the most heavily-trafficked search engines in the world, serving over one billion queries per day. The week before we deployed Blender, the #tsunami in Japan contributed to a significant increase in query load and a related spike in search latencies. Following the launch of Blender, our 95th percentile latencies were reduced by 3x from 800ms to 250ms and CPU load on our front-end servers was cut in half. We now have the capacity to serve 10x the number of requests per machine. This means we can support the same number of requests with fewer servers, reducing our front-end service costs.

Twitter サーチは、1日あたり 10億以上のクエリーをサポートするという、最も多くのトラフィックを発生させるサーチ・エンジンの 1つである。 この Blender をディプロイする前の週に、日本における #tsunami により、著しいクエリーが発生し、サーチ・レイテンシーに大きなピークが生じた。 そして、この Blender の立ち上げの後には、私たちの 95 パーセンタイル・レイテンシが、800ms から 250ms へと、約 1/3 に低減された。 さらに、フロントエンド・サーバー上の CPU 負荷は、半分にカットされた。 そして、今では、マシンごとのリクエストに関するキャパシティを、10 倍に引き上げる能力を持つに至った。 それにより、以前と同じだけのリクエスト量を、より少ないサーバー台数で処理することが可能となり、フロントエンド・サーバーに関するコストも低減できるようになった。

image

95th Percentile Search API Latencies Before and After Blender Launch

TWITTER’S IMPROVED SEARCH ARCHITECTURE

In order to understand the performance gains, you must first understand the inefficiencies of our former Ruby-on-Rails front-end servers. The front ends ran a fixed number of single-threaded rails worker processes, each of which did the following:

このパフォーマンス向上の理由を理解するには、以前の Ruby-on-Rails フロントエンド・サーバーの非効率について、最初に理解しなければならない。 このフロントエンドは、固定した数のシングル・スレッド Rails Worker プロセスを実行してており、個々のスレッドは以下の項目を処理していく:

  • parsed queries
  • queried index servers synchronously
  • aggregated and rendered results
  • パーズされたクエリー
  • クエリーされたインデックスのサーバー間同期
  • アグリゲーションとレンダリングの結果

We have long known that the model of synchronous request processing uses our CPUs inefficiently. Over time, we had also accrued significant technical debt in our Ruby code base, making it hard to add features and improve the reliability of our search engine. Blender addresses these issues by:

この同期プロセス処理のモデルが、CPU 非効率に消費していることを、私たちは以前から認識していた。 そして、長い時間を経ることで、この Ruby コードベース上にテクニカルな負債を大量に蓄積しており、サーチ・エンジンにおける信頼性の改善や、新しい機能の追加を難しくしていた。 そして、Blender により、以下の問題に取り組んでいる:

  1. Creating a fully asynchronous aggregation service. No thread waits on network I/O to complete.
  2. Aggregating results from back-end services, for example, the real-time, top tweet, and geo indices.
  3. Elegantly dealing with dependencies between services. Workflows automatically handle transitive dependencies between back-end services.
  1. 完全な、非同期アグリゲーション・サービスの構築。ネットワーク I/O の終了を、スレッドが待たない方式。
  2. バックエンド・サービスからの結果をアグリゲート。 たとえば、リアルタイムや、トップ・ツイート、地理インデックスなど。
  3. サービス間の依存性を、エレガントに取り扱う。 Workflows は、バックエンド・サービス間における、推移的な依存性を自動的に処理する。

The following diagram shows the architecture of Twitter’s search engine. Queries from the website, API, or internal clients at Twitter are issued to Blender via a hardware load balancer. Blender parses the query and then issues it to back-end services, using workflows to handle dependencies between the services. Finally, results from the services are merged and rendered in the appropriate language for the client.

以下のダイアグラムは、Twitter サーチ・エンジンのアーキテクチャを示す。  Twitter における Webサイト/API/内部クライアントからのクエリーは、ハードウェア・ロードバランサーを介して Blender に発行される。 Blender により解析されたクエリーは、サービス間に依存性を処理するワークフローを用いて、バックエンド・サービスへと発行される。最終的に、このサービスからの結果がマージされ、対象となるクライアントに適した言語でレンダリングされる。

Twitter Search Architecture with Blender

ーーーーー

大好評だった、昨日のポスト 『 Twitter における、Ruby から Java への回帰とは? 』の元ネタは、この Twitter Blog の記事です。 長いので、とりあえず Part_1 としてポストします。なお、Twitter で頂いたコメントは、Facebook Page に整理しています。 ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3
ーーーーー
Blenderに近いアーキテクチャになっているMessage Pack RPCのJava版の実装
Talk about Scala – SlideShare ( @yasushia さんより)
Twitter における、Ruby から Java への回帰とは?
ーーーーー

Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!
10億人のユーザーを目指す、Twitter の 6つの戦略とは?
日本の大震災で証明された Twitter と Facebook の SOS パワー
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

Twitter における、Ruby から Java への回帰とは?

Posted in Big Data, Twitter by Agile Cat on April 13, 2011

Once Again, Twitter Drops Ruby for Java
By
Alex Williams / April 11, 2011 4:00 PM
http://www.readwriteweb.com/cloud/2011/04/twitter-drops-ruby-for-java.php

_ Read Write

ーーーーー

<元ネタです>

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3

ーーーーー

Twitter has now moved its entire search stack from Ruby-on-Rails to Java. That’s a big shift. Twitter moved its back end message que from Ruby to Scala, a Java platform in the 2008-2009 time frame. The move was attributed to issues with reliability on the back-end. This latest move makes the shift pretty much complete. At Twitter, Ruby is out of the picture.

Image(28)

Twitter のサーチ・スタック全体が、Ruby-on-Rails から Java に移行された。 まさに、大きな変更である。 具体的に言うと、Twitter のバックエンド・メッセージ・キューが Ruby から、2008-2009 タイムフレームにおける Java プラットフォームである、Scala に移行したことになる。 この変化は、バックエンドにおける信頼性の問題に起因すると思われる。 この、最近に実施された変更は、その大方を完了し、Twitter からは Ruby が消えることになる。

Twitter explains the change on its engineering blog:

Last week, we launched a replacement for our Ruby-on-Rails front-end: a Java server we call Blender. We are pleased to announce that this change has produced a 3x drop in search latencies and will enable us to rapidly iterate on search features in the coming months.

Twitter の engineering blog では、この変更について、以下のように説明されている:

Last week, we launched a replacement for our Ruby-on-Rails front-end: a Java server we call Blender. We are pleased to announce that this change has produced a 3x drop in search latencies and will enable us to rapidly iterate on search features in the coming months.

先週のことだが、Ruby-on-Rails によるフロントエンドを、Blender と呼ぶ Java サーバーに置き換えた。 この変更により、サーチのレイテンシーが 1/3 に抑えられたことを発表できて嬉しい。 そして、今後の数ヶ月のうちに、複数のサーチ機能について、迅速なイテレーションが可能となる。

imageDoes this mean that Java is better than Ruby for services with heavy loads?

つまり、大きな負荷を伴うサービスに関しては、Ruby よりも Java の方が適しているのだろうか?

Ganeshji Marwaha, director at Triomatrix Webservices, says it all depends:

Wow, that is quite an achievement. Could this mean that Java is a better platform than Rails for high scalability needs? Even if that is the case, for simpler scenarios, the beauty of RoR out-weighs Java’s performance.

They say that this change will enable them to rapidly iterate on search features in the coming months. That along with the news that Twitter has hired 25 more employees kinda tells that Java’s code base is practically more maintainable than equivalent Ruby code – at least when the code base is huge and the team size is large. Or that could mean that this time they really put a lot of thought into designing a maintainable system than when they started out. But for smaller team size and code base, RoR is still an unbeaten champion.

Triomatrix Webservices のディレクターである Ganeshji Marwaha は、すべてが依存すると発言している:

Wow ! それは、なかなかの成果だ。 それにより、高度なスケーラビリティの要求において、Java が Rails よりも優れたプラットフォームであると、捉えられるのだろうか? たとえ、そのようなケースであるにしても、よりシンプルなシナリオにおいては、RoR の美しさが Java のパフォーマンスに勝る。

Twitter は、今後の数ヶ月のうちに、複数のサーチ機能について、迅速なイテレーションが可能になると言っている。 この、Twitter が 25人の技術者を採用したというニュースによると、Java と Ruby のコードを比較して、Java の方がメンテナンスしやすいと捉えられる。少なくとも、そのコードベースが巨大である、さらにチームの規模が大きいときには、そうなる。 また、今回の変更においては、Twitter がスタートしたときと比べて、さらにメンテナンスが容易になる、たくさんの新しいアイデアが投入されたのかもしれない。 しかし、小規模なコードベースとチームを前提にするなら、依然として RoR が無敵のチャンピオンである。

You can read the full account about the new search capabilities with Java on the Twitter blog post. It goes into detail about the changes and the benefits that it is seeing with the switch.

なお、Twitter のブログ・ポストで、Java を用いた新しいサーチ機能に関する、詳細な記述が読める。 そこでは、今回の切り替えにおける、変更とメリットに関する細部が述べられている。

ーーーーー

先日の 『 MySpace を殺したのは Microsoft ソフトウェア・スタックなのか? いや、それは違うだろう 』 では、Twitter においても RoR を、そのまま使っていることなどあり得ないと、Todd Hoff さんが説明していました。そして、今回の変更は、Java への回帰という、とても興味深いものになっています。 MySpace の失速も、開発のための環境やツールを、使いこなせる人材の確保の難しさが原因とのことであり、ハイ・スケーラビリティの難しさを感じさせてくれます。ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!
10億人のユーザーを目指す、Twitter の 6つの戦略とは?
日本の大震災で証明された Twitter と Facebook の SOS パワー
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

Web デベロッパーが知っておくべき、15種類の オープンソース・プロジェクト

Posted in API, Big Data, Research by Agile Cat on January 27, 2011

15 open source projects you should know about as a web developer
Posted in Main on January 25th, 2011 by Pingdom
http://royal.pingdom.com/2011/01/25/15-open-source-projects-you-should-know-about-as-a-web-developer/

_ pingdom

Building websites and web applications today is not only about being a great programmer, it’s even more important to be a smart programmer. This means to re-use existing code and applications when possible instead of re-inventing the wheel.

現代的な Web サイトおよび Web アプリケーションを構築するには、素晴らしいプログラマーであること、そして更に、スマートなプログラマーであることが重要である。 つまり、全体を再構築する代わりに、既存のコードやアプリケーションの再利用を考えることが、スマートなプログラマーの条件となる。

Open source has been around for ages and much of the web is built using it. Every developer knows about Linux, Apache, MySQL and PHP (LAMP).

オープンソースは長い歴史を持っており、また、それを用いて、多数の Web が構築されている。 そして、すべてのデベロッパーが、Linux と、Apache、MySQL、PHP の総称である LAMP を知っている。

But what about all the other open source projects out there? As a web developer you can save lots of time or optimize the performance of your applications by using many of the other projects that’s available.

しかし、その他のオープンソース・プロジェクトについて、その存在を知っているだろうか? Web デベロッパーとして、それらの多様なプロジェクトを活用することで、開発時間の大幅な短縮と、パフォーマンスの最適化が、あなたのアプリケーションにもたらされる。

Lets take a look on what’s out there, free for everyone to use.

さぁ、誰もがフリーで利用できる、それらのプロジェクトを見ていこう。

New databases on the block

Traditionally you might have been using MySQL. Although MySQL still is a great database many new alternatives has shown up trying to solve some of the issues MySQL has.

これまでにも、MySQL を使ってきたかもしれない。 依然として、MySQL は偉大なデータベースであるが、それに代わる新しいプロジェクトが、MySQL の問題を解決するものとして注目されている。

MongoDB

MongoDB is one of the new so called “NoSQL” databases. It’s scalable and offers high performance.

MongoDB は、いわゆる ”NoSQL” データベースの 1つである。 そして、スケーラビリティと高度なパフォーマンスを提供している。

Apache Cassandra

Apache Cassandra is similar to MongoDB in that it’s a “NoSQL” database, which is scalable, and offers high performance. It works well with very large and active data sets.

Apache Cassandra も、”NoSQL” データベースという意味では MongoDB に類似している。 しかし、さらに大規模でアクティブなデータセットに対して、スケーラビリティと高度なパフォーマンスを提供する。

More

There are lots of more alternatives out there to choose from depending on your needs. Take a look at this list in Wikipedia.

それ以外にも、ニーズに応じて多様なプロジェクトを選択できる。 この、Wikipedia のリストを参照して欲しい。

Cache your data

As some data is used frequently it makes sense to put it in memory instead of querying a database each time. This can speed up a web application greatly.

なんらかの、頻繁に使用されるデータが存在するとき、毎回のようにデータベースにクエリーをかけるのではなく、イン・メモリで処理することは、とても意味がある。 それにより、Web アプリケーションの処理速度が大幅に改善される。

Memcached

Memcached is a simple but powerful way to cache small chunks of data in memory.

Memcached は、小さなチャンクのデータを、インメモリでキャッシュする際の、シンプルだがパワフルな方式を提供する。

Redis

Redis can be used in the same way as Memcached but also includes many more features. For example it can also store data persistent on disk.

Redis も Memcached と同じ方式で利用できるが、より以上の機能を含んでいる。 たとえば、取り扱うデータを、パーシスタントなものとして、ディスクにストアすることも可能である。

Speeding up web requests

Most websites use the Apache web server to serve pages. This works great for most sites, but as soon as you start to get lots of traffic you might want to optimize things a bit.

数々の Web サイトにおいて、そのページを表示するために Apache Web サーバーが用いられている。 それらは、大半のサイトにおいて適切に機能しているが、膨大なトラフィックが生じてくると、その最適化が必要になるはずだ。

NGINX

NGINX is a web server, much like Apache, but it’s extremely fast. It’s often used to serve static content such as images or as a load balancer.

NGINX は Apache に似た Web サーバーであるが、きわめて高速なものとなっている。 写真などのスタティックなコンテンツの提供などで頻繁に使用され、また、ロード・バランサーの役割を担うことも多い。

Varnish

Varnish is a cache that you put in front of your regular web server. It works by putting all your popular content in memory and serves it directly, instead of having to pass everything on to your web server.

Varnish は、一般的な Web サーバーのフロントに配置するキャッシュである。 それは、通常のコンテンツをインメモリに保持し、また、ユーザーに対してダイレクトに提供する。

Manage your content easily

If you’re building a website which will have content that will be added and edited by writers you want to have a content management system (CMS). A CMS makes it easy to manage blogs and websites and also offers lots of plugins that can extend the functionality of your site.

コンテンツ・ライターが追加・編集する Web サイトを構築していく場合は、CMS(content management system)が必要となる。 CMS により Blog と Web サイトの管理が容易になり、また、たくさんの Plug In におりサイトの拡張が実現される。

WordPress

While WordPress is a blogging platform it can also be used to manage whole websites, big and small.

WordPress はブログ・プラットフォームであるが、大小の Web サイトを管理するためにも利用できる。

Drupal

Drupal is a complete platform that can be used to build scalable and flexible websites.

Drupal は、スケーラブルで柔軟な Web サイトを構築するための、完璧なプラットフォームである。

More

There are lots of Content Management Systems available. See this huge list at Wikipedia.

その他の Content Management Systems に関しては、Wikipedia の膨大なリストを参照して欲しい。

Having a interactive web user interface

Today you can build a web application that works in many ways just as a desktop application using techniques such as JavaScript and AJAX. Using JavaScript frameworks it has become really easy to build great web applications.

JavaScript や AJAX などのテクノロジーを用いて、まさにデスクトップ・アプリケーションのように機能する Web アプリケーションを、さまざまな手法で構築できる。 JavaScript のフレームワークを活用することで、素晴らしい Web アプリケーションの構築が、きわめて容易になった。

JQuery

JQuery is a framework with plugins to help build dynamic websites with AJAX interaction and animations.

JQuery は、AJAX のインタラクションとアニメーションを用いて、動的な Web サイトの構築を促進するフレームワークである。

MooTools

MooTools is just like JQuery a framework to help build powerful web applications using Javascript.

MooTools は JQuery ライクなフレームワークであり、Javascript を用いたパワフルな Web アプリケーションの構築を促進する。

More

If you want to try any of the other alternatives look through the list in this Wikipedia entry.

その他のプロジェクトに関しては、Wikipedia のリストを参照して欲しい。

Other cool stuff

When you start to build complex web applications there are lots of software, libraries and modules that can help you solve problems that would otherwise take a lot of time. Below are two examples just to get you started.

複雑な Web アプリケーションの構築に着手するとき、膨大な時間を費やすことになる問題の解決を促進するための、ソフトウェア/ライブラリ/モジュールがある。以下の 2つの例は、まさに構築を開始するときに、利用するものである。

Node.js

Node.js is an event-driven I/O framework where you write applications in Javascript that runs on the V8 JavaScript engine. It’s a great way to build fast and scalable network programs.

Node.js は、V8 JavaScript エンジン上で実行される Javascript を用いて、アプリケーションを記述する場合の イベント・ドリブンな I/O フレームワークである。それにより、高速でスケーラブルなネットワーク・プログラムの構築が促進される。

RabbitMQ

RabbitMQ is a reliable and scalable messaging system that can handle high throughput. If you need to exchange data between systems or applications a messaging system is a great way to do this with lots of benefits compared to a custom solution or storing the data in a database.

RabbitMQ は、ハイ・スループットに対応し、信頼性とスケーラビリティを実現する、メッセージング・システムである。 システムおよびアプリケーションの間で、データ交換を行う必要がある場合には、カスタムなソリューションやデータベースへのストアに替えて、メッセージング・システムを活用することで、数多くのメリットがもたらされる。

Use a framework to speed up development

Weather you are using PHP or another language there are several different frameworks available that can help you speed up development and make your code easier to manage.

PHP を使うにしろ、その他の言語を使うにしろ、その開発速度を高め、コードの管理を容易にするための、数々のフレームワークが存在する。

Symfony

Symfony is a PHP framework that includes components and tools to help you build complex web applications faster. It also has over 1000 plugins contributed by the community.

Symfony は、複雑な Web アプリケーションを短期間で構築するための、コンポーネントとツールを取り込んだ、PHP フレームワークである。さらに言えば、コミュニティからコントリビュートされた、1000 個以上のプラグインも利用できる。

Ruby on Rails

For fans of the Ruby language, Ruby on Rails is the most popular framework available.

Ruby ファンための、最も人気のあるフレームワークが Ruby on Rails である。

Django

Django is a Python web framework developed to help you build high-performing and elegant web applications quickly.

Django は、ハイ・パフォーマンスで洗練された Web アプリケーションを促進するために構築された、Python Web フレームワークである。

More

See this list on Wikipedia for a more complete list of web application frameworks available for different languages.

さらに詳細な情報に関しては、Wikipedia における 言語別アプリケーション・フレームワークを参照して欲しい。

Spend your time wisely

As a developer it’s always worth the time to keep up to date on which new software that are available as it can help you solve complex tasks easily. Often time spent planning and doing research at the start of a project is well worth it since you can identify upcoming issues and how to solve them in the best way. The days where you program your way out of every issue are over, it’s more about using existing technology in a smart way.

デベロッパーとして重要なことは、ソフトウェアを最新の状態に保ち、複雑なタスクを容易に解決できるようにしておくことだ。プロジェクトを開始するときに、計画と調査に時間を費やすことで、問題の識別が促進され、解決のための最適な方式が見つかる。そして、すべての問題を独自の方式で解決することは、すでに古い考え方となっており、よりスマートな方法で、既存テクノロジーを活用することに、価値が見出されている。

ーーーーー

この、Agile_Cat も利用している WordPress は、典型的な LAMP スタックの上に構築されている Web アプリケーションです。しかし、最大の LAMP スタックといえば、それは Facebook になるでしょう。 こうしたオープンソース・プロジェクトにより、インターネットの記録とスケールの記録が、毎日のように塗り替えられているわけです。 スゴイ! ーーー __AC Stamp 2

ーーーーー

<関連>
Facebook における 1300万/秒 クエリーの秘密
Facebook の HBase は、毎月 1350億 メッセージを処理する!
Facebook は 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!
Google Megastore – 1日で 30億 Write/200億 Read のトランザクションを実現
Amazon S3 – 5 TB のシングル・オブジェクトは お好き?

 

%d bloggers like this: