[方式設計編]性能要件はユーザーが決めると思ってはいけない
「ユーザーが要件を決めてくれないので…」「性能要件を出していただかないと機器が見積もれません，早く要件を出してください！」。要件定義フェーズのみならず，プロジェクトの様々な工程でよく耳にする言葉である。 非機能要件はユーザーにヒアリングして洗い出すのが，インフラ設計における一般的な手法だ。だが，インフラ設計者はヒアリングによって得られたユーザーの「要望」を絶対的な「要件」としてとらえてはいけない。非機能要件を洗い出すに際しては，要望の裏にあるリスクやそこから派生する制約を先読みすることが重要である。その思考を停止してしまうと，後工程で様々な問題が発生する。 今回は，非機能要件の中でも読者にとって最も身近だと思われる「（オンラインの）性能要件」を例に解説する。なお，現在のシステム構築では，現行システムが存在せずゼロから開発することはほとんどない。従って，ここでは現行システムで何らかの稼働統計
![[方式設計編]性能要件はユーザーが決めると思ってはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
出版-購読型モデル - Wikipedia
出版-購読型モデル（しゅっぱん-こうどくがたモデル、英: Publish/subscribe）は、非同期メッセージングパラダイムの一種である。メッセージの送信者（出版側）が、特定の受信者（購読側）に直接メッセージを発行するプログラムではなく、発行（出版）されたメッセージはクラス分けされ、どんな受信者が居るのかは知らない。受信者は興味のあるクラスを指定しておき、そのクラスに届くメッセージだけを受け取り、どんな送信者が居るのかは知らない。送信者と受信者の結合度が低いため、スケーラビリティがよく、動的なネットワーク構成に対応可能である。 出版-購読型モデルはメッセージキューパラダイムと対比され、一般に大きなメッセージ指向ミドルウェアの一部として使われる。一部のメッセージシステム（Java Message Serviceなど）は、出版-購読型とメッセージキューの両モデルをサポートしている。 メッセ
オンラインマニュアル ページ移転のお知らせ：ミドルウェア：ソフトウェア：日立
日立オープンミドルウェアは、お客様の既存の財産を生かしながら、高い信頼性と柔軟性、自律性を備えたITシステムの実現を支えています。
［次世代DB編］DWHアプライアンスでOLTPを動かしてはいけない
データウエアハウス（DWH）分野では、アプライアンス型の製品が続々と登場している。DWH環境が高性能・高機能になったことで、分析対象には日次バッチの結果だけでなく、より頻度の高い更新データも扱えるようになった。 ところが、よく耳にするのが「DWHアプライアンスで業務系システムのOLTP（オンライントランザクション処理）を動かしたい」という要望である。確かに、リアルタイム更新が可能であれば、OLTPを実現できると考えがちだ。景気停滞の中で、業務系と情報系のサーバーを一つに統合できれば、コスト削減にもつながる。 とはいえ、最新のDWHアプライアンスをもってしても、そのアーキテクチャーはあくまでDWH向けである。原則として、DWHアプライアンスでOLTPを動かしてはいけない。DWHとOLTPには、プラットフォームだけでは乗り越えられない違いがある。 性能が全く出ないケースも DWHアプライアンス
「これからのWeb(バックエンド)」を自分の頭で考えてみた - As a Futurist...
ふと今更、年初のCROSS 2013の「次世代 web セッション」の動画を見て、うんうん唸ってしまった。プロトコル編の方は知識不足であんまり分からなかったですが、アーキテクチャ編の方はグサグサくるものがあった。「自分の頭でこれからの web を考えてブログに書くまでがこのセッション」という宿題が出ていたので、せっかくなので最近考えてることをつらつらと書いておこうと思った次第。特にまとまりはないですし、戯言です。 これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2013) – Block Rockin’ Codes 前提 僕はコード書いてない＆サーバサイドしか見たことない＆WEB サーバはあんまり見たこと無くて、それより後ろ側ばっかり見てた人なので、ユーザ側とかアプリ開発者がどうなっていくかについて特に尖った意見はありません orz SPDY とかもまだ手を
DI コンテナがコードに出現するのは dependency lookup が行われている兆候
Dependency Injection (DI) コンテナを基盤にしたアーキテクチャを採用している場合に、(プロダクト|テスト)コードに DI コンテナが登場するのは dependency lookup (依存コンポーネントの検索)を行っている兆候と考えることが出来ます(もちろん必要があってコンテナの injection が行われている場合もあります)。 テストに DI コンテナが出現することに気付いたら、 Dependency lookup から Dependency Injection (DI) へのリファクタリングの契機とすることもできるでしょう。 続きを読む
チューリング・テスト再考
Some C are NOT B なお、チューリングは「ソクラテスの名前が出てきたときには Barbara」と言っているが、たぶん、これは、以下のような三段論法の実例を想定していると思われる（誰もがどこかで一度は見たことがあるやつだと思うのだけど）… すべての人間は死ぬべき運命にある ソクラテスは人間である それゆえソクラテスは死ぬべき運命にある 「ソクラテス」を「すべてのソクラテス」に置き換えれば、この三段論法が Barbara であることが明解になる。 寄り道が長くなったが、本題に戻ろう。チューリングは、推論の仕方を指示すること（プログラムであればアルゴリズムの選択にあたるだろう）の重要性を述べている。そして、論理的に思考している場合でも brilliant と footling の差が生じるのは、数多くの選択肢の中から何を選ぶかの違いだという。このへんは、数学とか論理学での才能の差は
いきあたりばったりのアーキテクチャと教訓
スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。 そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです（訳は前述の記事「データベースの間違った使い方10項目」から）。 Dynamic table creation（動的なテーブルの作成） Table as cache（テーブルをキャッシュとして使う） Table as queue（テーブルをキューとして使う） Table as log file（テーブルをログとして使う） Distributed Global Locking（分散したグローバルなロック）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大規模ログ分析におけるAmazon Web Servicesの活用
