この記事はエムスリー Advent Calendar 2022の30日目の記事です。 前日は id:kijuky による チームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作った でした。 AI・機械学習チームの北川(@kitagry)です。 今回はMySQLへのインサートを20倍以上高速化した話について書きます。 仕事をちゃんとしてるか見張る猫 TL; DR はじめに 今回のテーブル バイナリログを無効化する 追試 LOAD DATA INFILE 追試 テーブルの正規化 インデックスを一時的に剥がす まとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使う インデックスを一時的に消す はじめに AI・機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ

気が付いたらperfコマンドから直接flamegraphが生成できるようになっていたので利用方法のメモです。 flamegraphとは "Systems Performance"の本などでも有名なGreggさんの考案したサンプリングしたスタックトレースの情報を可視化するの手法です。視覚的にサンプリングデータの中でどのスタックトレースの実行箇所が多かったかなどを把握することができます。一次情報としてはwebページやgithubを参照してください。 とりあえず図を見た方が理解が早いので早速作成してみます。 perfコマンドから直接生成する方法 ここではperfコマンドを利用して実行中のプロセスに対してスタックトレースのサンプリングを行います。冒頭で触れた通り2020年にperf-toolsに取り込まれたコミットによりperfコマンドから直接flamegraphが生成できるようになっています。

はじめに フューチャー Advent Calendar 2022の16日目です。 昨日は@tutuzさんの技術記事執筆のススメでした。 AWSでアプリケーションに対してIP制御をかけたい、というニーズに応えようとすると、 Security Group WAF etc... といった感じで、いくつか出てきますが、これは言わずもがなそのインフラのアーキテクチャによって、向き不向きや利用の可否が変わってきます。 今年、AWSインフラの追加開発をやっていく中で、「特定のアプリケーションパスのみIP制御を実施したい」というニーズが生まれ、これについて短期間ながらいくつかパターンを試したので、その時のことを思い出していきながら書いていこうと思います。 前提 以下のアーキテクチャのような形で、フロントエンドからAPIという形でFargateを叩いています。 特定のパスにIP制御をかけるパターン 今回、そ

概要 結論から言うと、Streamで扱っているものはStreamのまま扱うです。 具体的にはio.Readerを毎回ioutil.ReadAllで[]byteに変換せずにそのまま使いましょうです。 なぜStreamを使うべきか Node.jsの例ですが、こちらで非常に分かりやすく説明されています。 yosuke-furukawa.hatenablog.com それを踏まえて考えてみると、Goの場合以下の２つが大きいと思います。 1. メモリの効率化 ioutil.ReadAllなどで一旦全て[]byteに変換すると、その分メモリを消費しますし、アロケーションやGCに依る速度低下が起きます。 一方io.Readerやio.Writerは各chunkの処理に同じバイトを使いまわすので、メモリの効率が良いです。 2. 標準パッケージの多くがio.Readerをサポートしてる io.Reader、

運用をしているとダウンタイムかありかに関わらず、alter tableにどれくらいの時間がかかるのか作業前に把握したいことはよくあります。 各種statusを見ることで一定時間でどれくらいの行を書き換えるかを把握することはでき、作業を始めてからであれば、あとどれくらい掛かりそうかは見積もれますが、alter tableの話が出た瞬間にどれくらい掛かりそうかの目処はつけたいです。 今回はalter時に実行されるDMLがなく、テーブルに断片化もないという理想的な環境で、各種Alter操作にどれくらいの時間がかかるのかを実験してみました。 環境やconfigの詳細はあえて書いていませんが、どちらにしろ実際には様々な要因が絡むので、このくらいの情報があれば充分かと思います。 概要 alter tableにかかる時間を計測 on/off memoryでALTER TABLEにどれくらい時間がかわるか

ノートラブルシステムへの道 ビジネス速度を落とさないために

「JAWS-UG SRE支部 #5」で発表した資料 https://jawsug-sre.connpass.com/event/270152/

こんにちは、ブログチームでエンジニアをしている id:Furutsuki です。ブログチームでは長らくEC2上でMySQLを運用していましたが、種々の理由により2021年末から2022年中盤にかけて、このデータベースをAmazon RDSに移行しました。 移行にあたって、新旧のデータベースやサービスの様子を一覧できる“RDS化ダッシュボード”をMackerelで作成しました。チームでは日常的な監視にダッシュボードを活用していますが、個人的にダッシュボードを一から作ったのは初めてだったので、このダッシュボードの配置や狙いについて書いてみようと思います。 RDS化ダッシュボードの全体像 サービスの状態を確認するコーナーの詳細 DBの様子の変遷を確認するコーナーの詳細 皆さんのダッシュボードを教えてください！ RDS化ダッシュボードの全体像 まずはダッシュボード全体をご覧ください。 こうして画像

はじめに こんにちは、Cloud Operations担当者です。このたび私が翻訳として関わった「オブザーバビリティ・エンジニアリング」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。 オブザーバビリティ・エンジニアリング 作者:Charity Majors,Liz Fong-Jones,George MirandaオライリージャパンAmazon www.ohmsha.co.jp 電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。 www.oreilly.co.jp また上記書籍情報ページに質問は報告を行うための連絡先も記載されておりますので、なにかありましたらそちらよりお問い合わせください。 TL;DR 「オブザーバビリティ・エンジニアリング」はオブザーバビリティ

#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。