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

はじめに GitHub Actionsを用い、ベースブランチへのマージを自動でブロックする方法をまとめました。 弊社プロダクト[1]ではリリースが行われる日を「休日の前の日を除いた平日」と定めています。 git-pr-release[2]を用い、1日あたり数十個のPull Requestを、まとまった単位でリリースしています。まとまった単位でリリースするために、ベースブランチへのマージを特定の時刻に締め切り、QAチームに動作確認を依頼しています。 この「特定の時刻でマージを締め切る」作業は、ベースブランチのブランチ保護ルールの変更によって行なっています。以前は人の手によって作業がなされていたため、特定の時刻に締め切られないことで動作確認対象のPull Requestが余計に増えてしまい、リリースが遅延していまう問題がありました。 この問題を対処すべく、ベースブランチへのマージを自動でブロッ

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] ~

TL;DR Amazon VPC CNI Pluginを利用したまま、Calicoをインストールすることで、k8sのNetwork Policyと拡張されたCalico Network Policyを利用できます。 Amazon Elastic Kubernetes Service (EKS) | Calico Documentation より Calico Network Policyを利用するとServiceを利用したポリシー設定が可能となります。 そのため、ユーザー側で制御できないタイミングでIPが更新されてしまうEKSのk8s APIに対しても制限ができます。 k8s Network Policyと異なる点がいくつかあり、例えばデフォルトの挙動が Deny となっていることに注意が必要です。 背景 EKSにおいて、セキュリティの観点からEC2のIMDSへのアクセスと、K8s API

はじめに 最近深層距離学習が気になっており、いろいろ勉強する日々を送っています。 そんな中、過去の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]が高まってきました。 例えば最悪の場合、以下のような事態が起こりうります。 とあるセッションで数十分レベルのスロークエリが発生 そのクエリが共有メ

日常生活においては「別に正しいスペルなんて知らなくても・・・」と思うのですが、プログラミングにおいてはスペルミス (typo) はあわや一大事です。 アルファベットが1文字違えば、プログラムは動かないですからね。 弊社プロダクト[1]はその性質上、さまざまな関連プロダクトの名称がソースコードに登場します。 スペルチェックの導入を検討する上で、そういった固有名詞たちがスペルミスとして扱われないようなツールを求めていました。 そんな中出会ったのがtypos[2]でした。 typosは導入が簡単なだけでなく、固有名詞がまったく引っかからないため、弊社プロダクトの要件にまさに一致するものでした。 そこで、以下をまとめました。 typosでエラーになった単語の紹介 typosの設定方法 typosでエラーになった単語の紹介 typosを実行した際にエラーとなった単語 (スペルミスの一覧) の全てを添

日常生活においては「別に正しいスペルなんて知らなくても・・・」と思うのですが、プログラミングにおいてはスペルミス (typo) はあわや一大事です。 アルファベットが1文字違えば、プログラムは動かないですからね。 弊社プロダクト[1]はその性質上、さまざまな関連プロダクトの名称がソースコードに登場します。 スペルチェックの導入を検討する上で、そういった固有名詞たちがスペルミスとして扱われないようなツールを求めていました。 そんな中出会ったのがtypos[2]でした。 typosは導入が簡単なだけでなく、固有名詞がまったく引っかからないため、弊社プロダクトの要件にまさに一致するものでした。 そこで、以下をまとめました。 typosでエラーになった単語の紹介 typosの設定方法 typosでエラーになった単語の紹介 typosを実行した際にエラーとなった単語 (スペルミスの一覧) の全てを添

はじめに ローカル環境などでRuboCopを実行する際にはよしなにキャッシュが利用され、高速化が図られています。 一方で、CircleCI上ではそうはいきません。RuboCopのキャッシュディレクトリを設定し、設定したディレクトリをCircleCIの依存関係のキャッシュ[1]を用いて次回以降のジョブに使い回す必要があります。 そこで、以下をまとめました。 キャッシュの利用によってどの程度の改善が見込めるのか キャッシュの設定方法 キャッシュの有無による実行時間の比較 先にまとめを貼ります。 キャッシュの有無 RuboCop (秒) キャッシュのリストア (秒) 合計 (秒)