Webサーバーアーキテクチャ進化論2023
はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ？」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自
Load Balancing
Past a certain point, web applications outgrow a single server deployment. Companies either want to increase their availability, scalability, or both! To do this, they deploy their application across multiple servers with a load balancer in front to distribute incoming requests. Big companies may need thousands of servers running their web application to handle the load. In this post we're going t
The 5-hour CDN
The 5-hour CDN Author Name Kurt Mackey @mrkurt @mrkurt The term “CDN” (“content delivery network”) conjures Google-scale companies managing huge racks of hardware, wrangling hundreds of gigabits per second. But CDNs are just web applications. That’s not how we tend to think of them, but that’s all they are. You can build a functional CDN on an 8-year-old laptop while you’re sitting at a coffee sho
物理サーバのセットアップをon-the-fly ISO patchingで自動化した話 | メルカリエンジニアリング
メルカリSREの@kazです。 今日は、メルカリの所有する物理サーバのセットアップと設定配布の自動化をどのように実現したかをお話します。 メルカリのデータセンタ 本題に入る前に、メルカリが現在構築している自社データセンタ（東京DC）についてご紹介します。 メルカリでは現在、基幹システムのMicroservice化を進めています。各Microservicesの開発においては、そのサービスの特性などを鑑みて、チームの裁量で柔軟にインフラを選択することが可能です。その結果として、メルカリはさくらインターネット、GCP、AWSなど複数のクラウドにまたがって運用される状況となりました。 こうした中、SREチームが問題視したのは「各クラウドデータセンタ間の物理的距離」です。メルカリでは、コストダウン・低災害リスクの観点から、主にさくらインターネットの石狩リージョンを利用しています。一方で、GCPやAW
WEBサーバのTCPコネクション数に上限はあるのか？ - Qiita
はじめに アクセス数がすごい環境は大抵高負荷環境でもあるので対策としてApacheの設定やサーバ構成のセオリーをすぐ見つけられて実際試しても目に見えて良くなります。 アクセス数の多さで起こる問題は実際に負荷をかけてみないと表面化しません。 問題が分かったら設定やパラメータを調整して現状がましになるようにするだけです。 ですが限りあるリソースの中でTCPセッションを十分にコントロールしようとするとすぐ手詰まりです。 WEBサーバがしているやりとりの基礎が足りていないそんな気がしていたのでTCPに目を向けてみました。 行き着いた結果は 待ち受け側とリクエスト側ではボトルネックが違う リクエスト時はTCPのエフェメラルポートが上限 待ち受け時はTCPよりもファイルディスクリプタが上限 になりやすい という良く見かける設定を見直すということになりましたが、どうやってそうなっているのかが今回の成果だ
ハイパーバイザの作り方
「ハイパーバイザの作り方」公開ページ こちらのページはSoftware Design誌の連載記事「ハイパーバイザの作り方」の公開ページです。 「Linuxのしくみを学ぶ - プロセス管理とスケジューリング」も公開中ですので、こちらも是非ご覧ください。 公開中の記事 第１回 x86アーキテクチャにおける仮想化の歴史とIntel VT-x [HTML] [PDF] [ePub] [mobi] [Kindle] 第２回 Intel VT-xの概要とメモリ仮想化 [HTML] [PDF] [ePub] [mobi] [Kindle] 第３回 I/O仮想化「デバイスI/O編」 [HTML] [PDF] [ePub] [mobi] [Kindle] 第４回 I/O仮想化「割り込み編・その１」 [HTML] [PDF] [ePub] [mobi] [Kindle] 付属資料 最近のPCアーキテクチャにお
5.4 ネットワーク・ボンディング
ネットワーク・ボンディングとは、冗長性やスループットの増加に向けて1つのホスト上でネットワーク・インタフェースを組み合せることです。冗長性は、単一の物理リンクで障害が発生した場合に仮想環境のサービスが失われないようにするという点で非常に重要です。このネットワーク・ボンディングは、Linuxネットワーク・ボンディングと同じです。Oracle VMでネットワーク・ボンディングを使用する場合はスイッチ構成が必要となる場合があります。 Oracle VMのネットワーク・ボンディングには3つのモードがあります。 アクティブ/パッシブ: アクティブなNICが1つと、休止状態のNICが1つ存在します。アクティブなNICが停止すると、もう一方のNICがアクティブになります。 リンクの集約: 集約されたNICが1つのNICとして機能する結果としてスループットが高くなります。 ロード・バランシング: マシンの
Erlangのメッセージングでバッファを使う - 備忘録、はじめました。
Erlang Angerの3章、3.3.2あたりで過負荷についての対処法として、キューのバッファを作るのが効果的という話が載っていたので、実際にどのくらい差が出るのか簡単に計測してみた話です。 問題設定： この二つの設定に対して、1,000〜500,000メッセージをbenchサーバーから並列で送信します。 PCの環境: OS: Linux 4.10.13-1-ARCH x86_64 GNU/Linux CPU: Intel® Core™ i3-4160 CPU @ 3.60GHz MEM: 16G バッファなし echoサーバー handle_castコールバックに処理を追加しました。 受け取るリクエストの中身の送り主FromSenderにMsgを返信します。 handle_cast({echo, Msg, FromSender}, State) -> FromSender ! Msg,
nginxのTCPロードバランシングを試す - CLOVER🍀
先日、nginxのHTTPでのロードバランシングを試しました。 nginxのHTTPロードバランシングを試す - CLOVER 次は、もっと汎用的にTCPでのロードバランシングをしてみたいと思います。なお、今回はTCPのみで扱いますが、UDPでのロードバランシングも可能なようです。 ドキュメント 主要に利用するモジュール的には、 Module ngx_stream_core_module と Module ngx_stream_upstream_module の2つとなります。 また、こちらのドキュメントも参考にしました。 NGINX Docs | NGINX Load Balancing – TCP and UDP Load Balancer MySQLへの接続をロードバランシングしてみよう 今回のTCP接続の対象として、MySQLサーバーを持ち出してみます。 MySQLサーバーが、次の
原因調査用Linuxコマンド | 外道父の匠
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
アセット的なアレを実行バイナリ内に入れる話。 | さにあらず
結論#go 言語でウェブアプリケーション書くなら、go-bindata使うべし。 はじめに#go で書いたサーバは一つのバイナリに全部入るからデプロイが楽だという話がありますけども、それは全部のコードを go で書いた時だけです。 ウェブアプリケーションでは、ユーザインターフェース用のテンプレートファイルなど、どうしても go のコードではないリソースが発生します。 例えばテンプレートをパーズする標準 API を見ると、こんな風になっています。 html/template#ParseFiles func ParseFiles(filenames ...string) (*Template, error) { return parseFiles(nil, filenames...)}コピー この API 構造はソースコードを配置しているディレクトリ構造が単純だと特に問題ないのですが、少し複雑
Go で 1024 以下のポートを Listen するアプリを作る - methaneのブログ
Go はネットワークアプリケーションを手軽に書ける言語ですが、例えば 80 番ポートなど、 root でしか bind できないアドレスを Listen するアプリケーションを、 root でないユーザーで動かすのは地味に面倒です。 普通はソケットを bind してから setuid/setgid するのですが、 Linux では setuid が呼び出したスレッドしか適用されないという問題があり、 Go との相性が悪いからです。 参考 対処方法として、 Linux では capabilities を使って非 root ユーザーでも 1024 番以下を bind できるようにし、 Mac OS X などでは bind してから setuid するようにする。 先に root で bind したソケットを Go のプログラムに渡す。 2番めの方法を使うサンプルプログラムを書いておきます. $
Delta - HTTP Shadow Proxy Server Written in Go - Kentaro Kuribayashi's blog
I just created a tool named "Delta". It's the first Go code for me. The reason why I created and wrote it in Go is that I just wanted to learn Go by writing some lines of code ;) https://github.com/kentaro/delta What's "Delta"? Delta is an HTTP shadow proxy server that sits between clients and your server(s) to enable "shadow requests". It's actually just a Go port of Kage. You can consult the doc
Slowloris HTTP DoS 攻撃について
ちょっと前に Apacheに新たな脆弱性発見 - スラッシュドット・ジャパン で紹介されていた脆弱性なんですけど・・・会社のお達しで各サービス毎に状況報告ってイベントがあったので、ちょいと脆弱性試験してました。そのまとめです。 Apacheに、DoS攻撃に繋がる脆弱性が新たに見つかったそうだ（本家/.記事より） この脆弱性は、これを利用したHTTP DoSツール「Slowloris」がリリースされたことから明らかになったとのこと。この攻撃ツールはApacheに不完全なリクエストヘッダーを送り続けるもので、Apacheが最後のヘッダが送られてくるのを待つ間、偽のヘッダを送ることで接続をオープンにし続け、Apacheのプロセスを一杯にさせるものだという。 脆弱性はApache 1.x、 2.x、 dhttpd、 GoAhead WebServer、そしてSquidにて確認されているが、IIS6
こんなに簡単！ Linuxでロードバランサ (2) : DSAS開発者の部屋
前回までで、 複数のWebサーバにロードバランスする というところまではできました。 これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。 このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。 というわけで今回は冗長化のお話、 リアルサーバのヘルスチェック を紹介したいと思います。 今回はkeepalivedを使います。 おおざっぱにいうと、keepalivedは2つの機能を提供します。 1. ヘルスチェック機構と連携したIPVSでのリアルサーバの管理 (--check) 前回ipvsadmコマンドを使って行ったような、バーチャルIPアドレス (VIP) やリアルサーバの管理を設定ファイルに記述す
nginx で特定のドメインや特定のディレクトリへの IP アドレスによるアクセス制限をする方法
server { listen 80; server_name example.com; location ~^/admin { allow 192.168.0.1; deny all; } } location 内に設定すれば、特定のファイル名にはアクセスさせないとか、特定のディレクトリにはアクセスさせないなどの様々な設定が可能です。.htaccess でアクセス制限をかけていた人は、.htaccess が使えないのでアクセス制限が効いてないと思いますので、nginx に乗り換えたらまず最初にチェックしたい項目ですね。
nginx連載5回目: nginxの設定、その3 - locationディレクティブ
locationディレクティブはパスの条件が評価されて選ばれたものが適応されます。この条件はパスの文字列の前方一致あるいは正規表現による評価です。この評価の順番は以下のようになります。 前方一致（"=", "^~", プレフィックスなし）の条件の評価を実施 最も一致する条件を選ぶ。 選ばれた条件が、完全一致で、プレフィックスが"="であれば、そこで評価を終了し、そのlocationディレクティブを適応する。 選ばれた条件のプレフィックスが"^~"であれば、そこで評価を終了して、そのlocationディレクティブを適応する。 正規表現（"~", "~*"）の条件の評価を実施 正規表現の条件を設定ファイルに定義した順番に評価する。一致したら、そこで評価を終了して、そのlocationディレクティブを適応する。 前方一致の評価で選ばれた条件のlocationディレクティブを適応する。 ここで注意
ブラウザキャッシュによる HTTP 高速化チューニング
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サーバサイドKotlinでGraphQLをやってみよう - Kotlin Fest 2019 - / Server side Kotlin + GraphQL
Why are Java server-side developers not adopting Kotlin?