Chalkboard

v2.Kafka/Pulsarの選択ガイドラインを作りたい(1-2章)

Thu, 23 Jan 2025 03:38:13 GMT

<p><a href="https://www.chalkboard.me/posts/kafka-pulsar-guideline/">前回の記事</a>では、Kafka と Pulsar の選択ガイドラインを作るにあたっての <strong>目次</strong> の骨子と、ガイドラインに盛り込むべき項目を洗い出しました。今回は、その目次のうち <strong>1章（ガイドラインの目的）</strong> および <strong>2章（基本的なアーキテクチャの違い）</strong> について、どのように内容をまとめるかを検討していきます。</p> <h2>1章：ガイドラインの目的</h2> <h3>1. 背景と目的の明示</h3> <ul> <li><strong>なぜガイドラインが必要なのか？</strong><br> Kafka チームと Pulsar チームがそれぞれ存在するため、利用者からの「どちらを使えばいいの？」という疑問に対して一貫した選定基準を示す必要がある。合併後の新体制下で混乱が生じないよう、標準となる方針を定義したい。</li> <li><strong>このガイドラインで扱う範囲</strong><br> 前回の記事で示した <strong>目次</strong> にある通り、基本的なアーキテクチャ比較や運用・管理面、セキュリティ、コスト試算などを網羅して解説する。</li> </ul> <h3>2. 想定読者と想定シナリオ</h3> <ul> <li><strong>主な対象</strong>: 新規にメッセージング基盤を導入したい社内ユーザ（開発チーム）。</li> <li><strong>規模感</strong>: 小規模から大規模まで特に限定しない。社内システムであれば、必要な規模に応じてチームと相談しながら対応可能。</li> <li><strong>SLA / SLO</strong>: Kafka / Pulsar ともに公式ドキュメントで提示されている基準があり、それらへのリンクを参照する形で対応。</li> </ul> <h3>3. ガイドラインの適用範囲（スコープ）</h3> <ul> <li><strong>取り上げるトピック</strong>: 前回の記事の目次に挙げた <ol> <li>基本アーキテクチャの違い</li> <li>選定判断のポイント（ユースケース別）</li> <li>運用・管理面</li> <li>セキュリティ / マルチテナント</li> <li>パフォーマンステスト</li> <li>コスト試算</li> <li>運用体制・権限分掌</li> <li>事例紹介・参考リンク</li> </ol> </li> <li><strong>あえて取り上げない（詳細に踏み込まない）トピック</strong> <ul> <li><strong>アプリケーション開発者向けのコードレベルの詳細実装</strong> <ul> <li>Producer/Consumerの実装サンプルやSDK設定などは、利用者向けの個別ドキュメントに委ねる。</li> </ul> </li> <li><strong>他のフレームワークやOSSとの高度な連携</strong> <ul> <li>Kafka StreamsやFlinkなどのストリーミング処理基盤、分析ツールとの連携、あるいは他PFとの連携はスコープ外。</li> </ul> </li> </ul> </li> </ul> <h3>4. このガイドラインを参照することで得られる価値</h3> <ul> <li><strong>導入判断をスムーズに進められる</strong><br> Kafka と Pulsar の違いや運用面の注意事項が整理されたガイドラインを参照することで、短時間で適切な判断が下せる。</li> <li><strong>運用フローのベースラインを確立できる</strong><br> 障害対応フロー、バージョンアップ方針などが概念的に分かるので、導入後のトラブル対応のイメージができる。</li> </ul> <hr> <h2>2章：基本的なアーキテクチャの違い</h2> <h3>1. どの程度の深さまで解説するか</h3> <ul> <li>ガイドラインとしては、<strong>「利用・運用する際に必要なポイント」</strong> を中心に説明し、コードレベルや内部実装の詳細な仕組みには踏み込まない。</li> <li>各製品の公式ドキュメントや、インストールガイド・設定ガイドへのリンクを提示して、さらなる詳細を知りたい場合の参考情報を提供する。</li> </ul> <h3>2. Kafka の概要</h3> <ul> <li><strong>ログ構造</strong>: Broker 内のパーティション単位でメッセージを保持し、必要に応じてレプリケーションを行う。</li> <li><strong>ZooKeeper / KIP-500</strong>: これまでは ZooKeeper が必須だったが、KIP-500 により ZooKeeper を排除したアーキテクチャも利用可能になる。</li> <li><strong>スケール方法</strong>: Broker 台数、パーティション数を増やすことで負荷分散。</li> <li><strong>用途の特徴</strong>: 主に <strong>イベントストリーミング</strong> としての大規模ログ処理が得意。</li> </ul> <h3>3. Pulsar の概要</h3> <ul> <li><strong>Broker と BookKeeper の分離</strong>: Pulsar Broker はメッセージを一時的に中継し、データの永続化は BookKeeper クラスタが担当する。</li> <li><strong>マルチテナント設計</strong>: テナントや Namespace を使って分離管理する仕組みが標準で備わっている。</li> <li><strong>スケールアウト</strong>: Broker 層、BookKeeper 層をそれぞれ独立して増減可能。</li> <li><strong>用途の特徴</strong>: <strong>Pub/Sub, キューイング</strong> 用途としての柔軟性が高く、大量トピックを同時に扱うケースでも適している。</li> </ul> <h3>4. 比較の観点（例）</h3> <ul> <li><strong>データの書き込み・読み取りフロー</strong> <ul> <li>Kafka: Broker のパーティションに書き込み → コンシューマがログを順次読み取り</li> <li>Pulsar: Broker が BookKeeper に書き込み → Broker がクライアントにメッセージを配信</li> </ul> </li> <li><strong>スケーラビリティと障害対応</strong> <ul> <li>Kafka: パーティション数が多いほど設計・管理が複雑になる可能性がある</li> <li>Pulsar: BookKeeper 層のレプリカ構成で耐障害性を高める一方、ネットワーク帯域にも配慮が必要</li> </ul> </li> <li><strong>マルチテナントとアクセス制御</strong> <ul> <li>Kafka: ACL や RBAC (SASL/SSL) で制御。大規模になるとクラスター分割なども検討</li> <li>Pulsar: テナント / Namespace を切り分けることで、論理的にプロジェクトごとに独立性を保つ</li> </ul> </li> </ul> <p>ここではあくまで高レベルの比較とポイントに留め、詳細は各運用チームや公式ドキュメントのリファレンスを参照できるようにする。</p> <hr> <h2>まとめ</h2> <ul> <li> <p><strong>1章（ガイドラインの目的）</strong></p> <ul> <li>社内で Kafka / Pulsar を導入する際の指針をまとめることが目的。</li> <li>想定読者は新規導入を検討する社内ユーザ。規模は限定せず、SLA/SLO は各プロダクト公式の基準を参照。</li> <li>コードレベルのサンプルや他のフレームワーク連携等は詳細に扱わない。</li> </ul> </li> <li> <p><strong>2章（基本的なアーキテクチャの違い）</strong></p> <ul> <li>運用や導入を検討する上で重要になるポイントを抽出し、高レベルにまとめる。</li> <li>Kafka は Broker 内パーティション構造 + ZooKeeper (KIP-500) という構成が特徴。</li> <li>Pulsar は Broker と BookKeeper を分離し、マルチテナントを標準でサポート。</li> <li>スケール方法や障害時の挙動など、運用・管理の観点で比較する。</li> </ul> </li> </ul> <p>次回は <strong>3章以降</strong>、具体的な「ユースケース別の選定基準」や「運用・管理面の考慮事項」などをもう少し掘り下げていきたいと思います。</p>

【調査ログ】Apache Pulsar と Kafka の比較～サブスクリプション、ルーティング、順序制御編～

Tue, 21 Jan 2025 22:59:52 GMT

<h2>はじめに</h2> <p>本記事では、メッセージングシステムとして代表的な <strong>Apache Pulsar</strong> と <strong>Apache Kafka</strong> を比較しながら、以下の点に着目して解説します。</p> <ul> <li>両者における <strong>サブスクリプションモデルの違い</strong></li> <li>Producer 側の <strong>ルーティング方式</strong></li> <li><strong>順序保証(Ordering)の考え方</strong></li> <li>Pulsar のサブスクリプションタイプを使った <strong>具体的なユースケース例</strong></li> </ul> <p>Pulsar は「サブスクリプションタイプ」を複数用意しており、1つのトピックに対して異なるタイプのコンシューマを同時に動かすことが可能です。一方 Kafka では、1つの「Consumer Group」で「パーティション割り当て」中心のモデルが確立されており、並列度の確保と順序保証はパーティション単位で管理するのが基本となります。</p> <hr> <h2>1. サブスクリプションモデルの違い</h2> <h3>1-1. Kafka の場合</h3> <ul> <li><strong>Consumer Group</strong> に属する複数の Consumer は、Kafka ブローカーから <strong>パーティションごと</strong> に割り当てを受けます。</li> <li><strong>1パーティション = 1Consumer</strong> の関係が基本で、パーティション内のメッセージは常に同じ Consumer が読むことになります。</li> <li>並列度を上げたい場合は、パーティション数を増やし、Consumer をスケールアウトさせる設計が必要です。</li> <li><strong>パーティション内部でさらに並列化</strong>したい場合は、アプリケーション側で工夫（スレッドプールなど）して順序を崩さないよう制御する必要があります。</li> </ul> <h3>1-2. Pulsar の場合</h3> <p>Pulsar には <strong>4種類のサブスクリプションタイプ</strong> が存在し、Consumer がトピックを購読するときに指定できます。1つのトピックに対して複数のサブスクリプションを張ることも可能で、それぞれ異なるタイプを選べます。</p> <ol> <li> <p><strong>Exclusive</strong></p> <ul> <li>1つのサブスクリプションに対し <strong>1つの Consumer</strong> だけがアクティブにメッセージを受け取る。</li> <li>完全にシリアルな読み出しが可能。</li> </ul> </li> <li> <p><strong>Failover</strong></p> <ul> <li>複数の Consumer が同じサブスクリプションを購読できるが、同時にアクティブなのは <strong>1つだけ</strong>。</li> <li>アクティブな Consumer が落ちたときに <strong>フェイルオーバー</strong> で別の Consumer が引き継ぐ。</li> <li>Exclusive と同様にシリアルな読み出しを行いつつ、高可用性を確保できる。</li> </ul> </li> <li> <p><strong>Shared</strong></p> <ul> <li>1つのサブスクリプションに <strong>複数の Consumer</strong> が同時に参加し、メッセージを <strong>ラウンドロビン</strong> などで振り分ける。</li> <li><strong>パーティション内の順序保証は崩れる</strong> 代わりに、高いスループットを得られる。</li> </ul> </li> <li> <p><strong>Key_Shared</strong></p> <ul> <li>Shared と似ているが、<strong>Message Key</strong> (Producer 側で設定) ごとに <strong>同じ Consumer</strong> に割り当てる。</li> <li><strong>同じ Key のメッセージ</strong> は必ず同じ Consumer が受け取り、パーティション内でキー単位の順序が保たれる。</li> <li>異なる Key は別の Consumer が同時に処理するため、キーごとのシリアル処理を維持しつつ並列化が可能。</li> </ul> </li> </ol> <hr> <h2>2. ルーティング方式の違い (Producer 側)</h2> <h3>2-1. Kafka</h3> <ul> <li>Producer でメッセージを送る際、<strong>Key</strong> を指定すると、その Key のハッシュ値をもとに <strong>特定パーティション</strong> へ常にルーティングされます。</li> <li>Key を指定しない場合はラウンドロビンなどでパーティションが割り当てられることが多いです。</li> <li><strong>同じ Key のメッセージを同じパーティションに集約</strong> できるのが特徴。</li> </ul> <h3>2-2. Pulsar</h3> <ul> <li>Pulsar の Producer も似たように、メッセージごとに <code>messageKey</code> をセットし、<strong>パーティションルーティングを KeyHash に切り替える</strong> ことで、同じ Key が同じパーティションへ送られます。</li> <li>何も指定しなければデフォルトはラウンドロビンなど、設定次第で柔軟に振り分けることができます。</li> <li>Key_Shared サブスクリプションと組み合わせると、<strong>「同じ Key → 同じパーティション → 同じ Consumer」</strong> のフローを構築可能です。</li> </ul> <hr> <h2>3. 順序保証の考え方</h2> <h3>3-1. パーティション内の順序</h3> <ul> <li><strong>Kafka</strong> / <strong>Pulsar</strong> ともに、<strong>単一パーティション</strong> ではメッセージが受信された順に <strong>append-only</strong> なログとしてブローカーに保存されます。</li> <li>Consumer はそのログをオフセット順に読み出すため、<strong>パーティション内のメッセージ順序は保証</strong> されます。</li> <li>複数 Producer が同じパーティションに書き込む場合、<strong>ブローカーが受信した順序</strong> で確定し、Producer の送信時刻順とは必ずしも一致しない点は共通です。</li> </ul> <h3>3-2. パーティションをまたぐグローバル順序</h3> <ul> <li>いずれのシステムも、<strong>パーティションをまたぐグローバルな順序保証は行いません</strong>。</li> <li>パーティション間で到着時刻が前後するのは一般的で、完全な時系列を保つにはアプリケーション側の追加ロジックが必要です。</li> <li>「すべてのメッセージで厳密な順序が必要」な場合は <strong>パーティション数を1つ</strong> にするか、キーを工夫して常に同じパーティションへルーティングする必要があります。</li> </ul> <h3>3-3. Pulsar におけるサブスクリプションタイプと順序の関係</h3> <ul> <li><strong>Exclusive / Failover</strong> <ul> <li>1つの Consumer (またはアクティブ1台) がすべてのメッセージを読み取るため、<strong>パーティション内の完全な順序が保たれる</strong>。</li> </ul> </li> <li><strong>Shared</strong> <ul> <li>パーティション内のメッセージが複数 Consumer に分散するため、<strong>グローバルな順序は崩れる</strong>。</li> </ul> </li> <li><strong>Key_Shared</strong> <ul> <li><strong>同じ Key のメッセージ</strong> は順序が保証される一方、<strong>Key が異なるもの同士</strong> では順序は保証されない。</li> <li>これは Kafka でも同じパーティションにキーを集めれば保持できる考え方と同様だが、Pulsar はキー単位で Consumer を自動振り分けする仕組みが標準機能として提供されている点が特徴的。</li> </ul> </li> </ul> <hr> <h2>4. サブスクリプションタイプを活かしたユースケース実例</h2> <p>Pulsar では、<strong>1つのトピック</strong> に複数のサブスクリプションを張り、それぞれ <strong>異なるサブスクリプションタイプ</strong> を同時に利用できます。<br> ここでは具体例を 3つ示します。</p> <h3>4-1. 監査ログ + リアルタイム分析</h3> <h4>シナリオ</h4> <ul> <li>トピック <code>audit-logs</code> にユーザ操作ログなどを集積している。</li> <li><strong>監査</strong> 向けには「時系列どおり全メッセージを1台で処理」したい (順序重視)。</li> <li><strong>リアルタイム分析</strong> 向けには「並列分散」して高スループットで処理したい (スピード重視)。</li> </ul> <h4>実装イメージ</h4> <ol> <li> <p><strong>監査向けサブスクリプション</strong></p> <ul> <li>サブスクリプション名: <code>audit-subscription</code></li> <li>タイプ: <strong>Exclusive</strong> (もしくは Failover)</li> <li>1台(またはフェイルオーバー構成)でログをすべて取得し、厳密な時系列で保存・検証する。</li> </ul> </li> <li> <p><strong>分析向けサブスクリプション</strong></p> <ul> <li>サブスクリプション名: <code>analysis-subscription</code></li> <li>タイプ: <strong>Shared</strong></li> <li>複数インスタンスで並列に取り込み、リアルタイム集計・ダッシュボード更新などを行う。</li> </ul> </li> </ol> <h3>4-2. ユーザIDごとのワークフロー制御 + バッチ処理</h3> <h4>シナリオ</h4> <ul> <li>ECサイトのイベント <code>user-events</code>。</li> <li>リアルタイムには <strong>「ユーザID単位の順序」を守りたい</strong> (注文→決済→配送リクエストなどのステートマシン処理)。</li> <li>別途 <strong>バッチ処理</strong> で全メッセージを定期的に取得し、大規模分析したい。</li> </ul> <h4>実装イメージ</h4> <ol> <li> <p><strong>ワークフロー制御用サブスクリプション</strong></p> <ul> <li>サブスクリプション名: <code>workflow-subscription</code></li> <li>タイプ: <strong>Key_Shared</strong></li> <li><code>userId</code> をキーとして、同じユーザIDのイベントは必ず同じ Consumer が順序通りに処理する。</li> </ul> </li> <li> <p><strong>バッチ用サブスクリプション</strong></p> <ul> <li>サブスクリプション名: <code>batch-subscription</code></li> <li>タイプ: <strong>Exclusive / Failover / Shared</strong> のいずれか</li> <li>定期的に全メッセージを取得し、Hadoop/Spark などでまとめて分析。</li> </ul> </li> </ol> <h3>4-3. 高信頼レプリケーション + 即時アラート</h3> <h4>シナリオ</h4> <ul> <li>IoT センサーからのデータ <code>sensor-data</code> が大量に流れてくる。</li> <li>すべてのデータを <strong>バックアップ</strong> (外部ストレージなど) し、高い耐久性を確保したい。</li> <li>一方で <strong>リアルタイムアラート</strong> (閾値超過検知など) にも活用したい。</li> </ul> <h4>実装イメージ</h4> <ol> <li> <p><strong>レプリケーション/バックアップ用サブスクリプション</strong></p> <ul> <li>サブスクリプション名: <code>backup-subscription</code></li> <li>タイプ: <strong>Exclusive</strong> (または Failover)</li> <li>1台がすべてのメッセージを漏れなく取り込み、外部に連携する。</li> <li>障害時は Failover で別 Consumer がすぐに引き継ぐ。</li> </ul> </li> <li> <p><strong>リアルタイムアラート用サブスクリプション</strong></p> <ul> <li>サブスクリプション名: <code>alert-subscription</code></li> <li>タイプ: <strong>Shared</strong></li> <li>センサーイベントを並列に処理し、閾値超過時に即アラートを発行。</li> <li>スケールアウトしやすく、高速応答が期待できる。</li> </ul> </li> </ol> <hr> <h2>5. まとめ</h2> <ul> <li><strong>順序保証(Ordering)</strong> の観点では、<strong>Kafka</strong> も <strong>Pulsar</strong> も <strong>「パーティション単位で到着順を保証し、パーティション間のグローバル順序は保証しない」</strong> という点では共通しています。</li> <li><strong>違い</strong> は、<strong>Pulsar</strong> が標準で持つ <strong>多様なサブスクリプションタイプ</strong> による <strong>Consumer モデルの柔軟性</strong> にあります。 <ul> <li>Kafka では「Consumer Group → パーティション割り当て」で順序制御するのが主流。1パーティションを複数 Consumer で並行処理したい場合はアプリケーション側の管理が必要。</li> <li>Pulsar では <strong>Shared / Key_Shared</strong> が用意されており、<strong>パーティション内でも並列かつ Key 単位で順序を維持</strong> するような運用が容易です。</li> </ul> </li> <li>同じトピックを複数の目的で読みたい場合、Kafka では通常トピックを複製するか Consumer Group を別々に作成しますが、<strong>Pulsar では「サブスクリプションごとに異なるタイプ」を併用</strong> できるため、1つのデータストリームをより多角的に活用できるのが特徴です。</li> </ul> <p>以上のように、<strong>Pulsar vs Kafka</strong> の比較ポイントとして、</p> <ol> <li><strong>サブスクリプション(コンシューマモデル)</strong></li> <li><strong>Producer からのルーティング</strong></li> <li><strong>順序保証の範囲(パーティション内 vs グローバル)</strong></li> <li><strong>ユースケース別の活用方法</strong></li> </ol> <p>を理解しておくと、要件に合ったメッセージング設計を行いやすくなります。</p>

v1.Kafka/Pulsarの選択ガイドラインを作りたい

Tue, 21 Jan 2025 22:56:41 GMT

<h2>Kafka と Pulsar のガイドライン作成に向けた調査メモ</h2> <p>私は今、OSSのApachePulsarを扱うチームに所属しています。<br> 最近、会社と会社がフィージョンした結果、社内に我々Pulsarチームと、新しい仲間のKafkaチームが出来上がりました。<br> PulsarとKafkaはともにApache Software Foundationに寄贈されているOSSであり、どちらも分散メッセージング基盤の代表格です。</p> <p>さて、問題は、利用者から見てどっちのプロダクトを使えばいいのだろうか？ということが分かりづらいことです。<br> もちろん目に見えた機能差異はありますので、それらを必要としている人にとってはあまり困らないかもしれませんが、そういったものがない利用者にとっての最適解をガイドするのが運用側の役割でもあります。</p> <p>今回はもしガイドを作成するとしたらどんな内容にしていくのがいいのだろうか？<br> というのを考えながらそれをメモして、複数記事にわたって掘り下げたいと思います。</p> <hr> <h2>ガイドラインに盛り込むべき主な項目</h2> <h3>1. ガイドラインの目的と前提</h3> <ul> <li><strong>目的</strong>: なぜガイドラインが必要なのか、どんなシーンで参照されるのかを明確化する <ul> <li>例: 「新規システムでメッセージング基盤を使いたい」「既存システムのリプレースを検討している」「開発チームが検証したい」など</li> </ul> </li> <li><strong>前提</strong>: どの程度の規模（メッセージ量、利用ユーザー数）、どんな SLA/SLO を想定しているか <ul> <li>「スモールスタート向け」「エンタープライズ全体の大規模ユースケース」など</li> </ul> </li> </ul> <h3>2. 基本的なアーキテクチャの違い</h3> <ul> <li><strong>Kafka の全体像</strong>: Broker 内のログ構造、パーティション管理、Zookeeper もしくは KIP-500 (ZooKeeperless) の話など</li> <li><strong>Pulsar の全体像</strong>: Broker と BookKeeper の分離構成、journal & ledger、マルチテナント設計など</li> <li><strong>比較ポイント</strong>: どこにデータが書き込まれ、どこで読み出されるのか。どのようにスケールするのか。</li> </ul> <h3>3. 選定判断のポイント（ユースケース・要件別）</h3> <ul> <li><strong>スループット要件 / レイテンシ要件</strong> <ul> <li>どれくらいのメッセージ量を捌きたいか、それに応じた Kafka/Pulsar の性能事例</li> </ul> </li> <li><strong>トピック数 / サブスクリプション数 / テナント数</strong> <ul> <li>マルチテナントや大量トピックが想定される場合は Pulsar が便利、など</li> </ul> </li> <li><strong>Geo-Replication / 複数データセンター運用</strong> <ul> <li>リージョンをまたいだ運用が必要なら Pulsar のジオレプリケーション機能が活きる</li> </ul> </li> <li><strong>キューイング用途 or イベントストリーミング用途</strong> <ul> <li>Kafka ではイベントストリーミング、Pulsar はキューイングと Pub/Sub を混在させられる etc.</li> </ul> </li> </ul> <h3>4. 運用・管理面の考慮事項</h3> <ul> <li><strong>インフラ構成</strong> <ul> <li>オンプレかクラウドか、Kubernetes での運用か、マネージドサービス（Confluent Cloud, StreamNative etc.）を利用するか</li> </ul> </li> <li><strong>スケーラビリティ</strong> <ul> <li>どのようにノードを増減して負荷に対応するか</li> <li>Kafka は Broker 台数増減、Pulsar は Broker 層と BookKeeper 層を分離して増やす構成</li> </ul> </li> <li><strong>可観測性（モニタリング / ログ / トレース）</strong> <ul> <li>Prometheus, Grafana などの統合監視のやり方</li> <li>死活監視・リソース監視・トピックのレイテンシ監視 etc.</li> </ul> </li> <li><strong>障害対応・リカバリー</strong> <ul> <li>Broker/Bookie の故障に対する自動復旧や、データ再配置までの手順</li> <li>メンテナンスやバージョンアップの手順・注意点</li> </ul> </li> </ul> <h3>5. セキュリティ / 認証・認可 / マルチテナント</h3> <ul> <li><strong>認証方式の違い</strong> <ul> <li>Kafka: SASL/SSL、RBAC、ACL</li> <li>Pulsar: TLS、Token 認証、Namespace レベルのアクセス制御</li> </ul> </li> <li><strong>マルチテナント管理</strong> <ul> <li>Kafka で複数部門やプロジェクトを分割管理するにはどうするか</li> <li>Pulsar のテナント/Namespace を使った場合の運用フロー</li> </ul> </li> <li><strong>監査ログやコンプライアンス要件</strong> <ul> <li>金融や医療などの高いセキュリティ要件への対応</li> </ul> </li> </ul> <h3>6. パフォーマンステスト項目</h3> <ul> <li><strong>テストシナリオ定義</strong> <ul> <li>「一定のメッセージサイズ・一定のメッセージレートで書き込み＋読み取り」</li> <li>「多くのトピックを同時に扱う」など現場想定シナリオ</li> </ul> </li> <li><strong>測定環境・条件</strong> <ul> <li>同一ハードウェアでの比較を行うか、クラウドのどのインスタンスタイプを使うか</li> <li>どんなネットワーク条件下で測定するか</li> </ul> </li> <li><strong>測定するメトリクス</strong> <ul> <li>スループット (MB/s, msg/sec)、平均レイテンシ、p99 レイテンシ</li> <li>CPU / メモリ / ディスク IO / ネットワーク帯域使用量</li> <li>Broker/BookKeeper のリソース使用率など</li> </ul> </li> </ul> <h3>7. コスト試算</h3> <ul> <li><strong>インフラコスト</strong> <ul> <li>Kafka: Broker 台数とストレージ容量、レプリケーション係数</li> <li>Pulsar: Broker 層 + BookKeeper 層（journal / ledger のストレージ構成）、必要な高速ディスク数</li> </ul> </li> <li><strong>クラウド上での料金計算例</strong> <ul> <li>EC2 インスタンスタイプ、EBS の種類や IOPS、ネットワーク転送料 etc.</li> </ul> </li> <li><strong>オンプレの場合</strong> <ul> <li>物理サーバー・ディスク構成、保守運用コスト</li> </ul> </li> </ul> <h3>8. ガイドライン策定後の運用体制 / 権限分掌</h3> <ul> <li><strong>チーム連携</strong> <ul> <li>Pulsar チーム / Kafka チーム / インフラチーム / セキュリティチームそれぞれの役割</li> </ul> </li> <li><strong>サポート体制・問い合わせフロー</strong> <ul> <li>社内サービスデスクの窓口や、マネージドベンダーとの連携</li> </ul> </li> <li><strong>バージョンアップ方針</strong> <ul> <li>どのように長期サポートバージョンを選定するか、メジャーバージョンアップをいつ行うか</li> </ul> </li> </ul> <h3>9. 事例紹介・参考リンク</h3> <ul> <li><strong>社内事例</strong> <ul> <li>具体的にどのプロジェクトがどのように Kafka/Pulsar を使っているか</li> <li>運用実績（メッセージ量、成功例・失敗例）</li> </ul> </li> <li><strong>一般的なユースケース例</strong> <ul> <li>ログ収集・IoT・金融・SaaS 通知など</li> </ul> </li> <li><strong>関連ドキュメント・OSS ツールのリンク</strong> <ul> <li>オフィシャルドキュメント、運用ガイドライン、Metrics ツール等</li> </ul> </li> </ul> <hr> <h2>ガイドライン執筆のための調査 & 測定項目</h2> <p>ガイドラインを作成するにあたって、上記の各項目を裏付ける <strong>客観的なデータやエビデンス</strong> が必要になります。そこで、特に重視したい調査・測定項目を整理しました。</p> <ol> <li> <p><strong>性能比較テスト</strong></p> <ul> <li>同じ条件で Kafka / Pulsar に対して書き込み・読み出しを行い、スループットやレイテンシを比較</li> <li>1 トピックあたりの負荷試験だけでなく、「大量トピック同時利用」や「マルチテナント運用」を想定したテスト</li> <li>p99 レイテンシ、レプリカ数を変えた場合の耐障害性と性能差</li> </ul> </li> <li> <p><strong>運用負荷や障害時の復旧テスト</strong></p> <ul> <li>Pulsar で BookKeeper ノードが 1 台故障したときの自動リカバリ挙動</li> <li>Kafka で Broker がダウンしたときのリーダーエレクションの時間</li> <li>マルチクラスターレプリケーション（あるいは Geo-Replication）が有効な状態での障害テスト</li> </ul> </li> <li> <p><strong>セキュリティ・認可設定の検証</strong></p> <ul> <li>Kafka の ACL をどの程度細かく設定できるか</li> <li>Pulsar のテナント/Namespace ポリシーでどんな要件に対応できるか</li> <li>実際に認証がうまくいかないケースや権限設定ミスがあった場合、どのような影響が出るか</li> </ul> </li> <li> <p><strong>コストの試算</strong></p> <ul> <li>クラウド環境で、想定メッセージ量を捌くために必要なインスタンス数・スペックはどのくらいか</li> <li>長期保存をしたい場合、ストレージにかかるコスト差（オンプレディスクの買い増し vs. クラウドストレージ）</li> <li>マネージドサービスを利用する場合のライセンスやサブスクリプション費用</li> </ul> </li> <li> <p><strong>実運用事例のヒアリング</strong></p> <ul> <li>社内の既存ユーザーに対して、「導入してよかった点」「苦労した点」「改善要望」などをインタビュー</li> <li>チーム間の連携や運用フローの課題も洗い出しておく</li> </ul> </li> </ol> <hr> <p>ひとまずこれをバージョン1の骨子として、よくわからんなーってところを詰めていこうと思います。<br> わたしkafkaのことは本当によくわかりませんし・・・。</p>

JavaのOSSによくみられる「shading」ってなんだ

Mon, 14 Oct 2024 14:09:58 GMT

<h1>Shadingって何</h1> <p>最近、本業の業務がOSSの運用・保守を中心に行う部署になったこともあって、「アプリケーション」開発とは異なる概念に行き合うことが増えてきた。<br> アプリケーションを開発していたときは、ベースはOSSの組み合わせで実現され、ロジックやデータフローを表現していけばそれで良かった。<br> しかし、OSSの保守運用（コミッター活動を含む）となると話は別で、ネイティブな言語仕様やOSSが隠してくれていた泥臭い部分の解決について理解することが重要になる。</p> <h2>PR</h2> <p>例えば下記のPR。<br> <a href="https://github.com/apache/pulsar/pull/19458">https://github.com/apache/pulsar/pull/19458</a><br> これは見ての通り、Apache Pulsarで使用されるClient側コードの修正になっている。<br> 修正対象の事象はClassのロードエラーで、アプリケーション開発だとまずお目にかからないエラーだ。なぜならそんなコードはコンパイルできないからである。<br> しかしOSSでは発生しうる。<br> この原因になったのがOSS側で行っているshadingである。</p> <h2>クラスパスの解決</h2> <p>shadingの説明に入る前に、Javaにおけるクラスパスの解決についておさらい。<br> maven, gradleを使用している際に、同名のクラスパスに複数のバージョンが重なっている場合どのように解決されるか？<br> 通常は一番新しいバージョンによって上書きされる。<br> この上書きは、jarにまとめられる単位で行われるので、自作のコードだけでなく、dependencyすべてが影響を受けるということだ。<br> これを利用して、脆弱性対応がされていない外部ライブラリの依存を無理やり新しいバージョンに差し替えることも可能である。（正しく動くかは別の話）</p> <h2>OSSにおけるクラスパスの解決</h2> <p>Apache Pulsarなど、独立性が強いOSSにおいては、外部依存のライブラリによって自らのクライアントが使用しているバージョンが変更されることは望ましい挙動ではない。<br> 特に、ClientはSpringFrameworkなどに組み込まれて使われることも一般的であるため、内部で使用している有名どころのOSSなんかはすぐに衝突してしまう。<br> こうなると、正しい挙動をするかどうかが保証されなくなってしまうし、いちいち正しいバージョンになるように解決することは人手でも自動でも不可能に近い。<br> (<code>dependency-hell</code> と呼ばれる)<br> これを解決する方法の一つがshadingである</p> <h2>shading</h2> <p>shadingは「あるクラスパスを別のクラスパスで表現し直す」機能である。<br> 実際にコードを見てみる。<br> <a href="https://github.com/massakam/pulsar/blob/42c72d1177f2be6ade02f84d5eedb910d51cd891/pulsar-client-shaded/pom.xml">https://github.com/massakam/pulsar/blob/42c72d1177f2be6ade02f84d5eedb910d51cd891/pulsar-client-shaded/pom.xml</a></p> <p>maven-shade-plugin によってshadingを行っているタスクである。</p> <pre><code class="language-xml"> <plugin>  <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <executions> <execution> <phase>${shadePluginPhase}</phase> <goals> <goal>shade</goal> </goals> <configuration> <createDependencyReducedPom>true</createDependencyReducedPom> <promoteTransitiveDependencies>true</promoteTransitiveDependencies> <minimizeJar>false</minimizeJar>

          &lt;artifactSet&gt;
            &lt;includes&gt;
              &lt;include&gt;org.apache.pulsar:pulsar-client-original&lt;/include&gt;
              &lt;include&gt;org.apache.bookkeeper:*&lt;/include&gt;
              &lt;include&gt;org.apache.commons:commons-lang3&lt;/include&gt;
              &lt;include&gt;commons-codec:commons-codec&lt;/include&gt;
              &lt;include&gt;commons-collections:commons-collections&lt;/include&gt;
              &lt;include&gt;org.asynchttpclient:*&lt;/include&gt;
              &lt;include&gt;io.netty:netty-codec-http&lt;/include&gt;
              &lt;include&gt;io.netty:netty-transport-native-epoll&lt;/include&gt;
              &lt;include&gt;org.reactivestreams:reactive-streams&lt;/include&gt;
              &lt;include&gt;com.typesafe.netty:netty-reactive-streams&lt;/include&gt;
              &lt;include&gt;org.javassist:javassist&lt;/include&gt;
              &lt;include&gt;com.google.guava:*&lt;/include&gt;
              &lt;include&gt;org.checkerframework:*&lt;/include&gt;
              &lt;include&gt;com.google.code.findbugs:*&lt;/include&gt;
              &lt;include&gt;com.google.errorprone:*&lt;/include&gt;
              &lt;include&gt;com.google.j2objc:*&lt;/include&gt;
              &lt;include&gt;com.google.code.gson:gson&lt;/include&gt;
              &lt;include&gt;com.fasterxml.jackson.*:*&lt;/include&gt;
              &lt;include&gt;io.netty:*&lt;/include&gt;
              &lt;include&gt;io.netty.incubator:*&lt;/include&gt;
              &lt;include&gt;io.perfmark:*&lt;/include&gt;
              &lt;include&gt;org.eclipse.jetty:*&lt;/include&gt;
              &lt;include&gt;com.yahoo.datasketches:*&lt;/include&gt;
              &lt;include&gt;commons-*:*&lt;/include&gt;
              &lt;include&gt;io.swagger:*&lt;/include&gt;
              &lt;include&gt;io.airlift:*&lt;/include&gt;

              &lt;include&gt;org.apache.pulsar:pulsar-common&lt;/include&gt;
              &lt;include&gt;com.yahoo.datasketches:sketches-core&lt;/include&gt;
              &lt;include&gt;org.objenesis:*&lt;/include&gt;
              &lt;include&gt;org.yaml:snakeyaml&lt;/include&gt;

              &lt;include&gt;org.apache.avro:*&lt;/include&gt;
              &lt;!-- Avro transitive dependencies--&gt;
              &lt;include&gt;com.thoughtworks.paranamer:paranamer&lt;/include&gt;
              &lt;include&gt;org.apache.commons:commons-compress&lt;/include&gt;
              &lt;include&gt;org.tukaani:xz&lt;/include&gt;
              &lt;!-- Issue #6834, Since Netty ByteBuf shaded, we need also shade this module --&gt;
              &lt;include&gt;org.apache.pulsar:pulsar-client-messagecrypto-bc&lt;/include&gt;
            &lt;/includes&gt;
            &lt;excludes&gt;
              &lt;exclude&gt;com.fasterxml.jackson.core:jackson-annotations&lt;/exclude&gt;
            &lt;/excludes&gt;
          &lt;/artifactSet&gt;
          &lt;filters&gt;
            &lt;filter&gt;
              &lt;artifact&gt;org.apache.pulsar:pulsar-client-original&lt;/artifact&gt;
              &lt;includes&gt;
                &lt;include&gt;**&lt;/include&gt;
              &lt;/includes&gt;
              &lt;excludes&gt;
                &lt;!-- bouncycastle jars could not be shaded, or the signatures will be wrong--&gt;
                &lt;exclude&gt;org/bouncycastle/**&lt;/exclude&gt;
              &lt;/excludes&gt;
            &lt;/filter&gt;
          &lt;/filters&gt;
          &lt;relocations&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.asynchttpclient&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.asynchttpclient&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.apache.commons&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.apache.commons&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;io.airlift&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.io.airlift&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;com.google&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.com.google&lt;/shadedPattern&gt;
              &lt;excludes&gt;
                &lt;exclude&gt;com.google.protobuf.*&lt;/exclude&gt;
              &lt;/excludes&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;com.fasterxml.jackson&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.com.fasterxml.jackson&lt;/shadedPattern&gt;
              &lt;excludes&gt;
                &lt;exclude&gt;com.fasterxml.jackson.annotation.*&lt;/exclude&gt;
              &lt;/excludes&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;io.netty&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.io.netty&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.checkerframework&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.checkerframework&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;javax.annotation&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.javax.annotation&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;io.swagger&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.io.swagger&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.apache.pulsar.policies&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.apache.pulsar.policies&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;com.yahoo.datasketches&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.com.yahoo.datasketches&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;com.yahoo.sketches&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.com.yahoo.sketches&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.eclipse.jetty&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.eclipse&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.reactivestreams&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.reactivestreams&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;com.typesafe&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.com.typesafe&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;com.yahoo.memory&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.com.yahoo.memory&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.objenesis&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.objenesis&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.yaml&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.yaml&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.apache.avro&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.apache.avro&lt;/shadedPattern&gt;
              &lt;excludes&gt;
                &lt;exclude&gt;org.apache.avro.reflect.AvroAlias&lt;/exclude&gt;
                &lt;exclude&gt;org.apache.avro.reflect.AvroDefault&lt;/exclude&gt;
                &lt;exclude&gt;org.apache.avro.reflect.AvroEncode&lt;/exclude&gt;
                &lt;exclude&gt;org.apache.avro.reflect.AvroIgnore&lt;/exclude&gt;
                &lt;exclude&gt;org.apache.avro.reflect.AvroMeta&lt;/exclude&gt;
                &lt;exclude&gt;org.apache.avro.reflect.AvroName&lt;/exclude&gt;
                &lt;exclude&gt;org.apache.avro.reflect.AvroSchema&lt;/exclude&gt;
                &lt;exclude&gt;org.apache.avro.reflect.Nullable&lt;/exclude&gt;
                &lt;exclude&gt;org.apache.avro.reflect.Stringable&lt;/exclude&gt;
                &lt;exclude&gt;org.apache.avro.reflect.Union&lt;/exclude&gt;
              &lt;/excludes&gt;
            &lt;/relocation&gt;
            &lt;!--Avro transitive dependencies--&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.codehaus.jackson&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.codehaus.jackson&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;com.thoughtworks.paranamer&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.com.thoughtworks.paranamer&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.apache.commons&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.apache.commons&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.tukaani&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.tukaani&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
            &lt;relocation&gt;
              &lt;pattern&gt;org.apache.bookkeeper&lt;/pattern&gt;
              &lt;shadedPattern&gt;org.apache.pulsar.shade.org.apache.bookkeeper&lt;/shadedPattern&gt;
            &lt;/relocation&gt;
          &lt;/relocations&gt;
          &lt;transformers&gt;
            &lt;transformer implementation=&quot;org.apache.maven.plugins.shade.resource.ServicesResourceTransformer&quot; /&gt;
            &lt;transformer implementation=&quot;org.apache.maven.plugins.shade.resource.PluginXmlResourceTransformer&quot; /&gt;
          &lt;/transformers&gt;
        &lt;/configuration&gt;
      &lt;/execution&gt;
    &lt;/executions&gt;
  &lt;/plugin&gt;

</code></pre> <p>artifactSet.includeはshading対象のクラスパスを示し、relocations.relocationはどのクラスパスをどんなクラスパスに変更するかが記載されている。</p> <p>ここで重要なのは、shadingの対象にするにはincludeにそのパスを記載する必要があるということと、<br> relocationは実際にそのクラスファイルが存在するかは気にしていないとうことである。<br> PRの編集内容がまさにそれを修正している。</p> <h2>PRの修正内容</h2> <p>PRでは、主に <code>< include >com.fasterxml.jackson.:</ include ></code> の追加と、それによって不要になるincludeの削除を行っている。<br> また、ユーザがアノテーションを使用する都合でjacksonのanotationクラスはexcludeされている。</p> <p>実際に問題を発生させていたのは、<code>pulsar-client-shaded</code> で jacksonのdatatypeをinclude指定内にも関わらず、com.fasterxml.jacksonをリロケーションしていることにある。</p> <p>これによって、リロケーションされたdatatypeは解決できるクラスがなくなってしまったため、例外になっている。</p> <h1>まとめ</h1> <p>shadingは適切に利用すると依存関係の変更からライブラリを守ることができる。<br> しかし、新しいライブラリを追加したときや、ワイルドカードを使用できないときなどはinclude/excludeとrelocationの設定を正しく行わなければ実行時エラーを招く原因になる。<br> あまり業務アプリケーションで使用したい機能ではないね。そんなシチュエーションは限られていると思うけど。</p>

AIでふっるいCVEの調査にあたりをつけてみる

Wed, 18 Sep 2024 12:21:18 GMT

<h1>今回の試み</h1> <p>最近よくLLM周りのツールを色々触っているのですが、新規開発ばかりに利用して、既存改修などではあまり活用できていません。(Cursorの力は借りていますが)</p> <p>そこで、今回はOSS絡みで調査が必要になっている古い脆弱性「CVE-2015-5237」について、生成AIを使用しながら調査してみたいと思います。</p> <h2>事前情報</h2> <p>CVE-2015-5237は <a href="https://github.com/protocolbuffers/protobuf/issues/760">https://github.com/protocolbuffers/protobuf/issues/760</a>で2015年に報告されたバッファオーバーフローに関する古い脆弱性です。<br> 大元のgoogle/protobufは当時様々なOSSが採用していたこともあり、影響としては大きなものであったようです。</p> <p>ただ、2015年当時の脆弱性ということもあって、あまり詳しい情報はやり取りがありません。google/protobufの実装は色々あるのですが、C++の話はしていますが他のクライアントでどうなのか不明です。</p> <h3>脆弱性検知ツールでの扱い</h3> <p><a href="https://security.snyk.io/vuln/?search=CVE-2015-5237">snyk</a>において、C++とPHPに脆弱性を認めていますが、Javaの脆弱性はかなり低い評価になっています。(Redhatのスコアが低いためと見られる)<br> この点についてなぜそうなのか記録が残っていません。</p> <p>つまり、Web上にはたいした情報が転がっていないという状況です。</p> <h1>調査の試み</h1> <p>まず、検索AI Perplexityを試してみましたが、これは惨敗か、、と思いきや下記を見つけてくれました。</p> <p><a href="https://security.snyk.io/vuln/SNYK-JAVA-COMGOOGLEPROTOBUF-173761">https://security.snyk.io/vuln/SNYK-JAVA-COMGOOGLEPROTOBUF-173761</a></p> <p>最初、SnykのDBを見たときは前述の通り、javaには低いスコアしかないなあ、と思ったのですが、どうやらUIが悪く、全部表示されていない上にページングもできないようです。<br> Mavenで絞った場合に限り上記を確認できました。Javaでもハイスコアとなっています。</p> <h2>コードベースの調査</h2> <p>次に、v2.4.1のprotobufをダウンロードして、Cursorで質問しました。この際に使用したLLM modelはclaude3.5 sonnetと割と強めのAIを選定しています。<br> 質問の際には <code>Codebase Answers</code> を使用しています。この機能では、開いているファイルだけでなく、質問内容から内蔵のベクトルDBにベクトル化されているソースコードを検索し、必要そうなファイルをLLMに渡してくれます。</p> <p>以下、全文を掲載します。</p> <h3>Q. 初期情報を与えて質問する</h3> <p>このプロジェクトはCVE-2015-5237: Integer overflow in serialization が報告されたprotobufです。<br> 下記のIssueに書かれている脆弱性が埋め込まれているコードを特定してください</p> <pre><code>int is used to express the size of serialized messages. If the size exceeds 4 GiB, the application may allocate a buffer which is too small, or protobuf itself does this, in google::protobuf::MessageLite::SerializeToString. This lead to a heap buffer overflow, which may be exploitable for code execution in some cases. It has been suggested that serialization of messages larger than 2 GiB is unsupported. But there is no good way for an application to ensure that the limit is not exceeded accidentally, without imposing rather draconian limits. To some degree, this is an gets-style interface. Right now, this is more or less harmless because the message sizes involved are substantial. But this will change over time. My worry is that it will be difficult to fix this because some of the overflowing computations end up in generated *.pb.cc files, so the eventual fix will not be a simple library update. </code></pre> <h3>A. 回答</h3> <p>この脆弱性は主にメッセージのシリアライズ処理に関連しています。特に重要な部分は以下のコードブロックにあります:</p> <pre><code class="language-229:258:src/google/protobuf/message_lite.cc"> GOOGLE_DCHECK(IsInitialized()) << InitializationErrorMessage("serialize", *this); return SerializePartialToCodedStream(output); }

bool MessageLite::SerializePartialToCodedStream( io::CodedOutputStream* output) const { const int size = ByteSize(); // Force size to be cached. uint8* buffer = output->GetDirectBufferForNBytesAndAdvance(size); if (buffer != NULL) { uint8* end = SerializeWithCachedSizesToArray(buffer); if (end - buffer != size) { ByteSizeConsistencyError(size, ByteSize(), end - buffer); } return true; } else { int original_byte_count = output->ByteCount(); SerializeWithCachedSizes(output); if (output->HadError()) { return false; } int final_byte_count = output->ByteCount();

if (final_byte_count - original_byte_count != size) {
  ByteSizeConsistencyError(size, ByteSize(),
                           final_byte_count - original_byte_count);
}

return true;

} } </code></pre> <p>このコードブロックでは、<code>SerializeToString</code>メソッドが実装されています。ここで、メッセージのサイズを<code>int</code>型で扱っているため、4GiBを超えるサイズのメッセージをシリアライズしようとすると整数オーバーフローが発生する可能性があります。</p> <p>また、以下のコードブロックも関連しています:</p> <pre><code class="language-499:522:src/google/protobuf/io/coded_stream.cc"> const void* void_buffer; int buffer_size; if (NextNonEmpty(input_, &void_buffer, &buffer_size)) { buffer_ = reinterpret_cast<const uint8*>(void_buffer); buffer_end_ = buffer_ + buffer_size; GOOGLE_CHECK_GE(buffer_size, 0);

if (total_bytes_read_ &lt;= INT_MAX - buffer_size) {
  total_bytes_read_ += buffer_size;
} else {
  // Overflow.  Reset buffer_end_ to not include the bytes beyond INT_MAX.
  // We can't get that far anyway, because total_bytes_limit_ is guaranteed
  // to be less than it.  We need to keep track of the number of bytes
  // we discarded, though, so that we can call input_-&gt;BackUp() to back
  // up over them on destruction.

  // The following line is equivalent to:
  //   overflow_bytes_ = total_bytes_read_ + buffer_size - INT_MAX;
  // except that it avoids overflows.  Signed integer overflow has
  // undefined results according to the C standard.
  overflow_bytes_ = total_bytes_read_ - (INT_MAX - buffer_size);
  buffer_end_ -= overflow_bytes_;
  total_bytes_read_ = INT_MAX;
}

</code></pre> <p>このコードでは、バッファサイズの計算が行われていますが、<code>int</code>型を使用しているため、同様に整数オーバーフローの問題が発生する可能性があります。</p> <p>これらのコードブロックは、大きなメッセージをシリアライズする際に整数オーバーフローを引き起こし、結果としてバッファオーバーフローを引き起こす可能性があります。これは、メモリ破壊や潜在的なコード実行の脆弱性につながる可能性があります。</p> <p>修正するには、これらの部分で64ビット整数型を使用するか、メッセージサイズに上限を設けるなどの対策が必要です。また、生成された*.pb.ccファイルにも影響を与える可能性があるため、単純なライブラリの更新だけでは解決できない可能性があります。</p> <h3>Q. 他のパッケージへの影響を聞く</h3> <p>javaディレクトリ以下にあるprotobuf-javaにこの影響がどう関わるか調べてください</p> <h3>A. 追加の回答</h3> <p>protobuf-javaにおけるCVE-2015-5237の影響を調査しました。この脆弱性は主にメッセージのシリアライズ処理に関連しています。javaディレクトリ以下の関連するコードを確認したところ、以下の点が重要です：</p> <ol> <li>MessageLite.javaファイル:<br> このインターフェースはシリアライズメソッドを定義しています。特に <code>toByteString()</code> メソッドが関連しています。</li> </ol> <pre><code class="language-90:97:java/src/main/java/com/google/protobuf/MessageLite.java"> ByteString toByteString();

/**

Serializes the message to a {@code byte} array and returns it. This is
just a trivial wrapper around
{@link #writeTo(CodedOutputStream)}. */ byte[] toByteArray(); </code></pre> <ol start="2"> <li>AbstractMessageLite.java:<br> このクラスは <code>toByteString()</code> メソッドを実装しています。ここでメッセージサイズの計算と実際のシリアライズが行われます。</li> </ol> <pre><code class="language-47:58:java/src/main/java/com/google/protobuf/AbstractMessageLite.java"> public ByteString toByteString() { try { final ByteString.CodedBuilder out = ByteString.newCodedBuilder(getSerializedSize()); writeTo(out.getCodedOutput()); return out.build(); } catch (IOException e) { throw new RuntimeException( "Serializing to a ByteString threw an IOException (should " + "never happen).", e); } } </code></pre> <ol start="3"> <li>CodedOutputStream.java:<br> このクラスはバイトストリームへの書き込みを担当します。特に <code>computeMessageSizeNoTag()</code> メソッドがメッセージサイズの計算に関与しています。</li> </ol> <pre><code class="language-727:730:java/src/main/java/com/google/protobuf/CodedOutputStream.java"> public static int computeMessageSizeNoTag(final MessageLite value) { final int size = value.getSerializedSize(); return computeRawVarint32Size(size) + size; } </code></pre> <ol start="4"> <li>CodedInputStream.java:<br> このクラスはサイズ制限を設定するメソッドを持っています。これは大きすぎるメッセージの処理を防ぐために使用されます。</li> </ol> <pre><code class="language-578:586:java/src/main/java/com/google/protobuf/CodedInputStream.java"> public int setSizeLimit(final int limit) { if (limit < 0) { throw new IllegalArgumentException( "Size limit cannot be negative: " + limit); } final int oldLimit = sizeLimit; sizeLimit = limit; return oldLimit; } </code></pre> <p>これらのコードは、メッセージのシリアライズとデシリアライズ、およびサイズの計算と制限に関連しています。CVE-2015-5237の脆弱性は、4GiBを超えるサイズのメッセージを処理する際に整数オーバーフローが発生する可能性があるというものです。</p> <p>Java実装では、int型（32ビット）を使用してメッセージサイズを扱っているため、この問題が発生する可能性があります。特に、<code>CodedOutputStream.computeMessageSizeNoTag()</code>メソッドや<code>AbstractMessageLite.toByteString()</code>メソッドでのサイズ計算において、大きなメッセージを扱う際にオーバーフローが起こる可能性があります。</p> <p>この脆弱性を修正するためには、メッセージサイズの計算と制限において64ビット整数を使用するか、明示的にサイズチェックを行うなどの対策が必要です。また、<code>CodedInputStream.setSizeLimit()</code>メソッドを適切に使用して、処理するメッセージサイズに上限を設けることも重要です。</p> <h2>評価</h2> <p>まず、最初の質問で返されたC++のコードはまさしく対象のコードでした。これはまだ、Issueの中に示唆があるので見つけられるのもわかりますが、解説付きで探してくれるのは大変ありがたいです。</p> <p>次の質問は、javaパッケージに与える影響を水平に質問しただけですが、こちらも的確にシリアライズを行っている関数と、int型で定義された計算フローを見つけてくれました。<br> この実装からして、C++だけでなくjavaでも間違いなく4GBを超えるメッセージを取り扱うとバッファオーバーフローを引き起こせることがわかります。</p> <p>なぜJVMで発生するバッファオーバーフローがハイスコアに評価されているのか疑問は残りますが、下記2点がわかるまで30分たらずでした。ニンゲンの手だけではこうは行かないでしょう。</p> <ul> <li>セキュリティベンダーでC++もjavaもハイリスクに分類されている</li> <li>コードベースでみて、C++、Javaどちらでも発生しうる</li> </ul>

2024-08-30

Fri, 30 Aug 2024 02:01:21 GMT

<h1>Topics</h1> <ul> <li>台風が来ているけど帰省する話</li> <li>AIの利活用の話</li> </ul> <h1>台風が来ているけど帰省する話</h1> <p>1ヶ月前から、8/29-9/1にお盆に代わって帰省することを考えていた。<br> 妻もそのつもりでスケジュールを組んでいたので、今さら帰らないという選択肢も取りづらい。</p> <p>しかし、8/28日段階で想定できる台風の強さと経路はなかなかのもので、大阪から松山への移動はともかく、9/1段階で伊丹空港への影響が強く懸念される状況にあった。</p> <p><img src="https://ik.imagekit.io/0vbjzxbih/7163c510-3f58-41a8-b7c3-4bad9b094588/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-08-309.52.53.png" alt="スクリーンショット2024-08-309.52.53.png"><br> <a href="https://weathernews.jp/s/topics/202408/290275/">引用</a></p> <p>この台風10号はうまく偏西風に乗れておらず、東西を高気圧に挟まれて進路に影響を受ける状態であり、時間単位で気象予報に変化が見られるような状況だったので、3,4日先の天気の見通しが全く立たない。</p> <h2>移動手段</h2> <p>大阪と愛媛の間を移動する手段はいくつかある。</p> <ul> <li>飛行機 <ul> <li>ANA、JAL共にあるがANAがメインで伊丹空港を使用する。</li> </ul> </li> <li>新幹線・電車 <ul> <li>広島あたりまで新幹線で行ってから、電車で四国に乗り入れるルート。</li> </ul> </li> <li>陸路 <ul> <li>自家用車 or 高速バス</li> </ul> </li> <li>船 <ul> <li>オレンジフェリーが東予港と大阪港を結んでいる。夜に出て朝着く感じ。</li> </ul> </li> </ul> <p>しかし、空路と海路は台風にすこぶる弱いのである。<br> 新幹線と電車の併用と陸路は大して所要時間に差はない。<br> まして、自分は自家用車を持っているので陸路以外の選択肢はなかった。</p> <p>陸路の場合、瀬戸大橋や明石大橋が台風の影響を受けるが、滅多なことで通行止めには至らない。それよりも、問題になるのは1歳になったばかりの子供の存在だった。</p> <p>空路は飛行時間1時間未満、海路は一泊なのでそこまでストレスもないが、陸路で帰る場合の拘束時間はトータル6時間を超える。<br> その間チャイルドシートに縛っておくのはまあ不可能なので、必然的に一泊しながらの移動となる。</p> <h2>乳児連れでの陸路長距離移動</h2> <p>一泊することを前提にすると、泊まれる宿は限られてくる。行けるところまで行って、そのへんで泊まろう、というムーブを夜にやる場合、普通のビジネスホテルなどに泊まることはできない。</p> <p>なので必然的に宿泊先はレジャーホテルになる。注意点としては、半数以上のレジャーホテルは18歳未満の立入禁止であり、子供を入れるわけにはいかないということだ。</p> <p>こういうときにはファインガーデンが有望だが、個人的に最近のファインガーデンはやたらとたばこ臭い部屋が多くて辟易しているので、何か別の選択肢を見つけたい。<br> （実際、今回泊まったファインガーデン岡山もかなりタバコ臭かった。つらみ）</p> <h2>到着しました</h2> <p>3h/3hに移動が分割されるのでそういう意味でも楽な経路だった。日を選べば宿泊費も1万円以下に収まるので飛行機と駐車場を併用するよりは経済的。</p> <p>9/1の台風の影響がどうなるかわからないが、影響が少なければ海路が使えるはず。<br> 陸路でもいいが、その場合はまた宿泊先を探さないといけない…。</p> <h1>AIの利活用の話</h1> <p>OpenAIやClaudeのAPIを中心としていた開発周りのAI利活用も、Vercelのv0、Cursorエディタ、Create.xyz、有名どころのツールに付随するようになったAIアシスタントなど広がりを見せている。<br> 完全に群雄割拠の状態にあるので、これが定まってくるにはもう暫く掛かると思うが、莫大なお金を背景に安定したリリースを続けるOpenAIに一日の長があるようには見えている。<br> (画像生成まわりの話とかはよくわからないが…)</p> <p>AIを活用するエンジニアが増えるのは間違いないので、そこと関わる側の立場としては、作成されたコードに責任を持っているエンジニアであり続けることが重要だろうと思う。<br> AIで作って、問題があったらAIに直してもらって、というトライアンドエラーは残念ながら本番環境には通用しない。</p> <p>何かしら問題があったならそれはもうビジネスに影響が出ているわけだが、その開発を続ける限り再発防止策のとりようがない。<br> AIは責任を持ってくれないので使う側が責任を持ち続けるしかない。要は、すべてのAIが作成したコードは、作成した当事者が完全に説明可能である必要がある。</p> <p>AIに使われるエンジニアは使い捨てのなにかしか作れずあまり価値がない。うまく付き合うのが大事になるだろう。</p>

ブログのシステムを刷新しました

Sat, 17 Aug 2024 13:10:28 GMT

<h1>前書き</h1> <p>AWSでWordpress + GraphQL + Next.jsによるSSGを行っていたのですが、どうやっても微妙にコストが出続けるため、思い切って構成を大幅に変更し、SaaSを多用するようにしました。<br> 今回の変更により、ほぼ0円でブログシステムの運用が可能になったはずです。</p> <h1>システム構成</h1> <p><img src="https://ik.imagekit.io/0vbjzxbih/3fc59470-cb17-4faa-bffb-ab1a90d15198/system.png" alt="system.png"></p> <h2>SaaS</h2> <p>Headless CMSにはNewtを採用しています。これは、公式が多数のチュートリアルで他のシステムやフレームワークとの連携を公開しているから採用しやすいのが理由でした。<br> また、AWS S3やCDNとの連携も簡単であり、通信量の大部分を占めるはずの画像をCDN経由にすることで、よりお得にNewtが使えるようになるのは本当に親切だと思います。<br> Newtは画像配布のSaaSとしてImgixとImageKitの2社をサポートしています。画像の配布だけならどちらを選んでもまず無料枠に収まるのではないでしょうか。<br> アプリケーションの公開にはVercelを使用しています。NewtのWebhookとの相性、Astroとの相性などが理由です。Newtに記事を公開してから数分でデプロイが完了するのでSSGをしている感覚があまりありません。</p> <h2>Framework</h2> <p>Astroを採用しました。Next.jsやNuxt.jsもSSGは可能ですが機能的に重たすぎ、GoogleAnalyticsなどとの外部スクリプトの統合がビミョーに特別対応が必要だったりして取り回しが悪いところを全て解決できる点が魅力です。SSG中心に考えるならAstroでいいじゃんというのが今回やってみての感想でした。</p> <p>また、Astroはデザインテンプレートが充実しています。私のようにデザインの能力が皆無な人間でも、デザインテンプレートを拝借し、データの導線だけ自分で実装してしまえば良いデザインに相乗りできてしまうのは本当に良い体験でした</p> <h1>Newtの話</h1> <p>他のHeadless CMSを触ったわけではないので比較はできないのですが、少なくともWordpressをAPI経由で使うよりはずっと建設的な開発が可能です。<br> Newtはデータモデルを自分で定義、リレーションさせることができます。記事というデータモデル、タグというデータモデル、カテゴリというデータモデル、のように。<br> それぞれのモデルにはどんなデータが紐づくかを定義し、モデルとモデルの間のリレーションも定義していきます。<br> 投稿フェーズではそれに沿って入力フォームを埋めたらよいだけなので、GUIは難しくありません。</p> <h2>クライアントの話</h2> <p>Newtが提供するNode.js向けのクライアントはいくつかのAPIを提供してくれますが、その構造はいたってシンプルになっています。<br> おそらく内部的にはGraphQLが採用されているのかな、と思いますが、APIの本数でどうこうするよりは与えるパラメータによって柔軟にフィールドの取得ができます。<br> 開発のおすすめとしては、適当にAPIを叩いてJSONを取得し、そのJSONをOpenAIなどに貼り付けてTypescript用の型を生成してもらってマッピングするとあとが楽です。</p>

任天堂の中途採用面接に挑んで負けた話

Sat, 17 Aug 2024 06:14:21 GMT

<pre><code>2020-08-21 の再掲です。 </code></pre> <p>なかなか楽しかったので、経緯をまとめつつ、どんなことをしたのか受験者のマナーの範囲で書き記したいと思います。</p> <h2>きっかけ</h2> <p>自分のキャリアプランに悩みがあったので、履歴書を登録してどんなところから声をかけてもらえるだろうか、今の自分にどれだけの可能性があるだろうか、と思ってビズリーチに登録しました。</p> <p>そこで、たくさんの企業から面接どうですか、という声をいただき、関西で就業可能で興味があるものを実際に受けさせていただいていました。<br> (結局、条件や面接過程で辞退したり、落ちたりして現職のままですが)</p> <p>ある時、唐突に任天堂からオファーが届きました。</p> <h2>オファーの内容</h2> <p>そこには、ある種ユニークな誘い文句(僕のキャリアに関するコメント)と、ゲームエンジニアだけを任天堂が求めているわけではないのだ、という旨が書かれていました。</p> <p>言われてみれば当然なのですが、ぼんやり任天堂といえばゲームだし、それ関連の知識を持ってない自分には全く関係ない企業だと言う先入観があったので、とても驚いたのを覚えています。<br> 自分がオファーを受けたのは、ネットワーク、またはツール開発を担当する領域の部門であり、ゲームの裏側や、開発そのものを支えるような部門でした。</p> <p>(ちなみに年収は応相談となっていました)</p> <h2>1回目の面談</h2> <p>とはいえ、自分が任天堂に入社したとして活躍できる、役に立つイメージが湧くわけではなかったので、面談という形でお時間を頂戴しました。</p> <p>後になって知ることですが、僕の面談を担当いただいた方はゲームキューブや、ゲームキューブの初期のゲームソフト開発に関わった方であったようで、検索するといくつかの記事が出てきました。<br> 子供の頃遊んでいたアレらを作った人なのか、と思うと尊敬の念を禁じえません。とても良い経験になりました。</p> <p>面談では、具体的な業務内容や、知っておけば良い知識などに関してお話を聞きました。曰く、オンラインゲームを支える技術、という本の冒頭を理解しておけば良い、というお言葉を頂戴しましたので自分はそれに従いました。</p> <h2>気づき</h2> <p>ここでわかったことは、Webのネットワークとゲームのネットワークの知識は根底を同じくする、ということです。<br> なので、たくさん新たに勉強しなければなりませんが、既に戦える道具もまた多く持っているのです。<br> (具体的には任天堂がAWSのイベントなどで発表したネットワークがらみのお話などを拝見すると良いです。Webをかじっている人間でもちゃんと読めるはず)</p> <p>それ当然じゃん、と思うところなのですが、あまりにもゲーム界隈のネットワークのイメージがつかなすぎて、全然同じという感覚が持てていませんでした。</p> <p>違いは、ゲームが関わる世界で必要とされるネットワーク接続は、その多くがステートフルなものである、というところです。我々Webに携わる人間はステートレスな世界に生きていますが、それとは真反対です。</p> <p>面白そうだな、という理由だけで<br> ここまでで、大体意思は固まっていました。</p> <p>企業にも仕事にも興味あるし、面接内容にも興味あるぞ、と。<br> 実際転職するかどうかなんてのは、受かってから考えればいいか、という形でした。</p> <p>後に、志望理由を問われて自分は無邪気に下記のように答えています。</p> <p>一番の理由は面白い仕事ができそうだからです。<br> ユーザの心を直接動かすようなものを作っていくという仕事はそうあるものではないし、ネットワークを通じて新しいコミュニケーションの形を作っていける機会があるというのは本当に面白そうです。</p> <h2>第一関門ポートフォリオ評価</h2> <p>おそらく合否にそこまで関わっていない気がしますが、プログラミングクイズと、今までに作ったサンプルアプリケーションの提出を依頼されます。</p> <h3>サンプルアプリケーション</h3> <p>自分は2,3個提出しました。本当はもうちょいまともなシステムが1個合ったのですがアングラだったので出せませんでした…。</p> <p>Sinatraで構築されたTwitterAPIを利用するシステム。<br> フォローしているニュースアカウントの投稿の、評判がいいIT関連ニュースだけをSlackに通知するもの<br> FrontからAPIコールするAPIのサンプルアプリケーション。docker-composeのサンプルでつくっており、nginxのプロキシを使ってCORSを避けつつ複数のアプリケーションを呼んでる感じ<br> プログラミングクイズ<br> ちょっと歴のあるプログラマなら下記のサイトを知っているでしょう。</p> <p><a href="http://cp1.nintendo.co.jp/">http://cp1.nintendo.co.jp/</a></p> <p>任天堂が昔、採用に使ったCodePuzzleです。<br> これに関してある条件の元、Puzzleを解いた成果物を提出する必要があります。<br> 競技プログラミングなどと比べてもまさにPuzzleという難しさがあります。</p> <p>なお、面接でこれらに触れられることはありませんでした!</p> <h2>第二関門一次面接(技術面接)</h2> <p>任天堂の面接官の特徴かもしれませんが、とても良く履歴書や職務経歴書を読み込んでくれているように感じます。<br> 自分は結構な企業のいろんな段階の面接を経験しましたが、その中でもトップクラスに丁寧な面接をしてくれます。(悪い記憶が本当にない)</p> <p>1次面接のメインは技術に関する知識とコーディング能力です。</p> <p>口頭試問では、知っている言語の特性、フレームワークの特性、ネットワーク、データベース、セキュリティ(暗号、Web)などに関して幅広く質問されます。<br> ど忘れしていると、ヒントを出してくれるので、なんとか細かい点も思い出せました。</p> <p>コーディングテストは、そこまで難しいものではありません。競技プログラミングの初級ランクを広く抑えておけば大丈夫と思います。</p> <p>ただ、コーディングしている様子を見られながらなので妙な焦りから問題文の意図をよく読み違えました。落ち着いて読みましょう…。<br> コロナ下でしたので、自分はリモートで画面共有でしたが、普段は会議室で行われるそうです。</p> <p>(再帰処理、嫌いなんだよな…。)</p> <h2>第三関門二次面接(技術/人事面接)</h2> <p>自分の場合ちょっとイレギュラーなのかもしれませんが、前半技術面接、後半人事面接という形で進行しました。</p> <h3>技術面接</h3> <p>ここでは、システム構成に関する例題とその解決のシミュレーションをしていきます。AWSの面接に似ています。<br> 1対2の面接になります。</p> <p>雰囲気はそのへんのWeb系企業と同様で、特有なラフな雰囲気でした。僕は任天堂に保守的なイメージを持っていたので(面接はスーツだろうな、と思う程度には)これは意外でした。</p> <p>小さなシステムから要件を叶えていき、面接官が新たな要件や障害を加え、それの対応を見ていく形です。<br> 30分超行いました。正直、反省点が多かったです…。ぱっといい解決策出ないですね。</p> <p>少なくともリードレプリカなDBを置く構成や、レプリケーションにつよいNoSQLなDBを使う構成、日本だけでなく、色んな国の間で使われる前提のシステム構成などを知っておかないとクリアできない例が出てきます。<br> ネットワークがブツブツ途切れるような環境にデータを送るには、という前提には本当に困りました…。P2Pネットワーク的な発想がぱっと出る人どれくらいいるでしょうね。</p> <h3>人事面接</h3> <p>技術の方が退出、人事の方が入出され、ここから1対4になります。</p> <p>技術の方々がある程度ラフな雰囲気だったのに対し、人事の方はThe任天堂という感じで、まさしく自分のイメージしていた保守的な任天堂の姿でした。<br> 今までのキャリアに関して担当の方が一通り紹介してくれます(このシステム、他で見たことがない)</p> <p>その後、志望理由を始め、色々根掘り葉掘りされます。<br> 自分は転職が複数あったのでその理由の深堀りもかなりありました。</p> <p>全体として、一般的な人事面接ですが、質問一つ一つが鋭いので、生半可に答えを用意していると死ぬでしょう。<br> 本心で答えられるとベストです。</p> <p>あ、ちなみに好きなゲームは？のようなゲームに関する設問は一切でてきませんでした。</p> <h2>第四関門最終面接</h2> <p>2次面接から1ヶ月以上経ってます。なるほど、これが任天堂のやり方か…。（担当者の方も合否決まるまでめっちゃ長いとはいってました）</p> <p>おそらく、この3次面接が決まった段階では、スケジュール調整されて見えないライバルが複数横に並んでいます。</p> <p>コロナ下でしたが、最終面接は京都本社で行われました。</p> <p>面接前にアンケートを記入するのですが、Paizaのスコア記入欄がありました。<br> ちょっと意外です。AtCoderやLeetCodeじゃないんだ、となりました。</p> <p>最終面接は、1対7です。歴戦のツワモノと思われる方々と進行の方がお一人います。<br> 質問のベースは2次面接の人事面接と同じですが、ツワモノがそれだけ揃っているので、疑問点とかあればガンガン質問が来ます。<br> 比較的現職におけるポジション、仕事(役割)、リスクアセスメント、ストレス対処、失敗経験の深堀り、性格の傾向に絡む質問が多かったように思います。</p> <p>印象的だったのは、自分が仕事で大事にしているものなどを話すと、それに対して「たしかにそれは大事だね」等感想を述べてくれたりするところです。<br> 他社では顔色を変えない面接官を多く見ました。それに比べ、これだけ多人数な面接をされても全く圧迫感がありませんでしたし、何なら少し楽しい気持ちで去れたのは初めてでした。</p> <p>この一連の面接を通して、自分のキャリアを見直せたところもあり、良い経験になりました</p> <h2>合否報告</h2> <p>10日後にメールできました。<br> 要約すると「採用人数少ないんだ、今回はごめんね」的なことが書かれてました。</p> <p>なるほど、誰か僕より強いやつがいたんだろうな、と思えるので、特にフィードバックがなくても納得の行く良い文面でした。お祈りよりずっといい。(事実はどうあれ)</p> <h2>まとめ</h2> <p>選考期間はおよそ3ヶ月強<br> 任天堂はゲームに詳しくなくてもオファーをくれる<br> 任天堂の面接はめっちゃ好印象<br> 思ったよりコーディングテストはイージーだが、口頭試問の難易度は高め<br> 自分はとても印象が良かったので、ぜひ機会があれば挑んでいただきたいなーと思います。</p> <p>なお交通費は少しだけ黒字で出してくれました。</p>