ECSとRDSをやめて、AWSコストを9割削減しました
はじめに こんにちは。BEENOSのがれっとです。 AWS上にアプリケーションを構築する際、一般的なのはECS + RDSという組み合わせです。私も社内システムをそのような形で構築しました。 しかし、使わないときにもインスタンスが動き続けてしまうため、大量のトラフィックを捌かないアプリケーションにおいてはコストが見合わないものとなってしまいます。 そこで、ECS + RDSという構成からLambda + EFSの構成に社内システムを移行して、コスト削減した話を紹介します。 前提 以下の構成のアプリケーションを移行しました。 Blitz.js 内部に下記を使用 Prisma Next.js PostgreSQL テーブル数は12 (_prisma_migrationsテーブルを含めて13) AWS 構成図 移行前 移行後 リレーショナルデータベースを用いることが必須のアプリケーションを構築す
住所正規化のデモ機能を作ったので、日本のヤバい住所を入力してみた
はじめに 数か月ほど前、住所の正規化が話題になりました。こちらの記事が特に有名ですね。 関連して、こちらの記事も話題になりました。 当時はほかにも色々な人が日本のヤバい住所の例をあげてくれて、とても楽しかったです。 実は弊社でもAddressianという住所正規化サービスを提供しています。初めて目にする変わった住所を見かけたら、とりあえず自社のAPIに投げてみて「おお、正規化できた」「すごい！」などといいながら遊んで働いています。 サービスは無料で利用できますが、今までは利用の手順が面倒でした。 ユーザー登録する APIキーを発行する 住所正規化APIを呼び出すプログラムを用意する（サンプルコードあり） プログラムを実行して住所を正規化する そこで、もっと気軽に住所正規化を試してもらえるように、ユーザー登録しなくても使えるデモ機能を作ってみました。 デモ機能の概要 住所正規化デモ画面 こち
Serverless Next.js Component のISR実装を読み解く
AWS Amplify ConsoleでNext.jsのプロジェクトをデプロイすると Serverless Next.js Component のインテグレーションによってAWS Lambda リソースが最大4つ作成される(ソースコードはエクスポートできる) Default Lambda@Edge for Next CloudFront distribution API Lambda@Edge for Next CloudFront distribution Image Lambda@Edge for Next CloudFront distribution Next.js Regeneration Lambda それぞれのAWS Lambdaが行っていることを読み解くとVercelが自社で構成しているシステムの外観が分かるのではないかと思って眺めてみた (CloudFrontのコンソール
AWS CDKにLambda関数を数秒でデプロイするhotswap deployments機能が追加されました
はじめに おはようございます、加藤です。AWS CDKのv1.122.0からhotswap deploymentsという機能が追加されました。 通常cdk deployを実行するとCloudFormationをデプロイしますが、このオプションがONの場合はそうせずにSDKでLambda関数をデプロイします。これによってCloudFormationを実行する時間が発生しないため素早くデプロイを行うことができます。 当然この方法によるデプロイを行うとCloudFormationが管理する状態とドリフトが発生してしまいます。この機能は開発環境で素早くデプロイして動作を確認する為のものであり、本番環境では使用してはいけません。(ドキュメントにも明記されています) hotswap deploymentsは実験的な実装であり今後破壊的な変更が入る可能性があります。 v1.122.0時点でのDocs:
AWSでバッチ処理を実装する際の選択肢とサービス比較
処理が複雑でジョブの依存関係を定義したい場合は、AWS Batch 単体で制御するか、より複雑な場合は Step Functions を用いて Lambda、ECS（Fargate）、AWS Batch（Fargate） を組み合わせる。 AWSにおけるバッチ処理の選択肢 ざっくりとした選択肢は下記。 Lambda ECS（Fargate） AWS Batch（Fargate） これらのサービスに実際は SQS や Step Functions を組み合わせることもあるので選択肢はさらに広がる。 ちなみに、SQS + Fargate（常時起動でポーリング） という構成や、SQS + Lambda + Fargate（都度実行） という構成は、AWS Batch が Fargate に対応した現在は特にメリットがないので取り扱わない。 2021/5/2 追記 「常時リクエストがくるユースケー
商品入荷情報を定期的にスクレイピングしてSlack通知する（Lambda with serverless framework）
my-scraping-app ディレクトリ内に serverless framework 関連のファイルが生成されます。 その後 venv の設定や、serverless framework で AWS にデプロイするための credentials の設定をします（本記事では省略）。 以下 credentials 設定の参考ページです。 スクレイピング & slack通知スクリプトの実装 スクレピングは様々な方法があると思うのですが、今回は該当商品の商品ページに出ている「現在品切れ中」というボタンの有無を確認することで、入荷状況を判断することとします。 依存モジュールを追加して、handler.py にスクレピングコードと Slack 通知コードを書いていきます。 import requests import re import os from bs4 import BeautifulS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
