Chapter 1: I/Oモデルの進化
はじめに
このチャプターでは、コンピュータシステムにおけるI/O（入出力）モデルの歴史的進化と、現代の高性能サーバーアプリケーションで使用される様々なI/Oパターンについて学習します。I/Oモデルの理解は、スケーラブルなネットワークアプリケーションを構築する上で不可欠です。
学習目標
このチャプターを完了すると、以下のことができるようになります：
- ブロッキングI/OとノンブロッキングI/Oの違いを説明できる
- 同期I/Oと非同期I/Oの概念を理解する
- select/pollの歴史的背景と制限を理解する
- イベント駆動アーキテクチャの基本原理を説明できる
- I/O多重化の概念とその利点を理解する
- ZigにおけるI/Oアプローチの特徴を把握する
1. I/Oモデルの基礎
1.1 I/Oとは何か
I/O（Input/Output）は、プログラムが外部デバイス（ディスク、ネットワーク、キーボードなど）とデータをやり取りするプロセスです。ネットワークプログラミングにおいて、I/Oは主にソケット操作を指します。
1.2 なぜI/Oモデルが重要なのか
アプリケーションの性能は、しばしばI/O処理によって決定されます。
CPU処理時間: [====] (速い)
メモリアクセス: [========] (中程度)
ディスクI/O: [======================] (遅い)
ネットワークI/O: [============================] (非常に遅い)
I/Oバウンドなアプリケーション（Webサーバー、データベース、チャットサーバーなど）では、適切なI/Oモデルの選択がパフォーマンスを大きく左右します。
2. ブロッキングI/O vs ノンブロッキングI/O
2.1 ブロッキングI/O（Blocking I/O）
ブロッキングI/Oは最もシンプルなI/Oモデルです。I/O操作が完了するまで、プログラムの実行が停止（ブロック）されます。
const std = @import("std");
const net = std.net;
pub fn blockingRead() !void {
const address = try net.Address.parseIp("127.0.0.1", 8080);
const stream = try net.tcpConnectToAddress(address);
defer stream.close();
var buffer: [1024]u8 = undefined;
// この行でプログラムがブロックされる
// データが到着するまで待機
const bytes_read = try stream.read(&buffer);
std.debug.print("受信: {s}\n", .{buffer[0..bytes_read]});
}
ブロッキングI/Oの動作フロー：
アプリケーション カーネル デバイス
| | |
|--- read() -------->| |
| |--- 読み込み ---->|
| [待機中...] | |
| |<--- データ ------|
|<--- データ --------| |
| | |
続行 | |
利点：
- シンプルで理解しやすい
- デバッグが容易
- エラーハンドリングが直感的
欠点：
- 1つの接続しか処理できない（スレッドあたり）
- 多数の接続を扱うには多数のスレッドが必要
- スレッドのオーバーヘッド（メモリ、コンテキストスイッチ）
2.2 ノンブロッキングI/O（Non-blocking I/O）
ノンブロッキングI/Oでは、I/O操作がすぐに完了しない場合でもプログラムはブロックされません。代わりに、エラーコードが返されます。
const std = @import("std");
const os = std.os;
const linux = os.linux;
pub fn nonblockingRead(fd: os.fd_t) !void {
// ソケットをノンブロッキングモードに設定
const flags = try os.fcntl(fd, os.F.GETFL, 0);
_ = try os.fcntl(fd, os.F.SETFL, flags | os.O.NONBLOCK);
var buffer: [1024]u8 = undefined;
while (true) {
const result = os.read(fd, &buffer);
if (result) |bytes_read| {
if (bytes_read == 0) {
// 接続が閉じられた
break;
}
std.debug.print("受信: {s}\n", .{buffer[0..bytes_read]});
break;
} else |err| {
if (err == error.WouldBlock) {
// データがまだ利用可能でない
// 他の処理を実行できる
std.debug.print("データ待機中...\n", .{});
std.time.sleep(10 * std.time.ns_per_ms);
continue;
} else {
return err;
}
}
}
}
ノンブロッキングI/Oの動作フロー：
アプリケーション カーネル
| |
|--- read() -------->|
|<--- EAGAIN --------| (データなし)
| |
| [他の処理] |
| |
|--- read() -------->|
|<--- EAGAIN --------| (まだデータなし)
| |
| [他の処理] |
| |
|--- read() -------->|
|<--- データ --------| (データ到着!)
利点：
- 単一スレッドで複数の接続を処理可能
- リソース効率が良い
欠点：
- ビジーウェイト（busy-wait）が発生しやすい
- CPUを無駄に消費する可能性
- 複雑なロジックが必要
3. 同期I/O vs 非同期I/O
3.1 同期I/O（Synchronous I/O）
同期I/Oでは、I/O操作の完了を待ってから次の処理に進みます。ブロッキングI/OもノンブロッキングI/O（ポーリング型）も、実際には同期I/Oの一種です。
// 同期I/Oの例
pub fn syncOperation() !void {
const data1 = try readFile("file1.txt"); // 完了を待つ
const data2 = try readFile("file2.txt"); // 完了を待つ
const result = process(data1, data2);
try writeFile("output.txt", result); // 完了を待つ
}
3.2 非同期I/O（Asynchronous I/O）
非同期I/Oでは、I/O操作を開始した後、その完了を待たずに次の処理に進みます。操作が完了したら、コールバックやイベント通知を通じて結果を受け取ります。
// 非同期I/Oの概念例（疑似コード）
pub fn asyncOperation() void {
// I/O操作を開始し、すぐに戻る
asyncReadFile("file1.txt", onFile1Complete);
asyncReadFile("file2.txt", onFile2Complete);
// 他の処理を続行できる
doOtherWork();
}
fn onFile1Complete(data: []const u8) void {
// file1の読み込み完了時に呼ばれる
processData(data);
}
fn onFile2Complete(data: []const u8) void {
// file2の読み込み完了時に呼ばれる
processData(data);
}
同期 vs 非同期の比較：
同期I/O:
Task1 [==========]
Task2 [==========]
Task3 [==========]
時間 ---------------------->
非同期I/O:
Task1 [====]
Task2 [====]
Task3 [====]
[待機時間を有効活用]
時間 -------->
4. I/O多重化の概念
4.1 問題：C10K問題
2000年代初頭、「C10K問題」が注目されました。これは、1台のサーバーで同時に10,000（C10K = Client 10,000）の接続を処理する問題です。
従来のアプローチ（スレッドプール）:
- 10,000接続 = 10,000スレッド
- 1スレッドあたり約1MB のスタック
- 合計: 約10GB のメモリ（スタックだけで！）
- コンテキストスイッチのオーバーヘッド
4.2 解決策：I/O多重化
I/O多重化は、単一のスレッドで複数のI/O操作を監視する技術です。
I/O多重化の基本概念:
[アプリケーション]
|
| 1つのスレッド
v
[I/O多重化API]
(select/poll/epoll)
|
監視対象のファイルディスクリプタ
/ | | \
fd1 fd2 fd3 fd4 ... fd10000
主なI/O多重化技術：
| 技術 | プラットフォーム | 最大監視数 | パフォーマンス | 導入年 |
|---|---|---|---|---|
| select | POSIX | 1024* | O(n) | 1983 |
| poll | POSIX | 無制限 | O(n) | 1986 |
| epoll | Linux | 無制限 | O(1)** | 2002 |
| kqueue | BSD/macOS | 無制限 | O(1) | 2000 |
| IOCP | Windows | 無制限 | O(1) | 1995 |
: FD_SETSIZEによる制限 : アクティブな接続に対して
5. select/pollの歴史と制限
5.1 select システムコール
selectは最も古いI/O多重化メカニズムです（1983年、BSD Unix 4.2で導入）。
const std = @import("std");
const os = std.os;
const linux = os.linux;
pub fn selectExample(sockets: []os.socket_t) !void {
var read_fds: linux.fd_set = undefined;
linux.FD_ZERO(&read_fds);
var max_fd: i32 = 0;
for (sockets) |sock| {
linux.FD_SET(@intCast(sock), &read_fds);
if (sock > max_fd) max_fd = @intCast(sock);
}
var timeout = linux.timeval{
.tv_sec = 5,
.tv_usec = 0,
};
const ready = linux.select(
max_fd + 1,
&read_fds,
null,
null,
&timeout
);
if (ready > 0) {
for (sockets) |sock| {
if (linux.FD_ISSET(@intCast(sock), &read_fds)) {
// このソケットは読み込み可能
try handleRead(sock);
}
}
}
}
fn handleRead(sock: os.socket_t) !void {
var buffer: [1024]u8 = undefined;
const bytes_read = try os.read(sock, &buffer);
std.debug.print("受信: {d} バイト\n", .{bytes_read});
}
selectの動作フロー：
1. ファイルディスクリプタセットを準備
[fd_set] = {fd1, fd2, fd3, ..., fdN}
2. カーネルにセットをコピー
User Space -> Kernel Space
3. カーネルが全FDをチェック
for each fd in fd_set:
if fd has data:
mark as ready
4. 準備完了セットをユーザー空間にコピー
Kernel Space -> User Space
5. アプリケーションが準備完了FDを処理
selectの制限：
- FD_SETSIZE制限: 通常1024個まで
- O(n)の複雑度: 全FDをスキャン
- メモリコピー: カーネル空間とユーザー空間間でfd_setをコピー
- セットの再構築: 毎回fd_setを再設定する必要
5.2 poll システムコール
pollはselectの改良版として1986年に導入されました。
const std = @import("std");
const os = std.os;
const linux = os.linux;
pub fn pollExample(sockets: []os.socket_t) !void {
var fds = try std.heap.page_allocator.alloc(linux.pollfd, sockets.len);
defer std.heap.page_allocator.free(fds);
for (sockets, 0..) |sock, i| {
fds[i] = linux.pollfd{
.fd = @intCast(sock),
.events = linux.POLL.IN, // 読み込み可能イベント
.revents = 0,
};
}
const timeout_ms: i32 = 5000; // 5秒
const ready = linux.poll(fds.ptr, @intCast(fds.len), timeout_ms);
if (ready > 0) {
for (fds) |pfd| {
if (pfd.revents & linux.POLL.IN != 0) {
// このソケットは読み込み可能
try handleRead(@intCast(pfd.fd));
}
if (pfd.revents & linux.POLL.ERR != 0) {
// エラーが発生
std.debug.print("Error on fd {d}\n", .{pfd.fd});
}
}
}
}
fn handleRead(sock: os.socket_t) !void {
var buffer: [1024]u8 = undefined;
const bytes_read = try os.read(sock, &buffer);
std.debug.print("受信: {d} バイト\n", .{bytes_read});
}
pollの改善点：
pollの制限：
5.3 select/pollのパフォーマンス問題
パフォーマンス比較（10,000接続の場合）:
select/poll:
- 毎回10,000個のFDをスキャン
- カーネル/ユーザー空間のコピー: 10,000 * sizeof(fd_set/pollfd)
- 時間複雑度: O(n)
疑似コード:
for i = 0 to 10000:
if fd[i] has event:
process(fd[i])
6. イベント駆動アーキテクチャ
6.1 イベント駆動とは
イベント駆動アーキテクチャは、イベントの発生に応じて処理を実行するプログラミングパラダイムです。
イベントループの基本構造:
┌─────────────────────────────────────┐
│ イベントループ（Event Loop） │
│ │
│ while (true) { │
│ events = wait_for_events() │
│ for each event in events { │
│ dispatch(event) │
│ } │
│ } │
└─────────────────────────────────────┘
↑ ↓
│ │
[イベント通知] [イベント処理]
│ │
┌────┴────┐ ┌────┴────┐
│ Socket │ │ Handler │
│ Timer │ │ Router │
│ Signal │ │ Process │
└─────────┘ └─────────┘
6.2 Zigでのイベント駆動アプローチ
Zigは明示的でシンプルなアプローチを提供します：
const std = @import("std");
pub const EventLoop = struct {
events: std.ArrayList(Event),
handlers: std.AutoHashMap(EventType, HandlerFn),
pub fn init(allocator: std.mem.Allocator) EventLoop {
return EventLoop{
.events = std.ArrayList(Event).init(allocator),
.handlers = std.AutoHashMap(EventType, HandlerFn).init(allocator),
};
}
pub fn registerHandler(
self: *EventLoop,
event_type: EventType,
handler: HandlerFn
) !void {
try self.handlers.put(event_type, handler);
}
pub fn run(self: *EventLoop) !void {
while (true) {
// イベントを待機
const event = try self.waitForEvent();
// 対応するハンドラを実行
if (self.handlers.get(event.type)) |handler| {
try handler(event);
}
}
}
fn waitForEvent(self: *EventLoop) !Event {
// ここでI/O多重化を使用
// (epoll, kqueue, IOCPなど)
return Event{ .type = .socket_read, .data = undefined };
}
};
pub const EventType = enum {
socket_read,
socket_write,
timer_expired,
signal_received,
};
pub const Event = struct {
type: EventType,
data: []const u8,
};
pub const HandlerFn = *const fn(Event) anyerror!void;
7. 実世界の例
7.1 Nginxのアーキテクチャ
Nginxは、イベント駆動アーキテクチャの成功例です：
Nginx アーキテクチャ:
Master Process
|
├─ Worker Process 1 ─┐
├─ Worker Process 2 ├─ イベントループ (epoll/kqueue)
├─ Worker Process 3 │ ├─ accept()
└─ Worker Process N ─┘ ├─ read()
├─ process()
└─ write()
各Workerは:
- 数千の接続を処理
- ノンブロッキングI/O
- epoll/kqueue による効率的な多重化
7.2 Redisのシングルスレッドモデル
Redisは、シングルスレッドでありながら高性能を実現：
Redis イベントループ:
┌──────────────────────────────────┐
│ メインスレッド（シングル） │
│ │
│ while (true) { │
│ // ファイルイベント (I/O) │
│ processFileEvents() │
│ │
│ // 時間イベント │
│ processTimeEvents() │
│ } │
└──────────────────────────────────┘
利点:
- ロック不要
- コンテキストスイッチなし
- シンプルなデバッグ
- 予測可能な性能
8. ZigにおけるI/Oアプローチ
8.1 Zigの設計哲学
Zigは以下の原則に基づいています：
8.2 Zigの標準ライブラリI/O
const std = @import("std");
// Zigのアプローチ例
pub fn zigIoExample() !void {
// エラーハンドリングが明示的
const file = try std.fs.cwd().openFile("data.txt", .{});
defer file.close();
var buffer: [4096]u8 = undefined;
const bytes_read = try file.read(&buffer);
// アロケータが明示的
var gpa = std.heap.GeneralPurposeAllocator(.{}){};
defer _ = gpa.deinit();
const allocator = gpa.allocator();
// メモリ管理が明示的
const data = try allocator.alloc(u8, bytes_read);
defer allocator.free(data);
std.mem.copyForwards(u8, data, buffer[0..bytes_read]);
}
8.3 非同期I/Oの将来
Zigはasync/awaitのサポートを検討中です：
// 将来的な非同期構文（実験的）
pub fn asyncExample() !void {
const frame = async readFileAsync("data.txt");
// 他の処理
const data = await frame;
processData(data);
}
まとめ
このチャプターでは、I/Oモデルの基礎から進化までを学習しました：
次のチャプターでは、これらの問題を解決するepoll*について深く学習します。
参考資料
次のステップ
Chapter 2では、epollの詳細な仕組みとZigでの実装方法を学習します。