はてなブックマーク

協働的AIチームメイトを謳うソフトウェア開発エージェント、Devin が注目を集めています。日本コミュニティでの勉強会は参加者が1000人を超えるほどです(！) 今回はDevin的な動きを実現するセルフホスト型のソリューションを開発してみたので、その紹介です。 TL;DR; こちら↓にソースコード (IaC + Agent + Bolt app) を公開しています。 github.com 主な機能は以下です: クラウド上で並列して動作できるソフトウェア開発エージェント サーバーレス構成のため、料金の前払いは不要で固定費もほぼゼロ MCPサーバーとの統合が可能 プロンプトキャッシュやコンテキスト長制御によるコスト効率化 OSSのレポジトリもフォークして開発可能 .clinerules や CLAUDE.md などからリポジトリ固有の知識を自動読み込み AWSアカウントとGitHubアカウント

LLMアプリ開発プラットフォームのDifyでは、ワークフローのコードブロックでPythonコードを実行できます。 この記事では、このコード内でboto3やnumpyなど任意のライブラリを呼び出す方法をまとめます。セルフホストのDify向けです。 Difyコードブロックの例 Difyのコード実行の仕組み 前提知識として、Difyのコード実行の仕組みを簡単におさらいします。 Difyでは、PythonやNode.jsのコードをDify Sandboxという独自のサンドボックス内で実行します。 Dify、特にSaaS版では、ユーザーがDifyのサーバー上で悪意のあるコードを実行する可能性があるため、こうしたセキュリティ対策が必要となります。対策がない場合、例えばDifyのサーバーから重要な情報を窃取したり、Difyサーバーのネットワーク・AWS IAM権限 (あれば) を悪用したりといったリスク

先日Amazon S3でconditional write機能がリリースされました。本記事では、この機能を用いた分散ロックについて検討します。 aws.amazon.com 分散ロックとは 分散ロック (distributed lock) とは、分散環境で排他制御を実現するために必要な機構です。実現できることはロックですが、分散環境から利用できることが特徴です *1。 実装はRedisを利用したものが有名ですが、AWSネイティブな実装としてはDynamoDBを利用することも多いでしょう。(実装例: DynamoDBLockClient, Powertools for Lambda) 分散ロックは強い整合性を持つ条件付き書き込みが可能なストレージがあれば、実現することが出来ます。 // 分散ロックの擬似コード 結果 = 条件を満たしたら書き込み(共通のキー) if (結果 == 成功) {

AWS Lambdaのコールドスタートはアプリ開発でしばしば悩まされる問題です。この記事では、特にPythonのLambda関数 (コンテナも含む) において、コールドスタートが遅い際の対処方法をいくつか紹介します (注意: 網羅は目指してません)。 第一歩: 計測する Pythonプログラムのコールドスタートが遅い場合、モジュール群のインポートに時間が掛かっていることが多いと思います。 モジュールのインポートに要する時間は次の方法で計測・可視化できます。 まず、-X importtime オプション付きでPythonプログラムを実行します。Lambda環境そのもので実行する*1のはログの取得が面倒なので、最初はローカル環境で実行して良いでしょう。厳密には異なると思われますが、十分良い近似を出してくれるはずです。 このオプションにより、標準エラー出力に以下のような形式のテキストが出力されま

最近にわかに話題沸騰中のJavaScriptランタイム LLRT を紹介する記事です。 github.com LLRTとは LLRT (Low Latency Runtime) は、軽量なJavaScriptランタイムです。サーバーサイド向けのJavaScriptランタイムはNode.js、Deno、Bunなどが有名ですが、それらにまた一つ加わった形になります。主にLambdaでの利用が念頭に置かれているようです。その他必要な情報は README.md にまとまっています。以下は抜粋です。 AWSのソリューションアーキテクト Richard Davison さんにより開発されています。リポジトリがAWSのGitHub organization (awslabs) で公開されているため、実験的ではありますが、AWS公式のプロジェクトと言って良いでしょう。 ここ5日間ほどでとんでもない勢いでG

あけましておめでとうございます。冬休みの自由工作レポートを提出します。 はじめに 最近Amazon RDS AuroraでData APIが使えるようになりました。Auroraインスタンスに対してHTTP APIでSQLクエリを発行できる便利なものです。 この記事では、Data APIをより使いやすくするための方法を検討します (ネタバレ: 目標未完です) 。 Data APIのおさらい Data APIに関する知識を箇条書きでまとめます。 メリット 踏み台なしにインターネットからクエリ可能 (IAM認証) 不要ならData API自体を無効化できる (デフォルトで無効) IAM認証なので、DB認証情報の管理が不要になるのも嬉しい Data API側でコネクションプールされる Lambdaでもコネクション枯渇の可能性が抑制できる RDS Proxyが不要になり、コスト減の可能性 Cloud

ワタミチートシート以来、久々のカンペ記事。 AWS SDK JavaScript v3がリリースされて久しいが、移行は進んでいるだろうか？ LambdaのNode.js v18ランタイムではv3 SDKのみビルトインされているなど、そろそろ移行を進めないとまずい状況も増えてきている。 私自身は未だにv3のSDKでS3のファイルをダウンロード/アップロードする操作に慣れないので、この記事にそれらのサンプルコードをまとめる。 事前準備 以降のコードに必要なライブラリは、基本的に以下の一つだけでOK。 npm install @aws-sdk/client-s3 コード S3頻出のパターンとして、以下5つがあるだろう: メモリ上のデータをS3にアップロード ファイルシステム上のデータをS3にアップロード メモリ上にS3のデータをダウンロード ファイルシステム上にS3のデータをダウンロード S3上

AWS CDK Tipsシリーズの記事です。 CDKアプリケーションの開発運用が成熟するにつれ、CDKの合成処理 (synthesize)が遅く感じることがあります。 合成処理はCDKのデプロイやdiffのたびに走るため、速ければ速いほど嬉しいものです。 この記事では、合成処理を高速化するための方法をいくつか紹介します*1。 1. ts-nodeの型チェックを無効化する CDKをTypeScriptで記述している場合、実行時の型チェックを無効化することで処理が高速化する場合があります。 このためには、cdk.json を開き、次の設定変更をします ( --transpileOnly オプションを追加): - "app": "npx ts-node --prefer-ts-exts bin/cdk.ts", + "app": "npx ts-node --transpileOnly --pr

AWS CDKを日々使う中で溜まった知見を書き出しています。記事を追加するごとにここも更新していきます。 以下はベストプラクティス的な話です: CDK Tips: コンストラクトで構造化しよう すべてのリソースをスタックのコンストラクターにベタ書きしないほうが良いこともある話 CDK Tips: スタックの分け方について スタックは不必要に分ける必要ないですという話 Construct IDはパスカルケースで命名するのが良い コンストラクトを定義するときの命名規則の話 上記のプラクティスをまとめたスライドもあります: AWS CDKのあるあるお悩みに答えたい 以下はより発展した使い方の考察です: CDK Tips: cdk synthを高速化する CDKの合成処理が遅いときに速くするための話 AWS CDK Tips: ID=Defaultの使い方 コンストラクトで構造化する記事で紹介した

昨今Infrastructure from Code (IfC)という概念をよく耳にします。先日もAWSのGregor Hohpeが関連する記事を書いていました。 architectelevator.com この記事では、Infrastructure from Codeとはなにか簡単に紹介し、具体的にどのようなツールがあるか網羅的にまとめます。 Infrastructure from Codeとはなにか Infrastructure from Code (IfC) とは、その名の通り、Infrastructure as Code (IaC) に関連する概念です。IaCとの根本的な違いは、IaCは開発者がインフラを明示的に意識して構成を記述するのに対し、IfCでは開発者がインフラをできるだけ意識しないよう抽象化を試みていることです。これにより、差別化に繋がらない重労働ができる限り排除された高

昨今LLMの台頭により、テキストをベクトル化して類似文書の検索に利用する手法が流行っています。 今回はAWSでこの検索を実現するための一方法として、SQLiteのプラグインであるsqlite-vssをAWS Lambda上で使う方法をまとめます。 github.com 意外とハマりどころや特有の考慮事項が多いので、必見です！ アーキテクチャ LambdaでSQLite？と思った方のため、このアーキテクチャの要点をまとめます。 このアーキテクチャのメリットは、完全なサーバーレスでベクトル検索を実行できる点です。OpenSearchやPostgres (pgvector)、Redisなどのインスタンスを管理する必要はありません。サーバーレスの利点はもはや言うまでもないでしょう。 また、SQLiteを使うため、ベクトルだけでなく他のリレーショナルなデータをあわせて格納できる点も便利でしょう。例え

AWS CDK TIpsシリーズの記事。 タイトルの通り、AWS CDKのNodejsFunctionを使う時に依存関係を解決する方法が数パターンあるので比較してみる。 例 今回は、以下のTypeScriptのLambdaをデプロイするケースを考える。 // よくあるAPI GatewayのLambda Authorizer import { APIGatewayRequestAuthorizerHandler } from 'aws-lambda'; import { verify, decode } from 'jsonwebtoken'; export const handler: APIGatewayRequestAuthorizerHandler = async (event, context) => { const token = event.headers?.Authoriz

GraphQLサーバーを開発する際は、まず schema-first か code-first かを決めることになるでしょう。前者はまず graphql.schema を手書きし、そこから言語固有のコードを生成する方法です。後者は言語固有のコードを書いてから、 graphql.schema を生成する方法です。 今回2つのどちらが良いかは議論しませんが、後者の code-first & TypeScriptでGraphQL開発をする場合、ライブラリの選択肢がいくつかあります。この記事では、それらのライブラリの特徴をまとめます。特に以下の観点で比較します: Prismaとの連携: 私がTypeScriptでウェブ開発するときはORMのPrismaをよく使います。GraphQLと組み合わせる上では、型定義の重複やN+1問題を回避するため、ライブラリ間の連携は重要です。 開発の活発さ: 将来的に

AWS CDK TIpsシリーズの記事です。 AWS CDKのスタック、まとめてますか？分けてますか？分けている方はどういう基準で分けていますか？ この議論は人によって割と意見の分かれることも多く、最高の飲み会ネタになるでしょう。今日は私見も交えながら、CDKのスタック分割法についてまとめてみたいと思います。 自己紹介 私見を語る上で自己紹介は必要だと思うので、私自身のCDK経験を簡潔に: CDKは2020年の頭に出会い、以下のようにかれこれ3年ほど使っています。 前職ではそれなり規模のmBaaSをCDKを使ってAWSに移行･運用していました 現職では大小様々な規模のプロトタイプ開発にCDKを使っています。数えるとこれまで15個くらいシステムのプロトタイプを作ったようです。 現職のサイドプロジェクトとして、グローバル規模の社内システムの開発運用もCDKでやってました (お手伝い程度)。AW

これは AWS LambdaとServerless Advent Calendar 2022 の記事です。 Next.jsをホスティングする手段の一つとして、Standaloneモードで動かす方法があります。 コンテナ1個で動かせるため非常にお手軽な選択肢で、GCPのCloud RunやAWSのApp Runnerなどで動かす例を見ることも多いです。 この記事では、AWS Lambda + API Gatewayのサーバーレス鉄板構成でNext.js standaloneモードを公開する方法を紹介します。巷ではあまり見かけない構成だったので、新しい選択肢となることに期待したいです。この構成は趣味運用でできる限り費用を抑えたい方にもオススメです。 方法 具体的な方法はCloud RunなどでNext.jsを動かす従来の方法とほぼ同じです。Lambdaで動かすための面倒な工夫やコードの変更はそ

はじめに 最近AWSのサーバーレスサービスで作るWebサービスの雛形を公開してみた*1。小規模サービスならかなり安く (ほぼ無料になるケースも多そう) で運用できるので、割と良い選択になる場面も多いと考えている。今日はその布教記事。 github.com 全体構成 全体の構成は下図のとおり。特徴としては以下が挙げられる: CDNでフロントエンド (React SPA) の静的ファイルを配信 バックエンドAPIは API Gateway + Lambda (Express.js) データベースはDynamoDB (詳細は後述) ユーザー登録が必要なサービスのため、Eメール認証も付けている ありがちな非同期ジョブ、cronジョブ実行の仕組みも用意 AWS CDKで一発デプロイ こういう構成を趣味サービスで採ることのおそらく一番のデメリットは、学習コストだろう (VMを使った構成とはかなり違うの

ISUCON12予選に参加しました！結果、スコア自体は予選ボーダー通過していましたが追試で失格でした 😭😭😭 チームいすもなで参加　もなちゃんすまん… 通過した気満々で参加記事書いてましたが、供養のため投稿します。 なお過去にはISUCON9, 11に参加していずれも上位30~50%tileくらいに留まったので、今回はその反省も踏まえつつ準備しました。 今回の方針 Go使う 大きな変化はこれです。ISUCONで使う言語は実質RubyとGoの二択だと思ってます (他の言語はISUCON向けの情報が充実してない印象) が、これまでは業務でGoを使ったことがないのでRubyを選択してました。ただしRubyは以下のつらみが見過ごせませんでした: 諸々のツール (profilerなど) が古く使いづらい unicorn/pumaの設定などチューニング項目も増える 静的解析が弱いゆえにデプロイし

はじめに DynamoDBを使っていると、とかくテーブルは1つにまとめるべきという声や、複数テーブルからシングルテーブル設計に移行したという事例を耳にすることがあります。 しかし、その理由を聞いてみると、性能のためだったり管理を簡単にするためだったり、人により異なる印象です。 NoSQLにおける非正規化してデータをもつプラクティスは理解しつつ、その域を超えて全く無関係なItemを1テーブルにまとめる場合もあるようです。 私自身このトピックについて混乱していた中で、先日 The What, Why, and When of Single-Table Design with DynamoDB というブログを見つけました。 それを読んだ上で考えると、割と理解が整理できたので、この記事にまとめてみます。 なお私はDynamoDBの運用経験がまだ十分にあるわけではないので、勘違いや考慮漏れなどあるか

数少ない読者へ愛を込めて 「MariaDB にコントリビュートした話」ってタイトルでブログ書いてください✋— N. Yanagisawa (@NayutaYanagisaw) May 19, 2022 MariaDBに初めてコントリビュートした時の作業記録をまとめる。Issue自体は一番簡単なものを渡してもらったので、最も初歩的なことはじめの参考程度にご覧ください。 開発環境の用意 初めに開発環境を整える。MariaDBのビルドは重いとよく話に聞いていたので、手元のMacでは心もとない。仕事柄使いやすいEC2を採用。オレゴンに c5.2xlarge を建てた。 ↓を参考にすればよいが、今回はAmazon Linux 2上で動かしたいので、UbuntuではなくCentOS向けの手順を使う。 nayuta-yanagisawa.hatenablog.com sshログインしたら、これを打てばO

定義 プログラムに変更Xを加えるとき、類似の機能A,B,Cの実装を確認し、その共通部分から、変更Xに必要な実装を導くことがあります。 この一連の作業を、この記事では帰納的プログラミングと呼びます。 帰納（きのう、英: Induction、希: επαγωγή（エパゴーゲー））とは、個別的・特殊的な事例から一般的・普遍的な規則・法則を見出そうとする論理的推論の方法のこと。 出典: Wikipedia 帰納的プログラミングの例 このコミット は帰納的プログラミングにより作成されました。 github.com 帰納する際は、次のコミットを参考にしています。 MDEV-28007 Deprecate Spider plugin variables regarding statistics per… · MariaDB/server@f31642e · GitHub MDEV-28297 Depre