Blog Archives

Ubuntu14.04でNFSv4を動かしてみる

ゴール nfs-server nfs-client というホスト名の Ubuntu 14.04 のサーバを2台用意し、nfs-server サーバに Network File System バージョン 4(以下 NFSv4) を構築、nfs-client サーバからマウントしてみる。 NFSv4 サーバを構築 まずは nfs-server に NFSv4 サーバを構築します。 必要なパッケージのインストール NFS サーバに必要な nfs-kernel-server パッケージをインストールします。 nfs-kernel-server は NFSv3 にも対応しているようですが、今回は NFSv4 として利用します。 共有ディレクトリを作成 次に共有ディレクトリを作成します。 今回は /tmp/no_root_squash /tmp/root_squash /etc を共有します。 ディレクトリが存在しない

Tagged with: , ,
Posted in linux, middleware

HTTP ベンチマークツール wrk についてメモ

モダンな HTTP ベンチマークツール wkr の簡単な使い方についてメモ。 wrk の特徴は以下。 C で書かれている マルチコア CPU を 活かした高負荷をかけられる スレッドと epoll/kqueue のイベントドリブンを活用して負荷をスケールさせる(NOTICE ファイルを読むと Redis Event Library(ae event loop) を拝借しているようです) Lua スクリプトで HTTP クライアントの処理や実行結果のレポートをカスタマイズできる Installing wrk in CentOS 6 まずはビルドに必要なパッケージをインストールします。 openssl-devel をインストールしていないと、make 時に以下のようなエラーが発生します。 次にソースコードから wrk をビルドします。 Usage 上の例では

Tagged with: , , ,
Posted in middleware

Redisのレイテンシを計測

やりたいこと Redis に TCP でコマンドを投げた時 DNS Lookup -> Initial Connection -> Request Sent -> Waiting(TTFB) -> Content Download というような流れで処理される。 この一連の流れで Redis の内部処理にかかった Waiting(TTFB) を除く通信の時間を計測する方法をメモ。 通信のレイテンシ Redis には疎通確認向けのコマンド PING がある。 クライアントがこのコマンドを実行すると、サーバーは PONG を返すだけ。 このコマンドに対してサーバー(Redis)の処理は極めて軽微なため、PING を実行してから PONG がかえってくるまでの時間をレイテンシとみなして計測するのが次のコマンド。 上の例で言えば 103 回 PING

Tagged with: ,
Posted in middleware

S3にBasic認証付きリクエストをすると400:Bad Requestになる

nginx で S3 にリバースプロキシしたサイトで、特定の URL 配下にしらーっとBasic認証を追加したら、S3 のリソースの取得が”400 : Bad Request” でことごとく失敗していた。 現象を再現させる まずはこの動きを確認してみる S3を用意 バケットを作成し、オブジェクトを public-read の ACL つきて PUT する。 public read が付いているので、anonymous user も GET できる。 Basic 認証付きでリクエスト 次に Basic 認証付きでリクエストしてみる みごとに 400 Bad Request エラーが発生した。 nginx での解決

Tagged with: , , ,
Posted in aws, middleware

Varnishのレスポンスヘッダーにサーバ情報を含める

Load Balancer – Varnish(複数台) – Origin Server(複数台) というような構成の時に リクエストを処理した Varnish サーバ Varnish にコンテンツを返したオリジンサーバ と言った情報をデバッグ目的で Varnish のレスポンスヘッダーに含める方法をメモ。 ヘッダーに含められる情報 Varnish Server Varnish サーバに関しては、以下の情報が取得可能 server.ip Varnish サーバの IP アドレス server.port/std.port(server.ip) Varnish サーバのポート番号 server.hostname Varnish サーバのホストネーム server.identity プロセス起動時に -i オプションで指定するID。デフォルトはホストネーム 最後の identify は CentOS

Tagged with:
Posted in middleware

[AWS]マルチAZなElastiCache Redisの永続性についてメモ

Redis のデータを永続化させるには RDB : point in time スナップショット AOF : write ahead logging(WAL) の2種類の方法がある。 AWS ElastiCache Redis で Multi-AZ かつ自動フェイルオーバーなレプリケーショングループを組んでいる Redis での動きをメモ。 このようなレプリケーショングループの作り方は次のURLを参照 http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/AutoFailover.html Redis の RDB と AOF について RDB について RDB は point-in-time にダンプしたファイル。 通常の Redis であれば SAVE

Tagged with: ,
Posted in aws, middleware

Varnish4でエラーページをカスタマイズする

vcl_backend_error と vcl_synth の2種類のエラー Varnish3 でエラーページをカスタマイズにはサブルーチン vcl_error 内でゴニョゴニョやればよかった。 Varnish4 では バックエンドサーバで発生したエラーはサブルーチン vcl_backend_error で処理 VCL 内で synth キーワード(3.* 時代の error)を使って生成された synthetic object はサブルーチン vcl_synth で処理 するように変わった。 例えば、オリジンサーバで 500 番台系のシステムエラーが発生した場合のメッセージは、昔ながらの vcl_synth を修正しても何も変わらず、 vcl_backend_error でカスタマイズしなければいけない。 違いのわかる設定例 この2種類のエラーの違いを実際に確認してみる。 利用する default.vcl は次のもの。 オリジンサーバは localhost:8080 に設定。このサーバは落としておいて、backend

Tagged with: , , , ,
Posted in middleware
Archives
  • RT @__apf__: How to write a research paper: a guide for software engineers & practitioners. docs.google.com/presentation/d… /cc @inwyrd 7 months ago
  • RT @HayatoChiba: 昔、自然と対話しながら数学に打ち込んだら何かを悟れるのではと思いたち、専門書1つだけ持ってパワースポットで名高い奈良の山奥に1週間籠ったことがある。しかし泊まった民宿にドカベンが全巻揃っていたため、水島新司と対話しただけで1週間過ぎた。 それ… 7 months ago
  • RT @googlecloud: Ever wonder what underwater fiber optic internet cables look like? Look no further than this deep dive w/ @NatAndLo: https… 7 months ago
  • @ijin UTC+01:00 な時間帯で生活しています、、、 1 year ago
  • RT @mattcutts: Google's world-class Site Reliability Engineering team wrote a new book: amazon.com/Site-Reliabili… It's about managing produc… 1 year ago