2016年10月24日のQCon Tokyo 2016にて「今どきのアーキテクチャ設計戦略」という講演をさせていただきました。 アーキテクチャ設計のジレンマ 伝統的に、アーキテクチャ設計というのは設計や実装に先立って事前的に行われる必要がある、とされています。設計や実装は定義されたアーキテクチャを参照しながら進めなくてはならないからです。なので、アーキテクチャ設計にあたっては「システムの振る舞いに対する要求」という「話」を理解して進めていくことになります。そのため、その要求が正確であればあるほど適切な構造を定義できることになります。これは当たり前のことですね。 一方で、現在的なシステム開発というのはアジャイルに代表される「フィードバックと改善によって段階的に機能を拡張する」という前提にあります。これも当たり前のことで「誰も事前に正しい要求を定義できるわけがない」から「動くソフトウェアを見て
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
想像してみてください。今この瞬間…… 悪意のないユーザがF5キーに手を添えたまま、うたた寝してしまうかもしれません 巨大ニュースサイトにリンクが張られ、大量のユーザが流れ込もうとしているかもしれません エンジニアが不注意で埋め込んだ不具合がプロセスを落とし、パフォーマンステストを怠ったSQLがCPUやIOを占有することもあるでしょう ミドルウェアやOS、ネットワーク機器のファームウェアだって完ぺきではありません サーバのメモリを狂わせるため、宇宙線は虎視眈々と隙をうかかがっています 数え上げればきりがない程、サーバ達は常に危機に晒されているのです。 一台のサーバやネットワーク機器の障害で大切なシステムをダウンさせてしまうわけにはいきません。 深夜に障害を告げ鳴り響く携帯電話に叩き起こされ、やっとの思いでシステムを復旧させた朝、関係各所に平謝りしながらクライアントへの障害報告書を用意する、な
少し前に，Facebookのロードバランサが話題になっていた． blog.stanaka.org このエントリを読んで，各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた． ざっくり検索した限りだと，Microsoft, CloudFlareの事例が見つかったので，Facebookの例も併せてまとめてみた． アーキテクチャ部分に注目してまとめたので，マネジメント方法や実装方法，ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする． 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた？)ロードバランサのアーキテクチャは，下記の論文が詳しい． Parveen Patel et al., Ananta: cloud scale load balancing
下記は一般的なn層アーキテクチャーの図です。各層をここでは「Presentation」、「Business Logic」、「Data Access」と表現しています。 ただしいくつか特徴があります。一点目は、参照系と更新系のBusiness Logicを分別して表現していること。二点目は、「Access Control」機能を明示し、かつ、参照系では「Operation」と明確に分離させていて、更新系では境界を曖昧としています。 更新系Business Logicに対して「Lifecycle Management Operations」と別名を与えています。ここで「参照系」「更新系」の用語を、低レベルI/Oとしての単純CRUDを意味するものとしては用いていません。業務データは、作成され、何段階かの更新（※一般に更新操作は複数種類ある）がなされ、最後に破棄されるという経緯を経るでしょう。業務
要約 (1) 参照系の要件はもっぱらデータ資源利用側から発せられ、更新系の要件はもっぱらデータ資源提供側から発せられる。 (2) よって、もし「フロントエンド・アプリ」と「バックエンド・サービス」とに階層分けするならば、参照系は「フロントエンド・アプリ」が装備すべきで、更新系は「バックエンド・サービス」が装備すべきである。 (3) 以上のように分離された参照系と更新系は、同一データ資源を扱っていても、もはや異なる境界付けられたコンテキストに属すると云うべきである。 (4) DDDにおける「CQRS」は、参照系と更新系が異なる境界付けられたコンテキストに置かれるとした場合の設計アプローチに関する論だと捉え直すことができるのではないか。 ◇ 参照系と更新系の非対称性について気付いたのは、かつて「ROA」と「SOA」の差異の本質は何なのかを考えた時でした。 ROAでは、リソースを比較的“裸”に公
ソーシャルゲームを作る時に参考になるデータベースやKVSの選定、設計などの記事やスライドのまとめ 2013-02-03追記 スライド ソーシャルゲームのためのデータベース設計 http://www.slideshare.net/matsunobu/ss-6584540 とあるアプリの開発運用(トラブルシュート) http://www.slideshare.net/takafumionaka/ss-5852561 PHPで大規模ブラウザゲームを開発してわかったこと http://www.slideshare.net/ketaiorg/php-4638298 Lampで作るソーシャルアプリの負荷対策〜アプリとインフラの調和のテクニック〜 (Klabさん) http://www.slideshare.net/klab/4-d6963726f736f667420506f776572506f696e
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
先週書いたエントリJava EE6標準の範囲でフルスタックのWebアプリケーションが簡単に作成できることを確かめてみました。 - 達人プログラマーを目指してで、Java EE6の標準仕様を使うだけで、かなりシンプルにデータのCRUD処理を行うアプリケーションが作成できることを紹介しました。ただし、前回は全体のアプリケーションを紹介しただけなので、細かい仕掛けについては解説しきれませんでした。今回は、前回に引き続き特にJPAを使ったデータベースアクセスの部分がどうなっているのかをもう少し掘り下げて解説してみたいと思います。 なお、この場で宣伝ですが、8月10日（水）にGlassfishユーザーグループの勉強会にてお話をさせていただくことになりました。 GlassFish Japan Users Group 勉強会 2011 Summer : ATND 私はJava EE6を使った開発について
一般的な業務アプリケーションではデータを永続化するために、RDBMS（関係データベース管理システム）を利用します。RDBMSでは大量のデータを効率的に検索したり、集約してレポートを作ったりすることが得意ですし、一般的に業務システムで求められるトランザクションのACID特性*1を満たすことも容易です。また、適切にテーブル設計の正規化を行うことにより、運用面においてデータの管理コストを下げることもできます。最近ではスケーラビリティの問題などもあり、RDBMS以外のデータベースについても注目されるようになってきていますが、今後も業務アプリケーションの主流としてRDBMSは使われていくだろうと思われます。 従って、Javaなどのオブジェクト指向言語で開発を行い、DDDのようなオブジェクト指向の設計技法を利用する場合に必ず考えなくてはならない問題は、オブジェクト指向と関係モデルとのインピーダンスダン
文書情報 更新履歴 2009.12.16 -- 新規作製 2010.06.27 -- ストアドに関するメモ書きを追加 2010.08.16 -- スタイル修正 2010.10.14 -- 最終更新 本稿の目的 DB設計に関する雑多な事柄を記録する。特に断りが無い場合MySQLが対象である。 テーブルの考え方 リソースとイベント 主キーと外部キー 必須なフィールド オプショナルなフィールド フィールドの桁数とかデータ型について フィールドの役割とか キー項目 それ以外 大雑把な指針など。 (1) 特に桁数に縛りが無い項目で255文字以下に納まるデータは一律varchar(255) (2) (1)以上の桁数が入るデータは(text)型 (3) (2)の条件にあてはまるが、検索対象となる項目はインデックスの考慮が必要なので別途考える (4) 主キーはAutoIncrimentのINT(UNSIG
小規模のサービスを如何にスモールスタートするか、そのために各コンポーネントをどうやって配置するのがいいのかという話。個人的な考えも含めて。 大まかな構成は昨年のnekokakさんのYAPC::Asiaでの発表、省サーバ運用と大体同じです。Web/Appに使うサーバ2台、データベース2台です。あとはLBが別にあればそれを、なかったらもう一台(組)必要となります。 Web/Appサーバには、Reverse Proxy、Application Serverがまず配置されます。あとは必要に応じてmemcached、Job Queueのworkerを動かします。ここまでのコンポーネントは2台のサーバ両方に配置し、Active-Activeで動作し冗長性がとれるよう構築します。cronについては、両方のサーバで動かしても問題がない状態が理想ですが、そうでない場合、Web/Appの1台目で動かすというル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
