React Router v7 の内部構造を探る：リクエストからレンダリングまでの道のり
はじめに React Router は、React アプリケーションにおけるルーティングライブラリのデファクトスタンダードとして長年利用されてきました。v6 で Data API が導入され、フルスタックフレームワークとしての側面が強化されましたが、v7 ではさらに進化し、Vite との統合、Single Fetch、Lazy Loading といったモダンな機能がデフォルトで組み込まれ、より洗練された開発体験とパフォーマンスを提供します。 しかし、これらの機能がどのように連携し、ブラウザのリクエストがどのように処理され、最終的にページが表示されるのか、その内部構造は少し複雑に見えるかもしれません。 この記事では、React Router v7 で構築されたアプリケーションの動作フローを、主要なパッケージやコンポーネントの役割、データ取得の仕組み、レンダリングプロセスなどに焦点を当てて、内
MCPサーバーを利用することはセキュリティ的に安全か?
1. はじめに Model Context Protocol (以下、MCP) は、大規模言語モデル (LLM) と外部データソースやツールを連携させるための便利なオープンプロトコルです。 一方で、MCPサーバーは誰でも作成してGitHubで公開できるため、場合によっては悪意のあるコードが含まれている可能性も否定できません。自作のMCPサーバーに脆弱性を埋め込んでしまうのは自己責任ですが、実際には、公開されているMCPサーバーをマーケットプレイス経由で使用する場合、どの程度の安全性が期待できるのでしょうか？ 本稿では、MCPサーバーのマーケットプレイスの現状と、利用する上での注意点について解説します。 1.1. TL;DR 「誰かが何かを保証してくれるわけで、自己責任で使いましょう」というのが前提です。その中でも一定信用して良いと思われるのは、以下の2つです。それ以外は、公式な保証がない状
The mystery of the hanging S3 downloads
A coworker was experiencing a strange problem with their Internet connection at home. Large downloads from most sites worked fine. The exception was that downloads from a Amazon S3 would get up to a good speed (500Mbps), stall completely for a few seconds, restart for a while, stall again, and eventually hang completely. The problem seemed to be specific to S3, downloads from generic AWS VMs were
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) やリアルサーバの管理を設定ファイルに記述す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サーバサイドKotlinでGraphQLをやってみよう - Kotlin Fest 2019 - / Server side Kotlin + GraphQL
Why are Java server-side developers not adopting Kotlin?