ECSでサービス間を「NLBでつなぐ」のと「Service Connectでつなぐ」のと、どっちがデプロイが速いかをチェックしてみた - Mitsuyuki.Shiiba
忘れる前にやっとこかなと思って、続きをやることにした。 bufferings.hatenablog.com やりたいこと この２つでデプロイ時間にどれくらい差があるかなぁってことを見たい NLBあり + Service Connectなし NLBなし + Service Connectあり 今日のコードはここにある github.com 環境を再構築 OpenTofuで作っておいたから楽ね。 ❯ terragrunt apply -auto-approve ... Apply complete! Resources: 18 added, 0 changed, 0 destroyed. Outputs: nlb_dns_name = "<生成されたNLBのDNS名>" はい。できた。 ECSのTask Execution Roleが必要だった 忘れてたので追加。こんな感じ。 ❯ git di
Avoiding the Top 10 NGINX Configuration Mistakes - NGINX
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
Kubeflow: Authentication with Istio + Dex
Compatible with Static Users, LDAP/AD and External IdPs Multi-tenancy is a central feature of Kubeflow 0.6 and providing a flexible authentication scheme is important for enterprise use-cases. In this article, we will explore how we leveraged the power of Istio and open-source components to create a flexible, robust and clean authentication solution. This solution is especially powerful because: I
Improving NGINX Performance with Kernel TLS and SSL_sendfile( ) - NGINX
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
AWS ALBの運用豆知識 | 外道父の匠
たいした諸事情なわけでもないですが、だいぶ更新を空けてしまいましたので、ささやかなことからコツコツと書いていこうかと思います。 今回は、ALB(Application Load Balancer)の運用で得られた豆知識の記録です。 暖機運転の豆知識 申請の必要性 ALBはトラフィックが増加しても自動的に拡張して対応してくれますが、急激に増加すると拡張が間に合わずにキャパシティオーバーとなって、ALBがエラーを返してしまう可能性があります。そのため、事前にこのくらい跳ね上がりますので暖めて馴染ませておいてください。ってのが暖機運転（Pre-warming）です。 基本的には事前に申請して扱う仕組みですが、想定よりトラフィックが多くなり、エラーが多発し、数十分・数時間も解決しない場合もこの申請をすることがあります。この場合、ALBが自動拡張してくれない ＝ 何か他に問題がある 可能性が高いので
nginx-backend間でKeepAliveする - road288の日記
nginxをフロントにおいて、バックエンド(upstream）にリバースプロキシするというのはよくあるけど、nginx - upstreamでkeepaliveさせるには設定がいる。数年前にやっていたのに忘れていたのでメモ。 公式のドキュメントはこちら。 Module ngx_http_upstream_module 公式のママだが、(1)httpバージョンを1.1にする (2)Connectionヘッダを空にする、の2つの設定が必要となる。 upstream http_backend { server 127.0.0.1:8080; keepalive 16; } server { ... location /http/ { proxy_pass http://http_backend; proxy_http_version 1.1; // http1.1する＝デフォルトでKeepAli
GCP+Django+Docker+Nginx+LINE Messaging APIで翻訳botを作った - Qiita
はじめに LINE botで翻訳botを作りました。 このbotを友達登録して何か発言するとそれを英訳して返してくれます。 ルームにも招待できるので、普段会話を英語にするとどんな感じなんだろう？と気になっている人はぜひ使ってみてください。 bot 友達登録 使ったもの python 3.7 Django 2.2.8 mysql (使っていない) nginx 1.17 Google Compute Engine Google Translate API (google-cloud-translate 2.0.0) お名前.com Let’s Encrypt コード こちらにコミットしています。 https://github.com/ken-araki/line-bot-python コスト感(予定) 年間1円です。 まだ運用が始まっていないので想定値ですが、以下のような試算をしています。 お
Avoiding dropped connections in nginx containers with “STOPSIGNAL SIGQUIT” | Ubuntu
Thank you for signing up for our newsletter! In these regular emails you will find the latest updates about Ubuntu and upcoming events where you can meet our team.Close (Also published on my blog at robinwinslow.uk) Update: The default used in the official nginx docker image was changed from SIGTERM to SIGQUIT in November 2020, so this should no longer be an issue for Docker or Kubernetes users. n
Why does one NGINX worker take all the load?
Why does one NGINX worker take all the load?10/23/2017 Scaling up TCP servers is usually straightforward. Most deployments start by using a single process setup. When the need arises more worker processes are added. This is a scalability model for many applications, including HTTP servers like Apache, NGINX or Lighttpd. CC BY-SA 2.0 image by Paul Townsend Increasing the number of worker processes
gRPC WebがGAになったのでそろそろ理解してみる
2018/10/23に「gRPC-Web is Generally Available」というタイトルでgRPC-WebがGAになった事がgrpc公式ブログで発表されました。 https://grpc.io/blog/grpc-web-ga 翌日にCNCFのブログでも「gRPC-Web is going GA」というタイトルで同等の内容が公開されました。 https://www.cncf.io/blog/2018/10/24/grpc-web-is-going-ga/ 今までブラウザからgrpcが使えるgRPC-Webの存在は知っていましたが、ちまたで実際に利用しているというのもあまり聞かなかった為ほとんど気にしていませんでした。 この度GAになったのをきっかけにエコシステムができあがってくれば間違いなくパラダイムシフトになると思いちゃんと検証してみました。 この記事で書く事 gRPC-W
agentzh's Nginx Tutorials (version 2020.03.19)
agentzh's Nginx Tutorials (version 2020.03.19) Table of Contents Foreword Writing Plan for the Tutorials Nginx Variables (01) Nginx Variables (02) Nginx Variables (03) Nginx Variables (04) Nginx Variables (05) Nginx Variables (06) Nginx Variables (07) Nginx Variables (08) Nginx Directive Execution Order (01) Nginx Directive Execution Order (02) Nginx Directive Execution Order (03) Nginx Directive
CentOS7.5 の fsnotify がレースコンディションを起こすバグを nginx + td-agent + in_tail プラグインで踏む - hibomaの日記
2018/7/18 追記 3.10.0-862.9.1.el7 で fix されました hiboma.hatenadiary.jp 2018/7/4 追記 最新の情報はこちらにまとめています hiboma.hatenadiary.jp 2018/6/16 追記 CentOS Plus の kernel-plus では修正が入っています. 詳しくはこちらをご覧ください hiboma.hatenadiary.jp エントリの概要 CentOS7.5 の fsnotify() がレースコンディションを起こすバグを、 nginx + td-agent (fluentd) + in_tail プラグインで踏んだ際の調査内容を記していきます. イントロダクション このエントリを書いた時点では、CentOS 7.5.1804 以降でリリースされているカーネルは 3つありますが、カーネルの fsnotif
Nginxでlocationの書き方はとりあえずコレにしておけ - Panda Noir
「Nginx の location の書き方がわからない！」そう思ったことはありませんか？ ネストするとおかしくなる 同じ階層にあるうち一つしか適用されない 同じ階層のlocationディレクティブの演算子をすべてチェックしないと、どれが適用されるかわからない このように、Nginx の locationディレクティブは直感的ではなく、クセのある動作をします。 今回はとてもカンタンで、ファイル分割管理が楽になるやり方をご紹介します。 locationの基礎事項 まずlocationの基礎知識ですが、locationは並列して書かれていた場合、どれか一つのみ適用されます。どれが適用されるかは演算子によります。 「=、^~、~、~*、なし」の順に適用されます。 =完全一致 ^~前方一致~case-sensitive*1な正規表現 ~*case-insensitive*2な正規表現 なし前方一致
Nginx 1.13 の http_mirror_module を試す - たごもりすメモ
みなさんにも、さまざまな過去の経緯からくる微妙挙動を満載した外部ユーザ向けのHTTPサーバをリプレイスしたりするとき、実際にガツンとやっちまう前にちょっとリクエストを分岐して挙動と性能を確認したい、と思うことがあると思います。考えるだけでつらい気分になってくるやつ。でもやったほうが100倍マシなやつ。 どうしよっかなとちょっと考えたところ、少し前にこんな話があったのを思い出すはずですね*1。 asnokaze.hatenablog.com とはいえヨッシャ使うぞといきなりぶちこむこともできないので、まずいくつか試してみることにする。 準備 前提としては以下のように、元のアプリケーションと同じにホストにリバースプロキシが立っており、そこのnginxで http_mirror_module を使う、という想定*2。ミラー先はどこか適当なアプリケーションサーバ(あるいはロードバランサ)で、元アプ
NginxのアクセスログをJSON形式で出力する - Qiita
http { : log_format json escape=json '{"time": "$time_iso8601",' '"host": "$remote_addr",' '"vhost": "$host",' '"user": "$remote_user",' '"status": "$status",' '"protocol": "$server_protocol",' '"method": "$request_method",' '"path": "$request_uri",' '"req": "$request",' '"size": "$body_bytes_sent",' '"reqtime": "$request_time",' '"apptime": "$upstream_response_time",' '"ua": "$http_user_agent",'
Direct Data Transfer: NginxのX-Accel-Redirectを使って直接データを転送する — LS4 v1.0.0 documentation
目的¶ LS4の用途の一つにWebサービスの画像ストレージシステムがあります。このようなWebサイトでは、アプリケーションサーバの前面にHTTPリバースプロキシを設置しているでしょう。 もしHTTPリバースプロキシとして nginx を使っているなら、nginxの “X-Accel-Redirect” 機能を組み合わせる事で、アプリケーションサーバのCPU負荷とトラフィックを削減することができます。 このドキュメントでは、次のようなWebバックエンドシステムを想定しています： Internet | load balancer / reverse proxy (1) / (5) / App (3) (2) | ----------- GW / | +-------------+ (4)| | | | | | +-|--+ +----+ +----+ | MDS | | DS | | DS |
[WordPress][Nginx] Nginx 1.13.9 に実装された http2_push_preload を使って HTTP/2 push してみる - Qiita
[WordPress][Nginx] Nginx 1.13.9 に実装された http2_push_preload を使って HTTP/2 push してみるWordPressnginxhttp2 先日リリースされた Nginx ver.1.13.9 に http2_push と http2_push_preload ディレクティブが実装されました。 Changes with nginx 1.13.9 20 Feb 2018 *) Feature: HTTP/2 server push support; the "http2_push" and "http2_push_preload" directives. *) Bugfix: "header already sent" alerts might appear in logs when using cache; the bug had
![[WordPress][Nginx] Nginx 1.13.9 に実装された http2_push_preload を使って HTTP/2 push してみる - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed5a46ed423a9f5b4846ef2a2f97da506b793300/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCV29yZFByZXNzJTVEJTVCTmdpbnglNUQlMjBOZ2lueCUyMDEuMTMuOSUyMCVFMyU4MSVBQiVFNSVBRSU5RiVFOCVBMyU4NSVFMyU4MSU5NSVFMyU4MiU4QyVFMyU4MSU5RiUyMGh0dHAyX3B1c2hfcHJlbG9hZCUyMCVFMyU4MiU5MiVFNCVCRCVCRiVFMyU4MSVBMyVFMyU4MSVBNiUyMEhUVFAlMkYyJTIwcHVzaCUyMCVFMyU4MSU5NyVFMyU4MSVBNiVFMyU4MSVCRiVFMyU4MiU4QiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9NDgzMmY0OTc5ZGExYzlmOTA4MGUxNzQ4NGYxMTgzMTQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB3b2thbW90byZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ODRmZDUzMDljMWJmYzlmMzYyYWFmNDc0NjA2MWU4YWU%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44OH44K444K_44Or44Kt44Ol44O844OWIChEaWdpdGFsQ3ViZSBDby4gTHRkLiAp%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Dbe5cd5047f8817caa0e645ee32381668)
HTTPリクエスト単位でmrubyのバイトコードをProcとFiberで包みなおして実行した場合の性能とv2について - 人間とウェブの未来
2018年4月にngx_mrubyのノンブロッキングHTTPクライアントとノンブロッキングsleep相当のメソッドに対応させてngx_mruby v2.0.0をリリースするという目標を立てた— 松本 亮介 / まつもとりー (@matsumotory) 2018年2月13日 ngx_mrubyのv2の4月リリースに向けて、HTTPリクエスト単位で実行されるRubyのコードを、FiberとProcで包んだオブジェクト経由で実行する実行方式に実装しなおしています。これまでのngx_mrubyのv1系は、Rubyのコードをnginx起動時にstruct RPocにコンパイルしておき、リクエスト毎にそのバイトコードを実行していました。 一方v2では、nginx起動時にコンパイルされたstruct RProcを、HTTPリクエスト時にprocオブジェクトに変換した上で、そのprocオブジェクトをca
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Narito Takizawa
nginxのイベント駆動アーキテクチャをソースコードリーディングする | ten-snapon.com
