分散キューという名の苦しみ - Software Transactional Memo
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
CDP:Fanoutパターン - AWS-CloudDesignPattern
解決したい課題 あるデータを元に、複数の処理を実行したいケースがある。例えば、画像をアップロードした後に、サムネイル、画像認識、メタデータのスキャンの三つのタスクを実行するなどのケースが該当する。 このような場合、画像アップロードを検知したアプリケーションからそれぞれの処理を呼び出して逐次処理は可能だが、各処理の時間が長い場合、トータルで非常に長くなる。例えば、画像アップロードをWeb 画面から実行した場合にサーバー側の処理が長ければ、ユーザーエクスペリエンスが悪くなる。 また、処理が増えた場合、例えばモノクロ画像作成のタスクを増やしたいような場合は、呼び出し元のプログラムを改修する必要が出てくる。 クラウドでの解決/パターンの説明 処理を呼び出すプロセスから直接各処理を呼び出すのではなく、間にノーティフィケーション（通知）コンポーネントとキューイングコンポーネントを入れることで、非同期か
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Xcode】コンパイル時に64bitかどうか判定する - Qiita
