タグ

architectureに関するi97506051502のブックマーク (16)

  • アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離(新規開発のメモ書きシリーズ4)

    新規開発のメモ書きのラスト シリーズだったはずなのに、色々あって前回のエントリから1ヶ月あきました。_:(´ཀ`」 ∠): 今回の話の中心は結果的に「Server Side Rendering との折り合いの付け方」と「Fastly を利用した動的コンテンツのキャッシュ戦略」です。 このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ まずは全体的なアーキテクチャ像 次の図はアーキテクチャの全体像です。クライアントサイド寄りの範囲を中心に書いているため、バックエンドな Microservice 群以降がおざなりな図ではありますがご容赦ください。 主要リソースは Fastly を通じ

    アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離(新規開発のメモ書きシリーズ4)
  • クリーンアーキテクチャ(The Clean Architecture翻訳)

    Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしいで採用した。 Onion Architecture by Jeffrey Pa

    クリーンアーキテクチャ(The Clean Architecture翻訳)
  • 若手が知らないメインフレームと銀行系システムの歴史&基礎知識

    若手が知らないメインフレームと銀行系システムの歴史&基礎知識:FinTech時代、銀行系システムはどうあるべきか(1)(1/2 ページ) 連載では、銀行系システムについて、その要件や歴史を整理しつつ、スマートフォンを使う銀行取引やブロックチェーンなど、新しい技術が及ぼす影響を考察していきます。初回は、メインフレームと銀行系システムの歴史と基礎知識についてです。 「Finance(金融)」と「Technology(技術)」を足した造語である「FinTech」。その旗印の下、IT技術によって金融に関わるさまざまな業務や処理を利便化し、ビジネスの拡大を図る動きが国内金融業界から大きな注目を浴びています。特に金融業界の中心である“銀行”が運用するシステムについては話題に事欠きません。 例えば、ブロックチェーンによって銀行の勘定系システムが変わるという話があれば、2016年10月から日でも利用可

    若手が知らないメインフレームと銀行系システムの歴史&基礎知識
  • System of Record と System of Engagement

    補足を以下に記載しています: https://www.wantedly.com/companies/ikyu/post_articles/42802

    System of Record と System of Engagement
  • コレオグラフィ vs オーケストレーション

    SOA や BPM の世界では、ビジネス プロセスの構築や実行制御を指すものとして、コレオグラフィ と オーケストレーション という 2 つの用語が使われています。 Fiorano Software では、ビジネス プロセスの構築/実行を指す言葉として コレオグラフィ を意図的に用いています。 これは、コレオグラフィとオーケストレーションという言葉が意味するものが、ビジネス プロセスの構築/実行においてそれぞれ異なるからです。 1. 辞書的意味 コレ1. オグラフィ (choreography) とオーケストレーション (orchestration) の辞書などに掲載されている意味合いは、次のようになっています。 コレオグラフィ (choreography) バレーや舞踏などの振り付け オーケストレーション (orchestration) オーケストラによる演奏方法 バレーとオーケストラと

    コレオグラフィ vs オーケストレーション
  • Dropboxが構築したMagic Pocketの中身:エクサバイトのストレージシステムの仕組み | POSTD

    自社で構築した数エクサバイトのストレージシステム、 Magic Pocketを発表 して以来、多くの好意的なフィードバックをいただいています。この発表に続きまして、舞台裏からシステムの興味深い側面を見ていただくことができる技術ブログシリーズを投稿していこうと思います。保護の仕組み、運用ツール、ハードウェアとソフトウェアの境界線上の革新などです。しかし、まず、背景を説明する必要があるでしょう。稿では、Magic Pocketのアーキテクチャ概略と設計で使われた基準についてお話しします。 紹介の投稿 で説明しましたように、Dropboxには、ファイルの内容と、ファイルやユーザについてのメタデータという2種類のデータが保存されます。Magic Pocketは、ファイルの内容を保存するのに使われるシステムです。保存するファイルは、ブロックに分割されて耐久性のためにレプリケーションされ、複数の地域

    Dropboxが構築したMagic Pocketの中身:エクサバイトのストレージシステムの仕組み | POSTD
  • [ 技術講座 ] Domain-Driven Designのエッセンス 第1回|オブジェクトの広場

    DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』(以降DDD)は、「

  • Go Hasegawa and Associates

    3-3 Ichigayatamachi, Shinjuku-ku, Tokyo, 162-0843, Japan

    Go Hasegawa and Associates
  • 異種統合型情報サービスシステムにおける自律分散アシュアランス技術の研究 | 東京工業大学附属図書館 学位論文データベース

    学位論文の著作権は、原則として著者にあります。著作権法で認められている範囲外のデータの複製、転載は著作権の侵害となります。 データの複製(ダウンロード等)は、利用者個人において調査・研究・教育を目的とする場合に限られます。 表題紙等 目次 序論 第1章 異種統合型情報サービスシステムのニーズと課題 第2章 分散技術の動向 第3章 異種統合型情報サービスシステムアーキテクチャとアシュアランス技術 第4章 鉄道乗車券システムへの適用 第5章 結論 謝辞-参考資料-研究実績 学位論文の著作権は、原則として著者にあります。著作権法で認められている範囲外のデータの複製、転載は著作権の侵害となります。 データの複製(ダウンロード等)は、利用者個人において調査・研究・教育を目的とする場合に限られます。 表題紙等 目次 序論

  • Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD

    あるシステムを、1人のユーザから1100万人以上にスケーリングするにはどのようにすれば良いのでしょうか。Amazonのウェブサービスソリューションアーキテクトである Joel Williams が AWS re: Invent 2015 Scaling Up to Your First 10 Million Users でスケーリング方法について素晴らしいプレゼンをしています。 AWS上級者のユーザには適さないプレゼンですが、AWS初心者やクラウド初心者、Amazonが次々と送り出す新機能の流れについていけていない人が始めるには素晴らしい内容だと思います。 おおよその見当は付いていると思いますが、このプレゼンはAmazonによって提供されているため、どの問題についても解決策として提案されているものは全てAmazonのサービスになります。amazonのプラットフォームの役割は、印象深く、分か

    Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD
  • ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ

    この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、PerlScalaGoもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談

    ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
  • ロードバランサのアーキテクチャいろいろ - yunazuno.log

    少し前に,Facebookのロードバランサが話題になっていた. blog.stanaka.org このエントリを読んで,各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた. ざっくり検索した限りだと,Microsoft, CloudFlareの事例が見つかったので,Facebookの例も併せてまとめてみた. アーキテクチャ部分に注目してまとめたので,マネジメント方法や実装方法,ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする. 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた?)ロードバランサのアーキテクチャは,下記の論文が詳しい. Parveen Patel et al., Ananta: cloud scale load balancing

    ロードバランサのアーキテクチャいろいろ - yunazuno.log
  • 分散システムの一貫性に関する動向について

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

    分散システムの一貫性に関する動向について
  • Carousel by Dropbox: 遅延のない動きを実現する工夫 - ワザノバ | wazanova

    Dropboxは先週iOS、Android向けに発表した写真管理アプリCarouselを発表しました。Carouselの開発にあたり、がまずチャレンジすべき目標は、デバイスのローカルに保存された写真を閲覧するギャラリーアプリにパフォーマンスが劣らないようにすること。その取り組みを同社のエンジニアブログで紹介しています。ポイントとしては、ユーザのアクションを邪魔しないこと。 1) 解決すべき問題点 クラウドに保存された写真を閲覧するCarouselにおいて、まず問題になったのは、 写真タブにおいて、ユーザのアクションをサーバと同期させる際に、HTTPSリクエストが待機した状態が起きる。例えば、写真をシェアする場合、このような画面になる。写真を削除する場合も同様。ネットワークの接続がよくなければ、後でユーザは再トライする必要がでる。 Dropboxにアップしてない写真、つまりデバイスのローカル

  • 小さなサーバーで大きなサービスをつくる | カメリオ開発者ブログ

    アーキテクトのItoです。動画を撮るのが趣味ですが、最近はこのを買って、カラーグレーディングの勉強をしています。とても良いです。 さて、今回お話するのはバックエンドにあるフロントエンドについて。 以下はほぼ実際にカメリオで運用しているバックエンド構成です。 図中のサーバーというものはいわゆるHTTPベースのサーバーアプリで、ここでは緑をNode.js, グレーをPython, C++で実装しています。小さいサーバーがたくさんあります。主にクライアント〜フロントエンドAPIだけの構成図で、記事クローラーや各種管理画面などは図にはありませんが存在します。 まずフロントエンドにELB(AWSを使用)とNginxを置き、後ろに NodeベースのフロントエンドAPIサーバーを置きます。 ここはNode.jsで作られたアプリをサービスするごく一般的な方法です。 エンドポイント(api.kamel.

    小さなサーバーで大きなサービスをつくる | カメリオ開発者ブログ
  • SaaSのためのクラウドをオープンソースで構築する。Zohoの内部アーキテクチャとは?

    Webブラウザ上で表計算やメール、カレンダーなどの機能を提供するサービスといえば、グーグルGoogle Appsや、数カ月前に発表されたマイクロソフトのOffice Web Appsなどがよく知られています。 Zohoも、そうしたクラウドベースのWebアプリケーションを提供する企業として知られています。同社の特徴は、Google Appsのような表計算、メール、カレンダー、プレゼンテーション管理、タスク管理といったオフィス系アプリケーションに加え、セールスフォース・ドットコムのようなCRM/SFA(顧客管理、営業支援)アプリケーション、さらにプロジェクト管理、人事管理、請求管理、Wikiといった業務アプリケーションまで、幅広いアプリケーションを提供している点にあります。すべてに無料版が提供されており、自由に試すことが可能です。

    SaaSのためのクラウドをオープンソースで構築する。Zohoの内部アーキテクチャとは?
  • 1