Stripe Goエンジニア面接体験記：goroutineからマイクロサービスアーキテクチャまで完全レビュー

背景紹介

2年間のGoバックエンド開発経験があり、クラウドコンピューティング企業でインフラストラクチャ関連の仕事をしていました。主にGoでマイクロサービスを書き、サービスガバナンスやミドルウェア開発に携わっていました。正直なところ、前の会社での技術的成長はまずまずでしたが、ビジネスの方向性が狭く、より大規模なビジネスシナリオに挑戦したかったです。メルカリはグローバルな決済インフラ企業として、マイクロサービスアーキテクチャと並行処理のシナリオが非常に豊富で、まさに私が求めていた方向でした。

今年の5月、メルカリで働く友人がGoエンジニアのポジションにリファラルしてくれました。リファラルはやはり通常の応募より速く、3日で面接の招待を受けました。全体のプロセスは3回の技術面接+1回のHR面接で、約2週間で完了しました。各ラウンドを詳しく振り返ります。

一次面接：Go基礎と並行モデル（1時間）

一次面接の面接官は非常に効率的な方で、雑談なしで本題に入りました。簡単な自己紹介の後、すぐに技術的な質問が始まりました。

スライスの内部構造

最初の質問はGoの定番：スライスの内部構造は何ですか？拡張メカニズムはどうなっていますか？

スライスの内部は3つのフィールドを持つ構造体だと説明しました：基盤となる配列へのポインタ（array）、長さ（len）、容量（cap）。拡張メカニズムについて、Go 1.18より前は容量が1024未満なら2倍、1024を超えると25%増加していました。Go 1.18以降はより滑らかな拡張戦略に変更され、明確な境界線がなく、期待容量と元の容量に基づいてより合理的に計算されます。面接官が追及：スライスと配列の違いは？配列は固定長で、長さが型の一部であり、[3]intと[5]intは異なる型です。スライスは動的長さで、配列の参照ビューだと答えました。

マップの実装

Goのマップは内部でどう実装されていますか？なぜマップの反復は順不同なのですか？

Goのマップはハッシュテーブルで、チェーン法でハッシュ衝突を解決していると説明しました。各バケットは最大8つのキーと値のペアを格納し、8つを超えるとオーバーフローバケットに溢れます。マップの反復が順不同なのは、反復の開始位置が毎回ランダムだからです。これは開発者が反復順序に依存するのを防ぐためのGoの意図的な設計です。面接官が追及：マップは並行安全ですか？いいえ、並行読み書きはパニックを引き起こすと答えました。並行安全性が必要な場合は、sync.Mapまたは読み書きロックを使用できます。面接官がさらに質問：sync.Mapとロック付きマップの違いは？sync.Mapは読み書き分離のアプローチを使用し、読み取り操作はほとんどの場合ロック不要で、読み取りが多く書き込みが少ないシナリオに適しています。ロック付きマップは毎回ロックが必要で、読み書きが均衡したシナリオに適していると答えました。

インターフェースの原理

Goのインターフェースは内部でどう実装されていますか？空インターフェースと非空インターフェースの違いは？

空インターフェース（interface{}）は内部的にeface構造体を使用し、型ポインタとデータポインタを含んでいます。非空インターフェースはiface構造体を使用し、型ポインタとデータポインタに加えてitabポインタもあり、itabにはインターフェースメソッドから具象型メソッドへのマッピングが格納されています。面接官が追及：型アサーションの原理は？型アサーションは本質的にインターフェースの動的型が一致するかをチェックし、一致する場合はデータポインタを対応する型に変換すると説明しました。コンパイラはアサーションの型に応じて異なるコードを生成します。具象型アサーションの場合は直接型チェックコードを生成し、型スイッチの場合は一連の型比較を生成します。

goroutineスケジューリング：GMPモデル

この部分は非常に深く聞かれました。GMPモデルを詳しく説明してください。G、M、Pはそれぞれ何ですか？それらの関係は？

Gはgoroutine、MはOSスレッド、Pは論理プロセッサだと説明しました。Pの数はデフォルトでCPUコア数と同じで、Mの数に上限はありません。GはPのローカルキューに配置され、MはPにバインドしてローカルキューからGを取得して実行します。ローカルキューが空の場合、Mはグローバルキューまたは他のPのローカルキューからGを盗みます（ワークスティーリングメカニズム）。面接官が追及：なぜPが必要なのですか？GとMだけではダメですか？Pがなければ、すべてのGがグローバルキューにあり、MがGを取得するたびにロックが必要で、競合が激しくなると答えました。Pのローカルキューはグローバルロックを回避し、スケジューリング効率を大幅に向上させます。また、Pの存在により、goroutineのコンテキストスイッチはP上のGキューを交換するだけで済み、OSスレッドを切り替える必要がありません。

チャネルの使用

チャネルの内部実装は？バッファありとバッファなしの違いは？

チャネルはリングバッファ、ミューテックス、送信/受信待ちキューなどを含むhchan構造体として実装されていると説明しました。バッファなしチャネルは同期的で、送信と受信が両方準備できて初めて完了します。バッファありチャネルは非同期的で、バッファが満杯でなければ送信はブロックされず、バッファが空でなければ受信はブロックされません。面接官が追及：クローズされたチャネルから読み取るとどうなりますか？書き込むと？クローズされたチャネルから読み取るとゼロ値とfalseが返り、書き込むとパニックが発生すると答えました。だからチャネルをクローズする責任は受信側ではなく送信側にあるべきです。

二次面接：Goメモリ管理と並行パターン（1.5時間）

二次面接の面接官はシニアバックエンドエンジニアで、質問はより深く、実際のエンジニアリングでの使用シナリオを重視していました。

GC三色マーキング

GoのGCアルゴリズムは何ですか？三色マーキングのプロセスを詳しく説明してください。

Goは三色マーキング法+ハイブリッドライトバリアを使用していると説明しました。三色マーキングはオブジェクトを3種類に分けます：白（未訪問）、灰（訪問済みだが参照未スキャン）、黒（訪問済みで参照スキャン済み）。GC開始時、すべてのオブジェクトは白です。ルートオブジェクトから始めて、ルートオブジェクトを灰にマークし、灰のオブジェクトを取り出してその参照オブジェクトを灰にマークし、自身を黒にマークするプロセスを繰り返します。灰のオブジェクトがなくなると、残りの白のオブジェクトがゴミです。面接官が追及：ライトバリアとは何ですか？なぜ必要ですか？ライトバリアはユーザープログラムがオブジェクト参照を変更する際に実行されるコードです。GCとユーザープログラムが並行して実行されるため、ライトバリアがないとオブジェクトのマーキング漏れが発生する可能性があると説明しました。例えば、黒のオブジェクトが新しく白のオブジェクトを参照し、白のオブジェクトが灰のオブジェクトからの参照を失った場合、その白のオブジェクトは誤って回収されてしまいます。Go 1.8以降はハイブリッドライトバリアを使用し、Dijkstraの挿入ライトバリアとYuasaの削除ライトバリアの利点を組み合わせています。

エスケープ解析

エスケープ解析とは何ですか？どのような場合に変数がヒープにエスケープしますか？

エスケープ解析はコンパイラが変数をスタックに割り当てるかヒープに割り当てるかを決定するプロセスです。ヒープにエスケープする一般的なケースは：ローカル変数のポインタを返す、クロージャが外部変数を参照する、インターフェース型の動的ディスパッチ、スタック領域不足です。面接官が追及：エスケープ解析の結果をどう確認しますか？go build -gcflags="-m"で確認できると答えました。面接官がさらに質問：なぜスタック上の変数はヒープ上の変数より速いのですか？スタック上の変数の割り当てと解放はスタックポインタを移動するだけでほぼゼロコストですが、ヒープ上の変数はGCによる回収が必要で、メモリ断片化も引き起こす可能性があると答えました。

並行パターン

Goでよく使われる並行パターンは何ですか？

いくつか列挙しました：fan-in/fan-outパターン（複数のgoroutineの結果を1つのチャネルに集約）、pipelineパターン（複数の処理段階を直列に接続）、worker poolパターン（固定数のgoroutineでタスクを処理）、contextキャンセルパターン（contextを通じてキャンセル信号を伝播）。面接官はworker poolのコードを書くよう求め、約10分で書きました。チャネルをタスクキューとして使用し、固定数のgoroutineを起動してチャネルからタスクを取得して実行します。面接官はまずまずだと判断しました。

contextの使用

contextの用途は何ですか？contextのキャンセルはどう伝播しますか？

contextには主に4つの用途があると説明しました：WithValueでリクエストスコープの値を渡す、WithCancelでキャンセル信号、WithTimeoutでタイムアウト制御、WithDeadlineで期限制御。キャンセルの伝播は子contextを再帰的にトラバースすることで実現され、親contextがキャンセルされるとすべての子contextがキャンセル信号を受け取ります。面接官が追及：context.WithValueの落とし穴は？WithValueはグローバルに可視であるため、ビジネスデータの受け渡しには適していず、カップリングを引き起こしやすいと答えました。traceIDやuserIDなどのリクエストスコープのメタデータのみに使用すべきです。

アルゴリズム：生産者消費者モデル

Goで生産者消費者モデルを実装してください。複数の生産者と消費者をサポートし、消費者はグレースフルシャットダウンできること。

2つのチャネルを使用しました：taskChをタスクキュー、doneChを終了信号として使用します。生産者はtaskChにタスクを送信し、消費者はtaskChからタスクを取得して処理します。sync.WaitGroupで全生産者の完了を待ってからtaskChをクローズし、消費者はfor rangeでtaskChから読み取り、チャネルがクローズされると自動的に終了します。面接官が追及：消費者がタスク処理でエラーになったらどうしますか？errorChを追加してエラーを収集するか、contextでキャンセル信号を伝播してすべてのgoroutineをグレースフルに終了させると答えました。

三次面接：マイクロサービスアーキテクチャとシステム設計（1.5時間）

三次面接の面接官はアーキテクトレベルの専門家で、質問は非常にマクロでしたが、具体的な実装の詳細も求められました。

サービス登録・発見

サービス登録・発見はどうやっていますか？

etcdをサービスレジストリとして使用していると説明しました。サービス起動時にetcdにアドレスを登録し、定期的にハートビートでリースを更新します。コンシューマーはetcdからサービスリストを取得してローカルにキャッシュし、watchメカニズムでサービスの変更を監視します。面接官が追及：etcdがダウンしたらどうしますか？コンシューマーにはローカルキャッシュがあるため、短時間なら正常に動作できると答えました。etcd自体はクラスタデプロイされており、少数のノードのダウンは可用性に影響しません。etcdクラスタ全体がダウンした場合は重大インシデントとなり、緊急復旧が必要です。

分散トレーシング

分散トレーシングはどうやっていますか？

Jaegerを分散トレーシングに使用し、OpenTelemetry SDKで統合していると説明しました。各リクエストのエントリポイントでtraceIDを生成し、RPC呼び出し時にmetadataを通じてtraceIDとspanIDを伝播します。各サービスは子spanを作成して自身の処理情報を記録します。面接官が追及：トレーシングのパフォーマンスオーバーヘッドは大きいですか？サンプリング率を適切に制御すればオーバーヘッドは大きくないと答えました。本番では確率サンプリングを使用し、デフォルト1%、重要エンドポイントは100%サンプリングしています。spanデータは非同期でバッチ報告されるため、ビジネスロジックをブロックしません。

レート制限とサーキットブレーカー

レート制限とサーキットブレーカーはどうやっていますか？

レート制限にはトークンバケットアルゴリズムを使用し、ゲートウェイ層のミドルウェアで実装しています。エンドポイント単位、ユーザー単位のレート制限設定をサポートしています。サーキットブレーカーにはsentinel-goを使用し、エラー率と遅延呼び出し比率に基づくルールを設定し、サーキットがオープンした場合はデグレードレスポンスを返します。面接官が追及：トークンバケットとリーキーバケットの違いは？トークンバケットはバーストトラフィックを許可し、バケットにトークンがあればリクエストが通過できます。リーキーバケットは入力速度に関わらず一定速度で出力します。トークンバケットはバーストを許容するシナリオに、リーキーバケットは厳密に均一な速度が必要なシナリオに適していると答えました。

プロジェクト深掘り

最も挑戦的だったプロジェクトについて話してください。

以前開発した分散タスクスケジューリングシステムについて話しました。最大の課題はタスクの高可用性と冪等性でした。etcdで分散ロックを使用して同じタスクが重複実行されないようにし、タスクの実行状態をMySQLに永続化して失敗時にリトライできるようにしました。冪等性については、各タスクにユニークIDを割り当て、実行前に既に実行済みかチェックしています。面接官が追及：分散ロックの落とし穴は？最大の落とし穴はロックの更新で、ロックを保持しているプロセスがクラッシュした場合、ロックを自動的に解放する必要があると答えました。etcdのリースメカニズムを使用し、リースの期限切れでロックが自動的に解放されます。また、リエントラントロックの問題もあり、ロックのvalueにホルダー情報を格納して解決しています。

システム設計

高並行のオーダーシステムを設計するとしたら、どうアプローチしますか？

いくつかのレイヤーから回答しました：アクセス層はゲートウェイでレート制限とルーティング、サービス層はドメインごとにオーダーサービス、決済サービス、在庫サービスなどに分割、データ層はMySQLで永続化、Redisでキャッシュと分散ロック、メッセージキューで非同期デカップリング（注文後に在庫引当のメッセージを送信など）、一貫性については分散トランザクション（TCCパターン）でオーダーと在庫の一貫性を保証します。面接官が追及：在庫引当が失敗したらどうしますか？TCCパターンにはTry、Confirm、Cancelの3つのフェーズがあり、Confirmフェーズで在庫引当が失敗した場合、Cancelがトリガーされて以前の操作をロールバックすると答えました。ネットワークタイムアウトによる失敗の場合は、スケジュールタスクで補正を行います。

HR面接：キャリアプランと報酬（30分）

HR面接は比較的標準的で、主にキャリアプランと報酬の期待について話しました。

キャリアプラン

HRは3〜5年のキャリアプランについて聞きました。短期的な目標はマイクロサービスアーキテクチャとクラウドネイティブ技術の専門知識を深めること、中期的な目標はアーキテクトになり、システムアーキテクチャ設計を独立して担当できること、長期的には技術分野でより深い蓄積を持ち、技術的な深みのある仕事をしたいと答えました。

報酬

HRは給与の期待額について聞きました。範囲を提示し、HRは妥当な範囲内だと言い、具体的には承認待ちとのことでした。あまり交渉はなく、全体的にスムーズでした。

面接問題まとめ

1. スライスの内部構造？拡張メカニズム？スライスと配列の違い？
2. マップの内部実装？なぜ順不同？並行安全？sync.Mapとロック付きマップの違い？
3. インターフェースの内部実装？空インターフェースと非空インターフェースの違い？型アサーションの原理？
4. GMPモデル？G、M、Pの関係？なぜPが必要？ワークスティーリングメカニズム？
5. チャネルの内部実装？バッファありとバッファなしの違い？クローズ後の読み書きは？
6. GC三色マーキングのプロセス？ライトバリア？ハイブリッドライトバリア？
7. エスケープ解析？どのような場合にエスケープする？確認方法？
8. Goでよく使われる並行パターン？worker poolの実装？
9. contextの用途？キャンセル伝播メカニズム？WithValueの落とし穴？
10. Goで生産者消費者モデルを実装？グレースフルシャットダウン？
11. サービス登録・発見の実装？etcdがダウンしたら？
12. 分散トレーシングの実装？パフォーマンスオーバーヘッド？
13. レート制限とサーキットブレーカーの実装？トークンバケットとリーキーバケットの違い？
14. 分散ロックの落とし穴？
15. 高並行オーダーシステムの設計？在庫引当失敗時の対応？

気づきとアドバイス

1. Go言語の基礎は非常にしっかりと身につける必要がある。メルカリのGoの要件は「使える」レベルではなく、内部原理を理解していることが求められます。スライス、マップ、チャネル、インターフェースの内部実装はすべて明確に説明できなければなりません。

2. 並行プログラミングはGo面接の核心。goroutineスケジューリング、チャネル、並行パターンはほぼ確実に出題されます。原理を理解するだけでなく、正しい並行コードを書ける必要があります。

3. マイクロサービスアーキテクチャには実戦経験が必要。サービス登録・発見、分散トレーシング、レート制限とサーキットブレーカー——これらはいくつかの記事を読んだだけで対応できるものではありません。実際の使用経験があり、遭遇した落とし穴について話せる必要があります。

4. システム設計には深みが必要。面接官が求めているのはアーキテクチャ図を描くことではなく、各コンポーネントをなぜ選んだのか、どのようなトレードオフがあるのか、障害時にどう対応するのかを説明することです。

5. リファラルは本当に重要。友人のリファラルは通常の応募よりはるかに速く、履歴書が見られる可能性も高くなります。メルカリに入りたいなら、まずリファラルを見つけましょう。

よくある質問FAQ

Q：メルカリのGoエンジニア面接は通常何回ですか？

A：経験者採用の場合、通常3回の技術面接+1回のHR面接で、約2週間で完了します。

Q：Go言語の要件はどの程度深いですか？

A：使えるだけでは不十分で、内部原理を理解する必要があります。スライス、マップ、チャネルの内部実装、GCアルゴリズム、goroutineスケジューリングモデルはすべて明確に説明できなければなりません。

Q：アルゴリズム問題は難しいですか？

A：それほど難しくはありませんが、純粋なLeetCodeスタイルではありません。Goの並行処理に関連するアルゴリズム問題、例えば生産者消費者モデルなどに偏っています。

Q：マイクロサービスアーキテクチャはどの程度準備すべきですか？

A：少なくともサービス登録・発見、分散トレーシング、レート制限とサーキットブレーカー、分散トランザクションについて理解している必要があります。実際の使用経験があることが望ましいです。

Q：リファラルと通常応募の差は大きいですか？

A：かなり大きいです。リファラルの方が処理速度が速く、面接官がより真剣に対応する可能性があります。リファラルが得られるなら、ぜひそのルートを使いましょう。