2013-03-13

サーバ初心者Webサービスを公開するうえで考えたこと

だって自作Webサービス公開しました

http://www.radiosonde.net/

これまで他の人に用意してもらったサーバ自分プログラムを動かしたことはありましたが

自分自身で一からサーバをセットアップしたことはほとんどなかったので、いろいろとハマりました。

作業を進める上で困ったり考えたりしたことを書いていきます

ちなみにサーバ自体はさくらのクラウドOSにはCentOSを使用しているので、それ前提のお話になります

SSHファイヤーウォールの設定

最初サーバを起動してから速やかにSSHファイヤーウォールの設定を変更しました。

はてブなんかでも定期的に話題になっているのでおなじみですね。

SSHポートを22以外の別のポートに変更する

rootによるリモートログインを禁止する

パスワードログインを禁止し、鍵認証有効にする

・念のためrootパスワードを潰しておく

SSHHTTP(S)など、どうしても公開しなければならないポート以外は遮断する

SSHポートについてIP制限が行えるならば尚良い

さらっと書きましたが、設定をミスって自分自身もログインできなくなり、何度かOSの再インストールを繰り返しています

から気付いた事ですが、さくらのクラウドではクラウド管理画面のリモートスクリーン経由でローカルログインできるので

別にOSインストールしなくてもiptablesの設定を変更できたんですよね...

逆に言うといくらファイヤーウォールとSSHを設定しても管理画面にパスワードログイン環境が残ってしまうので

パスワード管理には引き続きしっかり気を使う必要がある。ということでもあります


Webアプリの動作が重い

httpd,php,mySQL,memcachedなど必要サービスインストール、設定し

作成したWebアプリプログラムを乗せて動かしてみました。が、動作が重いような...

開発環境ではさくさく動いていたのに、本番環境ではどのページ遷移ももっさりしています

abで計測してみたところ、開発環境のおよそ2分の1のスコアとなってしまいました。

開発環境が仮想2コアのメモリ1Gだったのに対し、本番環境が仮想1コアのメモリ2G

CPUの性能について半減しているのでそのせいかな、と思いつつ設定を見なおしていたところ

特に使っていないと思われたipv6を停止した途端にパフォーマンス改善されました。

ページ遷移に伴うもっさり感が解消され、abの計測結果も開発環境と遜色ない結果が出ています

デフォルト有効になっていたipv6の影響により余計な処理が走っていたのかもしれません。


サーバから送信したメール迷惑メールと判定される

パフォーマンス改善に喜んだのも束の間、会員登録などの処理でWebアプリからメールを送信したところ、Gmail宛のメールがことごとく迷惑メールと判定されるという事案が発生。

spfの設定を行なうメールの内容について吟味するなどの回避策を試してみましたが一向に改善されません。

試しにHotMailexciteメールアカウントに送信したところ、そちらではそもそもメールを受け付けてもらえずエラーコードが返って来る始末。

困り果てていたところ、エラーの内容からサーバIPがspamhousにスパム送信元として登録されていることが判明しました。

postfixホスト名の設定がデフォルトで「localhost.localdomain」などとなっており、それをそのまま使っていたためにGmailスパム送信元として通報してしまったようです。

設定を修正し、spamhousに解除依頼を提出。事なきを得ました。


KVSの変更

クラウドを利用すれば、サーバを停止することなく簡単な設定でスケールできるようになる。

と、自分勝手に思い込んでいたせいなのですが、消えては困るデータの一部をmemcachedに保存する実装を行なっていました。

実際のところさくらのクラウドではサーバを完全に停止しなければプラン変更を実施できないし

そもそもサーバが落ちたらどうするんだよ。ということで、急遽KVSを変更する必要に迫られました。

速度の低下が気にかかったため、いくつかの候補を実際に動かし

phpスクリプトから1万件のデータ読み書きを行うという形でmemcached比較してみたところ次のような結果に。

サービス1万件書込1万件読込
memcached 2.55秒 2.30秒
handlersocket 21.23 2.71秒
InnoDB20.23 5.10
kyotoTycoon 8.22秒 7.72秒

さすがに読み書きそれぞれmemcachedが最速ですが、読み出しについてはhandlersocketも負けていません。mySQLから普通にSELECTしてもmemcachedの2倍程度の時間しかからないという結果が意外でした。

しかしながら書き込みのほうではhandlersocketもmemcached10倍近くの時間がかかっており、少々速度的な影響が気になってきますmemcachedの倍のパフォーマンスを記録したという記事を見たことがあるので、設定、チューニングについて生かしきれていない部分があるのかもしれないとも思いましたが、知識が不足しているところで無理をすると問題が発生した時に対処できないと考え、候補から除外することとしました。

結局、今回の用途では読み込み処理より書き込み処理のほうが圧倒的に多いことも考慮し、kyotoTycoonを採用しました。実際の利用箇所に組み込んでabで計測してみたところ、だいたい30%程度のパフォーマンス低下にとどまっており、これなら許容範囲かと考えています

mySQLレプリケーションが止まる

実行系と参照系に分ける形でmySQLレプリケーションを行なっていたのですが、度々レプリケーションが停止する現象が発生しました。

一部のテーブルについて肥大する可能性が考えられたため、参照系に接続するプログラムで使わないテーブルをレプリケーションから除外していたのが原因です。

例えばtabelAをレプリケーションし、tableXをレプリケーションしないという設定にしたうえで

実行系でINSERT INTO `tableA` SELECT `value` FROM `tableX`などといったクエリを発行すると、参照系にtableXが無いためエラーが発生して止まってしまます

レプリケーションするテーブルを限定する場合プログラム側でも注意を払わないと危険です。当たり前ですが。

サーバ監視にmonitを使用

監視といえばcactinagios定番なのかもしれませんが、設定が複雑そうで尻込みし、monitを使用することにしました。

簡単な設定でloadaverageやメモリHDDの使用量をチェックできるほか

httpdmysqldなどといったサービスプロセス監視し、もし落ちていたら自動で起動してくれるので助かります

Webアプリの秘匿

パスワード保護を行うとしても、サイト全体の管理画面など自分しか使わないプログラムWeb晒しておきたくない。

というわけで、一部のWebアプリを秘匿する設定を行いました。

管理画面のWebアプリを9999番など閉じているポートに設置した上で、SSHを利用したトンネルを掘ります。といっても

ssh -t -L 9999:localhost:9999 user@xxx.xxx.xxx.xxx

上記のようなコマンド管理画面のWebアプリを置いたサーバログインするだけです。

ブラウザアドレス欄にhttp://localhost:9999/と打ち込めば、接続が開いている間のみアクセス可能になる感じですね。

サーバログインできる人でなければ実行できないことなので、気分的にある程度安心します。

SSHログバックアップ

自動ログバックアップを行いたいと考えたのですが、パスワード無しの鍵でログインして転送する形には抵抗がありました。

調べてみたところ、authorized_keysに公開鍵を記入する際の設定で、その鍵でできることを制限するという手段があるようでした。

具体的には、authorized_keysに

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="some commands" ssh-rsa AAAAB3NzaC1yc2EAAA...

などとして公開鍵を追加しておくと、その鍵でログインした直後にcommand=""の部分で設定したコマンドを実行して接続を終了する挙動となり

接続フォワードもできなくなるため、パスワード無しでも鍵の流出に関するリスクを最低限に留めることができるというわけです。

commandの実行結果は標準出力から受け取ることができるので、例えばcommand=""の部分にファイルの内容を表示する処理を設定していたとすれば

ssh -i .ssh/no_password_key user@xxx.xxx.xxx.xxx > /path/to/file

などとしてログインの結果をファイルに書き込むだけで、簡単にファイル転送が実現できます


まとめ

他にも大小さまざまな問題に行きあたりましたが、忘れてしまったor書ききれないのでここまでとします。

たった1つのサイトを公開するにしても問題というのは尽きないものだと実感させられました。

今は基本的な情報だけでなく、ちょっと突っ込んだ内容でも検索で解決していけるので嬉しいですね。手がかりを残してくれた先達に感謝することしきりです。

現状ではひとまずの見切りを付けて公開していますが、より堅牢で負荷に強いサーバとなるよう、随時チューニングを行なっていこうと考えています

最後

作ったWebサービスについて少し書きます

サイト名は「Radiosonde」

個人サイトや小規模な商業サイトなどプロモーションにあまりお金をかけられないサイトを主な対象とした、無料で出稿できる広告ネットワークサービスです。

既存サービスで近いのは「あわせて読みたい」や「zenback」、各社提供RSS相互リンクサービスなどになるでしょうか。

広告としての体裁がある分、それらより若干積極的な性質になるのではと考えています

現時点ではサービス本体のプロモーションに苦心するという本末転倒のものの状況でありますが、もしよろしければ見ていただけると嬉しいです。

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん