タグ

dbとawsに関するlepton9のブックマーク (48)

  • 事業の成長にアラインするためにAWS DMSを活用してDB統合した話 - Techtouch Developers Blog

    バックエンドエンジニア兼万年ダイエッターの taisa です。毎朝子どもの幼稚園バス送りのついでに短距離ダッシュして運動してます。はたから見ると変な人ですが、バスを追っかけるようにダッシュすると幼稚園バスの子どもたちは喜んでくれます。 テックタッチは以前、マイクロサービスの切り直し後に DB 統合を実施しました。記事では、テックタッチがどういったプロセスで DB 統合を実施したかを紹介します。また、AWS DMS を利用する際に気をつけるポイントについても合わせて紹介します。 マイクロサービス切り直し記事のおさらい なぜ DB 統合したか Before After DB 統合の前提条件 やりたいこと 制約 DB の特徴 サービスの特性 AWS DMS(Database Migration Service)とは どのように DB 統合したか Phase1:DMS でレプリケーションを開始す

    事業の成長にアラインするためにAWS DMSを活用してDB統合した話 - Techtouch Developers Blog
    lepton9
    lepton9 2024/10/08
  • 開発環境のデータベースでも本番環境相当のデータを使う - クックパッド開発者ブログ

    こんにちは。レシピ事業部バックエンド基盤グループの石川です。 2014 年、このブログに『開発環境のデータをできるだけ番に近づける』というタイトルの記事が投稿されました。 クックパッドでは、ユーザーさんが実際に体験している状況と近い状況を再現しながら開発することに価値があると考えています。技術的には、最初からレコードがたくさんあることによってパフォーマンス問題に気付きやすくなるなどの長所がありますし、サービス開発としても、実際のユーザーさんの体験を最速でなぞって素早くフィードバックループを回せるようになるという長所があります。 この慣習は 2014 年の記事から 10 年経った今でも続いています。一方でその実現手法については変化を続けてきました。現在のクックパッドでは状況に応じていくつかの手段を使い分けています。それらの手段については今まであまり公開されていなかったような気がするため、こ

    開発環境のデータベースでも本番環境相当のデータを使う - クックパッド開発者ブログ
  • リクルートが『スタディサプリ』で Amazon Aurora Serverless v2 を採用。コストを最適化しつつ Aurora の管理工数を大幅削減 | Amazon Web Services

    Amazon Web Services ブログ リクルートが『スタディサプリ』で Amazon Aurora Serverless v2 を採用。コストを最適化しつつ Aurora の管理工数を大幅削減 株式会社リクルートは、日国内のHR・販促事業及びグローバル斡旋・販促事業をおこなう事業会社です。リクルートでは、『スタディサプリ』というスマートフォンアプリ、パソコンで利用可能なオンライン学習サービスのデータベースとして Amazon Aurora PostgreSQL を採用しています。 2023 年 5 月にこの Aurora PostgreSQLAurora Serverless v2 に変更しました。採用検討から 1.5 ヶ月と短期間で導入を決定しましたが、入念な検証の結果 Aurora の運用負荷を大幅に削減し、サービスの安定運用も実現しています。ブログは、『スタディサ

    リクルートが『スタディサプリ』で Amazon Aurora Serverless v2 を採用。コストを最適化しつつ Aurora の管理工数を大幅削減 | Amazon Web Services
  • DynamoDBでできないこと

    この記事について 記事は、筆者が普段AWSの各種サービスを使って感じた感想・気づきをもとに、クラウドアーキの設計やサービスのより良い使い方Tipsを考察するシリーズです。 第二弾も第一弾に引き続きDynamoDBについてです。 DynamoDBはkey-value型のNoSQLであり、従来よく使われていたRDBとは異なるDB特性・クエリ特性を持っています。 そのためRDBを設計するときと同じようなノリでスキーマ設計・テーブル設計を行うと、後から「この操作をやらせるならDynamoDBじゃないほうが良かったんじゃないか?」ということが発覚しがちです。 記事では筆者が遭遇した「DynamoDBでやらせてみたら苦労した・できなくて設計変更を強いられた」というユースケースをまとめることで、DynamoDBのクエリ特性や適性を考察することを目指します。 使用する環境・バージョン 2024/1/1

    DynamoDBでできないこと
  • いいねとその通知機能をDynamoDBで設計したら思ったよりムズい - エムスリーテックブログ

    【Unit4 ブログリレー4日目】 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 今回は、SNSではごく一般的ないいねとその通知機能をDynamoDBを利用して実装したら思ったより大変だったので、その詳細をご紹介します。 キャナルシティ劇場は、福岡県福岡市博多区の複合商業施設「キャナルシティ博多」のシアタービル最上階に位置する劇場。文には特に関係ありません。 m3ラウンジ m3ラウンジのいいねとその通知の要件 RDBで実装したらどうなるか いいね機能 通知機能 DynamoDBで実装する いいね機能 通知機能 いいねする いいねを取り消す 通知を表示する 未読の通知の取得 未読の通知数 未読の通知を既読にする テーブル設計むずい PKとSKに何を選ぶか LSIは途中から作れない DynamoDBをローカルで動かして設計する まとめ We are h

    いいねとその通知機能をDynamoDBで設計したら思ったよりムズい - エムスリーテックブログ
  • Redis OSS とMemcached - インメモリデータストアの違い - AWS

    Redis OSS と Memcached は、人気のあるオープンソースのインメモリデータストアです。どちらも使いやすく、高性能ですが、エンジンを選択する際に考慮すべき重要な違いがあります。Memcached はシンプルさを重視して設計されている一方で、Redis OSS は幅広いユースケースに効果を発揮する豊富な一連の機能を提供します。要件と、各エンジンが提供する内容を理解して、ニーズに合ったソリューションを選択します。

    Redis OSS とMemcached - インメモリデータストアの違い - AWS
  • Amazon DynamoDB の論文を読んでいく - Qiita

    概要 AWS で人気のサービス DynamoDB についての論文が公表され巷で噂になっていたと思う。 今回は、その論文を読み込んでいき、ざっくりまとめていくという記事になります。 完全趣味な記事なので、興味ある人がいれば幸いです笑 Abstract まず論文のタイトルですが、「Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service」と題したものとなっています。 Amazon DynamoDB は、NoSQL とよばれる部類のデータベースサービスです。 一貫した耐久性、可用性、パフォーマンスを提供してくれるマネージドなサービスなのが特徴ですね。 冒頭、2021年に66時間にわたる「Amazon Prime Day」中にピーク時8920万リクエスト/秒をさばいてい

    Amazon DynamoDB の論文を読んでいく - Qiita
  • PostgreSQLエンジンでのAuroraとRDSのベンチマーク - so what

    PostgreSQLエンジンでAuroraとRDSでpgbenchを使った負荷テストを行った。 テスト環境 クライアント pgbench (PostgreSQL) 14.2 (Ubuntu 14.2-1ubuntu1) EC2のc5.2xlargeインスタンスから実行 クライアントインスタンスの性能上限には引っかかっていないことは確認 以下のようなスクリプトを実行 スケールファクター: 100 トランザクションタイプ: デフォルト(TPC-B like) #!/bin/bash . .rds for i in 8 16 32 48 64; do echo "--- $(date +%FT%TZ) RDS $i" pgbench -i -s 100 -q pgbench -c $i -T 210 sleep 60 done echo "--- $(date +%FT%TZ) RDS end"

    PostgreSQLエンジンでのAuroraとRDSのベンチマーク - so what
  • ありがとうRedshift よろしくBigQuery - freee Developers Hub

    ナカミチといいます。freeeのデータ基盤でエンジニア業に勤しむ日々です。 今回は長年freeeの分析環境を支えてくれたRedshiftをBigQueryに移行したお話。 なお技術的な詳細までは触れず、移行プロジェクト全体に関して記述しています。 (Techieな記事を期待した方スミマセンmm) 移行の規模はどんなもんか ボリューム的にはざっと下記の通りです。 テーブル数: 約2,000テーブル データ量: 約180TB(snappy) クエリ数: 約500件 移行期間: 約1年4ヶ月(準備期間含む) そもそもなんで移行したの? 大別すると移行を決めた理由は3つほど。 パフォーマンス向上が見込めた 手段を多様化したい エンジニアリソースの最適化 以下にそれぞれ細かく記述します。 1. パフォーマンス向上が見込めた SQLによりますが、それまで使っていたRedshift環境と比べて平均5〜6

    ありがとうRedshift よろしくBigQuery - freee Developers Hub
  • DynamoDB の基礎と設計 / DynamoDB Design Practice

    Qiitaにも記事があります https://qiita.com/_kensh/items/2351096e6c3bf431ff6f サーバーレスでよく利用される Amazon DynamoDBですが、設計方針はRDBMSと違うとよく言われます。 アクセスパターンに従った、DynamoDBならではの設計の仕方を一緒に学んでみませんか?

    DynamoDB の基礎と設計 / DynamoDB Design Practice
  • DynamoDB の設計について考えてみる。 - Qiita

    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

    DynamoDB の設計について考えてみる。 - Qiita
  • あと2時間でElastiCacheのメモリが枯渇!そのときあなたは何をしますか?

    突然ですが... あなたは、あるゲームプロジェクト番リリース2日前にサーバエンジニアとしてJOINしました。いざリリースを迎えたとき、ElastiCacheのメモリが突然危険域を超え、さらにあと2時間で枯渇しそうな状況になりました。 さて、この状況におかれたあなたは何をしますか? はじめに モバイルゲームのシステムは新しいイベントをopenするとトラフィックが2倍、3倍、時には普段の10倍以上来ることがあり、トラフィックの変動が非常に大きい特性があります。 新しいゲームのリリース時はより顕著で、想定以上のトラフィックが来ることもしばしばあります。 この記事は、あるゲームプロジェクト番リリース時に大規模トラフィックが来た際のサーバトラブルを題材に、 どのような観点で問題を切り分けていったのか、トラブルシュートのプロセス どのような準備(負荷テスト)をしていれば防げるのか という話をし

    あと2時間でElastiCacheのメモリが枯渇!そのときあなたは何をしますか?
  • 米AWS、サーバレス時系列データベースサービス「Amazon Timestream」の提供を開始

    Amazon Timestreamは、高速でスケーラブルなサーバレス時系列データベースサービスであり、1日あたり数兆もの時系列イベントを最大1000倍高速に、リレーショナルデータベースの10分の1のコストで簡単に収集、保存、処理できる。 すべてのデータは、同じAWSリージョン内の複数のアベイラビリティゾーン(AZ)に常に複製され、新たなデータはメモリストアに書き込まれ、操作の成功を返す前に3つのAZ間でデータが複製される。 データレプリケーションは、クォーラムベースなのでノードまたはAZ全体が失われても、耐久性や可用性は損なわれない。また、メモリストア内のデータは、追加の予防措置としてAmazon Simple Storage Service(S3)へ、継続的にバックアップされる。 クエリは、保存場所を指定することなく、階層全体の最近のデータと履歴データに自動でアクセスして結合し、時系列固

    米AWS、サーバレス時系列データベースサービス「Amazon Timestream」の提供を開始
  • 【レポート】楽天の大規模決済システムを支えるAWSアーキテクチャ #AWSSummit | DevelopersIO

    DA事業部の春田です。 AWS Summit Online絶賛開催中!ということで、記事では「CUS-65: ペイメントプラットフォームにおける AWS の活用」の内容についてまとめていきます。 セッション情報 楽天株式会社 グローバルテクノロジー統括部 國谷 彩 氏 AWS上でのPayment Platformシステムの歴史についてお伝えします。AWSへ移行してからこれまでの課題と解決方法について説明します。 ※セッション動画は以下リンク アジェンダ 楽天グループについて ペイメントプラットフォームについて ペイメントプラットフォームにおけるアマゾンウェブサービス(AWS)の歴史 楽天グループについて Eコマースのサービス「楽天市場」をはじめ、Fintech事業やエンターテイメント事業まで、さまざまなビジネスを展開 各サービスが楽天共通IDで繋がることで、サービスを跨いだグループシナ

    【レポート】楽天の大規模決済システムを支えるAWSアーキテクチャ #AWSSummit | DevelopersIO
  • PayPayでのDynamoDB活用事例について

    Presented by: Tomoki Nishinaka, Yu Zhouxun PayPayの機能の一つとして2020年4月に新たにリリースされた通知サービスでは、スケーラビリティとパフォーマンスを重視し、数々のデータストアソリューションの中からDynamoDBを採用しました。通知センターの…

    PayPayでのDynamoDB活用事例について
  • RDS Proxyが無意味になる恐怖の現象「ピン留め」を回避するための基本的な設定値について | DevelopersIO

    CX事業部@大阪の岩田です。 RDS Proxyを利用するとRDS ProxyにプールされたDB接続を複数のDBクライアントで使い回すことができ、限られたDB接続を効率的に利用することが可能になります。しかし複数のDBクライアントが安全にDB接続を共有できない場合、RDSProxyはコネクションプール内のDB接続を特定のDBクライアントに対して固定してしまいます。これが「ピン留め」と呼ばれる現象で、このピン留めが発生するとRDS Proxyを利用するメリットが失われてしまいます。 このブログでは「ピン留め」を回避するための基的なパラメータ調整についてご紹介します。 環境 今回利用した環境です こちらのブログとほぼ同様の設定にしてクライアントからの同時接続数が実質1に制限されるようにしています。 RDS for PostgreSQL 11.8-R1 インスタンスクラス db.t3.mic

    RDS Proxyが無意味になる恐怖の現象「ピン留め」を回避するための基本的な設定値について | DevelopersIO
    lepton9
    lepton9 2020/07/29
  • [速報]RDS ProxyがGAされました!! | DevelopersIO

    CX事業部@大阪の岩田です。 re:invent2019で発表されたRDS ProxyがついにGAされました!! RDS Proxyって何? RDS向けのフルマネージドなDBプロキシです。よくLambdaとの組み合わせについて取り上げられますが、Lambda専用のサービスというわけではなく、EC2やFargate上で動作するアプリから利用することも可能です。 つい数日前にこんなブログを公開しているので、よければ参考にして下さい。 何が嬉しいの? これまでも自前でEC2を構築してPgpool-IIやPgBouncerを導入すれば、RDSでもプロキシ型のコネクションプーリング機構を利用することができましたが、EC2やミドルウェアの管理負荷を考えるとあまり良い選択肢とは言えませんでした。今回RDS ProxyがGAされたことによりプーリングレイヤーを簡単に構築&運用することが可能になり、アプリ

    [速報]RDS ProxyがGAされました!! | DevelopersIO
    lepton9
    lepton9 2020/07/01
  • 「AWSではじめるデータレイク」出版記念データレイク解説セミナーの資料公開 | Amazon Web Services

    Amazon Web Services ブログ 「AWSではじめるデータレイク」出版記念データレイク解説セミナーの資料公開 去年よりAWSのメンバー4名(志村、上原、関山、下佐粉)でデータレイクの基礎からアーキテクチャ、構築、運用管理までをカバーした書籍「AWSではじめるデータレイク」を執筆してきたのですが、7月出版の目処がたったことを記念して、5月末から毎週木曜にデータレイクに関するWebセミナーを開催してきました。 幸いにも大変多くの方にご参加いただくことができました。ご参加いただいた方にはあらためてお礼申し上げます。 一方で、以前の回に出られなかったので資料だけでも公開して欲しい、というご要望をたくさん頂いていました。そこで今回第1回から第3回の資料を公開させていただく事になりました。 ※ 2020/06/25更新:第4回の資料を追加公開しました 以下よりご覧いただけます。(PDF

    「AWSではじめるデータレイク」出版記念データレイク解説セミナーの資料公開 | Amazon Web Services
  • LambdaからRDS/RDBを利用する際に意識したいポイント5選 | DevelopersIO

    こちらの記事はRDS ProxyがGAされる前に執筆した記事です。現在はLambdaからRDSを利用する場合、間にRDS Proxyを挟むという選択肢が増えているので、まずはRDS Proxyを使う/使わないの検討をお願いします。以後で紹介しているトピックの一部はRDS Proxy利用時は考え方が変わってきます。 CX事業部@大阪の岩田です。私が現在関わっているプロジェクトではLambda × RDSというアーキテクチャを採用して開発を進めています。開発を進める中でLambda × RDS(RDB)という構成についてある程度ノウハウが貯まってきたので、注意したいポイントやオススメの設定をTIPS的に紹介していきます。 環境 以後の説明では以下の環境の一部もしくは組み合わせを利用しています。具体的なコードやSQLの例はプログラミング言語やDBエンジンに依存しますが、根底の考え方はどの言語、

    LambdaからRDS/RDBを利用する際に意識したいポイント5選 | DevelopersIO
  • PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離 | Amazon Web Services

    Amazon Web Services ブログ PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離 Software as a Service (SaaS) プロバイダーには、基的にテナントデータの分離を適用する責任があります。テナントの 1 つが別のテナントのデータにアクセスした場合、信頼はなくなり、ビジネスのブランドに永久的な損害を与える可能性があるだけでなく、さらにひどい場合には、ビジネスを失う可能性があります。 リスクが非常に大きいため、効果的なデータの分離を計画することが重要です。マルチテナントアーキテクチャは、各テナントのリソースをレプリケートするのではなく、すべてのテナントのデータストレージリソースを共有することで、俊敏性と運用コストを節約します。しかし、共有モデルで分離を適用することは難しいため、マルチテナントデータモデルで妥協して、テナント

    PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離 | Amazon Web Services