論文・特許データのデータマイニングシステムの開発案件
プロジェクト内容
特定の論文や特許データの内容を分析するためのデータマイニングシステムの開発。
やりたいこと主な部分はデータ分析なので、その機能さえあれば要件は満たすが、一般のユーザーにも使いやすいようWebシステムとして作ることになった。
Webシステムとして動かすため、バックエンド領域ではREST APIを20本程度作ることになった。この領域を3人で対応し、自分はその中のメンバーの1人。
技術スタック
※自分が関わった範囲に限定して記載
- プログラミング言語: Java
- フレームワーク: Spring Boot
- データベース: Firestore、BigQuery
- コンテナ管理・オーケストレーション: Kubernetes（GKE）
- クラウド: Google Cloud
- バージョン管理: Git
主な業務内容
- データ分析の際に使用する定義ファイルのフォーマット設計
- Firestoreのスキーマ設計
- バックエンド領域のシステム設計レビュー
- APIの実装とコードレビュー
- 手動でのシステムテスト実施
データ分析の際に使用する定義ファイルのフォーマット設計
本システムで扱う論文・特許データはxmlで構成されており、分析にあたり各種タグをどう扱うかの定義が必要だった。
タグの定義自体は別チームが用意したので、それをシステムに反映するためのフォーマットを設計した。
諸々の制約からtsvをベースにしたが、tsvでは扱いにくい部分もあり、そこは反省点。
Firestoreのスキーマ設計
バックエンドで使うデータベースがFirestoreに変更されたため、スキーマ設計を行った。
Firestoreのスキーマ設計では、ホットスポットの回避が重要。分散処理が可能なIDを設定する必要がある。しかし、システム要件として「IDはAuto Incrementにする」という条件があり、分散IDとAuto Incrementという相反する要素を組み合わせる必要があった。
解決策として、「IDのAuto Incrementを管理する専用のDocumentを作成し、アプリケーションで使用するDocumentには分散用IDとAuto Increment用IDの2つを持たせる方法」を採用して、要件を満たした。
詳細は、Firestoreで連番IDを実装する方法を参照。
バックエンド領域のシステム設計レビュー
チームで設計領域を分担し、設計は各自で行い、それをメンバー全員でレビューして成果物を仕上げるという方法を取った。
バックエンド領域では、DataflowやFirestoreなどクラウドリソースの実行状態の整合性を保ちながら処理を行う点（分散トランザクションの類）が難しく、異常系のパターン列挙とその解消パターンの設計が特に困難だった。
設計フェーズは1ヶ月半あったが、この部分だけで2週間以上を費やした。
「異常が発生した場合、処理の状態を戻さずに終了し、後でバッチ処理で異常を救う」という方針に至り、複雑さを抑えて設計を完了させた。
APIの実装とコードレビュー
Clean ArchitectureをベースにREST APIを実装。ここでも各自でAPIを実装し、メンバー全員でレビューする体制で進めた。
当初の予定に対して、設計と実装フェーズで時間を多く使ってしまったが（元々の見積もりよりアプリの実装量が多かった）、品質を優先してしっかりレビューを行った。
結果として、後のテスト工程でバックエンド領域の不具合は1件（軽微なもの）しか発生せず、高品質なAPIを作ることに成功。バックエンド領域でテスト工程の追加はほぼなかった。
手動でのシステムテスト実施
ユニットテストではカバーできない部分を手動でテスト。テストシナリオに沿ってシステムを操作し、エビデンスとしてスクリーンショットを撮る方法を採用した。
重要な工程ではあるが、全くモチベーションが上がらず、自分はこの手の作業が好きではないと再確認した。