AWS から OCI に移行してコストを約半額にした話 - Qiita
OCIについて知らない方向け AWSは知ってるがOCIを知らないという方は取り急ぎ以下のようなページを読むとイメージが掴みやすいかと思いますのでリンクを貼っておきます。 本件では細かい用語の違いなどの説明は省略します。 OCIへの移行理由 今回移行した理由はコスト削減が最大の理由でした。 オンプレからAWSに移行したのは3年前の2021年2月で当時のドル円相場は約106円でした。 2021年のAWS移行当時、RDSのReserved InstancesとEC2のSavings Plansを3年で購入していました。（通常は1年などで購入されるケースの方が多いと思いますが、歴史のあるサービスなので急激なリソースの増減はあまり無さそうではと考えたためとなります。結果としては円が強いタイミングで安く買えて助かりました） 移行を検討し始めたのはRI/SPが切れる1年前くらいで、その時点のドル円レート
Redis, DynamoDB, S3 Selectを使ったIoT向け時系列データベースのアーキテクチャ
高いリアルタイム性を保つため、デバイスにつき、 3秒に1回 の頻度でデータを貯めています。 1つ1つのデータは小さいのですが、何年間分のデータを残すとなると、積もり積もって相当なデータ量になっていきます。 センサデータを保存するためのテーブルは1つ（ 単一テーブル ）で、いわゆる分割はしていません。 ちなみに最初期は、「DynamoDBで時系列データベースを構築するベストプラクティス」の中で紹介されているように、データの期間によってテーブルを分けていました。ただし、紆余曲折があって単一テーブルに戻しました。詳細は本筋から外れるので、もし興味があれば下記の（補足）をご覧ください。 （補足）ベストプラクティスをやめて単一テーブルにした理由 以下の3つの理由によるものです。 1. テーブルが分かれることで、データアクセスが複雑になる テーブルをどう分けるか次第でもありますが、DynamoDBで書
Amazon Aurora のインフラコストを55％削減しました。 - Stanby Tech Blog
はじめに こんにちは。スタンバイで求人データ管理に関するバックエンドエンジニアをしている池田です。 スタンバイはWEB上に存在する大量の求人を一括検索できるサービスを提供しており、その求人票のマスタのデータは Amazon Aurora を使って運用しております。 以下の記事で説明をしておりますが、2021年に求人取込直後の求人情報を構造化データとして保存するために Amazon Aurora を採用しました。 スタンバイの求人情報取込の仕組みを作り直した話 〜序章〜 DBエンジンとして Aurora ( MySQL 5.7 ) を利用しております。 ストレージエンジンとしてInnoDBを利用しております。 しかし作り直しから時が経ち、求人票の増加や各種機能の追加等によって Aurora のデータ量は想定上の速さで増加していき、それに比例する形でインフラコストも増加し続けていました。 今回
Amazon ECR pull through cache now supports additional upstream registries
Amazon Elastic Container Registry (ECR) now includes Docker Hub, Azure Container Registry, and GitHub Container Registry as supported upstream registries for ECR’s pull through cache feature. With today's release, customers can configure a rule that is designed to automatically sync images from the newly supported upstream registries to their private ECR repositories. ECR customers can create a pu
NTT退職エントリ 底辺子会社編
先日10年勤務したNTTを退職してフリーランスエンジニアになりました。 流行りの？NTT退職エントリーですが、よくあるのはNTT研究所とかの超エリートがGAFAMでデータサイエンティストになりましたみたいな話ですが、 私の場合はグループでも底辺の話で、NTT持株会社から見るとひ孫会社で保守を専門にする会社で更に中途採用です。 研究所なんてほんの上位の話なので、NTTの実態として大量の底辺保守人材を抱えているので、ある意味リアルな話になるかなと。 自己紹介 NWエンジニア歴9年、AWSエンジニア歴1年の37歳。 NWエンジニアと言いつつほぼ監視のみという弱々エンジニアでしたが、AWSエンジニアに転向して1年でフリーランスに挑むことにしました。 前歴 新卒時は氷河期末期。 新卒は金融営業だったが1年で嫌気差し退社 次も金融だったがパワハラにあい1年で退社 鬱になり就職活動する気も起きないが金も
VS Code オンライン版「code-server」 を AWS Lightsail に構築（マルチユーザー対応） - Qiita
本記事の内容 VS Codeのオンライン版「code-server」をAWS Lightsailに構築し、ブラウザがあればどこでも開発できる環境を作る。 下記設定を行う。（今後追加予定） マルチユーザー対応 拡張機能のインストールと設定 Node.jsのインストール ※本記事は、code-serverやDockerを学習しながら書いています。 もっと良い設定や方法がありましたら、コメントいただけると嬉しいです。 前提条件 Lightsailインスタンス（Linux）を作成済み。 Docker、Docker Composeを導入済み。 本記事は、Lightsailの3.5ドルプラン、CentOS バージョン 7.9.2009 で作成。 ※その後、5ドルプラン（メモリ1GB）にアップグレード。 メモリ512MBではスワップが大量に発生し、操作レスポンスが落ちたり、npmでのパッケージインストー
【SAM + Cognito + Amplify ライブラリでログイン機能を実装した React アプリを作成】Part1 - SAM で API 作成 - シー・エス・エス イノベーションラボ（ブログ）
みなさん、こんにちは。イノベーションLABのハヤシです。 今回は、以下の構成の Web アプリをさくっと作る手順をご紹介します。 バックエンド：Node.js の REST API（Amazon API Gateway / AWS Lambda） フロントエンド：TypeScript の React 今回は全 3 回のうちの 1 回です。 必要な部分だけでも、ぜひ参考にしてみてください。 環境構築手順はこちらで紹介しています blog.css-net.co.jp 1. 前提条件 1-1. 想定読者 1-2. 作成するもの 1-3. 前提条件 2. 事前準備 2-1. 作業ディレクトリ作成 2-2. リポジトリ作成 2-3. ターミナルで git 設定 3. バックエンド API 3-1. API 作成 3-2. API デプロイ 3-3. API 動作確認 3-4. リポジトリに登録 3-
翻訳: プログラム可能なハードウエアを搭載したEC2インスタンス(F1) - Qiita
原文 AWS Blog Developer Preview – EC2 Instances (F1) with Programmable Hardware by Jeff Barr | on 30 NOV 2016 感想 * Ultraスケール使ってみたい * Ultraスケール向けにフロアプランナを作ってみたい * Vivadoを１０本とか同時に動かせるのだろうか？ * Ultra8個あればASICプロトタイピングとか余裕でできる？ ジェフ・バール 汎用的な目的を持ったツールと特定の目的のために作られたツールのどちらかを選ばなければ ならなかったことはありませんか？ 汎用ツールは、多くの異なる問題を解くのに使えますが、ある特定の問題に最適にはならないでしょう。 特定の目的向けに作られたツールは、その仕事に限れば素晴らしい能力を発揮しますが、それが必要な機会は多くはないでしょう。 コンピュ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSコストを全体で43.75%削減するためのコストモニタリング技術 | ドクセル