プロジェクトの概要と振り返り

本プロジェクトは、大規模なコンテンツ配信プラットフォームをモデルとして設計されました。ユーザーの関心に基づいた精度の高い技術記事を推薦し、クリエイターがコンテンツを運用できる環境を提供することが主な目的です。このようなシステムは、ビッグデータ解析とマイクロサービスアーキテクチャが融合した現代的なWeb開発の代表例であり、DevOpsの観点からも重要な学習対象となります。

核心業務の構成

プロジェクトの中核は記事配信ですが、実際の大規模システムではこれ以外にも多様なモジュールが存在します。データの流転は主に「ユーザー認証」「記事投稿・閲覧」「行動ログ収集」の3つに分類されます。推薦エンジンの構築といった高度なデータ処理は、Javaバックエンドの機能開発と並行して、Pythonなどの専門環境で担当する役割分担が一般的です。

技術的解決策の応用

ショート動画機能においては、メディアのアップロードおよびストリーミング配信を実現するために、FastDFSやAlibaba Cloud Video on Demand（VOD）といった技術が活用されます。また、MySQL単体では対応困難な巨大なデータセットを扱うために、HBaseと連携したデータライフサイクル管理を採用しています。具体的には、MySQLのデータをHBaseへ定期的にアーカイブし、古いデータをMySQLから削除することでパフォーマンスを維持します。検索時には、まずMySQLを確認し、見つからない場合にのみHBaseを参照する階層構造をとります。

データベースのスケーリング：シャーディングと垂直分割

業務が拡大しデータ量が数千万件を超えると、単一のデータベースでは負荷限界に達します。この際、ハードウェアの増強にはコストと限界があるため、データベースの「分庫分表（データベースの分割とテーブルの分割）」が不可欠です。

分割の手法

• 垂直分割 (Vertical Partitioning): 頻繁にアクセスされる列と、説明文などの大きなテキストデータを物理的に分離します。これによりI/O競合を低減します。
• 垂直データベース分割 (Vertical Database Sharding): 商品管理や店舗管理のように、業務単位でデータベース自体を分離し、サーバーの負荷を分散させます。
• 水平データベース分割 (Horizontal Database Sharding): ユーザーIDや商品IDのハッシュ値、あるいは奇数・偶数判定を用いて、データを複数のデータベースへ物理的に分散させます。
• 水平テーブル分割 (Horizontal Table Partitioning): 単一データベース内でテーブルを論理的に分割し、単一テーブルの肥大化を防ぎます。

実装における課題と解決策

データの分割はパフォーマンスを劇的に向上させますが、同時に以下の複雑な課題を伴います。

• トランザクションの一貫性: 複数サーバー間に跨るため、分散トランザクション制御が必要となります。
• クロスノードJOIN: 異なるサーバー間での結合クエリが不可欠となるため、アプリケーション層でのデータ集約ロジックが求められます。
• ページネーションと集計: ソートや集計（SUM, COUNTなど）を行う際、全ノードから結果を収集し、再計算を行う必要があります。
• 主キーのユニーク性: データベース単位の連番IDは使用できないため、UUIDやSnowflakeアルゴリズムを用いたグローバル一意識別子の生成が必須です。

これらに対処するため、Sharding-Sphere (旧Sharding-JDBC) や MyCat といった分散データ管理ミドルウェアの利用が標準的な選択肢となります。