エンジニアの津田です。スタメンで運営しているサービス、「TUNAG」では、毎日、データベースの"その日の状態"を別々のデータベースとして残していました。こちらの運用を、AWSのS3、Glue、Athenaを利用して置き換えたのですが、その中で利用した、MySQL互換Auroraから、S3上へのデータ抽出用スクリプトの紹介をいたします。Aurora(MySQL互換)を使用しています。サービス利用状況の分析などで、過去の特定時点でのデータベースが必要となるため、いままでは、日次でデータベースのコピーを作成し、一つのRDSインスタンス内に追加していました。この形式では、全てを使い慣れたデータベース上で完結できるため、機能の構築は素早く行えたのですが、データ総量が日々増え、処理時間が次第に増大していました。なんらかの原因で処理が失敗した場合の再試行にかかる時間も含めると許容できない長さになりつつあったため、以下のように置き換えています。Glueジョブで各テーブルの内容をparquet形式でS3上に抽出し、データの利用はAthena経由としています。今回紹介するのは、図の黄色い部分で使用したGlueジョブのスクリプトです。(ETL)を行うマネージド型のサービスです。job」ボタンから、コードを一行も書かずに処理を作成することも可能です。今後、テーブルの追加があった場合、手動で個別にジョブを追加といった手順が必要となります。元になるデータベースへのテーブル追加はそれなりの頻度で発生するため、そのたびにジョブを作成するのは嬉しくありません。そこで、生成されたスクリプトをベースに、mysqlのinformation_schemaを参照して、データベース内の全てのテーブルを調べて抽出するよう変更しました。抽出する必要がないテーブルはfilterで弾いておく。frameを書き出す。capacityという項目があり、スケールアウトするために使用できるデータ処理単位(DPU)を指定できます。容量計画のモニタリングを参考にメトリクスを確認したところ、先述のスクリプトの書き方ではDPUを使い切れていなかったので、適当と思われる数字に減らして設定し直しました。アプリケーションマスター用に予約されています。ドライバー用に予約されています。3になると思われます。DPU2だと利用できるエグゼキュータ数は1ですが、DPU3だと3で、三倍になります。エグゼキューター時間3で終わる処理があるとすると、DPU2では3/1で3時間、DPU3なら3/3で1時間で終わります。6)の半額で済む計算です。capacityは、必要とされるエグゼキュターの数を上回らない範囲で大きな値を設定すると、処理が早く、かつ、費用が抑えられることになると思われます。LambdaでRubyスクリプトを使って実装しています。こちらについては、@uuushiroが名古屋Ruby会議04で発表しますので、よろしければお越しください。2019にも出場させていただきますので、よろしくお願いします。5.1から6.1へのバージョンアップをカナリアリリースしましたこんにちは、スタメンのエンジニア、津田です。Prismaで認証付きアプリケーションの作成こんにちは。フロントエンドエンジニアの渡邉です。こんにちは、スタメンの松谷(@uuushiro)です。株式会社スタメンでは、エンジニア採用を強化しています。ご興味のある方はぜひエンジニア採用情報をご覧ください。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。