タグ

architectureに関するnakackのブックマーク (14)

  • ソフトウェアアーキテクトが知るべき97のこと

    ソフトウェアアーキテクトが知るべき97のこと大人気の書籍『ソフトウェアアーキテクトが知るべき97のこと』のエッセイを無料で公開中!すべてのソフトウェアアーキテクトにおすすめのがウェブで読めるようになりました。 エッセイ一覧システムの要件よりも履歴書の見栄えを優先させてはならない質的な複雑さは単純に、 付随的な複雑さは取り除け最大の問題は、たぶん技術的なことではないまずコミュニケーション、そのための明快さとリーダーシップパフォーマンスの決め手はアーキテクチャー要求仕様の当の意味を探れ立ち上がろう!すべてのものは、かならずエラーを起こすそれは交渉だということに気付け定量化を求めよ500行の仕様書より1行のコードフリーサイズのソリューションを求めるなパフォーマンスの検討に早過ぎるということはないアーキテクチャーとはバランスをとること犯罪的なコミットエンドラン

    ソフトウェアアーキテクトが知るべき97のこと
  • 伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する(前編)。QCon Tokyo 2016

    クラウド上でアプリケーションを構築する新しい手法として「サーバーレスアーキテクチャ」が急速に注目を集めています。しかし一方で、サーバーレスアーキテクチャを採用することで得られる質的なメリットはなにか、そもそもサーバーレスアーキテクチャとはなにを指すのか、などについてはまだ識者の間でも議論されていることです。 10月24日に都内で開催されたイベント「QCon Tokyo 2016」の伊藤直也氏のセッション「Serverless Architecture」は、こうしたサーバーレスアーキテクチャの質について大きな示唆をもたらす内容でした。この記事では、その内容をダイジェストで紹介します。 (記事は前編、中編、後編に分かれています。いまお読みの記事は前編です。) Serverless Architecture 一休 CTO 伊藤直也氏。 先に結論を言ってしまうと、サーバーレスアーキテクチャと

    伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する(前編)。QCon Tokyo 2016
  • Serverless: Zero-Friction Serverless Apps On AWS Lambda & Beyond.

    Easily define your applications as functions and events. Declare AWS Lambda functions and their triggers through simple abstract syntax in YAML. Deploy infrastructure and code with a single command. AWS Lambda functions, triggers & code will be deployed and wired together in the cloud, automatically. Extend your use-cases and workflow with Plugins. Install thousands of Serverless Framework Plugins

    Serverless: Zero-Friction Serverless Apps On AWS Lambda & Beyond.
  • クックパッドにおける最近のMicroservices事例 - クックパッド開発者ブログ

    こんにちは。技術部の吉川です。 最近ではMicroservicesという言葉もかなり浸透し、そのテクニックも体系化されつつあります。 一方でMicroservicesについての話は概論や抽象的な話が多く、具体像が見えないという方もいらっしゃるのではないでしょうか。 当ブログでは1年半ほど前にMicroservicesへのとりくみについてご紹介しました。 当時社内ライブラリだったGarageはその後オープンソースとして公開され、また社内のシステムも当時と比べ飛躍的な進化を遂げています。 そういったクックパッドにおける最近のMicroservices事例を先日Microservices Casual Talksで紹介しました。 Microservicesの抽象的な話は一切割愛し、具体的な事例に終始した内容となっています。 Microservicesの基となる考え方はわかったものの、実践方法で

    クックパッドにおける最近のMicroservices事例 - クックパッド開発者ブログ
  • アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD

    注釈: CASH LAYER:キャッシュレイヤ FRONT END:フロントエンド ASSET SERVE:アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER:ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD:クラウド ALL READS! :全ての読み込み WRITES:書く READS:読む MASTER:マスタ INPORTANT POINTY THINGS:重要な鋭い情報 MULTI MASTER DB CLUSTER:複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー

    アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
  • サーバレスアーキテクチャとは? - プログラマでありたい

    サーバレスアーキテクチャの整理です。少し前は、2-Tier Architecture(クラウドネイティブなアーキテクチャ)と3-Tier Architecture(従来のアーキテクチャ)という対比で論じられることが多かったです。しかし、API Gatewayの登場により、3-Tierな構造でもクラウドネイティブなアーキテクチャにしやすくなりました。ということで、サーバレスアーキテクチャ(ServerLess Architecture)と呼ばれることが多いです。 サーバレスアーキテクチャのパターン それでは、従来型のアーキテクチャ(旧3-Tier)と2-Tierパターン、API Gatewayを利用したサーバレスアーキテクチャをそれぞれ見てみましょう。 従来型のパターン( アプリケーションサーバ・パターン) まずは従来型のアーキテクチャです。間にELBを挟んでAutoScaleにすることは多

    サーバレスアーキテクチャとは? - プログラマでありたい
  • AI、IoT、ビッグデータなど知っておくべき4つの俯瞰図 | IT Leaders

    IT Leaders トップ > テクノロジー一覧 > 業界動向 > 市場動向 > AI、IoT、ビッグデータなど知っておくべき4つの俯瞰図 業界動向 業界動向記事一覧へ [市場動向] AI、IoT、ビッグデータなど知っておくべき4つの俯瞰図 2015年7月15日(水)田口 潤(IT Leaders編集部) リスト 米国ではベンチャーキャピタリストなどの投資家が、担当分野の俯瞰図(ランドスケープ)を作成し、公開しているケースがある。分野の動きを追ったり企業動向を把握するには状況を一覧して把握できる俯瞰図が、とても都合がいいからだだろう。この種の整理は日ITリーダーにとっても大いに参考になる。 例えば、Machine Intelligence(http://www.shivonzilis.com/)。いわゆるスマートマシン分野の俯瞰図だが、コア技術だけでもArtificial Intel

    AI、IoT、ビッグデータなど知っておくべき4つの俯瞰図 | IT Leaders
  • 分散システムの一貫性に関する動向について

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog システム統括部アーキテクト室 今野です。 昨年は、Twitter,Facebookを始めとするクラウド各社で新規の分散システム開発のプロジェクトが相次いで発表された年でした。これらの新しい分散システムを開発する理由や、その背景にあるものは何なのでしょうか? 今回は、昨年末に開催された高信頼性分散システム系の国際学会であるSRDS 2014[1]の発表内容に関連する論文の話題も踏まえて、昨今のクラウド各社の分散システムの動向について整理してみます。 分散システムにおけるクラウド各社の動向 近年の分散データベースの世界では、AmazonのDynamo[2]やFacebookのCassandra[3]などを代表とする結果整合性(Eve

    分散システムの一貫性に関する動向について
  • 「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏(前編)

    でも選挙活動にインターネットを利用するという議論が始まっていますが、世界でもっとも大規模にインターネットを利用して選挙活動が行われたのが、昨年の米大統領選挙です。 その選挙戦を勝ち抜いたオバマ大統領のチーム「Obama for America」が、どのような選挙キャンペーンシステムを構築したのか。3月15日に都内で行われたAmazonクラウドのイベント「JAWS DAYS 2013」で、語られました。 そこでは、過去の選挙データやソーシャルメディアなどを元に有権者の動向を徹底的に分析し、テレビCMの打ち方からボランティアの働き方まであらゆるものを最適化する大規模なシステムをいかに構築したのか。そして、大規模システムでクラウドを活用するとはどういうことか、ということを学ぶ絶好のサンプルになっています。 国内でこのシステムの舞台裏がこれほど詳しく紹介されることは初めてのはずです。講演の内容

    「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏(前編)
  • 情報アーキテクチャの脊髄を視覚化

    2月9日に東京で開催された World IA Day 2013 に参加してきました。前回の記事 で書いた今後の IA の課題のヒントになるようなメッセージを、イベントを通して幾つか見つけることができました。 今回は吸収した内容を自分なりにインフォグラフィックにしてみました。 イベントを通して『情報』にはデータベースに蓄積できるようなものと、掴み所がないものと二種類あると考えました。言い換えれば右脳的な情報と左脳的な情報があるといったところでしょうか。まったく違う存在のようにみえる二種類ではありますが、4つの段階を踏んでアーキテクチャ(構造)を作り出しているようにみえました。 Deconstruct (分解) Sort(分類) Compose(構成) Adjust(調整) つまり、感情やニュアンスといった掴み所のない情報だったとしても、ビッグデータを活用した情報の解析だったとしても、進むべき

    情報アーキテクチャの脊髄を視覚化
  • セールスフォースのアーキテクチャ(物理アーキテクチャ編)~ Podによるスケールアウト

    米国の計算機学会として知られるACMが主催したクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」(ACM SOCC 2010)が6月10日、11日にインディアナ州インディアナポリスで開催されました。 基調講演には、グーグル、Facebook、セールスフォース・ドットコムというクラウド業界のトップベンダーが登場し、それぞれのクラウドについて語るという内容でした。ここではその基調講演から、セールスフォース・ドットコムのRob Woollen氏による同社クラウドのアーキテクチャの解説を紹介します。おそらくこれまででもっとも詳しく、同社のクラウドアーキテクチャを解説したものになっています。 セールスフォースのマルチテナントアーキテクチャとは Rob Woollen氏。講演タイトルは「Inside Cloud:Salesforce.

    セールスフォースのアーキテクチャ(物理アーキテクチャ編)~ Podによるスケールアウト
  • マルチスレッド・プログラミングの落とし穴、その2

    ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その1(かもしれない)」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD(Create/Read/Update/Delete)のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに(HTTP Requestに返事をする前に)データベースに変更を加え、Readの際にも(キャッシュを使う・使わないを別にして)データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと

  • 地盤環境工学分野 - 京都大学大学院 工学研究科 都市環境工学専攻 -

  • mixi Engineers’ Blog » 新RSS Crawlerの裏側

    このブログでは初めましての長野雅広(kazeburo)です。mixi開発部・運用グループでアプリケーションの運用を担当しています。 12月12日よりmixiのRSSのCrawlerが改善され、外部ブログの反映が今までと比べ格段にはやくなっているのに気付かれた方も多いかと思います。この改善されたRSS Crawlerの裏側について書きたいと思います 以前のCrawlerについて 以前のCrawlerは cronからbrokerと呼ばれるプログラムを起動 brokerはmember DBから全件、idをincrementしながら取得し、外部ブログが設定されていればcrawlerを起動(fork) crawlerはRSSを取得しDBに格納して終了 このような設計になっていました。 この設計の問題として、member DBを全件走査するという無駄な動作と、一件一件crawlerを起動するためオーバ

    mixi Engineers’ Blog » 新RSS Crawlerの裏側
  • 1