Amazon CloudWatch Logs announces Live Tail streaming CLI support - AWS
Amazon CloudWatch Logs announces Live Tail streaming CLI support We are excited to announce streaming CLI support for Amazon CloudWatch Logs Live Tail, making it possible to view, search and filter relevant log events in real-time. You can now view your logs interactively in real-time as they’re ingested via AWS CLI or programmatically within your own custom dashboards inside or outside of AWS. In
Terraform AWS Cloud Control API provider now generally available
The AWS Cloud Control (AWSCC) provider, built around the AWS Cloud Control API and designed to bring new services to HashiCorp Terraform faster, is now generally available. The 1.0 release of the AWSCC provider represents another step forward in our effort to offer launch day support of AWS services. Initially launched in 2021 as a tech preview, the Terraform AWS Cloud Control provider is automati
水平 Pod 自動スケーリングのチューニングの驚くべき経済性 | Google Cloud 公式ブログ
Gemini 1.5 モデル をお試しください。Vertex AI からアクセスできる、Google のもっとも先進的なマルチモーダル モデルです。 試す ※この投稿は米国時間 2024 年 5 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。 Kubernetes HorizontalPodAutoscaler（HPA）は、環境のスケーラビリティと効率を管理するための基本的なツールであり、負荷の増加に応じてデプロイする Pod を増やすことで機能します。しかし、HPA で優れたコスト パフォーマンスを実現するには、HPA の設定、特に CPU 使用率の目標値の微細な部分を理解しなければなりません。一般的に、CPU 目標値を 50% に設定することが出発点として有効であるという認識があります。しかし、これは実際に費用の増加につながりかねません。実際、HPA
How we choked our Kubernetes NodeJS services
The days of counting bits and clock ticks are history. CPU and memory may be cheap, but not enough to waste them — especially since it would be at our users’ expense. In this blog post, I’ll explain how we run our services in Kubernetes and manage their resources, how to make the most of them and what to look out for. Cover image by Jeremy Waterhouse at pexels.comKubernetes resourcesWhen we deploy
コンテナイメージなのにブート可能な新技術による「Image mode for Red Hat Enterprise Linux」、Red Hatが発表。レジストリなどのコンテナ関連ツールがそのまま利用可能
コンテナイメージなのにブート可能な新技術による「Image mode for Red Hat Enterprise Linux」、Red Hatが発表。レジストリなどのコンテナ関連ツールがそのまま利用可能 Dockerコンテナで使われるコンテナイメージは、そもそもOSのカーネルなどが含まれていないためそれ単体で実行することはできず、コンテナに対応したOSの上にデプロイすることで実行されます。 このコンテナイメージのフォーマットは業界標準の「OCIコンテナ」（Open Container Initiativeコンテナ）として標準化されていますが、このOCIコンテナのフォーマットを守りつつ、ベアメタルサーバ上でブート可能な「ブータブルコンテナイメージ」の開発が進められています。 ブータブルコンテナイメージとは？ ブータブルコンテナイメージは、カーネルやデーモンなどの単独で実行可能なOSとしての
TypeScriptのGenericsで部分的型推論を行う
TypeScript では部分的型推論が出来ない TypeScript では部分的型推論が出来ないというのは、Generics の使い方に制限を与えてしまう問題です。例えば、上記のコードでは func 関数に対して一つ目の引数だけ number 型を指定したい場合、残りの引数の型も明示的に書かなければなりません。しかし、これは冗長であり、型安全性も損なわれる可能性があります。なぜなら、引数の型が変わったときに、Generics の型も一致させる必要があるからです。 部分的型推論が出来ればこのような問題を回避できまが、TypeScript では以下のような状態です。 const func = <A, B, C>(a: A, b: B, c: C): [A, B, C] => { return [a, b, c]; }; func(1, "2", 3); // OK func<number>(
新しいBuildKitでのイメージのリベースとリモートキャッシュサポートの改善 | Docker
BuildKit Builder エンジン、Dockerfile 1.4 フロントエンド、 Docker Buildx CLI の新しいバージョンをリリースしました。これらのそれぞれには、多くの新機能が付属しています。 このブログ投稿では、そのうちの1つであるDockerfilesの新しいコピーモードを示し、Dockerfilesでそれを使い始める必要がある理由を説明します。 Dockerfile 1.4 リリースでは、ビルドコンテキストまたは別のステージからファイルをコピーするためのコマンド ADD とコマンドが、 COPY 新しいフラグ '–link' を受け入れるようになりました。このフラグを使用すると、キャッシュ セマンティクスが大幅に向上し、新しい基本イメージの上にビルドを再構築せずに 2 日目の高速リベースを実行できます。 このフラグを使用するには、Dockerfile の先頭
AWS CodePipeline でステージレベルの手動および自動のロールバックをサポート
AWS CodePipeline V2 タイプのパイプラインでステージレベルのロールバックのサポートが開始されたので、本番環境に確実に変更をデプロイできるようになりました。あるステージで何らかのアクションが失敗したためにパイプライン実行が失敗した場合、そのステージで以前に成功したパイプライン実行にロールバックすることで、そのステージをすぐに既知の良好な状態に戻すことができます。ソースステージを除き、成功か失敗かにかかわらず、どのステージでも変更をロールバックできます。 コンソール、API、CLI、または SDK から手動でステージのロールバックを開始することも、失敗したら自動的にロールバックを選択するようにパイプライン定義内でステージを設定することもできます。ロールバックが開始すると、新しいパイプライン実行がそのステージから開始し、選択したパイプライン実行からの変更が適用されるか (手動ロ
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました | CyberAgent Developers Blog
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました CTO統括室の黒崎(@kuro_m88)です。本日早朝に面白そうな発表を目にしました👀 AWS CodeBuild now supports managed GitHub Action runners AWS CodebuildがGitHub Actionsに対応したという内容ですが、要するにAWSがホストするGitHub Actions Runnerが出たということですね🎉 AWSがマネージしてくれることで、EC2(x64, arm)はもちろん、GPUとカスタムイメージも利用できるようです。 さらに注目したのはGitHub Actions RunnerとしてAWS Lambdaが使えるようです。Lambdaが使えると嬉しいポイントはActionsのjo
Node.js + TypeScriptのモジュールを整理してみる
はじめにlink 最近受けるNode.js + TypeScript環境の相談の中で、CommonJSやECMAScript Modulesのあたりで落とし穴にはまっている人が多いという事に気づいた。 Node.jsは歴史的にCommonJSとECMAScript Modules（以後ESMと表記）がどうしても入り乱れる環境にあり、これにTypeScriptのモジュールが加わると組み合わせでさらに複雑度が増すのが現状である。 説明する際に口頭より整理した文章が欲しいと思ったので記事にする。 以下のリポジトリで検証コードを管理している。 https://github.com/koh110/module_test Node.jsモジュールチェックシートlink まず最初にNode.jsにおけるCommonJSとESMの挙動について整理する。 いきなり書かれても把握できないかもしれないが、一旦こ
RFC の URL はどのドメインで貼るのが良いか | blog.jxck.io
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H
[ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media
この記事について みなさん、ECS利用していますか！？ AWSでコンテナを使うのなら、ECSですよね！?(kubernetesわからない勢) ECSはタスクという単位で、アプリケーションを実行させます。 そして、タスクの中にコンテナが１つ以上稼働します。 タスクはタスク定義から作成されます。タスク定義はタスクの金型的な存在です。 また、タスク定義はJSONファイル（以後taskdef.json)として運用することが一般的です。 このtaskdef.jsonを実運用する際に迷うポイントがあります。 それは以下のどちらの方法にするかです。 – 方法① : 各環境ごとにtaskdef.jsonを用意する – 方法② : 各環境でtaskdef.jsonを共用する ①,②について、それぞれの詳細/メリット・デメリットについて洗い出しをして、どちらを採用すべきかについての見解を述べていきます。 あく
![[ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media](https://cdn-ak-scissors.b.st-hatena.com/image/square/44fc1474c22e3382588fd4b15ee70ff7f704163b/height=288;version=1;width=512/https%3A%2F%2Firet.media%2Fwp-content%2Fuploads%2F2021%2F07%2Fimg-eyecatch-aws-02-1200x630.png)
TypeScript 4.9 の "satisfies" 演算子で union の網羅性チェックが少し楽になる - Qiita
TypeScript 4.9 で新たに導入される satisfies 演算子にとても期待しています。個人的に役に立ちそうだと思ったユースケースとして、switch や if で union を順番に処理していくときの網羅性チェックが挙げられます。 declare const difficulty: "easy" | "medium" | "hard"; switch (difficulty) { case "easy": case "medium": case "hard": break; default: // OK throw new Error(difficulty satisfies never); } switch (difficulty) { case "easy": case "hard": break; default: // Type 'string' does not
Array.filter ← これで型が絞れるようになるらしい
const fruits = ['Apple', 'Banana', undefined] const result = fruits.filter(x => x !== undefined) // const result: (string | undefined)[] console.log(result) // ['Apple', 'Banana'] このように、resultという変数にundefinedがない状況でもfilterを使用した場合は型が絞られませんでした。 Javascriptに慣れてきて、TypeScriptに足を踏み入れた頃は本当にここで躓きました、、 それが近い未来、変わるかもしれません。 これからのfilter const fruits = ['Apple', 'Banana', undefined] const result = fruits.filter(x
Amazon Timestream for InfluxDB is now generally available
Today, AWS announces the general availability of Amazon Timestream for InfluxDB, a new time-series database engine. Timestream for InfluxDB makes it easy for application developers and DevOps teams to run fully managed InfluxDB databases on AWS for real-time time-series applications using open-source APIs. In minutes, you can create an InfluxDB database that handles demanding time-series workloads
コスト削減成功！Amazon Auroraの監査ログをS3に保存する仕組みを構築した話 - Classi開発者ブログ
こんにちは。プロダクト本部Growth部でエンジニアをしている id:ruru8net です。 前回はこちらの記事を書かせていただきました。 tech.classi.jp 今日は前述したSRE留学中にやったことの中の「Amazon Auroraの監査ログをCloudWatch Logsを経由せずS3に保存する」を紹介したいと思います。 前提 前掲の記事にもある通り、弊社のAWSにかかっているコストを調査したところCloudWatch Logsの特にAmazon RDSの監査ログの保存にコストがかかっていることがわかりました。今回は弊社で最も使用しているAmazon AuroraのMySQLのみを対象として、監査ログをCloudWatch Logsを経由せずS3に保存する仕組みを作成しました。 作成した仕組み こちらのオープンソースの仕組みを参考に構築、またLambdaのソースを使いました。
大テーブルと小テーブルのJOINのコスト計算の話 - amamanamam
先日MySQLアンカンファレンスでhogeさんの以下の発表を聴かせていただいた。 www.docswell.com 100万行×3行のJOINが全検索でhash joinになり、後者の行数を増やして100万行×10行にするとeq_refになる現象を紹介いただいた。 自分の環境でも同様の現象を再現できて、オプティマイザトレースの内容やコスト計算の過程が非常に興味深かったので、色々調べてみたことを垂れ流してみる。 環境 mysql> select version(); +--------------+ | version() | +--------------+ | 8.0.28-debug | +--------------+ 1 row in set (0.00 sec) mysql> desc mytable; +---------+--------------+------+-----
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node.js Redis Connection Pooling
DMMプラットフォームで発生したノイジーネイバー問題に対してのSLI/SLOを検討した話 - DMM inside
