Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用
Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用 急速に人気が急上昇するWebサービスでは、どのようにスケールするアーキテクチャを構築し運用していくのかはサービスの成否を分けるほど重要です。Pinterestのように急成長してきたサービスのソフトウェア構成やリソース構成はどうなっているのでしょうか、Web上でいくつか情報が公開されているのでまとめてみました。 Pythonで開発し、Amazonクラウドで運用 1年ほど前なので少し古い情報ではあるのですが、Q&AサイトのQuoraにPinterestのco-founder Paul Sciarra氏が書き込んだソフトウェア構成の説明があります。 PinterestはPythonで開発されており、MemcachedやNginxなど高速なレスポンスに配慮した構成になっている様子がうかがえま
LINE Storage: Storing billions of rows in Sharded-Redis and HBase per Month « NAVER Engineers' Blog
Hi, I’m Shunsuke Nakamura (@sunsuk7tp). Just half a year ago, I completed the Computer Science Master’s program in Tokyo Tech and joined to NHN Japan as a member of LINE server team. My ambition is to hack distributed processing and storage systems and develop the next generation’s architecture. In the LINE server team, I’m in charge of development and operation of the advanced storage system whi
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
データベースのスケーラビリティをどうやって向上させるか
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
あえてNoSQLでクラウド上にエンタープライズアプリを作ってみる : 小野和俊のブログ
RDBMSとNoSQLを巡る議論でいつも私が違和感を感じるのは、RDBMSに固執しようとする人と、NoSQLに固執しようとする人と、それぞれが極端にどちらかを擁護し、極端にどちらかの長所や可能性に対して目を瞑ろうとしているように見受けられることである。 これまでRDBMSを業務で使ってきた人にNoSQLの制約の話をすると、大抵の場合、「そんなのじゃ業務には使えない」という反応が返ってくる。特に即時一貫性が保てないという話をすると「まったく使い物にならない」と脊髄反射的に拒否反応を示されることが多い。 私が思うに、クラウドがシステム構築で活用されていくのに比例して、これからは「RDBMSとNoSQLを適材適所で使い分ける」ことがこれからのアーキテクトに求められるのではないか。 これまではRDBMSがあったから何もかも一貫性が保障されていた。だが、本当にそこまですべてのデータに即時一貫性が必要
ゲームを作ってるときに心がけてること - GAME NEVER SLEEPS
今日はプレイテストがあった。開発中のゲームを、ある程度傾向の定まったグループに遊んでもらって、マジックミラーとかカメラごしにどんなところで詰まるのかみたり、あらかじめ用意した質問に答えてもらったり、ゲームの良かったところ悪かったところを討論してもらったりするイベントだ。 まあ、数週間おきにやってるもんだから、ある程度評価が予想できるし、いつもつい気が重くなってしまう。なぜかというと、けっこう厳しいことを言われるから。 特に若いグループは批判がキツくて、「PS2並」とか、「つまらない○○（大作タイトル）」とか、「ダウンロード用ならいいんじゃん」とか、「え、これ売るの？マジで？」とか、おしっこ漏れそうな罵詈雑言を毎回聞かされる。 だが、今回は違う。僕は周りに今回は大丈夫って宣言してた。ゲームの内容に対するチュートリアルが入り、ストーリーが語られるムービーが入り、適切な音楽が流れ、要するに最終的
プログラマが知っておきたいJavaと.NETの違い
システム開発がますます複雑化していく中、エンジニアには、テクノロジを理解して、さまざまな場面に適した選択が求められます。本連載では、Javaと.NETの基本的な仕組みから最新の傾向や技術などについて、数回に分けて紹介します いまさら聞けない、Javaと.NETの違い 今日、アプリケーション開発・実行のプラットフォームは、大きく2つのテクノロジに収束しているといえるでしょう。 1つは、エンタープライズ・アプリケーション開発の定番ともいえる「Java」です。 実行環境、開発環境の無償提供、OSを自由に選べること、フレームワークや開発環境が充実していることが人気の理由です。大規模アプリケーションの採用実績も多く、ほかのプラットフォームをリードしてきました。 もう1つは、マイクロソフトが発表した「Microsoft.NET」構想に基づいた「.NET」です。 プラットフォームが主にWindowsに制
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
suicaは実はたまに落ちている - 紅茶屋くいっぱのあれこれ日記
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
デザイン・パターンとは何か
先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、（業界に蓄積されたノウハウに立脚した）何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな（場合によってはお互いに矛盾する）要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
ScalaによるWebアプリケーションフレームワーク「Lift」とは
Java仮想マシン上で動くオブジェクト指向＋関数型言語として、Scala（スカラ）が最近注目を集めています。Scalaで構築されたWebアプリケーションフレームワークはいくつかありますが、 本連載ではその中で比較的歴史のある（といっても2年程度ですが） フレームワークである、Lift（リフト）を紹介したいと思います。 はじめに Java仮想マシン（以下JVM）上で動くオブジェクト指向＋関数型言語として、Scala（スカラ）が最近注目を集めています。 Scalaで構築されたWebアプリケーションフレームワークはいくつかありますが、 本稿ではその中で比較的歴史のある（といっても2年程度ですが） フレームワークである、Lift（リフト）を紹介したいと思います。 対象読者 Javaは知っているが、Scalaも学んでみたいと思っている方 ScalaでのWebアプリケーション開発に興味がある方 必要な
ロケスタの新サービス「ナナピ」で使った技術を紹介してみるよ - UNIX的なアレ
http://nanapi.jp 本日2009年9月1日、株式会社ロケットスタートの新サービス「ナナピ」をリリースしました。 「ナナピ」はライフレシピと呼ばれる生活の便利な知恵や、ノウハウをみんなに共有してしまおう！というサービスです。 なんとか予定通り9/1にリリースをすることができました。すでに投稿数が160ほどあり、生活に便利な内容が投稿されています。 http://r.nanapi.jp/162/%E3%81%82%E3%81%8F%E3%81%B3%E3%82%92%E6%AD%A2%E3%82%81%E3%82%8B%E6%96%B9%E6%B3%95/ http://r.nanapi.jp/158/%E3%83%AC%E3%83%99%E3%83%AB%E3%81%8C%E4%B8%8A%E3%81%8C%E3%82%8B%E6%8C%A8%E6%8B%B6%E3%81%AE
ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな
Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね（しんぱいそうなめでみている） http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 本当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、１台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム
不倒城: SI業界からネットゲーム業界に移った知人に色々話を聞いてきた。
ちょっと技術的な話になる。 私の知人に、かつてはアルファベット三文字の某有名SI会社に在籍していて、今はどういう訳か某ネットゲームの会社に勤めている変り種がいる。 彼はネットワークとDBの専門家である。ゲーム業界には元来DB周りに詳しい人があまり多くなかったらしく、しかしネットゲームの開発にはDBやネットワークのアーキテクチャに関する知識が必須で、要は引き抜かれたらしいのだが、当人それ程ゲーム好きでもないのに面白いルートに行くなーと思っていた。 機会があったら金融業界とネットゲーム業界のシステム周りの違いについて聞いてみたいなーと思ってたんだが、この前久々に会ったら色んな話が聞けた。特定されない程度においおい書いてみよう。ぼかして書く為、ところどころいー加減だが勘弁して頂きたい。 今日はサーバとかデータのやり取りとか、技術的な話。 まず、前提。オンラインシステムの肝の一つに、「誰がデータを
ひらたのゲーム開発ブログ そのつど考えながらの開発と、最初から全部を決めた開発と
ゲーム開発会社沖縄メトロでアルバイト中のひらたが 気になることや日常の仕事をつづっていく応援ブログです／(.^.)＼ ども。ひらたです／(.^.)＼ もちょっと、イトイ新聞の「ジブリの仕事のやり方」から引用します。 宮崎駿監督は、 まだ、何を作るのかさえわからないときに、 まず、主人公の髪型や洋服を決める……。 のだそうですｗ え？それって重要なことなの？ｗ このつづきは どうなるのだろうということを、 宮崎駿本人を含めて、 全員知らないわけですから……。 そんなやり方でこれまでの大作が作られてきたの？！！！ いや、ジャンプの「ドラゴンボール」とか、 「魁！男塾」とか、 そういうのが、まったく何も考えずに作られたとは聞いたことあるんですよ。 週刊誌の場合、毎週の引きや盛り上がりが不可欠ですから 多少全体で整合性が合って無くても、それが面白いということもある。 でも、１年や２年がかりで作られ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
