【ITニュース解説】Building SW: Lessons from the Backend

GitHubのコミットメッセージに隠された、開発者の本音を探るユニークなプロジェクトが「SW」だ。このサービスは、GitHubのイベントデータを取り込み、そこから人間の書いたテキストを抽出し、皮肉混じりのスラングを検出する。その目的は、コンテンツを監視することではなく、開発者の感情を軽快に分析することにある。このプロジェクトは、既存のAIや機械学習に頼らず、標準ライブラリに近い技術で実現しようと試みられた。

開発当初、データストレージには多くのITプロジェクトで実績のあるPostgresが選ばれた。しかし、データ量が増え、サービスが拡大するにつれて、いくつかの問題が表面化した。具体的には、データベース内の「ビュー」と呼ばれる集計データが更新に手間がかかり、データ取り込み時にはデッドロックが発生し、システム全体のパフォーマンスが低下した。Postgresのチューニングも複雑になり、大規模な運用では限界が見えてきた。そこで、開発者はストレージ戦略を大きく見直した。新しいアプローチは、PostgresとClickHouseという二つのデータベースを組み合わせるハイブリッドモデルだ。Postgresは「コントロールプレーン」として、ユーザーの同意情報やルール、データ取り込み状況など、サービスの根幹となるメタデータを管理する役割を担う。Postgres 18の新しい機能も活用し、安全性と使いやすさを向上させた。一方、ClickHouseは「ファクトストア」として、検出されたスラングの発生記録やイベントといった大量の生データを高速に処理し、集計する役割を持つ。この分割により、それぞれのデータベースが得意な処理に特化でき、システムの全体的なスケーラビリティとパフォーマンスが劇的に向上した。

スラングの検出は、一見単純に見えて非常に複雑な課題だ。開発者は文字を置き換えたり、特殊な記号を混ぜたりと、様々な方法でスラングを表現する。また、過剰な正規化は、無関係な単語をスラングと誤検出する「Scunthorpe問題」を引き起こす可能性がある。この問題に対処するため、複数のステップからなる「正規化パイプライン」が構築された。これは、テキストの文字コードを修復し、大文字小文字を統一し、特殊なスペースを取り除き、leetpeak（数字や記号で文字を置き換える表現）を一般的な文字に戻すといった処理を段階的に行うものだ。さらに、検出ルールの「ドリフト」にも対応する必要があった。初期の単純なルールでは、新しいスラング表現に対応できなかったり、誤検出が増えたりする。そこで、テンプレート、語幹（lemmas）、カテゴリ、そしてバージョン管理機能を備えた新しいJSON形式の「rulepacker」が導入された。これにより、検出ルールを柔軟に進化させながら、過去のデータを再処理することなく、新しいルールを適用できるようになった。Aho-Corasickのような効率的な文字列検索アルゴリズムを導入することで、高速な検出も可能になった。

GitHubのコミットメッセージには言語情報が付与されていないため、入力されたテキストがどの言語で書かれているかを判別するのも大きな課題だった。開発者は最初、Unicodeの文字範囲を数えるという素朴な方法で日本語や韓国語などを判別するスクリプトを試した。その後、Postgresの拡張機能で言語検出を行う方法を経て、最終的にはClickHouseの実験的なNLP（自然言語処理）機能を利用するに至った。これにより、言語検出の速度とスケーラビリティが大幅に向上し、多言語対応の基盤が確立された。

開発者のプライバシー保護は、このプロジェクトの最も重要な側面の一つだ。SWサービスは、分析結果が個人を特定する「ドクシング」に繋がらないよう、厳格な安全策を講じている。具体的には、GitHubのリポジトリ名やユーザー名、イベントIDをそのまま保存するのをやめ、代わりにハッシュ化された一方向のID（HIDs）を使用する。個人を特定できる情報はPostgresの専用スキーマで厳重に管理され、意図しないAPIからの情報漏洩を防ぐ。ユーザーが自身のデータ利用に同意しない場合は、リポジトリのルートに特定のゼロバイトファイルをコミットすることでオプトアウトできる。逆に、自分のスラング使用状況が公開されても構わないというユーザーは、特定のGist（GitHubのコードスニペット共有サービス）を作成することでオプトインできる。これらの同意状況はPostgresに記録され、監査可能な形で管理される。デフォルトではすべてのデータが匿名化され、スラングの内容もマスクされるが、オプトインしたユーザーのデータについては、リポジトリ名やユーザー名を部分的に公開するといった柔軟な対応が可能になる。これにより、倫理的に守られたデータ分析を実現している。

SWサービスは、2011年からのGitHub Archiveという膨大な過去データを処理する必要があった。このような大規模なデータ処理では、ネットワーク障害やシステムエラーにより処理が途中で中断したり、再試行が必要になったりすることが頻繁に発生する。しかし、単純な再試行ではデータの重複や不整合が発生する可能性がある。この問題を解決するため、SWは「冪等性」という考え方を採用している。冪等性とは、ある操作を何度実行しても同じ結果になることを保証する性質だ。具体的には、各データレコードにUUIDv7とSHA-256ハッシュを組み合わせた決定論的なIDを付与することで、同じデータは常に同じIDを持つようにした。これにより、処理を再実行しても重複してデータが書き込まれたり、古いデータが上書きされたりする心配がなくなった。また、複数ワーカーでの並行処理を安全に行うため、Postgresを介して「リース」機構を実装している。これは、ある時間帯のデータ処理を担当するワーカーを一つに限定し、処理が完了するまでその担当権をロックすることで、複数のワーカーが同じデータを同時に処理して競合することを防ぐ仕組みだ。これにより、大量の過去データでも安全かつ効率的に処理できるようになった。

SWのバックエンドは、「ポート・ファースト・アーキテクチャ」という設計思想に基づいて構築されている。これは、サービスのインターフェース（ポート）をまず定義し、そのインターフェースを通じて各モジュールがやり取りすることで、モジュール間の依存関係を疎結合にするアプローチだ。これにより、各モジュールが独立して開発・テストしやすくなり、システムの変更や拡張が容易になる。Go言語の一般的なコーディング規約とは異なる独自のルールも導入されたが、これらは開発者の生産性とコードの予測可能性を高めるために意図的に行われた。内部ライブラリのエイリアシングを目的とした「Modkit」というパッケージも活用され、クリーンなインポートと保守性を追求している。

大量のデータを処理するバックエンドサービスにおいて、システムの健全性を把握することは運用上の鍵となる。SWでは、開発の初期段階から「オブザーバビリティ（可観測性）」を重視し、様々な監視機能を組み込んでいる。すべてのログは構造化され、各操作にかかった時間が詳細に記録される。Postgresの専用テーブルには、時間ごとのデータ取り込み統計やエラー発生状況が記録される。ClickHouseには、データの圧縮率や実際のストレージ使用量に関するクエリが用意され、Nightshiftサービスもデータ集約やポリシーチェックの際にメトリクスを記録する。これらの綿密な監視体制により、運用チームはシステムの状況をリアルタイムで把握し、問題が発生した際には迅速に原因を特定し、対応できるようになった。これにより、運用は「システムの監視」から「メトリクスの信頼」へとシフトし、より安定した運用が実現している。

GitHub Archiveから取り込まれるデータは膨大で、2025年までに数十億レコードに達すると予測されている。これらの生データをすべてオンラインで保持し続けると、ストレージコストと運用負荷が莫大になる。この課題に対処するため、「Nightshift」というサービスが導入された。Nightshiftは、一定期間が経過した生データ（個々のスラング検出イベント）を、時間ごとの集計データ（例: 時間ごとのスラングの総数、カテゴリ別内訳、頻出ワードなど）に変換し、元の生データは削除する役割を担う。この集約処理により、数百ギガバイトからテラバイト規模だったデータ量が、わずか数ギガバイトにまで劇的に削減される。これにより、ストレージコストを大幅に抑え、運用を簡素化できるだけでなく、プロジェクトがオープンソース化された際にも、一般的なノートパソコンで扱えるデータ規模になるという利点もある。

このSWサービスの開発を通じて、いくつかの重要な教訓が得られた。一つは、Postgresをコントロールプレーン、ClickHouseをファクトストアとするハイブリッドなデータストレージ戦略が、大規模データ処理において非常に有効だったことだ。また、テキストの正規化とバージョン管理されたルールセットの組み合わせにより、検出ルールの進化に柔軟に対応しつつ、過去のデータを再処理する手間を省けた。言語検出は困難な課題だったが、ClickHouseの機能活用で解決の道筋が見えた。ユーザーのプライバシー保護に関しては、GitHubのシンプルな機能を利用した同意フローが、倫理的かつ運用上も効率的であることが証明された。さらに、データの冪等性保証とリース機構によって、バックフィル（過去データの再処理）が安全かつ確実に実行できるようになった。サービスの設計ではポート・ファースト・アーキテクチャを採用することで、モジュール間の依存関係を整理し、コードの保守性とテストのしやすさを向上させた。そして、開発初期から監視機能を組み込むことで、システムの運用が「手がかからない」良い状態になった。最後に、データ保持ポリシーによる積極的なデータ削減が、ストレージコストと運用負荷を抑える上で不可欠であることが示された。