はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、_kenshです。 これから年末年始に入っていきますが、お気に入りのゲームを夜通し楽しんでも誰にも文句を言われない冬休みに入る方も多いんじゃないかなと思います！今年も１年お疲れ様でした！ ところで、タイトル回収しないといけないのでそろそろ本題に。 ちょうど、ゲームでマイクロサービスを使っていくことについての Advent Calendar 良記事が上がってました。 マイクロサービスとゲーム マイクロサービスとトランザクション これらの記事に対する Answer Song として "ゲームとイベント駆動アーキテクチャ" につい

Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R

Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R

なぜこの記事を書くか Fargateが良いかLambdaが良いかという質問をよく受け付けます。答えは一通りではありません。 すべてシステムやユーザーのワークロードに依存するのでどちらが優位ということは一般に言えません。 ただ、達成したい目的が明確で、こういうコンテキストの上ではどちらの方が相応しいということは言えると思います。そのために、今回Lambdaの起動モデルについて改めて説明を書きました。 Thread Model と Function Model LambdaはFunction Modelとなります。 Provisioned Concurrencyのプラクティスを説明する上でLambdaのFunction Modelを理解した方が良いと思いますので、すこし説明いたします。 Function Model Lambdaサービスにリクエストがくるとサービスはインスタンスを立ち上げ初回起

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Provisioned Concurrencyのおさらい 「LambdaのProvisioned Concurrencyと１年付き合ってみて思ったこと。」を前回書いたので、そこにProvisioned Concurrencyとは何で、なんのために誕生したかが書かれています。また、どんなとことで使えるかというユースケースもまとめておきました。 簡単に言うと、LambdaのColdStartの課題を解決するために生まれました。つまり、Lambdaのインスタンスを事前暖機しておく機能と言えます。 この絵のように、Provisioned Con

Lambdaのチューニング AWS Lambda 関数を使用するためのベストプラクティスにも詳しく書かれていますが、 Lambdaのチューニングにはそのスコープごとに３つの視点でみて行く必要があります。 他のAWSサービスとの統合方法やシステム要件などの俯瞰したアーキテクチャ的な視点 SQSを用いた非同期実装 EventBridgeを用いたイベントドリブン実装 StepFunctionsを用いたワークフロー構築 継続的改善のための可観測性向上、X-Ray, CloudWatch Metrics(Logs), External Extensions フロントキャッシュ etc. AWS Lambdaサービス機能としてのチューニング Provisioned Concurrencyによる暖機 Memory設定 VPC設定 Containerの利用 EFSの利用 etc. プログラミングコードとし

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? １年付き合って見て思ったこと。 Lambdaは毎年たくさん機能アップデートがあるけど、やっぱりLambdaの醍醐味はそのシンプルさだと思います。シンプルに使えるように、Lambdaだけでシステムやロジック設計をするのではなくて、AWSのビルディングブロックの組み合わせで適材適所で活かしあった方が良いなと思う１年でした。 Provisioned Concurrencyによって、より多くのワークロードでLambdaが利用された１年になりましたが、それ以上にProvisioned Concurrencyを利用しなくても、そのまま素で自動的にス

TL;DR AWS LambdaでJavaのフレームワーク、たとえばSpringBootなどを使いたいって思ったことありませんか？ 結論としては、AWS Lambdaの上に、aws-serverless-java-containerフレームワークというプロキシフレームワークを入れれば比較的簡単に実現可能です。 今日は、そのあたりを、このAWSブログを軽く意訳しつつ書いていきたいと思います。 AWS Open Source Blog Running APIs Written in Java on AWS Lambda 背景 Java開発者は、SpringやSpring BootからJersey、Sparkといった慣れ親しんだフレームワークで開発していることが多いのではないでしょうか。 これらのフレームワークは、Tomcatなどのサーブレットコンテナを用いて、ビルドされたWarやJarをデプロ