2013年1月30日水曜日

はじめてのAWSでわかったこと、わからないこと -1-

機会があって、初めてAWSを使って仕事をしました。
とある公開Web系サービスの構築です。

公開系自体、あまり経験がないので色々な意味でいい勉強になりました。
今回は、AWS環境ではまった内容、わからなかった内容、未だに謎な項目を上げておきたいと思います。

せっかくですので発生した順に並べます。

CDP(Cloud Design Pattern)を、どうやって実装すればいいの?

やりたい事、簡単な構成を書き出し、CDPの「NFS Sharingパターン」が近いという事で認識が一致しました。
NFSサーバ上にソースを配置してとりあえず2台のWebサーバ+NFSをELBでバランスさせることとなりました。基本的な構成だよねって事でインスタンスをデプロイ。

ん?でも・・・これって。
インスタンス同士はネットワーク的に、どういう風に接続されてるんだろう。

IPアドレスもバラバラだし。どうなってるんだろう。全くわかりませんでした。これらがネットワーク的につながっている事はPingを発射してわかりましたが、そもそもこのままでいいの?単純な疑問でモヤモヤとしましたが、ネットワークを好きに設計できないEC2はそんなもんだという事で納得しました。

EC2環境で構成を始めたけど、NFSでパフォーマンスが出ない

公開系サービスで凝った事するんじゃないからEC2でいいんじゃない?という満場一致の賛成意見によりEC2環境で構築を行いました。
NFSの構成も特にハマる事なく完了。でも、いざソースを配置してELB経由で動かしてみると・・・

「遅い・・・」
Webサーバのローカルにソースを置いた状態よりも遅い。明らかに遅い。
そもそも構成的にNFS接続用のネットワークを分離していないため、後々レスポンスの問題は発生するだろうと思ってはいました。
でも、今の環境はWebサーバ2台、しかも1台だけでの接続でこんなに遅いなんて!('A`)

まず、WebサーバとNFSサーバ間のネットワーク的な遅延を考えました。この間のPingによる折り返し応答は2-3ms。LANという意識としては遅延が大きいです。
遅い原因はこれだろうと考えました。

でも、解決する方法があるのだろうか?そもそもEC2環境に実装した時にIPアドレスはバラバラだしネットワーク的にどうなっているのかも理解できていないままでした。
そこでVPC環境でサブネットを切り、そこにWebサーバとNFSサーバを配置して、同一のサブネットでどうなるかを実験してみました。
すると、Pingの折り返しは0.5ms以下となりました。
これで問題は解消されるはずだと判断し、VPC環境に同じ構成を構築しました。
その結果

若干のレスポンス解消は見られたものの、根本的な解決にはいたっていませんでした。


NFSの構成自体に慣れてないため、根本的な過ちを犯している可能性もあります。
Twitterにて状況をつぶやいていると、色々な方から助言をいただくことができました。ソースを作っているチームに話を聞いてみるとNFS上にはソースを置いているだけでなく様々なテンポラリも配置していることが分かりました。試しにテンポラリをWebサーバのローカルに吐くとレスポンスの悪化は見られません。
以上の事から、テンポラリを吐くタイミングでレスポンスが悪化しているのではないかと想定され、これについてNFSマウントオプションでasyncを設定してみる事で回避できるのではないか?とアドバイスを受けました。
結果的にはこれが正解でした。NFSクライアント側のマウントコマンドをsync→asyncとすると良好なレスポンスを得られるようになりました。

EC2環境とVPC環境の違いを舐めきってました。ただ単にサブネットが自由につくれるぐらいの認識しかありませんでした。
VPCさん、ゴメンナサイ。

次回に続く

2013年1月4日金曜日

Linux関連Tips (基本的な事)

Linuxで運用するにあたって操作に慣れる必要があるので必要な事のメモ。
AWSでの運用を考慮して。


■sudo su - で rootに昇格できるのはec2-userだけ。
これを変更するには
 1)ユーザを作成
 2)ユーザをWheelグループに追加

■wheelグループに所属しているユーザ一覧の表示
grep wheel /etc/group

■ユーザ一覧の表示
cat /etc/passwd

■ユーザの作成
adduser <ユーザ名>

■作ったユーザをwheelグループに所属させる
usermod -G wheel <ユーザ名>