はてなブックマーク

はじめに こんにちは!ナウキャストのデータエンジニアのけびんです。 ナウキャストでは一部のバッチジョブの実行やデータの保存にAWSを利用しています。その中でも、古くから運用しているAWSアカウントでは、特に2024年までのコスト増加が課題となっていました。 様々な施策を通じて、2025年にはアカウント全体での月額コストを 約30% 削減することができ、その中でもS3単体での削減が最も大きな成果を上げました。本ブログでは、S3に焦点を当て、実際にどのようにコスト削減を行ったのか、その設定やアーキテクチャをご紹介します。 Cost Explorer で確認した対象のAWSアカウント全体のサービスごとのコスト。 特にS3が2024年まで増加し、その後削減されている様子が確認できる。 ナウキャストのビジネスモデルとS3の役割 本記事の技術的な詳細を理解するうえで、背景としてナウキャストがどのような

検出精度 ✅ 全体精度: 97.5% - 80件中78件で正確な判定を実現 ✅ DB検出: 100% - データベース照合による検出は完璧 ⚠️ LLM検出: 95% - Web検索+LLM判定で1件誤判定 ⚠️ 中リスク判定: 95% - 疑わしい情報の分類で1件誤判定 技術スタック 今回は特にスピード重視で作りつつ、一定の保守性も担保できるような仕組みにするために、できるだけ慣れている言語・環境でかつ、AIエージェント開発と相性が良く、実現したい機能のライブラリが十分に揃っているという3つの条件をもとに技術選定を行いました。 バックエンド 言語: Typescript 実行環境: Bun Webフレームワーク: Hono バリデーション: Zod DB: PostgreSQL(w/Drizzle ORM) LLM API: Azure OpenAI GPT-4.1: データのパース、検

はじめに こんにちは。ナウキャストでデータエンジニアをしているTakumiです。 社内(Finatext HD内)の生成AIコンテストでMultiAgentを利用したシステムをスクラッチで構築しました。 具体的には、ユーザーがSlackでメッセージを送信し、コードの記述、レビュー、GitHubでのPR作成までEnd2Endでできるシステムです。 コンテストで構築したシステムの概要図は以下の通りです。 本記事では、複数のエージェントが協調して動作する本格的なコーディングAgent(Coodinator) に絞って、構築した概要を説明します。 この記事でわかること この記事では、LangChainとAzure OpenAIを使用してゼロからコーディングエージェントを構築する方法を詳しく解説します。 具体的には以下の内容を学ぶことができます。 コーディングエージェントの実装方法:Programm

この記事はGo Advent Calendar 2024の 14 日目の記事です🎄 はじめに 先日、専用コンテナを利用したユニットテストのアプローチとして、Testcontainers for Goを利用した具体例を紹介させていただきました! まだ読んでない人は、ぜひチェックといいねをよろしくお願いします 👍 本記事では、Testcontainers と合わせて、runn を用いた API テスト基盤について詳しく解説します。 前提 runn とは runn は、k1LoWさん作のシナリオテスト[1]を柔軟に構築できるツールです。 個人的な runn の推しポイントとしては以下2点です。 ポイント 1. チュートリアル、クックブックが日本語対応している 初めて使うのにまったく困らないほどのドキュメントが、それぞれ日本語かつ zenn で公開されているのは、国内で普及させるのにだいぶア

この記事はFinatextグループ Advent Calendar 2024の12/9の記事です。 モノリポでGitHub Actionsを使ってCI/CDを構築する際に直面する問題について、インターネットであまり見つからなかったtips 3選を紹介します。 Matrix strategyを使ったパイプライン並列化 Required status checks Dependabotの完全自動マージ Matrix Strategyを使ったパイプライン並列化 Matrix Strategyを動的生成を利用する Finatextのプラットフォームチームでは社内プラットフォームを担うアプリケーション群を領域や性質に合わせて複数のAWSアカウントに区切り運用しています。それぞれのAWSアカウントの中でモニタリングや自動化などの各種タスクのために複数のAWS Lambdaのfunctionを実行してい

この記事は、dbt Advent Calendar 2024の8日目の記事です。 はじめに こんにちは!ナウキャストのデータエンジニアのけびんです。 dbt incremental model とは dbt を利用すると ELT パイプラインを宣言的に作成・管理することができます。 hoge.sql というファイルに select 文を書いておくと、その内容で hoge というテーブルを作るように CTAS でラップして実行してくれる、という訳です。これはつまりテーブル全体を毎回洗い替えする構成になってしまいますが、データ量が大きいテーブルに対して毎回洗い替えするわけにはいきません。 そこで dbt における materialization の一種である incremental model を利用すると、洗い替えではなくいわゆる差分更新を可能にします。 incremental model

この記事はFinatextグループ Advent Calendar 2024 7日目の記事です。 はじめに こんにちは。インフラエンジニアのぐらにゅです。 突然ですが、みなさんはTerraformを使っている中で、設定ミスをコード側で検知したいと思ったことはないでしょうか? クラウドインフラを利用するケースが多いと思いますが、設定ミスがあると脆弱性を生んだりガバナンス違反をしていたなど、何らかのセキュリティ上のリスクが発生する可能性があります。 手動での変更も含めて網羅的にケアしたい場合にはクラウドインフラ側でガードレールを設けた方が良いですが、コード側でも検知できると嬉しいなあと思ったので、設定ミスを検知できるツールをいくつか調査してみました。 この記事で書くこと/書かないこと 書くこと 設定ミスを検知するツールとしてどういうものがあるか ツール選定する際に考えたいこと 書かないこと T

この記事は、Finatextグループ Advent Calendar 2024の3日目の記事です。 はじめに ナウキャストでデータエンジニア/データプラットフォームエンジニアとして働いている@mt_musyuです。ナウキャスト社内のデータ基盤の構築や運用を行い、また社内の知見を生かしてクライアント企業様のデータ基盤の構築や運用の支援を行っています。 近年、データ利活用の推進や生成AIの利用が進む中で、データ基盤の重要性が増しています。単にデータ基盤を構築するだけでなく、増え続けるデータやユーザーを考慮した運用も求められています。そのため、データ基盤の構築や運用を効率化するために、IaC(Infrastructure as Code)の導入が重要であると考えています。もちろん、通常のシステム開発においてもIaCは重要ですが、データ基盤においては特にその重要性が際立っていると考えています。そう

主観満載でとても大雑把な分類ですが、当記事ではこの前提で進めていきます。 アーキテクチャ説明 私たちが作ったのはモジュラーモノリス(共有DB)です。1つの共有DBを扱い、APIサーバーとして外部公開用のインターフェースを持ってます。ディレクトリ構成に踏み込むと「レイヤードアーキテクチャ + モジュラーモノリス(共有DB)」と表現した方がわかりやすいかもしれません。 まずはモジュールの構成を把握していただくために、レイヤーごとの責務を説明します。アーキテクチャは次の図のようになっています。 実装上はインターフェースを定義して抽象と具象をレイヤーごとに区別して管理し、依存性逆転してます。ですが、それらは理解されてる方が多いと思うので、簡易的に処理の流れを矢印で表現しました。 それぞれ簡単に紹介します。 アプリケーション層 ビジネスロジックを担うレイヤーです。 DDDやクリーンアーキテクチャでは

Go のコミュニティーで昔から話題になっているテーマだと思いますので、自分なりの考えを共有したいと思います。プロジェクトの内容によって構成などはかなり違ってくると思いますが、ここでは DDD を使ったWebサーバーについて紹介します。よくあるユースケースではないかと思います。 フィードバックやコメントなど大歓迎です!意見交換もしていきたいです! ファイルとネームスペース Go ではプロジェクト構成がそのままネームスペースになります。不便だと思う方もいるかも知れませんが、僕は非常に使いやすいと思っています。他の言語ではしばしば、プロジェクトの構成をすでに大まかに決めているか、もしくはコードを書く前に決めるようにすることが基本だったりします。しかし、Go ではコードを書きながらプロジェクトの構成、パッケージの追加・削除を行うことが一般的です。 よくインターネットで Go の初心者が、「プロジェ

InnoDB のロックアーキテクチャを解説し、デッドロックの原因を説明できるようにします。開発時に実際に起きたデッドロックを題材にし、インデックス、ロックアーキテクチャ、実際のロック例、デッドロックの解明という順で説明します。記事中の SQL は実際に試すことができるので手を動かしてみてください。 できる限り他の記事やドキュメントを見なくても良いように書いています。そのため「参考リンク」は折りたたみにしています。より詳しい情報を知りたい場合は参照してください。 ※(注記)この記事は株式会社 Finatext のテックブログの一つとして書いています。 株式会社 Finatext のテックブログに関しては以下をご覧ください 実行環境 MySQL 8.4.0 InnoDB トランザクション分離レベル: REPEATABLE READ 実際に起きたデッドロック まずは実際に起きたデッドロックを再現します。

開発していると、公開鍵暗号の技術を利用する場面は多々ある。 EC2インスタンスへのSSHする時や、Snowflakeの認証時に RSA キーペアの秘密鍵を利用する 公開鍵証明書 ... いろんな用語、トピックがあり混乱するのでまとめてみた。 ここではとりあえず特にRSA暗号を念頭に置き話を進める。 規格群 そもそも公開鍵暗号に関する技術はいろいろな形で規格が定められていたり、標準化されていたりする。 PKCS Public-Key Cryptography Standards の略で、RSAセキュリティというソフトウェア会社が考案した公開鍵暗号の規格群のこと。元々はRSAセキュリティ社が自社の暗号技術に関する特許を利用促進するために発行したのがはじまり。 近年ではその一部は IETF などと標準化が進められており、 RFC として整備されているものも多い。 内容ごとに PKCS #1 など