nginx

[WIP]Locustで初心者がAPIサーバーの負荷試験をやってみた

この記事はチラ裏です。僕の頭の中を整理するためだけの記事です。 寒いなぁ…寒いなあ… 卒論を提出して2/6にはパワポとレジュメを作成して発表です。   負荷をかけるツールはいっぱいある 便利な世の中なので負荷ツール(Load test tool)はたくさんあります。 ここでどれを使うかを選定しないといけないわけですがいくつか候補を挙げてみたいと思います。 JMeter(有名、高機能、リクエストがいっぱい出せる、知見多) ab(シンプル、知見多、手軽) httpperf(手軽、リクエストがいっぱい出せる) vegeta(リクエストがいっぱい出せる) hey(手軽) siege(使ったことない) goad(Lambdaから負荷をかけれる、色んなリージョンからアクセスできる、JSONのPOSTのやり方分からず、手軽) Locust(分散して負荷をかけれる、Web GUIがある) 分散しないで負荷をかける vegeta や hey では家のネットワークとか、1台のマシンだけじゃサーバー側のリソースを使い切ってくれないため除外。 JMeterは設定がダルい、勉強するのは少し面倒。 Locust は Qiita 等で取り上げられてるので知見は結構あります。 JMeter のようなシナリオを Python で書き、負荷をかけるサーバーも簡単に実行することができる。 ドキュメントもきちんと整備されているので今回は Locust を使ってみました。     Locust を使ってみる インストールも簡単です。 pip install locustio これだけです。 実行は locust -H host --master Slaveは locust -H host --slave --master-host=masterip Master は実際に負荷をかけず、集計や Web GUI を担当し、Slaveが実際の負荷を行います。 今回は c4.large のインスタンスを6つ建てて 1Master 6Slave で負荷をかけました。 画面が多いと負荷試験がやりやすい pic.twitter.com/QozJrFR3ag — るいす (@lu_iskun) 2018年1月29日 負荷試験中は、LB(Nginx), API, DBのリソース状況、各サーバーのログを表示しておき、 Nginx のコネクション数や、FD数などは Nginx Amplify を表示しておくと便利です。   今回は 10万ユーザーを作成し、秒間1万ユーザーずつ増加していく方法を取りました。   Charts には数値がグラフ化されています。 この図を見るだけで、RPSは最大3200、ユーザー数が増えるごとにレスポンスタイムが増えていっていることが分かります。   失敗したリクエストは Failures にまとめられています。 先程の図から推測すると、何らかの要因でレスポンスタイムがどんどん増えていき、サーバーがコネクションを切ってしまったんだと思います。     [crayon-5b28895d205bd063880305/] ルーターのネットワークインターフェースを見てみると LB, API, DB が載ってるサーバーからのパケットで、いくつかドロップされてるパケットがあります。 CDN に Cloudflare を挟んでいるのですが原因は Cloudflare ではなく完全にこちら側ってことが分かります。     コンテナで動かしているAPIサーバーに16スレッドを割り当ててますがうまいこと全部のスレッドを使っているようです。Go はメモリが全然消費されなくてすごいですねぇ ここを見ている限り、平均70%のCPU負荷で %iowait もそこまで高くないため(そもそもディスクの読み書きがないようなAPI)、LBかDBのような感じもします。   LBは2段あって、3段目にAPIがあるわけですがこの画像には写って無くて申し訳ないですが(画像は最上段LB)、最上段LBは HTTP Error が発生していましたが、2段目のLBでは HTTP Error…

NGINX Amplifyを使ってNGINXの状況を監視したりステータスを確認してみる

日々新しいツールや技術が生まれ、歳を取ると頭が追いつかなくなるというのは 何となく分かるような気がしてきました。 ということで NGINX Amplify というのを試してみようと思います。     NGINX Amplify とは NGINX を監視するSaaSです。 https://www.nginx.com/amplify/ Datadogや、Mackerelみたいな感じで NGINX のステータスだけでなく、一応はマシンのリソースとかも確認できる。 NGINX のステータスだけでなく、マシンのリソースをトリガーとしても アラートを出すことができます。 現在はベータで今は無料で使用できますが、正式にリリースされた後は、 もしかしたら NGINX+ (NGINX Plus) だけの提供になりそう。     NGINX Amplify のインストール 会員登録をし、NGINX Amplify にログインをするとインストールの仕方が書かれています。 stub_status とログの設定に関しては必須要件でないものの、 有効にしておくと監視できる項目が増えます。 外部から参照できる必要性はなくてインストール方法にかかれている通り、 ローカルホストからのみアクセスができればいいそう。     機能 NGINX Amplify の機能について。 大雑把に機能紹介   グラフ ログインするとダッシュボードが表示されます。 メトリクス含め、グラフも結構な量が表示されていて困ることは無いかと思うレベル。 ファイルディスクリプタ数が見れるのは中々良いと思います。     ダッシュボード ダッシュボードも自分で作成することができる。 右上を見て分かる通り、時間帯も選択できるけど細かい日時指定はまだできないっぽい。 グラフの描画上にマウスポインタを合わせることで分まで分かるものの、 秒までは分からなかった…。     Analyzer ここもめっちゃいい機能だと思う。 NGINX の設定を確認することができる。 SSL証明書の概要だったり、設定の不備を教えてくたり 中々に便利な機能。 default.conf は存在しているのに見つからないエラーが出るのはバグなのかな。     アラート機能 閾値を設定することがメールで通知することができる。 まだメールだけでの通知だけど今後、Slackとかも対応してくれると良いなあ。

Grafanaをリバースプロキシ環境でBasic認証が使えない問題

ちょこっとハマったので記事に。 覚書です。   概要 GrafanaをNginxのBasic認証で動かしたい   問題 認証情報があってるのに永遠にBasic認証のダイアログがでてくる   解決 [crayon-5b28895d20897788482759/] GrafanaのBasic認証でのログインがデフォルトで有効になってるので無効にする。 ずっとNginxのログを見てたけど、Grafanaのログを見たら解決した。 トホホ。

nginxの多段リバースプロキシ環境でWordpessをパス指定で振り分ける

nginxの多段リバースプロキシを使って、パスによって振り分け先はWordpressにしてみます。 そもそもサブドメインで振り分けるのが設定も複雑にならず、分かりやすくていいんですけどね…。     目標 多段リバースプロキシの環境でパスによって参照するWordpressの乗ったサーバーを振り分ける。 例) http://hoge.com/gallery/docker と http://hoge.com/gallery/docker1 は別なWordpress Dockerfileは下記のものを使いました。 [blogcard url=”https://github.com/eugeneware/docker-wordpress-nginx”][/blogcard]     構成 最上リバプロ : nginx 後段リバプロ : nginx WordPress  : nginx WordPressが乗ってるコンテナはDockerです。docker,docker1,docker2はそれぞれ独立したコンテナです。 また、Wordpress側はローカルでクライアントからIPアドレスだけで開ける状態です。 リクエストパスに /gallery があるものは後段リバプロへ行き /gallery/docker は dockerコンテナへ /gallery/docker1 は docker1コンテナへといった感じです。     設定 WordPressが載ってるNginxから見たリクエストURLには /gallery/docker が含まれるともちろんですが 404 が返ってきます。 しかしWordpressが載ってるコンテナのPHPから見た $_SERVER のREQUEST_URI, SCRIPT_NAME, PHP_SELF に /gallery/dockerが含まれていないとPHP側が返す(作成する)ヘッダには /gallery/docker が含まれないレスポンスURLになってしまい、 ログインはできても管理画面が http://hoge.com/wp-admin となり、/gallery/docker が含まれずそれ以降どこのリンクを押しても 404 となります。     最上リバースプロキシ 最上リバースプロキシは後段リバースプロキシへ /gallery というパスを伝えないといけないので http://docker-reverse-proxy/gallery というリクエストURLで後段リバースプロキシへ。 [crayon-5b28895d209fa108268111/]       後段リバースプロキシ リクエストURLが /gallery/docker のものは http://docker へ /gallery/docker1 のものは http://docker1 へと言った感じにします。 また、Wordpress(docker)のNginxがリクエストURLを見たときに /gallery/docker が含まれないようにします。 [crayon-5b28895d20a04104392001/] 最上リバースプロキシでは location ディレクティブの後ろに / をつけませんでしたが 後段リバースプロキシでは付与します。 ココらへんの説明は下記のサイトさんが詳しいです。 [blogcard url=”https://www.xmisao.com/2014/05/09/nginx-proxy-pass.html”][/blogcard]     WordPress(docker)側の設定 – wp-config.php 前述した通り、PHPから見た $_SERVER のREQUEST_URI, SCRIPT_NAME, PHP_SELF には /gallery/dockerが含まれていないと 404 になってしまうのでグローバル変数を書き換えます。 [crayon-5b28895d20a08644662715/]   これらの設定をすることで管理画面へログインしても正常に動作すると思います。     php-fpm の設定を変更する wp-config.php の編集ではなく、Wordpress(docker)側の php-fpm の設定でも可能です。…

WordPressで記事新規追加時にレイアウトが崩れたりした時の対処法 Refused to apply inline style because it violates the following Content Security Policy directive

お久しぶりな記事 この夏はインターンに参加したり、今は静岡で合宿免許に来てます。 平日の休みと言えば三日間ぐらいしかありませんでしたが毎日充実してます。(家帰りてえ・・・)   合宿免許で暇だったので記事を書こうと思ってWordpressの新規追加をクリックしたところ テキストボックスは表示されるもそれ以外は適当に表示されていて頭を抱えました。 そんなときに便利なデベロッパーツールを使うとこんなエラーが! Refused to apply inline style because it violates the following Content Security Policy directive ~~~ エラーログにも書かれているように Content Security Policy を適切に設定しろってことですね。 ブラウザのセキュリティの一環でXSS対策、クリックジャッキング対策ができます。 ただもちろん弊害もあって、インラインのコードが実行されなくなります。 詳しくは知らないのでこちらのサイトが参考になるかと思います。   対処 アクセス制御を行う値をヘッダーに載せます。 nginxでの設定を記述しますがApacheでもできます。 /etc/nginx/conf.d/.confのserver {}に以下を記述します。 [crayon-5b28895d20bee301690469/] 見にくいですけどとりあえずこのまんまコピペすればいいと思います。 値の意味に関してはこちらのサイトが参考になります。   これでnginxを再起動してヘッダーを見ると変わっている箇所があると思います。 このContent-Security-Policyにあるサイトからのファイルは展開されるようになります。 Content-Security-Policy, X-XSS-Protection, X-Frame-OptionsとかWebサイトを公開する人は知っておかないとダメですね…徒歩歩

nginx + リバースプロキシ + SSL でWordPressを動かす

1日10万PVぐらいのWordpressを管理することになってどうがんばっても8秒を切れない。 そこでテスト環境に入れた nginx + リバースプロキシ + SSL でWordpressを動かした時のコンフィグを覚書として。 nginx.conf [crayon-5b28895d20e9c357805112/] [crayon-5b28895d20ea7969752495/] SSLで動かす際に大事なのがこれで、この記述がないと [crayon-5b28895d20eaa485037605/] こんな感じにコンテンツがブロックされて、レイアウトが崩れた誰もが1度は見たことある状況になります。 ちなみに [crayon-5b28895d20eac105494237/] この記述はなくても普通に動く。ヘッダーに設定すればこの記述は不要なのかなと思って [crayon-5b28895d20eae031429536/] これを消して [crayon-5b28895d20eaf587119420/] これだけの記述にしたけど同様に [crayon-5b28895d20eb1620755410/] と怒られた。   default.conf [crayon-5b28895d20eb3945141255/]     mobile_cache_setting [crayon-5b28895d20eb6765300190/]     php_exec [crayon-5b28895d20eb9199954644/]   WordPressで記事更新時などのキャッシュ削除は Nginx Cache Controller を使うようにした。 もう1つ名のしれてるやつは、パッケージから入れた場合 ngn_cache_purge モジュールが入ってないために使えない”らしい”。 Nginx Cache Controller はキャッシュディレクトリと、レベルを指定することで同じことを実現してるのかな? ngn_cache_purge モジュールを使ったことないので適当に言いました!

[Ubuntu / CentOS]Nginxをビルドし起動するまで

覚書です。 build make [crayon-5b28895d211d0622390537/]   Init Script [CentOS 6] [crayon-5b28895d211de972299075/]   [CentOS 7] [crayon-5b28895d211e3447133365/]   [Ubuntu] [crayon-5b28895d211e8029817866/]  

「Raspberry Pi Zero」でWordPress動かすならリバースプロキシは必須だ

Raspberry Pi Zero シリーズ 第三弾! 「Raspberry Pi Zero」を買ってみた。【外観編】 500円パソコン「Raspberry Pi Zero」を使ってみた。【Unixbench】   Raspberry Pi Zero に WordPressをいれてベンチマーク 構成としては Nginx + php7-fpm という構成です。Wordpressは最新の4.4.1 ベンチマークに、Loadimpactを使いました。 abとか、wrkでも良かったんですけどこういうのって、CMSとかだときちんとした数値とれるんですかね?リクエスト投げて何かしら返ってきたらはい終わり!ってやつだと思うんですけど(?)   Active 30ユーザーぐらいからどんどんロードタイムが伸びていくのが分かると思います。 45ユーザーで最高値となって25秒とロード時間が長い。   こっちはリバースプロキシを使った時 最長でも6秒とさすがといったところ!個人で使うブログぐらいだったら何も問題なさそう。 ストレージが microSD がちょっと難点だけど。 CMSにも使えるぞ!Raspberry Pi Zero!