SREチームの安達(@adachin0817)です。今回はMENTA、Lancers Creative、Lancers Agencyでマスキングした本番環境のデータをStgや開発環境のMySQLコンテナへ毎週リストアする仕組みを実装しました。実際にここらへんは運用をしていく中で一苦労されている方も多いのではないでしょうか。それではまず背景と、実装するに当たっての活動含めてご紹介できればと思います。 背景 今回はMENTAを例にしています。各サービスの開発環境はDockerを利用しており、本番とStg環境はTerraformで管理しています。カラム追加ではマイグレーションを実行することでサンプルのスキーマファイルを投入して開発をしているのですが、たまに開発環境で動いていたソースがStgや本番で動かないといったことで開発効率が下がることが見受けられます。開発メンバーにとってはより本番環境に近い
技術本部 サービスリライアビリティグループ（SRG）の長谷川 @rarirureluis です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 また Amazon Aurora MySQL（以下：Aurora MySQL）の話です。何でこんなに Aurora MySQL に関する記事ばっか書いてるのか僕も分かりません。 前回の Aurora MySQL のアップグレード方法のベストプラクティスはこちらです。 RDS Graviton2 に少ないリスクで切り替える方法を考えてみる【アップグレード編】 | CyberAgent Developers Blog 今回はバックアップについてです。 そのクラスター、間違ったクエリ流したときに
概要 ローカルPCのDocker環境からRDSに接続する方法のメモ Dockerの開発では、DBのコンテナイメージを作成する場合が多いと思われるが、何かしらの理由でAWSのRDSを直接使用したい場合の方法 前提 VPC環境を構築し、PrivateサブネットにEC2インスタンスおよび、Railsアプリケーションが接続する用のRDSを作成済 Nat gateway もしくは Endpointにより サービス 「com.amazonaws.us-east-1.ssm 」に接続が可能なこと EC2インスタンスにssm-agentがインストールされている EC２インスタンスへは踏み台サーバ等使用せずにSSMにて接続を行う ローカルPC環境 Docker for mac 参考 https://dev.classmethod.jp/articles/session-manager-launches-tu
はじめに CX事業本部の佐藤智樹です。 今回はAWSが提供しているDynamoDB用のアプリ「NoSQL Workbench」の機能を使ってデータモデリングする流れを解説します。 最近案件でテーブル設計を再検討する必要がありNoSQL Workbenchを使ったところ、サンプルデータを入れながら設計が正しいか検証でき非常に便利だったので紹介します。 他の記事でもアプリの紹介はありますが本記事ではデータモデリングに絞って解説を行います。題材として多対多のデータをモデリングしながら設計する方法を紹介します。 本記事を読めば今までDynamoDBのデータ設計に悩んでいた方の検討時間をかなり減らすことができます。自分ももっと早く「NoSQL WorkbenchのData modeler はこう使って欲しい！」という記事があれば良かったなあと思ったので記事にしました。 NoSQL Workbench
CX事業本部＠大阪の岩田です。 社内で需要がありそうだったので、RDS Proxyの基本動作について簡単にまとめてみました。クライアントからの最大同時接続数を1に設定したRDSに対してRDS Proxyを構成し、クライアントアプリケーションに見立てたEC2からいくつかのパターンで接続を試行した結果をまとめています。 環境 今回検証に利用した環境です。 RDS for PostgreSQL 11.8-R1 インスタンスクラス db.t3.micro max_connections: 9 バックグラウンドでrdsadminユーザー、rdsproxyadminユーザーがDBに接続するのを考慮して9に設定しています。今回の環境であればmax_connectionsを9に設定することで非マスターユーザーからの同時接続数を1に制限することができます。 RDS Proxy エンジンの互換性: Postg
こんにちは！少し前までProgateでエンジニアのインターンをさせていただいておりました、chisatonと申します。 Progateのアドベントカレンダーに参加させてもらえるだなんて思ってもみなかったので、とても嬉しい限りです。 今私はエンジニアとして別の会社で働かせていただいているのですが、今の部署とProgateではAWSを使用しているという点で共通点があるため、今回はAWSのサービス紹介も兼ねて、どんな時にどのデータベースを選択すべきなのか、についてまとめてみようかと思います。 元ネタは、最近参加させていただいたラスベガスでのAWS re:Inventの"Which Database to Use When?"というセッションになります。 こちらに動画が既にアップされていますので、興味がある方はこちらを見てみてください。 DB選択においてまず考慮すべき3つの項目 Shape Siz
先程、公式ブログにてDynamoDBのトランザクションがネイティブでサポートされた事が発表されました！！ DynamoDBトランザクションは、単一のAWSアカウントおよび領域内の複数のテーブルにわたって、原子性、一貫性、分離性、耐久性 （ACID）を提供します。 1つの論理的なビジネス操作の一部として、複数のアイテムに対するコーディネートされた挿入、削除、または更新を必要とするアプリケーションを構築するときに、 トランザクションを使用できます。DynamoDBは、複数のパーティションとテーブル間でトランザクションをサポートする唯一の非リレーショナルデータベースです。 新機能 TransactGetItems TransactWriteItems 各ドキュメント API TransactGetItems TransactWriteItems CLI transact-get-items tr
![[速報]待望のDynamoDBのトランザクションがリリースされました！ #reinvent ｜ DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/69d5e5df38c6d27d133baa3f894a2379a68db070/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_reinvent-2018-city_1200x630.jpeg)
こんにちは。インフラエンジニアの永井(shnagai)です。 サービスで使っているDBをRDS for MySQLからAuroraへ移行するプロジェクトを進めていて、 色々と知見が溜まってきたので、これまでAWS SAの方に聞いたりwebで調べたことについてざっとまとめてみました。 アーキテクチャ リーダエンドポイントによる負荷分散と共有ストレージモデルのメリットが大きい リードレプリカアクセスにLB機能がある リーダエンドポイントによって、ヘルスチェック&ラウンドロビンで読み取りアクセスに負荷分散 レプリカ0の場合は、writerにアクセスがいく アプリケーション側のエンドポイントとしては、リーダエンドポイントを指すことでr53では出来なかったヘルスチェック機能付き負荷分散可能(パブリックアクセス許可しないとr53からのヘルスチェックは使えない。。) & HA Proxyやライブラリで行
開発時のDynamoDB環境としてDynamoDB Localを用いた際に行なったノウハウを公開します。 DynamoDB Local立ち上げや管理画面であるDyanmoDB Admin、AWS SDK for Python (Boto3)を用いたDynamoDB Localへのアクセス方法等を紹介します。 はじめに 好物はインフラとフロントエンドのかじわらゆたかです。 現在私が構築を行っているサービスでは、DynamoDBをデータストアとして用いています。 開発時に開発者各々に開発用のDynamoDBのテーブルを作成すると、 テーブル名の重複やコストの問題が発生してしまいます。 これらの問題を回避するため、開発時にはDynamoDB Localを用いて開発を進めました。 それらの手法についてお伝えします。 環境は以下の環境で実施しております。 Mac OS X High Sierra 1
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon Aurora Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適
サーバ監視サービスMackerelにおいて開発中の、高解像度・長期間のサーバメトリック収集を実現するための新しい時系列データベースDiamondを紹介します。具体的には、Amazon ElastiCache、Amazon DynamoDB、Amazon S3を組み合わせ、Amazon Kinesis StreamsとAWS Lambdaによりコンポーネント間を接続した、階層構造のデータストアアーキテクチャの設計と実装を解説します。 2018/06/05 追記: この記事の内容をWSA研#2でより一般的なアーキテクチャレベルでの貢献として書き直しました。 サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ はじめに 先日開催されたAWS Summit Tokyo 2017にて、「時系列データベースという概念をクラウドの技で再構築する」というタイトルで登壇
普段開発とかしない人達にもデータベースに簡単に触れられるようにしたお話です． 安全なデータベースを作る 本番サービスのデータベースと同等，だけど個人情報的なものは隠しておきたい，よく聞く話ですね． これについては様々なアプローチがあるようですが，できる限り安定させたい＆バッチでやるにしてもサーバの面倒を見たくない，とう方針のもと，RDSのスナップショットを利用して作成することにしました． 処理の流れ RDSが1日1回スナップショットを取っている(これはRDSの機能) RDSのスナップショットが取られると，RDSからイベント通知が投げられるので，SNS→SQSへ届くようにしておく(これもRDSの機能) CloudWatchでSQSのキュー数を監視するようにしておき，キューが1つ以上になると処理用のインスタンスを立ちあげる設定にしておく(CloudWatch，AutoScalingの機能) イ
ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
