Redis(2.8系)の基本オペレーションとかSentinelの挙動とかの色々メモ - 元RX-7乗りの適当な日々
最近必要に迫られて、ようやくRedisをインストールして触ってみました。(Redis童貞からの脱却) 色々と、基本部分ではあるけど、せっかく実際に触りながら勉強したので、このエントリにメモしておこうと思います。 尚、使ってみたRedisのバージョンは、stableの最新版である2.8.7です。(OSは、LinuxのCentOS 6.5) ちなみに、このエントリに書いていないような、Redisの基本的なアレコレについては、WEB+DB Press Vol.73のRedis特集(2.6向けではありますが)にほとんど書いてあるので読むべし。 WEB+DB PRESS Vol.73 作者: 設樂洋爾,白土慧,はまちや2,大和田純,松田明,後藤大輔,ひろせまさあき,小林篤,近藤宇智朗,まかまか般若波羅蜜,Mr. O,川添貴生,重国和宏,柳澤建太郎,奥野幹也,佐藤鉄平,後藤秀宣,mala,中島聡,堤智
UUIDをワンライナーで生成する - 元RX-7乗りの適当な日々
ちょっと調べたのでメモ。 UUID(Universally Unique IDentifier)の詳細については下記リンク先をご参照いただくとして、UUIDの生成については様々なプラットフォームでサポートされているのと、いくつかバージョンが存在します。 Universally unique identifier - Wikipedia UUID と Perl について - daily dayflower バージョン4(完全ランダム生成)を使う前提で、いくつかワンライナーで実行するやり方を残しておきます。 uuidgenコマンド(Linux) $ uuidgen f6574b6b-02f7-4255-865b-dda39dcd0979オプションなしで実行すると、上記の通りデフォルトはバージョン4で返してくれます。 (UUIDの 00000000-0000-X000-0000-00000000
Amazon EBS の性能ベンチマーク その3 (Provisioned IOPS編) - 元RX-7乗りの適当な日々
さて、またまた昨日のエントリ「Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編)」の続きです。 ここまでの経緯は以下。 Amazon EBS の性能ベンチマーク その1 (Standard編) Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編) ここまでのベンチマークでは、StandardタイプのEBSボリュームを使っていたのですが、ここからは、必要とするIOPSを設定することが可能な"Provisioned IOPS"なEBSボリューム(プロビジョンドIOPSボリューム)を使って性能を計測してみたいと思います。 # 個人で Provisioned IOPS ボリュームを使って高負荷テストとかクラウド破産まっしぐら。 ベンチマークの条件の詳細等は、上記のこれまでのエントリからご確認くださいませ。 今回ベンチマークの対象とす
Amazon EBS の性能ベンチマーク その1 (Standard編) - 元RX-7乗りの適当な日々
以前、「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた」でAmazon EC2で利用できるSSDボリュームのベンチマークを取った際に、EBSボリュームに関しても簡単に計測しているのですが、もう少し詳細に見てみようと思い、もうちょっと詳しく性能を計測してみました。(急いでいる方は最後のまとめを読むだけでOKですｗ) 実は、大昔(3〜4年くらい前)にも同じようなことを軽くやったのですが、結果がどこかにいってしまった＆今はまた結果が違うかもなので、やってみた。 ベンチマークの目的は、EBSボリュームをソフトウェアRAIDで束ねた(ストライピング)場合に、どのくらいパフォーマンスが出せるのかという観点。 というわけで、色々な観点から性能を測ってみました。使ったツールは「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた -
DNSラウンドロビンを使った時にアクセス・負荷が偏る話 - 元RX-7乗りの適当な日々
昨日に続き、アクセスが偏る系のエントリです。 なにかと議論のネタになるDNSラウンドロビンですが、今日はDNSラウンドロビンを使った時に、各IPアドレスにくるリクエスト数に偏りが出るという話。 DNSラウンドロビンで設定されているFQDNに、コマンドラインで"host"とか"nslookup"のコマンドを何度か実行すると、返ってくるIPアドレスリストの順序が入れ替わっていくことが確認できると思います。 基本的に、クライアントはそのIPアドレスリストの上(最初)からアクセスを行うため、これによって(一応)負荷分散が実現できるはずですが、特定環境のクライアントでは、ラウンドロビンとはならずに必ず特定のIPアドレスにアクセスするケースがあるのです。(既知の事実ですが。) この事は、Wikipediaの該当ページにも記載されています。 主にIPv6における宛先アドレス選択アルゴリズムとして定義され
DeNA松信さんの「MySQL環境におけるFusion-io検証結果とDeNAにおける活用価値」セッションメモ - 元RX-7乗りの適当な日々
弊社の一部のサービスでも絶賛活躍中のFusion-io社のioDrive。 Fusion-io ioDriveとFusion-io ioDrive Duoではどちらも、最小容量のモデルはSLC型、そのほかはMLC型を使っているが、Fusion ioDriveの読み込み速度は735〜770MB/s、書き込み速度は510〜750MB/sだ。Fusion ioDrive Duoに至っては、読み込み速度は1.0〜1.5GB/s、書き込み速度は一律1.5GB/sという数値をたたき出す。 ＠IT Special PR：Fusion-ioのクールな技術を使いこなせ！ 今日はデルさん主催の下記セミナーにて、このFusion-ioに関するDELL社の検証結果紹介や、DeNA松信さんによるMySQL環境でのFusion-io検証結果およびDeNAでの利用に関するお話が聞けるとのことだったので、途中からの参加で
Amazon EC2性能検証！気になるパフォーマンスをインスタンスタイプやリージョン毎に計測・比較してみた - 元RX-7乗りの適当な日々
大手クラウドサービスであるAmazon EC2では、9種類ものインスタンスタイプ(サーバの種類)から、利用したいスペックのサーバを選択できます。また、EC2のサーバは、4ヶ所ものリージョン(アメリカ東海岸、同西海岸、ヨーロッパ西部、シンガポール)から稼動させる場所を選択することができます。 ここで、気になるのが、Amazon Web Servicesの説明ページで、各インスタンスタイプの公表スペック差異として、EC2独自のCPU単位である"ECU"の数値や、IO性能のModerate(中)やHigh(高)で、どのくらいパフォーマンスが違うのかが見え辛いといった点。 また、一部の場所ではパフォーマンスが出ていない等の話が以前に出ていましたが、4ヶ所のロケーション(Region)によって、各場所でのインスタンス性能が全く同じなのか等も気になるところ。 ここを解明すべく、各種ベンチマークを実行し
Amazon EC2の仮想サーバ(インスタンス)から自身のメタ情報を取得する方法 - 元RX-7乗りの適当な日々
Amazon EC2で起動した仮想サーバ(インスタンス)では、サーバの内部から、そのサーバ自身の各種メタデータ(MetaData)を取得することが出来ます。 自前でAMIをカスタマイズする際、インスタンスの起動時に割り振られる(確定する)データ(例えば、IPアドレスとかインスタンスIDとか。)については、事前に扱いを決めることは難しいかと思います。 例えば、インスタンスIDをサーバ自身が判別できることで、サーバ起動のタイミングや、サーバ稼働中に、Amazon EBSボリュームを(自動で)自分自身に割り当てられたり等もできたりします。 また、余談ですが、Amazon EC2では、ユーザがインスタンスの起動時に任意のデータ(UserData)をインスタンスに渡すことができ、そのデータをインスタンスの中で扱うことも可能です。 この場合も、以下で紹介するやり方で、メタデータだけではなく、ユーザデー
Amazon EC2/S3を使ってみた - まとめ (Amazon Web Services関連エントリ目次) - RX-7乗りの適当な日々
Amazon EC2/S3および、その他Amazon Web Servicesについて、具体的な使い方を中心に、これまでこのブログ内で色々とエントリを書いてきたので、このエントリに目次代わりとしてまとめておきます。 今後も関連エントリを書いた際に、以下に追記していきますが、場合によっては記載されている情報が古い場合もありますので、その点はご了承ください。(できるだけ気づいた時点で修正しています。) # 尚、ここで紹介しているエントリは、全て私(id:rx7)自身が書き記したものです。 基本の流れを知る Amazon EC2/S3を使ってみた - 1.AWSへの登録〜S3を使う Amazon EC2/S3を使ってみた - 2.EC2が起こすイノベーション Amazon EC2/S3を使ってみた - 3.EC2起動後〜AMI作成 Amazon EC2/S3を使ってみた - 4.EC2で固定IP
Amazon EC2のサーバからメール送信をするまでにやるべきこと (スパムメール扱いを回避する！) - 元RX-7乗りの適当な日々
先日のデブサミ2010でも話した(デブサミ2010の資料"クラウドサービスAmazon EC2を活用した「SKIPaaS」構築事例"を公開します＋α)のですが、Amazon EC2のサーバからメールを送信すると、一部分の宛先(メールサーバ)では、迷惑メール(SPAM)扱いされ、突き返されちゃう事があります。 それをどう解決したかという話。 Twitterを見ていて、まだきちんとした情報がまとまっていない気がしたので、経験談をまとめてみます。 課題 Amazon EC2のサーバがスパムメール送信に利用されるケースが増えているようで、Amazon EC2で利用されているIPアドレスのレンジ(ネットワーク)が、スパムメールのブラックリストにまるっと載ってしまっているため、メールサーバによっては、門前払いによる受信拒否となるケースがあります。 参考： Amazon EC2を悪用したセキュリティ攻撃
自作サーバカンファレンス「はてなの自作サーバの実際」＋他セッション講演メモ - RX-7乗りの適当な日々
本日の自作サーバカンファレンス、申し込みして楽しみにしていたのですが、体調がよろしくなかったので泣く泣く不参加・・・にしようとしていたところ、なんと！Ust(USTREAM)配信されているようだったので、そっちで視聴しました。感謝！！ 1つ目のトークの"はてな"の自作サーバ事情の話、他各トークセッションのメモ書きを今後の自分のために残しておきます。 田中さん(id:stanaka)のオープニングセッション 自作サーバは安い早いうまい 必要十分な仕様 部品単位で調達・組立 独自のカスタマイズ(SSD使いたい、など) はてなでは1年くらいSSD使っている！ 安い Core2Quad + 8GB + SSD X25-M 80GB \100,000 + 5,000/month (1A) \160,000/year Amazon EC2と比べても、1年でもとが取れて、SSDも付いてくる 自作サーバの
topコマンドでマルチコアなCPUの状況を確認する - RX-7乗りの適当な日々
ということがしたくて、よく"man top"している気がするのと、意外と知られていないと思いまして。 # その前に需要がないという説もあるし、システム管理者向けかも。 top - 20:53:14 up 7:49, 2 users, load average: 0.00, 0.00, 0.00 Tasks: 150 total, 2 running, 148 sleeping, 0 stopped, 0 zombie Cpu(s): 0.8%us, 1.3%sy, 0.0%ni, 97.7%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3064832k total, 1412824k used, 1652008k free, 135808k buffers Swap: 1895416k total, 0k used, 1895416k free, 6015
Amazonの従量課金制CDNサービス「Amazon CloudFront」を使う方法 - 元RX-7乗りの適当な日々
「Amazon CloudFront」はAmazonが提供してくれるCDNサービスの1つで、コンテンツを世界各国に分散して配置させることで、ユーザからのアクセスを集中させること無く分散させることと、ユーザは最もネットワーク距離の近いサーバからコンテンツをダウンロードすることが出来るため、ユーザにとっても非常に快適でかつ効率的なアクセスの仕組みを作ることが出来ます。 Amazon CloudFrontでは、世界14ヶ所にエッジサーバがあり、それぞれの場所でコンテンツをキャッシュして配信することが可能です。 で、そんな話を昨日のエントリ「Amazonが従量課金制のCDNサービス「Amazon CloudFront」を開始・・・したので試してみた」にて、"Amazon CloudFront"の概要や実際の速度なんかを紹介したのですが、具体的な使用方法を端折ったので、今日はここに使い方を書き残して
Amazon EC2/S3を使ってみた - 8.EC2とS3のデータを同期させる(S3Syncを使う) - 元RX-7乗りの適当な日々
Amazon EC2のインスタンスは一度シャットダウンしてしまうと、そのインスタンスで保持していたディスクの内容は全て消滅してしまいます。 そこで「Amazon EC2/S3を使ってみた - 3.EC2起動後〜AMI作成」では、自分でカスタマイズ＆利用したインスタンスのイメージを、バックエンドのストレージであるAmazon S3に保存する方法を紹介しました。 しかし、これはOSのイメージをまるごとフルバックアップする方法に近いため、定期的に行うバックアップとしては非効率的な方法です。 定期的に行うべきなのは、サービスなどで日々更新されるような特定のデータやログなど、必要なデータをピンポイントでバックアップすることが効率的です。 そこで、今回は"S3Sync"を使ってみます。 http://s3sync.net/wiki この"S3Sync"は、(EC2に限らず)あるサーバからAmazon
"サーバー/インフラを支える技術"を読んだ - 元RX-7乗りの適当な日々
正確には、まだ読んでいる最中だけど、ざっと流し読みした。 これはすごい。 私のようなオープンソースプロダクトをフル活用してインフラ構築をする人間にとっては、まさに必読の書籍。 入門的な内容から一歩踏み込んだ内容まで、体系的に書かれている。しかも、はてなとDSAS(KLab)の事例を元にしたノウハウが詰まりきっている。 目次を見ていただければ分かる通り、ハードウェア〜ネットワーク〜OS〜ミドルウェア、と所謂インフラと呼ばれる領域をフルサポート。 私が、これまで長い時間をかけて、色んなサイトやブログから学んできたことが体系的にまとまりすぎている。 これからインフラの勉強を始めるエンジニアにとっては、わずか3000円弱と数時間で、私が今まで少しずつ学んできたような知識を手に入れることが出来る。 私としては、少し悔しい。 3年前にこの本と出会いたかった！ 是非、これからインフラの勉強を始める人達や
はてなとKLab(DSAS)のインフラ構築・システム運用のノウハウがとうとう本に！ - 元RX-7乗りの適当な日々
以前参加したKLabさんの勉強会(KLab勉強会#4へ行ってきました)で、KLabのid:hirose31さんがチラッと宣伝されていた本がとうとう発売になるようです！ (まだ予約受付中の段階で、発売間近といったところでしょうか。) [24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者: 安井真伸,横川和哉,ひろせまさあき,伊藤直也,田中慎司,勝見祐己出版社/メーカー: 技術評論社発売日: 2008/08/07メディア: 単行本（ソフトカバー）購入: 133人 クリック: 2,270回この商品を含むブログ (288件) を見る 執筆陣をみても、"はてな"と"KLab"(DSAS)で培われたインフラ構築やシステム運用のノウハウやTIPSがたくさん鏤められているに違いない！・・・なんですか、この
Amazon EC2の公式AMI(Fedora8)利用時の注意点(SSH接続できなくなる場合有) - 元RX-7乗りの適当な日々
いやー、がっつりハマりました。 Amazon EC2でAmazonの公式AMI(Amazon Machine Image)のFedora8を使われている方、要注意です。 インスタンスを停止する場合など、イメージファイル化してAmazon S3へ転送されるかと思いますが、公式AMIのFedora8をベースとしている場合、上手くやらないとSSH接続できなくなる現象に遭遇する可能性があります。 具体的には、以下のAMI(Fedora8)を利用している場合。 ami-f51aff9c ec2-public-images/fedora-8-i386-base-v1.06.manifest.xml ami-2b5fba42 ec2-public-images/fedora-8-i386-base-v1.07.manifest.xml 状況としては、、、 Amazonの公式AMI(Fedora8)からイ
Amazon Web Services のステータス配信サイト - 元RX-7乗りの適当な日々
今更ですが、Amazon Web Servicesのヘルスチェック結果を公開している公式なページがあったのですね。 ここをチェックすることで、Amazon EC2やS3などAWSの最新状態の把握が出来るようになっています。 AWS Service Health Dashboard http://status.aws.amazon.com/ 右端には、、、そう、問題発生時にRSSにて情報取得できるようになっているようです。 真面目にサービス運用するなら、RSSではちと遅い気もしますが。 こんな感じで過去のhistoryも見れます。 問題があったサービス/日付のアイコンにマウスオーバーすると障害情報が公開されています。 運用する際には、確実に押さえておきたい情報ですね。 まとめ Amazon EC2/S3を使ってみた - まとめ (Amazon Web Services関連エントリ目次) クラ
2.EC2が起こすイノベーション - RX-7乗りの適当な日々
さて、昨日(d:id:rx7:20080423:p1)はAWSに登録して、Amazon S3を軽く使うところまで紹介しました。 今日は、Amazon EC2を動かしてみて、最後に考察も書いてみたいと思います。 # Amazon EC2/S3については、d:id:rx7:20080423:p1 をご覧ください。 昨日も書きましたが、Amazon EC2は仮想マシンのホスティングサービスで、所謂レンタルサーバみたいなものですが、いくつかの制約事項もあります。 このEC2もHaaS(Hardware as a Service)形式での提供となるため、従量課金制となります。 以下に料金表を引用していますが、一番小規模のインスタンスで1時間あたり$0.1ながら、1vCPU(1Core)、1.7Gメモリと、なかなかお買い得です。 Instances $0.10 - Small Instance (De
KLab勉強会#4へ行ってきました - 元RX-7乗りの適当な日々
第3回に引き続き、第4回のKLab勉強会にも参加させていただきました。 今回のテーマは、システム管理に関するもので、割と普段やっていることに近い話題だったので、興味深かったです。 相変わらず、刺激をもらいまくりで楽しかったです。以下にメモをペタッと貼り付けておきます。 DSASのやりくり - MATRIXの秘密と効率的なシステム管理の関係 お馴染みKLabのひろせさん(id:hirose31)。 余談だけど、今度「サーバ24時」(仮)なる書籍が出るらしい。KLab＋はてなの方で執筆しているとか。これは期待！ さて、本題だけど、サーバをたくさん(数十台、数百台とか)管理していると、運用管理(手間がかかりまくり、管理できない、オペミス発生、とか)が面倒だけど、KLabさんではどう解決したかってテーマ。 サーバ情報の一元管理には「MATRIX」を使っている サーバの一覧、役割、状態管理とかを定義
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
