タグ

architectureに関するaki77のブックマーク (36)

  • RESTFul(リソース指向アーキテクチャ)について - In urban breeze

    2014-05-06 RESTFul(リソース指向アーキテクチャ)について アーキテクチャ ROA(Resource Oriented Architecture)について。 次のを参考に勉強してみた。参考図書 RESTful Webサービス ROAの基 アプリケーションを動作と名詞(リソース)で考える。 リソースは特定のデータ、データの演算結果、状態、ユーザーアカウントなどである。 URIに動詞を含めてはならない。 リソースはHTTPメソッドを使用してのみ操作できる。 アドレス可能性 リソースはアドレス(URI)で一意に表現する。 1つのURIが複数のリソースを示してはいけない。 リソースを特定の言語や特定のフォーマットで取得したい場合は「Accept-Language」や「Accept」、または「Media-Type」を使用する。このようにリソースの表現方法が複数あ

  • モバイルAPIデザインのまとめ - ワザノバ | wazanova

    Natasha Murashevがブログで、API Strategy and Practice Conferenceにおける、Michele Titolo (先月、「 Ruby RoguesメンバとiOSエンジニアAPI議論」で紹介しました。)とEtsyのPaul Wrightの講演のポイントをまとめてくれています。 1) スピード ユーザは待ってくれない。300msで、リクエスト / レスポンスの処理 / ユーザに結果の表示をする。 2) RESTが常にベストとは限らない 以前のEtsyのAPIリソースはDBスキーマのミラーになっていた。クライアントがリスティングのリストを受け取ったら、ユーザがFavoritedに指定しているリスティングIDを取得するために、再度APIコールする必要があった。クライアントのAPIコールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ

  • The Twelve-Factor App (日本語訳)

    はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F

  • Trelloのアーキテクチャ - ワザノバ | wazanova

    http://nodeup.com/fiftyfour 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 Trelloのアーキテクチャについてのアップデートです。2012年1月にブログで紹介されたものと、昨年11月の最新状況をまとめてみます。 まずは、当初のアーキテクチャ: UIをクライアントサイドで生成し、プッシュでの更新を受け入れるシングルページアプリ。Client/ServerともにJavaScript、2011年5月以降はCoffeeScriptで書いている。 1) The Client TrelloのサーバはHTML、クライアント側のコードをほぼ扱っていない。Trelloのページは2Kのシェルで、一つの圧縮されたJavaScriptファイル(サードパーティのライブラリと圧縮したCoffeeSc

  • 2014年のウェブシステムアーキテクチャ - stanaka's blog

    (Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWS格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWS格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerLXC (LinuX Conta

    2014年のウェブシステムアーキテクチャ - stanaka's blog
  • Twitter: 大きなトラフィックに耐えうるアーキテクチャーへの変更 - ワザノバ | wazanova.jp

    https://blog.twitter.com/2013/new-tweets-per-second-record-and-how 少し前、8月のTwitterエンジニアブログのエントリーですが、アーキテクチャー変更について触れているポストなので、取り上げてみます。 1) 背景 2010年のワールドカップ時点でのトラフィックがさばききれなかった時点での状況は、 200人のエンジニアが、単一のRailsのコードベースで大量のユーザとトラフィックに対応する構造であった。 MySQLのストレージシステムは、一つのマスタと一時的にシャーディングされるスレーブの構成で、読込み/書込みともにスループットの限界にきている箇所がでていた。 フロントエンドRubyマシンは期待通りのトラフィックをさばけていなかったが、技術的な解決ではなく、サーバの追加でしのいでいた。 コードベースは、可読性とパフォーマン

  • 国内注目のWebサービスを支える言語・フレームワーク・アーキテクチャ一覧【2013年版】 | Find Job! Startup

    FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ

    国内注目のWebサービスを支える言語・フレームワーク・アーキテクチャ一覧【2013年版】 | Find Job! Startup
  • 「このサービス、裏側はどうなってるんだ... | Qixil(キクシル)

  • #18 「サービスの負債を減らしましょう」tech.kayac.com Advent Calendar 2012 - KAYAC engineers' blog

    こんにちは、入社4年目にして初投稿する、あきひと(@takihito)です。 このエントリーは tech.kayac.com Advent Calendar 2012 の18日目の記事になります。 今年の12月で5周年を迎えた某サービスの運用開発をしています。自分が関わり始めてからは4年ほどです。 その間にサービスの成長に伴い溜まった負債を減らす方法をいくつか紹介したいと思います。 (テーマは「2012年のマイイノベーション」ですが特に気にせず書かせて頂きます) カプセル化 リリース時にコントローラにベタ書きしてしまったコード、開発速度や納期を優先するとよくあります。 このままでは単体テストも書きにくく、品質や機能拡張の障害にもなります。こんな時にはカプセル化をしましょう。 ベタ書きしたビジネスロジックを上図のようなModelクラスを新たにつくって、移し閉じ込めてしまいまいます。 これでコ

    #18 「サービスの負債を減らしましょう」tech.kayac.com Advent Calendar 2012 - KAYAC engineers' blog
  • Dropbox のスケールとか

    Python なサービス みんな大好き Dropbox のスケールとかメモ。以下のページ辺りからピックアップ。Parted? みたいなので、続編がでたら追記するかも。 Scaling lessons learned at Dropbox, part 1 (comment) Dropbox - Startup Lessons Learned (slideshare) Dropbox -Yコンビネーターが生んだスタートアップの軌跡と未来 - スケール関係ないですが、2006 年当時はオンラインストレージサービスがいっぱいあったようで、VC から資金調達したときのやり取りがおもしろい VC "クラウドストレージサービスなんて腐るほどある" Drew "なにか使ってるのありますか?" VC "NO" Drew "..." 完璧で、スケーラブルで、クロスプラットフォームなクラウドストレージ!当時、プ

    Dropbox のスケールとか
  • Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用

    Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用 急速に人気が急上昇するWebサービスでは、どのようにスケールするアーキテクチャを構築し運用していくのかはサービスの成否を分けるほど重要です。Pinterestのように急成長してきたサービスのソフトウェア構成やリソース構成はどうなっているのでしょうか、Web上でいくつか情報が公開されているのでまとめてみました。 Pythonで開発し、Amazonクラウドで運用 1年ほど前なので少し古い情報ではあるのですが、Q&AサイトのQuoraにPinterestのco-founder Paul Sciarra氏が書き込んだソフトウェア構成の説明があります。 PinterestPythonで開発されており、MemcachedやNginxなど高速なレスポンスに配慮した構成になっている様子がうかがえま

    Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用
    aki77
    aki77 2012/05/25
    Pinterest
  • Webアプリケーションにおける Job Queue システムの構成例と Worker を作る際に気をつけること - blog.nomadscafe.jp

    Webアプリケーション内で処理を直列に実行せずにJob Queueに回して非同期に実行することが多くなって来て久しいと思いますが、そのおすすめ構成と気をつけることについてつらつらと。 1) 既存のデータベースをキューとして使う構成例 1つ目はMySQLなどのデータベースをキューとして用いる例。既にアプリケーションで利用しているデータベースにキュー用のテーブルを作成して利用します。データベースを利用したキュー管理の仕組みとしてJonk、Qudo、TheSchwartzなどがPerlでは有名どころです。 依存するミドルウェアが増えないので最もシンプルな構成になると思います。 上記の図ではWorkerはアプリケーション内で実行することで冗長性を確保しますが、キューを格納するデータベースはSPOFになります。しかし、、データベースに障害があった場合キューだけでなくすべてのサービスが停止すると思われ

  • いきあたりばったりのアーキテクチャと教訓

    スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。 そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです(訳は前述の記事「データベースの間違った使い方10項目」から)。 Dynamic table creation(動的なテーブルの作成) Table as cache(テーブルをキャッシュとして使う) Table as queue(テーブルをキューとして使う) Table as log file(テーブルをログとして使う) Distributed Global Locking(分散したグローバルなロック)

    いきあたりばったりのアーキテクチャと教訓
  • 太田さんによる某銀行のバッチについてのまとめ

    Kenichiro Ota @oota_ken やる夫:やらない夫ー、地震に続き某メガバンクでトラブルがあってお金の引き出しとかができなくなっているみたいだけど? 2011-03-20 07:16:33

    太田さんによる某銀行のバッチについてのまとめ
  • 補足 - Web Applicationをきれいに設計するためのMVACという考え方 - $shibayu36->blog;

    Web Applicationを綺麗に設計するためのMVACという考え方 - Dive into the Tech World! では、様々な意見をいただきありがとうございました。コメントを見る限り、うまく伝えきれていないなという部分がいくつかあったため、補足としてまとめたいと思います。 前提 前回の記事は一応前提として、以下のようなものがあります。 Web Application設計の新しい手法を提案したわけではない 昔からある手法の理解が自分の中で深まったので、まとめてみたわけです もらった意見とその補足 MVCにおけるMの定義がおかしいのでは Mの定義がおかしいから、Aがある データモデルがMと思うと失敗する これに関しては、「MにSkinnyを」などというように、記事の書き方が少し良くなかったのではないかなと思いました。Mに関しては、DBへのインターフェイス、オブジェクトの層、ロジ

    補足 - Web Applicationをきれいに設計するためのMVACという考え方 - $shibayu36->blog;
  • Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;

    【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって? データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した