Webサーバーアーキテクチャ進化論2023
はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ？」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自
マルチスレッド・プログラミングの道具箱
まえがき クラウド上の仮想サーバから手元のスマートフォンまで、いまや複数のCPUコアを搭載するマルチコアはどこにでもある環境になりました。ハードウェア側が並列(Parallel)・並行(Concurrent)処理に向けて急速に進化する一方で、ソフトウェア側つまりプログラミング言語の進化はさほど追い付いていません。並行処理記述の手軽さを求めた Go言語 や、マルチスレッド処理の安全性を重視する Rust言語 などが登場してはいるものの、「普通にプログラムを記述するだけで複数CPUコア環境で高速に走るプログラミング言語」は遠い夢物語のままです。 モダンなプログラミング言語や並列・並行処理ライブラリは、複雑で難解なマルチスレッド処理を直接記述しなくてすむよう、安全性・利便性の高い抽象化レイヤを提供します（例：Go言語のgoroutineとchannel、Rust言語の Rayonライブラリ）。し
新雑誌「n月刊ラムダノート」の『「コルーチン」とは何だったのか？』の草稿を公開します - まめめも
『Ruby でつくる Ruby』などでお世話になっているラムダノートが、新しい雑誌「n月刊ラムダノート」を創刊しました。 www.lambdanote.com コンピュータ関係の技術情報の記事だけが載るそうです。創刊号は、『TCPの再送制御機構』、『「コルーチン」とは何だったのか？』、『MLOpsの歩き方』、の 3 本です。 『TCP の再送制御機構』は、パケットを送ってから返事が来るまでの RTT (Round-Trip Time) を計測する方法や、RTT を使った再送のアルゴリズムや、RTT を使わない再送のアルゴリズムなど、TCP の再送に関する仕様・実装の歴史から最新提案までを、日本語話者の中では間違いなく世界一詳しい第一人者である西田佳史さん（@nsd）が広く深く紹介しています。 『「コルーチン」とは何だったのか？』は、ぼくが書きました。伝統的なコルーチンの説明から、JavaS
ForkJoinPoolとblocking
以下は、いつも通り、私のざっくりな調査内容をまとめるものだから、もし、内容に誤りがあったら報告してほしい。(想像も含むので) 前提目的としては、akkaベースのウェブフレームワーク(sprayかakka-http)で、複数のリクエストを同時に受けた時にサーバのCPUをフル活用するためにはどうすることである。 フル活用とは、あるスレッドがIOなどで寝た場合、他のタスクにCPUを割り当てて、CPUを使う処理を常に全力で実行することである。こうすると、最善では、結果的に全タスクを処理する時間は、全計算を行った時間まで短縮出来る。こういうテクニックは、GPUにおいてメモリ転送と計算をオーバーラップさせてメモリ転送を償却する形でも用いられる。 さて、ウェブフレームワークは何らかのポートにbindして、そこからリクエストを捌く。akkaでは、この時のスレッドの割当方法をdispatcherなりExec
JavaScriptは如何にしてAsync/Awaitを獲得したのか: がおさんち 技術部屋
JavaScriptを記述する上で、避けて通れないのが非同期処理。 人類は、長い年月、この非同期的な処理を「如何にして書きやすく、読みやすく記述するか」について探求してきました。 要するに†闇†の塊なのですね。（闇に飲まれよ！！！！） この物語は、そんな†闇†の存在だった非同期処理を、人類がどのように苦しみ、そしてどのように解決していったかを書いていくポエムである。 補足：厳密には、JSはシングルスレッドで動くため、非同期処理は存在しない！と言ってしまえばそこまでなのですが、今回はsetTimeoutやajax通信、onloadイベント登録など、見かけ上、非同期的な挙動を示すものすべてを対象に話していきます。 第一章 ～人類はsetTimeoutを採用しました～ 古代のJavaScriptで、以下のような処理をしたい場合、どうしていただろうか。 「ブラウザ更新直後に『a』を表示し、その2秒
並列に実行するんだけど並列度も制限したい時 - Qiita
まあ例を挙げて話したほうがわかりやすい気がするので例をあげると、たとえばあなたはオンプレミスからコンテナまで総計数千台のホスト的な何かで構成されたシステムを管理する必要があります、と。この規模になってくると当然日々何かが壊れては何かが直っていくのはそういうものですね。で、じゃあ、刻一刻と変わる管理台帳と実際の環境の整合性をチェックすることを考える、と。すると要件としては、 管理台帳から存在するはずのホスト名とそのIPアドレスの一覧を引っ張ってくる そこからまずホスト名をババババと名前解決して管理台帳どおりのIPアドレスが解決されるか確認する 次にそいつらが生きてると限らんので、解決されたIPアドレスに向かってICMP Echoパケットをババババと打ちまくって反応を見る ping応答あった「なにか」が、本当に管理台帳どおりのホストとは限らないので、とりあえずsshで入れるか確認する 入れたら
C++ マルチスレッド 入門
エラーハンドリングとはどうあるべきかについての考察。 Boost.勉強会 #3 関西 ( http://kokucheese.com/event/index/4335/ )にて発表。
const, mutableキーワードとスレッド安全性 - yohhoyの日記
C++11標準ライブラリにおいて const, mutable キーワードが持つセマンティクスと、自作クラスのスレッド安全性に関するイディオムについてメモ。本記事の内容はC++ and Beyond 2012でのHerb Sutter氏プレゼン "You Don't Know const and mutable" に基づく。 要約： C++98/03：constメンバ関数はオブジェクトに対して「logical const（論理的const）」な操作であることを意味する。constメンバ関数ではmutableメンバ変数の変更操作を含む可能性があるが*1、クラス外部から観測する限りはconst（不変操作）のように振る舞う。 C++11以降：C++03以前のセマンティクスに加えて、「同一オブジェクトのconstメンバ関数を複数スレッドから同時に呼び出してもよい」というスレッド安全性を表明する。標
条件変数 Step-by-Step入門 - yohhoyの日記（別館）
多くのプログラミング言語では、マルチスレッド処理向け同期プリミティブとして「ミューテックス(mutex)」と「条件変数(condition variable)」を提供しています*1 *2。ミューテックスは排他制御機構として有名ですし、その動作もロック(lock)／アンロック(unlock)と比較的理解しやすいため、不適切に利用されるケースはあまり無いと思います*3。一方、条件変数の動作仕様はしばしば誤解され、不適切な利用による並行性バグに悩まされるケースが多いようです。 本記事では、スレッドセーフなFIFO(First-In-First-Out)キューを段階的に実装していく事例を通して、条件変数の適切な使い方について説明していきます。例示コードではC++11標準ライブラリを用いますが、Pthreads(POSIX Threads)やC11標準ライブラリへは単純に読み替え可能です（→Pthr
ヘッダオンリーで簡単なタスクライブラリhwm.taskを作ってみた。 - How to disappear completely
勉強会での発表 先日Sapporo.cppとCLR/Hの合同勉強会を開催し、 僕はC++11のスレッドについて紹介をしました。 規格書で読むC++11のスレッド from Kohsuke Yuasa この発表では、C++11で導入されたスレッドライブラリの中から、 thread mutex/lock future/promise condition_variable について、それぞれがどんなものかを紹介し、また、それらの機能を使用して簡単なタスクライブラリを作ったという話をしました。 実際のセッションでは、発表時間が足りなくなってしまい、ちゃんとこのhwm.taskを紹介できなかったので、ちょっと残念だったのと、 あと、当日発表したときは未完成なところや微妙なところがもあり、それからもう少し手を加えたりしたので、改めてこのブログで紹介したいと思います。 hwm.task GitHub -
スレッドセーフという幻想と現実 - yohhoyの日記（別館）
この記事はC++ Advent Calendar 2013の15日目にエントリしています。 内容はC++標準ライブラリとスレッドセーフに関する解説になります。 flickr / rennasverden もくじ What's スレッドセーフ？ スレッドセーフという幻想 基本型とデータ競合 C++標準ライブラリとデータ競合 C++標準ライブラリ：シーケンスコンテナ編 C++標準ライブラリ：連想コンテナ編 スレッドセーフ RELOADED 基本的なスレッドセーフ保証 std::shared_ptr<T> std::rand() std::cout （本文のみ約9000字） はじめに マルチスレッド対応の点では他言語に遅れを取っていたプログラミング言語C++ですが、C++11ではようやく標準ライブラリにスレッドサポートが追加されました。C++11スレッドサポートではスレッドクラスstd::thr
マルチスレッドを意識しないマルチスレッド・ライブラリ「Intel Concurent Collections」がおもしろい
「Intel Concurrent Collections for C++」（CnC）とは 実際並列処理はややこしいしおっかないです。大きなキッチンで大勢のコックが包丁とフライパン振り回しているようなもので、ほっとけばしっちゃかめっちゃかになっても不思議じゃない。各人はそれぞれの役割に専念し、他人のふるまいを気にせず勝手に働きながらも全体としては統制のとれた動きを作り出さにゃなりません。mutexで排他制御したりjoinで完了を待ったり、さまざまな道具を駆使して統制のとれた動きを作り出しているのはプログラマであり、そこがいちばん難しく悩ましいところです。 C++,C#あるいはVB,Javaもそうですが、コードは原則的に並べた順に実行されます。 と書けば、まずf()、それが終わればg()、しかるのちh()の順で呼び出されます。たとえこの3つをどの順にやっても（あるいは同時にやっても）構わない
volatile変数とマルチスレッドとの関係についての押し問答（前編） - yohhoyの日記
プログラミング言語C++のvolatile変数がスレッド間の同期機構として機能するか否かという論点について、有りそうな質問とその答えについての簡易メモ。（自身の思考整理用） 結論：このプログラムは可搬性が無く、未定義動作(undefined behavior)を引き起こす。C++11ではvolatile変数でなくatomic変数を用いるべき。C++03以前ではコンパイラ依存の仕組みを利用する。 volatile int running = 1; // 処理スレッド void another_thread() { while (running) { // ??? //... } } // 制御側スレッド void main_thread() { //... running = 0; // ??? } C++言語仕様ではどう定義される？(C++03以前) C++03以前のC++言語仕様ではそも
C++11標準ライブラリのスレッド安全性 - yohhoyの日記
C++11標準ライブラリが提供する機能とスレッド安全性(thread safety)についてのメモ*1。C++03以前では処理系依存。 要約：C++標準ライブラリのオブジェクトでは、少なくとも言語組み込みint型と同様のスレッド安全性を提供する。 基本的なスレッド安全性 C++標準ライブラリが提供するオブジェクトは、個々の関数動作仕様で特記されるケースを除いて、下記の基本的なスレッド安全性を保証する。 異なるスレッド上における異なるオブジェクトに対する操作はデータ競合を引き起こさない。*2（1.10, 17.6.5.9/p2-4） 異なるスレッド上における同一オブジェクトに対する操作は、全スレッドがreadアクセスのみであればデータ競合を引き起こさない。少なくとも一方が変更操作を行う場合はデータ競合を引き起こす。*3 *4（1.10） 明に要求している場合を除いて、引数やコンテナ要素が間接
UNIX上でのC++ソフトウェア設計の定石 (3) - memologue
鉄則3: マルチスレッドのプログラムでのforkはやめよう マルチスレッドのプログラムで、「自スレッド以外のスレッドが存在している状態」でfork*1を行うと、さまざまな問題を引き起こす可能性があります。「問題」の典型例としては、子プロセスのデッドロックが挙げられます。問題の詳細を把握しないまま、マルチスレッドのプログラムで不用意にforkするのはやめましょう！ 何が起きるか 実例から見てみましょう。次のコードを実行すると、子プロセスは実行開始直後のdoit() 呼び出し時、高い確率でデッドロックします。 void* doit(void*) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&mutex); struct timespec ts = {10, 0}; nanoslee
セキュアなソフトウエア開発を支援する資料 | JPCERT コーディネーションセンター
「Java セキュアコーディング 並行処理編」 「Java セキュアコーディング 並行処理編」（原著 CERT/CC「Java Concurrency Guidelines」）は、カーネギーメロン大学ソフトウエア工学研究所の CERTプログラムと Oracle の共同作業の成果である「CERT Oracle Secure Coding Standard for Java」の中から、次のカテゴリに含まれる並行処理プログラミングに関連したガイドラインをまとめた資料です。 可視性とアトミック性(VNA) ロック(LCK) スレッドAPI(THI) スレッドプール(TPS) スレッドの安全性に関する雑則(TSM) セキュアな Java マルチスレッドプログラミングに取り組む際の手引きとしてご活用ください。 本資料に記述されたガイドラインを含む「CERT Oracle Secure Coding S
*nix系のロック方式をトイレにたとえる。 - 為せば成る・・・かもしれない
ずっと探していたテキストがようやく発掘できました。 昔のデータはとっておく物だ。 内容は スピンロックをトイレでたとえると？的な内容です。 探している方もおおいようなので、あえて公開。 ちなみに、ネタもとは確か「働かないプログラマ」というサイト。 2chのプログラマ板からおもしろいネタを引っ張っていたサイトだったと記憶しています。 肝心の文面は続きに。 で、Lock ContentionがLinux並になるのマダー？ 開発者のマンパワーが同じだとして4年ちょっとだよね。 じつはもっと進んでる！というなら(2.3の後半とか？)あと何年かかるか予想できますか？ ----------------------------------------------------------------------------------- > で、Lock ContentionがLinux並に
XLsoft エクセルソフト : マルチスレッド・アプリケーション開発のためのインテル・ガイド
開発ツールスイート インテル® oneAPI ベース・ツールキット インテル® HPC ツールキット インテル® レンダリング・ツールキット インテルの AI ツール クラウド・プラットフォーム インテル® Tiber™ デベロッパー・クラウド コンパイラー インテル® oneAPI DPC++/C++ コンパイラー インテル® Fortran コンパイラー インテル® Fortran コンパイラー・クラシック NVIDIA*/AMD* GPU 向け Codeplay プラグイン パフォーマンス・ライブラリー インテル® oneMKL インテル® IPP インテル® oneTBB インテル® oneDAL インテル® MPI ライブラリー 分析、解析ツール インテル® VTune™ プロファイラー インテル® Inspector インテル® Advisor インテル® Trace Anal
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
boost::asio::socket thread safety
IBM Developer
