kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
MySQL Clusterが苦手とするJOINを如何にして克服するべきか。
シェアードナッシング型の負荷分散機能を持ち、なおかつ同期レプリケーションによるHA機能まで備えたMySQL Cluster最大の弱点といえば、JOINの遅さであろう。MySQL ClusterのJOINは偽りなく遅い。JOINを多用するアプリケーションでMySQL Clusterを利用するのはある意味マゾヒスティックな行為であると言えよう。何故MySQL ClusterはJOINが遅いのか？それはMySQL Clusterが分散データベースだからである。 ご存じの通り、MySQLにおけるJOINのアルゴリズムにはNested Loopしかない。他のストレージエンジンを利用していればそれでも十分実用に耐えうるぐらい高速なのだが、MySQL Clusterの場合はそうはいかない。JOINでは自ずとストレージエンジンからデータをフェッチする回数が増えるが、MySQL Clusterの場合レコード
PFIインターンに行ってきました。 - Blog by Sadayuki Furuhashi
8月1日から8月31日までの１ヶ月間、PFI夏期インターンに行ってきました。 はてなインターンの 講義・課題・チーム 形式とは趣を異にして、個々人が何か１つのプロジェクトに取り組む方針で進みました。取り組むテーマは 新たに取り組みたい/今取り組んでいる 内容を前提に、既存の問題の中から近いテーマを見つけます（あるいはこじつける^^;）。 インターンの期間中の１ヶ月か２ヶ月の間に成果を出すのが目標！ 取り組むテーマはスムーズに決まりました。何か自社で製品を作っていれば普通かと思いますが、探せば問題はいくらでもあるモノです^^ ちなみにPFIの製品は、全文検索エンジンやレコメンドエンジンなどです。 私は以下の４つのプログラムを実装しました： 既存の実装に代わるRPCフレームワーク MessagePack-RPC for PFI クラスタ管理ツール clx プロセス管理ユーティリティ daemo
EhcacheがTerracottaに加わる
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
連載記事 「Heartbeatでかんたんクラスタリング」
Heartbeatの特徴とユニークな機能 連載：Heartbeatでかんたんクラスタリング（1） オープンソースソフトウェアの「Heartbeat」をご存じでしょうか？ これを使い、Linux上でHAクラスタを構成する方法を紹介します
L'eclat des jours(2008-11-20)
_ ACIDからBASE ちょっと勉強。 BASE：ACIDの代わりをどうぞ 要約(のつもりだったがのりで)抄訳：（誤読は十分あり得る） これまでは垂直拡散（うまい訳はなんだろう？ vertical scaling）ってのがひとつの方法だった。よりパワフルなマシンへ移行するという道筋だ。何より簡単だってのがいいところ。でも、問題がある。どこまででもでかくできるわけでもないし、何より金食い虫だ。 それに対して水平拡散（horizontal scaling）ってのもある。いや、でもこれは複雑になる。この場合は、2次元で考えるといいね。横方向は機能分割。縦方向は断片化だ。Oracleのパーティショニングあたりとかかな。 機能分割はいいんだけど、そうなると1つのトランザクションが複数のデータベースサーバーをまたがる必要が出てくる。 エリック?ブルーワっていうバークレーの先生で、インクトミの首席サイ
米Amazonのクラウドサービス「EC2」が正式版に、99.95％のSLA提供 | OSDN Magazine
Amazon.comの子会社Amazon Web Services（AWS）は10月23日（米国時間）、ベータ版として提供してきたクラウドサービス「Amazon Elastic Compute Cloud（Amazon EC2）」を正式版にすることを発表した。また、「Windows Server」に対応したEC2ベータ版の提供も開始した。 EC2は、AWSが2006年8月に提供を開始したサービス。開発者や企業にクラウドサービスのコンピューティングキャパシティを重量課金制で提供する。正式版では、稼働率99.95％のサービスレベル合意（SLA）も導入し、顧客に信頼を提供するとしている。 EC2はこれまで、UNIXとLinuxに対応していたが、今回、Windows Serverと「Microsoft SQL Server」などWindows技術にも対応、Windows対応はベータ版として提供する
＠IT Special：ITインフラ全体の“正しい仮想化”を実現するデル／イコールロジックのストレージ
サーバを仮想化することで ストレージをオーバースペックにしていませんか？ ITインフラ全体の“正しい仮想化”を実現する デル／イコールロジックのストレージ ITシステムの管理負荷の増大や、リソースが効率的に配置されていないために投資対効果がよくないといった、企業の抱える問題を解決する技術として「仮想化」が注目されている。仮想化が問題解決のキーテクノロジーであることは、もはや疑う余地がない。ただし、仮想化といえば「サーバの仮想化」と思い込んでいないだろうか。そのバックエンドにあるストレージを見落としてしまうと……。 まず、仮想化というトレンドが起こった背景についてまとめておこう。 技術が高度化し、管理対象となるアプリケーションやデータが急激に増加したことで、IT管理者は慢性的に不足している。このため、ハードウェアコストは年々低下しているにもかかわらず、運用やメンテナンスといったサービスコスト
Amazon Web Services Developer Community : Building GrepTheWeb in the Cloud, Part 1: Cloud Architectures
This two-part series of articles illustrates how to build applications using Amazon Web Services by describing how Alexa's GrepTheWeb service was built. AWS Products Used: By Jinesh Varia, Amazon Web Services Introduction Cloud Architectures are designs of software applications that use Internet-accessible on-demand services. Applications built on Cloud Architectures are such that the underlyin
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
【詳報】「Google App Engine」ってなんだ − ＠IT
2008/04/08 米グーグルは3月7日、「Google App Engine」を発表し、ついにクラウド向けサービスに参入した。この市場では米アマゾンが先行。フルスタックのWebアプリケーション環境を提供することを武器に、グーグルは新たな開発者の取り込みを狙う。Google App Engineの速報記事はこちら。 公開したGoogle App Engineのプレビュー版は1万人の限定サービス。大量のドキュメントとWindows、Mac、Linux向けのSDKがすでに用意されている。 Google App Engineのメリットはグーグルの各サービスを運用する高信頼なインフラを使って、Pythonで書いたアプリケーションを実行できることだろう。インフラとは具体的には分散ファイルシステムの「GFS」や、データストレージシステムの「BigTable」だ。Google App Engineのブ
はてなは京都移転するけど、インフラは東京、という話 - stanaka's blog
はてなの京都移転話も、もうはや周回遅れ気味ですが、あまり気にせずにいきます。ちなみに、今回のエントリの結論はタイトルそのままで、データセンターは京都に移転しません、ということです。 これまで、はてなはデータセンターの移転を二度経験しています。一回目は、京都から東京で1日半ほどサービスが停止しました。その後、鉢山からさくらインターネットのiDCへ1年ほどかけて徐々に移転しました。この時は、各サービスが最大半日程度停止しました。 今回の京都移転を計画していた時もid:jkondoはいつもの調子で、自前サーバからさらに自前DCなんてどうどう？、などと言うのですが、300台程度の規模では自前DC建設の初期コストは賄えないし、また移転のために長い時間サービスを止めれられる状況でもないでしょう、ということで(幸いなことに)没になりました。やれやれ。 id:naoyaもはてなのインフラの仕事から卒業して
とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
DRBD+Heartbeatでお手軽HA Cluster VA Linux Systems Japan
サーバを運用する際の問題の一つとして故障時の対応があります。高価なシステムを構築すればストレージはSANで構築し、サービスのフェイルオーバーも高価な商用ソフトを導入することで実現することは可能です。しかしながら、「そこまでコストをかけて構築しなくても、、、」といった場合もあるかと思います。そのような場合の解決策の一つとして、本編ではDRBD + Heartbeatというオープンソース・ソフトウェアを用いて、HA Clusterを構築する方法を解説します。以下、<host_m>と<host_s>という2台のサーバを用いた構成手順を紹介します。 DRBDとは、Distributed Replicated Block Deviceの略で、本家WEBサイトは http://www.drbd.org/ になります。具体的にDRBDは何をするものか？というと、パーティション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Archived MSDN and TechNet Blogs | Microsoft Docs
10GbE is Ready for Your Cluster. Or is it?
Online Solver の計算機サーバ - 最適化問題に対する超高速＆安定計算
Google Code Archive - Long-term storage for Google Code Project Hosting.
MySQL 5.1 リファレンスマニュアル :: 14 MySQL Cluster
Linux-HA