監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita
はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール
Architecting RESTful Rails 4 API · Jesal Gadhia
Architecting RESTful Rails 4 API 22 Oct 2013 This is a follow-up to my previous post about Authentication with Rails, Devise and AngularJS. This time we’ll focus more on some aspects of the API implementation. One thing to keep in mind, where my previous example used Rails 3.2, I’m using Rails 4 this time around. Versioning If you are building an API which could be potentially consumed by many dif
小さなサーバーで大きなサービスをつくる | カメリオ開発者ブログ
アーキテクトのItoです。動画を撮るのが趣味ですが、最近はこの本を買って、カラーグレーディングの勉強をしています。とても良い本です。 さて、今回お話するのはバックエンドにあるフロントエンドについて。 以下はほぼ実際にカメリオで運用しているバックエンド構成です。 図中のサーバーというものはいわゆるHTTPベースのサーバーアプリで、ここでは緑をNode.js, グレーをPython, C++で実装しています。小さいサーバーがたくさんあります。主にクライアント〜フロントエンドAPIだけの構成図で、記事クローラーや各種管理画面などは図にはありませんが存在します。 まずフロントエンドにELB(AWSを使用)とNginxを置き、後ろに NodeベースのフロントエンドAPIサーバーを置きます。 ここはNode.jsで作られたアプリをサービスするごく一般的な方法です。 エンドポイント(api.kamel.
パイプとフィルタ ~ソフトウェア工学における有用なアーキテクチャ~ | POSTD
パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な（そして驚くほど活用されていない）アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l
JavaOne報告会2014アーキテクチャトレンド
2014/10/18に開催されたJavaOne報告会での「アーキテクチャトレンド」での発表資料です。 （誤字があったので再アップしました）Read less
マーチン・ファウラー氏による「マイクロサービスの前提条件」
「マイクロサービス」という新しいアーキテクチャスタイルが話題になっています。ごく簡単に言えば、1つのシステムを複数の小さなサービスを組み合わせて実現することです。マーチン・ファウラー氏とJames Lewis氏が今年の5月に公開した記事「Microservices」で注目が集まりはじめました。 参考："Microservices"を読んだ | SOTA 参考：クックパッドとマイクロサービス - クックパッド開発者ブログ 参考：マイクロサービスとSOA - InfoQ このマイクロサービスを実現する上で、組織が備えていなければならない能力について、マーチン・ファウラー氏が先月、「MicroservicePrerequisites（マイクロサービスの前提条件）」という記事を公開しています。同氏のWebサイトの記事は翻訳が許可されているので、ここで翻訳を紹介したいと思います。 マイクロサービスの
TaskRabbit: 複数のRails 4 Enginesで構成したアプリ - ワザノバ | wazanova
http://tech.taskrabbit.com/blog/2014/02/11/rails-4-engines/ 3 comments | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 TaskRabbitは、modelが100+におよぶ単一のRailsアプリと、APIを介して複数のRailsアプリの構成にしたプロダクトを経験し、今回UKのプロジェクト で、複数のRails Engines を利用したアプリの開発に取り組んだ事例を紹介しています。 サンプルアプリはこちら。 APIを介した複数アプリの構成の場合、アプリをまたがるリリースが問題になる。一つのコードベースのときよりも遅くなる。各アプリに必要なgemがバージョンの問題で果てしなくコンフリクトがおきる。結合テストが相当大変。一方、複数のRails Engin
microservicesに分割する際に注意するべき5つのこと - Qiita
はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくことです。ですので、プロセスを跨いだ通信が大量に発生します。その結果、サーバー台数は増大します。 つまり、インフラコストの増大と開発速度の高速化のコスト感覚をバランスして判断していく必要があります。疎結合性が高まり、アーキテクチャとしては美しく感じますが、実施に
クックパッドとマイクロサービス - クックパッド開発者ブログ
技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ
プロジェクトを準備する - パルカワ2
準備は重要 コードコンプリートでは、準備が重要とされていて、そこで言われている準備とは、「課題定義」「要求」「アーキテクチャ」があげられている。 そんな事とは露知らず、準備の重要性の話を昨晩していた。 テスト、プロジェクト開始時からちゃんと書く準備してないとあとから書こうとしてもほぼ確実に書かないので、最初にそういう準備するのメッチャ重要だと思ってる。— ひさいち (@hisaichi5518) 2014, 9月 7 あと最初からあると次来た人も書きやすい。— ひさいち (@hisaichi5518) 2014, 9月 7 もちろん、テストだけの話ではなくコードコンプリートに書かれている例外・データベースのコネクションの管理などなども同じ。 準備不足にならないために コードコンプリートでは、準備が不十分になる原因は2つあるとしている。 準備が不十分になる一般的な原因は、上流の作業を担当する
Groupon: アナリティクスシステム改善の取組み - ワザノバ | wazanova
http://vimeo.com/96931912 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 GrouponのEngineering ManagerであるChris Powersが、同社のGeekfest Chicago Eventで、アナリティクスシステム改善の取り組みを紹介しています。 ２年半前に改善の取り組みを開始 事業の拡大に伴ってアナリティクスの需要は、CEOへの報告から、マーケ/開発の現場の利用、データサイエンティストの分析まで様々。しかし、各チームがバラバラに複数のアナリティクスシステムを運用していて、オーナーシップを取るチームはなし。 トラッキング用にページあたり20-30ピクセルを仕込んでいて、つまりユーザ当たり 20-30 GETリクエスト / ページとなり、サーバ負荷が過大
Facebookの数千台規模のmemcached運用について - ゆううきブログ
Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログの続きとして、Facebook の memcached 運用に関する論文を読んだ。 タイトルなどは以下の通り。 NSDI はネットワークシステムに関するトップレベルのカンファレンス。 Scaling Memcache at Facebook Rajesh Nishtala, Hans Fugal, Steven Grimm, Marc Kwiatkowski, Herman Lee, Harry C. Li, Ryan McElroy, Mike Paleczny, Daniel Peek, Paul Saab, David Stafford, Tony Tung, Venkateshwaran Venkataramani NSDI'13 In Proceedings of the
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
LevelDB入門 (基本編) - from scratch
さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDB は Google のBigTableをベースにしたアーキテクチャを持
アーキテクチャ設計に品質特性を使おう - arclamp
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報
Stack Overflowのアーキテクチャ - ワザノバ | wazanova
http://www.youtube.com/watch?v=OGi8FT2j8hE1 comment | 0 pointsドイツのハンブルグで開催されたDeveloper Conference 2013で、Stack Overflowのアーキテクチャが紹介されてます。 Stack Overflowのネットワークは、110 Q&Aサイト、430万ユーザ、質問760万件、回答1360万件、月間5億6千万ページビュー サーバ25台: ウェブサーバ11台（内9台でほぼトラフィックさばく）、ロードバランサ1台 (+ 予備1台)、DBノード4台、アプリサーバ3台、検索サーバ3台（Elasticsearch）、Redisサーバ２台（キャッシュ、メッセージング） 毎秒質問が投稿されているので、トップページには都度最新の質問を掲載するように更新はできないが、ユーザの回答パターン、質問閲覧パターン、好みのタ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Martin Fowler氏の語る“犠牲的アーキテクチャ"
FINAL FANTASY Record Keeper の作り方
Facebook の決断：MVCはスケールしない。ならば Flux だ。