移転しました http://please-sleep.cou929.nu/20130121.html
This article was contributed by Havoc Pennington Havoc Pennington is a developer at Typesafe, the Scala company. In the past he's worked on everything from web apps to Linux UI toolkits to JavaScript runtimes. Last Updated: 08 June 2012 akka cedar scala Table of Contents Web Words Overview: a request step-by-step Akka: Actor and Future Scala Bridging HTTP to Akka Connecting the web process to the
Scala でもやるかとぶつやく同僚を見て, たしかに Scala したいかも...などと意思の弱い私は気をそそられ, しかし特に書くものも思いつかずなんとなくウェブをぶらぶらしていた. そういえば Heroku が Scala をサポートしたニュースを読んだっけと検索すると, たしかにアナウンスがあった. このアナウンスにあるサンプルコードは面白い. Lift でも Play でもなく, Twitter の RPC フレームワークである Finagle が使われている. Finagle でサンプルを書いた理由の一つは画面におさまる簡潔さ, あとは流行り物の目新しさだろうけれど, Heroku の勧める Polyglot Platform の ありかたを示す意味もある気がしなくもない. Polyglot Polyglot という言葉を最初に目にしたのは プロダクティブプログラマ だったと思
ZooKeeperServerSetCluster を使って Finagle サーバのクラスタをつくってみました。 まずはデモをご覧ください。発表会のときに動画を用意しておけばよかったのですが、そこまで手が回りませんでした。 個々の Finagle サーバはそれぞれ単体のサーバとして立ち上がっているだけであり、サーバ側でお互いを意識している訳ではありません。 Finagle クライアント側に ZooKeeper への接続設定と、サーバの接続先(java.net.SocketAddress)情報のリストを持たせます。これらの情報を ClientBuilder で渡すと、リクエストのロードバランシングや障害検知、フェールオーバーなどをよしなにやってくれるようになります。 今回のデモのソースコードは GitHub で公開しています。ZooKeeper さえ起動していれば割と簡単に動かせると思いま
管理が困難―分散処理の常識はZooKeeperで変わる:ビッグデータ処理の常識をJavaで身につける(8)(1/3 ページ) Hadoopをはじめ、Java言語を使って構築されることが多い「ビッグデータ」処理のためのフレームワーク/ライブラリを紹介しながら、大量データを活用するための技術の常識を身に付けていく連載 分散処理の課題が「管理」なのは常識 複数の計算機上で動作(分散)するアプリケーション、ソフトウェアが多く存在します。分散ソフトウェアは複数の計算機で動作することで大量のデータを扱えたり、高負荷な状況に対処します。本稿では、複数の計算機(クラスタ)で動作する各サーバを「インスタンス」と呼びます。 本連載で紹介した分散Key-Valueデータベースである「HBase」は複数の計算機で動作する代表的なソフトウェアです。両ソフトウェアはともに「Apache ZooKeeper」(以下、Z
ちょっと前に「thriftって便利らしいよー」って話を聞いていたのだけれども、なかなか手をつけられずにいたらはてなブックーマークで使われているらしいという噂を聞いたり、Thriftを使って俺俺Key-Value Storeを作ったのように、TXを使ったThriftの紹介などが出てきたりしたのでそろそろ自分でも試したいなあと思い、試しました。で、先に結論を言っておくとThrift、とても気に入りました。とても簡単に処理用の専用サーバをたてることができて、かつ簡単にクライアントから処理要求が送れます。ボクは今まではRESTFulな感じでhttpでこのタスクをやっていたのですが、RESTFulな専用サーバをたてるのは結構開発コストがかかるんですよね。その点で、Thriftは開発コストはとても落ちると思うのでとても気に入っています。なんといって言語バインディングを自動で生成してくれるのは本当に開発
協調型分散システムに必要な Peer to Peer (以下PTP) RPC サービスインフラストラクチャを構築するための通信端点の設計について。コンポーネントと役割ベースでの記述となります。プロトコルは別途。 抜けている点など多々存在していると思いますのでご意見などをコメント頂けると幸いです。 概要 SOAP, Thrift, RMI など従来の RPC の多くはクライアント-サーバ型で構成されています。これは主 (Server) の提供するサービスを従 (Client) から利用するという一方通行の利用形態です。 この構成はサーバ側からクライアントへ通知を行う必要があるようなシステム設計とはうまく適合しません。例えばサーバで行なっている非同期処理の結果通知が必要な場合、ロングポーリングのような実装で回避するか、さもなくばサーバからクライアントへ逆方向の RCP 接続を行う必要があります
Nettyと言えばJavaのノンブロッキングIOのAPIであるNIOをラップしたフレームワークとして、TwitterのFinagleなどで分散ネットワークアプリケーションシステムで使わていて高速で実績のあるライブラリとして有名ですが、ノンブロッキングIOでイベント駆動のサーバークライアントのネットワークアプリケーションを知るのに非常に良い題材ですので、素人翻訳ですがその日本語訳を公開することにしました。 ちなみにNettyがどれぐらいパフォーマンスに優れているのかというと、Herokuの仮想インスタンスを利用した実験の結果が参考になります。Scala(Finagle)がNettyの実装を利用したものになりますが、秒間6000リクエスト時の1dyno(APサーバー)の応答が秒間4000レスポンスで、C(Accept)、Java(Jetty)、Java(Tomcat)、Js(Node)、Pyt
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く