« April 2010 | Main | July 2010 »

May 31, 2010

USBメモリにバックアップデータを格納する方法

過去にHDD障害によるデータ消失を何度も経験しているため、バックアップには多少神経質になっているところがあります。かといって面倒くさいのはもっと嫌。そこで考えたのは、Linuxが動いているマシンにUSBメモリを突っ込んでそこにバックアップデータを流し込む方法です。こうしておけばいざHDDが壊れてもUSBメモリだけ引っこ抜き他のマシンにマウントするだけですぐにデータを移行できるので楽ちんです。

今回はそんなテーマで記してみます。(root権限でお試しください)

【USBメモリをマウントする方法】
まずはUSBメモリをマウントさせなければなりません。USBメモリをマシンに突っ込み、「# dmesg」とすると、「sdb1」のような感じのものが出てくると思います。これを覚えておき

# mkdir /mnt/extdisk
# mount -t vfat /dev/sdb1 /mnt/extdisk

とするとUSBメモリが見えるようになります。(# ls /mnt/extdisk等)

ただし一時的にマウントしただけだとリブートしたら消えてしまいますので/etc/fstabに下記を追加します。

/dev/sdb1 /mnt/extdisk vfat defaults 0 0

これでUSBメモリの準備はOKです。


【バックアップ用のスクリプトを作る】
次にバックアップ用のスクリプトを作ります。今回は/var/www/html配下のファイルとMySQL上にあるデータベースをバックアップ対象とします。

下記のスクリプトを仮に/root/bin/backup.shという名前で保存したとします。

#!/bin/sh

#-------------------
# backup script
#-------------------

TARGET_DIR=/var/www/html

SAVE_NAME=www_backup`date +%Y%m%d_%H%M`
BACKUP_DIR=/mnt/extdisk
SAVE_DIR=$BACKUP_DIR/$SAVE_NAME

TMP_DIR=/tmp
TMP_SAVE_DIR=$TMP_DIR/$SAVE_NAME

mkdir $TMP_SAVE_DIR

# sources
cp -r $TARGET_DIR $TMP_SAVE_DIR

# database
/usr/bin/mysqldump -R --skip-lock-tables -uUSERNAME -p'PASSWORD' DATABASE_NAME > $TMP_SAVE_DIR/dbdump.sql

# compress
cd $TMP_DIR
tar -cf $SAVE_NAME.tar $SAVE_NAME

rm -rf $TMP_SAVE_DIR

gzip $SAVE_NAME.tar

mv $SAVE_NAME.tar.gz $SAVE_DIR.tar.gz

そして「# crontab -e」でcrontabに登録します。

0 2 * * * /root/bin/backup.sh 1 > /dev/null

この例では毎晩2:00にバッチが回るようになります。


【最後に】
USBメモリの値段が劇的に下がっている現在、皆なんでこの方法でバックアップを取らないのだろうと思うくらい非常に手軽です。ぜひ皆さんもお試しください。


※追記(2010/6/20)
古いバックアップデータを自動削除するようにしたいというリクエストをいただきました。これは以下のような記述を追加すれば実現可能です。

find /mnt/extdisk -maxdepth 1 -type f *.tar.gz -atime +6 -exec rm -f {} \;

| | Comments (1) | TrackBack (0)

May 07, 2010

ソーシャルアプリ専用ホスティングサービスをまとめてみました

他の人から頼まれたので、ソーシャルアプリ専用ホスティングサービスをざっと調べてみました。せっかく調べたのでブログでも公開してみます(注:今回は単なるクラウドや普通のホスティングなどのサービスは対象外)。
※他にもあったらぜひ教えてください


■GMO「GMOアプリクラウド」
ソーシャルアプリに必要なものがパッケージ化されていて大変便利。個人的に一番のおすすめ。
・初期費用無料
・準備期間完全無料、さらに公開後も4日間20台無料
・アクセス解析ツール無料
・ロードバランサー無料
・WEBコントロールパネルからサーバの増減が可能
・最短2日でサーバやインフラ用意可能

■ライブドア「DATAHOTEL for Social」
単なるホスティングだけでなく日常運用・監視まで対応してくれるので、インフラ担当エンジニアが全くいない会社には便利かも。
・初期費用無料
・月額課金開始はアプリのサービスインから(引渡し日1ヶ月以内)
・最短1日でサーバやインフラ用意可能
・有償コンサルティグサービスあり
・参考月額費用90万円(フルマネージドサービス付き)

■ライブドア「DATAHOTEL P.O.I for Social」
ライブドア「DATAHOTEL for Social」の安価版。よくわかりませんが、どうもWEBサーバは仮想化サーバ、DBサーバは実サーバにすることで安くしているような気がします。
・初期費用無料
・月額課金開始はアプリのサービスインから(引渡し日1ヶ月以内)
・最短1日でサーバやインフラ用意可能
・有償コンサルティグサービスあり
・参考月額費用30万円(サーバ5台、フルマネージドサービス付き)

■KLab「DSAS Hosting for Social」
・レベニューシェア型(初期費用無料)と従量課金型(初期費用あり)の2種類

■トリグラフ・インフラストラクチャー「Social Application Stock」
・レベニューシェア型(初期費用無料)と従量課金型(初期費用あり)の2種類

■ビットアイル(GMO系)「ソーシャルアプリケーションパッケージ」
・初期費用無料
・最短2週間でサーバやインフラ用意可能、追加サーバは3営業日
・基本パッケージの最低利用期間は3ヶ月
・基本パッケージにはシングル構成と冗長構成がある
・参考月額費用100万円(シングル構成、サーバ10台+FW+NW機器)

■アイ・ティー・コンサルティング「ソーシャルアプリ向けホスティングサービス」
・初期費用無料
・最短2週間でサーバやインフラ用意可能、追加サーバは3営業日
・最低利用期間は2ヶ月
・参考月額費用70万円(サーバ10台+FW+NW機器)

■ハートレイルズ「OpenSocial Host」
・フリープランとビジネスプランがある。
・フリープランでは広告表示が義務付けられる他、転送容量制限等がある。
・ビジネスプランではデータベース使用量、API使用回数、ファイル使用量、およびファイル転送量の従量課金。



※以下お願いというか宣伝というか。

最近たまに私個人宛にソーシャルアプリのインフラ関連でご相談をいただくのですが、結構手間がかかりますので今後有償でお引き受けすることにしました。(私or私の責任で別の人が対応)

1回5万円
(メールやチャットで要件整理~業者選定~申請書類作成代行~サーバ初期設定~サービス開始まで)

| | Comments (0) | TrackBack (0)

May 06, 2010

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

前回のエントリーからの続きです。今回は大規模システムと小規模システムでの負荷対策に対する考え方の違いについて述べてみたいと思います。

【小規模システムではパフォーマンスチューニング力が重要】
小規模システムではハードウェアリソースの追加が費用面で難しいので、負荷対策においては限られたハードウェアリソースを最大限活かす方向で頑張ることになります。つまりアクセスが増えてきた場合はパフォーマンスチューニングすることで乗り切ることとなります。

例えば1台のサーバ上にApacheとJAVAとTomcatとMySQLを入れた環境があったとします。最初の頃は特に問題がなくても、徐々にアクセス数が増えてだんだん応答速度が落ちてきたときは、ソースコードを改良したり、オープンソースの各パラメータを調整したり、もしくはmemcachedを入れて繰り返し問い合せられるものをメモリ上にキャッシュさせたりといった、パフォーマンスチューニングに労力を注ぐことになります。

【大規模システムではスケーラビリティの高いシステム設計が重要】
一方、大規模システムではアクセス数増大をパフォーマンスチューニングだけで乗り切るのが不可能な場合がほとんどなので、負荷対策においてはハードウェアリソースを増強することで対処することになります。つまりシステム設計の上で、ハードウェアリソースを増強することで容易にシステムキャパシティを増やすスケーラビリティの高いシステム設計が重要となります。

例えばWEBサーバ10台でアクセスをさばいている環境があったとします。ある日TV広告を打つことになりました。TV広告を打った直後アクセスが確実に100倍以上になることが予想されたときは、早急にハードウェアリソースを増やして乗り越えなければなりません。サーバを追加する、アクセス数が多すぎてキャパシティを超えた時のことを考えてSorryサーバに飛ぶようにネットワークを調整する、画像などの静的コンテンツはCDNなどを利用する、もしくはこの機会にクラウド環境に切り替えるなどなど、矢継ぎ早に作戦を練って対処していかなければなりません。

【結論】
同じインフラエンジニアであっても大規模システムを扱うか小規模システムを扱うかでこれだけ負荷対策が異なることがおわかりいただけたかと思います。

前回のエントリーでも書きましたが、大規模システムを扱う場合は技術力云々よりもとにかく次々と意思決定していくことがとても重要となります。次々と意思決定するためには幅広い技術的知識や経験がとても重要となります。インフラエンジニアを志したからにはそれらを身に付けつつ、是非ともいつかは大規模システムに挑戦してみていただければと思います。

| | Comments (0) | TrackBack (0)

May 03, 2010

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

「小規模システムの構築」と比べて「大規模システムの構築」はなんだかものすごく高度で難しい印象を持つかもしれません。しかしどちらが高度で難しいかと問われればそれぞれ作業内容が大きく異なりどちらとも言えない気がします。そこで今回は両者どのように作業内容が違うためどちらが高度で難しいと言い切れないのかを考えてみたいと思います。

【小規模システムは全てを自分でやらないといけないので難しい】
小規模サイトの場合は担当者が自分一人しかいないということがよくあります。しかし例え小規模であっても押さえなければならないポイントは大規模サイトのそれとは大きく差がないと言えるため、実は広く深い知識と経験が必要なのが小規模システムの構築と言えそうです。

例えばいわゆる一般的な2階層式(=WEB+DB)WEBサイトをリリースするとします。この場合に必要な知識は例えばサーバ、OS、WEBサーバ、セキュリティ、ネットワーク、SSL、メールなどなど。これらを一人だけで一通りこなすというのはある意味高度で難しいと言えます。

【大規模システムは全体の構成を考えるのが難しい】
一方、大規模サイトの場合は担当者が数名でかつ予算がそれなりに用意されている場合が多いです。この場合自分はある特定の部分だけ担当すればよいので気が楽です。また手厚いベンダーのサポートを受ける予算があるので、何か問題に突き当たったときにいちいち検索して調べなくてもベンダーに連絡しておけばすぐに回答が帰ってきます。このことは実は自分自身が高度な技術を持っていなくてもある程度なんとかなってしまうことを意味します。

ただし大規模システムの場合、システムを構成する要素が多くて何をどう組み合わせるのか設計するのが難しいと言えます。また小規模システムと比べて購入するハードウェアが非常に高価な場合が多いので、何を購入するかの選定が非常に難しいです。例えばネットワーク機器を購入する場合、メーカー毎にどのような違いがあり、どのような機能差があり、パフォーマンスはどうで、実績はどうで、拡張性はどうで・・・等々、気にすべき要素が多くて非常に悩みます。

【結論】
思うに、小規模システムの構築は職人技の世界なのに対して大規模システムの構築は意思決定の世界な気がします。つまり、小規模システムの構築では担当者の知識と経験が全てなのに対して、大規模システムの構築では担当者を誰にしてどのベンダーを選定してどの機器を採用して等々、大半の時間を選ぶという作業に費やすことになります。

この機会にインフラエンジニアである皆さんがどちらの世界を目指そうとしているのかをちょっと考えてみても良いかもしれません。

| | Comments (0) | TrackBack (0)

« April 2010 | Main | July 2010 »