Amazon Web Services（AWS）は、マネージドサービスとして提供しているグラフデータベースの「Amazon Neptune」のサーバレス対応となる「Amazon Neptune Serverless」の正式サービス提供開始を発表しました。 Take your business all the way to Neptune! The first serverless purpose-built graph database that scales instantly in fine-grained increments to your exact needs—offering 90% cost savings compared to provisioning for peak capacity. Deeeep! #AWS https://t.co/VURnBhqi1s pic
Getting IAM permissions right is one of the hardest parts about building serverless applications on AWS. Many official tutorials and blog posts cop out of giving you the full details on how to set up IAM, preferring something vague like “ensure you use least-privilege permissions when creating this role”. Or worse, they give you a wide open wildcard or admin-level example policy with a “don’t use
はじめにNext.js アプリケーションのデプロイ先の候補として Vercel が真っ先に挙げられますが、料金などの色々な都合でほかの場所にホスティングしたいこともあると思います。 SSG (Static Site Generation) で利用する場合は、幅広い選択肢がありますが、SSR (Server Side Rendering) と ISR (Incremental Static Regeneration) を使いたい場合の選択肢は、それほど多くありません。 AWSに SSR可能な Next.js アプリケーションをデプロイするメジャーな２つの方法 AWS Amplify と Serverless Next.js Plugin (Component) を紹介します。 サーバーレスなSSRとISRNext.jsのさまざまなレンダリング形態と特徴については、本記事では深掘りしませんが、
概要 新しくジョインしたメンバー向けに独自でトレーニングメニューを作成し、最新の情報に追従してアップデートしていくのはコストがかかる面もあります。 AWSは公開されているトレーニングが豊富なので、私のチームではそれを活用しています。良さそうなハンズオンを適宜さがしてきて「作ったものを説明&デモ」「手順の存在しないオリジナル追加課題」という工程を加えています。 今のところ省力で効果的と感じているので、流れやハンズオンの探し方をまとめてみました。 流れ 経験や勉強していることを改めてヒアリング。担当予定のシステムのアーキテクチャを説明し、理解度をお互いに確認。 レベルと補完しておきたいサービスに応じたハンズオンを探す トレーニングの実施 ゴールの設定 フェーズ① ハンズオンを一通り完了させる 作ったものをデモを交えて説明&QA。 ゴールの設定 フェーズ② フェーズ①で作ったものに対してオリジナ
A common question developers bring up when wanting to develop serverless and cloud native applications is: what will the developer experience be like? It is an important question as a good developer experience with a quick feedback loop results in happier and more productive developers who are able to ship features rapidly. Since we’re building Plain to be intentionally small, an outstanding devel
Photo by Thalia Tran on UnsplashKafka is a top-notch industry platform for streaming data processing at scale. No surprise that first-class citizens of Kafka world are 24/7-running producer/consumer applications (e.g. classical servers, k8s-pods, etc.). But what about the rapidly rising world of AWS Serverless ecosystem? Image credit: AuthorThe diagram above is a collection of workflows: Propagate
こんにちは、臼田です。 みなさん、AWSの最新情報はキャッチアップできていますか？(挨拶 社内で行っているAWSトレンドチェック勉強会の資料をブログにしました。 AWSトレンドチェック勉強会とは、「日々たくさん出るAWSの最新情報とかをブログでキャッチアップして、みんなでトレンディになろう」をテーマに実施している社内勉強会です。 このブログサイトであるDevelopersIOには日々ありとあらゆるブログが投稿されますが、その中でもAWSのアップデートを中心に私の独断と偏見で面白いと思ったもの(あと自分のブログの宣伝)をピックアップして、だいたい月1で簡単に紹介しています。 12月はre:Invent 2021が先月から続いていてめちゃくちゃ記事があります。というわけで今年も2回に分割します。 ちなみにAWSの最新情報をキャッチアップするだけなら週刊AWSがおすすめですが、Developer
こんにちは。今年からアナリティクスエンジニアを名乗ろうとしてる池田です。 こちらは、KAYAC Advent Calendar 2021 1日目の記事です。 この記事では、setddblockという分散ロックを実現するためのツールと、その動作試験のために現代版アクセスカウンターを作成した話をします。 setddblock 皆様がcronなどで定期実行のスクリプトを実行する場合、同時実行されては困るものはどうしていたでしょうか？ daemontoolsのsetlock というツールを使って同時実行を防いでいたことがある方も多いと思います。 http://cr.yp.to/daemontools/setlock.html このsetlock はローカルのファイルシステム上にロックファイルを作成し、ロックファイルの作成が成功したら指定されたコマンドを実行するというツールです。 例えば1分ごとに起
JavaScript(TypeScript)で メディアサイトを インフラから構築する方法 / jsconf-jp-2021
はじめまして、wind-up-bird です。スタディストの SRE Unit に入ってから約半年が経ちました。今回は社内で利用している Serverless Framework を lambroll に移行しているのでその話を少し書いてみようと思います。 これまでの開発の流れスタディストでは AWS Lambda および周辺リソース（AWS IAM や Amazon API Gateway など）の管理はこれまで Serverless Framework を利用していました。開発からリリースの流れは以下の通りです。 Lambda の開発serverless.yml を作成開発者がデプロイ担当者に連絡する担当者がローカルの環境から serverless deploy を手動実行Serverless Framework 導入当初は管理しているリソースが少なくこの運用でもあまり問題になりません
Amazon Web Services ブログ AWS AmplifyでのフルスタックアプリケーションのCI/CDパイプラインの構築 この記事は、Complete guide to full-stack CI/CD workflows with AWS Amplifyを翻訳したものです。 AWS Amplify は、1) 条件付きバックエンドデプロイ、2) ビルド時のaws-exports.js の自動生成、3) 異なるAmplify アプリケーション間でのバックエンドの共有といった３つの新しい機能をAmplify のCI/CD ワークフローに追加しました。これらの機能を使用することで、より柔軟にフルスタックアプリケーションをデプロイすることが可能です。 AWS Amplify は、フルマネージドな CI/CD およびホスティングサービスを提供し、開発者は Git リポジトリを接続するだけ
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のコンソール
このシリーズの第一回では、べき等性とは何かについて紹介しました。べき等性とは「ある操作を 1 回行っても複数回行っても結果が同じである」という概念で、例えば実数の乗算では 0 と 1 がべき等になります (ある数字に 0 または 1 を何回掛けても同じ結果になる)。前回の記事では注文処理の例、障害復旧時のフロー処理の例でべき等性の考え方を紹介し、べき等性を保証する実装の典型的な基本パターンとして、①入力時チェック方式、②出力時チェック方式、③トランザクション型への処理への対応について説明しました。本シリーズでは AWS のサーバーレスサービスの利用を前提に、べき等性を実現する具体的な実装について紹介します。べき等性の実現には考慮すべき点が多いため、個別のユースケースを取り上げながら、どのようにべき等性を実装するかについて、これから数回に分けて解説していきます。 第一回の記事 では、クライア
追加の記事を作成しました。 ※ 混乱させるかもしれないので一応、ところどころamplifyって出てきますが、apiの作成にamplify使っているだけで、デプロイとかにはホスティングにはamplify使ってないので。わかりにくくてすみません。 ※現状では、bucketRegionを指定すると、エラーになってしまいます。 https://github.com/serverless-nextjs/serverless-next.js/issues/1111 解決済み serverless-next.jsでISRに対応したNext.jsをデプロイのサポートが！ついに！ つい先日こちらのプルリクがマージされてました。 まだα版ではありますが。 ということで、やってみました！ 結論躓くことなくうまくいきました！ Vercel使わずにも生きていけるかも！ 実際に試した構成 serverless-nex
はじめに esbuild のビルド時間の速さに感動して、個人プロダクトで使っている AWS Lambda (Node.js) をなるべく速く更新できるようにしたいな、と思ってやってみた投稿です。 おことわり タイトルに2秒と書いていますが、当然どんな環境でも2秒でできるわけではありませんのでご注意ください。 使用するソースコードの内容によって、デプロイする時間も変わります インターネットの回線速度やAWSリージョンによって、デプロイする時間も変わります 参考までに、私の通信速度はこのぐらいでした。 その他 AWS の状況などの要因でも変わるかもしれません。 「参考：私の個人環境の場合」の章にも書いていますが、私が実際に使っている Lambda 関数は約4.2秒でアップデートできます。 高速にデプロイしたい理由 ローカルでも AWS Lambda の環境をある程度まで再現して開発することは可
珍しく早起きをしてRSSを眺めてるとアッツアッツなアップデートが来ていました。 Amazon CloudFront announces CloudFront Functions, a lightweight edge compute capability 今回はCloudFront Functionsをご紹介していきます。 CloudFront Functionsとは？ CloudFront Functions(CF2)はLambda@Edgeより手前で、シンプルな処理をより高速に、素早く、安価に実行できるサービスです。 CloudFront Functionsを使うことでこれまでLambda@Edgeで実行していたシンプルな処理をよりユーザーに近いEdge Locationで実行しつつ、高速に処理を行う事ができます。 また、CloudFront FunctionsとLambda@Edge
概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel（最近資金調達しました！記事はこちら）で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト（リソース・運用） ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論（アーキ
そもそも、べき等性とは、どういうことを言うのでしょうか ? これは「ある操作を 1 回行っても複数回行っても結果が同じである」ことをいう概念です。 例えば、注文処理を考えます。画面インターフェースで、注文確定 / 送信ボタンを押すという操作で二度三度押してしまうユーザーがいます。これで同じ内容の注文が複数回登録されてしまったら問題です。こういったケースでは、画面側で連続して押せないような実装を追加したり (①)、サーバー側で同じ注文の処理であることを認識して適切に一つの処理と判断するようなこと (②) が必要です。 この例では、画面側の制御を入れたほうが簡単なように見えます。しかし、現実には画面とサーバーとの間のネットワークの問題や画面以外からの HTTP コールなどを考えると、このような重複リクエストが起こってしまうという可能性はゼロではありません。 このようなものへの対処として、サーバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く