はてなブックマーク

こちらは primeNumber AI Native Summer Calendarの記事です。 本日の担当は、CTO の kekekenta (@kekekenta) です。 他の記事も読みたい人は カレンダー を見てください! はじめに インシデントの再発防止策として「レビューで注意する」「チェックリストに追加」といったアクションを決めても、時間とともに形骸化してしまう経験はありませんか? TROCCO/COMETAの開発チームでは、AIエージェント(Claude Code)を活用して、過去のインシデントから学んだ知見をもとに、AIのレビューで事前に問題を検知することを試しています。 課題:人の記憶に頼る再発防止策の限界 primeNumber では、インシデントやヒヤリハットが発生した場合にポストモーテムを実施し、再発防止のアクションを決定しています。しかし、以下のような課題がありま

through-bastion /tmp/10mb_test_file Running iteration 1... Iteration 1: Latency = 1663 ms Running iteration 2... Iteration 2: Latency = 914 ms Running iteration 3... Iteration 3: Latency = 967 ms Running iteration 4... Iteration 4: Latency = 912 ms Running iteration 5... Iteration 5: Latency = 930 ms Running iteration 6... Iteration 6: Latency = 1015 ms Running iteration 7... Iteration 7: Latency

はじめに TROCCO は 2018 年にローンチしてから成長を続け、2024年には1日20万個のデータ転送ジョブを実行するプラットフォームに進化しています。 進化の歴史の中で、1000 GB 以上 のメモリ確保量を削減をした事例があります。 (※(注記) 縦軸の値は集計期間が大きいためまとめられています) 移行後、1年近く安定して運用実績を残せたため アーキテクチャ移行の歴史を記録に残すこと 安全に移行するプロセスの知見共有 を目的として記事にしました。 前半はシステム個別の課題の話ですが、後半の移行の考え方は多くの人に役に立つものではないかと思います。 改善した機能(TROCCO のワークフロー) TROCCO はデータ分析基盤の総合支援 SaaS です。具体的には、MySQL や Salesforce や Google Ads、Amazon S3 など様々なデータソースから、BigQuery

はじめに TROCCO では ETL ジョブや、dbt 連携、ワークフローなど、様々なジョブで実行ログをリアルタイムで見ることができます。 これによりエラー時のトラブルシュートをスムーズに行うことができます。 そして、この実行ログですが、DB にあるジョブのレコードの1カラムに書き込まれていました。 このように TROCCO の実行ログの表示機能は、データベースのアンチパターンの上に成り立っています。 ログデータは TEXT 型で DB に保存されているためサイズが大きく、また TROCCO の成長に応じてジョブ数は増えるため、ログデータもサービスの成長とともに無限に成長してしまいます。 おかげさまでアカウント数は増加の一方であり、それに伴い DDL が遅くなったり、また SELECT のパフォーマンスも当然落ちるため、INDEX に気をつけたりする必要がありました。 SRE ではこれに課

はじめに お世話になっております。primeuNumberの庵原です。 処暑の候、いかがお過ごしでしょうか。 今回はGoogle CloudのDatastreamを本番運用開始するにあたって検証した内容や構築に際してつまづいた点やTipsなどを共有できればと思います。 対象 Datastreamについて興味がある方 RDBMSからBigQueryへのレプリケーション(複製)の実際のソリューションが気になる方 DatastreamのTipsやつまづいた点が気になる方 Datastreamについての説明 概要 ・MySQL、PostgreSQL、AlloyDB、SQL Server、Oracle データベースからのストリーミング データへのアクセス ・BigQuery for Datastream を使用した BigQuery で、ほぼリアルタイムの分析を実現 ・安全性の高い組み込み接続が利用

この記事は trocco Advent Calendar 2023 の6日目の記事となります。 はじめに 今回はtroccoの内部でも利用されているETLのためのOSSであるEmbulkについて、core部分のソースコードリーディングを通して、そのしくみを紐解いていきたいと思います。 おことわり Embulkの基本的な使い方などについては解説しません。 筆者はembulk-coreにコントリビュートしているわけではないので、間違いなどがあればお気軽にご指摘ください。 今回見ていくcoreの実装自体は、比較的変更が少ないとされる各種プラグインが従うべきインターフェース部分(embulk-spi)から隠蔽されているため、今後この記事の内容が正しくなくなる可能性は容易にあります。 Embulkにはguessやpreviewやresumeといった機能も含まれていますが、今回は単純なembulk r

こんにちは。SWEの中村(@mnmandahalf)です。 最近サービス稼働中にDDLを適用するタイミングで初遭遇したMySQLのエラーについて皆様にご紹介したいと思います。 エラーの内容と発生条件(概要) 1 トランザクション分離レベル transaction-isolation が REPEATABLE-READ である 2 セッションAのトランザクション内でテーブルt1をメタデータロックしないテーブルt2へのSQLを実行 3 セッションBがテーブルt1に対して特定のDDLを実行 4 セッションAがテーブルt1を参照すると ERROR 1412 (HY000): Table definition has changed, please retry transaction というエラーが発生し、セッションAのトランザクションがロールバックする ※(注記)なお、テーブルt2がテーブルt1への外部キ

trocco® SREの髙塚(@tk3fftk)です。 Security-JAWS【第30回】[Security-JAWS DAYS] のCTFに参加してきたので、writeup的なものを書いてみます。 オフライン会場はprimeNumberのオフィスとはお隣!だったのですが、諸事情により自宅からオンライン参加をしていました。 どういうイベントだったの? 以下、引用ですがこんな感じです。 Security-JAWSは、AWS+Securityをコンセプトに立ち上げられた勉強会になります。 第30回は記念回として「Security-JAWS DAYS」と題し、オンライン+オフラインのハイブリッドでしかも2日間の開催です! Day1はカンファレンスデイ、Day2はCTFデイとなります。 詳しくはイベントページの Security-JAWS【第30回】[Security-JAWS DAYS] ~

はじめに 最近深層距離学習が気になっており、いろいろ勉強する日々を送っています。 そんな中、過去のKaggleなどの画像系コンペでElasticFaceを用いた解法を時折見かけ、試してみよ〜と思ったのですが、意外に日本語の解説記事等がなかったので備忘録的に書き起こしておこうと思います。 元論文はこちら CosFace・ArcFace CosFace・ArcFaceはサーベイ論文で名を挙げられるほど強力な角度系距離学習の1つです。 「とりあえず使える」という部分もさることながら、直感的に理解できる部分もポイントが高いです。 式 Cosface -\frac{1}{N} \sum_{i=1}^N \log \frac{\exp (s \cos (\theta_{y_i}) - m)}{\exp (s \cos (\theta_{y_i}) - m) + \sum_{k \neq y_i} \e

TL;DR strong_migrations gemの導入により、開発者がルールを意識しなくてもRailsマイグレーションのメタデータロック待ちのリスクを低減させることができた タイムアウト時のマイグレーションのリトライ機能や危険なマイグレーションのチェックが便利なため、Railsのマイグレーションを行う際はとりあえず導入するのがおすすめ 導入の経緯 trocco®開発チームではアプリケーションにRails、RDBにMySQLを使用しており、DBスキーマのマイグレーションにはRailsのマイグレーション機能を利用しています。 サービス運用を続けるうちにDBへのスロークエリが徐々に増えてきたため、DDL適用によるメタデータロック待ちのリスク[1]が高まってきました。 例えば最悪の場合、以下のような事態が起こりうります。 とあるセッションで数十分レベルのスロークエリが発生 そのクエリが共有メ

はじめに あるプログラムから別のプログラムを実行し、結果を受け取りながら処理を進めたい場面が時折生じます。 しかし、パイプの挙動への注意を怠ると思わぬ問題を引き起こす可能性があります。 実行環境 本記事は、以下の環境にて実行しています。 Ruby: 3.0.6 Ubuntu: 20.04 LTS Linux kernel: 5.15.0-71-generic 以降のプログラムは筆者の普段使いの Ruby で記述していますが、本質的には言語によらない問題です。 また、本記事で取り上げているパイプの概念は Unix 系 OS に広く共通するものですが、具体的な説明としては Linux を中心に話を進めます。 サンプルプログラム 子プログラム 実行に一定時間を要し、その途中で標準出力に結果を書き込むプログラムです。 単純化のため、1 秒の固定頻度で標準出力に書き込むだけですが、現実世界では外部へ