概要
この記事では、求人サイトのバックエンド開発におけるDynamoDBの設計と実装に関する受託開発の実績を紹介します。特に、DynamoDBが本案件のDBとして適切か評価し、最終的にPostgreSQLを採用した理由について説明します。
背景と依頼内容
■対象：求人サイトの新規リリース案件
■新規・既存：新規案件
■お客様：フロントエンド・エンジニアの個人事業主 様
■状況：フロントエンドの実装はほぼ完了。バックエンドの開発は外部に委託していたが未完成であり、お客様が指定したDynamoDBを利用せずPostgreSQLで実装されていた。
■依頼内容：DynamoDBでバックエンドのコードを修正＆ローカル環境・きちんとデプロイできるようにする
依頼内容を丁寧にヒアリングすると、DynamoDBをDBとして選定するのが適切かソースコードを見るまで判断できなかったため、以下を提案いたしました。
- DynamoDBの設計案の作成
- DynamoDBが適切か、現行のPostgreSQLが適切かを説明し決定する
- →後述する理由により、PostgreSQLが適切であることを説明しご納得頂いた
- バックエンドのコードをDynamoDBに書き直すか、現行のPostgreSQLで動くようにするかを提案
- →現行のPostgreSQLを選択。コードの修正＆ローカル環境でGitHub ActionsによるCDを実装した。
ユースケースのヒアリングとDynamoDBの設計
- ユースケースのヒアリング:
求人サイトの具体的なユースケースをヒアリングし、以下のような要件が明らかになりました。
- 求人の一覧表示（フィルタなし）
- １求人の表示
- 求人の検索
- 項目1（複数選択）ｘ項目2（複数選択）によるフィルタリングが必須
- 任意のページへのページネーションあり
- DynamoDBの設計:
ユースケースに基づいて、DynamoDBのテーブル設計とインデックス設計を実施しました。
DynamoDBの適切性評価
DynamoDBは、NoSQLデータベースとして高速な読み書きを実現するために設計されていますが、以下の点で求人サイトのユースケースに適していないことが明らかになりました。
- 複数項目ｘ複数項目によるフィルタリング:
DynamoDBは、複数項目ｘ複数項目によるフィルタリングが効率的に行えるように設計されていないため、クエリのパフォーマンスが低下する可能性があります。
- 任意のページネーション:
DynamoDBでは、任意のページネーションを実現するのが難しいことが多く、特に大規模なデータセットに対しては不適切です。
結論と採用したアプローチ
上記の評価結果をもとに、以下の結論に至りました。
- 現行のPostgreSQLを継続使用:
求人サイトのユースケースに基づいて、DynamoDBではなく現行のPostgreSQLを継続使用することを提案し、ご納得いただきました。PostgreSQLは、データの整合性を確保し、複雑なクエリやフィルタリング、ページネーションを効率的に実行できるため、求人サイトの要件に最適です。
バックエンドコードの修正とデプロイ
- コードの修正:
現行のバックエンドコードを修正し、PostgreSQLで動作するようにしました。また、DBの初期データを投入するコードの不備も修正しました。.envファイル等動作に必須となるファイルも委託先から頂いていないとお伺いしたため、既存のコードから作成しました。
- AWS環境とGitHub Actionsの設定:
AWS環境にGitHub Actionsを使用して、コード変更時に自動でデプロイされるように設定しました。既存のServerless Frameworkを踏襲して、環境ごとにデプロイできるようにしました。
成果
- 効率的なデプロイ:
GitHub Actionsを使用することで、コード変更時に自動でデプロイされる仕組みを整え、開発効率を向上させました。
- 安定した運用:
現行のPostgreSQLを継続使用することで、データの整合性とクエリのパフォーマンスを確保し、求人サイトの安定した運用を実現しました。
この受託開発を通じて、DynamoDBとRDBの違いを理解し、プロジェクトの要件に最適なデータベースを選択する重要性を実証しました。
あなたのプロジェクトでも類似の課題に直面している場合は、ぜひお問い合わせください。