アーキテクチャのトレンドサマリ（2014） - arclamp
今年はJavaOneに参加できたので、標準Java系は詳しい人に任せて、僕はアーキテクチャ関連の技術紹介や事例系のセッションを回ってきました。このサマリをJavaOne 2014 サンフランシスコ報告会 Tokyoにて発表しています。資料はこちらから。 動画はこちらから（コミュニティアップデートの途中からがアーキテクチャトレンドになります）。 発表時間が30分なのでコンパクトになっていますので、さっくりと見ていただければと思います。 もちろん「明日から案件に使えます」という話ではありません。ただ、JavaOneということもあって、話者はエンタープライズへの適用を前提にしています。よって、単純なスケーラビリティだけではなく、システム連携や信頼性についても意識はしています。意識したうえで「まだ簡単にはいかないけど、こうやっていくべきだ」という話です。 サマリとしては、アーキテクチャ設計をする上
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
"Microservices"を読んだ
James Lewis氏とMartin Fowler氏による“Microservices”を読んだ．以前ざっと目を通したが，最近よく耳にするようになったのでちゃんと読んだ．以下はそのメモ． 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア
大量データをスムーズに処理 失敗しないバッチ処理のアーキテクチャ設計、5つのポイント
バッチ処理とは 前回はWebアプリのアーキテクチャ設計の基礎を解説しました。今回はバッチ処理を円滑に行うためのアーキテクチャ設計のポイントを紹介します。 バッチ処理とは、蓄積された複数件のデータを、まとめて一括処理する処理形態のことを指します。このような処理形態においては、大量データの処理を一定時間以内に完了させるためのアーキテクチャを、さまざまな角度から検討していく必要があります。 また、画面オンライン処理とは異なり、ユーザーとの対話なく処理が進められます。よって、バッチ処理の途中でエラーが発生した場合の対応を考慮して、アーキテクチャを設計しなければなりません。バッチ処理の基本についてより深く知りたい方は、下記参考記事をご参照ください。 参考リンク:鉄板焼のお店から学ぶ、バッチ処理"超"入門（＠IT） バッチ処理におけるアーキテクチャ設計時の検討ポイント バッチ処理のアーキテクチャを考え
microservicesに分割する際に注意するべき5つのこと - Qiita
はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくことです。ですので、プロセスを跨いだ通信が大量に発生します。その結果、サーバー台数は増大します。 つまり、インフラコストの増大と開発速度の高速化のコスト感覚をバランスして判断していく必要があります。疎結合性が高まり、アーキテクチャとしては美しく感じますが、実施に
Webアプリ構築で、まず考えるべきアーキテクチャの検討ポイント（基礎編）
Webアプリ構築で、まず考えるべきアーキテクチャの検討ポイント（基礎編）：徹底解説！ ITアーキテクトとは何か？（2）（1/4 ページ） 連載目次 ユーザーの要求をアーキテクチャに落とし込む方法とは？ 前回は、アーキテクトの役割とタスクについて解説しました。今回からは、アーキテクチャ設計の話に入っていきたいと思います。アーキテクチャ設計の最初の段階で重要なのは、エンドユーザー／ユーザー企業の要求を見極めて、それをアーキテクチャに落とし込むことです。システムを設計する上で、ベストオブブリードでシステムを構成できる現在のようなオープンな環境の中では、さまざまな選択肢が存在します。その選択肢から選ぶ際に優先されるのは、「ユーザー要求」だということです。 例えば、顧客が「リアルタイムな情報反映と、その活用」を望んでいるにもかかわらず、バッチ処理中心型のシステムを設計・構築することは、エンドユーザー
AngularJSを使ったWebアプリのアーキテクチャ設計 - Qiita
AngularJSは公式で分かりやすいチュートリアルが用意されているし、日本語の記事も増えてきたし、けっこう簡単に使い始めることができるんじゃないかと思います。 でも、チュートリアルやサンプルはクライアントサイドオンリーなことが多くて、サーバーサイドも含めたWebアプリを作ろうと思うと、どういう構成にすればいいのか迷うのではないでしょうか？（僕がそうでした） 最初は試行錯誤していたのですが、書籍やネットの記事を読んだりGitHubで見つけたアプリを真似たりしているうちに、どういう構成にすればいいのかだんだん見えてきたので、解説してみたいと思います。 SPA 最近、SPA（Single Page Applicationまたは Single Page Web Application）という言葉をよく耳にするようになりました。 SPAとは、最初のページだけ通常のWebアプリと同じようにサーバーか
アーキテクチャ設計に品質特性を使おう - arclamp
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報
Oracle Database 12cによるDB最適化(2) 「マルチテナント・アーキテクチャ」でDB運用管理の方法論が進化する
前回は、主に「データベース統合」の観点から、Oracle Database 12cで新たに採用された「マルチテナント・アーキテクチャ」がもたらすメリットについて紹介した。今回は、このアーキテクチャによって、旧来のDB運用管理の方法論が、どう効率的になるのかについて説明していこう。 ここで少しだけ復習をしておこう。マルチテナント・アーキテクチャは、1つのデータベース上に、複数の仮想的なデータベースを作成して稼働を可能にする機構だ。構成にあたっては、新しい型のデータベースである「マルチテナント・コンテナ・データベース（CDB）」を作成し、その上に「プラガブル・データベース（PDB）」を差し込んで稼働させるスタイルになる。 CDBではメモリやCPUといったシステムリソースを管理し、その上で稼働している複数のPDBで共有する。そのため、一般的な仮想化機構を使った仮想マシンによる方法よりもオーバーヘ
アーキテクトと要求もしくは技術について[追記あり] - arclamp
2014年2月27日の要求開発アライアンス２月定例会で「アーキテクチャの発掘に見る要求変化の発見」、そして翌2014年2月28日にはEnterprise ☓ HTML5 Web Application Conference 2014で「JavaエンタープライズアーキテクチャにおけるHTML5」という講演をさせていただきました。 前半は（ここ数年間は同じですが）、ITサービスの提供において「利用価値、提供機能、構成／構造、プロセス」の４つの要素のバランスが重要であり、そのバランスを取る事がアーキテクチャ設計だという話です（そのバランスを保ちながらモノを作るのがマネジメントですね）。そして、後半はそれぞれのイベントの趣旨に従って変えています。 要求定義がきちんとできても、どんなにHTML5に詳しくても、あるいは、どんなにアジャイルがうまく回っても、それ"だけ"で良いITサービスを提供する事は出
![アーキテクトと要求もしくは技術について[追記あり] - arclamp](https://cdn-ak-scissors.b.st-hatena.com/image/square/6d8216e64106bac7e18f0344459bda51cb85fdba/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704346814673873149%2F12921228815719241700%2F1396502451)
ITの地殻変動はどこで起きているのか～アーキテクチャ設計技術にクラウドが必須になった時代 - プログラマの思索
2014年になって、ITの地殻変動がどこに起こっているのか、を考えてみる。 ＃ラフなメモ書き。 【1】最近感じることは、Webアプリをプログラミングするアプリケーションエンジニアよりも、サーバー基盤を構築するインフラエンジニアの方が目立つというか輝いて見える時が多い。 何故なのだろう？ また、先月の日経BP主催のITアーキテクト カンファレンスでは、エンタープライズシステムの構築に携わるITアーキテクトを対象にしているが、その内容はすべて、クラウドがキーワードだった。 DOAやOOAは全く含まれていない点が衝撃だった。 ITアーキテクト カンファレンス 2013 最近の流れを見ると、アーキテクチャ設計の技術では、DOAやOOAは既に古い技術であり、クラウドが席巻しているように見える。 【2】最近のバズワードである「クラウド」には、否定的な意見を持つ人も多い。 ITの歴史の延長線上にあるだけ
モジュラー型 vs. インテグラル型－－設計のアーキテクチャ再論 | タイム・コンサルタントの日誌から
3年前に書いたサイトの記事「モジュラーとインテグラル － 製品アーキテクチャーの二つの方法」に、最近、読者の方から質問が寄せられた。良い質問だと思うので、ここでとりあげ、あらためて自分の考え方をご説明したい。 ご質問は、つぎのとおりだ（やや長いが、全部引用させていただく）： 「車がインテグラル型アーキテクチャということは多方面で言われていることなのですが、すんなり納得ができません。 確かに、ボディ形状は独自設計ではありますが、ヘッドライトは他車種でも移植可能なものもありますし、内部のランプ単体については明かな標準規格品です。 また、ハンドルの入れ替えも(日本国内法は別として)置き換え可能ですし、ワイパーやウィンカーレバーはメーカー内で汎用品になっていることが多いです。 タイヤは規格品ですし、ホイールやサスペンションも変更可能です。確かに社外メーカーが純正品規格に合わせて作っているからである
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
FacebookにおけるMySQLを用いた大規模システムアーキテクチャの現実～MySQL Connect 2013
米オラクルが主催するMySQLのイベント「MySQL Connect」が9月21日から23日まで、サンフランシスコで開催されました。Oracle OpenWorld、JavaOneとの同時開催でした。 基調講演の1つには、MySQLのヘビーユーザーであるFacebookのHarrison Fisk氏が登壇。FacebookにおけるMySQLの役割、大規模運用の背景などを紹介しています。その内容をダイジェストで紹介しましょう。 MySQL@Facebook Lots and lots of small data Harrison Fisk氏。 Facebookでデータパフォーマンスチームのマネージャをしている。社内ではMySQLはもちろん、HBase Hadoopなどにも関わっている。 まずは、どんな種類のデータをMySQLで扱っているのかについて。 Facebookとは基本的にグラフだ。グ
最速最強Webサーバーアーキテクチャ - Qiita
POST /post HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 7 foo=bar 1行目は request-line で、 method URI HTTP-version の形をしています。URIはホストを含めた絶対URIの場合と、ホストを含めない絶対パスの場合がありますが、絶対パスの方が一般的です。 2行目から空行までが request-header です。各行は field-name: field-value の形をしています。 field-name は大文字小文字を区別しません。 request-line から request-header とそれに続く空行まで、改行は CR LF になってます。Windowsでよく見る改行コードですね。 meth
OTN Japan - 今だからデータ・アクセスを真剣に考える！ 第1回
システムを構築する上で必須となるデータベースアクセスの機能、皆さんはどのように実装しているでしょうか？JDBCで記述/EJB Entity Bean(BMP/CMP)を利用/データアクセスフレームワークを利用、等様々な実装方法を選択されているかと思います。 この連載では、様々な観点からデータアクセスに関わる事項を取り上げ、皆ささんがデータベースアクセスについて、少し考えてみる場になればと思っています。まず今回のデータアクセスことはじめ（前編/後編）では、これから様々なデータベースアクセスに関する事項を扱っていく上でのベースとなる知識を取り上げます。 現在、Javaプログラミング言語を用いてエンタープライズシステムを開発する場合、要件変更への設計・実装の変更の容易性、JDBC、EJB Entity Beanなどのデータアクセス要素技術とのマッピングの容易性、等々の理由により、システム全体を論
＠IT：連載 INDEX - 保守性・拡張性に優れたシステムを作る
保守性・拡張性に優れたシステムを作る（12）： システム開発はなぜ楽にならないか？ これまで、本連載ではこれまで11回にわたって、システムの拡張性・保守性を考慮するうえで重要になるオブジェクト指向における分析設計の流れや考え方を解説してきた。最終回では、なぜいまもってシステム開発が楽にならないのかについて、筆者の考え方を紹介したい。（2008/7/15） 保守性・拡張性に優れたシステムを作る（11）： キミの設計に「トレーサビリティ」はあるか システム開発は5つのステップ（工程）に分けられる。全体の流れを可視化し、それぞれの工程で発生する影響範囲を追跡する。それにより、構築後の保守・拡張性をも視野に入れた作業を行うことが可能となる。（2008/2/7） 保守性・拡張性に優れたシステムを作る（10）： ドメイン層をシンプルに作るためのO-Rマッピング （2007/9/13） 保守性・拡張性に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アーキテクチャでアジャイルを管理する
【1カ月集中講座】 骨まで理解するPCアーキテクチャ(GPU編) 第1回 ～固定機能からシェーダへの移り変わり
ITアーキテクトを目指すあなたが、今読むべき3大連載
