Posted inプログラミング

Goの並行処理：GoroutineとChannelで構築する高パフォーマンスシステム

Programming tutorial - IT technology blog
Programming tutorial - IT technology blog

Goにおける並行処理の考え方

ほとんどのプログラミング言語では、並行処理は複雑なライブラリや後付けの機能として追加されています。しかし、Goは違います。Goは設計の初日から、CSP（Communicating Sequential Processes）モデルに従って並行処理のために構築されました。Goの格言によくあるのが、「メモリを共有することで通信するのではなく、通信することでメモリを共有せよ」という言葉です。

私がPythonのスレッドやNode.jsのイベントループから移行した際、Channelのシンプルさは驚きでした。従来のスレッド処理は、タイトロープの上でナイフをジャグリングしているような感覚になることがよくあります。対照的に, Goは高いスループットを処理するための構造化された方法を提供します。これにより、標準的なOSスレッドのような重いオーバーヘッドなしに、1秒間に数千のリクエストを処理するバックエンドシステムを構築できます。

クイックスタート：初めてのGoroutineとChannel

Goroutineは、OSではなくGoのランタイムによって管理される軽量なスレッドです。Goroutineを起動するには、関数呼び出しの前にgoキーワードを追加するだけです。しかし、単独で実行されるGoroutineはあまり役に立ちません。データを送り返す方法が必要です。それがChannelの役割です。

Channelをパイプと考えてください。一方の端からデータを押し込み、プログラムの別の部分で反対側からデータを取り出します。バックグラウンドタスクを実行して結果を取得する方法は以下の通りです。

package main

import (
    "fmt"
    "time"
)

func fetchUserData(userId int, resultChan chan string) {
    // 2秒の遅延があるAPIコールをシミュレート
    time.Sleep(2 * time.Second)
    resultChan <- fmt.Sprintf("ユーザー %d のデータ", userId)
}

func main() {
    results := make(chan string)

    // バックグラウンドでワーカーを起動
    go fetchUserData(101, results)

    fmt.Println("APIレスポンスを待機中...")

    // Channelがデータを受信するまで、この行で実行をブロックします
    data := <-results
    fmt.Println("受信内容:", data)
}

このスニペットでは、main関数はfetchUserDataを待つために停止しません。すぐに「APIレスポンスを待機中…」と出力します。プログラムは<-resultsの部分でのみ一時停止し、自然な同期ポイントとして機能します。

エンジンの仕組み：M:Nスケジューラ

標準的なJavaやC++のスレッドは、通常OSスレッドと1:1でマッピングされます。各OSスレッドは通常、約1MBのスタックメモリを消費します。もし10,000個のスレッドを実行しようとすれば、サーバーは停止するかクラッシュするでしょう。

GoはM:Nスケジューラを使用し、M個のGoroutineをN個のOSスレッドにマッピングします。Goroutineはわずか2KBのスタックから開始され、動的に拡張または縮小します。この効率性は驚異的です。標準的な8GB RAMのノートPCで100,000個のGoroutineを簡単に実行できますが、従来のスレッドではずっと前にメモリを使い果たしていたでしょう。

バッファ付きChannel vs バッファなしChannel

デフォルトでは、Channelはバッファなしです。送信側は受信側がデータを受け取る準備ができるまでブロックされます。これにより確実なハンドオフが保証されます。しかし、即時の読み取りを待たずに複数の値を送信したい場合は、バッファ付きChannelを使用できます。

// バッファサイズを3にすると、送信側がブロックされる前に3つのアイテムをパイプに格納できます
ch := make(chan int, 3)
ch <- 10
ch <- 20
ch <- 30
// ch <- 40 // 4回目の送信は、受信側が空きを作るまでブロックされます

Selectによるオーケストレーション

selectステートメントは、複数のChannelを管理するための核となる仕組みです。switch文のように機能しますが、非同期通信のために使われます。タイムアウトの実装や、複数のデータストリームを同時に処理するのに最適です。

select {
case res := <-results:
    fmt.Println("結果を処理中:", res)
case <-time.After(3 * time.Second):
    fmt.Println("エラー：3秒後にリクエストがタイムアウトしました。")
}

実践的なパターン：スケーラブルなWorker Pool

無限にGoroutineを生成するのは、トラブルの元です。100,000個のデータベースクエリを実行する必要がある場合、一度にデータベースを叩くと接続エラーが発生する可能性が高いです。これを解決するには、Worker Poolを使用します。このパターンでは、タスクのキューを処理しながら、並行数を固定された数のワーカーに制限します。

package main

import (
    "fmt"
    "sync"
)

func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
    defer wg.Done()
    for j := range jobs {
        fmt.Printf("Worker %d がジョブ %d を処理中\n", id, j)
        results <- j * 2
    }
}

func main() {
    const numJobs = 50
    jobs := make(chan int, numJobs)
    results := make(chan int, numJobs)
    var wg sync.WaitGroup

    // 負荷を処理するために、ちょうど5つのWorkerを起動
    for w := 1; w <= 5; w++ {
        wg.Add(1)
        go worker(w, jobs, results, &wg)
    }

    for j := 1; j <= numJobs; j++ {
        jobs <- j
    }
    close(jobs) 

    go func() {
        wg.Wait()
        close(results)
    }()

    for res := range results {
        _ = res // ここで結果を処理
    }
}

このアプローチは堅牢です。sync.WaitGroupを使用して進捗を追跡し、すべてのジョブが完了した後にのみアプリケーションが正常に終了するようにします。

よくある落とし穴を避ける

Goは並行処理を扱いやすくしてくれますが、魔法ではありません。私が夜遅くまでデバッグに費やした問題の多くは、以下の3つの単純なミスに集約されます。

1. Goroutineを放置しない

Goroutineリークは、クローズされない、あるいは書き込まれることのないChannelを待機してGoroutineがスタックしたときに発生します。これはアプリがクラッシュするまでゆっくりとメモリを消費し続けます。常に明確な終了戦略を定義してください。複雑なシステムでは、キャンセルやタイムアウトを伝播させるためにcontextパッケージを使用してください。

2. Race Detector（競合検出）を使用する

2つのGoroutineが同じ変数にアクセスしようとし、一方が書き込みを行っている場合、レースコンディション（競合状態）が発生します。これらのバグは再現が非常に難しいことで知られています。幸い、Goには組み込みのRace Detectorがあります。テストやローカルビルドを実行する際は、常に-raceフラグを付けてください。

go test -race ./...
go run -race main.go

3. シンプルに保つ

Goroutineを使えるからといって、使うべきだとは限りません。逐次的なコードの方が読みやすく、テストしやすく、デバッグも容易です。並行処理を導入するのは、明確なパフォーマンスのボトルネックがある場合だけにしましょう。複数のAPI呼び出し、大量の独立したデータのバッチ処理、または並行ウェブリクエストの処理などが良い候補です。

これらのパターンを習得するには練習が必要です。しかし、Channelとselectがどのように連携するかを一度理解すれば、高パフォーマンスなソフトウェアの構築は、より予測可能でやりがいのある経験になるでしょう。

Share:
Tags: