【要約】Slackが社内知見・データの宝庫なので、SnowflakeにSlackのデータを安全に取得できるかを検証したい [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がSlackのデータを分析基盤へ集約しようとした際、既存の手段にはコストと機能の両面で課題があった。
- ・Snowflake公式のコネクタは、アイドル時も常時課金が発生し、日次連携にはコストが見合わない。
- ・公式コネクタは、設定した時点以降のデータしか取得できず、過去の会話ログを遡れない。
- ・Fivetran等のETLツールは、利便性は高いが別途高額なライセンスコストが発生する。
// Approach
開発者は、Snowflakeの機能を組み合わせることで、外部サーバーを一切介さないサーバーレスな仕組みを構築した。
- ・External Network Accessにより、SnowparkからSlack APIへの通信を許可した。
- ・Snowpark Pythonを用いて、
conversations.historyからデータを取得するプロシージャを実装した。 - ・
MERGE文を活用し、メッセージの重複登録を防止するロジックを組み込んだ。 - ・Snowflake Taskにより、毎朝9時の日次バッチ実行を自動化した。
// Result
検証の結果、外部インフラを管理することなく、低コストでSlackデータの自動蓄積を実現した。
- ・実行時のみの課金となるため、運用コストを極めて低く抑えられる。
- ・
oldestパラメーターの活用により、過去ログの遡及取得が可能となった。 - ・社内知見をSnowflakeに集約し、Cortex Search等を用いた高度な検索基盤への道筋を立てた。
Senior Engineer Insight
> 非常に合理的かつ実戦的な構成だ。マネージドサービスの「利便性」と、自作による「コスト・柔軟性」のトレードオフを、Snowflakeの機能を使い倒して解決している。特にExternal Network Accessによる脱・外部サーバー化は、セキュリティと運用コストの両面で評価できる。ただし、大規模なチャンネルや大量のメッセージを扱う場合、APIのレートリミットやSnowflakeの計算リソース消費に注意が必要だ。