Webサーバーアーキテクチャ進化論2023
はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ？」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自
CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
OSSのサーバ構築自動化ツール、4製品徹底検証 2016年版
OSSのサーバ構築自動化ツール、4製品徹底検証 2016年版：実際に検証済み！OSS徹底比較（3）サーバ構築自動化【前編】（1/9 ページ） 今回は、サーバ構築・運用自動化ソフトの中でも特に利用者の多い、「Chef」「Ansible」「Puppet」「Itamae」の4製品をピックアップ。「各ソフトの実行環境の構築手順」「OSSのブログ／CMS基盤であるWordPressの構築」を通じて、その違いを探る。 増え続けるサーバと比例して増大する運用コスト パーソナルコンピュータに加えて、スマートフォンなどのモバイルデバイスの普及により、インターネットを経由したシステムの利用規模や利用時間の拡大が続いている。B2B、B2C分野でもシステムを利用することが当たり前になっており、ビジネスにおいてコンピュータは不可欠なものとなっている。 そのビジネスを支えるシステムで利用されるサーバの台数も、増加の一
いい機会だし自宅サーバの現状を整理してみる - ラブライブ駆動開発
vector.hateblo.jp 友人が上の記事で録画サーバについて色々書いていたので、自分も自鯖の現状を把握するために書き出してみる。 上記記事と似たようなアジェンダで行く。 前提 あ、私的利用の範囲ですよ。 ほぼ毎日放送されているアニメを録画している また以下のタレントが出演している番組もほぼ録画されている マツコ・デラックス さまぁ～ず TSの増加ペースとしては、1本3〜6GBで1週間で60〜80本ほど(溜まるときは300GB/weekぐらいのペース) 流石に容量増加に耐え切れないので、録画が完了したTSから順次ffmpegにてh.264+aacな720pのmp4に変換される エンコード済のTSは1ヶ月ほど保持してから削除 サーバについて 自鯖その1(NAS) HP ProLiant Microserver N40L AMD Turion II NEO 1.5GHz 2Core U
サーバ/インフラエンジニア養成読本「ログ収集〜可視化編」を頂きました！ - oranie's blog
改めて著者の方々と実際に僕に本を送付する手配をして頂いた@yoshi_kenさん本当にありがとうございます。 社内の他のエンジニアが「本頂きました！^^」とかのツイートをしている*1のを見る度に「ブルジョワが！( ﾟдﾟ)､ﾍﾟｯ」とか思っていたらついに僕も貰える時が来るなんて・・・。もう二度とこんな機会はこなさそうなので、保存版として額に入れておこうかと思いましたが、せっかくなので読んでみました。 特集1「ログ解析から始めるサービス改善」 ここではまず「なぜログ解析をする必要があるのか？」「何のためにそもそもやるの？」という事が分かりやすく書かれているかなと思います。特にログは大規模であれば膨大な量や情報を抱える為、やみくもに「これも取ってみよう」「あれも計測してみよう」という事をやっても結局「そもそもなんでこれ必要なんだっけ？」で終わるパターンもあるので、まずここを読んで自分に必要な事
2014年のウェブシステムアーキテクチャ - stanaka's blog
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
監視ソフトをNagiosからSensuに切り替えて2ヶ月経ったのでまとめた - Glide Note
新規サービス用の監視をNagiosからsensuに切り替えて2ヶ月経ったので、 導入時の調査で社内で公開してたissueと、投入して2ヶ月間運用した記録を公開しておこうと思う。 というか以前Sensuの事を書くと公言していたのに、すっかりサボっていて 昨日@ma0eさんのブログを見て下記のやり取りを思い出して急いで書いた… @ma0e We started using it. @glidenote will report the detail soon, I think. — kentaro (@kentaro) 2013, 10月 30 @kentaro @glidenote that would be nice — Mitsutoshi Aoe/maoe (@ma0e) 2013, 10月 30 導入環境はCentOS 6.4で、利用しているsensuのバージョンは0.12.1-1にな
今さら聞けない Immutable Infrastructure - 昼メシ物語
Immutable （不変な） Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
G-WAN > Web Application Server
G-WAN better uses CPU Cores to make the Internet of Things fly thousand times higher ! Leverage legacy servers and low-consumption CPUs to do more with less! With 1GHz in 2000 and 3GHz in 2002 10GHz CPUs were expected in 2005. Today, we should run much faster CPUs but: We're not going to have faster processors. Instead, making software run faster in the future will mean using parallel-programming
「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」始めました - K.Maebashi's はてなブログ
以前から「誰か書いてくれませんかね」とか言っていた「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」ですが、誰も書いてくれないので自分で書きました。 本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう http://kmaebashi.com/programmer/webserver/index.html 現状、合計で140行くらいのJavaプログラムで、普通に画像やCSSを含むWebページが表示できています。こちらのページの下のほうにも画像を貼っていますが、こんな感じで、ローカルのファイルシステムに置いてある私のWebサイトのトップページが表示できていますし、もちろんリンクをクリックして遷移することもできます。 「えっ? Webサーバってこんなに簡単に書けるの?」と思う人も多いのではないでしょうか。 もちろんこんなのは「わかっている人」から
なんかサーバ構築にやたらと時間かかるんだけど何で時間かかるのか考えてみた - tumblr
最近サーバ構築を仕事でやっているんだけど、どうにも時間がかかってしょうがない。 色々と面倒な制限があるため、それに合わせるように通常の手順を色々変更しなければならないんだけど、それにしても自分の見積もりより大幅に時間がかかっている。自分の見積もり精度は確かに良くはないんだけどもそれを差っ引いても時間がかかっている気がしてしょうがない。 何故かと考えてみた。 1. 何をやったらいいのか分からない 自分でサーバ構築した経験はあるものの、ほとんど全て自分の開発サーバや勉強用や社内で使うようなものだ。apache入れて終わり、iptablesとか面倒なものは使わない、みたいな場合が多い。なのでいくつかの要件を満たすように複数のミドルウェアの設定に一貫性を持たせた上で構築するということはしたことがなかった。 自分の開発マシン内で使うVMであればcurlを叩けばレスポンスが返ってくるもので普通は十分だ
#isucon2 に向けて、かなり間違った方向に本気出してみた（recaro 誕生秘話） : DSAS開発者の部屋
先日、NHNさん主催の #isucon2 に @methane と参加してきたので、事前準備や当日の状況などを数回に分けてレポートしようと思います。#isucon2 が終わって少し体調を崩していた @pandax381 です。 すべてはここから始まった 社内のIRCチャンネルで #isucon2 の開催が話題になっていて、隣の席の @methane が真っ先に参加を表明し、パートナーを募集していました。僕はというと、面白そうだなぁと思いつつも、WebアプリとかDBとよくわかんないし戦力にならんだろうと「椅子投げコンテストｗ」とか言ってスルーしていたんですが、@methane から「一緒に出ようぜ！」とルフィばりの熱い誘いを受け、参加を決意することになりました。ちょうど #isucon2 開催１ヶ月前の話です。 L7未満は全部なんとかしてくれ！ そんなこんなで #isucon2 への参加が決
サーバーマシン1台で同時接続者数1万名を実現するにはどうすればいいのかというノウハウと考え方
CEDEC 2012ではドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？ということで、オンライン作品であるドラクエXを支えるサーバの構成が講演されましたが、ゲームサーバー＆ネットワークエンジン「ProudNet」の開発者であるNettention社のCEOであるHyunjik Baeさんは、韓国のオンラインゲームのサーバー開発と利用の経験を通して大規模プレイヤーのためのリアルタイムネットワーク同期技術について講演しました。 サーバーマシン１台でMMO同時接続者数10,000名を実現する方法 | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/AB/C12_I0284.html Hyunjik Bae： こんにち
cron等をつかって外部のAPIに問い合わせる場合は、毎時0分を避けるのが大人のマナー - blog.nomadscafe.jp
なんかtwitterで書いたらウケたっぽいので cronをつかって外部のAPIに問い合わせる場合は、毎時0分をさけるのオススメ！！！！お兄さんとの約束だ！！！ — masahiro nagano (@kazeburo) August 9, 2012 某サービスのAPIへの問い合わせ件数を調べると、毎時 0分台(0秒から59秒)のアクセスは1分から59分までの1分間の平均アクセス数の5倍から8倍にもなります。 これはおそらく、crontabの設定が 0 * * * * /path/to/call_foreign_api になっていることが多いからじゃないかなぁと思うのです。 その結果、サーバのロードアベレージは このように毎時0分だけ跳ね上がってしまいます。サービスを快適に提供できなくなる可能性があるので、APIの利用を制限したり、サーバを追加しなければなりません。これはサービス利用者、サー
いい加減、>/dev/null 2>&1と書くのをやめたらどうか (追記あり) · DQNEO日記
はじめに これから書く内容は、シェルスクリプトをばりばり書いている現場(サーバエンジニア・インフラエンジニア)向けのものではありません。 年に数回crontabをいじるような現場(サーバに詳しくないアプリケーションプログラマが多数を占めるような現場とか、Webデザイナや非プログラマがcrontabをおそるおそるいじったりするような現場)を想定しています。 >/dev/null 2>&1 の問題点 この記法の問題点は、「覚えにくい、間違えやすい、間違ってても気づかない」ということです。 初心者を迷わせる要素がこんなにあります。 >/dev/nullは先か後か 1と2はどちらが先か &はどこに書くのか よって下記のように多種多様なミスが起こり得ます。 2>&1 >/dev/null >/dev/null 1>&2 >/dev/null 2>1& >/dev/null &2>1 これをぱっと見て
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSD VPS Servers, Cloud Servers and Cloud Hosting - Vultr.com
CloudCore VPS
「秒速で1億PV稼ぐ条件」をエンジニアに聞いてみた
ORITY370の日記