Latest post from blog.tnmt.info

Wordpress to Octopress

2011/11/20 22:11

BlogをWordpressからOctopressに変更しました。…

Read More

Fedora 16へのアップグレード (preupgrade-cli)

2011/11/10 1:29

もはや、preupgrade-cli成功したよ報告にしかなってないですが。…

Read More

  • Shared News 2011/6/3 10:50

    memcached を使ったアプリケーションの設計について

    クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基本は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシュに保存してしまうと問題はさらに大きくなります。対応策としてexpires時間を短くしていることが散見されますが、本末転倒な気がします。 現代的なハードウェア、最新のMySQLを利用し、適切なスキーマ設計・SQLであればMySQLは数百qps〜数千qpsのパフォーマンスを発揮します。もしこの数値でも足りないということであれば”“ピンポイント”“でmemcachedを導入することをお勧めします。よくあるORMのmemcached連携機能は使ってはいけません。 2) 消えては困るキャッシュを置かない memcachedは揮発性のKVSで、再起動するとすべてのデータが失われるから消えては困るキャッシュを置いては行けない。というのはよく言われていることかもしれませんが、実は本質ではありません。memcachedの単体再起動はあまりすることではありませんし。 アプリケーションを効率よく運用していくために、スケールアウト(台数追加)、スケールアップ(性能の高いサーバに入れ替え)、スケールイン(台数削減)、スケールダウンなどサーバの入れ替えはいつでも行えるようにしてして置くことが必要です。memcachedのキャッシュの分散はクライアントのアルゴリズムにもよりますが、サーバの追加削除によってキャッシュミスが少なからず起こりえます。 消えては困るキャッシュの代表がセッションだと思います。このようなデータは別の永続化できるデータベースに(も)格納したり、Cache::Memcached::IronPlateのキャッシュ複製機能を利用し複数のmemcachedに格納するなどの対応策が考えられます。 3) リスクヘッジのためにmemcachedサーバはスケールアウトを行う メモリの単価が下がったことで1台のサーバで16GB〜数十GBのメモリを積むことは珍しくなくなりました。memcachedも一つのインスタンスで数十GBをメモリを確保して使うことができます。しかし、スケールアップすることで1台のmemcachedサーバに障害があった場合、アクセスできなくなるキャッシュも膨大になるのでサービスへの影響が大きくなりがちです。適切なスケールアウトも行いましょう。 スケールアウトを行うことでサーバ群の障害発生可能性は上がります。Consistent-Hashingを利用したmemcachedクライアントライブラリでは、障害を検知して別のサーバへアクセスをし直すrehashの機能を持たないものがあります。その場合特定のキーだけキャッシュに保存できないので、サービスへの影響がでてくる可能性があります。そのようなキャッシュでもCache::Memcached::IronPlateのキャッシュ分散・複製機能が活用できるでしょう。メモリは余裕あるので複製しても問題はないはずです 様々なミドルウェアが出てくる中で、memcachedだけが唯一の選択肢ではなくなってきていると思います。しかし雨後のタケノコのようにでてくる多くのミドルウェアを同時に運用するのはなかなか骨の折れる作業です。冷静な技術の判断と適切なサイジングが重要なこのごろです。

  • Shared News 2011/6/2 18:59

    mixi Engineers' Blog » Jenkins はじめました + ほか3つ

    mixi Engineers' Blog » Jenkins はじめました + ほか3つこんにちは。加藤和良です。 まずあの話を書いて、それを前提にあの話を書いて、みたいなキューが筆者の中にはあったのですが、正直キューの先端につまってる話はだんだん個人的な関心および記憶がうすれてきました! 昔のはなしですからね。 というわけで、最近のまとめをさらっと書いて、新しいネタをすぐ書ける状態にリセットしたいと思います。 mixi ではバージョン管理システムとして Subversion を使っ...

  • Bookmark 2011/6/2 16:22

  • Video 2011/6/1 22:43

  • Bookmark 2011/6/1 14:00

  • Bookmark 2011/6/1 0:35

  • I went to 2011/5/27 13:29

  • Posted 2011/5/26 1:27

    2011/05/25

    一日1ステップ 三日で3ステップ 3ステップからの〜2ステップ バック!! 人生に二段飛ばしとかないんだろなー。 昔の人はいいうたを歌うな。 「会いたい、でも会えない」とか「こんなに思ってるのに…」とかより 示唆に富んだいいうたを歌うよなー。 明日も確かで真面目な一歩を。

  • Shared News 2011/5/25 11:54

    大規模サービスを支える仮想ネットワーク

    エンジニアブログをご覧の皆さんこんにちは、インフラエンジニアのすとーです。僕はインフラの中でもネットワークチームで長らく働いてきたため、今回はAmebaのネットワークまわりのお話をさせていただこうかと思います。そこで、「ネットワーク基盤の変遷の歴史」を一歩踏み込んで、その時々でポイントになった(と思っている)技術を、簡単な設定例と共に紹介していきます。前提として、弊社ではルーティングはスタティックに行っており、機器についてはCiscoとH3Cを7:3の割合ぐらいで利用しています。(ざっくり)其の一 「VRF」VRF(Virtual Routing and Forwarding)とは、ひとつのルータ内で仮想的に複数のルーター(ルーティングテーブル)を作れる機能です。(ざっくり)主な目的は、初期アメーバの余剰なネットワークリソースを、マルチレイヤスイッチの導入で解消するというものでしたが、弊社ではサービスごとにVLANを割り当てているため、アクセス層(VLAN)とディストリビューション層(VRF)を対にすることによって、管理上もわかりやすいといったメリットもありました。設定例# VRFの定義ip vrf vrf100# ルート識別子の定義rd 100:1# サーバ側のVLANinterface Vlan100# VRF vrf100のインターフェースとする ip vrf forwarding vrf100 ip address 192.168.100.1 255.255.255.0# LB側のVLANinterface Vlan110# VRF vrf100のインターフェースとする ip vrf…

  • Bookmark 2011/5/23 14:11

  • Reblog 2011/5/22 22:38

  • Reblog 2011/5/22 22:36

  • I went to 2011/5/22 18:12

  • Reblog 2011/5/22 3:02

  • Reblog 2011/5/22 3:00

  • Reblog 2011/5/21 23:37

  • I went to 2011/5/20 13:22

  • I went to 2011/5/19 19:44

Page: 1... 13 14 15 16 17 18 20 21 22 ...79