Instagram のスケール正攻法 -- Kosei Kitahara's Blog
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
How to build customizable multitenant web applications - PHPBNL11
This document discusses how to build customizable multitenant web applications. It explains that a single-tenant architecture is not scalable and leads to maintenance issues. A multi-tenant architecture allows customizing the frontend, backend, workflows and logic for each tenant. This is achieved through feature-driven CSS, modularization, dependency injection and aspect-oriented programming to a
Re: @kazuho: handlersocket plugin や mycached を使えば memcached は不要か、それとも使うべきケースがあるか。考察せよ [10点] - blog.nomadscafe.jp
handlersocket plugin や mycached を使えば memcached は不要か、それとも使うべきケースがあるか。考察せよ [10点] kazuho (Kazuho Oku) http://twitter.com/kazuho/status/21477219149 考えて答えてみる。 HandlerSocketやmycachedを利用し、MySQLへの接続数が数万単位で行えるようになったり、より多くのクエリ数が発行できるようになっても、memcachedは不要ではないし、使うべきケースもあります。 memcachedは単なるKVSではなく、ExpiresとLRUがついたキャッシュサーバです。キャッシュオブジェクトには期限を付ける事ができ、期限が過ぎたキャッシュは無効にされ、またアクセスがされていない不要になったオブジェクトは削除され、空いたスペースは新しいキャッシュオ
建築基準法とミニスカートの幾何学による「３５ｃｍ丈のミニスカートは絶対安全」という証明 | 雑学界の権威・平林純の考える科学
スカートの長さが32cmよりも長ければ、スカートの内側を見られる心配はありません。 なぜなら、「風が吹くことさえなければ、角度が25度程度の比較的急な階段であったとして、スカートの内側を見ることはできない」ということが数学的に証明されているからです。 たとえば、階段の上に立つミニスカートを履いた女性がいたとしても、そのスカート丈が32cmよりも長ければ、（たとえ、どんなに階段の下に降りてみたとしても）ミニスカートの内部を覗き見ることはできないという代数幾何的な証明がされているのです（参考：ミニスカートの幾何学）。 しかし、３２ｃｍ丈のスカートで安全なのは、角度が２５度程度の階段までに過ぎません。 もしも、それより急な階段があれば、もっと長いスカートを履いていなければスカートの内側が見えてしまう、ということになります。 それでは、一体どのくらいの長さのスカートであれば「スカートの内側を見られ
ダイコン時代の設計手法 - クラス図なんて要らない - ひがやすを技術ブログ
ほぼ、クラス図不要論とおなじなのですが、自分の意見を書いておきます。 ドメインをデータと振る舞いの点から考えてみたいと思います。 データはどのように永続化するのかが最も重要です。 RDBMSを使う限りはRDBMSに適したようにモデリングしたほうがいい。 HibernateなどのORMを使えば、RDBMSを使っても理想的なドメインモデルを 構築できると主張する方もいるかもしれません。 すべてのプロジェクトの参加者がオブジェクトを通じてデータを見ているなら それでも良いと思います。 しかし、実際はテーブルに入っているデータで結果を確認しているのが ほとんどではないでしょうか。 特にユーザはオブジェクトなんて興味はありません。 データの入出力もテーブルを通じておこない、テスト結果の確認も テーブルを使います。 JavaとRDBMSで違うモデルを構築してしまうと開発者は相互に変換を 行わなければな
ダイコン時代の設計手法 - Logicがない場合 - ひがやすを技術ブログ
これは、UI仕様書（Validationつき）とエンティティ仕様書とを明示的に関連づけてしまい（一枚にできないか）、バウンダリからサービスを経由しないで（デザイン的にはスルーして）S2Daoをたたくことで実現できる(Excelでうんぬんを突き詰めたい)。 これまでバウンダリから呼び出されるコントロール (システムが提供するサービス)をロジックと 永続化(Dao)に分けて処理することをずっと提案してきた。 アーキテクチャ的にはきれいなのだけど、心にはくすぶるものがあった。 だって、たいていの画面ってロジックなんかなくて、Daoをたたけば良いのが ほとんどだからだ。 単にDaoに処理を委譲しているロジックでも実際の案件では、 仕様書もテストもインターフェースも実装クラスも作らなければならない。 無駄なコストは削らなければならない。 バウンダリからDaoを呼ぶようにしても良いけど、 バウンダリに
ダイコン時代の設計手法 - 内部設計 - ひがやすを技術ブログ
バウンダリに関しては、UI層のフレームワークに合わせた 内部設計書を作成します。 とりあえず、必要だと思われるのは、UI層のコントローラ (例えばStrutsのAction)のコンポーネント定義です。 UI層のコントローラは、ロジック層のクラス(interface)に依存します。 依存関係もコンポーネント仕様書に記述します。 ロジック層とは、以前サービス層と呼んでいた層です。 SOAの絡みでややこしくなりそうなので、呼び方を変えました。m(_ _)m コントロールの内部設計が最も重要なポイントです。 コントロールの処理を 業務固有の部分 永続化に関する部分 共通部分 に分解します。 業務固有の部分は、ロジック層のコンポーネントで実装します。 ロジック層のコンポーネントはバウンダリごとに作成します。 例えば、従業員管理初期ページに 新規入力を行う 検索を行う という2つのコントロールがあった
ダイコン時代の設計手法 - 外部設計 - ひがやすを技術ブログ
外部設計のインプットデータは、業務フローです。 業務フローごとに外部設計を行います。 ユーザにレビューしてもらえるのは、外部設計まで。 気合を入れます(笑)。 業務フローの中で、既にバウンダリが洗い出されているはずなので、 それらをもとにロバストネス分析を行います。 ロバストネス分析は、次のように行います。 バウンダリごとにUI仕様書とモックを作成します。 UI仕様書には項目説明をつけます。 項目とテーブルのカラムのマッピングも行います。 足りないカラムがあればエンティティ仕様書に追加します。 Validationもこの段階でつめます。 コントロールとはVO(動詞 + 目的語)で書き表されるもので、 「〜を〜する」という1センテンスになります。 動詞は現在形の能動態です。 画面で起こるイベントごとにコントロールを定義します。 コントロールがすべて洗い出されていることを確認したら、 データの
ダイコン時代の設計手法 - 外部設計に必要なもの - ひがやすを技術ブログ
ダイコンの守備範囲は、外部設計以降なのですが、外部設計をするために 最低これだけは必要になるだろうと思うものを書いておきます。 逆にいうとこれらが決まらずに外部設計にはいっても、 結局待ち状態に入り、プロジェクトは迷走をし始めるでしょう。 デスマはこのようにしてはじまる! 新業務フロー これだけあれば、外部設計をはじめられます。 新業務フローとは今回開発するシステムにおける業務フローのことです。 新業務フローでは、アクター・バウンダリが 明らかになっていればそれでいいと思います。 バウンダリとはシステムの外部とのインターフェースのことで、 画面や帳票のことです。 今回、業務フローのフォーマットは顧客が理解できるものなら何でも良いと 思います。
階層アーキテクチャの利点は、複雑さの減少 ― ＠IT
個々のコンポーネントを組み上げて、どのようなシステムを構築するか。構造（アーキテクチャ）によって、できあがるシステムの性質が変わってくる。作り手側の視点に立てば、どのようなアーキテクチャを採用するかによって、作り方も変わってくる。いままで連載した記事を通して、わたしたちは、個々のコンポーネントの作り方を学んできた。今回からは、コンポーネントをいかに組み上げるか、という課題に知恵を絞ることになる。コンポーネントの利点を最大限に生かすこと。それがアーキテクチャ設計の現実的な意味の1つだ。そして、1つの有効なアプローチに階層化アーキテクチャがある。 前回「使いやすくて、変化に強いコンポーネント」までにサブシステムなどを利用したコンポーネントの作り方についてお話ししてきました。それでは、コンポーネントは実際どのような単位で作り上げていけばよいのでしょうか。 コンポーネントの単位として考えられるのは
Webアプリケーション内のMVCアーキテクチャ - 今日の役に立たない一言 － Today’s Trifle! －
twitter とか(もちろん自分のTL)で MVC アーキテクチャのことが話題になってるみたいなので、ちょっとメモ程度のことを書いておく。 まず、ここで言及してるのは、MVC2アーキテクチャのことではないので念のため。 Webアプリケーションは、一般的に三層アーキテクチャを採用する。プレゼンテーション層、サービス層、データアクセス層の3つ。でも、これはMVCアーキテクチャとは異なる。 Webアプリケーションでのコア部分はサービス層である。サービス層でWebアプリケーションで提供するサービスをきちんと構築するには、サービス層の中に MVC のうちの、少なくとも Model と Controller が必要になる。 プレゼンテーション層はまさしく View にあたる部分だけど、サービス層の中に View というか、UML で言うところの Entity・Boundary・Controller
いきあたりばったりのアーキテクチャと教訓
スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。 そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです（訳は前述の記事「データベースの間違った使い方10項目」から）。 Dynamic table creation（動的なテーブルの作成） Table as cache（テーブルをキャッシュとして使う） Table as queue（テーブルをキューとして使う） Table as log file（テーブルをログとして使う） Distributed Global Locking（分散したグローバルなロック）
ドメイン モデル パターンを使用する
In this article, we’ll go through the reasons to (and not to) employ the domain model pattern, the benefits it brings, as well as provide some practical tips on keeping the overall solution as simple as possible. Contents What Is It? Reasons Not to Use the Domain Model Technology Reasons to Use the Domain Model Scenarios for Not Using the Domain Model Scenarios for Using the Domain Model More Comp
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
ウノウラボ Unoh Labs: FarmVilleの開発 - FacebookのNo.1ゲームを5週間で作りあげスケールさせた手法
こんにちは、五十川です。 2010年12月1日に、ウノウがジンガジャパンとなってから初めてのタイトルとなるファームビレッジがリリースされました。ファームビレッジはFacebookで永らくNo.1の座にあるFarmVilleの日本語版ですが、先月そのFarmVille開発のリーダーで、現在はZyngaの共有テクノロジーをリードしているAmitt Mahajanが来日していました。 今回ご紹介するのは、そのAmittが2010年3月のGame Developers Conference（GDC）で行った、Rapidly Developing FarmVille - How we built and scaled a #1 Facebook game in 5 weeksと題したプレゼンテーションです。今回Amittの許可を得てそのときのスライドの日本語版を作成しましたので、それに解説を加えてご
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
グリーCTOが語る、大規模ソーシャルゲーム開発の舞台裏
9月1日、ゲーム開発者向けカンファレンス「CEDEC 2010」において、SNS「GREE」を運営するグリー株式会社（以下 グリー）が『大規模ソーシャルゲームのつくりかた ～60分でわかるサーバサイド技術～』と題するセッションを講演した。 一日あたり億単位のトラフィックを捌くインフラはどうなっているのか。技術者2名が解説したインフラ構築のノウハウや、ソーシャルゲームと一般のオンラインゲームとの違いについて紹介する。 オンラインゲームとソーシャルゲームとの違い 最近テレビCMでも目にする機会が多くなってきたSNS（ソーシャルネットワーキングサービス）の「GREE（グリー）」。2010年6月時点の数字で、会員数2059万人、月間353億ページビューという言わずとしれた大人気サイトだ。中でも携帯電話向けソーシャルゲームが特徴的で、専用機向けのゲームと比べるとコアゲーマー以外のプレイヤーも多く、利
月間57億PV、300台のサーバを運用するミツバチワークスが編み出したインフラ技術
ミツバチワークスのエンジニアは、「月間57億PV」という巨大なトラフィックをさばくため、さまざまな技術を駆使してインフラを構築している。主と副の2本立てでデータベースを運用し、300台のサーバを使いながら「負荷の限界」に挑むエンジニアに、技術ノウハウを聞く。 ミツバチワークスが運営するケータイブログサービス「DECOLOG」は、異色のサービスである。10代後半から20代前半の女性に最も人気のあるケータイブログサービスで、「デコメール」などを利用して、かわいくカラフルなブログを作成できる。広告基準を厳しくすることで女性ユーザーにも不安なく使ってもらえるような安心感を作り出し、口コミだけでじわじわとアクセス数を伸ばしてきた。 結果、2010年7月実績で月間57億PV（ページビュー）超、想定800万UU（ユニークユーザー）、会員登録者数180万件と、ケータイブログサイトでは国内最大のサービスとし
グーグルが構築した大規模システムの現実、そしてデザインパターン（4）～デザインパターン編
グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」（グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性）という講演を、6月に行われたACM（米国計算機学会）主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。 講演の内容を4つの記事（MapReduce編、BigTable編、教訓編、デザインパターン編）で紹介しています。この記事は教訓編の続き、デザインパターン編です。 大規模システムデザインの指針 よりよく使ってもらうためのインフラのデザインと開発方法を考えてみよう。 インフラに対する機能の要望についてさまざまなグループと話すと、多くのリクエ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Android is NOT just 'Java on Linux'
