2018年12月14日に行われたJaSST Review'18（ソフトウェアレビューシンポジウム 2018）での講演「アーキテクチャのレビューについて」の資料です
アーキテクチャのレビューについて - JaSST Review '18
2018年12月14日に行われたJaSST Review'18（ソフトウェアレビューシンポジウム 2018）での講演「アーキテクチャのレビューについて」の資料です
Aurora - クラウド時代のDBアーキテクチャ - 発明のための再発明
はじめに Amazon Auroraは、AWSを触る人ならほとんどの人が利用を検討したことがあるでしょう。 Amazon社内ではOracleを止めたというtweetもありました SHUTDOWN ABORT the last Oracle database running Amazon Fulfillment! pic.twitter.com/DorqTua2Lt— John Darrow (@jdarrow) 2019年3月29日 そんなAuroraは、従来のRDBとは違いクラウド上で動くことを念頭に設計されています。 また、ログが中心的な役割を持つことから「The log is the database」と表現されることもあります。 そんなAuroraの仕組みについての論文を読んだので紹介します。 読んだ論文は以下の２つです。 Amazon Aurora: Design Conside
分かれたシステムをていねいにモノリスに集約する/Integrate decentralized systems to a monolith carefully
https://starttoday-tech.connpass.com/event/96477/ オウチーノではもともとサービスごとに異なる言語やFWを用いてシステムが分かれており、担当者もそれぞれ別々でした。そのため各サービスに精通した担当者が少なく、担当者は日々の運用で手一杯という状況下で、…
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
You Need to know SSR - Speaker Deck
ng-japan で発表した Server Side Rendering の資料です。
GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? PySpa統合思念体です。チャットで話をしたことのまとめです。何人かで雑に話をしたことのまとめで、特定の誰かの発言というわけではなく、一種の怪文書です。 さて、GraphQLが世間を賑わせ始めています。Facebookが開発し、GitHubも機能提供をし始めました。GraphQLはRESTの未来か？みたいな論調もありますが、新しいものが出てくると既存のものをサンドバックにして「まだそんな古いの使ってやがるのかよwwwww」みたいな煽りをするのはもはやウェブ界隈の風物詩になっていますが、そういう信者発言をして「ああ、あいつまた踊らされてる
続・目指すのはぶっちぎりの速さ! HTML5版 Cacoo で刷新されたデータアーキテクチャを紐解く | 株式会社ヌーラボ(Nulab inc.)
こんにちは。Cacooの平山です。現在、僕たち Cacoo チームは脱Flash・ HTML5 化に向けて最終の追い込みの真っ最中です。そんな中ではありますが、前回の「ぶっちぎり」記事では、HTML5化に向けた描画技術としてSVGを選択したことをお伝えしました。今回は、HTML5版のもうひとつの改善ポイント「データ面での刷新」を紹介したいと思います。 Cacoo のデータ形式や構造の刷新・JSONフォーマットへの移行 HTML5版では、描画にSVGを採用するという変更だけではなく、抜本的なデータ形式や構造の刷新も行いました。これには以下3点の理由があります。 Flash版ではAMFというFlashに特化したデータフォーマットを採用している 図に含まれるデータ量に応じて、パフォーマンスが低下しやすい構造である サーバー内でデータを処理しにくい 1点目はFlashから脱却するにあたり対応必須な
Complexity and Strategy | HackerNoon
Too Long; Didn't ReadI struggled with how to think about complexity through much of my career, especially during the ten years I spent leading Office development. Modeling complexity impacted how we planned major releases, our technical strategy as we moved to new platforms, how we thought about the impact of new technologies, how we competed with Google Apps, how we thought about open source and
2年半を費やしたチャットワークのScala移行、もしやり直すならどうしますか？（後編） | HRナビ by リクルート
トレタCTOの増井雄一郎さんがチャットワークのScala化プロジェクトのお話を掘り起こすインタビューの後編です（前編はこちら：チャットワークのScala移行と大規模メッセージDB再構築、本当にできたんですね！）。ChatWork CTOの山本さんは2年半を費やしたプロジェクトを振り返り、「やっぱりScala化は必要だった」と語ります。 山本 2014年4月ぐらいにScala化を決断して、社内で勉強会が立ち上がりつつ、採用をかけていった感じです。2014年7月に加藤潤一（「日本Scalaユーザーズグループ」発起人のひとり）というScalaの優秀なエンジニアが入ってくれて。そこから設計をどうしよう、と始まって。しばらくは加藤と、もう1人ぐらいで設計をしていた。それが半年ぐらいあったのかな。 2015年ぐらいから実装を始めて。1年でチームメンバーも増えて、そのときは全部まるっと移そうと計画をたて
Reduxの正しい解釈の話
2016年の課題は状態遷移の管理だったと思う。 そのアンサーとして、 Fluxのような実装におけるStore相当にアプリケーションの状態をほぼすべて管理させるReactのようなVirtual DOMを搭載したビューの実装を透過的なユーザーインターフェースとして扱うこの2つの組み合わせにより、アプリケーションの状態と描画される画面が (ほぼ) 参照透過的になる。というのがFluxとReact以降のパラダイムだと思う (理論として) 。 このパラダイムなら、エラーの発生時にアプリケーションの状態を表現するJSONをエラー収集サービスに送るようにして、簡単にバグを再現したりできるし、状態の遷移をテストしていくことで、クラッシュするようなバグのうち大半を検出できる。 Fluxの問題そこで問題が出るのが、Action(Creator) とReducer (Store#reduce())の2要素間のル
第1回 ニコ動／ニコ生 HTML5化への奮闘～ドワンゴ流動画配信サービスのつくりかた～ | gihyo.jp
不動の人気を誇る動画配信サービス「ニコニコ動画」（ニコ動）と「ニコニコ生放送」（ニコ生）において、動画プレーヤのHTML5化、そしてバックエンドシステムの刷新が図られました。このプロジェクトの背景や使われた技術、苦労したポイントなどについて、ドワンゴのエンジニアである七田弘志氏（写真1）、後藤哲志氏（写真2）、三須健太郎氏（写真3）にお話を伺いました。 フロントエンドのみならず、バックエンドシステムも刷新 ──どのようなきっかけから、HTML5化プロジェクトが始まったのでしょうか。 七田：大きな要因となったのは、主要WebブラウザでFlashのサポートを打ち切るという方針が示されたことですね。今までもスマートフォンやテレビデバイスなどではHTML5プレーヤを実現できていたのですが、PC版のページは既存機能が大きく、プレーヤの作り変えが後手に回っていた部分が大きかったんです。そ
pixiv Sketchのフロントアーキテクチャ - pixiv inside [archive]
（ピクシブ株式会社 Advent Calendar 2016 12日目の記事です） qiita.com こんにちは、エンジニアの id:geta6 です。普段は主にpixiv Sketchの開発などに携わっています。 さて、先日ISUCON6の本選が開催され、ISUketchというReactを使ったお絵かきサービスが話題になったかと思います。 この問題で採用されたアーキテクチャは『pixiv Sketch』のアーキテクチャを参考にしたものとなっています。 パフォーマンス等に関しましては本選の感想として良質な記事がいくつも執筆されていますのでそちらに譲るとして、今回はこのアーキテクチャの設計意図や利点について話します（2年前のリリース当初からずっとこの構成なので今さら感はありますが）。 どういうアーキテクチャか pixiv SketchのWeb版は、2つのサーバーから構成されています。 1つ
![pixiv Sketchのフロントアーキテクチャ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/cf2ee8d96d203c862e1f96398c70d3fb29a28d8d/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Fc238d99d27621a6e29584c8bae22f1e41cf3e575%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fg%252Fgeta6%252F20161212%252F20161212144353.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ゼロからサーバレスの先頭に追いつこう
ChatWorkとPHPと私
YAPC::Fukuoka で分散 ID 採番機 katsubushi の話をしてきた - 酒日記 はてな支店
2000万アカウントの無停止データ移行の裏側
GitHub - pmjones/adr: Action-Domain-Responder: a web-specific alternative to Model-View-Controller.
技術的負債と向き合う
system-design-primer#system-design-interview-questions-with-solutions
