こんにちは、

 

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

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

 

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

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

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

 

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

 

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

 

 

対する、ラグは、

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で収集するようにしました。

 

 

今まさに攻撃を受けているサーバが一目でわかる世界地図がありました。 http://map.honeycloud.net/ test.gif 赤丸になっているところが攻撃を受けているサーバの場所です。 日本はちょろちょろと攻撃を受けているようです。 一番多いのは台湾でしょうか。なぜか突出して、赤丸が点滅しつづけています。 どこから攻撃されているのやら・・・。
レンタルサーバ界の老舗「ファーストサーバ」でデータ消失のトラブルがあったようです。 http://support.fsv.jp/info/nw20120620_01.html 障害お知らせページの更新時間を見ると、徹夜で復旧作業しているようですが、 解決の目処は立っていないようです。 ユーザの中には「データが無くなれば会社が潰れる」といった切羽詰った人もいるようです。 (そんな大事なデータのバックアップを取っていなかったのだろうか・・・) http://togetter.com/li/324748 恐ろしい・・・。
さくらインターネットのクラウドサービスが11月にオープンしていました。 http://cloud.sakura.ad.jp/ 最低料金は月額2,500円から。(1CPU、メモリ:2GB) 同じクラウドのAmazon EC2で同スペックを使おうとすれば3倍くらい高くなるので、結構安い値段設定です。 料金体系もシンプル。 レンタルサーバやVPSとの違いはスケールアウトができることでしょうか。 アクセスが増える時期は、サーバのスペックを簡単に上げることができるようです。 サーバーの冗長化もできますしね。
レンタルサーバ(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

プロフィール

愛知県名古屋市にあるジャスウィルで働く社員です。
ジャスウィルは大学事業に特化したシステムを提案しています。『大学向け事務・教務統合パッケージ―TriR Campus』を開発しています。