Amazon Auroraに2種類のオートスケーリングポリシーを組み合わせてコストを削減しました - Nealle Developer's Blog
こんにちはSREチームの宮後(@miya10kei)です。最近、DisplayLink対応の変換アダプターをGETし、トリプルディスプレイ化していろいろ捗っています！ 前回から少し時間が空いてしまいましたが、今回はAmazon Auroraに対して2種類のオートスケーリングポリシーを組み合わせた事例を紹介します。 背景 Park DirectではデータベースにAmazon Aurora（Provisioned）を利用し、Writerインスタンス1台、Readerインスタンス2台の構成で運用しています。 ReaderインスタンスのCPU利用率には次の傾向がありました。 ReaderインスタンスのCPU利用率の推移 CPU利用率の傾向 平日 08:00~18:00までCPU利用率が（相対的に）高い状態が続き、18:00を境に低い状態になる。 休日 平日と同じ傾向だが全体的にCPU利用率が低い状
検索が爆速になるデータベース設計を公開します
こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/
PlanetScaleというサーバレスDBが凄く勢いのあるサービスらしいのでQuick Startやってみた - Qiita
PlanetScaleというサーバレスDBが凄く勢いのあるサービスと聞いて、公式にクイックスタートがあったのでやってみました。 環境 PC: MacBook Pro (Intel Core 2016) OS: macOS Montery12.2.1 では概要から確認していきます。 サーバーレスDBとは サーバがない、のではなく、サーバ管理や検討が不要 AWS Lambda(NoSQL)など PlanetScaleとは PlanetScale年表 2010年頃 YouTubeが急激に成長し、データベースが爆発しそうになっていたので、Sugu氏ともう一人のYouTubeのエンジニアがオープンソースプロジェクト「Vitess.io」（ヴィテス）を立ち上げる 2016年頃 MySQLでバイナリプロトコルを扱えるようにしたことで、VitessはYouTube以外の企業にとっても魅力的なシステムになり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
