ヤマ

こんにちは、

 

先日、リビングに敷くためのラグを

パルコの雑貨屋さんで購入しました。

 

インドでの手作りラグは、機械で作るのとは違い

見た目も決して綺麗に整っているわけではないですが、

シンプルで手作り感もあり、気に入っています。

 

で、リビングに置いたわけですよ。

 

ルンバさんの居る、リビングにね。

 

 

対する、ラグは、

http://honda-kagu.net/shop/item/honda/picture/goods/10222_1_expand.jpg

 

こんなイメージのもので、

四隅に、ヒラヒラがついているわけですよ。。。。

 

 

完全に、忘れてましたね。

ルンバさんのことを。

 

で、戦いの結果は、

 

ルンバ:(#`皿´)

ラグ:(_TдT)

 

こんな感じでした、、、ヤマです。

 

 

 

本題

 

 

ELB(AWSサービスの一つ、バランサ)

を一つ構えて、配下にEC2インスタンスを2台設置しました。

 

設置当初は、何も考えて無かったのですが、

ログの扱いをすっかり忘れていたことに、気づきました。

 

ログと言っても、WEBサーバのアクセスログではなく、

アプリから吐き出すログです。

 

セッションはDBに持っており、

どちらのサーバに振られてもいい様になっています。

 

この状況で、以下の解決方法を試してみました。

 

1)ログ出力先をS3にする

 サーバ1もサーバ2も、ログの出力先を同じS3バケットにすることで解決しようとしました。

 施策としては非常に簡単です。

 EC2からS3の特定バケットをマウントするだけ。

 

 結果

  S3へのアクセスが遅すぎて使えない

  実用に耐えられないほどの遅さでしたので、断念。。。

 

 

2)Cloudwatch Logsを利用する

 CloudWatch LogsのAgentをインストールして、定期的にログをCloudWatch Logsへ上げる。

 最初から素直に、この方法にしておけばよかったです。

 

 一つ懸念としては、複数EC2インスタンスから、同じロググループ、ログストリームに

 アップした事がなかったので、実現できるか心配だったこと。

 

 結果

  ほぼリアルタイムで閲覧でき、大満足

 

  各種ログをほぼリアルタイムで同期でき、サーバへアクセスすることなく、

  CloudWatch Logsコンソール上でログを閲覧できるので、かなり役立っています。

 

 

手順を簡単に書いておきます。

前回書いた記事も参考に。「CloudWatch Logs

 

 

1)IAM Roleを設定

 

CloudWatch Logsへのアクセス権限を持つIAM Policyを作り、

それを特定のIAM Roleに割り当てます。

で、そのIAM RoleをEC2インスタンスに割り当てます。

 

2)スクリプト入手&実行

https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py

 

実行権限を与えて、pythonで実行してください。

python ./awslogs-agent-setup.py –region ap-northeast-1

 

 

3)設定ファイル編集

/var/awslogs/etc/awslogs.conf

を良い感じに編集してください。

 

 

この設定を、2つのサーバ(EC2インスタンス上)で設定して、

それぞれのサーバのログを、CloudWatch Logsで収集するようにしました。

 

 

other

今まさに攻撃を受けているサーバが一目でわかる世界地図がありました。
http://map.honeycloud.net/
test.gif
赤丸になっているところが攻撃を受けているサーバの場所です。
日本はちょろちょろと攻撃を受けているようです。
一番多いのは台湾でしょうか。なぜか突出して、赤丸が点滅しつづけています。
どこから攻撃されているのやら・・・。

【カテゴリ】サーバー構築・運用
other

レンタルサーバ界の老舗「ファーストサーバ」でデータ消失のトラブルがあったようです。
http://support.fsv.jp/info/nw20120620_01.html
障害お知らせページの更新時間を見ると、徹夜で復旧作業しているようですが、
解決の目処は立っていないようです。
ユーザの中には「データが無くなれば会社が潰れる」といった切羽詰った人もいるようです。
(そんな大事なデータのバックアップを取っていなかったのだろうか・・・)
http://togetter.com/li/324748
恐ろしい・・・。

【カテゴリ】サーバー構築・運用
other

さくらインターネットのクラウドサービスが11月にオープンしていました。
http://cloud.sakura.ad.jp/
最低料金は月額2,500円から。(1CPU、メモリ:2GB)
同じクラウドのAmazon EC2で同スペックを使おうとすれば3倍くらい高くなるので、結構安い値段設定です。
料金体系もシンプル。
レンタルサーバやVPSとの違いはスケールアウトができることでしょうか。
アクセスが増える時期は、サーバのスペックを簡単に上げることができるようです。
サーバーの冗長化もできますしね。

【カテゴリ】サーバー構築・運用
other
レンタルサーバ(VPS)のCPUやメモリを調べたい時用のメモです。

CPUスペック確認

cat /proc/cpuinfo
結果
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz
stepping        : 10
cpu MHz         : 3164.576
cache size      : 6144 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx smx est tm2 cx16 xtpr lahf_lm
bogomips        : 6329.15

メモリスペック確認

cat /proc/meminfo

結果

MemTotal:      2064896 kB
MemFree:        726404 kB
Buffers:        181152 kB
Cached:         653900 kB
SwapCached:          0 kB
Active:         794536 kB
Inactive:       343608 kB
HighTotal:     1168960 kB
HighFree:       201780 kB
LowTotal:       895936 kB
LowFree:        524624 kB
SwapTotal:     4128760 kB
SwapFree:      4128760 kB
Dirty:             320 kB
Writeback:           0 kB
AnonPages:      303160 kB
Mapped:          67264 kB
Slab:            55660 kB
PageTables:       3988 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   5161208 kB
Committed_AS:   744956 kB
VmallocTotal:   114680 kB
VmallocUsed:      6968 kB
VmallocChunk:   107124 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     4096 kB
【カテゴリ】サーバー構築・運用
other
CentOS(Linux)のバージョンを確認する方法をすぐに忘れてしまう人が多い(ある調査によると1人中1人が忘れている!)ようなのでブログに書いておきますね。
SSHでログイン後、以下のコマンドを打ち込みます。
#バージョン確認コマンド
cat /etc/redhat-release
#結果
CentOS release 5.4 (Final)

#アーキテクチャ確認コマンド(OSが32bit, 64bitとちらなのか)
arch
#結果(64bitの場合)
X86_64
#結果(32bitの場合)
i686
お店に売っているパソコン(Windows)は32bitが多いですが、WEBサーバやDBサーバには、基本的に64bitを使用します。
(32bitでは積めるメモリに限界があるため)
WEBサーバに32bitを入れてしまい、64bitに再インストールなんてこともよくある話です。
しっかりしてくださいkawaguc●iさん
【カテゴリ】サーバー構築・運用
【タグ】
other
若干鮮度の悪い情報ですが、日本データセンターがAmazonEC2で開設しました。
(これまで、日本から一番近いデータセンターは、シンガポールだった)
「データセンターなんてどこでもいいんじゃない?」と思われるかもしれませんが、海外にデータセンターがあるということは、何かとシステム開発の足かせになります。
その足かせは大きく2つありました。
1.ネットワーク遅延
2.セキュリティ
1.ネットワーク遅延
通信を行う端末間の物理的な距離が長くなると、ネットワーク遅延が問題となります。
日本からAmazonEC2の海外サーバに置いてあるWEBページを見ると、モッサリ感満載です。
またWEB管理者の場合、SSH等を使用して接続しますが、サーバからの反応は遅く、10文字ぐらい打っても空白で、数秒したらズダダダっと文字が表示されるような状態です。
2.セキュリティ
データを海外に持つことをよく思わない企業は、意外と多いです。
(セキュリティポリシーなどで、「データ保管場所は日本国内に限る」と明記している企業もあります)
特に個人情報等の重要データは自社内、大目に見て国内のデータセンターという場合が多いのではないでしょうか。
事実、海外データセンターでは、人為的な情報漏洩だけではなく、日本の法律外となるがために起こるデータ流出(事件等の捜査でデータが没収される)などもあります。
これら2つが足かせとなり、お客様には勧めづらいAmazonEC2でしたが、解消されれば、今後の主力サーバになっていくのではないかと思います。
【カテゴリ】サーバー構築・運用
other

最近はJAVAの案件を担当していますが、ハマったことがあったのでメモします。

ハマった内容は、ソフトウェア開発でよくある文字化けです。
しかも、開発環境ではうまくいくけど、本番環境でうまくいかないというお決まり。

具体的には、javaのグラフ生成ライブラリ「JChart」を使用し、グラフを表示すると
目盛りの部分「6月、7月」などが「□□□□□□」に文字化けしてしまいます。

ネットでJChartの文字化けを検索すると、悩んだ方が多いようで色々と解決方法がのっていました。
でも、どれをやってもうまくいかない・・・。

まさか日本語フォントがサーバに入っていないのでは・・・。

早速yumで日本語フォントをインストールすると、グラフに日本語が表示されました。

yum install fonts-ja* ttfonts-ja*

原因が分かると単純なことでしたが、なかなか思いどうりにはいかないです。

画像に文字入れする場合は、日本語フォントが入っているか確認する。

other

Amazon Web Serviceで1年間の無料サービスが開始された。
無料となる期間は2010年11月1日~2011年11月1日。

ただし、以下の制約があります。
・750時間分の仮想サーバ(EC2 Microインスタンス)
・10 GB/月の仮想外部ディスク(EBS)、
 1 GBのスナップショットストレージ(EBSのバックアップ)、
 100万回のI/Oリクエスト
・750時間のロードバランサ(ELB)、15 GBのデータ転送量
・5 GB/月の仮想ストレージ(S3)と、2 万回のGETリクエスト、2 万回のPUTリクエスト
・15 GBのインターネットデータ送信、15 GBのインターネットデータ受信
・10 万回のAmazon SQSリクエスト
・10 万回のAmazon SNSリクエストと、10 万回のHTTPメッセージと1000回のemailメッセージ
・25時間のAmazon SimpleDBのマシン容量と、1 GBのストレージ

簡単に要約すると、無料OSのLinuxで一番スペックが低いMicroインスタンスなら、
1年間無料になるということみたいです。

詳しくは下記サイトをご覧ください。
無料のクラウドリソース登場

そんな中、弊社でもAmazonEC2(クラウド)を使用してみようという話になったので、その手順をメモします。

まずAWS(Amazon Web Service)のアカウントを取得しなければいけません。
2010年11月現在、日本語での申込ができず英語サイトでの申込となります。

英語が苦手な場合は、下記サイトで新規アカウント登録の手順を確認してください。
AWSアカウントの新規登録

AWSのアカウント登録後、さっそくサーバインスタンスを立ち上げます。

まず、AWSのコントロール画面を開きます。
トップ画面の上部にある「AWS Management Consoleを利用する」をクリック。

a2.gif

次に「Amazon EC2」タブをクリックし、「Launch Instance」ボタンをクリックします。

a1.gif

ポップアップウィンドウが表示されるので、サーバのOSを選択します。
OSは、AMIと呼ばれるOSイメージを選択しマウントすることにより、

サーバを立ち上げることができます。
このAMIは自分で作ることもできますが、Amazonが作ったAMIや他の人が作って公開している
AMIがあるため、まずはそれを利用します。
今回はCentOS5.4の64bitかつ、インストールされているアプリケーションを削ってある
ライト版を選ぶことにします。
「Community AMIs」タブをクリックし、「RightImage」と入力し、Platformをクリックしてソートします。
CentOS5.4の一番新しいバージョンの「Select」ボタンをクリックします。
今回は「411009282317/RightImage_CentOS_5.4_x64_v5.5.9_EBS」を選択しました。
※注意点として、名前にEBSと付いたAMIを選択します。
※EBSについてはgoogle先生で調べてください。
a4.gif
次にサーバのスペックを選択します。
今回は一番安いMicroを選択しました。
a5.gif
あとは下記サイトに詳しくのっているので参照ください。
【カテゴリ】サーバー構築・運用
【タグ】
other

最近、サーバ構築系の仕事が多いので、自宅での検証用にネットブックを購入し、
CentOSをインスコしてシコシコいじくってます。
PB218734.JPG

ネットブックは、スペックが低いですが個人的なLinuxの検証用には最適のマシンです。
・初期費用が安い(3万くらい)。
・維持費が格安(電気代が1ヶ月つけっぱなしで700円くらい)。
・静か(ファンやハードディスクの音がほとんど無い)。

そんな中、MySQLを使った仕事がはじまるかもしれないので、色々とイジくりまわしてみました。

その中で感じたのが、データ件数が多くなると(10万件以上)、SQLでのデータ検索が非常に重くなる・・・。

オプティマイザの実行計画を見てみると、どうもテーブル結合するときにテーブルをフルスキャンしている。
インデックスを適切に貼っても改善されないのでネットで調べてみると、どうもMySQLはオプティマイザの性能があまりよくないようです。

現在MySQLの正式リリース版はバージョン5.1(2010年11月20日)ですが、
開発バージョンのMySQL5.5で、かなりオプティマイザが改善されているという情報があったのでインスコしてみたのでメモします。

CentOSはパッケージ管理に「yum」を使用できますので、これを利用しインスコします。

まず、yumのデフォルトリポジトリではMySQL5.5をインスコできないので、
remiリポジトリを使いインスコする準備をします。

①remiリポジトリの情報をダウンロードし、RPMにインスコ。

wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm 
wget http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
rpm -Uvh epel-release-5-4.noarch.rpm remi-release-5.rpm

②remiリポジトリの設定ファイルが出きるので、編集する。

vi /etc/yum.repos.d/remi.repo
priority=1
※ファイルの一番下に追加

③ダンプファイルで、既存のデータを保存しておく。

mysqldump データベース名 -u root -pパスワード --opt  > ダンプファイル名

④既存のMySQLを削除

yum remove mysql mysql-server mysql-libs

⑤既存のデータファイルが残っているので、削除(リネームして一応取っておく)

mv mysql _mysql
※既存のデータファイルが残したままインスコできますが、データのストレージが違うためか、エラーが頻発し、悩むことになるので消しましょう。

⑥MySQL5.5をインスコ。

yum --enablerepo=remi-test install mysql mysql-server
yum --enablerepo=remi install  mysqlclient15
※libmysqlclient15が無いとエラーになったら、まず上記をインスコする。

⑦正常インスコ後、MySQLを起動。

/etc/init.d/mysqld start

⑧MySQLにログイン。

mysql -u root -p
※パスワードがまだ設定されていないので、パスワード入力は何も入力せずにエンター

⑨ログイン後、バージョン情報が表示されるので5.5になっているか確認する。

Server version: 5.5.7-rc MySQL Community Serve

⑩一度、MySQLをログアウトし、以前のデータをリストアする(完了)。

exit;
mysql -u root -p データベース名 < ダンプファイル名
※データベースはリストア前に手動で作っておく。

⑪その他(外部からMySQL接続できるように、ユーザ作成)。

GRANT ALL PRIVILEGES ON *.* TO ユーザ名@'%' IDENTIFIED BY 'パスワード' WITH GRANT OPTION;

⑫その他(統計情報を再構築)。

mysqlcheck --analyze -optimize --database データベース名 -u root -p
※データを大量にINSERT、DELETEしているとオプティマイザが正しく動作しなくなるので、適度に統計を取りなおす。

MySQLインスコ後、問題のSQLは爆速になりました。
実行計画で、正しくインデックスが使用されているのも確認。

MySQL5.1でもJOIN句の変わりに、STRAIGHT_JOIN句を書くと、デーブルを結合する順番を指定できるので、適切なインデックスを使用することは可能です。
ですが、運用が始まるとデータ件数が変わり、思ったとおりにインデックスが使用されなくなることも考えられるかと思います。
そうなると遅くなるたびに、SQLを書き換えることになり現実的ではありません。

やっぱりオプティマイザが正しくインデックスを使用してくれるのが、一番楽です。

ただ、MySQL5.5は2010年11月時点では、開発バージョンなので、お客様に納品するシステムでは、正式バージョンの5.1を使用することになりそうです。

早く、5.5が正式リリースされることを祈るまうす。

プロフィール

愛知県名古屋市にあるジャスウィルで働く社員です。

ジャスウィルは大学事業に特化したシステムを提案しています。『大学向け事務・教務統合パッケージ―TriR Campus』を開発しています。


Facebookページでは、イベントや普段の社員の様子を公開中♪
ぜひご覧ください☆

過去一年の月別記事 全て表示