この記事は、NTT Communications Advent Calendar 2021 4日目の記事です。 こんにちは、イノベーションセンターでSREとして働いている昔農(@TAR_O_RIN)です。主にNTT Comのソフトウェアライフサイクルの改善への取り組みやアーキテクトに関わる仕事をしております。本日はサービスメッシュを題材に，その中で用いられるEnvoyの活用パターンを手を動かして理解するお話をさせていただきます。 また，昨年までのアドベントカレンダー記事もご興味があればご覧ください！ 2020年 How do you like k3s ? - CoreDNSで作るお家DNS Cacheコンテナ 2019年 TektonでCI/CDパイプラインを手の内化しよう 2018年 DevOpsってこんな仕事！考え方とスキルセットのまとめ 2017年 DockerのnetworkをCa
はじめに Nginx でロードバランサを構成する Webサーバ1号機の作成 Webサーバ2号機の作成 ロードバランサの作成 ロードバランサとWebサーバの起動 Web アプリケーションの準備 Docker でアプリケーションをビルドする DBサーバの準備 ロードバランサとアプリケーションサーバの起動 まとめ はじめに 前回は Docker のインストールからイメージビルド・コンテナ起動・Compose までの流れをみてきました。 blog1.mammb.com 今回は以下のような、一般的な Web アプリケーションの開発環境を構築していきます。 前回の記事とあわせて、Docker の活用方法を理解いただければと思います。 Nginx でロードバランサを構成する 最初に、単純な Web サーバを Nginx でロードバランシングする環境を作成して動作を見てみます。 このような構成となります。
CloudFront と API Gateway で SPA の CORS 問題をイイ感じに解決する | DevelopersIO
渡辺です。 弊社ではお客様の悩みや問題を解決するアンサーブログという文化がありますが、新しく「ドキュメントはブログ」というのを試しています。 現在、 Developers.IO Cafe はSPA（Single Page Application）で構成されています。 SPAとは、単一のウェブページ上でJavaScriptによるルーティングの処理を行うWebアプリケーションです。 一般的に、SPAで内のコンテンツは、APIを通して取得します。 この時、悩ましいのが CORS(Cross-Origin Resource Sharing) です。 本エントリーでは、カフェのSPAでとったCORS対策について解説します。 CORSとは？ CORSとは、簡単に言うと、 ウェブサイトが異なるドメインに対するAPIリクエストをブロック する仕組みです。 あるウェブサイトを開いている時、まったく関係ない別
TCP/QUICのポートフォワードツールを書いた。 概要 IETFで標準化が進められているトランスポートプロトコルQUIC。 UDPを利用しており、エンドポイントのIPアドレスが変わってもコネクションが切れなかったり、より良い再送制御が行えたりと長所は多くある。しかし、QUICをサポートしているアプリケーションプロトコル、実装が現状多くはない。 QUICの恩恵に預かるために、TCPとQUICを相互変換するポートフォワードツール 「t2q2t」 を書いた。(実態としてはただのProxy) github.com ただし、ハンドシェイク回数が増えるのでコネクション確立時のオーバーヘッドは高い 利用例 ユースケースとしては例えば: クライアントとサーバそれぞれでt2q2tを実行する。 クライアント: TCPで0.0.0.0:2022でリッスンし、QUICで192.168.0.1:22に転送する サ
Mercari Advent Calendar 2018 の5日目はSREチームの @catatsuy がお送りします。 メルカリではGoで書かれたproxy serverをサービスの各所で使っています。今回はGoでproxy serverを作るときにハマりそうな、標準ライブラリの挙動や特徴について紹介します。 本エントリーは2018/12/04現在の最新であるGo 1.11.2を元にして書きます。 Hostヘッダーはreq.Header.Set(“Host”, “example.com”)しても上書きできない https://github.com/golang/go/blob/e8a95aeb75536496432bcace1fb2bbfa449bf0fa/src/net/http/request.go#L1023 https://github.com/golang/go/blob/e8
It was brought to my attention recently that there is a dearth of introductory educational material available about modern network load balancing and proxying. I thought to myself: How can this be? Load balancing is one of the core concepts required for building reliable distributed systems. Surely there must be quality information available? I searched and found the pickings are indeed slim. The
The goal is to implement a proxy server for HTTP and HTTPS. Handling of HTTP is a matter of parsing request, passing such request to destination server, reading response and passing it back to the client. All we need for that is built-in HTTP server and client (net/http). HTTPS is different as it’ll use technique called HTTP CONNECT tunneling. First client sends request using HTTP CONNECT method t
先日mattnさんの記事を読みました。 golang の http.Client を速くする nettというパッケージを使って 名前解決の結果をキャッシュすることで、http.Clientを早くするというものです。 この記事に関して、ちょっと疑問に思ったことがあったので、検証してみました。 疑問 疑問に思ったのは以下の点です。 名前解決遅すぎでは？ ベンチマークの結果を見ると5億ns(=500ms)ほど速度が改善しています。 3つのURLに対してリクエストを投げているので、初回を除く2回DNSのキャッシュがヒットし、 名前解決2回分の速度改善になるはずです。 と、いうことは、名前解決1回あたり250msかかっている計算になります。 googleのsearchは302でリダイレクトがかかるので、Client.Getの呼び出し1回あたり2回リクエストが飛ぶ、 ということを計算に入れても100m
リバースプロキシのコンフィグテスト やりたいこと Apacheをnginxに置き換えたい Apacheやnginxをバージョンアップしたい テストパターン パターン1: 本番のproxyサーバに実際にリクエストする パターン2: proxyサーバをテスト用に起動しつつ、upstreamやlistenディレクティブなどconfigの一部を書き換える パターン3: ngx_mrubyやmod_mrubyで設定をmrubyで書き、mruby-mtestなどでテストコードを書く パターン2はconfigの一部を書き換えるため、本当に本番の環境で正しく動作するかわからない問題がある。テストコードがnginxやApacheなど特定の実装に依存する。CIは回しやすい。 パターン3はngx_mrubyやmod_mrubyでconfigを書かなければならないため、今動いているproxyの設定をテストできない
こんにちは、Sustain チームの山口です。 今サイボウズリモートサービスというVPN・中継サービスで使用する L7LB を nginx に移行しようといろいろ調査をしています。 nginx をリバースプロキシとして使用する際に少々障害となる動作があり、それに関するアップデートが最近あったので、今回はそのお話です。 3行で分かる本記事の内容 nginx をリバースプロキシとして使う場合、リクエストがバックエンドサーバに二重で飛ぶ可能性がある 対策として proxy_request_buffering off が使えそうだが、使えない nginx 1.9.13 で仕様変更が入り、POST, LOCK, PATCH メソッドのリクエストは二重で飛ばないことが保証された nginx の受動的な health check とリクエストのリトライ動作 nginx はリバースプロキシとして使う場合に
2016 - 03 - 15 Amazon ECSでHAProxyのDockerコンテナを各Taskに配置するのがなかなか良い件 Docker HAProxy AWS ECS どうも、コンテナ芸人です。久しぶり？に Amazon ECSを使ったネタをお届けします。 今のプロジェクトではDBに MySQL を利用していますが、コスト低減のためにMaster(Multi-AZ)だけRDSでSlaveはEC2で構築しています。で、SlaveにはELB経由で参照していましたが、最近この仕組みをHAProxyコンテナに置き換えてみたらなかなか良かったぞという話です。 旧構成 これがつい先日までの構成。 ECS Task *1 は Nginx+Node(React)+ API (Go)+td-agent で1セット Nginxは API コンテナや、 SSR でHTMLを返却するNodeコンテナへPr
GitHub - Shopify/toxiproxy: :alarm_clock: A TCP proxy to simulate network and system conditions for chaos and resiliency testing
Toxiproxy is a framework for simulating network conditions. It's made specifically to work in testing, CI and development environments, supporting deterministic tampering with connections, but with support for randomized chaos and customization. Toxiproxy is the tool you need to prove with tests that your application doesn't have single points of failure. We've been successfully using it in all de
以下の記事内容について、奥一穂氏（@kazuho）より、「connectのエラーコードが信頼できなくなるといった欠点もあるのに透過 SOCKS プロキシが汎用的に良いように読めてしまう」というご指摘をいただきました。確かに、下記内容は当社が抱えていた複数の課題を短期間で解消できる「ワークアラウンド」として透過 SOCKS プロキシという技法もあることを紹介したものであり、NAT と比較して常に良いという主張をしたかったわけではありません。また、記事内では解説を省きましたが、従来より HTTP(S) 通信は NAT ではなく HTTP プロキシを利用しています。謹んで補足・訂正とさせていただきます。 猫が好きだけど猫アレルギーで近寄ることができない山本泰宇です。 先日アーキテクチャ刷新プロジェクト「Neco」を紹介しましたが、今回はその活動の一環として実施したネットワークアドレス変換(NAT
この記事はQuipperのテックブログに書いた以下の記事の日本語版での要約です。 http://quipper.github.io/2015/11/11/introducing-shadow-proxy.html Shadow Proxyとは？ 本番のHTTPリクエストから同等のリクエストをステージング環境に適用するための仕組みです。主な目的は、2年以上の運用で肥大化したMongoDBに対するindexの追加/削除/つけ忘れなどを事前に検証・検知するためです。 構成 Fluentdが大活躍しています。 Reverse Proxy Log AggregatorにNginxのアクセスログを転送する Log Aggregator S3(バックアップ),BigQuery(調査用),Shadow Proxyにアクセスログを転送する Shadow Proxy アクセスログをもとにステージングのアプリに
nginxの背後にELBがいて、proxy_pass https://xxx.yyy.comみたいに指定していたんだが、突然クライアントにHTTP 499が返却されてしまうという事案が発生した。なおこの記事の対象はnginx1.8系とnginx1.6系。調べたところによると割とみんなよくハマる定期ネタのようだ。 どういうことか nginxの仕様としてproxy_passに名前を使っている場合、その名前解決はnginx起動時に行われる。そしてそのときに取得したIPはnginxにキャッシュされてnginxの再起動もしくはHUPを受け取るまで解放されない。 なのでELBのようにIPが変化するものをnginxの後段に置くときは注意する。 proxy_pass https://xxx.yyy.com; だけでなく、resolverでDNSとそのキャッシュのexpireを指定、さらにset $xxxで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
