昨日の日記「DDD (DoS Driven Development) を始めよう」からの続き。
DoS への対策で Fluentd + Elasticsearch + Kibana を使ったアクセスログ解析を第三tDiary.Netの上で行おうと思い立ったのは事実なんだけど、実はそれ以前から Elasticsearch 関連は勉強し始めていたのであった。
その勉強を実地で活かす場として、第三tDiary.Netのアクセスログを利用する。その結果として DoS 避けができるようになれば、オレに取ってのメリットが大きくなる。
Elasticsearch 関連を勉強するにあたって、参考にしているサイトや書籍を先に上げておく。これらが無ければ先に進めなかったかも。
さて、ここで話を元に戻そう。
今回のシステム構成を考えた。まずサーバは2台構成。第三tDiary.Netが動いているサーバとは別に解析用のサーバを用意する。用意するとは言っても、借りているけど遊び気味な VPS が元々あるのでそれを流用するイメージ。
Kibana で画面を見るのは手元の MacBook Air なので、いちおう描き加える。Kibana 本体は「解析サーバ」の上に置くとは思うけど、ちょっと図の簡略化をしたらこうなった。
第三tDiary.Netは apache2 で動いていて、アクセスログは普通に書き出している。この部分は今回は変えない。基本的には現在稼働中の tDiary 部分には手を入れない方針でいく。
Fluentd (td-agent) で apache2 のアクセスログを読んで、解析サーバの Elasticsearch サーバへ直接送信する。この間の通信は iptables によってアクセス元を制限しておく。うまくいったら ssh トンネルなどで経路の暗号化もちょっと考えるけど、最初はシンプルな構成にする。
Kibana から Elasticsearch へアクセスするために、nginx のリバースプロキシ機能を使う。Kibana (Ver3) は JavaScript から Elasticsearch に接続する形になる。
つまり、ブラウザを開いた場所の IP アドレスからの接続になるため、先ほどの iptables によるアクセス元制限との共存がうまくいかない。そこで Kibana からは一度 nginx に繋いで、そこで BASIC 認証などでアクセス制限を行なう構成にしてみた。
こういう考え方もどこかのサイトを参考にしたんだけど、辿りつけなくなってしまった。。。メモ重要なのに。
ということで、今回も実践には辿り着かずにこの日記を終えるけど、裏側(?)ではインストールやら設定やらを進めていて、少しずつ形になりつつある。まだ実際に Kibana で見るところまではできてないけど、、、もう少しじゃないかな、希望的観測としては(笑)