この記事は、第2回ウェブシステムアーキテクチャ研究会の予稿です。 ウェブシステムをモニタリングするために、高可用性、高書き込みスケーラビリティ、メトリックの長期保存が可能な時系列データベースが求められている。 これらを実現するために、性能特性の異なる汎用Key-Value Store(以下KVS)を組み合わせ、透過的に問い合わせ可能な、ヘテロジニアス時系列データベースであるDiamondを開発した。 この記事では、Diamondを分散システムの観点で捉え、アーキテクチャ、データ構造、実装を紹介し、考察によりFuture Workを議論する。 1. はじめに 2. アーキテクチャ アーキテクチャ概要 動作フロー データ構造 KVSの機能要件 3. 実装 実装概要 KVS間のデータ移動 データ位置の解決 費用特性 4. 考察と今後の課題 Diamondの欠点 将来機能 5. まとめ スライド
AWS CLIを使ってマルチAZなElastiCache Redisのリードレプリカを作成する(お手軽版)
2014/10/24 の機能追加により、Redis はマルチAZ構成でノードを配置し、自動フェイルオーバーに対応した。 Multi-AZ Support / Auto Failover for Amazon ElastiCache for Redis http://aws.amazon.com/blogs/aws/elasticache-redis-multi-az/ 自分が知るかぎり、この機能が追加される前は異なる AZ に自前でクラスター配置しないとマルチAZにならなかったけど、機能追加後はマネージメントコンソールからボタンポチでマルチAZできるようになった。 このマネージメントコンソールの機能追加はコマンドライン aws cli (というかAPI)にも反映されているので、高可用性な Redis クラスターをサクッと構築してみる。 自前でゴリゴリやる手順は過去に書いた。 AWS CLI
github.com 掲題の通り、軽量動作する分散ジョブスケジューラを作ってみました。 名前は Koyomi としました。 Perl で書きました。CPAN にもアップしています。*1 Motivation 出発点となった課題感としては、だいたい cron の冗長化法について調べてみた #cron - weblog of key_amb という記事に書いた通りです: バッチサーバの冗長化は割と見過ごされやすい やろうとするとちょっと面倒 上の記事では cron を冗長化するやり方をいくつか紹介したのですが、NFS は SPOF になりやすいし、keepalived を使ったやり方もなんだかトリッキーで少し複雑な気がしないでもないです。 そこで、もっとシンプルに高可用性を達成するやり方はないかなと考えて、実装してみました。 動作原理 仕掛けは割と単純で、スケジュールのデータストアをスケジュー
AWS Weekly Roundup – AWS AppSync, AWS CodePipeline, Events and More – August 21, 2023 In a few days, I will board a plane towards the south. My tour around Latin America starts. But I won’t be alone in this adventure, you can find some other News Blog authors, like Jeff or Seb, speaking at AWS Community Days and local events in Peru, Argentina, Chile, and Uruguay. If you see […] New – Amazon EC2 H
4. 自己紹介 • 本間 知教(ほんま とものり) • 株式会社gumi • System Operation Engineer • 国内アプリのサーバ運用全般 • アプリのイベントとかは作ってないです • 好きなAWSサービス：Amazon S3 14年1月13日月曜日 @CkReal 4 6. Redis運用に最低限必要な知識 • キーバリューストア • データ取得は全てインメモリ • メモリ以上のデータ格納時の挙動は、 maxmemory-policyで制御(default:volatile-lru) • 2種類のデータ永続手段 • Append-only file(追記型ファイル) • RDBスナップショット • 複数データベースが使える 14年1月13日月曜日 6
はじめに データアクセスの高速化、セッションの保持などに非常に重要なポジションを占めているMemcached 特徴をあげると、速い安い美味いで、AWS上のサービス化などされており、非常に扱いやすいプロダクトなのですが、Memcachedそのものが単一障害点とならないように冗長化を測った時に深刻な問題が発生する可能性があることをご存知でしょうか。 システムに心あたりがある方は今すぐ代替手段を検討しなければなりません。 どうしてもMemcachedを使いたいという方はこちらへ それでもMemcachedを使いたいあなたへ 前提条件 そもそも冗長化をしなければ問題ないという運用はその時点で怖いのでNG cache機構という性質上、データが飛ぶのは問題ない(”正”となるデータを他から読み出すだけ)が、誤ったデータが読み出されるのをNGとする Memcachedを利用した時に利用ノードを決定するのは
http://code.flickr.net/2013/03/26/using-redis-as-a-secondary-index-for-mysql/ Flickrがエンジニアブログで、Redisを利用したDBクエリ最適化の事例を紹介しています。 1) 背景 Yahoo.comのサイトの右側に、直近でアクティブなFlickrコンタクトの写真が10枚掲載 [例] されます。 Yahoo.comのトップページのサイトパフォーマンスを担保するため、このAPIはかなり厳しめのSLA (Service Leve Agreement) が課せられてます。直近に写真をアップロードしたアクティブなユーザのリスト作成の際、コンタクト数が多いユーザが存在すると、SLAを守るパフォーマンスがだせないため、クエリとMySQLのインデックスを改善する必要がでてきた。 2) 最初の試み 直近のコンタクトデータを非
Amazon ElastiCache – Now With a Dash of Redis | Amazon Web Services
AWS News Blog Amazon ElastiCache – Now With a Dash of Redis We launched Amazon ElastiCache about two years ago, and have steadily added features ever since. In the last two years we have added auto discovery, additional cache node types, and reserved cache nodes. We’ve reduced prices several times and we have added support for additional AWS Regions and VPC. Today we are taking a big leap forward
Pinterest has been riding an exponential growth curve, doubling every month and half. They’ve gone from 0 to 10s of billions of page views a month in two years, from 2 founders and one engineer to over 40 engineers, from one little MySQL server to 180 Web Engines, 240 API Engines, 88 MySQL DBs (cc2.8xlarge) + 1 slave each, 110 Redis Instances, and 200 Memcache Instances. Stunning growth. So what’s
A very fast Redis client for the JVM. Description of each module: redisgen/ Scrapes the redis.io/commands page and produce various typed clients and servers, very extensible util/ Some common encoding and data structures client/ Leverages the protocol module for encoding and decoding. Supports both synchronous and asynchronous pipelined requests from the RedisClient. Supports 2.6 commands. protoco
Dear Redis users, in the final part of 2012 I repeated many time that the focus, for 2013, is all about Redis Cluster and Redis Sentinel. This is exactly what I'm going to do from the point of view of the big picture, however there are many smaller features that make a big difference from the point of view of the Redis user day to day operations. Such features can't be ignored as well. They are le
Premise: a small rant about software reliability. === I'm very serious about software reliability, and this is not just a good thing. It is good in a sense, as I tend to work to ensure that the software I release is solid. At the same time I think I take this issue a bit too personally: I get upset if I receive a crash report that I can't investigate further for some reason, or that looks like alm
It’s True: Even Modest Datasets Can Enjoy the Speediest Performance Those of us who use them know that Redis and Memcached were designed from the ground-up to achieve the highest throughput and the lowest latency for applications, and they are in fact the fastest data store systems available today. They serve data from RAM, and execute all the simple operations (such as SET and GET) with O(1) com
A coworker and I were designing a solution to a rather interesting problem yesterday and we realized we needed a more in-depth understanding of the memory usage of the various datatypes in Redis to squeeze as much storage out of Redis as possible. Among other things we also wanted to verify some of statements in the Redis documentation, e.g. are hashes really preferable to creating pseudo-hashes b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
