みなさん、おはようございます！マイクです。今日は2024年11月28日、木曜日ですね。さて、今日の「zenncast」では、Zennで話題になっているトレンドの記事をいくつかご紹介しますよ！

前回ご紹介した記事は、「はじめからそうやって教えてくれればいいのに！」というタイトルでした。WebページをRAGしたい時の精度向上手法「HtmlRAG」や、ReactのページでGoogle翻訳するとエラーになる事象についてお話ししました。それでは、早速今日の内容に移りましょう！

今日ご紹介する記事は全部で5本あります。それぞれの内容を詳しくお伝えしていきますので、ぜひお楽しみに！

まずは1つ目の記事です。タイトルは「本番DBのマスターデータを全行ぶっとばすやらかしをしたときのお話、その反省」です。

この話は、著者がプロジェクトの本番DBでマスターデータを間違ってブランクで上書きしてしまったというミスから始まります。これが原因で、サービスがコアタイム中に完全に機能停止し、緊急メンテナンスが発生しました。著者は、過去に使ったスクリプトをそのまま使い、DEV環境でのテストを省略してしまったことが原因だと反省しています。

復旧策としては、RDSのスナップショットを利用して新しいインスタンスを立ち上げ、失われたデータを再インサートする方法を取りましたが、これには1時間近くかかりました。著者は、今後はバックアップを必ず取得すること、トランザクションを使って変更を確定させること、作業スクリプトから直接クエリを発行しないこと、DEV環境での動作確認を徹底することを教訓として挙げています。

特に、データベースのバックアップ方法にはSequel ACEを用いたエクスポートやCSV形式でのバックアップが推奨されています。著者は、この経験を通じて油断や慣れがミスを引き起こす要因になることを痛感し、今後はより安全で効率的な作業を目指す決意を新たにしています。

続いて、2つ目の記事、タイトルは「Raspberry Pi Pico Wのライセンスがヤバそう。（誤報）」です。

最近、Raspberry Pi Pico Wに関するライセンスに関する誤報が広がったのですが、実際にはRaspberry Pi財団の見解によると、PICOとCYW43439の組み合わせを利用した製品開発には特例として無料の商用利用ライセンスが適用されることが確認されました。これによって、商用利用は問題ないとのことです。

ただし、PICO WにはCYW43440というWiFi/BTモジュールが搭載されていて、そのドライバであるcyw43-driverには商用利用が制限されています。このドライバのライセンスは、再配布や使用が個人的な利益のみに限られていて、商業目的には適用できません。

誤報が広がったため、元の記事は削除されましたが、正確な情報としては、PICOとCYW43439の組み合わせで製品開発を行う場合、Raspberry Pi財団から商用ライセンスが与えられるため、安心して利用できるということが強調されています。ライセンスの解釈が難しいため、今後も注意が必要ですが、PICOに関しては基本的に商用利用可能であるとされています。

さて、次は3つ目の記事、タイトルは「LangGraphによる『AIエージェントWebアプリ』を作成する【Next.js】」です。

この記事では、LangGraphを使ってAIエージェントを活用したWebアプリを作成する手順が解説されています。このアプリは、ユーザーが「今日、明日、明後日」に関する天気や日付の質問に応答するチャット型アプリです。ユーザーの質問に応じて異なるワークフローを起動し、適切な回答を生成します。

例えば、ユーザーが「今日の天気を教えて？」と質問した場合、まず時間の情報を尋ね、その情報に基づいて回答を行います。このように、ユーザーの入力に応じて動的に反応する設計が特徴です。

LangGraphを利用することで、不適切な質問を防ぐ判定機能や、ユーザーごとの会話履歴を区別する機能、会話履歴を永続的に保存する機能も考慮されています。実装にはFastAPIを用い、SQLiteで会話履歴を管理します。APIには「/ask」と「/continue」があり、前者は新しい質問を処理し、後者は中断した会話を再開します。

実装コードはGitHubリポジトリにて公開されていて、フロントエンドはNext.jsとpnpmを使用しています。環境構築や動作方法も詳細に説明されているので、エンジニアなら再現も容易です。最終的には、VercelやLambdaでのデプロイを予定しています。

。...。...

次は4つ目の記事、タイトルは「【ログ分離】 ログデータを DB に保存してはいけません」です。

こちらの記事では、TROCCOがETLジョブやdbt連携の実行ログをリアルタイムで確認できる仕組みについてお話ししていますが、これらのログがデータベースの一部に保存されていたため、データ量の増加がパフォーマンスに悪影響を与えていたそうです。特に、1日に16万レコードが生成される状況では、DDLやSELECTの処理が遅くなる問題が顕著でした。

そのため、SREチームはログをDBから分離するプロジェクトを開始しました。ログデータはサイズが大きく、DBに保存することはアーキテクチャ上のアンチパターンであるため、S3を保存先として選択。これによりコスト削減と運用の簡素化が図れました。

ログの転送にはK8sのJobを使用し、サイドカーとしてVectorを導入しました。Vectorはメモリ使用量が少なく、ログの転送処理を効率的に行うことができるのです。メインコンテナの終了時にVectorも停止するためのCronJobも設定し、不要なコンテナの管理も行いました。この結果、K8sとVector、S3の組み合わせでDBからログデータを効果的に分離することに成功したということです。

このアプローチは、DBに大きなデータを保存することのリスクを軽減し、エンジニアの負担を減らすための良い参考になるでしょう。

。...。...

最後に5つ目の記事、タイトルは「AWSで実現するデータメッシュアーキテクチャ」です。

データの価値が高まる中、効率的かつスケーラブルなデータ基盤の構築が求められています。従来のデータレイクやデータウェアハウスでは対応が難しい中で、「データメッシュ」が注目されています。この記事では、データメッシュの概念とAWS上での実現方法について解説しています。

データメッシュはドメイン駆動設計を基盤として、ビジネスドメインごとにデータを管理・所有するアプローチです。これには、ドメイン別オーナーシップやプロダクトとしてのデータ、セルフサービス型データ基盤、横断的なガバナンスの4つの原則があります。

AWSでのデータメッシュ実現にはGlue Data CatalogやLake Formationの活用がポイントです。データプロデューサとしてS3にETL処理を行い、Glue Crawlerでデータセットを検出、Lake Formationでガバナンスを設定します。また、Amazon DataZoneを使うことで、データカタログの管理やアクセス権のリクエストも可能です。

データメッシュのメリットにはスケーラビリティやデータ品質の向上がある一方で、分散管理による複雑化、ドメインごとのデータ管理負担、セルフサービスプラットフォームのコストが課題です。また、組織がドメイン駆動に対応している必要もあります。

データメッシュは分権化を目指す一方で、データファブリックはテクノロジー重視のアプローチです。AWSを利用することで効率的でセキュアなデータ管理が実現可能ですが、データ収集の仕組み構築やデータ品質の統制、組織の構成も考慮する必要があります。

以上、今日ご紹介した5本の記事を駆け足でおさらいしました。次回もまたお会いできるのを楽しみにしています！詳しい内容はショーノートに書いてありますので、そちらもチェックしてくださいね。また、番組の感想もぜひお寄せください！それでは、今日も素敵な一日をお過ごしください！