1
0
AWS slackを組み合わせた検索システムの構築方法
やりたいこと：slackbotを使った検索システムの作成
slackbotに対して、メールアドレス(または氏名等の別情報)をメンションで投稿すると、裏で持っている情報(今はcsvしか無い)から該当者の氏名、電話番号等のプロフィールを返すようにしたいと考えています。(1万名ほどのデータです。)
背景、状況
前提として、弊社内にはオンプレのサーバーが無いため、クラウドサービスでの対応になります。
AWS dynamoDBとlambdaを使用するのがよいかと考えていましたが、部分一致での検索が多くなることが予想され、完全一致でないといけないパーティションキーが必要なdynamoDBは不向きかと思い始めました。
下記、想定される使用ケース等の詳細です。
ーーー
・裏で持つデータは、氏名、ID、電話番号、所属等の20列*1万行ほどのデータ
→今はcsvで保持しているので、それをDBに移すこととなります。月一程度で内容の更新予定です。
・ID、氏名、電話番号、メールアドレス列を部分一致で検索したいと考えています。所属等は検索できなくても問題ありません。氏名は同姓同名の可能性もあるので、検索の方法は検討中です。
・メンションによるリクエスト数は月間10000程度を想定しています。
・メンテナンスは私が一人で担当することになる予定です。
・費用はAWSの無料枠内でできればと考えていますが、実際費用感がどの程度になるかの検討がついていません。費用が発生するようでも、月数千円～1万円程度であれば問題ないと考えています。
・社内のみでの使用のため、100%ストップせずに運用しなければならない、といったレベル可用性は無くてもよいと考えています(費用との兼ね合いです)。
ーーーー
こういった場合は、AWS RDSでMySQL等を使用するのがいいのでしょうか？
slackbot -> API Gateway -> lambda -> MySQL(AWS RDS) でデータを検索、結果を返すのが良いのでしょうか？
弊社内で使用できるリソースはAWSくらいなので、AWSのサービスで解決したいと考えています。
なお、当方のレベルとしては
・slackbot -> webhook -> lambda &cloud watchを使用して定期的に投稿するslackbot
・slackbot -> API gateway -> lambdaを使用してメンションに応じてカスタムレスポンスするslackbot
を作成したことがあるくらいです。なおlambdaではpythonでコードを書いています。
以上、ご知見ありましたら是非ご教示ください。
回答6件
#1
総合スコア177
投稿2023/09/05 03:39
部分一致での検索が多くなることが予想され、完全一致でないといけないパーティションキーが必要なdynamoDBは不向きかと思い始めました。
仰るとおりなのですがここは工夫次第でDynamoDBで実現可能です。テーブルに格納する要素を洗い出し、コスト面の比較とバックアップの方法を検討してからDynamoDBかRDSかを決定すべきかと思います。
そのため、テーブルに格納する要素と月間予算、メンテナンスする人を割くことができるかをご提示してもらうと様々な人からご回答いただけると思うので記載をお願いします。
#2
tamanegine様
コメントありがとうございます。内容を追記したので、ご確認いただけますでしょうか。
#3
総合スコア125
投稿2023/09/05 09:25
IDが連番だったりすると部分一致検索自体が不適切になりやすい気がしますがどうでしょうね？
電話番号も市外、市内、加入者番号で分割格納すれば基本的には完全一致ではないかなぁと思うのですが…。
Dynamoでの部分一致はフィルタ式になるかな？ 検索条件、ではなく、全件取得をフィルタリングして取得する、という概念なので、検索、というと少し違う気がしますが、結果としては似たようなものが得られるかと。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Scan.html#Scan.FilterExpression
Dynamoの提供しているフィルタ式でご希望の検索条件が満たされるのならばそれでもいいでしょうし、データ構造を再設計してDynamoDBのフィルタ式の範囲で処理できるように構造を組みなおす、というアプローチもあるでしょう。
それでも収まりきらないような複雑な検索条件が出てくるならRDSやElasticSearchを持ち出すことになりますね。
ただ、現実問題として、要件の検索速度条件が厳しいとも思えませんし、わざわざDynamoDBの苦手領域で戦わなくても、要件のトランザクション的にもRDS Proxyなくても行けそうなので、RDSでイージーに考えてしまっても問題がないように思います。
※私なら素直にRDSかElasticSearchに放り込みます。
メンテナもおひとり、社内用途でサービス品質もお察し、という感じの様子なので、どちらかというとご質問者の方が「使い慣れている」とか「よくご存じ」のデータベースを選択するのが、現実的ではないでしょうか。
#4
KeisukeKoga様
コメントありがとうございます。恥ずかしながら今年今の業務に就き始めまだ実務でDBを触ったことがないため、慣れているDBが無い状況です。社内に他にシステムに明るい人間もいないため、手探りでいろいろ調べているところです。
(SQLの知識は基本情報レベルです。)
＞電話番号も市外、市内、加入者番号で分割格納すれば基本的には完全一致ではないかなぁと思うのですが…。
この視点はありませんでした。ありがとうございます。
おっしゃる通り、サービスレベルは求められていないので、半分練習として作成するつもりです。
KeisukeKoga様の言う通り、Dynamoの苦手なところで頑張る必要はないと思うので、とりあえずRDSを使う方針で考えてみたいと思います。ありがとうございます。
#5
総合スコア673
投稿2023/09/08 07:49
データの専門家ではないのでスルーいただいても問題ないのですが
そもそも、NoSQLの用途として一貫性のないデータを扱いたいときに私は使用します。
例えば、IoTなどとにかくいろいろな種類の機器から受け取ったデータを一旦一つのDBに保持をしたい場合にNoSQLを使用します。
NoSQLはカラムの制限が緩く、大量データをさばけるので用途としてはあっているかなと思います。
これに対し、DRBMSは一貫性のあるデータを格納するのに向いています。(一般知識で申し訳ないですが)
これも一般的な話ですが、きれいに整った(入力データに変更がない)データに対して高度な検索をするのに向いているので、今回の要件はDRBMS向きなのかと思います。
顧客データが1秒に数百件降ってきてデータの内容も様々(あるデータは飲食関連のデータだがあるデータは建築関連のデータなど)な場合はNoSQLのほうがとなりますが、元データをExcelのように使用しているのであればDRBMSのほうが向いているかと思います。
一般的に顧客情報はDRBMSが多いと思いますし、正規化すればデータ量も抑えられます。
ただ、ネックなのが検索をする方法で、チャットから検索するとのことなので入力された文字がどのカラムに該当するかを判断する必要があります。
NoSQLにしようと判断した理由が(自分では)読み取れませんでしたが、もしかしてvalueに顧客データをすべて入れてそこから検索しようとしたりしてますか?
それならチャットでも活用はできそうですが、データの扱い方から見ると上記で書いたようになぜNoSQL何だろうという疑問が出てきます。
DRBMSでうまくやる場合、一番簡単なのはslackで検索項目を判別できる検索用のフォームを作成する(簡単に調べましたができそうな様子でした)のが良いかなと思います。
そのほかだと自分でコード書けるのであれば自然言語処理で検索対象カラムと検索内容を取得すればいいですし、難しければ検索ルールだけ決めて(検索する際のメッセージは必ず項目名:検索したい値にするなど)単純に受け付けたデータを自作でパース(:で分割して前のデータをカラム名、後のデータを検索内容としてクエリを作成する)すればそれらしいものはできそうです。
クラウドの構成は提示いただいているもの(slackbot -> API Gateway -> lambda -> MySQL(AWS RDS))が一般的だと思うので個人的に問題はないかなと思います。
#6
Yuu様
コメントありがとうございます。
AWS RDSのサービスを知る前にDynamoDBを知ったのでそれを使う方針で考えていましたが、記載いただいた通り確かに今回の用途だとRDSで対応した方がいいと感じました。NoSQLの使い方もよく分かっておらず、参考になりました。
検索は、自然言語処理でいい形にできればいいのですが、私にそこまでの技術力がないのでこちらで定めた入力規則に従って入力してもら方法を想定しておりました。
構成についてもコメントありがとうございます。RDSを使う方向でトライしてみようと思います。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。