Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 （この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題」の続きです） キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に（友人たちの）情報を集めることがで
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の巨大なシステムは、3つのデータセンターにある約3万台のサーバと、PHP、C++、Memcache、MySQLなどのソフトウェア群によって支えられています（同社のデータセンターの巨大さは、記事「3億のユーザーを抱えるFacebookのデータセンター。移動は自転車、希望は100Gbイーサネット 」を参照）。 同社の技術担当バイスプレジデント Jeff Rothschild氏は、Facebookが実現している大規模なスケーラビリティを、いかにしてこれらのソフトウェアで実現しているのか、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Mas
データベースのスケーラビリティをどうやって向上させるか
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア
Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア Twitterは独自に開発した分散フレームワークの「Gizzard」をオープンソースとして公開しました。GizzardはScalaで書かれたJavaVM上で動作するミドルウェアで、PHPやRubyといったWebアプリケーションからの要求を自動的にデータベースに分散することで、大規模で可用性の高い分散データベースを容易に実現するためのものです。 Gizzard：フォルトトレラントな分散データベースを実現 The Twitter Engineering Blog: Introducing Gizzard, a framework for creating distributed datastores Twitterのブログにポストされた「Introducing Gizzard
AMDが、ARMベースのサーバ用プロセッサ開発を正式表明。データセンター向けに消費電力当たりの処理能力向上が飛躍的向上へ
AMDは10月29日、64ビットARMベースのサーバ向けプロセッサを開発し、2014年に出荷すると発表しました。このプロセッサは、2012年に買収したSeaMicroの高密度サーバシステムへも組み込まれる予定です。 おもにクラウドのサーバ分野ではこれまで、x86プロセッサがあらゆる用途に用いられる方向で急速に発展してきました。しかし最近では小さな処理要求が大量に発生するケースが急速に増加。ARMプロセッサはx86プロセッサよりもこうした処理に適しており、電力消費量当たりの処理性能を飛躍的に高めることができるとAMDは説明しています。 サーバ向けプロセッサに波乱を起こせるか？ ARMプロセッサはその低消費電力という特徴ゆえに、以前からサーバ向けプロセッサとしても有望視されていました。AMDがARMと一緒にARMベースのサーバ向けプロセッサを開発することは以前から十分予想されていたことです。い
Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート
Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート 「2011年1月にHigh Replication Datastoreを立ち上げて以来、App Engineでこれだけ大規模なシステム障害を経験したことはなかった」。グーグルのGoogle App Engine Blogは10月26日付けのエントリ「About today's App Engine outage」でこう書き、同日発生したApp Engineの障害について報告しました。 この障害は10月26日のおおよそ午前7時半から11時30分までの約4時間、 App Engineのリクエストの約半分が失敗するという大規模なものでした。同社は以下のように経緯を説明しています。 ルータへの負荷が全データセンターへ拡大 4:00 am - Load begins increasing o
グーグルのBigtableが耐障害性を強化、Megastoreレプリケーションで
グーグルがGoogle App EngineやGoogle Appsのデータベースなどのデータベースとして利用しているのが、「Bigtable」と呼ばれるキーバリュー型ストアです。 グーグルは以前からこのBigtableを複数のデータセンターにまたがって運用し、万が一障害が発生したとしてもデータを失うことがないように、データセンター間のバックアップなどを行ってきました。 しかし、先月の記事「データセンターが「落ちる」ことを想定したグーグルのアーキテクチャ」で紹介したように、グーグルといえどもこうしたデータセンターにまたがるデータベースを安全に運用する方法については試行錯誤しており、7月には6時間にわたり大規模なデータベースの障害を引き起こしていたことは、「Google App Engineにデータストアの障害発生。復帰まで約6時間、原因は現在も不明」で紹介しました（この件については後日、原
HadoopのSQL対応分散クエリエンジン「Cloudera Impala」。Clouderaがオープンソースで公開
HadoopのSQL対応分散クエリエンジン「Cloudera Impala」。Clouderaがオープンソースで公開 Hadoopのディストリビューションベンダとして知られるClouderaは10月25日、SQLに対応し、データの分析速度はMapReduceよりも何倍も高速だという新しい分散クエリエンジン「Cloudera Impala」（製品名「Cloudera Enterprise RTQ」）をオープンソースで公開しました。 これまでHadoopでは内部でMapReduceと呼ばれる処理が用いられていましたが、ImpalaではMapReduceを使わず、Clouderaが2年かけて開発した独自の分散クエリエンジンを用いて処理を行います。Hiveの上位互換のSQLが利用でき、Hive/MapReduceで数分かかっていた応答時間を数秒に短縮すると説明されています。 グーグルのDremel
マイクロソフトが設立わずか3年のストレージベンダStorSimpleを買収した理由は、Amazonに勝つためか
マイクロソフトは10月16日、設立してわずか3年のハードウェアベンダを買収しました。エンタープライズ向けストレージベンダの「StorSimple」です。マイクロソフトはなぜエンタープライズ向けストレージベンダを買収したのでしょうか？ 既存のシステムそのままでクラウドのメリットを得られる StorSimpleは「Cloud-integrated Storage」（クラウド統合型ストレージ）、あるいは「Cloud Storage Gateway」と呼ばれる新しい分野のストレージ製品を提供しています。 同社製品の基本的な機能は通常のストレージと同様です。iSCSIでサーバに接続し、モデルによって2TBから20TBの容量の記憶領域を提供。キャッシュ用にSSDを内蔵しているため、ホットデータに対して高速なアクセスも実現します。 同社製品が「クラウド統合型ストレージ」と呼ばれる理由は、ストレージがクラ
NTTコミュニケーションズのCloud<sup>n</sup>、オブジェクトストレージを開始。月額1GBあたり約7円からで通信料は不要
NTTコミュニケーションズのCloudn、オブジェクトストレージを開始。月額1GBあたり約7円からで通信料は不要 NTTコミュニケーションズは、オープンソースのクラウド基盤であるCloudStackを採用したクラウドサービス「Cloudn」（クラウド・エヌ）に、スケーラブルなオブジェクトストレージサービス「Bizホスティング Cloudn Object Storage」（以下、Object Storage）を追加したと発表しました。 クラウドでは数TBから数PTもの大規模なデータを長期にわたって保存する用途が期待されています。これだけの容量になると大きさの面でも信頼性の面でも通常のストレージでは対応できなくなるため、データを分散して大規模に管理できるオブジェクトストレージの仕組みが不可欠になります。 CloudnのObject Storageも、こうしたクラウドでの大容量高信頼なデーストア
グーグル、Paxosを採用したApp Engineのデータストア「High Replication Datastore」が1年間ゼロダウンタイムだったと報告
グーグル、Paxosを採用したApp Engineのデータストア「High Replication Datastore」が1年間ゼロダウンタイムだったと報告 いまから約1年半前の2010年6月、グーグルはGoogle App Engineの利用者拡大への対応が後手に回り、深刻な性能低下や障害に見舞われました。グーグル自身が「Google App Engineの利用拡大に追いつけていない」ことを認める記事をブログにポストしています。 その半年後の2011年1月、こうした問題を解決するために登場したのが、新データストアのHigh Replication Datastoreでした。 High Replicatin Datastoreは、それまでのデータストアが採用していたMaster/Slave型でのデータセンター間の冗長性を、Paxosアルゴリズムによる同期に変更し、特定のデータセンターに障害
IBMの新メインフレーム、商用初のトランザクショナルメモリ搭載でJavaを超高速実行。JavaOne 2012
IBMのメインフレームにはJavaを高速に実行する仕組みが組み込まれている。JavaOne基調講演に続いて行われたIBMの講演では、そんな興味深い技術が紹介されました。 このメインフレームは8月末に発表されたばかりの新型で、1筐体で最大10万もの仮想サーバを実行可能という怪物のような性能のマシン。これひとつでその辺のデータセンター並の性能を持つといっても過言ではなさそうです。 しかも、商用マシンとしては初のハードウェアによるトランザクションメモリを搭載。ランタイム・インストゥルメンテーションなど多くの機能によってJava実行の高速化を実現したとのこと。業務用アプリケーションを実行するメインフレームにとって、Java性能が重要であることを示しているようです。 IBMの講演の一部を紹介しましょう。 4年前から取り組む IBM Distinguished Engineer、Java CTOのJo
FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編）
Facebookは大規模なデータ処理の基盤としてHBaseを利用しています。なぜFacebookはHBaseを用いているのか、どのように利用しているのでしょうか？ 7月1日に都内で行われた勉強会で、Facebookのソフトウェアエンジニアであるジョナサン・グレイ（Jonathan Gray）氏による解説が行われました。 解説はほぼスライドの内容そのままでした。当日使われた日本語訳されたスライドが公開されているので、ポイントとなるページを紹介しましょう。 Realtime Apache Hadoop at Facebook なぜリアルタイムデータの分析に、Hadoop/HBaseを使うのか？ MySQLは安定しているが、分散システムとして設計されておらず、サイズにも上限がある。一方、Hadoopはスケーラブルだがプログラミングが難しく、ランダムな書き込みや読み込みに向いていない。 Faceb
IT系上場企業の平均給与を業種別にみてみた 2012年版 ～ ネットベンチャー、ソーシャル、モバイル、ゲーム編
IT系上場企業の平均給与を業種別にみてみた 2012年版 ～ ネットベンチャー、ソーシャル、モバイル、ゲーム編 IT系企業で給与が高いのはSIerなのか、それともネットベンチャーなのか、流行のソーシャルゲーム系なのでしょうか。今年も上場企業を主な業種ごと分類し、調査しました。 この記事は、Yahoo！ファイナンスの「業種別銘柄一覧：情報・通信」および金融庁の「EDINET」で公開されている企業の有価証券報告書から、従業員数、平均年齢、平均年収などの情報を収集、Publickeyが独自の判断で主な企業をピックアップして業種を分類。平均給与が高い順に並べてみたものです。年収の単位は千円です。 今回は前編として、ネットベンチャー、ソーシャル、モバイル、ゲームなどの業種に分類した企業を中心に紹介します。後編では、パッケージベンダ、SI／システム開発、ゲーム開発などに分類した企業を紹介します。 ネッ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ SSDがHDDに代わるストレージとして普及しようとしていることを背景に、SSDに特化したまったく新しいアーキテクチャを備えたリレーショナルデータベースを開発しようとしている企業があります。「ReThinkDB」です。 昨年7月に、PublickeyではReThinkDBの概要を記事「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現」で伝えました。 その記事の中では、ReThinkDBがロックを使わずにトランザクションを実現し、データベース利用中でもスナップショットがとれ、また異常終了しても容易に復帰できる機能を備えている、といったことを紹介しました。 4月に米サンタクララでに行われた「MySQL Conference & Ex
グーグル、データセンターの障害にも耐えるApp Engineの新データストアを発表。Paxosを採用
グーグルは1月6日、Google App EngineのデータストアとしてPaxos algorithmによるデータセンター間のデータ同期を採用し、可用性を大幅に向上させた新データストア「High Replication Datastore」を追加したと、ブログのエントリ「App Engine 1.4.1 をリリースしました - High Replication Datastore の紹介」で明らかにしました。 App Engine 1.4.1 をリリースしました - High Replication Datastore の紹介 - Google Japan Developer Relations Blog 複数のデータセンターにまたがったレプリケーションを行うことで、特定のデータセンターに障害が発生した場合でもほとんどの場合で問題なく動作するとのことです。 可用性は高まるが書き込みは遅く
SQL vs NoSQL、グーグルにおける戦い（前編）。Google I/O 2012
SQLとNoSQLではどちらが優れているのか？ グーグルの担当者がディベート（というより小芝居：-）を行ったセッション「Google I/O 2012 - SQL vs NoSQL: Battle of the Backends - YouTube」が公開されています。 このセッションは、先々週開催されたGoogle I/O 2012で行われたもの。SQLとNoSQLには機能的にどのような違いがあり、どう使い分けるべきなのか、明確な説明が参考になります。 ハイライトを紹介しましょう。 クラウドにおけるデータベースのメリット グーグルのAlfred Fuller氏（NoSQL担当）。 クラウドはフォルトトレラントでメンテナンス不要、パッチも私たちが適用しており、利用者は運用について心配する必要がない、といったメリットがある。 データのレプリケーションや地域分散でデータも保全され、インターネッ
Amazonクラウド先週のシステム障害、原因は電源トラブル。二重三重の防護策が次々と倒れる
先週6月14日に発生したAmazon Web Servicesの米国東部リージョンでのシステム障害は、HerokuやPinterestなど大手のサービスにも影響を与えたようです。その障害報告が、Service Health Dashboardで公開されています（現在はRSS内の記述として読めます）。 障害は米国東部リージョンでの特定のアベイラビリティゾーンで発生したもの。報告によると、プライマリの電源ケーブルのトラブルをきっかけにバックアップとしての発電機へ移行したものの、そこでもまたトラブルが発生し、二重、三重の防護策が次々に倒れていったことが示されています。 Amazonクラウドの多重の防護策の一端が分かると共に、これだけバックアップ策が用意されていても、わずかなトラブルによって防護策が倒れることの教訓を得ることができます。 一方で、障害は特定のアベイラビリティゾーン内だったため、マル
NoSQLデータベースを40種類以上リストアップ、キーバリュー型にもいろいろある
Webスケールのデータを扱うためにさまざまなデータベースが登場してきている、ということを昨日のエントリ「データベースは目的別に使い分けるべし」で紹介しました。 特にリレーショナルモデルをベースとしない、非SQL系（NoSQL）と呼ばれるさまざまな種類のデータベースが登場してきています。非SQL系のデータベースは以前からオブジェクトデータベースやドキュメントデータベース、階層型データベースなどが存在していましたが、最近注目されているのがキーバリュー型データストアと呼ばれるデータベース。 ブログ「High Scalability」にポストされたエントリ「A Yes for a NoSQL Taxonomy」では、これら非SQL系のデータベースを詳細に9分類し、それぞれの分類に属するデータベースをリストアップしています（基になったのは「NoSQL is a Horseless Carriage」
NoSQLを上回る性能のVoltDB、そのアーキテクチャとは
データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。 今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。 シェアドナッシングな分散インメモリデータベース VoltDBのアーキテクチャは、FAQのページで以下のように説明されています（英語を訳したものを引用しています。以下同じです）。 VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
