May 25, 2016

ブログを移転します

大変お久しぶりです。全然更新できなくてすみません。

このたびBlogを移転することにしました。古い記事は内容を直しつつ、少しづつ移転していこうと思いますので引き続きよろしくお願いいたします。
http://profile.livedoor.com/sanonosa/

| | Comments (2) | TrackBack (0)

January 06, 2015

書評「Webエンジニアが知っておきたいインフラの基本」

ハードビーツCTOの馬場さんから「Webエンジニアが知っておきたいインフラの基本」を献本いただきました。どうもありがとうございます! 馬場さんは拙著「インフラエンジニアの教科書」で校正いただいたりと、普段大変お世話になっております。

章立ては以下の通りです。
1章 Webサービスでのインフラの役割
2章 Webサービスを支えるインフラ技術の基礎知識
3章 Webサービスのサーバ構成ベストプラクティス
4章 Webサービスを始めるときのインフラ手配の基礎知識
5章 Webサービスの運用(1) システム監視の基本
6章 Webサービスの運用(2) ステータス モニタリング
7章 Webサービスのチューニング(1) ボトルネックの見つけ方
8章 Webサービスのチューニング(2) チューニングレシピ

インフラエンジニアという点では同業なのですが、私は自社サービスでのインフラエンジニアなのに対して馬場さんはBtoBを中心としたインフラエンジニアという立場の違いを感じて個人的にとても楽しく読ませていただきました。例えば自社サービスの場合はその時々で自分たちが使いたいものを割と自由に選定して使えるのに対して、BtoBの場合はまずは顧客に説明して了承を得なければならないためまずは要件定義が必須となります。本書では要件定義のときに気にすべきことが丁寧に書かれているように思いました。

そして後半部分(5章以降)では、実経験を踏まえた、具体的なインフラ運営方法が丁寧に書かれています。監視ツールや各種コマンドの見方や使い方、チューニングやボトルネックの見つけ方などが、豊富な具体例を使って大変わかりやすく記されています。このあたりの内容は一般的には日々の業務の中でいろいろな経験をしたり先輩に教わったりしながら少しずつ身につけていくものですが、本書ではそういった内容が具体的に示されていてとても参考になると思います。

私が思うに、本書のレベル感としては、普段Linux上でApacheやMySQLなどを使ったことはあるが特に設定変更等はしたことはなく障害が起こっても何をどう直せばいいかわからないくらいの人が大変役に立ちそうです。また中級あたりの人にとっては他のインフラエンジニア(今回の場合は馬場さん)が日々どのようにインフラ運営を行っているか知ることができて参考になりそうです。インフラ運営手法って一般的にあまり体系化されてなくてある意味皆自己流なので他の人が普段どのように運営しているかは私個人的に大変興味があるところでした。

ということで、馬場さん、執筆お疲れ様でした。

| | Comments (0) | TrackBack (0)

October 30, 2014

freeコマンドの出力結果について考える

Linuxの空きメモリ状況はfreeコマンドで確認できるのは有名ですが、出力結果がどのように構成されているのか正確に知らない部分があったので、今回改めて整理してみました。

【freeの出力結果を見てみる】
freeコマンドを実行すると下記のように表示されます。単位はKB(Kilo byte)です。

$ free
             total       used       free     shared    buffers     cached
Mem:       1018596     556204     462392        144      28188     403360
-/+ buffers/cache:     124656     893940
Swap:            0          0          0


【キャッシュ使用量込みの出力結果を見てみる】
まずはこの部分を見てみます。

             total       used       free
Mem: 1018596 556204 462392

これを見ると、トータルメモリは1,018,596KByte(約1GB)、使用量は556,204KByte(約556MB)、そして空きは462,392KByte(約462MB)です。
556,204+462,392=1,018,596なので計算が合いますね。

ちなみにここでusedに含まれる使用量にはキャッシュ使用分も含まれるので実際のデータはもっと小さいです。

【キャッシュ使用量抜きの出力結果を見てみる】
それではキャッシュ使用分を抜いたときはどうなるでしょうか?

             total       used       free
-/+ buffers/cache: 124656 893940

これを見ると、使用量は124,656KByte(約125MB)、そして空きは893,940KByte(約894MB)です。124,656+893,940=1,018,596となり、トータルメモリの数字(約1GB)と合います。
どうやらOSにはキャッシュとして、556,204-124,656=431,548KByte(約43MB)のメモリが使われていたようですね。


【キャッシュ使用量の出力結果を見てみる】
最後にそのキャッシュの使われ方を見てみます。

           shared    buffers     cached
Mem: 144 28188 403360

sharedは共有メモリに割り当てられたメモリのことを指しますが、これは昔の名残なようで現在は無視して良いようです。
buffersはバッファキャッシュに割り当てられたメモリで、ブロックデバイス用のキャッシュを指します。
cachedはページキャッシュに割り当てたメモリを指します。

sharedは無視して良いようなので、28,188+403,360を足すと431,548となり、先ほど計算した数字(約43MB)と合いますね。

【最後に】
・バッファキャッシュとページキャッシュの違いが紛らわしいですが、最近のKernelではページキャッシュに多くが統合されていると聞きます。(詳細はそのうち調べてみようと思います)


・一時的にキャッシュを解放したい場合は下記の通りです。100%完全に解放されるわけではありませんが。

$ echo 3 > /proc/sys/vm/drop_caches

| | Comments (0) | TrackBack (0)

October 16, 2014

家庭用外付けストレージケースを選んだときの話

今回は家庭用外付けストレージケースを選定して悩んだときの話を記してみます。

個人利用の場合は業務利用と違って全て自腹なので、価格的にかなり妥協しないと厳しいです。価格を落とす分ある程度妥協しなければなりませんが、何を妥協するかは大きな選択です。重要なデータを保存するわけなので絶対にデータ消失が発生しないという条件と共に、家庭用途とのことで価格や本体の大きさなんかも気になるところです。


【個人要件】
絶対的な要件としては、現実的な値段の製品のうち、狭い空間にきちんと収まりつつ、絶対にデータが消失しない製品/環境であるということです。それを前提として各ベンダーの製品仕様を元に具体的に要件に落とし込んだのが下記の通りです。

・絶対条件
値段(5万円以下。できれば3万円以下)、大きさ(w150 x h300 x d250以下)、静音、搭載本数(3.5inch 4本以上搭載可能)

・迷った条件
RAID機能、NAS機能、eSATA機能、HDDの出し入れがしやすい、フロント電源

・重視しない条件
速度

【故障時の挙動について考える】
データ消失が発生しないということを考える上で、故障時にどのような挙動が想定されるかを考えるのは重要なことです。そこで家庭用外付けストレージケースで起こりうる故障とその挙動について考えてみました。

(1) HDDが故障した場合
RAID機能がある製品の場合、HDDが物理的に故障したとしても残りのHDDでデータが保全されるはずです。しかし何らかの理由でデータ不整合が起きて論理障害が発生した場合データを取り出す手段があるのか気になります。個人的な経験としても例えばRAID5のボリュームが原因不明で突然見えなくなるという障害を経験したことがありますが、こういった障害の場合、データ復旧がかなり困難になります。

(2) 本体が故障した場合
本体が故障した場合、別の本体を持ってきてHDDだけ入れ替えると保存していたデータがそのまま見えてくるような製品であれば問題ないですが、多くの家庭用製品の場合データが見えてこない気がします。エンタープライズストレージの場合はRAID構成情報が各HDDに書かれる製品が多いですが、この場合がHDDを別の本体に入れ替えてRAID構成をHDDから読み込むとそれまでのRAID構成が引き継がれます。それに対して安いストレージ製品の場合はRAID構成情報がストレージ本体もしくはRAIDコントローラーにしか書き込まれないので、本体が故障した場合HDDだけ入れ替えても当然RAIDボリュームが見えてきません。

(3) 電源寸断時の挙動
HDD書き込み中にコンセントが抜けてしまったり停電が起きたりしたときにデータ破壊されることがないかどうか。製品によって挙動は異なると思いますが、おそらくデータが一部破壊された状態になるのではないかと思います。

【ハードウェアRAID vs ソフトウェアRAID】
ハードウェアRAIDではRAID関連の処理を専用チップで行うことで高速にRAID関連処理を行うことができることに加え、高価なものだとキャッシュとバッテリーを搭載し、更なる高速処理と電源寸断時のデータ破壊を防ぐ機能を搭載しています。

それに対してソフトウェアRAIDではRAID関連の処理をCPUで行います。特に家庭用ストレージはLinuxなどのオープンソースOSをカスタマイズして使っているものが多く、RAID関連処理はLinuxにある機能をそのまま使っているものも多そうです。

ハードウェアRAIDはエンタープライズストレージに多く使われているのに対し、家庭用ストレージの場合はコストの関係からほぼ100%ソフトウェアRAIDだと思います。個人的には家庭用ストレージに高速性まで求めませんが、電源寸断対策用バッテリーがないのは不安です。

【結論】
いろいろ悩んだ結果、「NETGEAR社 ReadyNAS 104」という製品を購入することにしました。コンパクトなサイズにHDDが4本搭載できるNAS/RAID機能付の家庭用外付けストレージなのでした。購入価格は約2万2千円です。


HDDはこのように構成しました。

HDD1: 2TB(RAID1)。メインデータを置く
HDD2: 2TB(RAID1)。同上
HDD3: 1TB(RAID0)。メインデータのバックアップを置く
HDD4: 1TB(RAID0)。同上

要はメインデータ用ボリュームは実容量2TB(RAID1)、バックアップ用ボリュームも実容量2TB(RAID0)となります。データ保全としてはRAID1ミラーリングとバックアップを併用する形です。この構成であればRAID1が問題なく機能すればHDDが1本故障してもデータは保全されますし、万が一RAID1ミラーリングボリュームが見えなくなったとしてもバックアップからデータを取り出せます。また本体が故障したらHDDを取り出してLinuxが動いているマシンに取りつけてmdadmコマンドを使って自力でデータを取り出すことになりそうです。

おそらくこのタイプのストレージでは4本でRAID5を組んで使われるパターンが多いのだと思いますが、その構成だと既記したようにRAIDボリュームが見えなくなったり本体が故障した場合に最悪データが取り出せなくなると思いRAID5は採用していません。RAID1であればLinuxのmdadmコマンドを活用してなんとか自力で復旧できる気がしますが、RAID5だとできなくはないかもですがとても時間がかかりそうな気がしたのでした。

データ消失リスクという点においてはソフトウェアRAIDを信用してないので本当は使いたくなかったのですが、予算の都合もありRAID1ボリュームとRAID0ボリュームに分けてバックアップを取りながら使うことにしました。データ保全を考える上で本来こういった構成を取る場合は外部バックアップが必須ですが、予算と設置スペースの関係で泣く泣く外部バックアップなしとなりました。

※補足
なぜソフトウェアRAIDを信用していないか。本質的なところとしてはハードウェアかソフトウェアかというところにはなく、HDDにRAID構成情報が書かれるかと、電源断時にも書き込み途中のデータが確実に書き出されるかというところにあります。

【おまけ】
「NETGEAR社 ReadyNAS 104」をいろいろいじっていて感じたこと/気づいたことを記します。

・2万円台の安いストレージなのに、LUN切り出し、iSCSI、シンプロビジョニング、スナップショットと、エンタープライズストレージ並の機能が搭載されていました。
・ある意味プロ仕様なので、エンタープライズストレージを扱ったことがない人だと最初どう設定したらよいのか悩むかと思います。
・標準でアンチウィルス機能が搭載されているようです。
・RAIDはNetGear社独自のX-RAIDの他、RAID0,1,5,6,10、JBODが扱えます。HDD4本のうち好きな組み合わせでRAIDが組めます。
・Linuxベースです。sshログインしていろいろ操作できるのは便利です。
・ソフトウェアRAIDです。mdadmコマンドの利用に慣れていたらいろいろできます。
・CPUが弱いです。ちょっと処理速度が遅いかなー。
・安いのにNICが2個搭載されています。
・2TB HDDでRAID1構成を組んだ後、rebuildに6時間以上かかりました。
・筐体は結構コンパクトです。

安いのにプロ仕様で大変気に入りました。IT業界に身を置いている人は勉強にもなるのでお勧めです。逆にIT業界に身を置かない人は国産メーカーのわかりやすいGUIを持った製品のほうが良いかもしれません。

| | Comments (0) | TrackBack (0)

June 27, 2014

特別編: インフラエンジニアの教科書の翻訳本が韓国で発売されました

拙著「インフラエンジニアの教科書」の翻訳本が韓国で2014/6/20から発売開始されます。これを記念して韓国語でコメントさせていただきます。

Krbook

안녕하세요. 사노라고 합니다.

이번엔 한국의 출판사에서 "인프라 엔지니어의 교과서" 한국어판이 발매되었습니다. 저자는 대학생때 우연히 한국어를 배우고 현재는 일상적으로 한국어를 사용하는 직장에서 인프라엔지니어 업무하고 있습니다. 평소 인연이 깊은 한국과 새로운 기회가 생기고 아주 기쁩니다.

한국에서는 일반적으로 IT관련책의 번역해이 많지 않는다고 알고 있습니다. 이유는 일본보다 인구가 적다는 것으로 듣습니다. 일본에서는 유명한 책이라면 어느정도 일본어판으로 구입할 수 있습니다. 이번에 제 책이 한국어로 번역돼 시판된다고 해서 정말 놀랐습니다.

인프라엔지니어의 교과서는 기술책라는것 보다는 인프라 및 인프라엔지니어를 소개하는 책이라는 평가를 잘 받습니다. 기술을 깊이 배우고 싶은 분은 다른 책으로 공부하시는 게 좋을지도 모릅니다만 원래 무엇을 공부해야 좋을지 모르는 분은 본서에서 전체상을 이미지 하는 것이 유효할지도 모릅니다.

감사합니다

Jpbook

| | Comments (0) | TrackBack (0)

May 26, 2014

dmマルチパスを用いたDELLストレージ設定方法(MD30xx編)

今回はいつもと趣向を変えて、DELL社DASストレージの設定方法をご紹介します。今回ご紹介するMD3xxx系はマニュアルがわかりにくいだけでなくネット上で設定例をあまり見かけないので役に立つ方は役に立つかと思います。

さて、本題に入ります。

DELL PowerVault MD3000系DASストレージではマルチパスを扱うときに専用のMPPドライバーを使います。それに対してMD32xx系ではDM-RDAC(dm-multipath)と呼ばれるネイティブLinux kernelデバイスマッパーを使います。ここではMD3000系でもdm-multipathを使えるようにする設定方法を記します。

Dell_powervault_md3000i


【Storage ManagerとHBA board用ドライバーのインストール】
Linuxサーバ上にStorage ManagerとHBA board用ドライバーをインストールします。それらはMD3xxxに付属しているCDROMに含まれています。

※MD3xxx系では、サーバにRAIDボードではなくHBAボードを挿します。RAIDボードを使う場合はRAIDボード上でRAID関連処理をしますが、MD3xxx系ではストレージ側のコントローラーでRAID関連処理をします。


【MD3000でdm-multipathを使うための事前準備】
/etc/multipath.confを以下の内容に置き換えてリブートするとmultipathから見えるようになります。


defaults {
        getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
}
devices {
        device {
                vendor DELL*
                product MD3000*
                path_grouping_policy failover
                getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
                features "1 queue_if_no_path"
#               path_checker readsector0
                path_checker rdac
                prio_callout "/sbin/mpath_prio_tpc /dev/%n"
                hardware_handler "1 rdac"
                failback immediate
        }
}
blacklist {
       device {
               vendor Dell.*
               product Universal.*
       }
       device {
               vendor Dell.*
               product Virtual.*
       }
}

【MDSM(Modular Disk Storage Manager)の起動と設定】
MDSMはバージョンによって操作性が多少異なるので注意です。大雑把に以下の手順を実施します。

$ SMclient

1. マシン名をつける。
2. HotSpare HDDを指定する。
3. ディスクグループを作成する。(例: VG01)
4. 仮想ディスク(LUN)を作成する。(例: VG01_lun1, VG01_lun2) ※注:ディスクグループ1つに対して2つの仮想ディスクを作るようにすべし。すると各々の仮想ディスクが各パスに分散されるのでパフォーマンスが上がる\!
5. 仮想ディスク(LUN)とホストをマッピングする。

【ストレージとうまく接続できているか確認する方法】
DASを接続しているサーバからストレージが正しく認識しているか以下のように確認することができます。


$ multipath -ll
mpathc (36f01faf000dd7c2a000002513aaa3f5b) dm-1 DELL,MD30xx
size=1.5T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=14 status=active
| `- 1:0:0:1 sdc 8:32 active ready running
`-+- policy='round-robin 0' prio=9 status=enabled
  `- 1:0:1:1 sde 8:64 active ready running
 
mpathb (36f01faf000dd7ba2000002a0529257a6) dm-0 DELL,MD30xx
size=1.5T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=14 status=active
| `- 1:0:1:0 sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=9 status=enabled
  `- 1:0:0:0 sdb 8:16 active ready running

いずれも「status=active」であれば正常。


【サーバ内で仮想ボリュームを作る】


■1. pvcreate
pvcreate /dev/dm-1
pvcreate /dev/dm-2
 
■2. vgcreate
vgcreate vg1 /dev/dm-1 /dev/dm-2
 
■3. lvcreate
lvcreate -n lv01 -L 100GB vg1
lvcreate -n lv02 -L 100GB vg1
lvcreate -n lv03 -L 100GB vg1





$ fdisk -l
Disk /dev/mapper/vg01-lv01: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

OSからLUNがデバイスとして見えていれば正常。(LUN:Logical Unit Number。サーバから見えるデバイスのこと。一般PCでは1台のHDDを指すが、仮想化されたストレージの場合は切り出された領域が見える)


| | Comments (0) | TrackBack (0)

March 30, 2014

パスワードなしでrsyncする方法

他のサーバにrsyncしたいときがあります。その場合考えなければならないのが認証です。よく見られるのは送信先のSSH公開鍵を送信元に登録することで認証をスルーする方法です。しかしrsyncの場合、そんなことをせずともパスワードなしでrsyncできるということを最近知りましたので記録を残しておきます。

【送信先での設定】
まずはパスワードなしでrsyncするために、送信先サーバに下記の要領で/etc/rsyncd.confに追記します。rsyncdの再起動は不要です。

[USERDATA]
   comment=user data
   path=/home/user
   read only=false
   uid=user
   gid=user
   hosts allow=送信元サーバのIPやFQDN
   hosts deny=*

【送信元でのrsync実行】
続いて送信元でのrsync実行となります。下記の要領でrsyncを実行するとパスワードが聞かれずrsyncが可能となります。

rsync -av /home/user/data user@DESTHOST::USERDATA


ご参考までに下記は通常のパスワードが聞かれるrsyncの実行方法です。

rsync -av /home/user/data user@DESTHOST:/home/user

| | Comments (0) | TrackBack (0)

December 16, 2013

LinuxでのNIC冗長化(bonding)を少し深く考えてみる

サーバNIC(Network Interface Card)の可用性向上や負荷分散にはNIC冗長化が有効です。NIC冗長化については拙著「インフラエンジニアの教科書」にも記しましたが、bonding、チーミング、リンクアグリゲーションなど様々な呼び名があります。今回はLinux上でのNIC冗長化の話しとなりますので、bondingについての話題となります。

【bondingとは】
bondingとは、複数のNICが搭載されているマシンのNICを束ねて1つの仮想的なNICとして扱うことのできる技術です。例えば1GbpsのNICポートが4つ搭載されているサーバとL2スイッチの間を4本のLANケーブルで接続してbonding設定を有効にさせると、冗長化が行われて最低1本が正常であれば1~3本に問題があっても通信が継続できたり、負荷分散が行われて通信帯域幅を4Gbpsに拡張されたりといった使い方ができます。

Linux Kernelに標準搭載されているbondingでは以下のように7つのmodeがあります。

mode 名称 負荷分散 冗長性 primary
指定 
Switch
機能 
監視
モード
送信 受信 MII ARP
0 balance-rr SW依存 × Ether Channel
全スレーブを順繰り(ラウンドロビン)に使ってパケットを送信。
送信のみ負荷分散。
1 active-backup × × 不要
1つのスレーブのみを active interfaceとしパケットを送信。
active interfaceに障害が発生した場合、他の backup slave を active interfaceに切り替え、冗長性を確保。
2 balance-xor SW依存 × Ether Channel
送信元/先 MACアドレスを元に送信スレーブを決定しパケットを送信。
送信のみ負荷分散。
3 broadcast SW依存 不明 要(設定不明)
全スレーブに同一パケットを送信。
このモードは通常の用途で使用されないので無視。
4 802.3ad SW依存 802.3ad ×
IEEE 802.3ad(LACP)に準拠したリンクアグリゲーション。
5 balance-tlb SW依存 不要 ×
スレーブの負荷に応じて送信スレーブを決定しパケットを送信。
送信のみ負荷分散。
6 balance-alb 不要 ×
balance-tlbの機能に加え、受信も負荷分散。
参考文献: bondingドライバの違いについて


【負荷分散する際気を付けること】
「1Gbpsを4本を束ねると4Gbpsになる」という理屈は理解しやすいですが、適切なmodeを選び適切に設定しないと、例えば送信側は4Gbpsのままだけど受信側は1Gbpsのままといったようなことが起こりがちなので注意が必要です。

bondingを設定する際、ネットワークスイッチ側でも設定が必要な場合とネットワークスイッチ側の設定が特に不要な場合があることにも注意が必要でしょう。

ただしネットワークスイッチ側の設定が特に不要な場合だと言われているmodeにおいてもネットワークスイッチやそのファームウェアバージョンによってはまれに正常に動作しなくなる場合も見受けられるので、本番環境に投入する際には事前検証が必須です。著者の所属する会社のネットワークエンジニア某氏によるとmode4をお勧めしていました。

【Linux Kernelのbondingは実運用に耐えうるものか?】
著者の経験ではLinux Kernelのbondingはどこの会社でも一般的に使われているものなので、適切に設定されていれば安定性についてはそれなりに信頼できそうです。他のホームページでは2つのNICポートでの事例ばかりですが、4つのNICポートでも8つのNICポートでも普通に動作します。

bondingを可用性向上目的で用いる場合は、mode1にてそれぞれのNICポートの配線を別々のネットワークスイッチに接続することをお勧めします。一方bondingを帯域幅増強目的で行う際は、全ての配線を同一ネットワークスイッチに接続するのが一番安定するはずです。ただしこれはネットワークスイッチの挙動に依存する部分でもありますので、複数ネットワークスイッチでも安定的に動作する可能性を否定するものではありません。このあたりはネットワークスイッチベンダーに問い合わせみると良いでしょう。

| | Comments (0) | TrackBack (0)

November 06, 2013

「インフラエンジニアの教科書」が増刷されました

拙著「インフラエンジニアの教科書」に、おかげさまで増刷がかかりました。皆さんのおかげです。本当にどうもありがとうございます。

(追記 2014/10/16: 数回増刷いただき、現在8刷となりました。深く感謝です)


Twitterでたくさんのコメントをいただきましたので引用させてください。

@neofact 10月29日
Amazonで購入した、インフラエンジニアの教科書、幅広いカバレッジに驚かされる。また内容も非常に読みやすくまとまっている。まさに教科書。 pic.twitter.com/eFiSGBcIMM

@dblmkt 10月30日
「インフラエンジニアの教科書」読んでみた。サーバ、ストレージ、OS、DCなどの概要に加えて購買の話など幅広く含まれててWeb業界若手には絶対読んでほしい。迷いがちな選択肢へのアドバイス(クラウドかオンプレかなど)も結構あって、情シスやSIerの人にとっても新しい発見がありそう

@kamiyn 10月31日
「インフラエンジニアの教科書」 ただの技術書ではなくて、今まさにホットなLINEの急成長にどう対処したかという物語が根底にあるのがとても面白い。もっと読まれて欲しいけど、現在品切れ中なところだけが残念です

@hachi_eiji 10月31日
インフラエンジニアじゃなくても全然OK!/ 『インフラエンジニアの教科書』この本をなんと呼ぶ?教科書と呼ぶ! - (id:akuwano / @kuwa_tw) http://d.hatena.ne.jp/akuwano/20131031/1383187202

@just_do_neet 10月31日
実際に読んでみたけれど良い本だった。「購買と商談」「データセンター」「インフラ運用」あたりの章は座学では絶対に学び得ない見地が多く含まれていて、そういう意味で非常に貴重な本です。 / インフラエンジニアの教科書: 佐野 裕: 本 http://amzn.to/HtXQ7h

@inose660 11月2日
@sanonosa さんの『インフラエンジニアの教科書』を読む。基本的なところは押さえつつも、"会計処理から見るクラウド", "購買と商談", "大規模インフラ" などの章がすごく新鮮かつ実践的。カタログ読むにもスキルが要るもんね。いままでになかった切り口の入門書だと思う。

@sohgoh 11月2日
インフラエンジニアの教科書、読了。帯には「LINE社の現役エンジニア!」と言葉が踊っていますが、中身はインフラ周りの基礎的な内容が丁寧に書かれています。新任エンジニアやディレクター、技術に疎い管理職に読んで(机に置いて)欲しい一冊。 http://ow.ly/qq6Cq

@ftngrn 11月4日
本屋で見かけたので即買いしました。手頃なお値段で手厚い内容 / “「インフラエンジニアの教科書」という本を書きました: sanonosa システム管理コラム集” http://htn.to/tPHCvR

@hayajo 11月4日
インフラエンジニアの教科書読了。弊社スーパーインフラエンジニアが「この内容を理解してやっとスタートラインだよね」と言っていたのを理解できたり。もっかい気になる部分を読み直そ。

@makotow 11月4日
インフラエンジニアの教科書は、新卒インフラエンジニアはもちろん、アプリ屋なのにインフラやることになってしまった人にもおすすめできる。まもっと早く出てればなー。

@nekoruri 11月4日
まさに教科書。『インフラエンジニアの教科書』佐野 裕 ☆5 http://bit.ly/1iJZWec #booklog


また書評してくださった方がいらっしゃるのでリンクさせていただきます。どうもありがとうございます。^^
・『インフラエンジニアの教科書』この本をなんと呼ぶ?教科書と呼ぶ!
・The textbook of the infrastructure enginee
・インフラエンジニアの教科書"を読んで

一生懸命書いた自信作ですので一度読んでみてください。どうぞよろしくお願いいたします。

| | Comments (0) | TrackBack (0)

November 04, 2013

RAID5のパリティ生成アルゴリズム

「RAIDという仕組みは本当に安全なのか?」という懸念が昔からあったので、今回RAID5のParity algorithmについて研究してみました。(RAID6のParity algorithmについて研究しましたが、それはまた今度)

【RAID5の特徴】
RAID5の特徴について改めて整理すると以下のようになるかと思います。

•Block単位でパリティ分散記録する。
•水平パリティを1つ用いる。水平パリティにはXOR方式を用いることが一般的。
•HDDが1本壊れても復旧できる。


【XOR(排他的論理和)について】
RAID5ではXORを用いてパリティを生成しますので、まずはXORについておさらいしておきます。

ABA XOR B
000
011
101
110

【RAID5のパリティ生成の仕組み】
例えばデータが「1111 0101 1100 1010 0000 1111」の場合は以下のようになります。

HDD-AHDD-BParity
111101011010
110010100110
000011111111

仮にB列が消失した場合はどうなるでしょうか。

HDD-AHDD-BParity
1111?1010
1100?0110
0000?1111

この場合はHDD-AとParityでXORを適用するとBが復元できます。

HDD-AHDD-BParity
111101011010
110010100110
000011111111

この仕組みを応用して、HDD本数が7本の場合、A-BのXOR結果とC、その結果とD、・・・とXORをしていくことになります。

HDD-AHDD-BHDD-CHDD-DHDD-EHDD-FParity
1111101011000110000011110000

仮にhdd-Bが故障した場合はどうなるでしょうか。

HDD-AHDD-BHDD-CHDD-DHDD-EHDD-FParity
1111?11000110000011110000

この場合もBを除いた全てとxorをしていくとBが復元できます。(xorする順番は問わない)

0000 G
1111 F
----
1111
0000 E
----
1111
0110 D
----
1001
1100 C
-----
0101
1111 A
----
1010 B

HDD-AHDD-BHDD-CHDD-DHDD-EHDD-FParity
1111101011000110000011110000

こんなシンプルな仕組みであればファームウェアのバグ発生は考えにくそうで、RAID5はそれなりに安全そうですね。

※最後に「インフラエンジニアの教科書」という本を出版させていただきました!という宣伝で締めさせていただきます。

| | Comments (0) | TrackBack (0)

October 31, 2013

「インフラエンジニアの教科書」という本を書きました

ご無沙汰しています。

前回の記事から1年半近く経ってしまっています。前回のエントリーでLINEが3500万ユーザと書いてますが、現在は2億数千万ユーザとなってますのでずいぶんと伸びたものです。感謝感謝です。

さて、「インフラエンジニアの教科書」という本を書きましたのでご報告させていただきます。おかげさまで出版社の方曰く「ただいま、素晴らしい初速で売れています」だそうで、一部売り切れてしまったお店もあるそうです。おそれいりますが気長に入荷をお待ちください。

書評してくださった方がいらっしゃるのでリンクさせていただきます。どうもありがとうございます。^^
・『インフラエンジニアの教科書』この本をなんと呼ぶ?教科書と呼ぶ!
・The textbook of the infrastructure enginee
・インフラエンジニアの教科書"を読んで

一応執筆時にこだわった点をアピールしてみます。

・「技術書なのに読みやすい」という路線を目指しました。さくさく読めると思います。

・文書だけだと読むのに疲れるので可能な限り図を入れました。

・起業してから現在に至るまで、個人的に悩んできたことの多くを盛り込みました。特に新たにインフラを立ち上げる場合役に立つと思います。例えば何か買いたいときどのようにベンダーや営業さんと付き合えばよいか、ルータはどれを買えばよいか、データセンターのラックにどこに何を設置すれば良いか等々、他の本ではあまり書かれていないような具体的なレベルのことがたくさん書いてあります。

・メモリには「ランク」という概念がありますが、拙著ではこのランクの意味をわかりやすく正確に説明している国内唯一の本ではないかと自負しています。ネットでくまなく探しましたが、日本語、英語共わかりやすく説明しているサイトが見つからなかったのでした。

・中小オープンソース系企業であまり使われないものについて一通り把握するのに便利です。
  ・Windowsライセンス体系
  ・VMwareライセンス体系
  ・ストレージの種類や技術全般
  ・エンタープライズ機器(電話回線接続してベンダーが障害検知する話しとか)
  ・SASディスク、FCディスク、Fusion-IO(ioDrive)の写真
  ・光ファイバ系の写真(ケーブル、LCコネクタ、SCコネクタ、GBIC、SFP)
  ・ネットワークファブリック構造
  ・データセンターの空調方式(排熱吸引方式、外気空調方式など)
など一通り網羅しています。

・一方、普通の用途に使われないと思うものはばっさり切り捨ててあります。例えばVMwareの製品体系は複雑ですが、本書ではvSphereとvCenterにしか触れてません。

・ライセンス購買のリファレンス的に使えるようにもしました。Win, RHEL, SQLSVR, Oracle, VMwareなどのライセンス体系と価格をわざわざ書いているのは、購買検討時にいちいちネットで検索しなくても済むので便利だからなのでした。ネットとは違い更新が効かない一般書で製品価格を入れるのはリスキーなので普通の本ではあまりやらないと思います。

では~。

(追記 2013/11/2)
いくつか誤植と内容修正が見つかっておりますのでここに共有させていただきます。

-----
第2刷で修正されている内容

・P52。「ストライピング本数がRAID5では4本なのに」→「RAID10では4本なのに」。(川島さん、ありがとうございます)

・P53。RAID6の対角線パリティ方式の考案者はNetAPP社のPeter Corbett氏だそうです。(manabuさん、ありがとうございます)

・P70。Oracle LinuxはDebian系ではなくてRed Hat系の間違いです。(なぜこの明らかな間違いが校正時にあぶりだせなかったのか個人的にショックです。関係者の皆さまご迷惑をおかけしました)

・P114。自動階層化の図で SSD-SATA-SAS の順は、SSD-SAS-SATAの間違いでした。(かみやさとしさん、ありがとうございます)

・P127。排熱吸引方式の最後の行にて、「高なります」→「高くなります」

・P141。Windows20・00→Windows2000

-----
第3刷で修正されている内容

・P93。Protcol -> Protocol。(堂阪さん、ありがとうございます)

・P94。cccc:::1 -> cccc::1、 :::1 -> ::1。(堂阪さん、ありがとうございます)

-----
もし第4刷が出たら修正される内容

・P84
・ARPテーブル -> MACアドレステーブル。(池田さん、ありがとうございます)

| | Comments (1) | TrackBack (0)

June 14, 2012

リリース1年弱で登録ユーザー数3,500万人突破した無料通話・メールアプリ「LINE」を支えるインフラ開発

先日リクナビNEXTさんから取材を受けました。写真入りで恥ずかしいですが。(笑)

リリース1年弱で登録ユーザー数3,500万人突破した無料通話・メールアプリ「LINE」を支えるインフラ開発

(記事掲載の2012年5月23日時点では3500万ダウンロードでしたが、この記事を書いている2012年6月13日時点では4100万ダウンロードを超えているようです。本当に凄い勢いですよね)


最近大ヒットしているLINEですが、あまりにも成長スピードが速すぎてインフラ構築は本当にきついです。企業秘密に触れない範囲でちょっとだけ舞台裏を暴露してしまうと、以前はサーバ納品速度がボトルネックでした(今は違います。それは内緒)。

いくらサーバを増設してもすぐに追加増設を求められる状況で、サーバ発注から納品までの期間をいかに縮めるか大変苦労しました。特にタイ洪水のときはHDDがなかなか確保できず、HDD確保後生産してもらったサーバをどの船や飛行機に乗せてもらえば納期に間に合うか、というレベルまでベンダーさんと調整したときもありました。今ではサーバベンダーさんに無理を言ってかなり短い期間でサーバ納品してもらえるようになりましたが。

・・・というような裏話がそれこそ本一冊書けるくらい連日発生している状態です。

それでも現在なんとか回せている理由は、リクナビNEXTのWEBページにも書いてありますが、昔ハンゲームが急成長したときに苦労した経験がものすごく生きているからだと思っています。当時の経験から、今の状態がこのまま続くと次は何が問題になるかを高い精度で導き出せるので、現場のメンバーには現在起こっていることを解決してもらう裏で、私が今後起こることを事前に対策する、という感じで回しています。

この辺の話は技術論とは別に多くの方に役立つ話だと思うのでぜひ公開したい気はありますが、果たして会社から許可でるかなあ。。。

| | Comments (0) | TrackBack (0)

June 04, 2012

Amazonで二度と機械モノは買わないと思った話

送料無料で何でも安く早く買えるAmazon。とても便利なのでよく利用していますが、最近とてもがっかりした話がありますので書いてみます。

先日AmazonでASUS社のマザーボードを買ったのですが、数ヶ月に壊れてしまいました。そのこと自体はどうしようもないことなので特に何も思っていませんが、問題はAmazonの対応です。

箱には、修理対応は購入店を経由してほしい旨書いてあったのでAmazonに連絡してみました。すると機械類については直接メーカーに問い合わせてくれという。そこでメーカーに連絡してみるとやはり購入店に連絡してくれという。

仕方ないので再度Amazonに連絡してみると、Amazonでは◯ヶ月以内の初期不良交換は無料で行うが、それ以降だと手数料がかかるが、今回は事情が事情なので、今回に限り無料で交換を行うという返事が返ってきた。

冗談じゃない。

こちらは保証期間中に壊れたので無償修理をしてほしかっただけで、新品交換してほしいだなんて一度も言っていない。しかも今回に限り無償交換ということは、次回以降は保証期間中でも有償交換になるということか。

話を聞いてみると、どうやらAmazon内にはハードウェアの修理対応担当部署がないとのこと。こんな販売店からは以後怖くて機械モノは買えないと思いました。

| | Comments (0) | TrackBack (0)

March 02, 2012

大規模システム構築と小規模システム構築の大きな違い

最近採用活動をしていてよく誤解されることがありましたので、昔書いた記事を紹介させていただきます。

・大規模システム構築と小規模システム構築の大きな違い(その1)

・大規模システム構築と小規模システム構築の大きな違い(その2)

| | Comments (0) | TrackBack (0)

January 23, 2012

ブログ再開のご挨拶

ここ5年ほど社内システム関連の部署に異動となっていたため、システム管理的な話題があまりなくてブログを更新できてませんでしたが、昨年9月に突然古巣のインフラ部門に異動となって戻ってきたため、ブログの更新を再開しようと思います。

あと、ずっと所属会社名を伏せていましたが、ちょっと考え方を変えて、今年から所属会社名をオープンにすることにしました。

所属会社はNHN Japan株式会社です。サービスブランドはHangame、NAVER、そしてlivedoorの3つです。社員数は多分1500人くらい、サーバ台数は数千台規模の会社となります。私は現在そこでサーバ部門の管理職を行っています。

最近はスマートフォン上で動く「LINE」というサービスが世界規模で大ブレイクしていまして、毎週100万人規模でユーザが増えています。今日時点でユーザ数が1500万人くらいです。このペースだと年内1億ユーザに到達してしまうかも、という雰囲気の中で動いています。当然サーバ増強のペースがものすごくてとてもあわただしい状況です。


最後に人材募集をさせてください。

今本気でインフラ部門の人材募集をしています。下記に該当される方は是非ご連絡ください。まずは話を聞いてみたい程度でも結構です。

●サーバ部門:Linux/Windows serverの構築・運用経験がある方。ベテランだけでなく伸び盛りな見習いの方も大募集です。

●ネットワーク部門:ISPもしくは同等規模でのネットワーク構築/運用経験がある方。L3スイッチ以上の経験者が望ましいです。

●データベース部門:Oracle/SQL Server/MySQLのDBA経験者。特にMySQLのDBAに関心がある方を大募集しております。


当社に関心を持ってもらうための売り文句を述べます。

・今年9月に渋谷ヒカリエに事務所移転します。通勤が便利です。
・億規模のインフラ投資(必要と思われるものは大抵買ってもらえる環境です)
・エンタープライズ機器大量導入(普段滅多に見られない高価な機器にたくさん触れます)
・海外に行くチャンスあり(一応グローバル企業ですので)
・福利厚生(詳しくはこちらを見てください)
・天才エンジニアが多い(天才エンジニアの開発速度は常人の常識を遙かに超えていてそれを間近に見られます。特に韓国でNHNはNo.1インターネット企業ということもあり韓国内での天才エンジニアがNHNに集まりやすい傾向があるようです。天才の定義は難しいのですが、概して韓国人天才エンジニアは全く日本語を知らない状態で来日して3ヶ月もあれば普通に日本語をマスターしてしまいます。うらやましい。。。)
・女性が多い。特にデザイナーの女性比率が結構高いみたいです。
・グローバル企業です。韓国本社、東京・福岡、アメリカ、大連などのオフィスがあります。他にもありそう(実はよく知らない)。
・(自身のキャリアアップの方向性が明確であれば)教育を受ける環境がたくさんあります。

この募集は一旦2月を締め切りとします。ご興味がちょっとでも沸いた方はとりあえずご連絡だけでもいただけたら幸いです。

よろしくお願いいたします。

※追記(2012/2/13)
予想を大幅に超えるご連絡をいただいており現在ご返答が大変遅れております。順次ご回答させておりますので今しばらくお待ちください。また、原則メールをいただいてから3日以内にご返答させていただいておりますが、もしメールが返答されてこないという場合は再度ご連絡ください。どうぞよろしくお願いいたします。

| | Comments (2) | TrackBack (0)

June 17, 2011

puttyをタブモードで使う

SSHクライアントソフトとして普段puttyを愛用していますが、タブモードで使えないことだけが不満でした。そこでなんとかならないかと調べてみたら、PuTTY Connection Managerを入れればよいとわかりましたのでご紹介します。(追記: 2014/12/16 現在は開発中止してるみたいです)

PuTTY Connection Manager

Downloads->Current beta versionの中にある「Standalone Executable」をダウンロードすれば、あとはそのexeファイルを実行し、putty本体の所在地を指定するだけでタブ版puttyが起動します。

Tabputty_2

※最後に「インフラエンジニアの教科書」という本を出版させていただきました!という宣伝で締めさせていただきます。

| | Comments (0) | TrackBack (0)

May 31, 2011

全角カタカナが含まれているファイルを探し出すスクリプト

携帯サイトを作っている際、全ての全角カタカナを半角カタカナに置き換えるために、全角カタカナが含まれているファイルを一気に洗い出したいと思うことがあります。しかしネット上で検索しても自分的にしっくりくる方法がみつかりませんでした。

そこで今回非常に簡単なスクリプトを作ってみました。スクリプトを見ていただければわかりますが、実現方法としてはかなり恥ずかしい部類とは言えます。が、この方法以外思いつかなかったのと、こんなスクリプトでもきっと役に立つ人がいると思い恥を忍んで公開してみます。(注:調べたいファイルの文字コードがUTF-8ならUTF-8で保存するようにしてください)

※もしスマートな解決方法をご存じな方がいらっしゃいましたらコメントいただけたら嬉しいです。

#!/bin/bash

pushd /var/www/html/
grep "ア" *.html > tmp
grep "イ" *.html >> tmp
grep "ウ" *.html >> tmp
grep "エ" *.html >> tmp
grep "オ" *.html >> tmp
grep "カ" *.html >> tmp
grep "キ" *.html >> tmp
grep "ク" *.html >> tmp
grep "ケ" *.html >> tmp
grep "コ" *.html >> tmp
grep "サ" *.html >> tmp
grep "シ" *.html >> tmp
grep "ス" *.html >> tmp
grep "セ" *.html >> tmp
grep "ソ" *.html >> tmp
grep "タ" *.html >> tmp
grep "チ" *.html >> tmp
grep "ツ" *.html >> tmp
grep "テ" *.html >> tmp
grep "ト" *.html >> tmp
grep "ナ" *.html >> tmp
grep "ニ" *.html >> tmp
grep "ヌ" *.html >> tmp
grep "ネ" *.html >> tmp
grep "ノ" *.html >> tmp
grep "ハ" *.html >> tmp
grep "ヒ" *.html >> tmp
grep "フ" *.html >> tmp
grep "ヘ" *.html >> tmp
grep "ホ" *.html >> tmp
grep "マ" *.html >> tmp
grep "ミ" *.html >> tmp
grep "ム" *.html >> tmp
grep "メ" *.html >> tmp
grep "モ" *.html >> tmp
grep "ヤ" *.html >> tmp
grep "ユ" *.html >> tmp
grep "ヨ" *.html >> tmp
grep "ラ" *.html >> tmp
grep "リ" *.html >> tmp
grep "ル" *.html >> tmp
grep "レ" *.html >> tmp
grep "ロ" *.html >> tmp
grep "ワ" *.html >> tmp
grep "ヲ" *.html >> tmp
grep "ン" *.html >> tmp
grep "ー" *.html >> tmp
sort tmp | uniq > tmp2
cat tmp2
rm -f tmp
rm -f tmp2
popd

| | Comments (2) | TrackBack (0)

May 26, 2011

Linuxで突然キー入力が受け付けられなくなる問題の対策

コンソール上でキー操作をしている時に突然キー入力できなくなる問題に遭遇することがあります。これは簡単に再現&解除できます。

CTRL+s : キー入力できなくなったように見える操作
CTRL+q : キー入力できなくなった状態を解除する操作


このキー操作がどのような経緯で生まれたのか等は別のWEBサイトに譲るとして、この機能自体恒久的に必要ないという大多数の方は、以下のコマンドを実行することでキー入力が受け付けられなくなる機能が無効になります。

$ stty stop undef


ログイン毎にこの入力をするのが面倒な方は.bashrcに追記しておくと良いでしょう。

| | Comments (0) | TrackBack (1)

May 15, 2011

MySQLアクセスはGUI派? それともCUI派?

Twitter内で、MySQL管理はGUIとCUIのどちらがいいのか、という論争がありました。私個人としては、断然GUI派です。CUIも一応使えますが、GUIが使える環境であれば迷わずGUIを使います。

データベースって、例えば細かい権限設定などをCUIでやろうとすると、見にくいのでどうしてもケアレスミスが発生しがちです。GUIであれば直感的な操作で対応できる場合が多いので、ケアレスミスが少なくなります。

・・・という表向きの理由がありますが、実は「privileges」という単語をどうしても覚えられなくてCUIだとつらいという状況が続いていました。MySQLのCUIって全般的に覚えにくい気がします。さすがに5年目くらいには慣れてきて今では大丈夫になりましたが。


[関連記事]
急いでいる人のためのMySQLのユーザ権限付与講座

| | Comments (0) | TrackBack (0)

November 05, 2010

L1スイッチの使い道

L2~L4スイッチあたりは馴染みがある人が多いと思いますが、L1スイッチについては聞いたことすらない人も多いのではないでしょうか。L1スイッチは大規模サイトでは必須と言っても過言ではないくらい重要となります。というわけで今回はL1スイッチについて記してみます。


【L1スイッチとは?】
L1スイッチとは、物理層で切り替え(スイッチ)することのできるネットワーク機器となります。ある意味パッチパネルでの切り替えを電気的に行える機械とも言えます。かつ市販されているL1スイッチではメーカー毎に様々な機能が付加されている場合が多いです。

※余談ですが、レピータHUBもレイヤー1に該当しますが、レピータHUB自体にスイッチ機能はないのでレピータHUBがL1スイッチかと問われると微妙な気がします。


【L1スイッチのよくある使い道: ログ分析&IDS】
大規模サイトでよく使われる用途としてはログ分析&IDS監視です。大量の通信をログ分析サーバもしくはIDSサーバに流し込むために、本番系ネットワークとバックエンドネットワークの間にL1スイッチを挟みこみます。

L1

本番系ネットワークのL2スイッチにポートミラーリング設定をほどこし、L2スイッチ上を流れる全てのフレーム(※念のため注:L2なのでパケットではなくてフレーム)をL1スイッチ側に流れるようにすれば、結果的に本番系ネットワークの全てのフレームがL1スイッチを経由してバックエンドネットワークに流れ込むことになります。

そして、その流れ込まれたフレーム(というかL1なので信号かな?)をログ分析サーバもしくはIDSサーバが拾い、分析を行います。

ところでL1スイッチによっては、流れ込まれた信号をロードバランサーのように各サーバに割り振る機能を持つ場合があります。この場合負荷が増えてきた場合に分析サーバのスケールアウトが可能になります。


【L1スイッチを製造しているメーカー】
L1スイッチを製造しているメーカーはそんなに多くありません。例えば著者が調べた限り、以下の4社がありました。

・APCON社(INTELLAPATCH Family)
・Gigamon社(GigaVUE)
・日本ダイレックス株式会社(eL1 SWS)
・Glimmerglass社


【おまけ(宣伝)】
私が監修させていただいた「これだけは知っておきたい ネットワークの常識」技術評論社(共著。監修担当)にも用語集にL1のことをばっちり(?!)載せています。

| | Comments (0) | TrackBack (2)

November 02, 2010

MySQLのSQLクエリーだけで棒グラフを表示する方法

MySQLの出力結果を棒グラフで表示できたらいいなぁと思っていろいろ実験していたらうまくいってしまったのでご紹介してみます。

【普通の場合】
普通は以下のようになりますよね。出力結果だけ見てもどうもよくわかりません。

■SQL文

mysql> select date_format(regdate, "%Y/%m/%d %H") date, count(*) count from usert group by date order by date asc;

■出力結果

+---------------+-------+
| date     | count |
+---------------+-------+
| 2010/11/01 00 |  405 |
| 2010/11/01 01 |  276 |
| 2010/11/01 02 |  188 |
| 2010/11/01 03 |  148 |
| 2010/11/01 04 |  96 |
| 2010/11/01 05 |  63 |
| 2010/11/01 06 |  85 |
| 2010/11/01 07 |  142 |
| 2010/11/01 08 |  164 |
| 2010/11/01 09 |  137 |
| 2010/11/01 10 |  177 |
| 2010/11/01 11 |  177 |
| 2010/11/01 12 |  248 |
| 2010/11/01 13 |  178 |
| 2010/11/01 14 |  148 |
| 2010/11/01 15 |  158 |
| 2010/11/01 16 |  195 |
| 2010/11/01 17 |  213 |
| 2010/11/01 18 |  243 |
| 2010/11/01 19 |  236 |
| 2010/11/01 20 |  274 |
| 2010/11/01 21 |  310 |
| 2010/11/01 22 |  309 |
| 2010/11/01 23 |  280 |
+---------------+-------+


【棒グラフの場合】
そして今度は出力結果を棒グラフにした場合の例になります。ものすごくわかりやすくなりました。

■SQL文

mysql> select date_format(regdate, "%Y/%m/%d %H") date, REPEAT("#", count(*)/10) graph from usert group by date order by date asc;

■出力結果

+---------------+-------------------------------------------+
| date     | graph                   |
+---------------+-------------------------------------------+
| 2010/11/01 00 | ######################################### |
| 2010/11/01 01 | ############################       |
| 2010/11/01 02 | ###################            |
| 2010/11/01 03 | ###############              |
| 2010/11/01 04 | ##########                |
| 2010/11/01 05 | ######                  |
| 2010/11/01 06 | #########                 |
| 2010/11/01 07 | ##############              |
| 2010/11/01 08 | ################             |
| 2010/11/01 09 | ##############              |
| 2010/11/01 10 | ##################            |
| 2010/11/01 11 | ##################            |
| 2010/11/01 12 | #########################         |
| 2010/11/01 13 | ##################            |
| 2010/11/01 14 | ###############              |
| 2010/11/01 15 | ################             |
| 2010/11/01 16 | ####################           |
| 2010/11/01 17 | #####################           |
| 2010/11/01 18 | ########################         |
| 2010/11/01 19 | ########################         |
| 2010/11/01 20 | ###########################        |
| 2010/11/01 21 | ###############################      |
| 2010/11/01 22 | ###############################      |
| 2010/11/01 23 | ############################       |
+---------------+-------------------------------------------+

| | Comments (0) | TrackBack (0)

November 01, 2010

古いログを別のディレクトリに自動的に移動する方法

ログが溜まってくると、必要な情報を探しにくくなるので古いログを別のところに移動させたいと思うようになります。今回はそんな場合のためのcron設定を記してみます。

【cron設定】
いろいろな方法があるかと思いますが、今回はシンプルにいきます。

5 3 * * * /usr/bin/find /home/user/logs/*log -maxdepth 1 -type f -mtime +6 -exec /bin/mv {} /home/user/oldlogs/ \; 1> /dev/null

細かいオプションの意味は以下の通りです。

・「-maxdepth 1」・・・検索対象のディレクトリを1階層に制限する。
・「-type f」・・・検索対象をファイルに限定する。
・「-mtime +6」・・・データが修正された時間が7日以前のもの。+6とは7日(144時間)前~過去を指す。(+7でない点に注意)
・「-exec ~ \;」・・・「~」の部分のコマンドを実行する。
・「{}・・・ここにfindされたファイルのファイル名が入る。


【注意事項】
この方法で古いファイルを移動させる際、ログを吐き出す元アプリケーションを再起動しないとその後のログを吐き出さなくなる場合があります。その場合はrotatelogsかlogrotateを組み合わせるなどで回避する方法もあります。

| | Comments (0) | TrackBack (0)

October 28, 2010

WEB上からapacheの生ログを見ることができるようにするプログラム

apache生ログをWEB上から見たいという要望を受けて簡単にPHPで作ってみましたのでご紹介致します。突っ込みどころ満載かと思いますが、その場合はコメントに記載いただけましたら幸いです。改善的コメント大歓迎です。

※重大な警告:この手のスクリプトは重大なセキュリティホールを招く場合がありますので、もし実利用される場合は十分ご注意ください。


【プログラムの概要】
今回作成したプログラムでは、特定ディレクトリ内のファイルリストを取得して一覧を出します。そして一覧の中から特定ファイルをクリックするとそのファイルの最後10行(もしくは指定行数)を表示するというものです。例えばこんな感じです。

web1 top>
tail -

access_log 38543
access_log 5435
access_log 23533
error_log 10206
error_log 236
error_log 1256


【プログラム】
これを実現するプログラムは以下の通りです。特に難しいことはやってないので容易に理解できるかと思います。(赤字の部分を直して使ってください)

■logview.php

<?php
$scripturl = "http://www.example.com/admin/logview.php";
$basedir = "/var/log/httpd";

global $f_cmd;
global $f_filename;
$f_numlist = 10;
if (isset($_GET["c"])) $f_cmd = htmlspecialchars(@$_GET["c"], ENT_QUOTES);
if (isset($_GET["f"])) $f_filename = htmlspecialchars(@$_GET["f"], ENT_QUOTES);
if (isset($_GET["n"])) $f_numlist = htmlspecialchars(@$_GET["n"], ENT_QUOTES);

if (strpos($f_filename, "..") !== FALSE) {
     print "You can't use '..'.";
     exit;
}

print `/bin/hostname` . "<a href='$scripturl'>top></a><br />";
?>

<form method="GET" action="viewlog.php">
  <input type="hidden" name="c" value="<?=$f_cmd?>" />
  <input type="hidden" name="f" value="<?=$f_filename?>" />
  tail -<input type="text" name="n" size=3 value="<?=$f_numlist?>" />
  <input type="submit" />
</form>

<pre>
<?php
//--------------------
//ログ一覧表示
//--------------------
if ($f_cmd == "") {
    $lists = `ls -lb  $basedir/*log* |awk '{print $9,$5}'`;
    $arr_lists = split("\n", $lists);
    foreach ($arr_lists as $list) {
        $list = str_replace($basedir."/", "", $list);
        $arr_list = split(" ", $list);
        if ($arr_list[1] != 0) {
            $arr_list_new = str_replace("error", "<font color=red>error</font>", $arr_list[0]);
            print "<a href='$scripturl?c=p&f=$arr_list[0]'>$arr_list_new</a> $arr_list[1]<br />";
        }
    }
}

//--------------------
//ログ表示
//--------------------
if ($f_cmd == "p" && !empty($f_filename)) {
    system("tail -$f_numlist $basedir/$f_filename");
}
?>
</pre>
</html>

| | Comments (3) | TrackBack (1)

October 26, 2010

サーバ間の設定ファイル差異を比較するスクリプト

サーバ台数が増えてくると、例えば同じ種類のサーバをスケールアウトしているとき、1台だけ設定ミスがあったとしてもなかなか気付きづらくなります。サービスの安定稼動のためにはこういった些細なミスは完全に潰しておく必要があります。そこで今回はサーバ間の設定ファイル差異を比較するスクリプトを作りましたのでご紹介してみます。


【前準備】
まずはこちらでも記したような方法で、パスワードなしで各サーバにSSH接続できるようにしておいてください。

【サーバ間の設定ファイル差異を比較するスクリプト】
下記スクリプトをどこかに保存してください。ファイル名は便宜上「filediff.sh」とでもしておきます。そして、今回比較するファイル名を羅列し、かつサーバ番号(下記の例だと10.0.0.1の設定ファイルを10.0.0.2~10の設定ファイルと比較しています)を書き換えてください。

$ cat > filediff.sh

~スクリプトの内容をペースト後、Ctrl+C~

$ chmod gou+x filediff.sh
$ vim filediff.sh

■filediff.sh

#!/bin/bash

FILES[0]="/etc/httpd/conf/httpd.conf"
FILES[1]="/etc/php.ini"
FILES[2]="/etc/my.cnf"

SVR_FROM=2 # サーバ番号始まり
SVR_TO=10 # サーバ番号終り

#
for file in ${FILES[@]};do
  echo "**************************************************"
  echo $file
  echo "**************************************************"
  scp 10.0.0.1:${file} /tmp/_a
  for i in `seq ${SVR_FROM} ${SVR_TO}`;
  do
    echo "[10.0.0.${i}]"
    scp 10.0.0.${i}:${file} /tmp/_b
    diff /tmp/_a /tmp/_b
    rm -f /tmp/_b
  done
  rm -f /tmp/_a
done

# 後処理
unset SVR_FROM
unset SVR_TO
unset FILES


【実行方法】

以下のように実行します。

$ filediff.sh

差異があると下記のように表示されます。

[10.105.4.33]
103c103
< ServerName web1:80
---
> ServerName web2:80


※緊急お知らせ
今週4~6名くらいで技術者交流会という名の飲み会を行なうことになったのですが、メンバーが全然集まっていません。当然面識がなくても構いませんのでどなたか飲みませんか? 参加可能な方は調整さんにエントリーお願い致します!
・・・ということで大変ありがとうございます。4名集まりましたので、10/27(水) 19:00 JR五反田駅改札を出たところ集合でいきましょう。多少であれば飛び入り参加もきっと大丈夫ですのでよろしくお願いいたしまーす。・・・ということで開催してきました。とても盛り上がって楽しかったですね。それにしても皆さん経験豊富だなあ、頑張らないとなあと思いました。またやりましょうね。

[調整さんにエントリー]

●開催趣旨:居酒屋土間土間で1時間525円飲み放題らしいので、たくさん飲みましょうというただそれだけになります。^^

| | Comments (0) | TrackBack (0)

October 24, 2010

WEB上からrsyncを実行する方法

各サーバ群にソースコードを配信するためにrsyncを使っているところも多いと思います。この操作をWEB上から行えるようになれば、例えばデザイナーがちょっとした画像データを配信するといった場面などで便利そうです。そこで今回はrsyncをWEB上から実行する方法について記してみたいと思います。


【ハマりどころ確認】
WEB上からrsyncを実行するのって、簡単に見えて実はちょっと難しいのです。ハマりどころは2つあります。それは

  (1) rsyncを実行するユーザがパスワードなしで配信先サーバにSSH接続できるようにしておかなければならない。

  (2) 配信先サーバでは、rsyncを実行するユーザと同じ名前のユーザで、該当ファイルやディレクトリの書き込み/編集権限を持っていなければならない。

というものです。

(1)については、こちらでも記したような方法で、パスワードなしで他のサーバにSSH接続できるようにしておかなければなりません。ただ厄介なのは、CentOSでyumを使ってapacheをインストールした場合、初期状態のままだとapacheユーザがnologinユーザ(すなわちログインできないユーザ)として登録されているので、これをログインできるユーザに直すところからはじめなければなりません。(注:もしくはapache起動ユーザを変えるという手もあります)

(2)については、配信先サーバ側でもapacheユーザとして該当ファイルやディレクトリに書き込みしに行きますので、パーミッション設定を行わなければなりません。方法としては、ファイルやディレクトリの所有者をapacheユーザにするか、もしくはファイルやディレクトリの所属グループをapacheにした上で、グループの書き込み権限を「w」にする方法があります。今回は後者の方法を採用しました。

ということを踏まえて、以降具体的な設定方法を記していきます。手順は面倒ですが、ほぼコピー&ペーストでいけるので作業自体はそんなに大変ではないかもしれません。


【配信元サーバ側の作業】
OSのapacheユーザがnologinになっているので、通常はapacheユーザでログインできませんが、今回は特別にapacheユーザでもログインできるようにします。(/etc/passwdのapacheユーザの最後の/sbin/nologinを/bin/bashにします)

# sed -i "s/apache:x:48:48:Apache:\/var\/www:\/sbin\/nologin/apache:x:48:48:
Apache:\/var\/www:\/bin\/bash/" /etc/passwd

apacheユーザの秘密鍵と公開鍵を置く場所を作ります。

# mkdir /var/www/.ssh
# chmod 700 /var/www/.ssh
# chown apache.apache /var/www/.ssh

apacheユーザの秘密鍵と公開鍵を作ります。

# su - apache

$ ssh-keygen -t rsa (とりあえず全部Enterで)

すると、秘密鍵(id_rsa)と公開鍵(id.rsa.pub)が生成されるので、公開鍵(id_rsa.pub)の中身をメモ帳などにコピーしておきます。(あとでペーストします。)

$ cat ~apache/.ssh/id_rsa.pub


【各配信先サーバ側の作業】
先程コピーした公開鍵をペーストしつつ、下記のスクリプトを実行します。特に一番最後の行がとても重要です。wwwディレクトリ配下をapacheユーザでも更新できるようにグループ変更を行っています。

# sed -i "s/apache:x:48:48:Apache:\/var
\/www:\/sbin\/nologin/apache:x:48:48:Apache:\/var\/www:\/bin\/bash/" /etc/passwd

# mkdir /var/www/.ssh
# chmod 700 /var/www/.ssh
# chown apache.apache /var/www/.ssh

# echo "ssh-rsa ABCDB3NzaC1yc2EAAAABIwAAAQEAuN0ZaKuttD5/XZna/B2vMKBe1VhuWu/mBqGoYncjkVM
qaWMBRyK1qI6sE4+2k2HGdJa3/RFQu5TMo1f3nxHpvM90wUMoyuTpu2b88WeWZ+ZZxjtS8E
ML5OGsnPBXJ0FMGhuIwQekIBWXiQ7VdfBEIMITngNqzhu+X3dZJgutaJudWyM0j4FZA0b9+
tVsTJw2Kz28r4HwR6Gkcl4vXAo4e4HS8Y7WlabTVXJIkKwN1VqfC/jMohXqUS3SkzMxpS0C
gII0Nmj0PNl+F7zPhJEpsVZbBP9vIYeOKzsKVnD3HWHeeW/QAwVguW8DG1xv4edTR5bwTHS
He3u4UVazwxaSFG== apache@web1
" >> /var/www/authorized_keys

# chown apache.apache /var/www/.ssh/authorized_keys
# chmod 600 /var/www/.ssh/authorized_keys

# chgrp -R apache /var/www/html ←超重要!

【rsync用スクリプトの準備】
細かくは説明しませんが、例えば以下のようなrsync用スクリプトを用意しておきます。

#!/bin/sh
servers[0]=10.0.0.1
servers[1]=10.0.0.2
servers[2]=10.0.0.3
for server in ${servers[@]};
  rsync -avz /var/www/html ${server}:/var/www/
done

【phpプログラムの準備】
そして最後に以下のようなphpプログラムを用意すれば、やっとWEB上からrsyncを実行できるようになります。

<?php
if (@$_GET["c"], ENT_QUOTES == "r") {
    system("/home/miracle/bin/myrsync.sh");
}
?>
<a href="rsync.php?c=r">[rsync]</a>

| | Comments (0) | TrackBack (0)

October 23, 2010

パスワードなしで他のサーバにSSH接続する方法

サーバ台数が増えてくると、サーバ間移動のたびにパスワード入力が求められるのが手間になってきます。これは何とかしたいところです。そこで今回はパスワードなしで他のサーバにSSH接続する方法を記していきます。

※今回、他のサーバにログインしようとするサーバを「admin」、ログインされるサーバを「web1」、対象ユーザを「user」としておきます。

【admin側の作業】
まずは秘密鍵と公開鍵を作ります。

$ su - user
$ ssh-keygen -t rsa (とりあえず全部Enterで)

すると、秘密鍵(id_rsa)と公開鍵(id.rsa.pub)が生成されるので、公開鍵(id_rsa.pub)だけを「web1」にコピーします。

$ scp /home/user/.ssh/id_rsa.pub user@web1:/home/user/.ssh/id_rsa.pub_admin


【web1側の作業】
adminからコピーされてきた公開鍵を「authorized_keys」というファイルに追加します。

$ su - user
$ cd .ssh
$ cat id_rsa.pub_admin >> authorized_keys
$ chmod 600 authorized_keys

すると、adminからweb1にパスワードなしでSSH接続できるようになります。

[user@admin ~] $ ssh web1

Last login: Sat Oct 23 00:42:19 2010 from admin
[user@web1 ~] $


ただ、この方法だとadminからログインされる全てのサーバにadminの公開鍵を配布するのが面倒なので、私は以下のようなスクリプトをログインされる側のサーバ上で実行して済ませています。

$ echo "ssh-rsa ABCDB3NzaC5yc2EAAAABIwAAAIEA0AIDjalANyx09R5KoWCBRheartsNMNmli95CBQ1eBhzZGEQRdHqyS4I9v/5qgKMsrgruhNMBlGUUrop19ALwodHB852vWvAZG3gReu2c3CbP9qGlA0mTG7nYUCWU0ggFwq1b+HAA5wF/BqkSvWXlTe+9G0/8nmgqZMzKr81fL2u8= user@web1" > /home/user/.ssh/id_rsa.pub_admin

$ chown user.user /home/user/.ssh/id_rsa.pub_admin
$ cat /home/user/.ssh/id_rsa.pub_admin >> /home/user/.ssh/authorized_keys
$ chmod 600 /home/user/.ssh/id_rsa.pub_admin
$ chmod 600 /home/user/.ssh/authorized_keys

| | Comments (0) | TrackBack (0)

October 18, 2010

サーバリソース監視ツール「munin」をCentOSで手軽に導入する方法

サーバリソース監視をする際、MTRG、Cacti、Nagiosなどを使う場合が多いですが、SNMPベースのツールは設定が面倒です。

そこで今回はSNMPを使わないお手軽サーバリソース監視ツールとしてmuninを手軽に導入する方法について記してみたいと思います。自動インストールスクリプト付きです。


【muninを使う前に最低限知っておいたほうが良いこと】
muninでは、監視用WEBサーバに入れるパッケージ「munin」と監視対象の各ノードに入れる「munin-node」があります。ただし監視用WEBサーバには「munin」だけでなく「munin-node」も入れなければなりません。


【監視用WEBサーバでの設定】
監視用WEBサーバ上では以下のスクリプトをroot権限で実行してみてください。(myhostnameのところだけそのサーバのホスト名に直した方がよいでしょう)

cd /root/Packages rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

echo "[dag]" > /etc/yum.repos.d/dag.repo

echo "name=Dag RPM Repository for Red Hat Enterprise Linux" >> /etc/yum.repos.d/dag.repo

echo "baseurl=http://ftp.riken.jp/Linux/dag/redhat/el4/en/\$basearch/dag/" >> /etc/yum.repos.d/dag.repo

echo "gpgcheck=1" >> /etc/yum.repos.d/dag.repo

echo "gpgkey=http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt" >> /etc/yum.repos.d/dag.repo

echo "enabled=1" >> /etc/yum.repos.d/dag.repo

yum -y --enablerepo=dag install munin
yum -y --enablerepo=dag install munin-node

sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/dag.repo

mkdir /var/www/munin
mkdir /var/www/munin/htmldir

chown munin.munin /var/www/munin/htmldir
chmod 755 /var/www/munin/htmldir

# munin.conf htmldir変更(9行目)
sed -i 's/# htmldir/htmldir/' /etc/munin/munin.conf

# munin.conf ホスト名に変更(60行目)
sed -i 's/localhost/myhostname/' /etc/munin/munin.conf

# munin-node.conf ホスト名指定(29行目)
sed -i 's/#host_name x86-19.phx2.fedoraproject.org/host_name myhostname/' /etc/munin/munin-node.conf

service munin-node start
chkconfig munin-node on


【各ノードでの設定】
各ノードでは以下のスクリプトをroot権限で実行してみてください。(myhostnameのところをそのサーバのホスト名に直すことと、監視サーバのIP指定部分だけ変更します)

cd /root/Packages rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

echo "[dag]" > /etc/yum.repos.d/dag.repo

echo "name=Dag RPM Repository for Red Hat Enterprise Linux" >> /etc/yum.repos.d/dag.repo

echo "baseurl=http://ftp.riken.jp/Linux/dag/redhat/el4/en/\$basearch/dag/" >> /etc/yum.repos.d/dag.repo

echo "gpgcheck=1" >> /etc/yum.repos.d/dag.repo

echo "gpgkey=http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt" >> /etc/yum.repos.d/dag.repo

echo "enabled=1" >> /etc/yum.repos.d/dag.repo

yum -y --enablerepo=dag install munin-node

sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/dag.repo

# munin-node.conf ホスト名指定(29行目)
sed -i 's/#host_name x86-19.phx2.fedoraproject.org/myhostname/' /etc/munin/munin-node.conf

# munin-node.conf 監視サーバからのアクセス許可(36行目)
sed -i 's/127\\.0\\.0\\.1\$/192\\.168\\.0\\.11\$/' /etc/munin/munin-node.conf

service munin-node start
chkconfig munin-node on


【動作確認】
WEBブラウザー上で以下のようなURLを開いてみてください。

http://monitoring.example.com/munin/

うまくいけば以下のような画面にたどり着きます。うまくいかなかった場合はapacheの設定を見直してみてください。

Munin


【監視項目の追加削除を行なう】
muninには監視項目をプラグインで追加削除できます。プラグイン追加といってもリンクを張るだけです。ここでは試しにApacheとMySQLを監視項目に加え、かつsendmailとntpを監視項目から外してみます。各ノード側で以下のスクリプトを実行してみてください。

ln -s /usr/share/munin/plugins/apache_accesses /etc/munin/plugins/apache_accesses

ln -s /usr/share/munin/plugins/apache_processes /etc/munin/plugins/apache_processes

ln -s /usr/share/munin/plugins/apache_volume /etc/munin/plugins/apache_volume

ln -s /usr/share/munin/plugins/mysql_bytes /etc/munin/plugins/mysql_bytes

ln -s /usr/share/munin/plugins/mysql_queries /etc/munin/plugins/mysql_queries

ln -s /usr/share/munin/plugins/mysql_threads /etc/munin/plugins/mysql_threads

rm -f /etc/munin/plugins/sendmail*

rm -f /etc/munin/plugins/ntp*

ただしこのままだと各ノードのApacheが必要な情報(server-status)を吐き出してくれないので、Apacheにも設定追加を行ないます。

echo "" >> /etc/httpd/conf/httpd.conf echo "ExtendedStatus On" >> /etc/httpd/conf/httpd.conf

echo "" >> /etc/httpd/conf/httpd.conf

echo "SetHandler server-status" >> /etc/httpd/conf/httpd.conf

echo "order deny,allow" >> /etc/httpd/conf/httpd.conf

echo "deny from all" >> /etc/httpd/conf/httpd.conf

echo "allow from 127.0.0.1" >> /etc/httpd/conf/httpd.conf

echo "" >> /etc/httpd/conf/httpd.conf

sed -i 's/#LoadModule status_module modules\/mod_status.so/LoadModule status_module modules\/mod_status.so/' /etc/httpd/conf/httpd.conf

service httpd graceful


【最後に】
以上のように、muninの導入は手軽なので非常に便利ですが、かゆいところに手が届かない気がするのも事実です。ただ本家のFAQは英語だけど割と親切なので一度目を通してみることをお勧めします。例えば集計間隔を5分以外に変える場合は /etc/cron.d/munin を編集してね、みたいなことが書いてあります。

| | Comments (0) | TrackBack (0)

October 12, 2010

急いでいる人のためのMySQLのユーザ権限付与講座

MySQLでは細かいレベルの権限付与が可能ですが、大抵の場合そこまで細かいレベルの権限付与は必要ないですよね? マニュアルを読まないか、もしくはちょっとしたメモ書きを見る程度でおおよそ使い方が理解できるくらいならいいのに、といつも思います。

そこで今回は、MySQLのユーザ権限付与の中でも、とりわけよく行われる手順だけを簡単にまとめてみました。

【まず知っておいたほうが良いこと】
ユーザはmysqlデータベース内のuserテーブルに作られます。

次に例えば以下のユーザの情報を見てみると「_priv」系のカラム値が全部「Y」であることがわかります。この場合はグローバルレベル権限として全部「Y」なので、全てのテーブルに対して接続が可能となります。

mysql> select * from user where User='adminuser' \G
 
*************************** 1. row ***************************
                 Host: %
                 User: adminuser
             Password: 136b4c537575b6f1
          Select_priv: Y      ←
          Insert_priv: Y      ←
          Update_priv: Y      ←
 
~~~中略~~~
 
  Create_routine_priv: Y      ←
   Alter_routine_priv: Y      ←
     Create_user_priv: Y      ←
             ssl_type:
           ssl_cipher:
          x509_issuer:
         x509_subject:
        max_questions: 0
          max_updates: 0
      max_connections: 0
 max_user_connections: 0
1 row in set (0.00 sec)

一方、以下のユーザの情報を見てみると「_priv」系のカラム値が全部「N」であることがわかります。

mysql> select * from user where User='testuser' \G
  *************************** 1. row ***************************
                 Host: localhost
                 User: testuser
             Password: 136b4c537575b6f1
          Select_priv: N      ←
          Insert_priv: N      ←
          Update_priv: N      ←
 
~~~中略~~~
 
  Create_routine_priv: N      ←
   Alter_routine_priv: N      ←
     Create_user_priv: N      ←
             ssl_type:
           ssl_cipher:
          x509_issuer:
         x509_subject:
        max_questions: 0
          max_updates: 0
      max_connections: 0
 max_user_connections: 0
1 row in set (0.00 sec)

この場合は、別途ユーザが接続するデータベースを「db」テーブルに設定します。

mysql> select * from db where User='testuser' \G
 
*************************** 1. row ***************************
                 Host: localhost
                   Db: testdatabase
                 User: testuser
          Select_priv: Y
          Insert_priv: Y
          Update_priv: Y
 
~~~中略~~~
 
  Create_routine_priv: Y
   Alter_routine_priv: Y
         Execute_priv: Y
1 row in set (0.00 sec)

普段意識すべきはこのあたりまでだと思いますが、さらに細かい設定を検討する場合は以下もご参照下さい。

※参照:mysqlデータベース内のテーブル一覧

データベース名 説明
user グローバルレベルの権限とパスワードを管理するテーブル
db データベースレベルの権限を管理するテーブル
host(今回は考えない) dbテーブルにホスト名が指定されていない場合に適用される権限を管理するためのテーブル
tables_priv(今回は考えない) テーブルレベルの権限を管理するテーブル。テーブル内のすべてのフィールドに適用される権限について格納。
columns_priv(今回は考えない) フィールドレベルの権限を管理するテーブル。テーブル内の一つのフィールドに適用される権限について格納。

これをふまえて。


【1.管理者用ユーザを作りたい】
いわゆる何でもできる管理者用ユーザは以下の要領で作ります。

GRANT ALL ON *.* TO adminuser@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;

※MySQLにはGRANT権限というものがあります。GRANT権限とは、他のユーザに対して権限を付与することができる権限のことです。当然のことながらGRANT権限は通常管理者用ユーザにか付与しません。

IP制限をかける場合は以下の要領です。

GRANT ALL ON *.* TO adminuser@'172.16.0.0/255.255.255.0' IDENTIFIED BY 'password' WITH GRANT OPTION;


【2.一般ユーザを作りたい】
全てのデータベースにアクセスできる一般ユーザは以下の要領で作ります(WITH GRANT OPTIONがないのに注目)。ただし全てのデータベースにアクセスできる一般ユーザをGRANT ALL ON *.*で作ると、SUPER権限がつくのでinit_connectが無視されるなどの副作用があるそうです。(sh2さんご指摘ありがとうございました)

GRANT ALL ON *.* TO testuser@'%' IDENTIFIED BY 'password';

特定のデータベースにアクセスできる一般ユーザは以下の要領で作ります。

GRANT ALL ON testdatabase.* TO testuser@'%' IDENTIFIED BY 'password';

SELECT,INSERT,UPDATE,DELETEしかできない一般ユーザは以下の要領で作ります。

GRANT SELECT,INSERT,UPDATE,DELETE ON testdatabase.* TO testuser@'%' IDENTIFIED BY 'password';


【3.レプリケーション用ユーザを作りたい】
MySQLの大きな特徴であるレプリケーションを行う場合、MASTER DBに以下の要領でユーザを作ります。

GRANT REPLICATION SLAVE ON testdatabase.* TO repl@'172.16.0.0/255.255.255.0' IDENTIFIED BY 'password';

【最後に】
柔軟な権限設定ができるシステムは多いですが、概してどれも設定が複雑になるんですよね。しかし前提知識として今回の内容程度を押さえておけば、日常運用程度ではなんとかなるし、応用も利くようになるのではないでしょうか。

| | Comments (0) | TrackBack (0)

October 04, 2010

MySQLでSLAVEサーバを作る方法

今回は、いわゆるMySQLでレプリケーションを行う方法を記してみます。非常に今更感がありますが、自分にとってかゆいところに手が届く文献がなかったので、自分でも一度まとめてみようと思いました。

【MySQLにおけるレプリケーションとは】
MySQLにおけるレプリケーションとは、マスターサーバでの更新情報がほぼリアルタイムにスレーブサーバに同期化される仕組みのことを指します。

マスターサーバ上で更新が起こると、バイナリログ(更新ログとも呼ばれる)に更新情報が記録されていきます。スレーブサーバは随時マスターサーバ上の更新情報を追いかけることでマスターサーバ上のデータをスレーブサーバ上で再現していきます。

レプリケーションにはシングルマスタ構成とマルチマスタ構成があり、通常はシングルマスタ構成を使います。シングルマスタ構成は1台のマスターサーバの下に複数台のスレーブサーバがぶらさがっているイメージです。selectなどの参照系SQLコマンドはマスターサーバでもスレーブサーバでも受け付けることができますが、insert、update、deleteといった更新系SQLコマンドはマスターサーバ上で行う必要があります。万が一更新系SQLコマンドをスレーブサーバで実行するとそのスレーブサーバにデータ不整合が起きます。

一方マルチマスタ構成は、各サーバがマスタとスレーブを兼ねるというもので、どのサーバで更新系SQLコマンドを実行しても大丈夫という仕組みです。これだけ聞くとマルチマスタ構成のほうが使い勝手が良さそうですが、シングルマスタ構成と比較すると動作が不安定とのことであまり推奨されていないようです。ですので今回はマルチマスタ構成は無視し、シングルマスタ構成についてのみ記していきます。


【レプリケーションを行う手順】
MySQLでレプリケーションを行う手順はちょっと面倒くさいです。

(1) マスタサーバ上でレプリケーションを許可するスレーブサーバの権限を付与する。
(2) マスタサーバ上でバイナリログを書き出す設定を行う。
(3) マスタサーバのテーブルへの書き込みを止め、現在のバイナリログのファイル名や位置を記録する。
(4) スレーブサーバ上で、マスターサーバを参照する設定を行う。
(5) マスタサーバのデータを、新しく構築するスレーブサーバにコピーする。
(6) スレーブサーバ上で、現在のバイナリログのファイル名や位置を先ほどコピーしたデータと合わせる。
(7) マスタサーバのテーブルへの書き込みを再開する。
(8) スレーブサーバを有効にする。

といった作業が必要になります。

ところで(2)と(3)はマスターサーバからデータや位置情報を持ってきてもいいですが、他のスレーブサーバから持ってきても良いです。稼働中のマスターサーバを止めるのは大変ですが、他のスレーブサーバであれば少しは気が楽です。


【マスターサーバからデータをコピーしてくる場合の手順】

(1) マスタサーバ上でレプリケーションを許可するスレーブサーバの権限を付与する。

mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%' IDENTIFIED BY '';

もしくは接続を許可するIPを制限したい場合は以下のようになります。
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'192.168.0.0/255.255.255.0' IDENTIFIED BY '';

(2) マスタサーバ上でバイナリログを書き出す設定を行う。
/etc/my.cnfファイルに下記を追記します。

[mysqld]
log-bin
server-id=1

(3) マスタサーバを止め(もしくはテーブルへの書き込みを止めるだけでもOK)、現在のバイナリログのファイル名や位置を記録する。

mysql> FLUSH TABLES WITH READ LOCK;
mysql> show master status;
 
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
mysql-bin.000039 | 17510192 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

画面に出力された現在のバイナリログのファイル名(File)や位置(Position)をメモしておきます。

(4) スレーブサーバ上で、マスターサーバを参照する設定を行う。
スレーブサーバの/etc/my.cnfファイルに下記を追記します。(※server-idは他のマスター、スレーブで設定した数とは異なった数にする必要があります。1以上の整数が有効となります)

[mysqld]
server-id=2

(5) マスタサーバのデータを、新しく構築するスレーブサーバにコピーし、スレーブサーバ上で展開する。
マスターサーバ上で以下の手順を行う。

# cd /var/lib/
# tar cvf /tmp/mysql.tar mysql
# scp /tmp/mysql.tar username@slave.example.com:/tmp/
# rm -f /tmp/mysql.tar

そしてスレーブサーバ上で以下の手順を行う。

# service mysqld stop
# cd /var/lib
# mv mysql mysql_old
# tar xvf /tmp/mysql.tar
# rm -f /tmp/mysql.tar
# service mysqld start

(6) スレーブサーバ上で、スレーブサーバのステータスを確認します。

mysql> show slave status \G

*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 10.0.0.1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000039
Read_Master_Log_Pos: 17510192
Relay_Log_File: mysqld-relay-bin.000024
Relay_Log_Pos: 80878039
Relay_Master_Log_File: mysql-bin.000039
Slave_IO_Running: No
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 17510192
Relay_Log_Space: 80878039
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL

この中の特に以下の内容が(3)でメモした内容と一致しているか確認します。

Master_Log_File: mysql-bin.000039
Read_Master_Log_Pos: 17510192

一致していなければ、現在のバイナリログのファイル名や位置を先ほどコピーしたデータと合わせます。

mysql> CHANGE MASTER TO
MASTER_HOST='10.0.0.1',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000039',
MASTER_LOG_POS=17510192;

エラーが出たら適切に対応します。

ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log
mysql> reset slave;
の後、「CHANGE MASTER TO~」を再度実行する。


(7) マスタサーバのテーブルへの書き込みを再開する。

mysq> UNLOCK TABLES;


(8) スレーブサーバを有効にする。

mysql> START SLAVE;

そしてスレーブサーバの動作を確認します。

mysql> show slave status \G

~中略~
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
~中略~


両方ともYesであれば成功です。


【スレーブサーバからデータをコピーしてくる場合の手順】
さて、次はスレーブサーバからデータをコピーしてくる場合の手順を記します。この手順が他のホームページやブログにはなかなか載ってなかったのです。とは言っても手順はほぼ同じです。違うところだけ記していきます。

(1) マスタサーバ上でレプリケーションを許可するスレーブサーバの権限を付与する。
同じ

(2) マスタサーバ上でバイナリログを書き出す設定を行う。
同じ

(3) 他のスレーブサーバを止め、現在のバイナリログのファイル名や位置を記録する。

mysql> stop slave;
mysql> show slave status;

~中略~
Master_Log_File: mysql-bin.000039
Read_Master_Log_Pos: 17510192
~中略~


画面に出力された現在のバイナリログのファイル名(File)や位置(Position)をメモしておきます。

(4) スレーブサーバ上で、マスターサーバを参照する設定を行う。
同じ

(5) 他のスレーブサーバのデータを、新しく構築するスレーブサーバにコピーし、スレーブサーバ上で展開する。
他のスレーブサーバ上で以下の手順を行う。

# service mysqld stop
# cd /var/lib/
# tar cvf /tmp/mysql.tar mysql
# scp /tmp/mysql.tar username@slave.example.com:/tmp/
# rm -f /tmp/mysql.tar
# service mysqld start

そしてスレーブサーバ上で以下の手順を行う。

# service mysqld stop
# cd /var/lib
# mv mysql mysql_old
# tar xvf /tmp/mysql.tar
# rm -f /tmp/mysql.tar
# service mysqld start

(6) スレーブサーバ上で、現在のバイナリログのファイル名や位置を先ほどコピーしたデータと合わせる。
同じ。ただ多分この作業は必要ないです。

(7)は必要なし

(8) スレーブサーバを有効にする。
同じ


【余談】
多くのサイトではマスターサーバ1台+スレーブサーバ1台の2台構成となっていると思います。しかし予備のスレーブサーバを1台足して3台構成としておくと便利です。

もし予備のスレーブサーバあると、スレーブサーバを増強しようとしたときに、本稼働中のスレーブサーバを止めずとも増強を行うことが可能となります。またバックアップや集計といったサービスとは関係ないけれども重いDB処理を行いたいときには重宝します。

| | Comments (2) | TrackBack (0)

August 06, 2010

ソーシャルアプリのサービスを行う際に考えておくべきこと

最近「ソーシャルアプリをやることになって、コンテンツは作れるけどインフラ周りが全然わからないので助けて欲しい」という相談をよく受けるので、よい機会ですので数回に分けてノウハウを記していこうと思います。というわけで今回はソーシャルアプリのサービスを行う際に考えておくべきことを記してみたいと思います。

【初期サーバ台数を多めにしておく】
「お金が無いので最初は少ないサーバ台数でサービスインをして、ユーザ動向を見ながらサーバを増やしていきたい」と思う人も多いと思います。

しかしソーシャルアプリの場合、サービスイン直後に大量のユーザが押し寄せてサーバダウンしてしまう場合が多々あることや、サービスイン直後に慌ててサーバ増強が必要となってもそれができる余裕がない場合も多いと思うので、初期サーバ台数を多めに準備しておき、ユーザ動向を見て事後にサーバ台数を調整するのが良いと思います。

【大量のテストデータを用意する】
よく聞く事例として「テストデータがほとんどない開発サーバ上でさくさく動いていてもいざ本番サービスに投入してみるとすぐに高負荷になって落ちてしまう」というものがあります。

DBテーブルのIndex貼り忘れ程度であれば早期に対応できますが、アプリケーションの構造に関するものであればすぐに対応できずサービスダウンが頻発して苦しむことになります。本番サービスに投入する前にかならず大量のテストデータ(数百万件とか)がある環境で負荷テストしてみましょう。

【極力早めに本番サーバに載せてテストする】
本番サーバを利用すると費用が発生してしまうので、サービスイン直前ぎりぎりまで本番サーバを用意しない会社も多いと思います。しかし実際にやってみると本番サーバの設定に思ったより時間が取られる、開発環境でうまく動いていても本番環境だと何故かうまく動かず原因究明に手間取る、また本番環境にしか必要でなくて準備をすっかり忘れているものがあって慌てて準備することが出てくる(ドメイン取得、DNS登録、SSL証明書取得などなど)といったことが起こり、結果としてかなり慌ただしい状態でサービスインを迎えることなります。

サービスイン直前はいろいろなタスクが集中するので、多少お金がかかったとしても事前にできることは事前に準備しておいたほうが良いと思います。

【スケールアウトできるようにアプリケーションを開発する】
開発中は1台の開発サーバ上で開発する場合が多いでしょうから、開発中はなかなかスケールアウト構成を意識することはないかもしれません。しかしソーシャルアプリの場合、サービスイン直後にいきなり高負荷になるケースがあり、その場合サーバ増強することですぐに負荷分散できるようにしておかないととても追いつきません。

スケールアウトできるようにアプリケーションを開発しておくことはもちろんのこと、サービスインの前に本当にスケールアウトできるかテストも行っておきましょう。

【マルチプラットフォームに対応できるようにシステムを構成する】
オープン当初は特定プラットフォーム上だけでサービスを行うこと前提だったとして、ビジネス判断として急遽他のプラットフォーム上でもサービスを行うことになるかもしれません。

そのようなときのために、まずアプリケーション側ではコンテンツ部分とプラットフォーム依存部分を完全に切り離しておくことで、プラットフォームを変える場合その部分だけを入れ替えることでプラットフォームを変えられる設計にしておくことが重要となります。

またシステム側では、プラットフォームごとにサーバを別に立てられれば理想的ですが、費用面でそれが叶わない場合同じサーバに同居せざるを得ないことがあるかもしれません。そんな場面を想定して予めそのようなことができるシステム構成を考えておきましょう。

【まとめ】
今回記したことは、つまり常に先の先を考えて事前に準備しておくということに尽きるのではないかと思います。多分今回記したことは「そんなの当たり前じゃないか」と思われる方も多いと思います。しかし実際やってみると、その当たり前のことが目の前のタスクに忙殺されて当たり前でなくなってしまうということが本当によくあります。

つまり「先にできることは先にやっておく」というのが最大のノウハウなのかもしれません。

| | Comments (0) | TrackBack (0)

«オープンソースソフトウェアのからくりとしくみ