はてなブログでSREをやっているid:cohalzです。 2019年12月頃からid:utgwkkやid:onkとともに、はてなブログにおけるキャッシュ周りの改善を行いました。その結果、次のような成果が得られました。 ブログ記事のキャッシュヒット率が、1日平均で8％から58％に向上 アプリケーションサーバの台数を、以前の半数以下に削減 DBに届くリクエスト数が、以前の3分の2まで減少 レスポンスタイムの平均が、以前の8割まで減少 この記事では、実際にどういった改善を行ったのか、その際に気をつけたことや大変だったことを紹介します。 はてなブログがVarnishを導入した経緯と課題 開発合宿をきっかけに問題が明らかになる 進め方をまず考える ホストのメモリをできるだけたくさん利用する メモリを積んだホストでなぜかレイテンシが悪化 キャッシュが分散しないようVaryヘッダを使う デバイス情報を適
YAPC::Asia Hachioji 2016 mid in Shinagawa 2016-07-03 Yusuke Wada a.k.a. yusukebe
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
米オラクルは、オープンソースのデータベースとして普及しているMySQLをクラスタ化して利用するためのソフトウェア「MySQL Cluster 7.2」の正式版を公開しました。 GPLに準拠したオープンソース版と同時に、管理ツールを同梱し、24時間365日のサポートも行う商用版の「MySQL Cluster Carrier Grade Edition」も同時に公開しています。 ジョインが70倍高速に MySQL Cluster 7.2の最大のポイントは、ジョインが高速になったことです。これまでクラスタでのジョインは、ジョインするテーブルのデータがクラスタ内のノード間をいちいち飛び交っていたため、複雑なジョインになるほど遅いものになっていました。 MySQL Cluster 7.2で採用されたAdaptive Query Localization（あるいはPush Down Joins）と呼ば
なんでもありのWebアプリケーション高速化バトル、#isucon に会社の同僚 @Songmu @sugyan と3人で、fujiwara組として参戦してきました。結果、幸いにも優勝を勝ち取ることが出来ました。 こんなに楽しいイベントを企画、運営していただいた Livedoor の皆様、本当にありがとうございます！！ さて、ざっとチューニングした経過などを記録しておきます。 [追記] もっと詳しいレポートを @Songmu が上げているのでそちらもご覧ください おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました [さらに追記] #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店 自分でももう少し詳しく振り返りエントリ書きました。 まず説明を聞いて、環境を作るところから。IPアドレスでは作業がしにくいし事故も起こりそうなので、host
クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基本は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ
Kyoto CabinetおよびKyoto Tycoonに新たに導入された「StashDB」を使うとmemcachedよりも空間効率を向上させられるという話。 StashDBとは 前回の記事で説明したように、Kyoto CabinetではローカルMapReduceのキャッシュとしてTinyHashMapというクラスを実装して省メモリ化を図っている。丁寧にシリアライズしてデータを詰めていくとかなりメモリを節約できるものなのだ。 同じ構造をDBMのインターフェイスにしたのがStashDBである。ProtoHashDB, ProtoTreeDB, CacheDB, GrassDB, HashDB, TreeDB, DirDB, ForestDBに続く第9番目のDBMということになる。もちろん、マルチスレッドセーフにして、レコード単位の粒度でロックを施して一貫性を確保し、VisitorやCurso
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
本連載「オープンソースソフトウェアでクリエイターを支援するmoonlinx」の第1回「ウェブメディア「moonlinx」を支えるオープンソースソフトウェア」ではmoonlinxの概要およびシステム構成を、第2回の「openSUSEの管理ツール「YaST」で作業を効率化：moonlinxを支えるOSS」では使用OSであるopenSUSEについて簡単に説明しました。 今回は、moonlinxで取り扱うメディアファイル（画像、音楽、動画）の保管方法について説明したいと思います。 分散ファイルシステム「MogileFS」 moonlinxでは、各種メディアファイルの保管に、オープンソースの分散ファイルシステム「MogileFS」を利用しています。 分散ファイルシステムを用いることにより、ファイルシステムを構成するノード群の一部がダウンしても、データを失うことなくシステムとして機能し続け、かつ自動レ
2010/09/07 KVS（キー・バリュー・ストア）に分類されるオープンソースのRedisの新バージョン、「Redis 2.0.0」が2010年9月5日にリリースされた。Redisはmemcachedと同様にキーと値のペアをメモリ上に保持するKVSの一種だが、3つの際立った特徴がある。1つはハッシュ以外のデータ構造もサポートしていることで、リスト型、集合型、順序付き集合型などのデータ構造が扱え、サーバ側でコレクションに対するpush/pop、コレクション同士のunion/intersection、数値のincr、decrなどの操作がアトミックに行える。バージョン2.0では複数の操作を1つにまとめてアトミックに操作するコマンドも増えている。 もう1つのRedisの特徴は、マスター・スレーブによるレプリケーション設定ができ、リード側のスケールアウトが容易にできること。 そして3つ目の特徴は、
handlersocket plugin や mycached を使えば memcached は不要か、それとも使うべきケースがあるか。考察せよ [10点] kazuho (Kazuho Oku) http://twitter.com/kazuho/status/21477219149 考えて答えてみる。 HandlerSocketやmycachedを利用し、MySQLへの接続数が数万単位で行えるようになったり、より多くのクエリ数が発行できるようになっても、memcachedは不要ではないし、使うべきケースもあります。 memcachedは単なるKVSではなく、ExpiresとLRUがついたキャッシュサーバです。キャッシュオブジェクトには期限を付ける事ができ、期限が過ぎたキャッシュは無効にされ、またアクセスがされていない不要になったオブジェクトは削除され、空いたスペースは新しいキャッシュオ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1.4系で新しく追加された主な機能しては バイナリプロトコルの導入 マルチスレッドの標準化 統計の強化 などが上げられます。この1.4系の機能の詳細については前坂徹氏の連載「memcached 1.4の到来」が参考となります。ここではバージョン1.2.5と最新の1.4.5の起動オプションを比較しながら、新しく追加された機能や実際の運用で用いられる起動オプションについて説明します。 1.2系と1.4系の起動オプションの違い まず、memcachedの起動オプションの一覧（ヘルプ）を確認しましょう。memcachedのヘルプを出力するには、「-h」オプションを使います。 $ memcached -h memcached 1.x.x -p <num> TCP port number to listen on (default: 11211) -U <num> UDP port number t
libevent-1.3b, libmemcached-1.4.4 で固まる? 2010-08-13 (Fri) 0:56 Uncategorized mixiの件について、nealさんから情報を貰ったので数時間調査してみた。というのも、うちの製品でもlibevent(evhttp)をリクエスト処理に使っているので、これにバグが有ると非常に困る。 Nealさんのつぶやき ひとまず、libevent-1.3b, libmemcached-1.4.4をビルドする。memcachedは、-cで同時接続数を制限できる。で、この同時接続数というのは、実はファイルディスクリプタの数を制限する事で達成されている。memcached.cの以下の部分。 /* * If needed, increase rlimits to allow as many connections * as needed. */
8月10日の17時20分頃から12日未明までの長時間にわたり、サービスが利用不能もしくは利用しにくい状況になっていた「mixi」。数度の断続的な復旧ののちに、本日12日午前1時50分頃には復旧が完了し、現時点で全面的に復旧しているようです。 その障害の経緯について株式会社ミクシィの広報からプレスリリース「『mixi』のアクセス障害のお詫び及び復旧に関するお知らせ」として発表されました。 原因はアクセスの急増ではなかった プレスリリースの中で、今回の障害の原因は以下のように説明されています。 『mixi』のデータベースへの負荷軽減のために導入しているデータキャッシュシステムが複数同時に異常終了したことに伴い、データベースへの負荷が急増したため『mixi』を閲覧しづらい状態となりました。 高負荷かつ特殊な状態でのみデータキャッシュシステムの異常終了が発生していたため、根本的な原因の究明に時間が
Neal Sato @nealsato 二日とも複数台のmemcachedが連続して落ちました。コアは吐かずにストンと落ちるので、原因追及に時間がかかりましたが、memcachedへの接続数が異常に多いと落ちる事は再現できました。 #mixi 2010-08-12 02:33:00 Neal Sato @nealsato memcachedが大量の接続を受けると突然停止をするので、memcachedへの接続数を減らし安定運用中。外部からの過剰アクセスではなく、サーバ追加→クライアント数増加→停止。 2010-08-12 08:45:50 Masahiro Nagano / 長野雅広 @kazeburo ファイルディスクリプタが不足してmemcachedが落ちたとして、そのときには、3万強の接続となってるはず。3万強の接続となるにはアプリケーションサーバ側のmax clientが平均60とし
クラウドのように大規模なシステムでは、ソフトウェアの開発と同等以上に、大規模運用の巧拙が、システム全体の成功を大きく左右します。 6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」で、FacebookのTechnical Operations teamを担当するTom Cook氏が「A Day in the Life of Facebook Operations」（Facebook運用のある1日）と題したセッションで、Facebookがふだんどのような運用を行っているか、紹介しています。 世界でトップクラスの大規模サイトが、普段どのようなツールを用い、どのような方法で運用しているのか、セッションの内容を紹介しましょう。 6年で4億アクティブユーザー、3カ所のデータセンター Tom Cook氏。Facebo
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
「日本でゼロからクラウドを生み出すムーブメントを作り出したい」（実行委員長 門林雄基氏）---“クラウドを支える技術”の開発力を競う「クラウドコンピューティングコンペティション」が2009年6月11日、Interop 2009の会場で開催された（写真1）。企業や大学・大学院の研究者、そして高校生を含む若手エンジニアが、新しいアイディアと技術力で作り上げたクラウドコンピューティングの基盤ソフトウエアを披露した。 クラウドコンピューティングコンペティションは、奈良先端科学技術大学院大学の門林雄基准教授らの呼びかけで実現したイベント。若手のエンジニアがP2P（ピア・ツー・ピア）技術や分散データ処理技術といったクラウドコンピューティングの基盤技術を開発し、その成果を競う。検証環境として、情報通信研究機構（NICT）が運用するクラスタ環境「StarBED」のコンピュータを最大1000台まで使用可能で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
