Google SRE面接体験記：Kubernetes・監視・自動化の完全評価

背景紹介

まずは私の経歴からお話しします。学部はコンピュータサイエンスを専攻し、卒業後は中堅のインターネット企業で2年間運用開発に従事しました。主にPythonとGoで自動化スクリプトを書き、数百台のサーバーを管理し、監視システムの構築も行いました。正直なところ、GoogleのSREポジションはずっと私の目標でした。GoogleはSREという分野を生み出した企業であり、そのインフラ規模は世界トップクラスです。

7月にリファラルチャネルで応募しました。約1週間後にHRから連絡があり、一次面接が設定されました。プロセス全体は技術面接3回＋HR面接1回で、約2週間で完了しました。Googleの面接ペースは速く、各ラウンドの間隔は2〜3日でした。各ラウンドの詳細を振り返ってみましょう。

面接プロセスの振り返り

一次面接：Linux基礎＋ネットワーク（約60分）

一次面接の面接官は非常に効率的なエンジニアで、雑談なしにすぐ本題に入りました。

Linux基礎：

最初の質問はGoogleらしいものでした——「Linuxのプロセスとスレッドの違いを説明してください」。アドレス空間、リソース使用量、スケジューリング、作成オーバーヘッドの観点から説明しました。追撃：「プロセス間通信にはどのような方法がありますか？それぞれの特徴は？」パイプ、メッセージキュー、共有メモリ、セマフォ、シグナル、ソケットを列挙し、それぞれの使用例とトレードオフを説明しました。

次に実践的な質問：「Linuxのファイルシステムについて説明してください。inodeとは何ですか？」inodeの構造（メタデータ、データブロックポインタ）、ハードリンクとシンボリックリンクの違い、ディレクトリエントリについて説明しました。追撃：「ディスク容量がいっぱいなのにduが残り容量を表示する場合、原因は何が考えられますか？」プロセスによってまだ開かれている削除済みファイルの可能性があり、lsofで確認できると答えました。

ネットワーク基礎：

面接官が聞きました：「TCPの3ウェイハンドシェイクと4ウェイ切断のプロセスを説明してください」。これはスムーズに答えられました。状態遷移図を描き、各段階のパケットと状態変化を詳しく説明しました。追撃：「なぜ3ウェイハンドシェイクで2ウェイではないのですか？なぜ4ウェイ切断にTIME_WAITが必要なのですか？」古い接続要求がサーバーに到達するのを防ぐことと、相手が最後のACKを受信したことを確認するためと説明しました。

HTTPに関する質問もありました：「HTTP/1.1、HTTP/2、HTTP/3はそれぞれどのような改善をもたらしましたか？」持続的接続、多重化、ヘッダー圧縮、サーバープッシュ、QUICプロトコルの観点から比較しました。追撃：「HTTPSのハンドシェイクプロセスはどうなっていますか？」証明書検証、鍵交換、対称暗号通信について詳しく説明しました。

Shellとツール：

最後にShell関連の質問：「nginxログでアクセス数トップ10のIPを見つけるコマンドを書いてください」。awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10と書き、面接官はOKと言いました。また：「プロセスが開いているファイルを確認するには？」lsof -p PIDと答えました。

二次面接：K8s＋監視システム（約75分）

二次面接の面接官は明らかにシニアで、おそらくSREチームの技術的柱でした。このラウンドは深さと幅が増しました。

Kubernetes：

最初の質問は大きなものでした——「Kubernetesのアーキテクチャコンポーネントについて説明してください」。コントロールプレーン（API Server、etcd、Scheduler、Controller Manager）とワーカーノード（kubelet、kube-proxy、コンテナランタイム）について詳しく説明し、各コンポーネントの責任と相互作用を解説しました。追撃：「Podの作成プロセスはどうなっていますか？」kubectlがAPI Serverにリクエストを送信し、etcdに保存、Schedulerが割り当て、kubeletがコンテナを作成するという全流れを説明しました。

サービスディスカバリに関する質問もありました：「K8sのServiceとIngressの違いは何ですか？それぞれどのようなシナリオに適していますか？」ClusterIP/NodePort/LoadBalancerタイプのServiceとIngressのレイヤ7ルーティング能力を比較し、それぞれの使用例を説明しました。

スケジューリングに関する追撃：「ノードのリソースが不足している場合、Podはどうなりますか？」Pending状態、スケジューリング失敗、クラスタオートスケーリングのトリガーの可能性について説明しました。

監視システム：

面接官が聞きました：「以前の監視システムはどのように構築されていましたか？」Prometheus + Grafana + Alertmanagerのアーキテクチャについて説明し、メトリクス収集、保存、可視化、アラートの完全なパイプラインを詳しく説明しました。追撃：「Prometheusのプルモデルとプッシュモデル（Pushgateway）の長所と短所は何ですか？」サービスディスカバリ、時系列の一貫性、適用シナリオの観点から比較しました。

アラートに関する質問もありました：「アラートが多すぎてアラート疲労になった場合、どう解決しますか？」アラートの段階付け（P0-P3）、アラートの集約と抑制、動的しきい値、SLOベースのアラート戦略など、いくつかの方法を説明しました。面接官はこの回答に満足していました。

ログシステム：

「ELK/EFKのアーキテクチャについて説明してください」。Filebeat収集、Logstash処理、Elasticsearch保存、Kibana可視化の完全なパイプラインを説明しました。追撃：「ログ量が多すぎてElasticsearchのパフォーマンスが低下した場合、どうしますか？」ホット・コールドデータ分離、インデックスライフサイクル管理、ノード追加、クエリ最適化のソリューションを説明しました。

三次面接：トラブルシューティング＋自動化（約70分）

三次面接はSREチームリーダーで、主にトラブルシューティング能力と自動化思考を評価していました。

トラブルシューティング：

面接官は障害シナリオを出しました：「オンラインサービスが突然遅くなりました。どうトラブルシューティングしますか？」アプリケーション層（ログ、トレース、プロファイル）、システム層（CPU、メモリ、I/O、ネットワーク）、インフラ層（データベース、キャッシュ、メッセージキュー）の3つのレベルから調査アプローチを説明し、まず止血してから調査する原則を強調しました。面接官はいくつかのシナリオを追撃しました：「データベースのスロークエリが原因の場合は？」「ネットワークのジッターが原因の場合は？」「GCの問題の場合は？」それぞれに対する的確なトラブルシューティング方法を説明しました。

キャパシティプランニングに関する質問もありました：「サービスのキャパシティ上限をどう評価しますか？」負荷テスト（wrk/locust）、パフォーマンスメトリクス（QPS、レイテンシ、エラー率）、リソースボトルネック分析、キャパシティモデル構築などの方法を説明しました。

自動化：

面接官が聞きました：「以前の仕事でどのような自動化を行いましたか？」オートスケーリング、自動障害復旧、自動デプロイメントパイプラインなどについて説明しました。追撃：「オートスケーリングのメトリクスはどう選択しますか？どんな落とし穴がありますか？」CPU/メモリ/QPSベースのスケーリング戦略と、コールドスタート遅延、メトリクスの遅れ、トラフィックスパイクなどの一般的な落とし穴について説明しました。

カオスエンジニアリングに関する質問もありました：「カオスエンジニアリングについて知っていますか？本番環境でどう実装しますか？」Chaos Monkeyなどのツール、ブラスト半径制御、段階的実験、観測可能性の確保などの原則を説明しました。

オンコール関連：

面接官の最後の質問は非常に実践的でした：「オンコールについてどう思いますか？良いオンコールプラクティスは何ですか？」ローテーション制度、アラート段階付け、ランブック、インシデント後レビューなどのプラクティスを説明し、オンコールは「消火」ではなく「防火」であるべき——自動化と予防措置によってオンコールの負担を減らすべきだと強調しました。

面接問題まとめ

Linux基礎：

1. プロセスとスレッドの違い

2. プロセス間通信方法と特徴

3. Linuxファイルシステムとinode

4. duが残り容量を表示するのにディスクがいっぱいになる理由

ネットワーク：

5. TCP 3ウェイハンドシェイクと4ウェイ切断

6. なぜ3ウェイで2ウェイではないか？TIME_WAITの目的

7. HTTP/1.1、HTTP/2、HTTP/3の改善

8. HTTPSハンドシェイクプロセス

Shellとツール：

9. nginxログでアクセス数トップ10のIPを見つける

10. プロセスが開いているファイルを確認する

Kubernetes：

11. K8sアーキテクチャコンポーネントと責任

12. Pod作成プロセス

13. ServiceとIngressの違い

14. ノードリソース不足時のPodの扱い

監視：

15. Prometheus + Grafana + Alertmanagerアーキテクチャ

16. プルモデル vs プッシュモデルの長所と短所

17. アラート疲労の解決策

18. ELK/EFKアーキテクチャ

19. Elasticsearchパフォーマンス最適化

トラブルシューティングと自動化：

20. サービス応答遅延のトラブルシューティングアプローチ

21. キャパシティ評価方法

22. オートスケーリングメトリクス選択と一般的な落とし穴

23. カオスエンジニアリングプラクティス

24. オンコールベストプラクティス

心得とアドバイス

1. Linuxとネットワークの基礎はSREの土台。Googleの面接ではK8sや監視などの高度な話題を聞かれますが、基礎が弱いと面接官の追撃ですぐにボロが出ます。「TCP/IP詳解」と「UNIXプログラミング環境」をしっかり勉強することをお勧めします。暗記ではなく真の理解のために。

2. K8sはアーキテクチャ原理を理解し、kubectlコマンドだけではダメ。多くの人はkubectl applyを実行するだけですが、面接官はPod作成フロー、スケジューリングアルゴリズム、サービスディスカバリメカニズムといった基礎原理を聞きます。K8sのソースコードを読み、少なくともAPI ServerとControllerの動作メカニズムを理解することをお勧めします。

3. 監視システムの全体像を持つ。Prometheusのルールを設定できるだけでなく、メトリクス定義、収集、保存、可視化からアラートまでの完全なパイプラインと、各段階のトレードオフを理解してください。Googleの面接官は監視システムの全体的な理解を非常に重視します。

4. トラブルシューティングには方法論を持つ。闇雲に推測せず、体系的なアプローチを持ってください。まず影響範囲を定義し、次にレイヤーごとに調査し、根本原因の修正の前にまず止血する。面接でこの体系的なトラブルシューティング思考を示すと大きく加点されます。

5. 自動化思考を常に持つ。SREのコアバリューは手動運用ではなく、自動化による効率と信頼性の向上です。面接で自動化の観点から問題を考えることで、SREのマインドセットがあることを面接官に示せます。

FAQ

Q：GoogleのSRE面接はプログラミング能力が求められますか？

A：ある程度求められます。開発職ほどアルゴリズム重視ではありませんが、自動化スクリプトやツールを書ける必要があります。面接ではShellとPythonのコーディング問題が出るので、事前に準備してください。

Q：K8s経験なしでGoogleのSRE面接を受けられますか？

A：難しいです。GoogleのSREポジションはほぼK8s経験が必須で、インフラが完全にコンテナ化されているためです。K8s経験がない場合は、まず自分でクラスタを構築して練習することをお勧めします。

Q：Googleのオンコールの強度はどうですか？

A：正直に言うと、Googleのオンコール強度は低くありません。特にコアサービステームでは。しかしGoogleの自動化レベルは非常に高く、多くの障害は自己修復可能で、オンコールの負担は徐々に減っています。

Q：面接でアルゴリズム問題は出ますか？

A：はい、しかし開発職よりは易しいです。一般的に中程度の難易度で、アルゴリズムのテクニックよりもコーディング能力とエンジニアリング思考が重視されます。

Q：給与はどうですか？

A：2年の経験であれば、Google SREの給与は非常に競争力があり、同レベルの開発職とほぼ同等です。株式報酬コンポーネントも魅力的です。