アーキテクチャ設計に品質特性を使おう - 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サーバ２台（キャッシュ、メッセージング） 毎秒質問が投稿されているので、トップページには都度最新の質問を掲載するように更新はできないが、ユーザの回答パターン、質問閲覧パターン、好みのタ
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
SIerの社内フレームワークを前向きに捉えてみる - たけぞう瀕死ブログ
その昔、僕が客先常駐ソルジャーだった頃、そこには辺り一面炎上プロジェクトばかりでした。 当時僕の参加していたプロジェクトでは、 SQLで書いたら数秒〜数分で済むであろうバッチ処理をなんちゃってEJB 1.0のような独自フレームワークを使って数時間かけて処理し、挙句に朝までに終わらないと問題になって作り直したり なぜかすべてのバッチがSQL*Plusを叩くシェルスクリプトで実装されており条件分岐で済むようなケースがすべて別ファイルとしてパターン数分用意されていたため処理を少し修正するだけでも数百のシェルスクリプトを修正しなくてはいけなかったり はたまたオンラインの処理では1人のユーザがボタンを押すだけで200M以上のメモリを消費しこれ想定ユーザ数での使用にどう考えて耐えられないでしょみたいなものがあったり ResultSetをJSPまで持ち合わしてどこでもクローズされていなくてJMeterで
makopi23のブログ 「DDD本 読書会(羊) #8＋α」に参加しました
2014/2/23(日) 「DDD本 読書会(羊) #8＋α」に参加してきました。 告知サイト http://connpass.com/event/5072/ 以下の書籍をターゲットとした読書会なのです。 場所はいつもの矢向、横浜地区センターです。 参加者は11人です。初参加は1～2名かな。 今回はじゅんいち☆かとうさんによるDDDの解説があるということで、申し込み開始後、すぐ満席になりました～ 事の発端は以下のツイート参照。 @j5ik2o DDD本の読書会主催してて案件がド直球なのでお話していただきたいような・・・(参加者が通常6名ぐらいの会っすけど #DDDSheep — なおぴ！ (@naopi) 2014, 1月 23 この後、二つ返事で引き受けてくださったじゅんいち☆かとうさん！ イヤッッホォォォオオォオウ！ 主催の@naopiさんもグッジョブ！ この日は前日の京浜東北線の脱線
僕らが技術的負債と呼んでいるもの - ぐだぐだ言ってないでコードを書けよ、ハゲ。
photo credit: miguelavg via photopin cc 技術的負債は少しずつ蓄積されていきます。 技術的負債が何を指すのか、相手によって一部しか理解されないことがあるので、まとめてみました。 基本的にシステムの「品質」を構成する要素を逆に捉えただけなので、ここでは品質の構成要素をまとめます。 参考：アプリケーション アーキテクチャ ガイド - 品質特性の章 by Microsoft 設計 システム構造 全体が一貫性のある構造になっているか。 たとえばUIにビジネスロジックが入り込んでいないか。 保守のしやすさ 機能拡張しやすい構造か。 また、バグを修正しやすい構造か。 たとえば必要に応じて必要なモジュールのみを修正すれば対応できるようになっているか。 流用しやすさ 他のシステムにも流用しやすい構造か。 たとえばそのシステム以外にも同じUIコンポーネントをそのまま流用
デブサミ2014「社内システムの構造と設計、実装のはなし」講演メモ #devsumi - 元RX-7乗りの適当な日々
失礼ながら、モリス節炸裂しまくりで面白かった。話上手だなぁ。 「社内システムの構造と設計、実装のはなし」 田籠 聡 氏 @tagomoris LINE(株) 開発支援室 LINE 「LINEというサービス、みなさんご存じない方もいらっしゃるとは思いますが(ry」 DevOps, by Ops, for Ops 今日言いたいことは、、、 社内システムほど他システムとの連携を考えよう 社内システムではJSON APIを使おう 必要なものを作ろう これから1つずつ説明します。 Webサービス今昔 Web2.0: マッシュアップ全盛期 OAuth流行、支配的に WebAPIの制限 GoogleMapsのJS APIの制限等 Open Web API トラフィック、レスポンスタイムが課題 ニコ動も最初はコンテンツストレージにyoutube使ってた 太平洋横断してTTLが コストは誰が払う？ 互換性
ゲームサーバ開発現場の考え方
【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発 ～実践編～ 2019/9/25-6に開催されたUnite Tokyo 2019の講演スライドです。 小端 みより（株式会社ミクシィ） こんな人におすすめ ・Unityでより本格的なマルチプレイのゲームを作りたい方 ・そもそも通信や同期処理ってどうやって実装するの？という方 受講者が得られる知見 ・Unityで専用サーバを開発するメリットやその方法 ・Unityでサーバとクライアントを同時に開発するテクニック ・通信に関する知識、専用サーバを運用する方法 Unityのイベント資料はこちらから： https://www.slideshare.net/UnityTechnologiesJapan/clipboards
次世代Webアーキテクチャーの話 (CROSS2014を聞いて)
CROSS2014の次世代Webセッションを見て来た。 セッションの前半で議論されていたプロトコル編はしっかりとした方向性が示されていたが、後半のアーキテクチャー編は現状の混沌とした話が多くて、方向性というか新しいビジョンを示すまではいけなかった印象だった。 それは、サーバのアーキテクチャーが成熟していることも理由の一つなのかもしれない。 しかし、アーキテクチャーこそ方向性を示すのが重要だろうと思うので、個人的に考えていることをまとめることにした。 Webスケールを実現する技術とリアルタイムWebの方向性 リアルタイムWebというわけではないが、密結合なプロトコルはことごとくインターネットで玉砕されてきた歴史がある。 古くはCORBA IIOP、DCOMの失敗。それからSOAPの失敗。 （ちなみに、IIOPのIはInternetで、当初は大規模なインターネットスケールで分散させようとしたこ
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
Angular.jsで組む場合のアーキテクチャは、MVCじゃなくてMVVMの方が良いっぽいと思った話 - id:anatooのブログ
Angular.jsを何度か仕事で使ってみて、Angular.jsを使う場合のアーキテクチャはMVCじゃなくてMVVMにしたほうが良いなと思った話を書く。 Angular.jsをMVCフレームワークだと勘違いしていた 少しAngular.jsについて今まで勘違いしていたことがあって、Angular.jsではコントローラを定義できるのでてっきりMVCアーキテクチャで作るものとばかり思っていた。 公式ウェブサイトのタイトルをよくよく見てみると、「Superheroic JavaScript MVW Framework」と書いてある。MVWのWってなんだよとか思ってたらWhateverの略で、要するにMVCでもMVVMでもなんでも良いということらしい。 MVCで組んで困ったこと 勘違いが解ける前は、普通にMVCフレームワークとしてAngular.jsを使っていたけどもそれで何が困ったかというと、
2014年のウェブシステムアーキテクチャ - stanaka's blog
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
[その３] Netflix: APIの改善と継続的デリバリー - ワザノバ | wazanova
http://techblog.netflix.com/2013/08/deploying-netflix-api.html その1はこちら。 その2はこちら。 このシリーズの3回目は、Netflixのサービスが急成長する中で、APIの改善と平行して継続的デリバリーを実現した経緯を紹介してます。同社の継続的デリバリーの仕組みのキーワードは、"Automation and Insight"（自動化と見える化）。 1) 開発から本番アップまでのフロー 開発からAWSインフラへの本番アップまでの概念図がこちら。段階的に、開発している機能の精度があがりシステムの安定性が増すのを確認していくプロセス。 具体的な作業フロー図はこちら。ほとんどプロセスは自動化され、各ステップでコードのステータスを確認できるような見える化の工夫がなされている。 2) ブランチ 現状では下記の３つのブランチがあるが、中期的
[その２] Netflix: APIの改善と継続的デリバリー - ワザノバ | wazanova
http://techblog.netflix.com/2013/01/optimizing-netflix-api.html その1はこちら。 2回目は、改善をしたプライベートAPIのアーキテクチャーについて、もう少し詳細を掘り下げています。 1) サーバコールをまとめる 以前のNetflix APIでは、一つのユーザエクスペリエンスを実現するために、複数のリクエストをクライアント側からAPIにコールする仕様であった。[イメージ図] そこでリクエストを一つにまとめることで、WANの遅延の影響を一度だけ受けるかたちに抑えて効率化した。このまとめられたリクエストは、サーバ側では複数のものを並列処理できることを担保すべき。そうするとエンドポイントの開発をするクライアントエンジニアそれぞれが、ローレベルなスレッド/ 同期 / スレッドセイフティ / 並列データ構造 / ノンブロッキングIOなどの
[その１] Netflix: APIの改善と継続的デリバリー - ワザノバ | wazanova
http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html 北米のインターネットトラフィックの30%以上を占めるNetflixのシステム構成は、UI（デスクトップ、スマホ、タブレット、ゲームコンソール、TV、ブルーレイ再生機）とサービス（Video meta data, search, user, A/B test, personalization）をAPIでつなぐアーキテクチャーになっていて、UIとサービスがそれぞれ独立して早いスピードで改善 & 新機能を投入できるかたちになっています。そのAPI改善から継続的デリバリーの仕組みをつくりあげるまでの昨年からの一連の動きを、４回にわけて紹介します。まず最初はAPIの改善の取組みから。 1) 背景 Web APIとしてはRESTが標準的になっている
Groupon: 単一のRailsアプリから複数のNode.jsアプリへの移行 - ワザノバ | wazanova.jp
https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/ Grouponのビジネス自体はかつての盛り上がりはないですが、シンプルなRailsアプリが、事業の成長 & グローバル化に従って、アーキテクチャを変えていった過程をエンジニアブログで紹介してるので、参考になればと。 1) まとめ Grouponは、Railsのシングルコードベースを独立した20個のNode.jsアプリにアーキテクチャを変更した。 ページの読み込み時間が概ね50%改善。これはテクノロジーの効果とコードの書き直しでwebページが軽くなったのとの相乗効果。 同じトラッフィクに対してハードウェアが削減できた。 チーム間の依存関係が少なくなったので、新機能リリースのペースが早くなった 同じ機能を複数の国にそれぞれ導入するような冗長さが
国内注目の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業界やクリエイティブ
HTML5のシングルページアプリケーションのセキュリティ - mizchi's blog
昨日の記事で、抽象的なまま書きまくった反省もあるのだけど、それと同時に残念な気持ちになったので、すごく当たり前のことを書く。 オンラインゲームでクライアントに状態を持ったらメモリ操作されて危険っていうブコメが多かった。それは正直、古典的なウェブアーキテクチャから脱却できない残念な感じだと思ってる。 原則 クライアントはサーバーのキャッシュを作って、サーバーと同じロジックを持って、計算し、次の行動を決定する。 が、サーバーはクライアントから送られてくる情報を信用しない。 大事なことなのでもう一度言う。サーバーは、クライアントから送られてくる情報を信用しない。 対応 モデルの状態を受け取るのではなく、モデルのトランザクションを受け取る。 実装例 AからBに攻撃したい。この時にattackEnemyというAPIを作るとする。 ここでのクライアント目的では、手元のデータで対象に攻撃可能かどうかを判
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DDDがよく分かんないときに見てそこそこ分かった資料置き場 - DRYな備忘録
ソフトウェアアーキテクチャの求め方 - プロ生勉強会 第25回＠品川 #pronama
