Redisアプリケーションパターン | おそらくはそれさえも平凡な日々
この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい
マイクロサービス時代に捧ぐ、Railsでの中規模APIサーバ開発のための技術構成 - Qiita
初めまして、qsona (tw) と申します。Ruby on Rails Advent Calendar 2016 6日目の記事になります。 Rails歴は10ヶ月で、もちろんAdvent Calendarへの参戦も初です。 全体的に生意気な内容と思いますが、 じゃんじゃんマサカリ投げてください お手柔らかにお願いします。 はじめに 環境 JSONを返すAPIで、データベースはRDBを想定してます。 あんまり関係ないですが一応、Rails5 (api mode) + MySQLを想定しています。 マイクロサービスとしてのバックエンドに使う技術スタックの必要な要件 マイクロサービスの良いところは、サービスごとに合った別々の技術が使えるということです。 とはいえ、一般的な組織であれば、学習コストの面などから、ファーストチョイスとなる言語があり、普通の要件に対してはその言語を使う、ということにな
アメブロ2016 ~ React/ReduxでつくるIsomorphic web app ~ | CyberAgent Developers Blog | サイバーエージェント デベロッパーズブログ
みなさんこんにちは、サイバーエージェントでフロントエンドを中心に開発しています原(@herablog)です。 アメブロでは、2016年9月にフロントエンドをJavaベースのアプリから、node.js・Reactベースのアプリへとシステムの移行をおこないました。本記事では、その移行へといたる経緯やゴール、システム設計、その結果についてお伝えします。 リリース直後に気づいているツワモノな方もいらっしゃいました。 アメブロのSP版がReactのSSRでフルリニューアルしたのを観測した — hr (@hrloca) 2016年9月1日 システム移行へといたる経緯 2004年から始まり、日本国内で最大規模のブログサービスとなったアメブロは、システムの肥大化や多数の関係者が存在したことによるモジュール・導線の急増などの理由により、ページ表示スピードが遅くなり、ページビュー数にも明らかに影響を与えるよう
複雑なJavaScriptアプリケーションを考えながら作る話
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アプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
Amazon.comがモノリシックな構造からSOAへ移行したときに気がついた間違い。同社CTOが語る
ニューヨークで開催されたイベント「AWS Summit 2016 New York」。基調講演で同社CTOのWerner Vogels氏は、Amazon.comのシステムがモノリシックな構造からSOAへ、そしてマイクロサービスへ移行する際に得た教訓について手短に紹介しています。 機能ドリブンでサービスを分解するべきだった Werner Vogels氏。 10年前の話をしよう、Amazon.comは巨大なモノリシックな構造から転換してきた。私たちのお客様もおそらく、似たような経験をこれからするはずだ。 Amazon.comは、モノリシックな構造からSOAに転換すると決めた、それはいわゆるSOAが登場するよりも前の時期だ。 さまざまなコンポーネントをサービス化し、APIでつなげるようにした。これは非常にうまくいったが、しかし私たちは間違いにも気づき始めていた。 それは、データドリブンにサービス
Cloud First Architecture設計ガイドが発売（8/25）されます #cfadg - arclamp
本を書きました。2016/8/25に発売されます。ハッシュタグは #cfadg (Cloud First Architecture Design Guide)でお願いします。 Cloud First Architecture 設計ガイド 作者: 鈴木雄介出版社/メーカー: 日経BP社発売日: 2016/08/25メディア: 単行本この商品を含むブログを見る 「Cloud First Architecture設計ガイド」ですから、クラウドファーストなアーキテクチャをどうやって設計するのか？という本です。とはいえ、（僕らしく）回りくどい道のりでクラウドファーストについて解説しています。 クラウドファーストは「クラウド技術群を前提にシステムを構築する」ということですが、これを体現したのがマイクロサービスアーキテクチャでしょう。しかし、マイクロサービスアーキテクチャは技術論ではありません。 マイク
メールの配信状況を可視化、追跡する - トレタ開発者ブログ
週1でスープカレー食ってる佐野です。仕事ではトレタのインフラをあれこれしています。今回はメール配信の異変にいち早く気づき、カスタマーサポートのレスポンスを向上する取り組みについてです。 スマートフォンの普及、メッセンジャーの台頭などによって個人間でのメールでのやりとりは減っているかもしれませんが、通知の仕組みとしてまだまだメールは現役です。弊社ではお店への予約確定の通知、お店への予約一覧のPDF送信、お客様への来店日のリマインド...などにメールを活用しています。メールを使っていると、たまにお客様から弊社カスタマーサポートに「メールが届かない」「突然届かなくなった」という問い合わせをいただくことがあります。担当者は原因(トレタの障害？メール配信システムの障害？お客様のメールアドレス間違い？...etc)を即座に調べて回答する必要があります。今日はその仕組みについて。技術的には簡単な話です。
UberのPostgresqlからNoSQL on MySQLへの移行を読んでざっくりまとめた
Uber-migrated-pg-to-mysql.md Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog のまとめ Posgresqlだと pgは追記型なので少しの更新でも多くのdiskへのwriteがおきる カラムを一つ更新しただけで多くのindexの書き換えが起こる よって、replicationはWALを送るので更新が多いとWALが大量に送られる repcliationでは物理的なdiskの変更を送る DC間でレプリするときつい bugがあってreplica間でMVCCの不整合が起きる masterとreplica同じdisk上のデータ構成を共有するのでupgradeがつらい cache readはsyscallとosのpage cache経由なので重い 1コネクション1プロセス
Why Uber Engineering Switched from Postgres to MySQL
We’ve represented the old version in red and the new row version in green. Under the hood, Postgres uses another field holding the row version to determine which tuple is most recent. This added field lets the database determine which row tuple to serve to a transaction that may not be allowed to see the latest row version. With Postgres, the primary index and secondary indexes all point directly
Web サイトっぽい SPA に必要なブラウザナビゲーションのエミュレートなど
Web サイトっぽい SPA に立ち向かう 大分前の話ですが、Node学園 20時限目 今回もdots!!!!! - connpass で Client Side of なんちゃらfresh.tv としてお話した内容のうち、Web サイトっぽい SPA に関してだけこだわりを再抽出して書き留めます。 本件は、ページ全体のスクロールや頻繁なナビゲーションを伴わず、1画面におさまるレスポンシブな Web アプリを作っている場合はあんまり関係がありません。画面内の局所的な状態更新は、コンポーネントの責務分割やら何やらの設計なので実は別の話です。 総じて、Web サイトっぽいくせに大人の事情で Web ブラウザのネイティブなナビゲーションを積極的に破壊しにいくときの心構えです。 URL が変わっても最低限レンダリングできるまで画面更新を遅延させる 画面遷移に必要なのは、 URL が更新されても次の
npm Blog Archive: package tarball read outage today
The npm blog has been discontinued. Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog. Earlier today, July 6, 2016, the npm registry experienced a read outage for 0.5% of all package tarballs for all network regions. Not all packages and versions were affected, but the ones that were affected were completely unavailable during the outage for any region of our
memcachedにおけるキャッシュシステムの Thundering Herd 問題への対策案 - blog.nomadscafe.jp
キャッシュシステムの Thundering Herd 問題とは、 通常、キャッシュに格納されるデータは、それぞれ単一の生存時間をもっています。問題は、頻繁にアクセスされるキャッシュデータがエクスパイアした際に発生します。データがエクスパイヤした瞬間から、並行に走る複数のアプリケーションロジックがミスヒットを検知し、いずれかのプロセスがキャッシュデータを格納するまでの間、同一のリクエストが多数、バックエンドに飛んでしまうのです。 という問題。クエリが重かったりするとそれだけでシステムに致命的な負荷を与えてしまい、キャッシュがあるにも関わらずキャッシュが切れたタイミング全体が停止することも考えられます。memcachedでこの問題に対応するため、次のような手段を考えてみました。 まず、保存時に通常のキャッシュと、それよりも指定した秒数Expiresが短いキャッシュを2つmemcachedに対し
Webサービスにおける
キャッシュ戦略
YAPC::Asia Hachioji 2016 mid in Shinagawa 2016-07-03 Yusuke Wada a.k.a. yusukebe
Serverless Architectures
Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. By using these ideas, and related ones like single-page applications, such architectures remove much of the need for a traditional always-on server component. Serverl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
System of Record と System of Engagement
Serverless Architecture
マイクロにしすぎた結果がこれだよ！
トランザクションの設計と進化
Redux Middleware Wars (Japanese)
GitBook – Knowledge management for technical teams
